Replace object-linked materials feature #99996

New Issue

Hans Goudey · 2022-07-26T15:26:09+02:00

Hans Goudey commented

2022-07-26 15:26:09 +02:00

Materials linked to objects have some issues:

They cause problems for geometry nodes, which can arbitrarily change material slots during evaluation.
They tend to be confusing, partially due to relying on consistent indices between two different lists
They cause large performance issues for reference counting in the main data-base, since geometry-level operations also have to be aware of objects
Object-linking is theoretically redundant now that materials can be changed during evaluation.

Because of that, it would be best to remove the feature and replace it with something more generic.
Most workflows are already possible with nodes like the "Replace Material" node, but we have to be able to replicate the behavior exactly in order to version the feature away. There are a few options:

Add a modifier with a UI-list interface that sets materials at specific slots.
Add the necessary features to geometry nodes (loop? lists?) necessary to make the behavior completely generic
Just add a geometry node group with enough nodes to handle whatever list of object linked materials the object had.

Materials linked to objects have some issues: - They cause problems for geometry nodes, which can arbitrarily change material slots during evaluation. - They tend to be confusing, partially due to relying on consistent indices between two different lists - They cause large performance issues for reference counting in the main data-base, since geometry-level operations also have to be aware of objects - Object-linking is theoretically redundant now that materials can be changed during evaluation. Because of that, it would be best to remove the feature and replace it with something more generic. Most workflows are already possible with nodes like the "Replace Material" node, but we have to be able to replicate the behavior exactly in order to version the feature away. There are a few options: 1. Add a modifier with a UI-list interface that sets materials at specific slots. 2. Add the necessary features to geometry nodes (loop? lists?) necessary to make the behavior completely generic 3. Just add a geometry node group with enough nodes to handle whatever list of object linked materials the object had.

❤️ 1

Howard Trickey commented

2022-07-26 20:51:57 +02:00

This would certainly simplify some code and simplify the understanding of what goes on with materials (speaking as someone who struggled a bit to understand the code dealing with the two material systems), so I hope this happens.

Aras Pranckevicius commented

2022-07-26 21:01:59 +02:00

Would this also remove the need to "scan the whole world" whenever setting a material on a mesh data object? If so, yes please.

I could try implementing this todo, if someone would decide which one of the "There are a few options" approaches is best.

Would this also remove the need to "scan the whole world" whenever setting a material on a mesh data object? If so, yes please. I could try implementing this todo, if someone would decide which one of the "There are a few options" approaches is best.

Hans Goudey commented

2022-07-26 21:17:40 +02:00

Would this also remove the need to "scan the whole world" whenever setting a material on a mesh data object? If so, yes please.

Yes, it should, since objects wouldn't have a material array that needs to be resized anymore (For reference: 94323bb427)

I could try implementing this todo, if someone would decide which one of the "There are a few options" approaches is best.

That would be great! At least options 1 and 3 should be relatively straightforward I think. But maybe people have other options too, that's just what I came up with in a few minutes of thinking.
I added it to the agenda for tomorrow's geometry nodes sub-module meeting, though it could make sense to discuss it elsewhere too.

>Would this also remove the need to "scan the whole world" whenever setting a material on a mesh data object? If so, yes please. Yes, it should, since objects wouldn't have a material array that needs to be resized anymore (For reference: 94323bb42748) >I could try implementing this todo, if someone would decide which one of the "There are a few options" approaches is best. That would be great! At least options 1 and 3 should be relatively straightforward I think. But maybe people have other options too, that's just what I came up with in a few minutes of thinking. I added it to the [agenda ](https://devtalk.blender.org/t/2022-07-27-geometry-nodes-sub-module-meeting-upcoming/25232) for tomorrow's geometry nodes sub-module meeting, though it could make sense to discuss it elsewhere too.

Johnny Matthews commented

2022-07-26 21:19:11 +02:00

I've used object-level materials with library overrides quite a bit recently as it's one less step for overriding a material. This type of change would definitely need to have a nice update functionality for old files.

Hans Goudey commented

2022-08-01 19:42:32 +02:00

@mont29 The point about library overrides is one thing that's not clear to me.
Do you think it is possible to version library overrides from object to modifier properties?

@mont29 The point about library overrides is one thing that's not clear to me. Do you think it is possible to version library overrides from object to modifier properties?

Bastien Montagne commented

2022-08-02 11:07:04 +02:00

@HooglyBoogly it should be possible yes, although it may be a bit tricky (hard to tell for sure before trying).

Valera Barashkov commented

2022-08-03 20:10:48 +02:00

Option 1 and 2 is great

Mindinsomnia commented

2022-08-05 02:36:55 +02:00

Just a couple of points of feedback for consideration as someone who uses the Object-Linked Materials regularly in my workflow to setup material variations of objects in scenes.

Options outline:

Add a modifier with a UI-list interface that sets materials at specific slots.

Add the necessary features to geometry nodes (loop? lists?) necessary to make the behavior completely generic

Just add a geometry node group with enough nodes to handle whatever list of object linked materials the object had.

With a modifier based approach outlined above, the per-object material properties would be located in the modifier tab, which isn't ideal from a UX perspective.

The biggest disadvantage of this approach however is that it would not be possible to use the 'Link/Transfer Data -> Link Materials' operator to transfer a set of Object-Linked Materials from one object to another. The per object materials would be located in a modifier.

So you would need to use the 'Link/Transfer Data Copy Modifiers' operator instead. But this would copy across all the other modifiers as well, and in addition, replace the existing modifier stack of the target object.

As someone who uses the Object-Linked Materials feature regularly, in my experience, this is rarely what I would what, as most objects have their own unique modifiers as well, such as boolean modifiers for unique cutting shapes per each object.

So either the entire modifier stack would have to be copied, and then altered. Or the material set modifier would need to be modified manually, setting possibly a dozen or more materials by hand to copy across a material set.

This would be considerably more time consuming than the current workflow.

With regards to this, would it be possible to maintain the current UI where what amounts to effectively a 'material override' for an object's slot is still visually located in the material properties tab? From a UX perspective it would be probably best to keep material related settings in that location.

Effectively, yes ditch the current underlying technical implementation of how this works, and replace it with a new implementation, but keep the UI entirely as is? And under the hood, the 'Object-Linked' materials could be transparently effectively adding a material modifier that you just can't see.

This would allow for easy transition of files from one system to the next with a straight 1 to 1 conversion from the old system to the new system, and keep modifiers and per-object materials separate.

Just a couple of points of feedback for consideration as someone who uses the Object-Linked Materials regularly in my workflow to setup material variations of objects in scenes. Options outline: > 1. Add a modifier with a UI-list interface that sets materials at specific slots. > 2. Add the necessary features to geometry nodes (loop? lists?) necessary to make the behavior completely generic > 3. Just add a geometry node group with enough nodes to handle whatever list of object linked materials the object had. With a modifier based approach outlined above, the per-object material properties would be located in the modifier tab, which isn't ideal from a UX perspective. The biggest disadvantage of this approach however is that it would not be possible to use the 'Link/Transfer Data -> Link Materials' operator to transfer a set of Object-Linked Materials from one object to another. The per object materials would be located in a modifier. So you would need to use the 'Link/Transfer Data Copy Modifiers' operator instead. But this would copy across all the other modifiers as well, and in addition, replace the existing modifier stack of the target object. As someone who uses the Object-Linked Materials feature regularly, in my experience, this is rarely what I would what, as most objects have their own unique modifiers as well, such as boolean modifiers for unique cutting shapes per each object. So either the entire modifier stack would have to be copied, and then altered. Or the material set modifier would need to be modified manually, setting possibly a dozen or more materials by hand to copy across a material set. This would be considerably more time consuming than the current workflow. With regards to this, would it be possible to maintain the current UI where what amounts to effectively a 'material override' for an object's slot is still visually located in the material properties tab? From a UX perspective it would be probably best to keep material related settings in that location. Effectively, yes ditch the current *underlying technical implementation* of how this works, and replace it with a new implementation, but keep the UI entirely as is? And under the hood, the 'Object-Linked' materials could be transparently effectively adding a material modifier that you just can't see. This would allow for easy transition of files from one system to the next with a straight 1 to 1 conversion from the old system to the new system, and keep modifiers and per-object materials separate.

Hans Goudey commented

2022-08-05 20:45:19 +02:00

Thanks for giving your detailed thoughts, it's helpful.

With a modifier based approach outlined above, the per-object material properties would be located in the modifier tab, which isn't ideal from a UX perspective.

I could see that, but I think it makes sense the other way around too, once you view the modifier stack as "everything that changes the data from the original".
The modifier would be replacing some materials from the original mesh with a different set. To me that fits well.

The biggest disadvantage of this approach however is that it would not be possible to use the 'Link/Transfer Data -> Link Materials'

I think this section of your comment misses that we have the "Copy to Selected" feature on modifiers for exactly this purpose. If needed we could expose that elsewhere too.

keep the UI entirely as is?

I could see that being a compromise, a way to solve the performance problems. But in the long term I think it's a bad idea for the technical design to differ so much from what we show in the UI.
I also think it misses out on the conceptual simplifications we get from separating "original data" from "changes during evaluation".
For newer users, object-linked materials are confusing because of these fuzzy boundaries.

So personally I'd still push for the long term clarity and embracing a more procedural workflow.

Thanks for giving your detailed thoughts, it's helpful. >With a modifier based approach outlined above, the per-object material properties would be located in the modifier tab, which isn't ideal from a UX perspective. I could see that, but I think it makes sense the other way around too, once you view the modifier stack as "everything that changes the data from the original". The modifier would be replacing some materials from the original mesh with a different set. To me that fits well. >The biggest disadvantage of this approach however is that it would not be possible to use the 'Link/Transfer Data -> Link Materials' I think this section of your comment misses that we have the "Copy to Selected" feature on modifiers for exactly this purpose. If needed we could expose that elsewhere too. ![ ](https://archive.blender.org/developer/file/13338/13338201/image.png) >keep the UI entirely as is? I could see that being a compromise, a way to solve the performance problems. But in the long term I think it's a bad idea for the technical design to differ so much from what we show in the UI. I also think it misses out on the conceptual simplifications we get from separating "original data" from "changes during evaluation". For newer users, object-linked materials are confusing because of these fuzzy boundaries. So personally I'd still push for the long term clarity and embracing a more procedural workflow.

ronan ducluzeau commented

2022-10-10 11:15:43 +02:00

I could see that, but I think it makes sense the other way around too, once you view the modifier stack as "everything that changes the data from the original".
The modifier would be replacing some materials from the original mesh with a different set. To me that fits well.

Object linked materials are filling the desire to change mesh data without modifiers, just by a relinking of another mesh datablock, without changing materials.

But in the long term I think it's a bad idea for the technical design to differ so much from what we show in the UI.
I also think it misses out on the conceptual simplifications we get from separating "original data" from "changes during evaluation".
For newer users, object-linked materials are confusing because of these fuzzy boundaries.

We could change UI to assume that material list in material tab is only mesh data, by default.
And add a material overrides list in a dedicated panel in Object properties tab.
Material slot, in material tab, would be greyed out. And material name replaced by an object icon in material list.
Properties and Shader Editor behaviour would not change.
Just the indication of use of object linked material would be more obvious.

There would be no ambiguity. Mesh data would be modified by GN.
And object properties could override result of GN, or be ignored if there are GN.
I am not sure what choice would be the more pertinent, here.

Ideally, material list in material tab should be dynamic and reflect changes.
At the moment, GN are changing material slots, material list in material tab should adapt.

> I could see that, but I think it makes sense the other way around too, once you view the modifier stack as "everything that changes the data from the original". > The modifier would be replacing some materials from the original mesh with a different set. To me that fits well. Object linked materials are filling the desire to change mesh data without modifiers, just by a relinking of another mesh datablock, without changing materials. > But in the long term I think it's a bad idea for the technical design to differ so much from what we show in the UI. > I also think it misses out on the conceptual simplifications we get from separating "original data" from "changes during evaluation". > For newer users, object-linked materials are confusing because of these fuzzy boundaries. We could change UI to assume that material list in material tab is only mesh data, by default. And add a material overrides list in a dedicated panel in Object properties tab. Material slot, in material tab, would be greyed out. And material name replaced by an object icon in material list. Properties and Shader Editor behaviour would not change. Just the indication of use of object linked material would be more obvious. There would be no ambiguity. Mesh data would be modified by GN. And object properties could override result of GN, or be ignored if there are GN. I am not sure what choice would be the more pertinent, here. Ideally, material list in material tab should be dynamic and reflect changes. At the moment, GN are changing material slots, material list in material tab should adapt.

Ludvik Koutny commented

2022-10-10 20:34:00 +02:00

Currently, materials can not be edited with the material editor unless they are assigned to an object which is selected. Would this change address that as well? Or would it have the same behavior as before, with the exception that you would not only need to have an object selected, but also have material assignment modifier present on that object?

kursad k commented

2022-10-11 07:38:33 +02:00

The problem with the geonodes solution is that now the user has to look in multiple places to figure out what the object's material evaluation is.

Mindinsomnia commented

2022-10-11 09:19:50 +02:00

Thankyou for your response, I appreciate you offering your time to hear me out.

In #99996#1400680, @HooglyBoogly wrote:

The biggest disadvantage of this approach however is that it would not be possible to use the 'Link/Transfer Data -> Link Materials'

I think this section of your comment misses that we have the "Copy to Selected" feature on modifiers for exactly this purpose. If needed we could expose that elsewhere too.
{F13338201 size=full}

The only issue with this is that 'Copy to Selected', would add an additional modifier to the other selected objects wouldn't it? Rather than replace it?

Just to give some perspective on where I'm coming from, please allow me to give some context in the ways in which I use this functionality:

I use Blender for a furniture manufacturer, it's our main tool for rendering product images of furniture for corporate offices for all our marketing material. I have libraries of their furniture products, their furniture ranges can be quite large, here's one such range:

That above is just one product called "Haven", a modular lounge range.

My uses for Blender include bulk rendering images of every item of furniture in a range in a consistent matching fabric colour scheme, and using the 3D models in realistic virtual office interiors to create insitu images of their products. There are situations where I may have literally hundreds of items of furniture in a scene which consists of several floors of an office.

The products themselves often have modifiers on them, as some of them are procedural (sometimes with geometry nodes), or some simply are too high poly to be viewed in their HQ form in the viewport, so they have modifiers which present them as low poly models in the viewport.

To keep things easily editable for fast workflow, when I'm setting up renders of products, I link back to the original model in it's blend file and use a link instead of appending many copies everywhere. To save on disk space and also to make it easy to update products once and see those changes reflected in all our renders.

I also deliberately use the same material slot indexes on each item of furniture in a range for to use the 'Link Materials' functionality to it's fullest.

The 'Link Materials' operator comes in handy then when for example, I need to take an swap all the materials of all the furniture units in an office from one colour scheme (say black and red) to another (blue and green) at once. By selecting just one item, changing it's materials, then selecting all the furniture in the scene with the same material slot layout, I just use 'link materials' to copy the material choices onto all of them at once.

To this proposed change of removing object-linked materials at least in it's current form, my two options would be:

Link Modifiers: I would lose the modifier setups of all the other objects in the process, so I can't use that, it would take longer to add them back than the time saved of doing everything in bulk.

Copy to Selected: The sticking point with this one is that it would 'add' a modifier to all the other furniture rather than replace. So I would have to go through each object manually then after that, find the old material replacements modifier I was using and delete it, otherwise I would have two on each object. Not an issue as such as long as the final one is the only one which counts, but if I need to change materials on objects enough times and repeat the process, eventually I'll have a whole stack of material replacement modifiers on each furniture object.

Geometry Nodes: Make a custom geometry node group that has the material replacements hard coded into it (couldn't be inputs because those are per-object), so I can link those replacements across the whole scene, then I would only need to edit one geometry node setup once for all objects using it. This would be better than the above options I guess but a lot more setup for each scene just to achieve something I'm already doing now with built in functionality.

I appreciate that my specific use case shouldn't be the deciding factor here or isn't the most important thing here, but for me at least, removing this functionality would mean a step backwards right now in terms of my workflow/speed.

...

Unless there was some way of replacing or updating that specific modifier on all objects at the same time?

Lets say you go with this idea:

Add a modifier with a UI-list interface that sets materials at specific slots.

And hypothetically we have a modifier called 'Override Materials', that takes a list of material replacements.
[ "Wood" ] -> [ "Metal" ]

You could duplicate the existing functionality right now of object-linked materials by just adding one operator:

"Set Override Material"

It could be a button somewhere in the material properties tab.

So lets say I want to replace all the 'wood' materials on selected objects with metal, I could select the objects, and click that button.

It could present a simple dialog box, that lets you pick a material 'wood', and pick a material to replace it with 'metal', and click 'add'.

Then for every object selected, if the object already has a 'Override Materials' modifier, it could use the existing modifier and update the replacement as specified by the user.
(If the modifier takes an arbitrary number of replacement slots there's no logical need to have more than one anyway right?)

If the object doesn't have the modifier already, it could be added first.

Maybe throw in a 'Clear Override Materials' to quickly remove the modifier from any selected objects as well.

That would still make it possible to bulk set per-object material replacements in a few clicks, while ditching the old system, and gets the UI close what's happening under the hood.

Would that work?

Thankyou for your response, I appreciate you offering your time to hear me out. > In #99996#1400680, @HooglyBoogly wrote: >>The biggest disadvantage of this approach however is that it would not be possible to use the 'Link/Transfer Data -> Link Materials' > I think this section of your comment misses that we have the "Copy to Selected" feature on modifiers for exactly this purpose. If needed we could expose that elsewhere too. > {[F13338201](https://archive.blender.org/developer/F13338201/image.png) size=full} The only issue with this is that 'Copy to Selected', would add an additional modifier to the other selected objects wouldn't it? Rather than replace it? Just to give some perspective on where I'm coming from, please allow me to give some context in the ways in which I use this functionality: I use Blender for a furniture manufacturer, it's our main tool for rendering product images of furniture for corporate offices for all our marketing material. I have libraries of their furniture products, their furniture ranges can be quite large, here's one such range: ![haven range.png](https://archive.blender.org/developer/F13655231/haven_range.png) That above is just one product called "Haven", a modular lounge range. My uses for Blender include bulk rendering images of every item of furniture in a range in a consistent matching fabric colour scheme, and using the 3D models in realistic virtual office interiors to create insitu images of their products. There are situations where I may have literally hundreds of items of furniture in a scene which consists of several floors of an office. The products themselves often have modifiers on them, as some of them are procedural (sometimes with geometry nodes), or some simply are too high poly to be viewed in their HQ form in the viewport, so they have modifiers which present them as low poly models in the viewport. To keep things easily editable for fast workflow, when I'm setting up renders of products, I link back to the original model in it's blend file and use a link instead of appending many copies everywhere. To save on disk space and also to make it easy to update products once and see those changes reflected in all our renders. I also deliberately use the same material slot indexes on each item of furniture in a range for to use the 'Link Materials' functionality to it's fullest. The 'Link Materials' operator comes in handy then when for example, I need to take an swap all the materials of all the furniture units in an office from one colour scheme (say black and red) to another (blue and green) at once. By selecting just one item, changing it's materials, then selecting all the furniture in the scene with the same material slot layout, I just use 'link materials' to copy the material choices onto all of them at once. To this proposed change of removing object-linked materials at least in it's current form, my two options would be: **Link Modifiers:** I would lose the modifier setups of all the other objects in the process, so I can't use that, it would take longer to add them back than the time saved of doing everything in bulk. **Copy to Selected:** The sticking point with this one is that it would 'add' a modifier to all the other furniture rather than replace. So I would have to go through each object manually then after that, find the old material replacements modifier I was using and delete it, otherwise I would have two on each object. Not an issue as such as long as the final one is the only one which counts, but if I need to change materials on objects enough times and repeat the process, eventually I'll have a whole stack of material replacement modifiers on each furniture object. **Geometry Nodes:** Make a custom geometry node group that has the material replacements hard coded into it (couldn't be inputs because those are per-object), so I can link those replacements across the whole scene, then I would only need to edit one geometry node setup once for all objects using it. This would be better than the above options I guess but a lot more setup for each scene just to achieve something I'm already doing now with built in functionality. I appreciate that my specific use case shouldn't be the deciding factor here or isn't the most important thing here, but for me at least, removing this functionality would mean a step backwards right now in terms of my workflow/speed. ... Unless there was some way of replacing or updating that specific modifier on all objects at the same time? Lets say you go with this idea: > Add a modifier with a UI-list interface that sets materials at specific slots. And hypothetically we have a modifier called 'Override Materials', that takes a list of material replacements. [ "Wood" ] -> [ "Metal" ] You could duplicate the existing functionality right now of object-linked materials by just adding one operator: "Set Override Material" It could be a button somewhere in the material properties tab. So lets say I want to replace all the 'wood' materials on selected objects with metal, I could select the objects, and click that button. It could present a simple dialog box, that lets you pick a material 'wood', and pick a material to replace it with 'metal', and click 'add'. Then for every object selected, if the object already has a 'Override Materials' modifier, it could use the existing modifier and update the replacement as specified by the user. *(If the modifier takes an arbitrary number of replacement slots there's no logical need to have more than one anyway right?)* If the object doesn't have the modifier already, it could be added first. Maybe throw in a 'Clear Override Materials' to quickly remove the modifier from any selected objects as well. That would still make it possible to bulk set per-object material replacements in a few clicks, while ditching the old system, and gets the UI close what's happening under the hood. Would that work?

Vyacheslav Kobozev commented

2022-11-11 20:04:18 +01:00

Okay, it need very good design.
Modifier is not a case. May be modifier from ready list with list of materials. So the same appearance as current material list.

Okay, it need very good design. Modifier is not a case. May be modifier from ready list with list of materials. So the same appearance as current material list.

Vyacheslav Kobozev commented

2022-11-13 22:48:17 +01:00

Okay, here is an idea with minimal difference for user and even better result:

Materials list.
Some materials slots can be overriden.
Option button can switch to original list, so that will allow to see materials on the initial mesh.

Okay, here is an idea with minimal difference for user and even better result: Materials list. Some materials slots can be overriden. Option button can switch to original list, so that will allow to see materials on the initial mesh.

Hans Goudey changed title from ~~Remove object-linked materials~~ to Replace object-linked materials feature

2022-11-13 23:32:12 +01:00

Bastien Montagne added this to the Core project 2023-02-09 15:42:54 +01:00

Bastien Montagne removed this from the Core project 2023-02-09 18:20:30 +01:00

Thomas Barlow referenced this issue

2023-09-14 22:08:31 +02:00

Material Slots: Why they're so weird, and how they could be less weird. #112391

Demeter Dzadik referenced this issue

2023-09-14 23:56:45 +02:00

Material Slots: Why they're so weird, and how they could be less weird. #112391

Demeter Dzadik referenced this issue

2023-09-15 00:02:25 +02:00

PyAPI requirements for Blender Studio Asset Pipeline #112392

Hans Goudey referenced this issue

2023-09-15 05:13:07 +02:00

Material Slots: Why they're so weird, and how they could be less weird. #112391

Demeter Dzadik commented

2023-09-15 14:26:38 +02:00

would it be possible to maintain the current UI where what amounts to effectively a 'material override' for an object's slot is still visually located in the material properties tab?

I have a proposal for this, inspired a bit by how Shape Keys are implemented; A Modifier that only exist under the hood, but not in the UI. But this would be a bit different.

Idea: Semi-Virtual "Material Overrides" GeoNode Modifier

The Materials UIList should use Mesh.materials rather than Object.material_slots.
Object.material_slots should be removed.
Adding a new "slot" just means adding a new entry to Mesh.materials with a value of None.
There is a new operator: "Add/Remove Material Overrides" in the Materials panel.
- When pressed, a system GeoNodes modifier gets created, at the bottom of the stack. You cannot re-order it or edit its node tree (yet). It could even be hidden.
- Its input slots are kept in sync with the Mesh Materials throughout adding, removing, and re-ordering operations performed through either the UI or Python.
- Its input slots are also displayed in the Materials list UI, which is now two columns:
  - The original list of Mesh Materials on one side
  - Corresponding Material Override next to them, which are actually inputs of the above modifier.
  - Unlike on this crappy mock-up, these would be drop-down ID selectors, not just names.
- There'd be an operator to make this modifier editable. This is a one-way process, and the above UI elements will no longer be present if this is done.
- After the system modifier was made editable, a new one can be created again with the "Add Material Overrides" button, just like before.

I think this addresses all the concerns raised in the thread so far.

Current operators like "Link Materials" can be implemented.
Old files can be versioned.
It is using GeoNodes.
It preserves the familiar, list-based UX, all in one place, rather than having to bounce between different UI areas.
Shader Editor should be able to continue working as it does now.

> would it be possible to maintain the current UI where what amounts to effectively a 'material override' for an object's slot is still visually located in the material properties tab? I have a proposal for this, inspired a bit by how Shape Keys are implemented; A Modifier that only exist under the hood, but not in the UI. But this would be a bit different. ### Idea: Semi-Virtual "Material Overrides" GeoNode Modifier - The Materials UIList should use `Mesh.materials` rather than `Object.material_slots`. - `Object.material_slots` should be removed. - Adding a new "slot" just means adding a new entry to `Mesh.materials` with a value of `None`. - There is a new operator: "Add/Remove Material Overrides" in the Materials panel. - When pressed, a **system GeoNodes modifier** gets created, at the bottom of the stack. You cannot re-order it or edit its node tree (yet). It could even be hidden. ![image](/attachments/516a76aa-1dac-41a7-a27f-03df2ae983f6) - Its input slots are kept in sync with the Mesh Materials throughout adding, removing, and re-ordering operations performed through either the UI or Python. - Its input slots are also displayed in the Materials list UI, which is now two columns: - The original list of Mesh Materials on one side - Corresponding Material Override next to them, which are actually inputs of the above modifier. ![image](/attachments/dda66c5b-ff3e-4a21-b6bf-66f76445d03e) - Unlike on this crappy mock-up, these would be drop-down ID selectors, not just names. - There'd be an operator to make this modifier editable. This is a one-way process, and the above UI elements will no longer be present if this is done. - After the system modifier was made editable, a new one can be created again with the "Add Material Overrides" button, just like before. I think this addresses all the concerns raised in the thread so far. - Current operators like "Link Materials" can be implemented. - Old files can be versioned. - It is using GeoNodes. - It preserves the familiar, list-based UX, all in one place, rather than having to bounce between different UI areas. - Shader Editor should be able to continue working as it does now.

image.png

41 KiB

image.png

34 KiB

image.png

34 KiB

👀 1 ❤️ 1

Demeter Dzadik referenced this issue

2023-09-15 14:56:17 +02:00

Material Slots: Why they're so weird, and how they could be less weird. #112391

Demeter Dzadik referenced this issue

2023-09-15 14:56:54 +02:00

Material Slots: Why they're so weird, and how they could be less weird. #112391

Mindinsomnia commented

2023-09-15 15:31:37 +02:00

would it be possible to maintain the current UI where what amounts to effectively a 'material override' for an object's slot is still visually located in the material properties tab?

I have a proposal for this, inspired a bit by how Shape Keys are implemented; A Modifier that only exist under the hood, but not in the UI. But this would be a bit different.

Personally I feel this would resolve all issues I have and I'd be thrilled to see your proposal adopted.

> > would it be possible to maintain the current UI where what amounts to effectively a 'material override' for an object's slot is still visually located in the material properties tab? > > I have a proposal for this, inspired a bit by how Shape Keys are implemented; A Modifier that only exist under the hood, but not in the UI. But this would be a bit different. > Personally I feel this would resolve all issues I have and I'd be thrilled to see your proposal adopted.

Iliya Katushenock commented

2023-09-15 21:54:15 +02:00

@zeauro

Object linked materials are filling the desire to change mesh data without modifiers, just by a relinking of another mesh datablock, without changing materials.

This introduce complexity where there shouldn't be any. The mesh will be different in any case, it’s just that the render engine won’t do it for you.

@Rawalanche

Currently, materials can not be edited with the material editor unless they are assigned to an object which is selected. Would this change address that as well? Or would it have the same behavior as before, with the exception that you would not only need to have an object selected, but also have material assignment modifier present on that object?

I admit, this is the most difficult dilemma in this whole topic.

@kursadk

The problem with the geonodes solution is that now the user has to look in multiple places to figure out what the object's material evaluation is.

If you're doing anything other than material replacment, you're probably going to organize everything in the easiest way possible for yourself.

@Grady

The 'Link Materials' operator comes in handy then when for example, I need to take an swap all the materials of all the furniture units in an office from one colour scheme (say black and red) to another (blue and green) at once. By selecting just one item, changing it's materials, then selecting all the furniture in the scene with the same material slot layout, I just use 'link materials' to copy the material choices onto all of them at once.

Perhaps your workflow is similar to something like this?

(Creating separate copy of monkey, for color from each object with multiple materials (today, with new geometry nodes features, this would be possible to sample multiple materials from each object to associated monkey) (see linked PR links below)).

Unless there was some way of replacing or updating that specific modifier on all objects at the same time?

I'm really not sure why you want to change modifiers and their data. Today's geometry node pipeline means you can simply process each individual object in the collection through your modifier.

@Mets

Idea: Semi-Virtual "Material Overrides" GeoNode Modifier

It would be better to remove the very concept of this kind of thing. If you want to change the geometry in any way, do it yourself, manually, via modifiers.

Its input slots are also displayed in the Materials list UI

Not sure about the lists. If you just want to have another mesh, with it own a list of it, you can do that now (Perfect solution is not yet available, so I didn't do a workaround with joining geometries.):

See: #106666, #105448

My opinion: This thing should be deleted and forgotten (Object Materials).
The very fact that the object itself adds any data to the mesh confused me.
If the textures in the node tree were determined by the owning object, because of slots indices rather than sockets and links (as in geometry nodes now), it would be even worse.

Please take into account that the geometry nodes are already quite developed, and will expand even more. Everything related to processing the mesh and mesh processing control UI is what develops in the geometry nodes (Panels, Zones, ...).

@zeauro > Object linked materials are filling the desire to change mesh data without modifiers, just by a relinking of another mesh datablock, without changing materials. This introduce complexity where there shouldn't be any. The mesh will be different in any case, it’s just that the render engine won’t do it for you. @Rawalanche > Currently, materials can not be edited with the material editor unless they are assigned to an object which is selected. Would this change address that as well? Or would it have the same behavior as before, with the exception that you would not only need to have an object selected, but also have material assignment modifier present on that object? I admit, this is the most difficult dilemma in this whole topic. @kursadk > The problem with the geonodes solution is that now the user has to look in multiple places to figure out what the object's material evaluation is. If you're doing anything other than material replacment, you're probably going to organize everything in the easiest way possible for yourself. @Grady > The 'Link Materials' operator comes in handy then when for example, I need to take an swap all the materials of all the furniture units in an office from one colour scheme (say black and red) to another (blue and green) at once. By selecting just one item, changing it's materials, then selecting all the furniture in the scene with the same material slot layout, I just use 'link materials' to copy the material choices onto all of them at once. Perhaps your workflow is similar to something like this? <video src="/attachments/4e35a790-621e-4f54-a112-84f6797559be" title="2022-11-19 22-27-34.mp4" controls></video> (Creating separate copy of monkey, for color from each object with multiple materials (today, with new geometry nodes features, this would be possible to sample multiple materials from each object to associated monkey) (see linked PR links below)). > Unless there was some way of replacing or updating that specific modifier on all objects at the same time? I'm really not sure why you want to change modifiers and their data. Today's geometry node pipeline means you can simply process each individual object in the collection through your modifier. ![image](/attachments/71f1d6dd-cc98-4eca-9725-30b480e8346b) @Mets > Idea: Semi-Virtual "Material Overrides" GeoNode Modifier It would be better to remove the very concept of this kind of thing. If you want to change the geometry in any way, do it yourself, manually, via modifiers. > Its input slots are also displayed in the Materials list UI Not sure about the lists. If you just want to have another mesh, with it own a list of it, you can do that now (Perfect solution is not yet available, so I didn't do a workaround with joining geometries.): ![image](/attachments/81da397c-aed7-4554-9e22-5fcecb736388) See: https://projects.blender.org/blender/blender/pulls/106666, https://projects.blender.org/blender/blender/pulls/105448 My opinion: _This thing should be deleted and forgotten (Object Materials)._ The very fact that the object itself adds any data to the mesh confused me. If the textures in the node tree were determined by the owning object, because of slots indices rather than sockets and links (as in geometry nodes now), it would be even worse. Please take into account that the geometry nodes are already quite developed, and will expand even more. Everything related to processing the mesh and mesh processing control UI is what develops in the geometry nodes (Panels, Zones, ...).

image.png

277 KiB

image.png

412 KiB

2022-11-19 22-27-34.mp4

6.9 MiB

Demeter Dzadik commented

2023-09-15 22:08:51 +02:00

This thing should be deleted and forgotten (Object Materials).

My proposal could also exist as a built-in add-on, for users like @Grady. I think at least that level of effort to try and preserve those workflows would really be a bit more respectful when killing off what I'm guessing is a circa 20-year-old feature. Otherwise users would be rightfully pissed, imo.

An add-on version of the design would be slightly weaker;

The .blend file may be spammed with NodeTrees by the add-on.
Direct editing of the modifier can't be prevented (unless we get some PyAPI for that). If the modifier is renamed, the add-on will break. If the modifier is re-ordered, its behaviour might change.

I have no strong feelings, but just wanted to offer a variation of my proposal that might make @mod_moder a bit happier, while maaaaybe still keeping @Grady also moderately happy. LMK what ya'll think.

> This thing should be deleted and forgotten (Object Materials). My proposal could also exist as a built-in add-on, for users like @Grady. I think at least that level of effort to try and preserve those workflows would really be a bit more respectful when killing off what I'm guessing is a circa 20-year-old feature. Otherwise users would be rightfully pissed, imo. An add-on version of the design would be slightly weaker; - The .blend file may be spammed with NodeTrees by the add-on. - Direct editing of the modifier can't be prevented (unless we get some PyAPI for that). If the modifier is renamed, the add-on will break. If the modifier is re-ordered, its behaviour might change. I have no strong feelings, but just wanted to offer a variation of my proposal that might make @mod_moder a bit happier, while maaaaybe still keeping @Grady also moderately happy. LMK what ya'll think.

❤️ 1

Iliya Katushenock commented

2023-09-15 22:19:30 +02:00

I wasn't trying to just lose everything what have users

We can automatically generate the necessary modifiers for old files to reproduce the result meshs (see as exfmples: #105494, #108014).
Add material replacement assets to buil-in node groups.
Redesign or improve existing operators.

But all this is so that the internal data finally comes into equilibrium and balance :).

The main problem for me is that all the problems described here... Their solution using geometry nodes is not even considered.
If the geometry nodes cannot do something in the mesh processing, then this needs to be solved. And not to continue maintain at the same time the same system with an outdated design.

I wasn't trying to just lose everything what have users 1. We can automatically generate the necessary modifiers for old files to reproduce the result meshs (see as exfmples: https://projects.blender.org/blender/blender/pulls/105494, https://projects.blender.org/blender/blender/pulls/108014). 2. Add material replacement assets to buil-in node groups. 3. Redesign or improve existing operators. But all this is so that the internal data finally comes into equilibrium and balance :). The main problem for me is that all the problems described here... Their solution using geometry nodes is not even considered. If the geometry nodes cannot do something in the mesh processing, then this needs to be solved. And not to continue maintain at the same time the same system with an outdated design.

Demeter Dzadik commented

2023-09-15 22:24:30 +02:00

Their solution using geometry nodes is not even considered.

But my proposal right above your previous comment is entirely based on Geometry Nodes. You even quoted me writing the words "GeoNode Modifier". So I'm confused by what you mean by this.

> Their solution using geometry nodes is not even considered. But [my proposal right above your previous comment](https://projects.blender.org/blender/blender/issues/99996#issuecomment-1021995) is entirely based on Geometry Nodes. You even quoted me writing the words "GeoNode Modifier". So I'm confused by what you mean by this.

Iliya Katushenock commented

2023-09-15 22:39:53 +02:00

Ah, yes, it seems that i was really a little inconsistent here, since when i read it now, you actually proposed a redesign of the operator

👍 1

Germano Cavalcante referenced this issue

2023-10-16 17:35:19 +02:00

Volume-type geometries always seem to use the object material while mesh primitives are unpredictable #113712

slowburn commented

2023-11-06 20:05:14 +01:00

Would this change also fix the memory usage problem?
#109978

Would this change also fix the memory usage problem? https://projects.blender.org/blender/blender/issues/109978

Demeter Dzadik referenced this issue from studio/blender-studio-pipeline