clipka <nomail@nomail> wrote:
> I guess this boils down to about the same as what I had in mind about separating
> what would basically be the tokenizer, and the actual parser. Except that what
> you call bytecode, I'd call a serialized "syntax tree"

  I don't think it's necessary to keep any kind of "syntax tree" data in
any form once the scene file has been parsed and compiled into bytecode.
The bytecode can be very straightforward asm-like series of opcodes and
their parameters. The advantage of this is that it's very fast to interpret
(which can be important at rendertime), and even JIT-compile.

> I don't think, however, that JIT-compiling would make any sense or be an option:

  I don't see why not. Many scripting languages have that.

> > - Currently there's a distinction between parse-time scripting (the SDL)
> >   and rendertime scripting (user-defined functions, used eg. in isosurfaces).
> >   Rather obviously no such distinction should be made in the new language.
> >   Anything you write should be runnable at parse time and at rendertime
> >   (and also at the post-processing stage).

> Yes and no. Obviously the render-time scripting should have exactly the same
> syntax as the parse-time scripting, most notably access to the same integrated
> identifiers. However, things like generating additional geometric objects, or
> even just modifying existing ones, is a definite no-go for render-time code.

  Not "same syntax". The one and only scripting language, down to the bytecode
compiler and bytecode interpreter.

  There may be additional limitations for the rendertime code, but
that doesn't mean it has to be separate from the compile-time code.

  It makes no sense to create two scripting languages with two compilers
and two interpreters. That will only be more work and very confusing for
the users (even more than the current SDL / user-defined function
distinction).

> > - Object properties, such as textures, should be fully specifiable using
> >   the scripting language itself (facilitated by the previous point). In
> >   other words, you should be able to write, for example, "shaders" with
> >   the scripting language. This "shader" is evaluated every time that
> >   certain property of the object (eg. its texture) is needed.
> ....
> > - Most core renderer features should be available to the scripting language.
> >   As an example, you should be able to launch a ray from a given point and
> >   retrieve the color it returns.

> I think these ideas are not realistic in near future, as they require yet
> another major architectural change of POV-Ray, and I guess we want a new SDL
> earlier.

  POV-Ray 4 was supposed to be a complete rewrite anyways. If it is, then
it should be done properly.

> In addition, I'd advocate not to implement those functions in script code, but
> instead have them remain binary modules, albeit separated from the main engine
> code more strictly, e.g. as a kind of plug-in.

  That sounds to me like it will only make the whole system more complicated,
not simpler.

  A simple core engine (only things which require speed should be there),
a simple script interpreter. Everything else as libraries written in the
scripting language. Let the complexities be inside the libraries, not in
the core engine.

> This would presume that the SDL in fact provide an interface to define new
> geometric entities. These would have to be render-time code.

> I don't really think there is much use for such objects, and that instead giving
> more flexibility to functions to be used in isosurfaces is the way to go.

  I consider those sentences contradictory.

  "There's no use for user-defined objects. Instead, we should enhance
the properties of usef-defined objects (isosurfaces)."

  I'd say no: Don't clutter the already cluttered features with even more
clutter. Instead, make a clean simple implementation which can be used for
the same thing, but with more flexibility.

-- 
                                                          - Warp

Post a reply to this message