To stake a little ground here, the Renderman exporter is already covered with the Neqsus/BtoR project, which is officially a part of the Aqsis project, and incidentally, the project I'm developing. <egregious horn blowing>It's also head, shoulders, and upper
torso above any other Renderman support project to date, and continues
to grow.</egregious horn blowing> I've been in communication with 2 major studios and multiple smaller studios regarding it, and I'm working with them to figure out what such studios would need/want from Blender to make it more attractive for them.
The feature list I have in store is pretty robust...and it includes things that Blender currently cannot handle. Blender has some growing to do in that regard.<br><span class="gmail_quote"></span> <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;">
That&#39;s what I mean about making the Generic Renderman lib very generic.&nbsp;&nbsp;It
<br>would do most of what you want - it could be set up to do your query and<br>decide method and thus support Aqsis, Serious, U3D, etc.).&nbsp;&nbsp;But you can&#39;t<br>assume that U3D will never extend or stray from the spec, and that Serious
<br>won&#39;t extend or stray in a different, non-compatible way and thus each<br>require a &quot;custom Renderman&quot; exporter to use all their features.&nbsp;&nbsp;That&#39;s all<br>I meant by &quot;Generic&quot;, a starting position based on the common spec.
</blockquote><div><br>Again, not a matter of great concern. I&#39;ve already implemented support for the vast majority of available renderers, and customizing to a huge degree isn&#39;t that big a deal when it gets down to it. I suggest you have a look at the Renderman spec and check out the mechanisms available for renderer customization. BTW, Serious and U3D aren&#39;t renderman compliant renderers, they are file formats. 
<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;">Let&#39;s be really optimistic and assume Blender will outlive the Renderman spec.
<br>Trying to come up with a universal solution _inside_ blender means some day<br>we will have to fit a square peg in our round hole. So let Blender provide<br>the wood and let the exporter drill the holes in whatever shape it wants.
</blockquote><div><br>Unlikely. The Renderman spec allows for the implementation of incredibly flexible scene graphs and allows extreme control over things. It&#39;s been nearly 20 years in development, to solve all of these rendering problems, and I don&#39;t think it&#39;s going anywhere. And I disagree with you about the square peg/round hole thing. A well-designed API should NOT limit what you can do in the long run. Consider the Autocad LISP/DXF API. Insanely powerful, and it&#39;s been around for a long time.
It&#39;s entirely possible that Renderman will outlive Blender. At any rate, Blender has a lot of catching up to do before it can hope to cause the Renderman API any kind of stress.<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;">
Blender should just provide the data requested (with the loadable exporter<br>
controlling the requests).&nbsp;&nbsp;That is the only thing design-wise we are in<br>control of.&nbsp;&nbsp;The makers of Aqsis don&#39;t really care what our API can or can&#39;t<br>do (yet).</blockquote><br></div>Well that&#39;s kind of the point. We&#39;re just adding the extra added benefit that blender provides the data according to what&#39;s specified by renderer capabilities.
<br><br>Bobby Parker<br>ShortWave<br>