I am posting this in the beta section because I am not sure right now if I am using a beta or production release of Krakatoa. My question probably doesn’t matter, but…
I am using the PRT Birth and Update operators for PFlow and I can only get particles to birth once, so if my PRT changes count over time, it is not reflected in the PRT BIrth op. Is this normal and/or is there a work around?
In addition to Birth and Update, you are supposed to use the Krakatoa ID Test to delete dead particles (I assume you are using that).
If the PFlow gives birth to more particles, they are supposed to have higher unique Born IDs and should appear again correctly.
What you cannot do though is give birth to the same particle AGAIN (it is an unfortunate limitation and it would be possible if it were up to me).
So if you have a PRT Loader that loads particles from, say, PRT Volume where some particles are born and gone multiple times in the sequence, since the PRT Volume has no ID channel the Index channel would be used. In that case, the PFlow will give birth to the particles only the first time, then they will be marked internally as “already lived” and won’t appear again.
I have logged this as a Wish for future versions of Krakatoa and really hope it will make it into v2.0.
I have a prototype of a TP operator that does this and it is quite useful…
This is sooo huge for proper pflow integration when you use PRT Volumes!
I see. So if I can give each particle a unique ID as they appear and dissappear, it should work ok in PFlow?
Yes. The trick we have used before is to figure out the max. number of particles per frame. Then use a KCM to set the ID to an integer based on that number multiplied by the currentTime.frame. If you feed these particles into PFlow, you have to delete them on each frame so the Birth can replace them all with the new frame’s particles. It is ugly and is a huge hack, plus you cannot go too long with millions of particles before you run out of IDs.
This should be fixed in the Birth/Update to get it working right…