[Bf-committers] Render API Design
sh0rtwave at gmail.com
Mon Jun 4 16:25:01 CEST 2007
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
That's what I mean about making the Generic Renderman lib very generic. It
> would do most of what you want - it could be set up to do your query and
> decide method and thus support Aqsis, Serious, U3D, etc.). But you can't
> assume that U3D will never extend or stray from the spec, and that Serious
> won't extend or stray in a different, non-compatible way and thus each
> require a "custom Renderman" exporter to use all their features. That's
> I meant by "Generic", a starting position based on the common spec.
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.
Let's be really optimistic and assume Blender will outlive the Renderman
> Trying to come up with a universal solution _inside_ blender means some
> we will have to fit a square peg in our round hole. So let Blender provide
> the wood and let the exporter drill the holes in whatever shape it wants.
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.
Blender should just provide the data requested (with the loadable exporter
> controlling the requests). That is the only thing design-wise we are in
> control of. The makers of Aqsis don't really care what our API can or
> do (yet).
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-committers