Method to turn an instanced asset into a unique copy

[gentlecolts]

Is your feature request related to a problem? Please describe.

Currently, when making a new mesh via the dev tool, they attach a common "default material". This often leads to errors where, especially when building with groups, users will have edited this material, and every new prefab mesh made will have whatever changes as well, rather than a clean default material. It is also extremely common to then need to make a new material right afterwards, when having a fresh material for each new object would streamline mesh creation

Describe the solution you'd like

Unique copy of default material when creating new meshes

Describe alternatives you've considered

I don't think there's really an alternative here other than the existing process of having to go through menus again to create a new material and attach it to the newly created mesh

Additional Context

No response

Requesters

zangooseoo

[Banane9]

Definitely ran into that before :'D

[Frooxius]

I don't know if this is necessarily a good change. The flip side of this is, that if we do this, it will hurt performance if you're making lots of meshes.

Currently the behavior is optimized for that - you can make lots of shapes in the world and they're cheaper to render, because they share the same material.

We could potentially investigate alternate approach here, like driving the default materials, so they cannot be changed easily, forcing the user to make a new one if they want to.

[Banane9]

Currently the behavior is optimized for that - you can make lots of shapes in the world and they're cheaper to render, because they share the same material.

Is it that much cheaper? I thought the only real improvement is when it's the same material and mesh. 🤔

[Frooxius]

@Banane9 Yes it is. Same material and mesh is even cheaper, because that allows GPU instanced drawing.

However sharing the material across different meshes still saves resources in a number of ways:

• Potentially less GPU state switching when rendering all those objects
• Dynamic batching combines the meshes into a single one and renders them in a single draw call
• Less memory/resource usage

[gentlecolts]

Maybe this'd be a good thing to benchmark then, spawn various numbers of procedural cubes and measure frame times with same material vs unique material. I'm not sure how much people are actually using the default meshes to build out worlds, but i'd imagine no one's using more than like, say, 10k in a world. If the practical performance impact is insignificant, then this is something that'd significantly improve convenience of actually building.

[Frooxius]

I don't think we'd really spend time bench-marking this, that's a lot of effort, over just approaching the problem with the way I proposed above and not worth the time investment on our end.

10K unique materials is quite a lot though, so I don't think we'd really make this change this way either way.

Is there a particular reason you want this problem solved exactly the way you propose, instead of using the approach I outlined above?

[shiftyscales]

I don't really see how it'd be a benefit to building?

The material tip is used to apply materials to surfaces- and if you're building a world out of primitives- then using the material tip to apply different materials to those different surfaces- then you're doing things right.

Having a default material on the cube itself just increases the number of materials in the world with no particular gain or purpose for it. E.g. say a user uses any material other than PBS_Metallic- then it was entirely pointless to have a material on the object itself.

Likewise- having a ton of materials on those slots, rather than managed and deduplicated by the world in the assets slot will lead to additional overhead.

[gentlecolts]

don't think we'd really spend time bench-marking this

Having a suite of performance benchmarks in general should be a goal at some point anyways, as automated testing can help avoid performance regressions and measure optimization tasks.

The material tip is used to apply materials to surfaces

If I'll be quite frank, I don't ever use the material tip. The only unique feature it provides is material conversion which is not something I often need personally. That point aside, regardless of whether you use the material tip or the dev tip, you still have to have a workflow of making the thing you want (say, a cube), then having to make the material you want (even though it's often the conceptually same material as what you already got when you made the cube), and if you or anyone else in the world forgets to do this even once, you now have some annoying incorrect material every single time you spawn in a new object.

It's extra steps that most other software does not impose on you. Unity and Unreal both provide a unique material set per-object unless you explicitly add the same material to multiple objects, Blender has a default material but it also has a very easy single click way of turning that into a unique instance. Resonite, meanwhile, has significantly more physical movement involved in performing similar tasks just due to the nature of how its tools work, so mitigating how many steps are needed to achieve similar results as elsewhere is important for workflows to feel efficient.

Furthermore, it's unintuitive, which is why the teams I've worked with seem to inevitably run into this issue sooner or later. People make a new object, see a new object, it is a distinct "thing", the idea that the coat of paint this unique entity has is shared with the next new unique object they make does not line up with what we experience in real space. When duplicating an object, it makes sense, on some level the user understands that the duplicates are "the same object", even if there's now two of them, but when making a new thing, it's expected to be a "new thing". I don't think I've run into anyone who intentionally shares the default material between objects, it's almost exclusively for prototyping, which is when a fast workflow is more important than a performant result.

With that all said, I'd like to amend my original request with this new alternative acceptance criteria: Reference fields, especially mesh an material ones, should display how many instances are sharing that same reference, and provide an button for turning that instance into a unique copy. Blender's interface would be a good example of this, and I can provide screenshots if necessary

[Frooxius]

Having a suite of performance benchmarks in general should be a goal at some point anyways, as automated testing can help avoid performance regressions and measure optimization tasks.

Sure, but that's way out of scope of this issue.

Even with that in place though, setting up a tests and running them for particular case, making sure it's representative and gives us the data we want takes time, which in this case I don't think would be worth it, even if we had such suite available.

---

For the rest, sure, we get the underlying issue. But what I keep asking for - why do you want it solved in this very particular way, rather than the way I proposed above?

There are often multiple ways to solve a problem and our goal is to find one that's most optimal solution in given situation, that will raise as few problems as possible and won't add a lot of unnecessary effort on our end.

With that all said, I'd like to amend my original request with this new alternative acceptance criteria: Reference fields, especially mesh an material ones, should display how many instances are sharing that same reference, and provide an button for turning that instance into a unique copy. Blender's interface would be a good example of this, and I can provide screenshots if necessary

I think this would work well too, a quick way to create a copy of the material.

This is actually similar to something that Unity does implicitly. Usually in Unity the materials are shared too by default, but when you access the material on an object, it implicitly creates a copy of it, unless you specifically access the shared instance of it. It doesn't fully apply here, but they also make an effort to reduce number of unique materials for performance reasons.

[shiftyscales]

I'd suggest opening a new issue with that request instead then- but generally speaking- it's better to focus on the underlying issues rather than a specific solution to the problem. This is something we establish in our best practices.

[gentlecolts]

rather than the way I proposed above

Appologies for not addressing this specifically. Using drives on it to make it read only only addresses the "accidentally changing it" part of the issue, not the part about it being annoying and unintuitive to have to make a second material. I see that solution as a bandaid

I think this would work well too

Then I think I can accept that as a solution.

it's better to focus on the underlying issues rather than a specific solution to the problem

The form for submitting requests asks for both a solution and an alternative solution. If you don't want people providing solutions as part of these requests why are those required fields

[shiftyscales]

Because it adds additional context to their use-case and problem they're experiencing. There's a reason the topmost question is "Is your feature request related to a problem? Please describe." @gentlecolts.

Feel free to recommend a solution- but don't write the entire issue with the hope of getting a specific solution to that issue implemented- because if that solution isn't suitable for whatever reason- the issue will just get closed down.

[Banane9]

However sharing the material across different meshes still saves resources in a number of ways:

* Potentially less GPU state switching when rendering all those objects

* Dynamic batching combines the meshes into a single one and renders them in a single draw call

* Less memory/resource usage

Thanks, good to know!

[gentlecolts]

I think this would work well too, a quick way to create a copy of the material.

Could this please be re-opened? If I make a new ticket it's just going to be the same request, the only difference may be the wording of the title and a change to the alternative proposed solution(s). It's really frustrating that the team keeps closing tickets that have had updated information in the comments and asking us to make new ones rather than just updating that information in the ticket. This causes frustration and, if acted on, loses prior context/conversation in the new tickets

[shiftyscales]

Sure. I've updated the title. The rest of the request sounds like it has some overlap with/would otherwise be covered by #1048 which is requesting a mechanism to find all instances of a given asset within the scene.

[gentlecolts]

Thank you for updating it, although the ticket is currently still closed and I would again request it being reopened. The ticket you referenced is a similar request, in that they'd like like to know what's referencing an asset, but there's some distinct differences/missing items from that request. The nature of this request, given the currently favored solution, would be a feature similar to how blender handles assets with multiple references. As an example:

Lets say I have two sources referencing the same material. Blender will display the number of references to that material next to it: This isn't unique to just materials, blender will do this with any sharable asset types, such as meshes, node graph groups, textures, etc

Additionally, and perhaps a more important part of this request, is that, in blender, clicking on this number will make make that instance into a single-user copy, aka making a duplicate, which can now be edited independently: The result of clicking that "2", blender has now made that specific material into a duplicate (with a new name, since blender requires unique names)

[shiftyscales]

Sorry- don't know how I missed the reopen button. Meant to comment and reopen, must have misclicked.