I think the crux of the issue is that it seems that there's less interest in Blender performing as a "database" for an exporter that does it's own thing(ala the way XSI does it), and more interest in allowing Blender's Render API to control the export process.
<br><br>I'm still not sure a "translator lib" is the smartest approach, since we'll need much more than that for effective support of things like Crystal Space, Renderman, MentalRay, etc...Renderman and Gelato, especially, require extra interface elements (GUI that is) to support things like custom materials, attributes, all the extended stuff that Renderman is capapble (see the Neqsus/BtoR interface here
<a href="http://wiki.aqsis.org/guide/btor/">http://wiki.aqsis.org/guide/btor/</a> ). While some support will be provided for blender's materials, truth be told, the more advanced users will want the kind of functionality that Neqsus/BtoR offers now for handling materials/shaders, and to that end, I see Neqsus/BtoR having great relevance as the exporter interface. A "translator lib" approach might work for other renderers (like for instance Yafray), but I don't see it being practical for something like renderman.
<br><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This doesn't seem very future-proof. Renderers will add new features over<br>
time and Blender will add more types of objects. These flags eventually get<br>obsolete. You can point to the renderman spec anad claim stability, but<br>ideally we should be ready for the next big spec, and at least able to handle
<br>a renderer with a (possibly poorly engineered) custom interface.</blockquote><div><br>Actually it's not much different from your own idea. All we're really talking about is where the black magic and voodoo happens. The general idea is to come up with a way for Blender to decide what to give the exporter in terms of data. Using Metaballs as an example, if the renderer capabilities setting for a given renderer indicates that it can support that kind of data, then Blender simply provides it. Otherwise, Blender provides the converted mesh.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For example, if rendering a sphere as a mathematically perfect surface is CPU<br>
costly, then the lib could choose to render distant spheres as meshes by<br>ignoring them during GetSpheres() and not allowing them to be flagged as<br>rendered.</blockquote><div><br>It normally works in the opposite direction. Procedural objects such as a sphere primitive is easier for the renderer to generate than a mesh would be.
<br></div><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Which is why the communications language should be as close to the Renderman
<br>spec as possible. Most translator libs would need to be nothing more than<br>very simple wrappers. But if we are flexible in the base method, the lib can<br>translate that to anything.<br><br></blockquote></div>I confess to a bit of confusion here....it sounds like you're expecting Blender to output a kind of limited RIB code? I think that would confuse the issue a bit if that's the case. The Render API should be less of a language and more of just an interface and expected set of callbacks for both exporters and Blender to communicate back and forth. At least that's how I see it.
<br><br>Bobby Parker<br>ShortWave<br><br><br><br>