[Bf-funboard] Another sort of plugins
Sun, 6 Jul 2003 11:30:44 +0300
> The plug would load when firing up blender.
Not so for all plugins... If you look at many programs, ala gimp, photoshop, etc,
which contain *a lot* of plugins, they have massive startup times, partly because
of having to load so many. One of the good things about blender is that it is fast
to load, so I can open it, check something, or modify something, and close again
in less than a minute. I'd vote for files in .blender:
etc. which would have lists of the plugins installed for each thing, and at
the correct point would load them. (Then again, onload is probably the
simplist and a lot easier than my over-complicated method) ;-)
> This plug would operate a complete "upgrade" of blender's functionality.
> -- It could add a new type of material. When you click on "Add New"
> it could add a "Add New Yafray Material" and this material would
> contain all the specificities of Yafray's shaders, like a complete new material panel.
> (or it could also modify the existing one, i'm just exposing what could
> be the possibilities of such an API, not designing a new plug :)
> -- It could add a new entry to the Spacebar ADD menu, such as Add Yafray Lamp.
> -- The lamp panel (with a yafray lamp selected) would show Yafray's Lamps' specific functions.
> -- It could also draw the new lamp types differently in the 3D views. (area lights, phton lights, etc...)
> -- and add a new option to the render window... "Render to Yafray"
I disagree on the "New Yafray Material" or "New Yafray Light" bit. This makes the different
renderers get too seporated, and then you can't use the blender renderer for quick
renders while working, before doing a final/production render in yafray. Just adding
"Area", "Photon" etc to the lamp-types would be better (IMHO), with perhaps a
note/tooltip/colour-change notifying that only in yafray (or other renderers (Renderman))
will these get used. Then if you rendered with the blender-renderer, it woudl just show
a normal light there (or some kind of "fake".)
> This design isn't perfect (but i think it could be a way to go in the futur for
> export plugins). But it wasn't my point as I said. I don't think scripts aim at
> the same goal as "plugins". in example: I do beleive (though I may be wrong)
> that dynamics such as soft bodies would better be written in a compiled
> language than a scripted one, for speed reasons (cloth, fluids.... require a lots of maths).
True. IMBWB scripts are like "a new function" ('create a tree', 'export current scene
to yafray', 'move an aeroplane convincingly', etc) and plugins are "new functionality"
('Photon Lamp-type', '"OOPS" type window'). So, in a sense, a script (by my understanding)
would be correct for dynamics of an object, but, as you say, for speed reasons,
compiled/plugin is better.
> But this API, if t was ever to come, should come with B3, not before.
Hm... I'd personally want to go there from current blender, slowly extending. For instance,
a) make 'Effects' plug-in-able (build/particles/wave)
b) move current effects into plugins (no "built-ins")
Then the effects list for me would look like:
(note - the 'build' plugin not on my list, as I never use it. People who do use it would
have it on their lists, if they want)
The same for textures, renderers, restraint-types, etc. Much as a whole new extensible
B3 is a good idea, and will happen I'm sure/hope, This kind of thing could happen within
B2 and still work/be good/be a good idea.