Currently if I use Matinee or even Blueprint to slow down the panning speed in my material, the material goes crazy, like the panners are resetting all the time.
I want to set it up so that my waterfall object will freeze up over time, but currently can’t seem to find a way to do it 
On top of that, Matinee really needs an overhaul. I can’t change the material parameters of any static objects, it refuses to add the objects to the timeline, kinda sucks.
What do you mean you can’t change the params of static objects? Are you talking about creating a blueprint object and then changing material params in there? The best thing to do would be to set up a material parameter collection. This is a global array of params you can add to the material and change via blueprint. It was what I was after for a while. Works like a charm 
I’m trying to change the properties in Matinee, not blueprint.
I found the cause of the previous issue, which I’ve now resolved. The problem is however, you cannot modify ANY property of a blueprint which is static, or has a static element in it. Matinee won’t allow me to add a track for that actor.
EDIT: Okay got it, thanks for the tip on Material Param Collections. Turns out I need to create a dummy blueprint actor and just place it in the level somewhere, it’s sole purpose is to change param values. Interesting! Never looked into these before…
The material param collections are very powerful. You can pass your level’s directional light rotation, color, fog etc to all the materials in the scene without them needing to be blueprints or ticking. Just one blueprint needs to gather the info and pack it into a collection. Very useful for many vertex shader things or toon shading without postprocessing.
About your original problem with using matinee to slow down time: There is a mathematical reason for that and it’s not technically a bug per say, but that you can’t really multiply the speed of time by a value to change the speed of time going forward. What you end up doing is going backwards in time and experiencing jittering because the frac component of time repeats over that interval. That’s because time is actually a huge number that keeps growing as the game runs. Most functions only care about the fraction of time though. When you multiply time, you are not multiplying it down from a relative now but from the origin, or 0. So if somebody were to suddenly “slow down time” on us right now by multiplying the value of time by 0.9 or so, it would actually “slow us down” from the origin of time (big bang or whatever), not relative to what we are doing at the moment. So we’d suddenly be back in time millions of years instead of just being ‘slowed down’. Does that make sense?
What I normally do in this case is Lerp (linear interpolate) to a manual value for time just before I need to control the speed of something. Then you are using matinee or a timeline or whatever to control the literal value of time. That ends up working much better than trying to control time directly.
It is easy to fix popping issues by just waiting for time to hit the 0 fraction before doing your manual fade.
You could also get more advanced within a blueprint by capturing the initial time then getting deltatime each tick and adding a compounding fraction of that to come up with a slowed down time value. You could even suddenly replace the value of time a shader sees using a lerp that flips alpha at the same moment. But a timeline curve should be plenty for a material. So many different solutions
Thanks Ryan, I understand why now, I guess the ‘Time’ node in materials isn’t quite what I think it is I’ve done something similar to what you suggested, my ‘Time’ parameter just increments every frame, based on the water speed * delta seconds, then re-updates the material. What I can then do is animate the water speed value over time in matinee and slow it down on the fly.
Screenshot for others:
Looks good! Just keep in mind you wouldn’t want to be doing that for tons of objects in your scene if this is a full fledged game project as you’d be ticking and updating tons of stuff constantly which is slow. If you wanted to do this for lots of objects you would want to create a branch on the tick that checks to make sure the panner speed is actually changing before swapping to the manual time. Then you should use the regular time node in the materials when the rate of change is constant because that is much faster.
You could also create a material parameter collection of your own modified time values to have only one blueprint do all the ticking work and distribute it to a bunch of materials for practically free.
Ah I see, so this is a more expensive method than modifying a material instance? I guess I could also use a static switch to flick between the two times as well provided the object isn’t in view at the time, making it cheaper again. I have a few objects in my scene doing tick-based updates to the material via blueprint. Is there a better way to do it?
Well, technically it is modifying a material instance. But its just that you would be modifying the instance every tick for every object that does it. We normally try to avoid updating a bunch of MIDs every frame unless it is explicitly necessary. The more blueprints doing stuff every tick you have, the slower the game thread will be, and updating MID’s every frame has its own additional cost.
If you are always changing the rate of time there may be no avoiding it, but you could try to simplify the problem by having a timeline for your own repeating version of time that varies as you want, and then trigger to a custom ‘event-base’ time change timeline at at the nearest whole time value interval. Without knowing the exact usage case or how many of these things you want in your scene it is tricky to recommend the right approach. Technically there is no right approach as long as you can get it to behave how you want. You could always just ignore that for now and later optimize it if it becomes an issue. I just try to prevent performance issues before they get too bad these days because it is so easy to ‘go nuts’ as they say and end up with way too much optimization work at the end of a project.
Edit: your idea about switching from the two versions of time would work, and I don’t even think you have to keep the object out of view during that. You just have to do the swap when the first version of time hits a frac of 0 and start your timeline version of time also at 0 or a frac of 0. Should be really easy to wait for that in your blueprint and switch times at exactly that moment. No pop.
For those who dont want to read heaps of convoluted information. Here’s how to do it.
Set it up your speed variable as a “ScalarParameter” in your material editor. Multiply it by time, and add it to the time node of the Panner.
Open the blueprint you want to use this material effect with, then Select your panning material.
In your blueprint, go to the construction Script area, and “Create Dynamic Material Instance”. From this node, set the dynamic material instance to a variable (I called it “Pipe Material”). From that node, you should apply it to each mesh in the blueprint that you want it to work on.
In your Event Graph, drag in your dynamic material instance variable (which I called “Pipe Material”), and from that node, choose “set Scalar Parameter Value”. Set the “Parameter Name” to the name of the scalar parameter within your material (in my case it is “PanSpeed”).
You may now edit this value with timelines, or any other method you choose. See screenshot for how I edited it with a timeline.
Thanks man, that’s much faster … though I’ve read through everything then saw your post