On Sun, 13 Aug 2000 22:18:17 +0100, Neil Freebairn wrote:
>
>Peter J. Holzer <hjp### [at] SiKituwsracat> wrote in message
>news:slr### [at] tealhhjpat...
>> There probably isn't a logical place where it could have been saved,
>> cause the parsing threaded its way through a dozen or more different
>> functions, each only handling a small part of the input.
>
>But that isn't to say that these functions couldn't concatenate their
>small bits of parsing input back into the complete 'original' string.

Yes, they could. but it probably means lots of little changes scattered
all over the source code. Also I don't think this is "the right way to
do it".

>> You have, however, the complete internal represenation of the object
>> (some kind of tree structure) and it should be possible to dump that
>> in any format you want. There is already a patch for povray which
>> does something like this: After parsing the whole scene, it just
>> dumps it in some binary format (called POB I think) to a file.
>
>With one exception, everything I've read suggests that the existing POB
>SDK cannot parse macros.

As far as I know (please correct me if I'm wrong), the POB SDK cannot
parse any PovScript. It can only parse POB files. To convert PovScript
into POB, you use a specially patched version of Povray, which dumps the
internal scene representation to a POB file. At this point, macros don't
exist any more, so they aren't a problem.

But the patches at Thomas' site are for Povray 3.0. Obviously, you
cannot use Povray 3.0 to parse a file which uses features (like macros
or media) which were only introduced in Povray 3.1. You would have to
port the patches to version 3.1. To do this you need to know C.


>> To dump in PovScript or give PovScript the ability to access a string
>> representation of its own objects, it would just have to be changed
>> to produce PovScript instead of the binary representation. A simple
>> but rather boring coding exercise, IMHO.
>
>As I had hoped! I was hoping that enthusiasm for the result - a pathway
>from POV-Ray to all the other great 3D apps and utilities out there -
>might provide the motivation...

I tried to convert a model of mine to some other format about a year
ago. It was still a povray 3.0 scene, so i could use POB. However, I
found that wasn't any help. The problem with converting PovScript to
almost any other format is those formats can only handle surfaces, not
bodies. This means that you cannot convert something as simple as

    difference {
	sphere { <0,0,0>, 1 }
	sphere [ <0,1,0>, 0.5 }
    }

into those format by simple text conversion. You have to compute where
the two spheres meet and replace the two sphere parts (what's "Kalotte"
in English? - calotte seems to be some kind of hat) by equivalent bezier
patches, or nurbs, or a bunch of triangles. I think there is even a
(low quality) macro for this, but it needs MegaPOV.

Apart from that, writing a PovScript-to-Povscript converter in C and
then a PovScript-to-SomethingElse converter in PovScript seems to me to
be about the most roundabout way to do this. Kind of like implementing a
Basic Interpreter in TeX, or a calculator with sendmail macros. 

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message