"clipka" <nomail@nomail> wrote:
> Reading the feature request threads, I get the impression that there are two
> differing opinions out here that are NOT necessarily contraditory...


This is something I've been mulling over for a while, and I agree in concept,
but thought of about 3 major parts.  The most obvious one would be the
rendering engine, which, of course, will doubtless have many subcomponents, but
I am lumping all calculating tasks that are directly required for image output
under 'rendering engine.'  The next would be the parser, which is responsible
for all parsing tasks, including those that may not necessarily result in
rendering.  The parser would also have a standardized interface that allows
plugins to access and add scene objects before handing the parsed scene over to
the rendering engine.

The last is the environment, which would contain an IDE style interface for
direct use, but is not required for remote use.  The environment would have the
typical IDE niceties, like the option of a user having the syntax checked as
they typed (by having the parser do a non-rendering, partial read), but would
just be a colorful interface that calls the parser and renderer via command
line as required.

I favor the idea of keeping them completely separate, so that changes to one
will not affect the other, and could be simply drop in changes.  Some of the
things brought up, such as the idea of macros and objects being able to read
into what is happening in the scene fit well with this.  The parsing engine
could have an xml dtd that tells it what is valid syntax for a given #version.
The parser could populate a DOM as the user enters their scene (or shortly
before rendering), and the parser could recognize (or be told) what it needs to
'come back to.'  For example: Let's say we want a sphere to be green if the
camera is looking up (above the horizon), but red if the camera is looking
down, and we want the sphere to always be in the middle of the frame.

// begin code:
sphere{
 scene.camera.look_at, 1
  // even though the camera look_at vector has not yet been set, this is valid,
  //    because the parser knows where to get that property.

 pigment{ color rgb <1,1,1> }
// it doesn't matter what this is, we will change it below
 name "mySphere"
// new, optional name property that can be applied to any object
}


camera{
 location <0,5,-10>
 look_at <0,2,0>
}

#if( scene.camera.look_at.y > scene.camera.location.y ) // camera is looking
above the horizon
 scene.objects.mySphere.pigment.color = <0,1,0>;
#else
 scene.objects.spheres[0].pigment.color = <1,0,0>;
 // also a valid reference, alternate syntax
 //  allows un-named objects to be referenced
#end

// end code

We could set variables and have the camera and sphere respond to both of them,
but to maximize backward scene compatibility, I would prefer something similar
to the above.  Wit that, you could take old scenes and includes and rework them
with far less effort by being able to add a few commands in a single place using
the fully qualified names.

It almost goes without saying that this is also fully compatible with an
object/scene browser within the IDE that would allow one to track what objects
reference what other objects/macros/includes.

The above example is mostly at the parser/environment level of what happens
before a scene is parsed with intent to render.  It would also be nice to have
the ability to reference things that will be calculated by the rendering
engine, perhaps by using an asterisk to let the parser know that it will not be
able to determine the exact value until after a rendering task of some sort.

Someone used the example, a while ago, of a macro that would grow moss in dark
corners of an object as determined by the radiosity pretrace data.  That is a
good example of the type of data that could be referenced by a scene element,
but cannot be determined by the parser itself.  Only the rendering engine would
know.

I think accessing this data is facilitated by splitting the rendering engine
into separate parts, even separate applications - a radiosity calculating one,
a photon one, etc - that take the scene data, do their part, and return the
result (which could, in turn, could be accessed by code within the scene before
the next engine is called).

This requires, of course, a method of specifying what order the engines are
called in and what is done with the result, which I would allow the user to
specify in the ini file.  In theory, if one wanted to have the moss grow in
dark corners created by other moss, then they could specify the radiosity step
twice, and ignore (or save) the first result from an image output standpoint
(this means that one could do a low quality radiosity pretrace, have the scene
respond to it, then do a higher quality trace).


There are many other things that need to be addressed, of course - issues such
as object access modifiers (to prevent a macro from accidentally changing
objects elsewhere in a scene), object storage classes (to tell the parser
whether or not to reparse an object between engine calls or even frames of an
animation), but I do have ideas for those, too...

-Reactor

Post a reply to this message