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