[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