[Bf-committers] Render API Design

[Jonathan Merritt]

Hi Aaron,

Aaron Moore wrote:
> The plan is to study these documents and study convertblender.c and
> try to put together a composite design which maximizes the ability to
> use existing designs and code. Making a design that looks very much
> like one of the existing 3d packages is a good idea because existing
> exporter code could be ported relatively easily in that case.
>   

Congratulations on taking on this project.  It's fantastic to see some 
progress being made.  I think you have a good summary of the existing 
documents, and it's also excellent that you are inspecting existing 
solutions.

I just have a small comment about starting with convertblender.c.  My 
comments come from the background of working on the RenderMan / Aqsis 
exporter in the Tuhopuu tree, which Paul Gregory (Aqsis project) 
originally started.  I have CC'd this email to Paul in case he has any 
additional comments.

My conclusion after working with the existing Yafray converter was that 
it used an approach which was far too "low level" to be entirely 
appropriate for RenderMan.  It was clear that Yafray benefited from the 
pre-conversion of the Blender scene into VlakRen ("Render Faces"), which 
are the low-level polygon form that the Blender renderer uses as input.  
However, due to the nature of the RenderMan interface, we needed access 
to much higher-level data.  Adding in this higher-level stuff to 
convertblender.c was a terribly ugly hack at best.

My comments may not make much sense without a few examples, so here goes:

1. Subdivision surfaces.  RenderMan renderers have their own schemes for 
dividing subdiv surfaces.  They typically do this in such a way that 
subdiv surfaces are guaranteed to be *locally* subdivided to a level 
which is appropriate for their on-screen size.  So, for example, if the 
on-screen (/ "screen space") size of a subdiv surface increases, the 
RenderMan renderer will increase the subdivision level accordingly.  
This can lead to great improvements in rendering efficiency over just 
using a single subdivision level, as Blender does.  So, having Blender 
pre-calculate a single subdivision surface level (and outputting this as 
VlakRen) is really a terrible solution from the RenderMan perspective.  
What the RenderMan renderer needs is the original mesh data; it does far 
better working with the original Blender mesh.

2. Curves.  Once again, RenderMan renderers *can* handle curves very 
efficiently.  The performance hit of having these exported as polygons 
is truly astronomical, even with a fairly naiive RiCurves implementation 
like the one I wrote for Aqsis.

3. NURBS.  Basically the same as the above two examples.

The "take-home message" is that much of the efficiency of a RenderMan 
renderer will be lost if only low-level, pre-diced polygon 
representations of geometry are passed down the pipeline.  RenderMan 
renderers, in general, will do a much better job if you give them the 
highest possible level representation that is available in the RiSpec.

Jonathan Merritt.


!DSPAM:18,465a626336376195519088!