well i dont see anything on that tiny chart either… u have to look at the ms counter for the gpu on the right hand side of stat unit.
And its technically a dynamic parameter for a material instance… i moved it back and forth without saving the material instance… and it dynamically adjusted the performance.
doesnt spike for me… and if it did how would u see it… look at that red line at the bottom… if it did spike it would spike 1 pixel on your monitor… barely noticeable. Check the ms counter really quick for the gpu and see if any difference.
It’s 1281 instructions in the noise branch. How many would be a valid test? Because I can just keep adding more, I promise you the result isn’t going to change.
I mean maybe it behaves different for texture samplers, I don’t know, I honestly don’t care enough to try and test it because successfully branching in one synthetic test case isn’t very helpful. I’ve never seen this work and the generated HLSL code indicates it shouldn’t work. You’re the first person I’ve seen to say it does, and honestly shaving 2 tenths of a millisecond off a 1300~ instruction material isn’t very convincing, even on a 3090.
This is what I would expect to see when dynamic branching actually works:
This is what you get with all the branch logic inside of a custom node:
(Please forgive this code, I’m not a programmer or a tech artist, just a regular artist)
My opinion is still the same as what I said in my very first reply: Don’t expect it to work unless the code for the branches is all inside a custom node.
perhaps my graph would bounce more if i had that many instructions. I just have no idea how to get my instructions that high… it seemsl like adding 100 mults doesnt add 100 instructions for some reason.
Is there a way to zoom in on that stat unitgraph… or shring the values so u can see spikes? I kinda see my yellow going up and down on the graph but the graph is so small its barely noticeable
in general, when compiling-down, something ‘simple’ like a multiply can be nested so even a dozen calls to multiply something can be run as one instruction ala: mul(mul(mul(mul(x,y), 1), 2), 3) etc…
specific to this case, one can often swap out a power-function, which is ‘expensive’ to just load, let alone execute, vs chaining a few multiplies. IMHO, if you aren’t powing something 10’s of times, just multiply it out. At least this is my understanding, not all functions on the GPU are equal in cost.
This guy notes specifically that the if node (which is the “dynamic branch” node) does not actually branch and he demonstrates it in the video. His “working” branch is using an if branch inside of a custom node, but I cannot reproduce that either. For all I know, it works in some cases, I don’t know. Regardless, it’s clearly unreliable.
His result is also very strange, because his GPU time drops when it takes the cheaper branch, but his performance is still extremely poor (69ms to return a constant??) so I really don’t know what to make of this.
By the way, according to the documentation the entire reason why Volumetric Cloud materials have a conservative density output is specifically because the material editor doesn’t support dynamic branching:
Anyway I don’t really know what else to add here. If you think you’ve managed to get it working all I can say is more power to you. Based on what I have seen in this thread though, I still won’t be branching for optimization outside of a custom node.