Page MenuHome

UI incorrectly permits changing material in materal_slots on linked mesh, but changes are not saved
Closed, ResolvedPublic


System Information
Linux bubastis 3.10.25-gentoo #10 SMP Thu Jan 30 22:17:35 UTC 2014 x86_64 Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz GenuineIntel GNU/Linux
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1) (prog-if 00 [VGA controller])

Blender Version
Broken: git bc9e66f0830627e807f720dca4b9d5d8d39e732a
and probably 2.70

Short description of error

The blender UI allows the user to change which material is in the material_slot of a linked mesh and these alterations affect any renders done during the session, however the alterations are NOT saved and will not take effect for any command-line renders.

To reproduce, link (not append) a mesh object from another .blend file. Make a local copy of the object, but leave the mesh as a link to the external file. You can change the material in the material_slots and see the effects in the UI and rendered images and animations. However, if you save the file and open it again, the changes have been lost since the material_slots are pulled from the linked mesh.

I feel the bug is that the UI does not prevent the user from altering the materials in the material_slots of the mesh.

A workaround for this "problem" is to use the per-object material_slots instead of the per-mesh material slots. Fixing the UI will take a little bit of ingenuity since the material combo box will have to be read-only for per-mesh slots and read/write for per-object slots. (although the per-object slots will have to be read-only if the object is still linked to an external file, eh)

See T40393 for some .blend files I was working with that helped me discover and characterize this shortcoming.

Event Timeline

Robert Forsman (mutantbob) created this task.
Robert Forsman (mutantbob) raised the priority of this task from to Needs Triage by Developer.

I agree. Assigning a different material to the linked mesh works temporarily but it shouldn't because it assigns it to the material slot of a linked mesh, which is actually read-only.

Bastien Montagne (mont29) triaged this task as Normal priority.

Not sure we consider that a bug or a TODO? It’s gonna be tough to handle this nicely, I bet. ID template is some kind of spaghetti code spreading all over the place, with a (too?) high factorization between all kind of IDs (objects, materials, textures, etc.)…

Good news is, getting a working patch was not that hard. Bad news is, it’s adding a very specific case handling in an area supposed to be generic… Not sure there is a better solution though.

1diff --git a/source/blender/editors/interface/interface_templates.c b/source/blender/editors/interface/interface_templates.c
2index dd951e4..e7851a9 100644
3--- a/source/blender/editors/interface/interface_templates.c
4+++ b/source/blender/editors/interface/interface_templates.c
5@@ -407,6 +407,18 @@ static void template_ID(bContext *C, uiLayout *layout, TemplateID *template, Str
6 idfrom = template->;
7 // lb = template->idlb;
9+ if (id && idfrom && idcode == ID_MA && GS(idfrom->name) == ID_OB &&
10+ STREQ(RNA_property_identifier(template->prop), "active_material"))
11+ {
12+ Object *ob = (Object *)idfrom;
13+ int index = ob->actcol - 1;
15+ /* If the material is linked to data and not object... */
16+ if (ob->matbits[index] == 0) {
17+ idfrom = ob->data;
18+ }
19+ }
21 block = uiLayoutGetBlock(layout);
22 uiBlockBeginAlign(block);

Campbell and/or Brecht, again would rather have your feeling about it before I commit. :)

I think it's possible to create a RNA_def_property_editable_func for this property? Then you don't have to add a hack in this generic code.

Further, editing the material should be allowed if the material is linked to the mesh, just not when then mesh is linked, so when me->id.lib is not NULL.

After testing a recent home-built blender from git with this .blend file, I find the UI to behave in a reasonable and correct manner for the test cases I could come up with.