Hey,
I am new to this forum, so please bear with me if this question has already been asked. I used the search function but could not find a relevant topic.
To my question:
I used Stoke to create a particle-animation of an hurricane based on satellite-data. No problem so far.
Next i wanted to use Frost to create an arrow for each particle where the lenght and color information comes from the Stoke-generated particle-cloud. That worked without problems as well. Problem is that I can only scale the arrows but not actually deform them as the move a long their way.
I was wondering if it is possible to get a similar effect as using a PFlow with a Path Deform Binding Modifier, so that the arrows bend while the move forward.
I tried to do a Stoke animation, convert the resulting particles to lines and use them with a new PFlow event… but I would have to create a new PFlow for every line (I have a few thousands) … so that did not work out for me.
I know that the Stoke particles actually do not follow a line, but get their position information out of a velocity field, so Frost does not know how to bend my arrows… but perhaps someone knows a work-around?
Deformations are based on moving vertices around. However, in this particular case, it would be nice if the deformation was localized to each arrow individually, without the chance of two arrows close to each other getting distorted because their vertices happen to be in a proximity of some local field area that points elsewhere…
So I hacked something using a pre-bent animated arrow, and just dialed the right timing using Magma based on the change in the Velocity vector over time.
Here is what I did:
I created a Stoke Field Magma with some VectorNoise field as Velocity (I made it 2D with Z component of 0.0, so all motion is in XY space)
I simulated a 1000 particles emitted on frame -1 using Stoke Particle Simulator and the Stoke Field Magma as the vel.source
I created two PRT Loaders from the Stoke sim - one set to Offset 0, one to Offset 1 (reading one frame ahead)
I made a Frost from the first PRT Loader, set to Custom Geometry, and picked a custom arrow mesh I made.
I set the Orientation to Velocity.
On that Arrow, I added a Bend modifier and animated it from -180 degrees to 180 degrees over 101 frames.
I added a Magma modifier to the PRT Loader used as source of Frost, and set up a flow where I calculate the Vector Dot product of the normalized Velocities of the current PRT Loader and the offset PRT Loader. The Dot Product is 1.0 when the two are parallel, 0.0 when they are orthogonal to each other, and -1.0 when they are parallel and pointing in opposite directions.
I also calculated the Vector Cross product and used the Z axis sign to multiply the Dot Product by either 1 or -1 as it changes (to determine when the vector is bending CW vs CCW).
I subtracted the Vector Dot from 1.0, so when it is 1.0 (parallel vector), it produces 0.0. When it is 0.0 (orthogonal), it produces 1.0. I assumed that a velocity would never change more than 90 degrees over a single frame, so no precautions for negative Dot Products.
I scaled by above result by half of the frame range of the arrow animation (50), and offset by 50. So when the Dot Product is 1.0, you get (1.0-1.0)*50+50 = 50, and the arrow is loaded with no Bend (middle of arrow animation). When the Dot Product is 0.0, you get (1.0-0.0)*50+50 = 100, and it loads the +180 Bend arrow. When the value is multiplied by -1 due to changed direction, it loads from the opposite side, from 50 to 0 to bend CCW…
I added a multiplier to boost the effect as the angle between the two velocities is in fact tiny over a single frame.
I output the resulting value as GeomTime channel
Then I switched the Frost to use Base Time 0 and Offset Time from GeomTime channel. This way, each arrow loads a pre-bent mesh from the frame specified in the GeomTime channel.
The result is quite convincing, despite being driven by the change in velocity direction and a pre-animated bend instead of by deforming the actual Frost vertices by the actual field. The latter might be possible, but it would be rather complicated… STK_BendFrostArrowsByVelocityField_v001.zip (51.1 KB)
Attached is a Max 2015 version of my 2017 scene. You must re-sim the Stoke Particle Simulator, and re-point both PRT Loaders to its cache data.
STK_BendFrostArrowsByVelocityField_v001.zip
I tried a more advanced, 3D space version, but it is a bit more complex.
Basically in addition to the Velocity field, I also made a Curl field from the Velocity field.
Then in a Magma modifier on top of the Stoke driven by that Velocity field, I sample the Curl and build a new Orientation based on the VectorCross product of the Velocity and the Curl, the Velocity itself, and the VectorCross of the Velocity and the other VectorCross. The Orientation is then applied to the Frost particles and ensures that the arrow mesh is always oriented according to these two vectors (so it flips when it changes from CW to CCW rotation). I then took the Magnitude of the Curl field and used it to define the GeomTime. This time the arrow had only one bend direction, from 0 to -180 degrees between frames 0 and 100. The result is that the arrow is always pointing in the direction of the Velocity, and is bending about the axis defined by the Curl vector field, and the longer the magnitude (the higher the curl value), the more it bends.
If your field is mostly in 2D space, the previous solution is probably easier to grasp.
Hi Bobo,
thanks for your fast reply and your detailed explanation. Your Max-File seems somehow corrupt and couldn’t be opened. No problem as you explained very well what you did. It took some time to understand everything… and to rebuild your magma flow. We changed it a little bit and added a curve… I will show you tomorrow as I am writing on my mobile right now…
We still have a problem with the cloned and shifted prt sequence… Adding no offset to the cloned prt sequnz shoul result in a vectordot =1 but it does not always… somehow… when the first particles are dead things get messed up… as if the magma flow starts to compare the velocities of wrong particles…
I will come back to you tomorrow with a better explanation and will also try your second solution… our simulation is more 3d then 2d…
You are correct, when both PRT Loaders have the same time offset and PRT sequence, their particles should be completely in-sync and produce a dot product of 1.0 everywhere, since we are using the Index channel of the one to query the other.
The approach will NOT work if there are particles being born and dying, because the indices would go out of sync when you set the offset of 1.
You could work around this by using a NearestParticle operator which would generally find the matching particle in the offset sequence. If the particle it finds is farther than some tiny threshold (based on how fast the particles move per frame), you could assume the Dot Product value as 1.0 instead of calculating it.
