[Bf-python] Ideal way to store material data for matlib add-on?

[Brecht Van Lommel]

Reliably copying material data in and out of a .blend file is going to
be difficult, I wouldn't recommend it. For one, the blender file DNA
needs to match and that keeps changing all the time. Another big issue
would be how it links with other datablocks, if a material has
textures, images, nodes, light groups, etc those pointers will become
invalid. The only way to reliably save all data of a material data
block I can think of is to actually save it to a .blend file.

If you are going to do something like this, you could perhaps find a
way to strip out all the unnecessary DNA and datablocks to get a
library .blend file that is as small as possible, rather than trying
to paste a material into an existing .blend. You could implement a way
to strip wm, screen, scene, .. and similar datablocks that are in
every .blend file, and some way to strip DNA definitions that are not
used by any data saved in the file.

I guess a way to save such a compact library .blend could be useful to
implement in Blender itself too.

On Fri, May 10, 2013 at 7:41 PM, Peter D. Cassetta
<peter at fingertipsoft.com> wrote:
> Hi everyone,
>
> I'm working on ideas for the next version of my material library add-on.
> I am rewriting it from scratch (reusing some old code, of course) and
> would like some help figuring out which route I should take with
> material data storage.
>
> I've been using an XML-based format up to now. It works, but is not
> exactly the best option, because it makes it less than easy to add new
> features into the material files. I had originally decided to use
> XML-based files instead of just .blend files. Because of their size,
> .blend files would have been a little bit overkill. (Downloading a
> .blend with one material; not the greatest plan either server-side or
> client-side.)
>
> After looking into the overall architecture of the Blender file format,
> it seems like it might be possible to somehow splice out the "materials"
> section of the file, use that as its own file which can be downloaded
> and all. Then perhaps the add-on could replace the materials section of
> some .blend with the new downloaded material file, and save the edited
> .blend in an appropriate location.
>
> The benefit of this method is that it makes it easy to distribute any
> material which Blender has saved. Multiple render engine support would
> be a breeze.
>
> My question: is this workable? If so, would someone experienced with the
> .blend file architecture be willing to give me some pointers?
>
> If it is not workable, or just too difficult, an alternative might be
> using a library.blend which stores all the materials. The only difficult
> part would be adding new materials to the library from time to time.
> Currently it's as simple as editing an XML file and uploading the
> XML-based material file, but you can imagine that appending would get a
> bit tedious after a while.
>
> Lastly (and this one seems pretty far-fetched), would it be possible to
> save the raw data contained in bpy.data.materials['Material'] to a file
> somehow? If it could actually work, this might be the best option. To
> add that material to a scene, one would just have to load the file,
> create a new material, loop through all the attributes and apply them to
> the new material. Is this completely ridiculous, or possible?
>
> Also, for any of these ideas I'd be using some kind of XML-based library
> file to provide information about each of the materials.
>
> I'd be happy to hear what anyone else has to think about all this!
>
> Regards,
> Peter Cassetta
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python