[tuhopuu-devel] Dobby the DSO

Jonathan Merritt tuhopuu-devel@blender.org
Mon, 26 Jul 2004 13:35:45 +1000


Hi Everyone,

I have just committed a significant change to the RenderMan exporter.  
It now uses a RenderMan DSO (Dynamic Shared Object (?)), which I've 
called "Dobby" (because it has a lot in common with a house elf :-).  
This DSO currently handles parameters passed to shaders, but will 
eventually be responsible for most of the texturing code.  This 
signifies a split from the "classical" RenderMan approach, which is to 
use shaders written purely in the RenderMan shading language.  The use 
of a DSO allows the incorporation of native code into the shading process.

Currently, the situation is quite complicated.  The DSO needs to be 
compiled separately to Blender itself, as a shared library object.  It 
is then found by the renderer at run time and is loaded as dynamic 
code.  This is working for Aqsis (and the scons compile), but my 
experiments so far with Pixie have been fruitless. I think that there 
*is* binary compatability between all known RenderMan renderers as far 
as DSOs are concerned, but if necessary, the DSO can be compiled 
separately for each renderer, in the same way as the shaders themselves.

The exporter now creates a "parameter file" (*.dobby) for each material 
used in the scene.  This parameter file contains most shading parameters 
that are passed to the shader, and mostly replaces the default RenderMan 
parameter passing mechanism.  This is not a move I'm completely happy 
with, but I believe it's quite necessary if we are to have an 
"all-in-one" surface shader.  Dobby parameters are strongly typed as 
integer, float, triple (colors, points, vectors and normals), matrix 
(4x4) and string.  They are also grouped, so that batches of parameters 
can be identified / accessed by group name.

Broadly, my reasons for the shift to using this DSO are the following:

- We can now pass varying numbers of parameters to the shader.  This is 
particularly important for textures.  Instead of having to pass all 
possible parameters for all possible textures on all possible texture 
channels (which was required by the RenderMan shading language 
parameter-passing mechanism), we can now pass only those parameters that 
are actually required for any given texture type.

- Because of the use of C/C++ for the DSO, we can now re-use (albeit 
with a little difficulty) more of Blender's native shading methods.  For 
example, color ramps are now implemented using an almost direct copy of 
Blender's own color ramp code.  This will enable more precise emulation 
of other things like noise functions, etc.  In the future, with a push 
for greater modularity, it may be possible to have *identical* code for 
Blender's internal engine as for the DSO.  There are a lot of 
interdependencies to remove before that will be possible though.

- Blender uses many more globally-accessible parameters in shading than 
I originally anticipated.  The DSO emulates this behaviour by allowing 
the shader, at any point, to query any of the parameters from the 
parameter file.  Hence, we no longer have immense argument lists, with 
literally hundreds of arguments, being passed down to shading language 
functions, which is much neater.

Hopefully those who are *very* enthusiastic (Paul maybe? :-) can try 
this out as it currently stands and let me know what you think.

Thanks,

Jonathan Merritt.