Hello guys!
I got myself into another problem. This time I’m trying to change the speed of animated clouds. To animate them I’m using panner for uv. After a few days of experiments I managed to build some basic working prototype where I’m using blueprint with Dynamic Material Instance and changing parameter value, that serve as a multiplier for the time, with the help of a timeline. Right now I have test collision volume to see how this behavior works and I’m experiencing problems with it. When my character starts overlapping the volume, clouds starts to accelerate. On End Overlap event plugged into Reverse input of the timeline and when I’m walking away from a volume clouds does not just starting to slow down, but rather they going backwards until timeline is finished and then they continue to flow in the right direction with the initial speed. My best guess is that is happening due to negative acceleration. But even if I’m right - I don’t know what to do with it. Obviously I need them just to slow down without changing the direction. That’s why I’m asking for your help!
share the BP logic for the timeline. I think it may be just an issue of where you plugged the executes to.
Also, a vid or gif of what the material scalar does would help - just increase decrease the scalar and show us what the clouds do when panning.
Obviously if they go backwards when lowering the scalar (which they likely do) you can’t reverse the timeline.
This is my setup:
And this is how I tried it on default sky sphere (results are the same):
Material Scalar is remapped for more convinient control and simply muitiplied by the time:
That actually looks OK.
In the first one you showed, you are using a color for setting the parameter though. This isn’t reflected in the material you showed.
The cloud speed material portion of the default sky-sphere seems Ok.
Personally I think you should remove the remap as it’s a set of useless instructions(overhead) on a materiel that provides you with no benefit what so ever.
You don’t gain any extra controls as you are limited to the amount of decimals of a regular float anyway:
lerping the value from 100 to 1 (so you have a possible value 99.99999) will result in the same exact effect as lerping a value from 10 to 1 (so you have a possible value of 9.99999) on the actual material. Ergo the extra instructions add needless computational times - and that’s all they do aside from having a “pretty” looking variable, if there can be such a thing.
Regardless, the setup works.
The timeline looks Ok too, but I think the bigger issue of your setup is that the current cloud speed isn’t being accounted for at all.
You need to read the value from the scalar parameter, and use a Lerp driven by the timeline to set the new parameter so that you can then start and rewind the timeline.
Open up the timeline and add a screenshot or tell us the time parameters you are using so we can test the same setup if you still have issues.
Also, before all of that or any changes, check your parameters and if the timeline is set to loop or not
And that the Length of the timeline matches what you set the variables to.
As far as just making a simple timeline with values from 1 to 10 the play and reverse work as expected.
Thank you for all your suggestions! I really appreciate your comments about optimisation and I’m looking forward to trying this learping idea!
You were right - on the first screenshot I’m doing the same logic only for the Speed input of the panner, instead of the Time (by using vector parameter to control x and y speed). But regardless of what is that I’m trying to affect through multiplier (Speed or Time) - I’m getting the same behavior. Timeline length and keyframe looks correct, no looping or anything out of place I believe. I’m spreading the transition between 60 seconds at least with first value being 0 at 0 time and the last value being 20 at 60 seconds. I think it helps to smooth blending at the beginning and at the end due to flat tangents that slowing down acceleration. When it’s happening let’s say over 10 seconds the acceleration slow down becomes very noticable.
Ha, but that’s the nature of the curve you are using.
Since it’s an actual curve and not a linear value, by 10 seconds the acceleration of the parameter is somewhere around (60/20)*10 but not exactly that since the curve is cubic.
Likewise between 45 and 60 the speed will slow down.
Try a linear curve and see if the speed of the clouds remains constant or not.
Another issue, the cloud panner default value is usually 1.
A speed of 0 stops the clouds from ever moving.
All that said, the same setup as yours presents the same issue. this is because the material is not being updated.
this is because the blueprint is updating Cloud Speed back to the default value. This can be easily fixed by updating the variable CloudSpeed along with the material value.
The other issue is the default implementation of the panner node.
The node has a coordinate, a time, and a speed.
The default implementation is only multiplying time X speed and setting that as the Time with a fixed speed - thus causing the reversal of the current position when reducing speed.
to fix it you need to properly modify the material.
First of all remember to make a local copy and not to modify the engine file.
Second of all. The reason it loops backwards now that I think about it is that when you change the speed you loop back in time - no matter what.
If the time is 100 seconds right now, and you change the speed from 1 to 10 you jump 100*10 seconds ahead, and if you change time back to 1 you jump back to 100 seconds.
This is why the clouds rewind essentially.
To work this you have to implement (add it to the update sun position) a manual panning.
For the manual panning you simply append CloudSpeed to 0, add it with TexCoord and feed it to the UV.
Now you have a speed value that is not always panning bust just controls the position of the texture.
This variable is really valid only from 0 to 1 - meaning you can exceed 1 and it will pan, but the range 0 to 1 is a full “loop” of the texture.
so now you need to go back to BP and implement a manual update of this value per-tick to make the speed of the panning a factor of game time instead of using the material which you cannot control.
to do that, I would think create a ManualSpeed variable, if = 1 then set it back to 0, and lerp it time * speed… here pictures.
Proof Of Concept:
Material:
Blueprint Tick Control
Speed Control
Unfortunately there is the overhead of the Tick Event for this to work this way.
But as you can see, because the value passed onto the material doesn’t have anything to do with time, the texture doesn’t “rewind”. which I suppose is essential in any time dilation effect that doesn’t directly manipulate game time.|
OFC, I hope you are aware that SetGlobalTimeDilation would be better suited to speed up time if you need the day to progress.
Yeaahhh…Well that’s not intimidating at all! 
But honestly you are so good at explaining things about that engine to someone like me, who has little to no experience with programming and with that kinda logic.Totally got this rewinding paradox due to Time involvement. Also I tried a different curve shapes with more steep roundings to minimize the acceleration fluctuations but plane linear didn’t feel that good, because there were obvious speed change jumps. When I was experimenting before posting here I indeed tried to ADD my value to the Time in order to get smooth results, just didn’t know how to do that constantly increasing my adding value (apparently multiplying it with a tick first) but later I found out that low values works with multiplication just as well. BTW this whole remapping thing was taking care of this 0 value at the beginning by changing it to 0.1 
And it feels kinda sad that because of this overhead. It seems like a good idea to have a control over the clouds speed because they behavior depends on the wind speed, not on the game time speed, right? And how about all those dynamic weather systems when you can have nice calm weather that can quickly change into a storm with a heavy wind that will move the clouds really fast? You won’t do fast forward in time for that! Also this approach might work fine with the default sky sphere and change the rotation speed in one direction but my clouds are floating above the head and could be oriented in desired way. Does that simply means that I need two speed variables to append with aTexCoord and it will be good to go? (At this point it feels like the best way will be to make a sphere mesh and just rotate it without messing with a panner at all). And the last thing I’m curious about: will the wind actor help me to set the initial vector for clouds movement?
Hum… lots of questions.
Wind speed is a part. but also game time is a part. If you speed up game time the wind would move faster as well - yet you don’t want the time passing to turn into a hurricane, so usually the wind is kept constant.
if your clouds are only driven by wind, then they will remain constant as well…
For dynamic weather systems you just deal with the overhead. Usually it’s a main aspect of gameplay, so you bite the bullet and do what you can to maintain a decent amount of memory/fps.
Usually though, the systems are built entirely on one blueprint/actor what have you, so that if you need a tick event to run there’s only one and it controls everything.
generally different functions within it allow you to call it in place from within the level blueprint.
You can take apart the skysphere as an example. It is essentially a small dynamic system that works through function calls and by looking at other items that are specified as variables (the light source).
There are a multitude of reasons to make your own unwrapped sphere instead of using the engine’s default.
for one, a custom made sphere will allow proper UV mapping of textures you want to use.
Secondly, you can add different UV channels and do different things with the materials and custom UVs.
I have done this before for instance, to implement the NASA star map in 8k as the stars.
I have also made the sphere rotate instead of the material so that the revolutions match the day time exactly without any panner nonsense… and it works much better since it’s less math.
In fact, you can actually use custom rotators in blueprint and change the speed at which they spin without too much trouble. (And the on tick event for those is ran by the engine so I’m not sure if you get a benefit or not, but in the end it’s a pretty simple operation).
The wind actor you could pass in into the new blueprint as a variable and just read its values right into the on tick event that runs everything.
So yes. You can make the wind direction and intensity be driven by the wind actor and affect your custom blueprint with a little work.
It is time consuming, but in the end you can use it as a learning excuse to get some blueprint communication basics in your hat…