Peter J. Holzer <hjp### [at] SiKituwsracat> wrote in message
news:slr### [at] tealhhjpat...
> On Fri, 11 Aug 2000 17:18:36 +0100, Neil Freebairn wrote:
> >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.

I wasn't terribly clear about this, but, since I only needed to refer to the
basic functions of the process, my description of POV's parser was meant to
describe only the essential black boxes, and therefore to be in some sense
sufficiently abstract to be guaranteed to be correct. 'At this point' would
better be said "at these points [i.e. when we have pieces of a longer string
that we recognise as tokens or not]".

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

> 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. Thomas Baier, the author, says it can be done, but I
suspect (in the absence of very much information from him) he means the same
as you: the converter is there, it just needs to be integrated. It's the
integration that I am trying to achieve through a quick'n'dirty route.

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

If not, perhaps you could describe in some detail what would need to be
done.

Neil

Post a reply to this message