[Bf-committers] Render API: Framework and Scene Break-Down

Bobby Parker sh0rtwave at gmail.com
Thu Jun 7 23:03:27 CEST 2007


> The idea was that any Renderman compliant renderer could use it.  If

A fine goal! Point of fact, any renderman renderer can in general
already mostly use output intended for any other renderman renderer
with a little tweaking.

> If someone publishes a Renderman compliant render engine (Stubby3D)
> out of the blue the day after we release the first exporter, it
> should just work using the generic RM exporter.   It may not take
> advantage of any Stubby special features, but it at least should work.

I think  that if the interface is done correctly, that this scenario
actually doesn't exist as a possibility. The Stubby team would simply
add their attributes & options list to the exporter, and the problem
is thus solved. Granted, Joe, who's running an older version of
Neqsus/BtoR can easily tweak the resulting RIB to get his scene to
render in Stubby.

> If you say "the Neqsus/BtoR exporter can handle Stubby's limited set
> of features via the register feature function", then I would claim
> that _it is_ the generic RM exporter.  Generic doesn't mean "plain"
> or "low feature" it means "nameless" - ie; not tied to one specific renderer.

Agreed. That's why Neqsus/BtoR supports the Renderman specification to
the highest degree possible. This ensures that it can support ALL
renderers available already. It's possible to render it a "generic
exporter" by simply specifying a renderer that has no extended
capabilities beyond the spec, but again, there wouldn't be much
facility for that, since it's the special features of the given
renderers that make them attractive for one task or another.


Bobby Parker
ShortWave


More information about the Bf-committers mailing list