vector direction in cloud animation

[Dune]

Am I correct in assuming that if you set a constant vector of minus X in this setup, that the cloud is actually moving positive X? Positive X is to the right (more or less), btw. Looks like it, but I don't understand why. Can anyone explain?
If that's the case; for a downward movement of clouds, I would expect to need a positive Y as vector.

[Matt]

Does this go into a warp shader? Warp is achieved by offsetting texture coordinates, so it reverses the apparent direction.

By the way, you can eliminate 9/11 of these nodes by simply plugging Get Frame into a Vector Displacement Shader. You can control the velocity in there. Breaking this down into optimization steps: First, converting to colour and then to red, green and blue is unnecessary. You could simply extract X, Y and Z scalars from the vector. Second, the Redirect Shader is only needed if you are starting with individual displacements for each direction, instead of a complete vector. But you already have a vector so you can go straight to a vector displacement shader. Third, the multiply vector isn't necessary because the Vector Displacement Shader has parameters to multiply the incoming value, so you can simply plug your Get Frame Scalar into it.

[Dune]

Yes it does. That explains it.

And thanks for your advice! My thinking hit a ceiling apparently. This setup wasn't mine, btw.

[Dune]

So this should be working. Setting the final multiplier by 1/frames/second and inverse function gives a m/s cloud warp speed in the XYZ inputs. Is that correctly assumed?

[Matt]

So this should be working. Setting the final multiplier by 1/frames/second and inverse function gives a m/s cloud warp speed in the XYZ inputs. Is that correctly assumed?

I think that's correct.

[Dune]

Thanks!

[Hetzen]

If you divide the Get Frame number by your desired frame rate, say 30 for 30fps, that will translate as taking 30 frames to move 1 meter, so you don't have to put in fractions in your final multiplier in the Vector Displacement node.

It's essentially similar to what you've done, except it should make your numbers a little more understandable.

That said, the 1 m/s only holds true if you're only moving in one axis. You've got the cloud moving in X,Y and Z. If you truly want the clouds to move at 1 m/s in a combination of X,Y,Z directions, you'd have to get into some Pythagoras. 

[Dune]

Thanks, Jon. I understand. But that's why I set the multiplier to that 1/frame rate, and inverted the function to get 'clean' meters. And you're of course right about Pythagoras, but it's no rocket science, luckily The only thing is that it's hard to imagine natural cloud speed.

[WAS]

This is a pretty cool method, I'm going to have to keep it in mind.

The only thing is that it's hard to imagine natural cloud speed.

I'd imagine there is no uniform speed. Which is why we get clouds breaking up, stretching out, etc, different air densities, drafts, etc. Which a PF could probably achieve with Redirect and different intensities for XYZ, X being your prominent force.

[Dune]

The Y movement will move the fractal itself, which kind of dissolves and creates cloud in the layer, so that would probably be enough for a natural look (with a decent speed). Plus some sideways movements from the main wind direction. I would think simply an extra fractal between get frame number and vdisp gives it some extra stretching and moving. Or indeed that redirect with some fractals.

[Tangled-Universe]

The only thing is that it's hard to imagine natural cloud speed.

Yes true.
1 m/s = 3.6km/h.
I don't know the scale of your clouds and how close they are to the camera, but in normal situations and assuming a relatively short animation (<30 sec or so) I think a speed of 1 m/s is difficult to notice(?)

[Dune]

We've set it to 2m/s now (X), which has a realistic, but visible effect.