[Bf-python] material lists

[Yann Vernier]

On Sat, Jul 17, 2004 at 03:46:03PM -0300, Willian Padovani Germano wrote:
> Blender stores material lists in objects and meshes as a pointer to pointers to
> mat structs.  So it only keeps existing ones itself.  The patch you sent only
> had changes to the bpython side.  Blender itself requires both the ob and mesh
> mat lists to have the same size, as you probably saw it has functions to confirm
> / fix that case their sizes differ.

Yes.. and the code to do that I saw in the python interface crashed,
due to copying the wrong size. The lists are indeed not always the full
size of 16 materials, but can have holes in them, similar to what 
happens with any object that doesn't have a material assigned.

These holes, as can be created with the UI, showed up as None with my
patch, leading to the conclusion that NULL is indeed the correct
representation.

> Changing this to allow empty (null) slots probably means making many changes in
> Blender, specially in the renderer, since it probably doesn't expect null mats
> or will stop upon finding one.  This also means more pointers stored per obj and
> mesh, but anyway it's a change in Blender, not only bpython.  To get it in you'd
> need to discuss / get approval in the bf-committers list first.

It already supports empty slots! Create a mesh in the interface, add a
few material indices, back up to the first material index, go to the
material buttons (F5) and remove the link. No material, but the slot
exists and the others remain unchanged. This is necessary, and allows
for some materials to be defined per-object while others are from the
mesh, without keeping unused materials assigned.

> On the other hand, without code changes: at the bpython side, you can define a
> "Null" or "Foo" material and use it in you importer where an empty slot would be
> placed.  Setting this material's alpha to 0, maybe also its color to white is
> enough to make it have no effect.  And since the face mat indices won't refer to
> it, the "foo" mats won't be used anyway, it'll just serve as your empty mat case
> you want to export the data back later.

But it doesn't match what you can put in the Blender material lists
right now from the UI, and means sticking more data in your .blend.
Besides, I'm not really sure even the argument about those lists being
equal size holds - Blender would crash if unequal size lists were set
from Python because of the copy my patch fixed. How would it deal with
someone altering a library linked mesh when the object is in another
file?

Experimenting with this, I found the interface is a bit inconsistent and
odd. Example at http://donkey.dyndns.org/~yann/blender/matlist.zip shows
two .blend files, tricolor used as a library and trilink linking to it.
The left quad, including its material index, was added to tricolor after
trilink was made; the bottom quad uses a material index set to be
per-Object, and has different materials in tricolor and trilink. That
one had no material when loaded into trilink originally. Curiously,
there's a UI bug here; I could add, but not edit, an object in the empty
data material slot, which naturally didn't get saved as the data was in
another file. Making Object materials over Data materials does not
seem to work for library linked data, but it is quite possible for
ordinary data. The fact that I could go back and forth, adding material
slots, seems to mean it's not too terribly fragile. 

> To export the same thing can work: check if a mat is called "Null" or something
> and put an empty slot where it would be.
But if a material was unassigned (as I've done in the UI and, with my
patch, from scripts) you can't tell which slot it came from. 

> About crashes: please tell us about any you find, they should not be there.
This one was straightforward: the memcpy copied only as many bytes as
there were pointers, simply a missing *sizeof(void*). Happened any time
you tried to assign material lists with different numbers of materials
in them to an object and its data.

-- 
PGP fingerprint = 9242 DC15 2502 FEAB E15F  84C6 D538 EC09 5380 5746
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20040717/07b56529/attachment.sig>