Dust wake caused by proximity of moving object

Hi,

I’m trying to set up a simple sim that reacts to a sphere moving just above the ground, and just through it’s proximity kicking up some dust (not through impact). Sort of like pushing a little wake in front of it
I have been experimenting with the W_FiniteDifference node creating gradient vectors of the sphere, scaling those and using them as velocity guides, but it doesn’t do anything that way.

Do I have to use a collider that precedes the actual geometry or can this be done based on vectors alone?
Any tips?

Cheers,
frank

Hi frank,
You will need an e_collider with the velocity of the object connected to the vel input on the collider. How are you emitting the ‘wake’ ?

Most of my similar setups have involved an impact/emission as well, so let me whip up an example like you are describing to sanity check.

Hi Matt,
when I drive things off collision tit all works fine.
I’m just curious about a setup that basically works based on displaced air rather than collision.
In my test I just have a narrow E_cube setup like a bowling lane producing the initial density, and an animated sphere moving just above it.
Another more obvious example would be a helicopter landing and kicking up dust before it’s even close to the ground.

I’m trying to figure out the most generic setup though, so one that takes into account speed and direction of the object and proximity to surface, hence my approach with gradient vectors.

Cheers,
frank

Ok no probs.

The E_FiniteDifference can be used to make a velocity field. A E_sphere into E_finite difference into E_Emitter will make a spherical force for example. I usually use this for adding velocity on top of a performance, to stylize it, and I try and be subtle as it can over-influence your simulation easily.

As far as it being calculated correctly, taking into account speed/direction/proximity I think you would need to use E_collider for that, and let the solver do it’s thing. Would love to hear any optimization tricks from the devs though so I hope i’m wrong. Mesh to volume and colliders are difficult sometimes!

cheers

Thanks. When using colliders I’d have to expand the volume derived from the mesh so that it actually collides. However, with a fast moving object you’d want the preceding dust wake to kick in quite some distance away (along it’s velocity vector). And expanding a volume by subtracting a value from it’s SDF might not work very nicely when you have to expand it that much, right?!

Thinking out loud:
It’s a bit like a projection, where you’d want to figure out the intersection of the ground and the objects’ (extrapolated) motion vectors, and that intersection becomes the initial emission area, but you’d also have to take the moving object’s size and shape into account, hence I though using the gradient vectors from the FiniteDifference. The initial velocity should also be coming from the moving objects velocity channel, probbaly with a fair amount of turbulence introduces, but that part is easy.
Now, how to translate the above into Eddy nodes… Seems like it should be possible, right?!

To my understanding, the vel input of the collider should calculate the movement and precede the movement by default, without modifying colliders. Depending on timesteps i guess.

that would make it easy. will try…

I think I got it. If I add the gradient to the velocity and amp up both I am getting there.
Will post a simple setup soon, it looks fun

Here is a result purely based on velocity and gradient vectors (multiplied a lot for additional fun):
wake_test.nk (10.7 KB)

1 Like