I’m looking at doing a load of snow shots on a film and pflow is ridiculously slow to generate high particle counts. Ideally I’d get the motion I like using pflow and then stoke to upres heavily and finally render via frost. What I’m finding as with the linked screencap below, is when I make a pflow system then add it into stoke as a velocity and distribution source, the particles gradually detach from the source particles and lose any velocity, leaving trails behind the original pflow system rather than new, similar particles. I’ve checked to make sure that pflow is using 100% of particles in the viewport, that both stoke and pflow are using the same start and end frames for the birthing and just in case I’ve set the integration step to frame just in case anything is causing a break. I’ve tried reducing the size of the grid for the pflow velocity source in case it’s missing the particles going through voxels too.
Unfortunately, there isn’t much you can do to avoid this - the Stoke particles are in no way directly bound to the source particles, they just get a push from a velocity field based on the source Velocities. If you want to produce multiple particles that follow exactly, you need to either perform Partitioning, or use Krakatoa Repopulation instead.
Basically, what you are seeing is a very low resolution particle system splatted on a grid. Each PFlow particle adds its velocity to the grid, and the Stoke particles attempt to follow. If the source particle moves too fast and the grid size is too small, it might skip over voxels and leave the followers behind. If two particles happen to come close to each other and are moving in different directions, the combined velocity in the voxel can cause the Stoke particle to slow down moving in the average direction of the two, and thus fail to reach the next voxel and be left behind again…
Things that can help somewhat:
*Increase the voxel grid size (as opposed to decreasing it). Larger voxels reduce the quality of the simulation result, but make it less likely for a particle to be left behind.
*Use Fluid Motion. This is usually not useful for up-resing since the new motion is quite different from the source motion. But there will be less particles left behind because velocities can affect voxels far away.
*Combine multiple entries of the same source system with different grid settings - uncheck the “Use Global Grid Settings” checkbox, then pick the PFlow event again and set to a larger grid size. Tweak the Scales to blend the two simulations.
*Use a Magma modifier to select very slow / stopped particles and a Krakatoa Delete to delete them.
*Use a lot more PFlow particles - when simulating with 20000 instead of 200, the Stoke particles will find a lot less empty voxels and will follow much better.
*Use a slightly higher Scale factor than 1.0. For example, 1.05 might help the particles to keep up with the source particles…
I played with several combinations of the above ideas, but while I could get a fairly good cloud following, it would never look exactly as the source. Only Partitioning produces a perfect solution.
In other words, Stoke is a good solution only when you have a very large number of particles and you want even more particles with approximately the same motion. But it has its obvious limits…
That’s perfect Bobo and makes lots of sense - if anything my “test” was too simple for stoke to actually use it seems. I’ll try an actual production scene which as you say has a higher particle count.
What happens to the voxels over time? Like say for example a single particle makes a trail through a set of voxels and no particles ever pass that way again. When stoke goes to use these fields at a different frame long after the source particle has gone, does the direction vectors of our source particles still exist or do they fade off after a certain number of frames, almost like the gradual energy loss in a fluid situation?
Excellent questions, and the answer is: It depends!
The Stoke 1.0 Particle Simulator you were testing does NOT remember anything about the previous frames. It is history-independent and dumps the current frame’s particles on a fresh grid, optionally removes the divergence (Fluid Motion option) and advects the particles. The particles remember their previous positions, but NOT their previous velocities, thus if the voxel contains 0 velocity, the particle stops and does not continue like in PFlow (this is as designed since we are “dragging” them with the “fluid”, and zero fluid motion implies zero particle motion.
The Stoke 2.0 Field Magma provides exactly the same mechanism via its ParticleSplat, PVelocitySplat etc. operators. The Stoke Field Magma is also history-independent and would create a new fresh grid with only the current velocities on each frame. But since it is Magma-driven, you can customize how the data is collected, how the grid is created (you can for example blur a Grid by resampling it onto a larger one) etc. So it is a step above the simple Stoke 1.0 particle advection.
The Stoke 2.0 Field Simulator is a totally different beast. It is history-dependent - any channels defined in the Initial flow will be cached between simulation steps and the output of the previous step will appear as input in the next step. If you define a Velocity field in it, that Velocity field will be used to advect any other channels. You can iteratively add to channels in the Simulation flow, so you can add the current frame’s Velocity to the previous frame’s Velocity. It has a built in Simple Fluid solver which removes the Divergence in the simulation step. Or you can disable that (No Solver) and remove Divergence in the PVelocitySplat node. Or you can disable the Divergence removal completely and simply collect the Velocity As Is. You could multiply the previous Velocity by a factor less than 1.0 before adding the current particle Velocities, so old data would slowly fade off. Or you could directly replace the Velocity with the current values just like in the previous examples above, while still advecting other channels by the Velocity on each step… It is VERY powerful and might give you the most control over particle advection for upresing simulations, as it would allow you to have the fading off effect you mentioned.
Both the Stoke Field Magma and the Stoke Field Simulator are valid velocity sources for the Stoke Particle Simulator, so you can play with them as alternative grid creation methods!
That’s lots to play with so! Accounts should be making the license purchase today or tomorrow so I’ll definitely be playing with these ideas - thank you so much for the clarifications!
