[Bf-committers] RenderMan export

[Jonathan Merritt]

Hi Everyone,

Following recent queries, I though I would provide a summary of "what
happened to the RenderMan exporter in Tuhopuu 2".

Paul Gregory began work on this exporter, using the original Yafray
exporter as a template.  I started work on the project a couple of
months after Paul.

All of the basic elements of RenderMan export were very easy to
implement.  We had a system which could do as much as any of the current
Python-based exporters and more.  The main difficulties lay in the more
advanced features of the exporter; particularly automatic shadow map
generation, motion blur and shading.  (Note that while many of the
Python efforts have not addressed these features, they are really
absolute requirements for any reasonable RenderMan exporter.)

We had automatic shadow map generation working well by the end of
Tuhopuu2, so I won't go into that.


=== Motion Blur ===

In RenderMan, motion blur is done by providing "snapshots" of the
blurred parameters.  The renderer then automatically blurs using the
snapshots as keys.  Motion blur comes in two varieties: transformation
motion blur and deformation motion blur.  In transformation blur, the
object being blurred is rigid between the key frames (ie: only its
transformation is "blurred"), and in deformation blur, the object can
deform between the key frames.

In order to implement motion blur, it was necessary to invoke the
exporter code at least twice, incrementing Blender's internal time
between the two invocations.  The exporter was then required to do some
clever tricks to collect all of the required information from the
keyframes, and associate that information with the correct meshes (ie:
*MUCH* more work than the Yafray exporter!! :-).  It also relied on the
assumption of "coherence", in other words: that render faces (VlakRen)
would be presented to the exporter in the same order each time.  This
worked most of the time, but I could of course find cases that broke it.

As far as I can tell, deformation motion blur presents a logical impasse
for the use of VlakRen for export: it simply *can't* be done without
kludgey assumptions!  What is required is access to the underlying mesh
data in Blender, and a way to enforce coherence for a particular mesh if
it is to be deformation-blurred.  The requirement for this extra
information means that VlakRen are not an "attractive" short-cut for
RenderMan in the same way as they are for Yafray.  I *definitely*
wouldn't recommend using VlakRen again! :-)


=== Shading ===

We originally took the approach of developing a single surface shader
and a single light source shader.  The idea was that we could pass all
of the required parameters to the shaders to have them behave as any
generic Blender material or light.  However, unfortunately the number of
parameters that must be passed to the shader is enormous, because
RenderMan shaders cannot have optional parameters (actually the most
recent release of PRMan from Pixar does allow optional parameters, but I
don't know of any other RenderMan implementations that do).

Just think, for example, that for each texture channel, all possible
parameters from all possible texture types had to be passed down to the
shader!  In addition to this large number of parameters at the top
level, each smaller level of the shader required a large number of
parameters as well.  For example, consider color ramps and all of their
possible parameters, which in RenderMan shaders must be incorporated
into the innermost illuminance loop of the shader.

To overcome the problem of massive numbers of shader parameters (and
massive numbers of parameters going to each shader function), I came up
with a system called "Dobby", which saved the texture parameters to a
text file.  The RenderMan shader was then passed the name of the file,
and it could (via a DSO) arbitrarily query the presence and value of any
of the parameters.  It also allowed many parts of the shading (for
example, pattern generation) to be done in C/C++, thereby allowing the
same, identical code to be used in both the RenderMan shaders and the
original Blender pattern generation.

The Dobby system was about 80% complete (it could read and write
parameters and do some other stuff) when Tuhopuu2 was abandoned.


=== Future Development ===

I would recommend using Python for future RenderMan export.  Despite all
of my efforts on the Tuhopuu2 exporter, my own use of the exporter has
been very minimal.  Instead, I have developed my own Python scripts that
have been used to produce real content.  I have rendered several
animations this way that have been used in the BVSc degree here in
Veterinary Science.

However, I would advise against the use of a "packaged" exporter like
BlenderMan, without a published API that allows elements of the exporter
to be used independently.  The reason being that a "packaged" exporter
misses much of the point of wanting to use RenderMan.  Depending on the
particular project, you might want to set up customized shadow map
passes, ambient occlusion baking passes, incorporate procedural elements
into the render, merge RenderMan elements from Blender with those
created by some 3rd party tool, etc.  I've done all of these things, so
they are realistic requirements!

What I would like to see (and have started working on myself), are a set
of RenderMan-specific Python classes that can be instantiated from the
existing BPy classes.  These wrappers can then provide utilities that
exporters will need.  For example, a RenderMan Mesh class would provide
utilities to export the mesh, export a UV-coordinate mesh for baking
purposes, etc.  A RenderMan Light class would provide utilities for
setting up a camera with the same transformation as the light, 
inserting the light into a RenderMan scene, etc.  A "packaged" exporter
could then be built up using these classes, but the more important
contribution would be a nice set of independent classes that can be used
to build a custom RenderMan solution for a given project.

I would also add that the use of a Python mapping for the RenderMan API
is something I would consider essential for this kind of work.  cgkit (
http://cgkit.sourceforge.net ) provides just such a mapping.  Trying to
do without a mapping for the API and using things like print statements
or direct file access is going to bite you one day when you want binary
RIB export!! :-)

-- 
Jonathan Merritt BE(Mech)/BSc
PhD Student - Equine Biomechanics
The University of Melbourne
Veterinary Clinical Centre, Werribee