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's what I mean about making the Generic Renderman lib very generic. 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.). But you can't<br>assume that U3D will never extend or stray from the spec, and that Serious
<br>won't extend or stray in a different, non-compatible way and thus each<br>require a "custom Renderman" exporter to use all their features. That's all<br>I meant by "Generic", a starting position based on the common spec.
</blockquote><div><br>Again, not a matter of great concern. I've already implemented support for the vast majority of available renderers, and customizing to a huge degree isn'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'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'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's been nearly 20 years in development, to solve all of these rendering problems, and I don't think it'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's been around for a long time.
It'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). That is the only thing design-wise we are in<br>control of. The makers of Aqsis don't really care what our API can or can't<br>do (yet).</blockquote><br></div>Well that's kind of the point. We're just adding the extra added benefit that blender provides the data according to what's specified by renderer capabilities.