Dynamic Material peformance

Hi,

I’m working on a model that has a large set of buttons that light up and which need to be able to toggle independently through Blueprint/code. The entire model uses one texture and material. My plan was to use a single emissive texture that contains all buttons, tied to a parameter, then have each button mesh a separate component in Blueprint. Then in the construction script, I’d turn the assigned materials into Dynamic Material Instances and reference them in variables (possibly adding them to an array). Each button can then be turned on and off independently. However, only a maximum of 10 buttons can be active at any one time.

Now, I wonder if this is the way to go, or if there is another more efficient way of doing it. It works, I already (partly) tested it, but I want to know if this is too inefficient or performance heavy, since I’m still a beginner in terms of understanding performance bottlenecks and optimizations.

Yeah, I think this is the way to go.

  • In the Material itself promote the emissive color to a variable.
  • Create one Dynamic Material Instance for every button.
  • Then “edit vector parameter” of the Material Instances during runtime.

I don’t think emissive color and Material Instances are that performance heavy as I’m using it, too.
But I’m also pretty new to developement.

How many buttons are we talking about? Each buttons will have some overhead, but for this to be an issue you probably need a very large amount of them.

A possible approach that would scale better could be:

  • Assign a single dynamic material instance to all buttons.
  • Adjust the UVs of the buttons so they lay nicely in a grid. (Potentially in a separated UV set if you already used the others for texturing/lightmapping)
  • Create a material that can blend 10 shapes the size of one button in UV space
  • Add ten parameters to set the UV locations of those shapes
  • Calculate the UV locations of the lit up buttons in your blueprint and pass them to the material.

This should scale to an almost infinite number of buttons (or at least until the geometry load becomes the bottleneck) but will probably be overkill. Before making things needlessly complex I would recommend profiling the actual impact your system currently has and only adjust it if it turns out to have a significant effect.

Well, there are 39 buttons with 38 of those having a similar shape. OK, perhaps I can say where it is used for specifically: the DHD of a Stargate. It has 39 buttons where 38 of those represent the symbols (minus one) on the gate. There are three unique button models; one for the outer ring, one for the inner ring and one for the center button. The first two however, have the symbols on them which requires unique UVs, so I can’t instance them.

But you have an interesting solution, though I wouldn’t know how to implement it yet. So far I understand, it basically masks the active buttons out of the inactive buttons, right? It’s interesting, and I can surely try it, but wouldn’t this add another material, or can I use the same material but using a different UV set?

This could all be done in a single material. But if you only have 39 buttons I think you do not have to worry about performance too much. Doing it the simple way with a dynamic instance per button shouldn’t be particularly heavy with that number of instances.

The approach I described probably only starts being worth it when talking about hundredths of buttons.

Ah, thanks. I’ll try to keep my on things and see if I can find the info in the profiler for it. Thanks for the help. :slight_smile: