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

[Bobby Parker]

> Then I think we're just arguing over the word "generic".
>
> If we can make the BtoR export just work with any off the shelf RM
> engine, then it meets my definition of a "generic" exporter.

Well, maybe. A lot of "generic" renderman exporters deal only with
exporting a single, or group of objects to be included in another
scene somewhere via RiReadArchive calls. For instance, when exporting
from Rhino3d via the built-in exporter, you end up with a .RIB file
that can be used in conjunction with another scene. The authoritative
Renderman exporter for Rhino is RhinoMan, which provides features very
similar to Neqsus, and in fact it uses much the same mechanism for
renderer-specific support.

Bottom line is that "generic exporter" means to me that it's basic
object-level support, not full scene.

So now that we agree on terminology...

> This is exactly the sort of things I think we should  try to
> avoid.  Dependance on others to add stuff to the exporter that the
> Blender Foundation has agreed to support, and requiring the user to
> do "tweaking" to get things to work if they don't do it.

Yes! This is yet another reason why I wrote Neqsus in the first place.
It was easily possible to use the Blenderman system to create RIB that
was tweakable. I'm simply saying that any renderman compliant renderer
can render most RIB.

> Not overly familiar with RIB, what does this tweaking involve?  Can
> it be done on-the-fly for each of 2000 frames you are rendering in an
> anim?  Ideally, while file output should be an option, pressing the
> render/anim button in Blender should be all that's needed.  It should
> send the RIB info to the engine (via a pipe?) and retrieve the
> rendered pixels for display/saving, and it should do this as
> seamlessly as possible.

The "tweaking" generally applies to scene-level options, and that's
actually not that big a deal, even for, as you say, a 2000-frame
animation. The automation tools to manipulate RIB exist already, and
are very robust. Renderman's design is so flexible that it allows many
methods of dealing with data.

For instance:

A given animation of 2000 frames can be created with a car that simply
moves around. All you need is one archive file (the car), and a
lighting setup that can be loaded into the scene via RiReadArchive.
Thus, all that needs to be done for the animation itself...is that
2000 frames of RiReadArchive and RiTransforms. Note that the car could
be easily replaced with another object. This is just one example.

As far as pushing data out to a file, that's a subject up for much
discussion. A typical scene rendered from Neqsus will create a single
file per object (or group of objects, depending) if the global config
is set to do so.  For static objects, I export the object once, and
simply include it. There's a lot of reasons for doing this. For
example, by keeping track of objects that have been modified or not
modified since last render, this "object caching" method allows for
faster and more optimized exporting. Also, for optimization purposes,
instead of pushing the same object out per frame, Renderman allows a
method of caching static objects to a single archive, reducing overall
output size for large scenes/animations. That can also be used for
animated objects that aren't being deformed, simply transformed. To
use your example of a 2000-frame scene, that means a single object
archive for a static or non-deformed object, simply gets reused 2000
times, rather than *exported* 2000 times.

> Maybe there can be an external DB of renderer features for
> convenience/fine tuning measure (It's a nice place to put 'the Stubby
> interface says "blobbies" work, but they don't really' kind of info -
> also users could customize what gets rendered as internal geometry
> and what Blender controls as VlakRen*), but a "generic" exporter
> ought to be able to discover them on it's own, or use a least common
> denominator subset, so that the _very first time_ someone tries
> Stubby3D, it just works.

This is why I was suggesting that the support for Stubby3D actually be
a feature of Neqsus, rather than a feature of Blender. And truth be
told, again, the "generic" features of Renderman will make it so that
Stubby3D just works in any event...even tho it won't be an ideal
output.

> AND, if it doesn't work, we should be able to say "Ah ha!   Of course
> it won't work, you silly Stubby team. Here's where you strayed from
> the RM spec.  Fix your interface or _you_ explain to _your_ users why
> they need to get busy on a custom exporter." (Maybe, a little more
> politely . . . Maybe.)

Hrm, well the ultimate goal for Neqsus is that any USER of Neqsus will
be able to add the neccessary attributes and options (through a nice
interface of course) to support ANY compliant renderer. The structure
of the Renderman API allows this extra-added benefit.

> If we try to support everything without hard adherence to a spec,
> then it's just a matter of time before two people ask for mutually
> exclusive features.  Maybe the RM spec tries to avoid this, but never

The RM spec very specifically avoids that.

#### From the renderman spec: #####

Rendering programs that implement the RenderMan Interface receive all
of their data
through the interface. There must not be additional subroutines
required to control or
provide data to the rendering program. Data items that are
substantially similar to items
already described in this specification will be supplied through the
normal mechanisms,
and not through any of the implementation-specific extension
mechanisms (RiAttribute,
RiGeometry or RiOption). Rendering programs may not provide
nonstandard alternatives
to the existing mechanisms, such as any alternate language for
programmable shading.

##################################

> *I just envisioned a list of features with 2 check boxes "Blender
> Feature" and "External Feature" and a user checks what features to do
> each way.  An unknown renderer could just start off with all the
> "Blender Features" checked, and thus export everything as VlakRen
> with very basic Material to Shader conversion.  This gives the
> average user the ability to add the list of features to the exporter,
> and to override that list if he happens to think Blender does it
> better (getting a FEATURE_NOT_SUPPORTED signal back could gray out
> the "External Feature" option for that feature..

That would be a good way to go about it, and I've already provided for
such with Neqsus...in truth, it's less about features, and more about
the options/attributes for each scene and/or object. It's simple
enough to, for a selected object, to append a list of configurable
attributes that can be modified. Truth be told, Renderman's
options/attribute system is actually how renderer features are
controlled.  Thus, RiAttribute and RiOption commands are passed, which
are standard and supported by all renderers that claim compliancy,
making it *very* easy to support. So from the standpoint of supporting
a given feature, a renderer merely needs to accept the Renderman
standard input mechanisms, and life is good.

Bobby Parker
ShortWave