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

New Issue

Robert Forsman · 2014-05-28T19:24:58+02:00

Robert Forsman commented

2014-05-28 19:24:58 +02:00

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 bc9e66f083
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 #40393 for some .blend files I was working with that helped me discover and characterize this shortcoming.

**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 #40393 for some .blend files I was working with that helped me discover and characterize this shortcoming.

Robert Forsman commented

2014-05-28 19:24:58 +02:00

Changed status to: 'Open'

Robert Forsman commented

2014-05-28 19:24:58 +02:00

Added subscriber: @mutantbob

Willi commented

2014-05-28 20:07:45 +02:00

Added subscriber: @willi-2

Willi commented

2014-05-28 20:07:45 +02:00

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 commented

2014-05-28 20:56:41 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2014-05-28 20:56:41 +02:00

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.)…

Bastien Montagne commented

2014-05-28 21:53:57 +02:00

Added subscribers: @ideasman42, @brecht

Bastien Montagne commented

2014-05-28 21:53:57 +02:00

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.

P72: #40411

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

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

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. [P72: #40411](https://archive.blender.org/developer/P72.txt) ```diff diff --git a/source/blender/editors/interface/interface_templates.c b/source/blender/editors/interface/interface_templates.c index dd951e4..e7851a9 100644 --- a/source/blender/editors/interface/interface_templates.c +++ b/source/blender/editors/interface/interface_templates.c @@ -407,6 +407,18 @@ static void template_ID(bContext *C, uiLayout *layout, TemplateID *template, Str idfrom = template->ptr.id.data; // lb = template->idlb; + if (id && idfrom && idcode == ID_MA && GS(idfrom->name) == ID_OB && + STREQ(RNA_property_identifier(template->prop), "active_material")) + { + Object *ob = (Object *)idfrom; + int index = ob->actcol - 1; + + /* If the material is linked to data and not object... */ + if (ob->matbits[index] == 0) { + idfrom = ob->data; + } + } + block = uiLayoutGetBlock(layout); uiBlockBeginAlign(block); ``` Campbell and/or Brecht, again would rather have your feeling about it before I commit. :)

Bastien Montagne self-assigned this 2014-05-28 21:54:04 +02:00

Brecht Van Lommel commented

2014-05-28 23:02:38 +02:00

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.

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`.

Bastien Montagne was unassigned by Campbell Barton

2014-05-29 07:56:30 +02:00

Campbell Barton self-assigned this 2014-05-29 07:56:30 +02:00

blender-admin commented

2014-05-29 08:21:15 +02:00

This issue was referenced by 47bf77951a

This issue was referenced by 47bf77951a69d1b817f5201525e62e9e496f1359

Campbell Barton commented

2014-05-29 08:21:58 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-05-29 08:21:58 +02:00

Campbell Barton commented

2014-05-29 08:21:58 +02:00

Closed by commit 47bf77951a.

Closed by commit 47bf77951a.

Robert Forsman commented

2014-06-10 17:52:34 +02:00

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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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