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

[Bob Wenzlaff (AB8TD)]

At 05:03 PM 6/7/2007, you wrote:
>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.

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.


>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.

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.

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.

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.

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.)

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 
underestimate the ability of a developer to re-interpret a spec 
:)  I've been in the Testing and Automation software business for a 
while and have seen it _a lot_.

*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..

Bob Wenzlaff





-- 
No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.472 / Virus Database: 269.8.11/838 - Release Date: 6/7/2007