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

[Peter D. Cassetta]

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

[Daniel Monteiro Basso]

On Fri, May 10, 2013 at 6:41 PM, Peter D. Cassetta

Post by Peter D. Cassetta
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.

You can script it, e.g.:
bpy.ops.wm.link_append(
directory="/home/dmbasso/projects/lilith/template.blend/Material/",
filepath="template.blend/Material/Hair",
filename="Hair",
link=False, instance_groups=False,
relative_path=False)

Btw, keep up the good work, the concept of your addon is really useful.

Cheers,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130510/9fb13bfe/attachment.htm

[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

Post by Peter D. Cassetta
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

[Dan Eicher]

This may or may not be helpful...

A while back I was working on a similar idea to convert blender materials
to/from JSON format and used a slightly different method, instead of
maintaining a list of properties to save I had a list of common props that
I didn't want to save and did a (in probably non-valid python):

for prop in dir(mat) if not in exclude_list:
do_something_with_prop(getattribute(mat, prop))

IIRC this fed the props into a python dict (used as a switch statement) to
dispatch into handler functions that converted them into a format JSON was
happy with.

The inverse was super easy, create a material/texture, read the props from
the JSON file and if the prop exists set it else it stays as the default.

Two things killed my little project: 1) there was no way to read/set curve
mapping points and nodes/node trees (both fixed now) and 2) my idea to use
a python function as an input method for the file browser was veto'd so
there's no non-sucky way to browse through an internets based material
library from within blender -- which doesn't really matter to the current
discussion but I like to vent...

Anyways, I was thinking on this yesterday and if one were to use an XML
schema, a schema to python generator (eg. generateds) and a little py-magic
it would be possible to have a fully versioned material library database
system without too much hassle.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130511/8a67615c/attachment.htm