|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> > Do we think that there's a way to export POV-Ray's "Abstract Syntax Tree" or
> > whatever we use after the scene has been parsed and lexed?
>
> Disclaimer. I am no parser / (POV-Ray parsing) expert...
>
> ... Suppose maybe code could be hacked and whacked to export something
> for, say, the expression parsing alone.
>
> Beyond that, my bet is it would be difficult to do without a significant
> investment of time - and the result won't be clean. I certainly don't
> have anything in hand. Maybe others have made runs at such work and have
> something more?
Right, but at the moment we really don't have anything, so even the most
imperfect / incomplete thing would be a step forward.
Do you know if the AST is - - - assembled into some kind of data structure in
memory right before rendering, and that's what the render phase operates upon?
Perhaps that data structure could just be barfed out so that we could take a
gander at it.
> Today's POV-Ray / yuqk parsers are convoluted and tangled with the
> raytracing code itself. I see the current parsers as more like
> semi-direct text to scene translators.
Right - this is the part that I don't understand. How does the parser and
raytracing code get entangled like that? Even a small example where two are
intertwined would help. Just point to line #'s nnn-NNN in such-and-such a file.
> > Comparing and contrasting a new parser with one that's being developed would be
> > a useful debugging tool, and a way to measure progress and completion.
> >
>
> In offline discussions with jr, we discussed some approaches to a brand
> new parser and with a POV-Ray 4.0 (or 5.0). There is value to thinking
> hard about what Scene Description Language 2.0 should be and perhaps
> writing potential parsers for it that interface to something. I'd lean
> toward that 'something' being a limited set of today's SDL while working
> up what we want any language implementation to be. (Perhaps flattened /
> un-nested SDL using very few language directives)
Likewise, we've had several discussions and brainstorming sessions.
However before we start talking about a new SDL, I think we need to understand
the parsing lexing part.
I actually feel confident enough to write a lot of the actual raytracing code
myself - and luckily, I don't think there will need to be a lot of it
(re)written.
By flattened un-nested SDL, you're suggesting something akin to writing a scene
in another language and having it generate every instance of a thing that would
be in a loop in current SDL. So if I had a loop that instantiated 100 spheres,
what we'd be doing is writing out the code for all 100 spheres individually to
be parsed.
> Much in the POV-Ray source code needs/could-use work/refining. This
> includes the core functionality itself - and the core feature set is
> where I've been focused for the better part of a decade now.
So you've added features to SDL.
We are all curious about exactly what needs to happen to fully accomplish such a
task.
See such an explanation by Leigh Orf at:
https://dl.acm.org/doi/fullHtml/10.5555/1029015.1029017
Apparently there are specific things that need to be done in several files to
make this happen.
- BW
Post a reply to this message
|
|