[Bf-committers] Render API: Framework and Scene Break-Down

[Jonathan Merritt]

Bobby Parker wrote:
> > Also IMHO, I think you have chosen The Right (TM) approach in allowing
> > Blender to act as a database and have the render plugin pick-and-choose
> > the data it needs.
>
> Truth be told, that's what Blender does now.
>
> I personally disagree that it's the best approach.

Well, aside from the ability to extend the "pull" system and turn it 
into a "push" system (which would be clearly be difficult and 
resource-hungry to do in reverse), I can see some specific RenderMan 
advantages to the pull approach.  One that comes to mind is the 
generation of specialized render passes.  In the most basic of 
exporters, you might want the following:
    - Shadow map generation
    - Beauty pass
But as you've already pointed out, RenderMan users will likely want 
greater control.  Take this project for example:
    
http://www.aqsis.org/xoops/modules/xcgal/displayimage.php?pid=196&pos=-196
(It's my equine distal forelimb anatomy model; it was shown at Paul 
Gregory's RenderMan session of the Blender conference a few years ago.  
It has also been very popular among local vet students during their 
equine rotations in 3rd and 4th years...)
I used the following passes:
    - Ambient Occlusion rendering of the static model (just once)
    - Shadow map generation (just once)
    - Diffuse pass (each frame)
    - Specular pass (each frame)
It's not 100% clear how customized passes like that (which use 
user-specified subsets of the scene!) could be built into the exporters 
that have been described so far, but it seems to me that it would be 
much easier to do by treating the Blender scene as a database than by 
having a push model where the exporter has to take everything in one go 
and *then* decide what to do with it.

Imagine for a second a GUI interface for an exporter (maybe written in 
wxWindows or whatever) that is launched when the export is initiated.  
The GUI could then present the user with a view onto the Blender scene, 
and allow them to mold specific rendering passes as they see fit.  
Personally, I wouldn't have much use for a "generic" RenderMan exporter, 
but I do have use for something that allows me more control.  (Hence my 
Python suggestion.)

> In any event, at implementation-level, doing it this way introduces 
> some requirements to the "Data access" portion of the API. Currently, 
> via the Python interface, there's no type-specific data retrieval 
> method. I.e. if I wanted to retrieve all lamp objects, I actually have 
> to return everything and iterate the list to type-check each object in 
> turn to see if it's a lamp or not.

Yes, I see this as a shortcoming of the current Python API rather than 
as a fundamental limitation.  I think Campbell Barton's recent push 
toward BPy may help here.

I think it's important for Aaron to go ahead with what he sees as the 
best approach right now.  He's the one who has to do the work, and those 
of us who've used the Blender->RenderMan route in the past may not have 
usage scenarios that match very well with the massive user base that his 
exporter API will open up (ahhhh, the great unwashed masses!  what 
terrific bug-hunters they shall be! :-).  I'm still using my own 
customized RenderMan export via Python for various projects, and I'm 
sure it will remain the easiest way for me to do things for some time 
into the future.  We need more users first, completing real-world 
projects, and then it will make more sense to compare notes about the 
right way to do things.

> Frame Access: From an exporter standpoint (And *specifically* for 
> Renderman support), a float-based frame access method becomes 
> neccessary. The current integer-based method doesn't hold up well for 
> situations with motion blur in other renderers.

I was wondering about this though.  I don't have many contacts out in 
the "real world" of RenderMan users.  Do people *really* use more than 
two transformations per RiMotion block?  Is it common in production?  I 
just remember building a particle system many years ago where I went to 
great pains to allow an arbitrary number of transformations per motion 
block (if Nicholas Yue is reading this: yes, partsys died a long time 
ago!), and I was terribly disappointed that people couldn't see the 
difference in any of my animations. :-/

Jonathan Merritt.