[Bf-committers] Renderman

dienben dienben_mail at yahoo.fr
Sat May 14 16:55:21 CEST 2005


Hi everyone.

Few months ago, i looked for people interested in working on a renderman 
exporter in python. I worked on it, but alone, so i stoped this project. 
But about one month ago, i met on the blenderclan new people and re 
worked on it.

Today, i ve got a very basic pool of functiuns, and some objects to 
manipulate and export data to the renderman interface.

I think that if we could  work together, we could manage to do this thing.

I don't know how to begin, but if you are interesed, send me an email 
(dienben_mail at yahoo.fr) and i will send the script.

I just want to help the community, so don't hesitate to make critics.

Dienben

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!!  :-)
>> --  
>
>




More information about the Bf-committers mailing list