Warp <war### [at] tagpovrayorg> wrote:
> - It must be easily byte-compilable. Preferably to a byte code which may
>   be easily JIT-compiled to native machine code in some future version.
>   Even without JIT-compiling just the fact of having it in bytecode
>   format can make parsing an order of magnitude faster.
>
> - The bytecode will also allow saving scenes in bytecode format for
>   faster parsing. (Basically the need to parse the scene is removed
>   completely, except for some sanity checks of the bytecode.)

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, however, that JIT-compiling would make any sense or be an option:

- A JIT-compiler integrated into POV-Ray itself is, quite obviously, no more
than a distant dream.

- Using an external JIT-compiler would require another piece of software (namely
the JIT-compiler) to run POV; I don't think this is acceptable.

- Integration of an external JIT-compiler would pose major architectural
problems, which I guess are better left unaddressed, given the number of other
ideas pending implementation and the desire of users to have them all ASAP.

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

Or, to put it in other words: Render-time code should be restricted to read-only
ops. Temp variables would come in handy, but their lifetime and scope should be
limited to the current invocation of the function for a whole bunch of reasons
- the most important being that many POV internals rely on user functions to be
stateless. Throwing this overboard would open up a can of really nasty worms.

> - 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. However, it is a good point to keep in mind when designing that
language.

But note also that these shaders, being render-time code, would not be able to
use data caches or stuff alike, due to restriction on statelessness. I'd
advocate that shaders that require stateful operation be written as binary
plug-ins of sort.

> - Related to that, the scripting language should be so flexible that many
>   current core features can be removed from the core renderer and put into
>   libraries.

Given how complex the render engine currently is regarding even seemingly simple
tasks, such as shooting a ray and seeing what color you get, I must conclude
that (a) heading for that goal would definitely be of benefit for the internal
architecture of the render engine, but (b) I'd be prepared for that goal to be
never actually reached.

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.

> - The design principle of the new scripting language should have some kind
>   of "unified object model" approach. With this I mean that core objects
>   and user-created objects should work and be usable in the exact same way.
>   That is, it doesn't matter whether a "sphere" object is a core feature
>   or something which came from a library. In either case you would use that
>   "sphere" object in the exact same way (as long as you know its interface,
>   of course).

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.

>     For example, if you wanted to access (read, change) the texture of the
>   object, it would be done with an identical syntax regardless of whether
>   the object is a core feature or defined in a library.

Yes, that's an important consistency thing. It will probably also make the
parser more lightweight. At the moment, every property for every thing has its
own code snippet in the parser.

> - As for memory management: Garbage collection (as in the one in Java or C#)
>   might be nice, but VERY hard to implement efficiently. If possible the
>   scripting language should be designed in a way which makes creating a GC
>   engine unnecessary.
>     This might mean that the only way to use dynamic memory is through the
>   dynamic data containers provided. However, that might be enough for
>   almost everything. (After all, most people have done cool things with
>   the current array feature, even though it's *really* rigid. The new
>   data containers will be much more flexible.)

Yes, I guess this is the way to go. It makes for clear memory handling
responsibilities: The built-in containers do all that's needed; they'll also
care for either copying items, or keeping a reference counter to know when a
shared entity is no longer needed. That should do for most practical purposes
(after all, we're not writing complex business applications in the order of
magnitude of several man-years ;))

Post a reply to this message