Stoke Particle Radius and Laziness?

hi all,

the Stoke particles always seem to start really tight near the main emission particles… is there a way to expand the radius or randomize the radius?

also, can we have controls to affect the laziness of the Stoke particles so they do not quite follow their main particle so well?

we are hoping to get the Stoke particles to mix together sooner instead of needing a lot of main emission particles nearby to disrupt/advect them into cool streams…

thanks

If you are seeding new particles from an existing particle source, there is a jitter option. Select the source on the list and the appropriate controls will appear.

Can you post a simple animation that would illustrate what laziness means in this context?

An illustration of this would be helpful for the conversation too. What combination of particle generators and velocity fields are you using? My guess is you are using particle sets as both the emission and the velocity and you are finding the velocity isn’t affecting as large of a region around the original particles as you would like. The generated velocity can be controlled by increasing the Grid Spacing parameter in the Velocity from Particles section of the UI.

sorry for the late reply…

yes - was using the same system to emit and distort. Will try the jitter option, thx.

for “laziness” was thinking of a drag force or velocity variance… but will check RC1 and try some more approaches…

There really are no forces in Stoke, only Velocity Fields. And the Velocity Fields can, but must not be, history-dependent continuous streams.
So while the resulting particle motion is history-dependent (Stoke creates and advects the particles over time and tracks their IDs and positions), the particles don’t have their own Velocity. They do have a Velocity channel that reflects the resulting value of the Velocity Fields applied to them on the current frame, but that Velocity does not persist between frames. If you remove the Velocity Fields influence on any frame, all particles stop.

If you have a narrow FumeFX simulation where the velocities are high at the borders of the grid and you try to use PFlow with FumeFX Follow, some particles will come near the borders and potentially escape the influence of the grid. Those particles will continue moving linearly forever unless a drag force is added. So FumeFX Follow has an option to delete them. In contrast, Stoke particles might come close to the border and possibly slow down, but they will never escape unless there is another external velocity field affecting them. If the FumeFX sim is the only source, the particles will move within the grid as expected and not one will have to die to produce a clean look.

Stoke was NOT designed to replace Particle Flow (that would be a completely different project). Stoke was designed to improve and speed up the typical Particle Flow + FumeFX Follow workflow. It does not replicate it completely due to the above difference (so you cannot apply 10% of the FumeFX Influence and let the particles float around based on their “inertia”), but it does a very good job at producing predictable results from the input data, and offers the ability to create some types of motion that were not possible before (for example, you can advect Stoke particles with other Stoke particles to produce Fluid Motion from non-particle Velocity Fields)…

And with the latest build (RC1) posted last week, we got a huge speed up thanks to multi-threaded asynchronous PRT generation compared to the PFlow+FumeFX Follow+Krakatoa combo.

We have logged your wish for “lazyness”, but we cannot implement it they way you envision it. So we will have to explore other possibilities in the future.