Replace object-linked materials feature #99996

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.

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @HooglyBoogly

Added subscriber: @mod_moder

Added subscriber: @aras_p

Added subscriber: @howardt

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.

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.

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.

Added subscriber: @guitargeek

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.

Added subscriber: @JacquesLucke

Added subscriber: @RedMser

Added subscriber: @mont29

@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?

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

Added subscriber: @valera-8

Option 1 and 2 is great

Added subscriber: @Grady

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.

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.
{F13338201 size=full}

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.

Added subscriber: @zeauro

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.

Added subscriber: @AlexeyAdamitsky

Added subscriber: @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?

Added subscriber: @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.

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?

Added subscriber: @scurest

Added subscriber: @EAW

Added subscriber: @Vyach

This comment was removed by @Vyach

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

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Replace object-linked materials feature #99996