I'm not sure what you mean about where the code is for 20 different renderers.I actually don't think that giving the Render API the functionality to make those decisions of renderer capabilities is going to contribute to code bloat. I don't really see what you think is going to contribute to such bloat. In fact, I believe it will have the result that exporters become far easier to write. Here's why.
<br><br>From a renderman standpoint, my exporter only needs to maintain a simple array of renderer names, and a set of fields per renderer that lists each capability and whether it's supported or not. Thus, when I select, say, Aqsis, the exporter knows what Aqsis supports.
<br><br>Then at render time, the Render API asks the exporter for the renderer's capabilities and reacts accordingly on each object.<br><br>Let's also consider the Serious Engine exporter. That particular exporter only recognizes mesh objects and bones only. So with the render API, we simply say that the exporter only supports mesh objects, and for authoring our exporter, we only have to worry about writing code that deals with the data it's provided and leave it at that.
<br><br>Also, the U3D exporter that I'm working on operates on the same principle. Mostly mesh data, with some limited primitive support. Again, I only need to register some capabilities and the render API gives me what I need.
<br><br>Using the other method...each exporter that's created that has to make its own decisions about object support winds up with a ream of code required to make those decisions. <br><br>Thus, Neqsus requires that for each object adapter, I make a decision somewhere in the code for whatever renderer I have supported.
<br><br>Same goes for Serious Sam and the U3D exporter (while not renderers, they do export the scene and the Render API can provide functionality for that).<br><br>While yes, doing it this way means a bit more code for the Render API...but in the long run it results in more efficient exporter authoring.
<br><br>For those reasons, I don't see how it encumbers the code unnecessarily. I think this approach enables exporter authors to be more efficient in their coding.<br><br>As far as a "generic renderman" lib goes...I don't think such a thing is neccessary. The exporter only needs to be aware of what each renderman renderer supports, and from there it specifies those capabilities to the render API, and voila', all renderers are supported. I personally envision Neqsus/BtoR remaining as the exporter interface, enabling me to simply add the required callbacks for the Render API to communicate with it.
<br><br>Bobby Parker<br>ShortWave<br><br><br><div><span class="gmail_quote">On 6/3/07, <b class="gmail_sendername">Robert Wenzlaff (AB8TD)</b> <<a href="mailto:rwenzlaff@soylent-green.com">rwenzlaff@soylent-green.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 Sunday 03 June 2007 20:10, Bobby Parker wrote:<br>> Actually it's not much different from your own idea. All we're really
<br>> talking about is where the black magic and voodoo happens. The general idea<br>> is to come up with a way for Blender to decide what to give the exporter in<br>> terms of data. Using Metaballs as an example, if the renderer capabilities
<br>> setting for a given renderer indicates that it can support that kind of<br>> data, then Blender simply provides it. Otherwise, Blender provides the<br>> converted mesh.<br><br>Yes, we are just talking about where the black magic occurs but do we want
<br>the "black magic" code for 20 different renderers (not all Renderman<br>compliant and possibly with features we haven't even thought of yet) in the 1<br>blender source tree, or in 20 different libs* that any particular user needs
<br>only 1 or 2 of, and only 1 is loaded at any time? There's a lot of<br>Me-Too-ism in software design and it tends to bloat software that is designed<br>monolithically.<br><br>The Generic Renderman lib could use all the discovery calls to determine how
<br>to best use a particular renderer making it _very_ generic. So in effect, it<br>might do 99% of what you want and support a vast majority of the renderers<br>out there. But it will also get out of the way for non-renderman exporters.
<br><br>If you are working on the RendererX code, you should only be working on the<br>RendererX code, with no chance of breaking the RendererY code (or Blender in<br>general).<br><br>External material editors are another area where we need work, but that really
<br>doesn't effect whether the magic code is in Blender or a loadable lib. It is<br>particularly important to have materials external to Blender as every<br>renderer will have different material specs. Perhaps a<br>
DrawMaterialEditor(), DrawRenderSetup(), etc. functions to popup a<br>customizable set of Blender controls for each lib? At that point the Blender<br>material becomes a quick preview of the material as it will be used for final
<br>render.<br><br>*Ideally, <a href="http://Blender.org">Blender.org</a> would only maintain one of these libs, the<br>GenericRenderman one, (maybe 2, since Yafray is currently supported<br>internally), with all others being maintained by the people who want that
<br>particular renderer. So the total number of lines of code we're supporting<br>is about the same.<br>--<br>*************************************************<br> What if it turned out that the only thing wrong<br> at Microsoft is that Bill just _really_ loves
<br> the sound of hard disks indexing?<br>*************************************************<br>Robert Wenzlaff <a href="mailto:rwenzlaff@soylent-green.com">rwenzlaff@soylent-green.com</a><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>