> Also IMHO, I think you have chosen The Right (TM) approach in allowing<br>> Blender to act as a database and have the render plugin pick-and-choose<br>> the data it needs. <br><br>Truth be told, that's what Blender does now.
<br><br>I personally disagree that it's the best approach.<br><br>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.
<br><br>Object Access by type: We'll need a method of accessing objects based on their datablock type, parent-child relationship, etc.. <br><br>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.
<br><br>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.<br><br>These are few ideas on what we might need.
<br><br>Bobby Parker<br>ShortWave<br><br>
<br><br>