[Bf-committers] Render Plugin Development

[Bobby Parker]

Again, for renderman, I've previously floated the idea of 'separating'
the blender material engine or wrapping it in a kind of library where
it could be used as a shadeop DSO to get the material support
neccessary for *seamless* migration. Don't know how plausible that is
for other renderers, but for Renderman it wouldn't be that hard
interface-wise, since the Renderman API provides a very clearly
defined method for doing it. This is very similar to what a lot of
commercial packages do (like Darktree) whereby they create a shader
file that contains the list of parameters to the actual material
engine, that are passed when the shader is called, requiring the user
to do next to nothing to get the desired material working.


On 8/15/07, Mathias Wein <lynx at aspect-design.de> wrote:
>
> Okay, seems we agree ID-Props are essential, before i can't
> access them it's almost pointless to write a plugin for the
> new yafray code, because pretty much everything gets
> stored as ID-Properties.
>
> Campbell Barton wrote:
> > Id suggest that custom material types make use of blenders internal data
> > where possible.
> > (Matt - maybe this is implied in your proposal, not sure...)
> > For example, you have a scene. render in Povray and set the color to
> > just the right color, then decide to try renderman, when changing the
> > material types youd not want to loose the color.
> >
> Well, my "scripting department" (Bert Buchholz) strongly voted against
> mixing blender settings with external renderer specific ones, and he
> pretty much convinced me it is the better way.
> If the blender material can't be converted, make a complete and clean
> interface for the material type, it is confusing if renderers overwrite
> each other's settings, and mappings will become unintuitive if you try
> to reuse too many settings, too few will have the same meaning.
>
> The reason is, the new materials in yafray are much more specialized,
> which is just necessary for efficient and realistic GI with reasonable
> development effort. A one-fits-all material will possibly never exist again.
> Lights and cameras don't have identical settings either...it is a pure
> raytracer after all, with all the benefits and limitations.
>
> What i do reuse (more or less in lack of an easy alternative) are
> blender's texture layers. But mapping of those channels to material
> specific ones is unintuitive enough...anyway, i tried to port the texturing
> code as good as possible, even though internally everything works
> on a custom node system now...so again, the code could do more
> than you can access through the blender interface until i get a custom set
> of nodes into blender...
>
> --
> Mathias (Lynx(3d))
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
Bobby Parker
sh0rtwave at gmail.com
http://www.stormwind-studios.com