flickering pyro - especially after converting particles to vdb

 Say you've made some nice particles and you give them density/burn/temperature and then convert these to VDB fields. You might find they flicker ever so slightly during rendertime. This is to do with a changing grid size. The "fix" is to make a gigantic box shaped VDB that encompasses the area of your particles/sim and plug this into the second input of the VDB from Particles node. Now the grid is fixed and you shouldn't have any more related flickering!

Pro tip from Walter.

POP streams, for POPs or even RBDs.

Bit of a waffly post here.. mostly for my own ref..

I had a case where there were a bunch of colour swatch cards in a display case of sorts. They needed to fly out of their resting position, but also had to vibrate and wiggle a little before this.
For context - I chose to use RBDs & the Bullet Solver, packed primitives for all of this, as there didn't need to be any clothy/plastic Vellum defomations.

So-

1) 10-15 frames run-up sim to settle
2) Cards gradually wiggle, not all at once.
3) Some cards shoot out of their position, not all at once.

The challenge is to effectively create an activation for the individual forces that effect the cards.

At first I was using the RBD-branded wind and fan forces - which did provide the necessary dynamic effect, but I couldn't figure out a way to use groups, or to trigger their activations on a per-packed-piece-point basis. These forces were connected one after another in a chain.


The solution is to use POP-Streams. In my case, we can plug this into an Rigid Body Solver (the 3rd input), as it already has a multi-solver, bullet solver and some other clever bits built into it.
We need to create a master POP stream with the rule set to include all the calculated points. You can/should initialise any values in this stream to account for any points that aren't picked up by the other streams. This might include making them active or not...
From this we can then connect secondary POP streams, each with their own rules and POP force nodes.

I tended to use the random stream option as a way to gradually and naturally add points to the stream.
Something I tried to get working was splitting streams one step further.. eg. A splits off to B ...but B then splits into C & D. This didn't quite go as planned.

I was trying to achieve a slow random addition to a stream/group and then for the cards to go either to the Left or Right, using POP forces. A bit of an inelegant solution, but I ended up creating two streams instead of B producing it's own two, (A divides into B AND C) using SOP bounding boxes. To achieve the random addition effect, I animated a threshold, which determined when the cards would activate. Each stream would then have its own POP forces. Much more control overall.

activating particles

to have particles come alive, mid sim (or indeed, to have them stop mid sim) you just need to trigger the "stopped" attribute in your pop network.

emitting only 1 particle per point per frame

Obviously stole this from ODforce:

if you want just 1 particle emitted per point at a given frame, the basic expression would be in the rate of the source node of your pop network
if you decide to put it in the impulse rate :
npoints(opinputpath("../",0))
and turning off the const. activation
if you decide to put it in the const rate
npoints(opinputpath("../",0))*$FPS
and turning off the impulse activation
don't forget to put the emission type to points(ordered) or you won't have a particle per point
this will hower emit the exact amount of points your emitter sop has per frame, so if your emitter has points that last 2 frames, you'll have 2 particles per point after 2 frames.


*Also, you could use $NPT/10 instead of npoints... Dunno if this works

When would you use this?
If you have a source which is changing point count each frame, eg, a pattern of cracks being animated (like when Godzilla is underneath a road)... 
I think the $FPS version helps when it comes to substeps etc like with Maya, where you need to divide the perframe emission to account for the substeps... 

The first option works well if you divide the emission count (just add a /10 or whatever after the expression)

random rotation with POPs

To get random rotation with POP particles, add a point wrangle at SOP level with a more specific version of the following code-

v@w=rand(x-value,y-value,z-value);

Then in the dop network, add a POP-torque node and set the amount to zero, so that it takes the initial "w" value. "w" is angular velocity..all according to keikaku.