[Bf-committers] Final Design of Basics (render api)

[Jonathan Merritt]

Hi Aaron,

Aaron Moore wrote:
> Hi,
>
> I just completed my final design of:
>
> 1) The basic Render API.
> 2) The Render API plugin system.
>
> http://wiki.blender.org/index.php/Render_API
>   
<snip/>

I think this document looks very good, and you've come to grips with the 
requirements quickly.

I have a couple of initial thoughts:

1. Object Names
I think it's useful to include these simply for debugging / editing 
purposes.  In the RenderMan world, it's common to mark objects with 
something like this (RIB chunk):
    Attribute "identifier" "name" ["MyWonderfulMesh"]
This has multiple uses:
    - The renderer can name the object if something goes wrong (eg. 
eyesplits exceeded).
    - You can find the object later (eg. if you need to tweak something 
like a shader).
Without this information, identifying objects - troublesome or otherwise 
- can be difficult.

2. Deformation Motion Blur
In the RenderMan world, there are really two different kinds of motion 
blur: transformation motion blur and deformation motion blur (I'm 
considering camera motion blur as a kind of transformation motion blur 
here; some people choose to separate it too).  Transformation motion 
blur deals with the "bulk" motion blur of an object, expressed purely 
through its transformation; eg:
    MotionBegin 0 1
        ConcatTransform ...
        ConcatTransform ...
    MotionEnd
Whereas deformation motion blur deals with the motion blur of 
deformations *within* the geometry and shading of the object itself; eg:
    MotionBegin 0 1
       SubdivisionMesh ...
       SubdivisionMesh ...
    MotionEnd
I can see how transformation motion blur is likely to work with the API, 
but I'm not sure that quite enough infrastructure is there yet for 
deformation motion blur.  There are some important restrictions on 
deformation motion blur that the render API must ensure before it can be 
used.  Even Section 6 of the RiSpec is a little incomplete on this (the 
Advanced RenderMan book is a more thorough reference), but for meshes, 
parametric and subdiv surfaces those conditions are:
    - Topology must be identical for all motion samples (no changes in 
number of vertices or connectivity)
    - Elements must be presented in the same order for all motion 
samples (eg. you can't change the order in which polygons or vertices 
are listed).

For best efficiency, I think the following requirements should be met:
    1. There should be a way to query whether the geometry of an object 
has deformed within the current frame.  Many objects don't deform, and 
IMHO it's not "premature optimization" to flag this if possible.  
Naturally, you could simply indicate that all objects deform as a 
starting point.
    2. The render API should provide a guarantee of identical topology 
and identical order of elements if an object is iterated more than once 
within the current frame.

Anyway, enough for now.  I'll let you know if I have any other ideas. 
:-)  Again, it looks like great work so far.  I can't wait to see this 
running, since it will open up an enormous range of possibilities! :-)

Jonathan Merritt.

PS: Typo; GEOMETRY_PARTICAL_SYSTEM -> GEOMETRY_PARTICLE_SYSTEM