[Bf-committers] Render API Plugin System
Aaron Moore
two.a.ron at gmail.com
Mon Jul 2 10:44:23 CEST 2007
Hi,
In parallel with my implementation of the api, I am continuing to work
on design. Here are some more issues with the plugin system that I've
run into. The big questions I've placed ***s by. Note some of this
might make a little more sense if you first look at this:
http://wiki.blender.org/index.php/Render_API#Render_API_Plugin_System_Design
and possibly this:
http://wiki.blender.org/index.php/Requests/Plugin-System
Terms:
- plugin --- the shared library which contains the code necessary to
make an external renderer work for blender
- render job --- a single render request, from start to finish
note: multiple can coexist and be composited, or
sequenced together.
- renderer instance --- the per-render-job render process: renderers can
have multiple instances--with different settings that
work together to produce the final image. They can also
be used for different render tasks throught the UI:
various types of previews, for example.
-----------------
Plugin Loading:
-----------------
Desc: plugin files are loaded, init functions run,
and the "Renderers" dropdown is populated.
When: good question. *** options:
a. on startup / on draw ui
b. on draw buttons area -- current choice
c. on draw render buttons -- IMO best alternative
d. on click on "Renderers" dropdown list
-----------------
Storage:
-----------------
Desc: where and what 1plugin, 2renderer, and 3instance data is
stored for 1sessions and in the 2file.
General Rule: Data that can be regenerated from plugin init
functions will not be saved to file.
Plugin Data: plugin name, author, version, render api version
only info that *only plugins need*, if internal needs it, that's below
Renderer Data: renderer name, version, capibilities, callbacks
Instance Data: renderer specific settings (custom ui), that is,
settings which can be set differently for different render jobs:
1. render layers that use different engines
2. different custom settings for material previews
hard code this, no need to save to file.
3. preview renders might want to have settings optimized.
4. *** any other kind of separate render jobs?
(basically it's: a. render layers and b. previews of various kinds)
*** Should the render engine even be specified for the whole scene?
Perhaps the render engine selection menu should move to the render
layers menu, and blender should maintain an active render layer from which
all previews choose their engine and settings. Just an idea. Up for
suggestions here.
On Save: save instance settings to the file
On Load File: load instance settings
All custom render instance settings should be saved to the place where the
the render job is instatiated: render layers should store the render engine
that they use, etc. *** is this a good idea? or should they be all
stored in some
central place and simple linked to by the various structures which
will need them?
I've got some idea of where I'm going with these questions, but I
thought I'd get input if there is input to be gotten.
Aaron
More information about the Bf-committers
mailing list