-
Trapcode Particular – End of Motion Path behaviour
Hi, I’m hoping to get my particles to freeze or ‘stick’ to their position after travelling along a motion path. I need the life of the particles to continue after they have travelled the path, but I need them to freeze on completion of path. My particles don’t freeze at the end, but instead disperse based on the emitter settings. I need the velocity turned up to gain the cone shape that the collective particles make. I’ve tried creating a child particle system with a static version of my particle (type sprite) emitting on death of parent particle, but unfortunately there doesn’t seem to be a way to inherit the parent particle’s rotation value which is critical for what I need.
-
4 Replies
-
good evening Job, here’s 2 solutions for you:
Core solution (single system, no Aux)
Emitter → Motion Path
Animate Position along the path as usual.
Particles → Life
Set Life long enough to extend past the end of the path.
Physics → Air
Velocity: keep high (for cone shape).
Velocity over Life:
0–90% → 100%
90–100% → 0%
This ramps velocity to zero exactly at path completion.
Physics → Air
Gravity: 0
Wind X/Y/Z: 0
Turbulence Field: disabled
Particles → Rotation
Rotation Random = 0
Spin = 0 after arrival
Use Rotation over Life to lock final orientation if needed.
Result:
particles travel the path, then mathematically lose all velocity and remain fixed in world space while staying alive.
Alternative solution (hard freeze using physics switch):
For absolute zero movement:
Duplicate the Particular layer.
First layer:
Normal motion path travel.
Particles die exactly at path end.
Second layer:
Emitter disabled.
Layer Emitter using the first layer.
Physics → None
Particles spawn already frozen, inheriting position and rotation.
This avoids Aux inheritance limitations entirely.
-
Trapcode Particular has changed a TON since that tutorial came out. There’s actual wind and air physics now. Motion Paths are now like a displacer (as is the old wind [now called Drift] and the old turbulence field) where they push off from wherever they would be naturally based on their physics settings.
Anyway, that doesn’t help you – it just explains why things may be a bit different now. If I were doing this, I’d make the lifespan of the particles be roughly as long as it takes them to move along the line and then have a new system spawn from the old system “at parent end of life”. (Spawning just one particle and inheriting the size, color, opacity, and particle type from the parent). It’ll look like the particle didn’t die, but just stopped moving.
-
Thanks John, but unfortunately these solutions don’t address all of my requirements.
-
Thanks Michael, that would all work (and I’ve tried this approach) except that it has a few limitations. I don’t believe there is a rotation over life setting which would quite possibly solve much of my issues. To give context: I’m creating a 2D video to map onto a 3D hemispherical LED display. The 2D video needs to be square shaped to map onto it correctly. The mapping of the 2D video onto the 3D hemispherical LED is such that the circular area that fits inside the square video will be the only part displayed on the LED. The video is to show different coins (about 10 x different still images of stylistic coins – these are the sprites) falling from the top of the hemispherical display, and slowly filling it (building up the sides until it’s full). How this translates, is that in the 2D video, the coins need to fly out from the center (rotating randomly as they fall while still facing the camera), then ‘bounce’ as they hit the top of the pile (noting that the pile is continualy growing – ie. getting closer to the center of the animation), then come to rest. The resting positions of each emitted coin grows increasingly closer to the center where they are being emitted from, until the comp is taken up by resting coins (from the 10 x different coin image – sprite – options). So in effect, I have 3 x different states that my sprite particles (coins) need to take on during the animation: 1. Rotating (as they fall / move out from the center emitter); 2. a bounce animation (as they land – start frame needs to match final rotation of falling coin); and 3. the final rested position (still image that matches the last frame of the bounce animation). The sprites need to stack behind eachother as they pile up too – not in front. Because when transposed onto the hemisphere, coins that are in front of lower down coins should slip off the pile in reality. I’ve been able to create almost what I need by having an emitter with direction set to ‘disc’. Emitter slowly moves away from the camera (to get the layering correct) with ever decreasing particle life (to have them finish closer and closer to the center). A secondary particle emitted at death of parent creates the rested coin. With the rotation of falling coins (parent system) set to follow particle motion 100%. Problem is I can’t match the rotations of the 3 x stages mentioned above. There is a set rotation angle that each coin needs to finish and rest at (because there’s individual drop shadows on each coin which always need to be offset outwards from the center of the comp.
Reply to this Discussion! Login or Sign Up