[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