[Bf-committers] Renderman
Jonathan Merritt
j.merritt at pgrad.unimelb.edu.au
Fri Nov 4 02:12:40 CET 2005
Hi Everyone,
Some of my core notes on this topic that have accrued over time... :-)
1. Before getting started, be clear on what the goals of "the exporter"
are. For example, typically, you'd want to use RenderMan instead of
(say) the internal renderer for:
- the RenderMan shading engine (custom shaders, micropolygon
displacement, etc.)
- greater control over your render pipeline (eg: custom render
passes for AO, etc.)
- greater control over render parameters (shading rate, sampling, etc.)
- camera effects (motion blur, DOF, etc.)
In short, most of the RenderMan advantages are related to its
versatility. See Paul's presentation from the Blender conference:
http://www.blender.org/cms/Paul_Gregory.689.0.html
2. The requirements of a RenderMan exporter are different (in many ways
a *superset*) of the requirements of Yafray.
- RenderMan is best given access to underlying primitives to be
rendered, NOT the VlakRen ("render faces") that Yafray uses. I CAN'T
emphasise that enough!!!!!! The reason is that for primitives like
subdiv surfaces or NURBS, a RenderMan renderer will, overall, be able to
make better decisions about the level-of-detail to use in dicing out
these primitives than Blender (or the user) can.
- For motion blur, there are two types: transformation motion blur
and object motion blur. Transformation motion blur is relatively
simple, but object motion blur (in which the individual vertices of the
object can move) demands consistent topology within all motion
sub-frames. There needs to be a way to guarantee consistent sub-frame
topology *within* Blender (anything done to check it on the exporter
side can only ever be a rough and nasty kludge).
- For the shading engine, you need to consider more complex cases
from the outset, especially if you are trying to "simulate" Blender's
internal shading engine. Consider the case of multiple applied
textures, and figure out a way of handling the data that needs to be
made available from the start. In summary, although writing a one-off
shader to simulate literally any one Blender material is uber-simple,
writing a generic shader to simulate all Blender materials is
unbelievably difficult. I'd recommend not trying to simulate Blender's
internal shaders (except for lights and maybe a very simple surface
shader), but instead allow custom shaders to be applied. For custom
shaders, though, you need to consider how surface parameters
(vertex/varying colors, uv coords, etc.) are going to be named and passed.
3. Methodology. Two main options have come up over time:
- Expand BPython to make it better suited for render export (eg: add
things to query consistency of mesh topology, etc.) and write a Python
exporter. In this case, a "one-click" exporter should be written on top
of a well thought-out base API (written in Python). The base API could
then be used by anyone needing more advanced features (custom render
passes, etc.). The lack of "underlying infrastructure" is my main
criticism of the existing Python exporters. Also, use something like cgkit:
http://cgkit.sourceforge.net/
to make the RenderMan API calls from Python. DON'T DON'T DON'T
hard-code the API calls as strings to generate a RIB file! Tempting as
this may be, it'll bite you hard one day when you have some enormous
file that you want to encode as a binary RIB, or when you want to add
debug hooks to the API calls themselves.
- Write a renderer exporter API (ie: not just for RenderMan, but for
any external renderer). In this case, the API needs to be well
thought-out. Simply providing (for example) an API that gives Yafray
everything it currently requires would *NOT* solve any of the important
problems for a RenderMan exporter. Instead, any API should be designed
as very generic from the ground up.
Whew! There's loads of stuff I haven't mentioned. The above just
outlines the major problems. Naturally, a large part of the problem of
exporting to a RenderMan renderer is very easy and poses no problems at
all. :-)
Jonathan Merritt.
More information about the Bf-committers
mailing list