So I’m trying to find a solution to my problem of simulating and caching millions of particles for over 4,000 frames. To simulate the particles in Pflow takes about 36 hours. Obviously I can’t do this on the farm since it’s frame history dependent. (Yay single threading). And the DiskCache node is failing in various and exciting ways that is breaking on the farm.
My plan was I would just cache out the pflow to PRT using the Krakatoa Particle Saver. No problems there, I exported 2,000,000 particles to PRT. Took about 25MB per frame and worked out dandy.
So I then created a PRT loader. Created a PFlow with a Krakatoa PRT Birth operator and a Krakatoa PRT Update node. Everything seems to work just dandy. Now I advance to say frame even 100 and it takes fooorrrrreeeeeevvvvver to update the PF Source. Am I doing something wrong? Even with just a Krakatoa PRT Birth operator it takes longer and longer every frame to calculate even though the birther isn’t doing anything. Shouldn’t it just load the one frame at the same speed regardless if it’s frame 0 or frame 10,000? It’s actually taking nearly as long to load frame 100 of the PRT as it did to simulate it in the first place which isn’t working at all as a cache.
The PRT itself loads like instantly. But I need to run some further manipulation on the Particles and then eventually render geometry for the particles not actually Krak.
Unfortunately, this workflow was NOT designed as a substitution of the DiskCache. It does not just load the particles of frame N into PFlow, it simply operates as PFlow normally does. The only difference is that the Birth operator reads from file, and the Update operator reads from file too. But if you go to frame 100, PFlow will have to load every frame from 0 to 100 and apply all the other rules. It even integrates using the Speed loaded from the PRT’s Velocity channel, so the particles are consistently one step ahead of the real simulation.
Originally we added these operators as unsupported “Bonus PFlow Tools”. I can assure you the original developer of the feature was totally against it, as he felt it was a poor hack. However, it allowed us (well, me) to take any data from any source that can be saved to PRT, and tweak it through PFlow for added flexibility. Also this was looong before we had Magma.
So these operators were added mainly for flexibility reasons, not to make PFlow faster. If you have watched my demo videos of deforming particles with splines, you will surely appreciate the benefits: youtube.com/watch?v=Ps1FWERTRrs youtube.com/watch?v=n2OPHxFCp_8
Are there any tools which provide an equivalent to Shape Facing in Magma? Is there a magma node for instancing geometry to each particle and rendering the PRT directly? I could recreate my Pflow stuff in Magma if necessary. I just don’t have any use for Krakatoa itself. PRT’s reliability and Magma’s performance though would be very welcome.
For facing particles (or other mesh-related effects) you could use Frost. Frost can read PRTs and do facing particles, sprites, custom geometry shapes, and respects Magma or PFlow-provided channels to control things like particle scaling (right now uniform scaling only), animation timing, shape index to assign, materialIDs to use, etc. The Orientation to Camera can be set automatically by Frost, or you can provide custom orientation via Magma.
Well it wouldn’t really end up being a test, I have to send this off to render by the end of the week and frost is probably too pricey as a simple instancer.
Maybe there is room for a new product FrostLite + Magma 2 (which I guess would be bundling a basic instancer with Stoke).
