POV-Ray : Newsgroups : povray.programming : POV-Ray 3.1 to other file formats - a possible solution : Re: POV-Ray 3.1 to other file formats - a possible solution Server Time
28 Jul 2024 20:30:23 EDT (-0400)
  Re: POV-Ray 3.1 to other file formats - a possible solution  
From: Peter J  Holzer
Date: 13 Aug 2000 12:00:56
Message: <slrn8pdgcs.u4n.hjp-usenet@teal.h.hjp.at>
On Fri, 11 Aug 2000 17:18:36 +0100, Neil Freebairn wrote:
>
>Chris Huff <chr### [at] maccom> wrote in message
>news:chrishuff-2701B4.09084811082000@news.povray.org...
>> In article <3993ce85@news.povray.org>, "Neil Freebairn"
>> The text that created an object is not associated with the identifier,
>> only the object data itself is. You would have to write out code
>> representing the current state of the object, so it *would* be a
>> conversion function.
>> It might be possible to save the string that produced the object, but I
>> have no idea how to do that.
>>
>
>I don't know very much about language parsing, but I'm guessing it works a
>bit like this.
>
>In parsing a declarative, the POV-Ray parser encounters '#declare' (or
>'#local'), stores the identifier 'MyObj', looks for the equals, then reads
>everything after the equals until the end is flagged (various conditions
>apply). At this point, if we could save this string - the right-hand side of
>the equals - against this identifier for returning using our function, we'd
>be home and dry.

I don't think so. I haven't looked at the Pov parser in detail, but from
what I have seen, it's a typical tokenizing recursive descent parser. It
always only keeps the current "token" (an identifier, operator, string,
...) as a string (plus some buffer for performance reasons). After it
has recogized the token, its string representation is discarded and it
is either converted to some internal format or only used to decide what
to do next.

So, when the final '}' of an object declaration is reached, there is
nowhere in memory a complete string representation of the object. 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. 

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.
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.

	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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.