I’ve been working on a nice material for the marketplace when I noticed something disturbing: I’ve added a ton of features to material that use static switch parameters to turn those features on and off. However, when I switched everything off to simulate a cheap material and checked the release stats, it was a much greater cost of a similar material that did not contain switches: 85 instructions vs 54, and they both look the same/use the same features. Is there some hidden cost to using switches that I don’t know about, or is a glitch in my version of Unreal (4.2)? I’d imagine static switches do not change at runtime, so they can remain permanent constants when compiled for final release.
If is not a glitch, that would mean I can’t parameterize too many things, and it would be much cheaper to make the features as separate materials.
NOTE: I noticed the increased instructions were for the stats related to static lighting. The dynamic lighting cost of both shaders is the same.
the problem you describe doesn’t make much sense to me, buuuuuuut…
as described here ], a Static Switch will only create 2 versions of the material internally.
stacks up to maximum possible combinations between them (i.e. 3 switches already creates 9 materials, 4 switches creates 16, etc), which in the end defeats all the advantages of the MaterialInstance system. I’d be extra careful with StaticSwitch if I were you
There may be hard limits on the number of static switches you are allowed to use. I don’t know how many you mean by a “ton”, but once you get past 20 parameter switches you will be looking at millions of combinations and you can quickly reach billions or trillions. I would imagine that there is a check to limit the number of compiled shaders to a sane amount so it may start silently treating additional parameter switches as dynamic.
Of course, that’s speculation. Might need to do some experimenting or digging into the source code to find out, but I would imagine it’s a pretty good bet there is some safety checks in the code somewhere. Rates of exponential growth can be pretty mind-boggling once n starts getting up there.
Separate materials may be necessary, I also have a large parameter material (~100 parameters, using a MaterialParameterCollection, the parameter limit is 1024 per material). I also found out Static switch & bool parameters are calculated at compile time so they cannot be turned on or off from a blueprint, but can be controlled from a material instance, just keep that in mind if you were planning to control values in a BP. The only way around limitation is to use lerps, and using only 0 or 1 as a value, however method does not reduce the instruction count, it will calculate the instructions for everything in the network, which is not ideal (at one point I was up to 1150 instructions).
Also try using a Static Bool parameter as the input value to a Static Switch (non parameter switch) for a material instance, way the instruction set should reduce when you turn it off, I was having issues with the switch parameter as well, so give that a try and see if it makes any difference.
As far as increased instruction count there is not much else you can do except split up the material if the difference is significant that I am aware of, if you have a lot of switches it might be best to create 2 or 3 materials.
I have 9 switches so far, and I was planning on adding at least another 3. 2^12 is 4096. But I’m only going to make 50 presets with material, and some of them do share the same settings. I use them for scaleability, and I do have separate shaders and stuff embedded into one material, so you get a lot of mileage out of it. And I find it much easier to simply toggle the features on and off to see what changes they make automatically through instances. It’s very easy to use. But thank you, glad to know it doesn’t make the final compiled material more expensive!
Also, it seems the inflated numbers are what’s used for calculating static lighting. I assume means using precomputed lighting makes the materials more expensive, as the indirect lightmaps get embedded into it. For some reasons the instances don’t show in their stats. The instances also don’t show the release stats either, which is kind of annoying
Whoa, whoa, no, these parameters are meant to be static! They’re for scalability settings and stuff. The system I’m making is supposed to handle tile generation, but it includes a glass tile shader, dual color algorithm, and a simple falloff occlusion that does add instructions, but is much cheaper than relief.
Also, what material are you making that costs 1150 instructions with 100 parameters?! That’s insane! I think altogether my material has 28 parameters, and the lighting model can be changed, and I think that is overtly excessive!
It’s my ocean material (see the link below), each wave is calculated by a function with 4 different parameters, then added together in another function for 8 waves in a set, using 4 sets put me up to 1150 instructions (with 140 parameters), along with all of the other parameters for color, normals, etc. I have since reduced it back to 2 sets as it was starting to have a noticeable reduction in performance, right now I am at ~650 instructions for dynamic lighting, ~100 params.
Some of these values will be hard coded eventually, but I need to be able to make adjustments without re-compiling the material, so I spent some (long) time making parameters.
is the most recent video of it, but a lot has changed since I posted it, foam was added, depth fade fixed, many small changes, need to update my thread soon. If you mean an image of the material nodes, I don’t have one right now, but I will be adding it to my thread with the new update (in a day or two).
Wow! Looking good! I’m sure you have a parameter to run the waves faster
Also, I would look at the possibility of using texture maps or vertex painting to make the waves larger with sharper crests as they reach the shore. It’s a small detail, but it could look really nice with everything else you have going!
You bet it can run faster, that video was before I added in the time multiplier, they will go as fast/slow as you like. The steepness of each waves is adjustable, but I have been playing around with vertex painting as well. I have already added in whitewater/foam once the wave reaches shore (or an object in the water), but still more work to do. I hope to have an initial version of it released in 2 weeks (it will be free).
