Reading the feature request threads, I get the impression that there are two
differing opinions out here that are NOT necessarily contraditory:

- Some people argue that a rendering engine should be "lean & mean"

- Other people argue that optimization of some stuff is a must, plus the scene
description language should remain easy enough for the 3d artist

Where's the contradiction?

Both can be done IF a good extension mechanism is built into BOTH the core
engine AND the scene scripting language.

One plug-in could provide generic objects / patterns / shaders / what-have-you,
to be scripted via functions to get all the bells & whistles at the fingertips
of the 3d scene language "coder".

Another plug-in (or set of plug-ins) could provide primitive objects and some
standard patterns / shaders / etc., easily configurable via a few parameters,
exposed by the scene language (but defined by the plug-in) for the 3d scene
"artist" who doesn't want to be bothered with too much coding - and/or for
people who appreciate optimized code for such things.

And the very hard-core coders could write their own objects using C++, or maybe
even a programming language of their choice, to get optimized code for highly
specialized needs, avoid long scene file parsing times or whatever.


So, basically, e.g. an object could expose:
- A standard interface to get its bounding box
- A standard interface to test for a ray-to-object intersection, and retrieve
the associated parameters: location, unpertubed normal, and pertubed normal
(for mesh-like objects)
- A standard interface to build a "generic" object from itself (I'd suggest an
isosurface)
- Maybe one or two things I'm missing here because I'm not that much of a
raytracing expert
(This API could be extended in future if some features turned out to be of great
benefit and easily optimizable for some objects; for "old" plug-in objects,
those features could be handled using a non-optimized isosurface proxy)
- PLUS a list of parameters, each with information such as:
    - parameter name
    - type
    - optional yes / no
    - address of function to call for set/get

For example, a sphere would have the following parameters:
    center / vector          / optional (might default to <0,0,0>)
    radius / positive scalar / optional (might default to 1)

(Any other parameter is, of couse, not the job of the sphere object; the pure
geometric properties are sufficiently described.)

The SDL would then expose these parameters to the user, like say:

    object {
        shape = sphere {
            center = <3,2,0>;
            radius = 2 * radius;
        };
        material = diffuse_material {
            ...
        };
    };

(just as an example for how it COULD look like) meaning:

    - create an object container.
    - create a sphere and add it to the container as its shape
    - set the center of the sphere to <3,2,0>
    - get the current radius of the sphere, multiply it by 2,
      and set it as the new radius
      (just a trivial example of how scripting might work)


This approach would have some advantages, all of which boil down to more clearly
defining the various components of the ray tracer.

So the essential idea is to have very generic interfaces for everything that
needs to be done during raytracing - yet leave it up to other parts of the
software (or even the user himself) to decide whether to actually expose all
that genericity to the user, or instead encapsulate a good deal of it for
various common cases in order to gain speed and ease of use.

Post a reply to this message