[Bf-committers] Re: RenderMan support

Jonathan Merritt j.merritt at pgrad.unimelb.edu.au
Sat Oct 23 07:56:18 CEST 2004


Hello Rednelb,

Paul Gregory and myself spent several concerted weeks trying to 
incorporate RenderMan export into Tuhopuu.  This project is still a 
work-in-progress.  Currently, I am waiting for the re-spawning of 
Tuhopuu3 from the bf-blender code base before proceeding with further 
work.  I am not sure about Paul's plans.

There are several major challenges posed for RenderMan export.  I can 
provide a brief description of two of these...


=== Shading ===

I have found it is rudimentary for anyone with reasonable experience 
with the RenderMan Shading Language to duplicate any *particular* 
Blender material in a matter of minutes.  However, duplicating the 
*general* Blender shading engine is much more of a challenge.  Our first 
approach involved a general shader, which was written in the RenderMan 
Shading Language, and was expected (in theory) to handle all possible 
materials.  (A similar general shader was created for lights.)  We found 
that this general shader had an enormous list of possible parameters, 
and many of these parameters were required broadly throughout the 
shader, making it difficult to sensibly split it up into smaller 
functional parts.  If you doubt this claim of non-modularity, try to 
implement Blender's "ramps" in RenderMan SL.

To overcome the problems of:
    - broad accessing of parameters throughout the shader
    - parameters which would be optional some of the time (eg: for 
different texture types)
    - calculations which take place in the innermost shading loops (eg: 
"ramps")
I started work on a shading DSO, written in C/C++, which would read 
parameters from a text file and use that information to calculate the 
color of the surface.  This approach, in turn, has its own unique 
problems, but is the current method I intend to proceed with.

Yet another approach, which is used by some exporters (eg: MaxMan), is 
to generate shaders "on-the-fly".  This involves the exporter actually 
writing (or tacking together) shader code which is then compiled by the 
exporter prior to rendering.  I haven't yet looked in detail at this 
method, but it may well prove preferable.

However, in the wider context, I have begun to question the wisdom of 
attempting to duplicate the entire Blender shading engine as a primary 
goal of a RenderMan exporter for Blender.  If the entire engine is 
duplicated, it makes RenderMan much more accessible to a typical Blender 
user (a Good Thing (TM)), but is probably the single largest hurdle in 
actually producing good RenderMan export in the first place (a Bad Thing 
(TM)).  Furthermore, an experienced real-world TD who might want to use 
Blender for something practical would probably have little use for the 
simulated Blender shading engine anyway...  For my own uses of RenderMan 
export, a duplication of the internal shading engine is not important.

I would like to see us focus on exporting important shading parameters 
(texture coordinates, etc), and allowing for the attachment of *general* 
RenderMan shaders to Blender objects first.  While I think that the 
simulation of the entire Blender shading engine is a very important 
goal, I don't think it should in the list of "show-stopping" objectives 
for the exporter (ie: I would be happy to see an exporter released 
without this functionality, provided that general shaders can be 
attached to objects).  Perhaps a set of rudimentary shaders that only 
partially simulate Blender's own engine would be sufficient initially?  
What do people think?


=== Motion Blur / DOF ===

The RenderMan exporter was initially created by copying much of the 
functionality of the Yafray exporter.  The Yafray exporter uses the 
"render faces" (VlakRen) created by Blender itself during rendering.  
This approach has several RenderMan-related problems.  The primary 
problem is that Blender only makes available information from a *single* 
frame using this method.  To allow for RenderMan motion blur, which 
requires several sub-frames worth of information to be exported for each 
frame of the animation, I implemented a relatively ugly hack to capture 
these extra sub-frames.  It is based upon Blender's own motion blur 
method, and basically exports several frames in series, which are then 
re-combined by the exporter.  It's very non-modular (with tight 
dependency upon Blender's own rendering loop) and likely to be error-prone.

I would much prefer to see an exporter which can access all scene 
information at all possible times, so it can then extract the 
information it requires without relying on a particular sequence from 
Blender's rendering engine.  I think that will be particularly important 
for exporting non-mesh objects (eg: parametric patch surfaces), which is 
something we haven't even looked at yet.  However, this approach would 
require substantial neatening-up (or maybe just documentation?) of the 
code required to set the global time to a different value in Blender.  
It also opens up a whole new set of problems concerning things like 
lattices, armatures, etc., whose effect on a mesh must obviously be 
taken into account.  Maybe Ton can provide some guidance in these issues?

The Tuhopuu depth-of-field (DOF) implementation required modification of 
Blender's camera to incorporate focal length, focal distance, and f-stop 
values.  I just chucked these straight into Tuhopuu (with full GUI 
support, IPO support, etc), and the result is a working implementation.  
However, the visual representation of these parameters will need to be 
thoroughly debated prior to their incorporation into the main Blender tree.


Anyway, I hope that more developers will become interested in RenderMan 
export following the spawning of Tuhopuu3.  I agree that it is an 
important goal, and it would be very useful to me personally in my use 
of Blender.

Jonathan Merritt.


>>>>> Hello Ton Roosendaal,
>>>>> I can imagine you are very busy and receive numerous similar  
>>>>> requests  but in spite of that I would like you to ask for a few  
>>>>> moments because  I think you are the most appropriate recipient.
>>>>>
>>>>> Frankly, I do believe that Blender tight integration with 
>>>>> RenderMan  is  a very good thing. This document is structured as 
>>>>> follows: an  attempt  to explain why, current situation, a 
>>>>> proposal and  conclusion.
>>>>



More information about the Bf-committers mailing list