It's actually workable either way, if designed correctly. All you're talking about here is a series of callbacks on both sides. In truth, to *fully* support Renderman, it's going to need a little bit of both. <br>
<br>As an example for that, to do REAL motion blur in renderman, i need to be able to access "subframe" positioning data for each object affected by motion blur. <br><br>Point of fact, using Blender as a database for scene information is what I do NOW. That being said, it falls to my exporter to have to make multiple passes through the scene database to build up an exportable scene. Here's what I currently do:
<br><br>I pull scene global setup information from both my own render settings and Blender's render context. Then I have to determine starting and ending frame for animation, and my exporter has to then increment the frame pointer to the starting frame.
<br><br>After that, I fetch lighting information. Currently, I have to fetch ALL OBJECTS IN THE SCENE to get the lights and then I have to filter them out to build the lighting list.<br><br>After that I have to iterate object information without the lights. Now here's where it gets interesting. My exporter has to make decisions based on the objects received and decide what to do with them. To handle this, I created object adapters, that each have the intelligence to export the data it's given for that particular type.
<br><br>This process, while it works acceptably well, is far from ideal. I export archives for each object in the scene, but I would like to be able to test an object to see if it has moved or not, to reduce the amount of data output that I'm dealing with. I would also like to be able to not have to worry about iterating frames myself. Based on my own practical experience with it, having Blender handle frame iteration and object decisions in the Render API is the superior method of dealing with it, since it makes the authoring of exporters a far more accessible task than it is currently. Relying upon the exporter to iterate frames and objects complicates the export process needlessly, in my opinion.
<br><br>As to how Blender would control the export process...it would control in much the same way it handles Yafray/Internal renderer rendering now. Again, all that's needed is a series of callbacks into both the exporter and the Render API.
<br><br>Bobby Parker<br>ShortWave<br><br><br><br><div><span class="gmail_quote">On 6/3/07, <b class="gmail_sendername">Aaron Moore</b> <<a href="mailto:two.a.ron@gmail.com">two.a.ron@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/3/07, Bobby Parker <<a href="mailto:sh0rtwave@gmail.com">sh0rtwave@gmail.com</a>> wrote:<br>> I think the crux of the issue is that it seems that there's less interest in<br>> Blender performing as a "database" for an exporter that does it's own
<br>> thing(ala the way XSI does it), and more interest in allowing Blender's<br>> Render API to control the export process.<br><br>I just wanted to comment that this is not at all my opinion. I see<br>blender as a database that a renderer needs to query. Setting optional
<br>flags to allow renderers to "opt-out" for support of given features is<br>an exception to the rule. This is because it is the renderer that<br>changes, not blender. Blender doesn't know what a variable exporter
<br>needs, it just knows what it has. But an exporter does know what it's<br>representative renderer needs. Therefore I suggest let each player in<br>this relationship use what they know. Let blender provide flexible<br>
access to the data, and let the exporter ask the questions.<br><br>That's my opinion. In fact, that's the only way that I can make sense<br>of the problem... I still haven't managed to figure out how a system<br>
based on blender controlling the export would even work...<br><br>Aaron<br>_______________________________________________<br>Bf-committers mailing list<br><a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org
</a><br><a href="http://lists.blender.org/mailman/listinfo/bf-committers">http://lists.blender.org/mailman/listinfo/bf-committers</a><br></blockquote></div><br>