[Bf-committers] RenderMan export

[Ton Roosendaal]

Hi Jonathan,

Thanks for the extensive report... no time for it now, but I'd be glad  
to assist with feedback on it later. Probably after release though. :)

-Ton-

On 13 May, 2005, at 7:31, Jonathan Merritt wrote:

> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org