[Bf-committers] Render API: Framework and Scene Break-Down
Bob Wenzlaff (AB8TD)
rwenzlaff at soylent-green.com
Fri Jun 8 16:04:36 CEST 2007
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..
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
More information about the Bf-committers