[Feature Request] Per Object Material Property

[Myterian]

This is a helpful feature for larger games, where material swapping isn't a viable option. The idea is that every actor can hold a set of properties, which can be read by the attached material. These properties would be set via scripting and during runtime. The attached material needs the same properties to apply it in render. A similar feature is the Random property on FoliageInstance.

Generally this feature can help creating variation with colors and properties, but only one material needs to be created.

Use case in my game is a selection glow: When the player hovers of an interactable actor, the actor needs to glow.

If I set the material emission, then every actor with the same material would start glowing.
If I create a secondary material, I would double the workload in the content creation and I would need to switch between materials. This is a problem, if I have two actors with the same material next to each other, because the glow of one would just stop, instead of fading away. Not looking nice.

I used this feature extensivley, when I was developing in unity and it's call Material Property Block there. Just as a point of reference.

[Tryibion]

Isn't this exactly what virtual material instances are for? You can see an example in code here. https://docs.flaxengine.com/manual/graphics/materials/instanced-materials/index.html?tabs=code-csharp

[Myterian]

As far as I understand, this will duplicate the material. On the surface it would indeed solve the problem, as values can be indipendently changed. But then every object you looked at is having it's own material

[Tryibion]

It does, but only during runtime. Your concern was doubling the workload by needing to create a bunch of materials, which you don't have to do with virtual material instances.

[Myterian]

Yeah, fair, I did only write a concern about workload. I'm also thinking about performance at the same time. Like each actor having their own material and when does the performance problem start with that

[Tryibion]

I believe (could be wrong since I am not an expert on shaders) since it just creates a new material instance that memory usage should not increase much because it is not re-creating the shader. This is similar to how unreal engine does it with their Dynamic Material Instances.

[Myterian]

I would be surprised if that is not the case ^^ My concern in that regard to performance are draw calls, cause every new material instance is an additional draw call.

I'm not sure if mafi said that only same meshes with same material are getting drawn together. There was a discussion a while back on discord about batching and iirc same mesh but different material is it's own draw call and different mesh, but same material is also it's own draw call. In that case the virtual dynamic material makes sense. Not quite sure about the batching tho

[Tryibion]

Looks like it is somewhat talked about here https://discord.com/channels/437989205315158016/437989205315158018/1210156259098103868

[Myterian]

Yeah, that's the convo I was refering to

[mafiesto4]

You can use Per Instance Random node to have stable per-instance random number - works with static meshes, instancing, foliage, decals, etc. If you want to pass some more data then Material Instances are the way to go (including virtual instances).