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

Bobby Parker sh0rtwave at gmail.com
Wed Jun 6 17:30:29 CEST 2007


> 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.

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. So from a standpoint of using Blender as a scene database, here's
what I think we'll need for that.

Object Access by type: We'll need a method of accessing objects based on
their datablock type, parent-child relationship, etc..

Object Access by property: A useful idea would be a method of accessing
objects based on properties that are common to all objects. (Layer,
material, etc.). This has use especially when dealing with render layers,
layers that are lit by some lights, and not others, etc. My own personal
experience with layers in Blender is that it's a very difficult thing to
manage when exporting and dealing with lights that illuminate some layers
and not others.

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. There are two potential ways of thinking about it. We can
either keep the current method (by setting the current frame pointer to
<some frame> and having blender update the current scenegraph to that frame)
or we can add a method where we can access frame data per object by using a
mechanism like some_object.getDataForFrame( 2.5). I think for this scenario
we probably need both, since for motion blur situations, it can be useful to
work in a given frame, but then allow an individual object to back up or
move forward a few subframes.

These are few ideas on what we might need.

Bobby Parker
ShortWave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070606/58c3d22e/attachment-0001.htm 


More information about the Bf-committers mailing list