I am trying to get an understanding of how the Time node in Shaders work.
What I want to do is change frequency of my Sine node for a varied output during runtime. It seems like I can’t control the “Period” value of the Sine node through dynamic parameters.
Therefore, my only option is to multiply the “Time” node feeding into the “Sine” node to vary the frequency. Example Below:
However, this causes a few issues. When I try to update the “PulsingRate” parameter shown in the image above (multiplier of time) inside of a blueprint, the effect visually breaks during run time. Basically the longer the game runs, the “faster” the pulsing becomes regardless of the value being set. So event if it appears to be working correctly at start of game, the pulsing will gradually become faster and faster.
To make things more confusing this multiplier only seems to make things worst if the value gets adjusted during run time. If I leave “PulsingRate” to what it started as, then the frequency will stay constant.
I did get the effect to work by creating a “FakeTime” parameter that I manually update in BP when the pulsing needs to happen. While it works, it doesn’t really solve the original issue. It’s more of a work around.
If I need to update the “PulsingRate” parameter in BP, I use fake time, otherwise I use normal “Time” node.
For Fake Time node, I have a simple delta seconds increment counter that goes from 0-DesiredTimeAmount and updates the shader value every frame. It restarts from 0 whenever the pulsing needs to be enabled.
It seems like since the multiplier is creating fraction and time always moves forward, those fractions end up getting bigger and bigger. Perhaps that plays some sort of role in getting a different value from Sine?
Ah that makes sense! For me, I ended up creating a Timer component that resets every time I need pulsing to start (similar to you doing Game time subtractions).
Since I go back and forth between pulsing needing to start, speed up and stop, it works in my instance. Knowing Time will always start at 0 helped me create more control over parameters.
I’ve accepted your suggestion as the answer since it seems to be the correct way to approach the problem! If Time needs to be altered, it needs to be accompanied by a BP.
The additional understanding I have now is that if you multiply time by an unaltered value, the scale of time is uniform so it just looks like it’s working faster.
However, as soon as you gradually alter that value, the fraction of the incrementing time become more complicated to handle. For this reason, it visually looks like it’s broken. Easiest way to combat this is to create your own time!
