having recently got back into using Frost, I was looking at the feasibility of using it for dumb crowds driven by particle flow.
As I understand it, multiple animated shape objects with offset animation is fine, but if you want to control which animation is used (say a death animation) then you need to use a PRT loader and Magmaflow?
Magmaflow is something I’ve been meaning to look at, but it’s a step above what I’m used to using, and I need to work through the tutorials.
But from what I’ve read, PRT only works with PFlow via mesher, and then you lose the channels like orientation presumably?
I’m just trying to understand what the intended workflow is - it seems like it’s a case of removing what’s slow in PFlow for the equation, but I do wonder if there’s room to have something that identifies a switch to another particle type/animation sequence which is picked up by Frost, without the whole animation being processed by PFlow.
Anyway, just getting my head around things - it’s only recently that I saw the benefits of using a PRT volume with Frost, and the modifiers that could be applied to that…
Hi Steve,
In short, you are mostly right, but take a look below for some more details.
This is not correct. The Mesher would be needed only if you wanted to capture the Shape channels of a PFlow to use for something. PRT files saved through Krakatoa can capture all other relevant channels like Position, Orientation, Scale, Velocity etc. and Frost could use them to recreate the PFlow. It is kind of possible to get a ShapeIndex channel out of PFlow through some tricks, esp. if you want to know when a particle moves to a new event and should change its animation source. Unfortunately, PFlow does not provide a channel that indexes into a list of shapes, it stores the whole TriMesh of the ShapeInstance in its Shape channel and we cannot use that directly.
Yes, you would completely disable the Shape/Geometry Display of PFlow to keep it fast. You would put some user-defined value (e.g. a custom Mapping channel) in each event, and save that Mapping channel out. So event 001 would have a U value of 1, the event 002 would have a U value of 2 etc. Then in the Magma, you could read the U value of the Mapping channel and generate a ShapeIndex channel to point at the custom geometry to play back. As a particle moves between events, its Mapping channel will change and produce a different ShapeIndex value to switch the animation. But blending the animations would be tricky…
In Max 2014, you could set the ScriptInteger value using a DataOp directly and then read that as ShapeIndex via Magma to control Frost.
Speed is quite relative though - right now Frost is not that much faster with animated meshes than PFlow. It IS faster, but not by much. I created a test scene today on my Dual-core+HT laptop with a Geosphere animated via XForm to jump up and down and scale on impact and assigned it to 1000 particles over 50 frames. PFlow played back in 1m28s, Frost played back in 1m05s. So only 23 seconds faster. This is 88 vs 65 seconds, or only 1.35x faster. Frost’s Geometry instancing is the only area that isn’t multi-threaded yet. It is on our list to revisit in a future update…
The real benefit is that you could modify the cached PRT particles using Magma after the fact (kind of like Post production). Let’s say you have a bunch of particles moving around in XY on a flat plane. You cache the general motion and logic etc., then decide that they should be moving over a slightly bumpy terrain. You add a Noise modifier to a tessellated plane, shoot a ray down the -Z from each particle and conform its Z to the new terrain. All other parameters remain the same, but now you have slightly new motion you can adjust interactively since all changes are history-independent (calculated on the current frame only).
Historically speaking, the reason we even have Geometry Instancing in Frost is this: Back in Frantic Films days, we got to do some CG snow shots for the second X-Files movie. We got some pre-animated particle caches from Maya and were asked to render them. Instead of switching to Maya on the whole farm, we added the option to Frost (then called PRT Mesher) to allow for Camera-Facing Planar Shapes we could map with the snow textures and render in Max. Then we added more geometry types and custom shapes, and later added support for all the channels, animation controls etc. just in case. But it was never meant to be a full replacement of the PFlow workflow, just an alternative way for those who have a pre-cached animation and want to tweak it somewhat in post without having to resimulate the base animation.
In other words, I would not claim our way is superior to native PFlow at this point. But it is an option and can be useful in certain cases…
I have messed around with this concept a few times, I rather like the control you have with it. It seems much more predictable than using multiple event Shape Instance operators. It is as simple as just setting a speed float (you can use age+lifespan channels too, to help control animation playback) and a shape integer in pflow and letting PRT Loader and Frost (you can use XMesh too for cached shapes) handle the rest. As Bobo mentioned the speed gain is not significant BUT the predictability is! Many a time I sit and wonder why some shape is not what it is supposed to be in pflow, I have yet run into that.