"Reactor" <rea### [at] hotmailcom> wrote:
> 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

This is a hybrid approach which won't work out:

- Referencing the camera location from within an object defined before the
camera actually is, you imply that the scene file is something static, and
forward references can always be made because "the parser knows where to get
that property"

- The code afterwards, which dynamically changes the sphere's pigment, implies
that the scene file is something dynamic, which can change during parsing.

The following code shows why that can't work:

sphere { scene.camera.look_at, 1 }
camera { location <0,5,-10> look_at <0,2,0> }
scene.camera.look_at += <0.1,0.1,0.1>;

Which "version" of the camera location should the sphere reference?

And if you do something like this, you're totally screwed:

sphere MySphere { scene.camera.look_at, 1 }
camera { location <0,5,-10> look_at scene.objects[MySphere].center + <1,0,0> }

So it needs to be decided whether the approach will be a static "scene markup
language", or a scripting language.

You might go for a mix like in dynamic HTML, but that's actually two separate
languages that "feed back" on each other, which doesn't help make the concept
of their combination easier.

I guess a scripting language will be perfectly fine, and the concept will
actually be much easier to grasp to the average user. If you ever did XSLT with
its static approach you probably know what I mean - at least it gave me brain
haemorrhaeging, virtually speaking.

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

How about am approach like this - in a script-oriented world it should work:

sphere { <0,0,0>, 1 }
camera { location <2,0,0> look_at <0,0,0> }
render
result.save { png, "my_scene_x.png" }
camera { location <0,2,0> look_at <0,0,0> }
sphere { <0,1,0>, 0.5 color result.average_color }
render
result.save { png, "my_scene_y.png" }

Question here is, how to make this user-friendly so that the user doesn't have
to type the standard commands for every simple scene that is just to be
rendered and that's it.

Maybe something like:

process {
  sphere { <0,0,0>, 1 }
  camera { location <2,0,0> look_at <0,0,0> }
  engine.raytrace
  engine.result.save { png, "my_scene_x.png" }
  camera { location <0,2,0> look_at <0,0,0> }
  sphere { <0,1,0>, 0.5 color result.average_color }
  engine.do_photons
  engine.do_radiosity
  engine.raytrace
  engine.result.save { png, "my_scene_y.png" }
}

if the scene doesn't contain a "process{}" statement, a default one is
constructed (or simply implied) around it:

process {
  // actual scene file content
  engine.do_photons
  engine.do_radiosity
  engine.raytrace
  engine.result.save { ... }
}


So what we'd do this way, we'd be constructing a language to script the
individual components of the renderer: Scene builder, photon shooter, radiosity
gatherer, output file writer, and so on.

Post a reply to this message