Replace object-linked materials feature #99996
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
14 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#99996
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Materials linked to objects have some issues:
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:
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.
Yes, it should, since objects wouldn't have a material array that needs to be resized anymore (For reference:
94323bb427
)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.
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.
@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).
Option 1 and 2 is great
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:
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.
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.
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.
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.
Object linked materials are filling the desire to change mesh data without modifiers, just by a relinking of another mesh datablock, without changing materials.
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.
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?
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.
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:
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?
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.
Remove object-linked materialsto Replace object-linked materials featureI 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
Mesh.materials
rather thanObject.material_slots
.Object.material_slots
should be removed.Mesh.materials
with a value ofNone
.I think this addresses all the concerns raised in the thread so far.
Personally I feel this would resolve all issues I have and I'd be thrilled to see your proposal adopted.
@zeauro
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
I admit, this is the most difficult dilemma in this whole topic.
@kursadk
If you're doing anything other than material replacment, you're probably going to organize everything in the easiest way possible for yourself.
@Grady
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)).
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
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.
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, ...).
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;
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.
I wasn't trying to just lose everything what have users
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.
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.
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
Would this change also fix the memory usage problem?
#109978