nothing particular clever to add, but damn, this this is super fast.
Advecting particles through fume is super fast, to the point that im confused why PF and TP follow ops are so painfully slow.
I read Bobo’s explanation, but my artist mind get get around it.
Anyway, very excited about this tool, and the Recent RC1 is much faster, especially the PRT creation!
cheers guys
sam
Thanks for the feedback!
I am preparing a demo for the New York City Max User Group next week, and I am running benchmarks / drawing graphics to explain it.
But basically it goes like this:
Let’s say you have a FumeFX simulation. You emit 100,000 particles per frame from some mesh surface or the FumeFX itself.
In PFlow, the FumeFX Follow provides the velocities and PFlow advects the particles on a single thread.
I just measured on my quad-Xeon with HT that it takes 213 seconds to simulate until frame 100 without saving to disk.
BUT if I were to save these particles to disk using Krakatoa, the saving is sequential:
[Sim Frame][Save PRT][Sim Frame][Save PRT][Sim Frame][Save PRT]...The total simulation and saving time would be MUCH longer - the PRTs take up around 15GB of disk space and the saving finishes after 1335 seconds (22+ minutes).
In Stoke, the advection of the same particles running on all 8 threads finishes in 38 seconds which is 5.76x faster thanks to the multi-threading alone.
If I decide to save to disk, the saving is asynchronous. Stoke puts the simulated data in a memory buffer, and from there a background thread would zip the data and save it to disk. If I were to run only one saving thread like we did in earlier builds of Stoke, it would take 1094 seconds to simulate and save. So while the simulation time is shorter than in PFlow, the saving time isn’t, and the difference between 1335 and 1094 isn’t that impressive if you are interested in Partitioning. If you want to do multiple iterations though, it would still be much better because after 40.5 seconds you would be ready to do other things and the saving would continue in the background…
The way it works is like this:
[Sim][Sim][Sim][Sim][Sim][Sim]...
[Save PRT][Save PRT][Save PRT][Save PRT][Save PRT][Save PRT]...
Then we added the ability to save multiple files at once. So in RC1, while the simulation is running, I would have by default 8 threads simming and 4 threads writing. This would slow down the simulation a bit, but reduce the total processing time. After the simulation is done, all but one threads start saving (in my case 7 threads, leaving me one for interacting with Max).
If using the Partitioning tool though, all 8 threads would be saving (I am adding thread controls to the dialog for RC2).
As result, the simulation would take around 76 seconds, but the whole process including saving all 15 GB PRTs to disk would finish in only 247 seconds, in other words 30 seconds more than PFlow took to just simulate without saving anything!
This is 4.4x faster than Stoke on on thread and 5.4 times faster than PFlow saving through Krakatoa.
It looks like this:
[Sim][Sim][Sim][Sim][Sim][Sim][Sim][Sim]...
[Save PRT][Save PRT][Save PRT]...
[Save PRT][Save PRT][Save PRT]...
[Save PRT][Save PRT][Save PRT]...
[Save PRT][Save PRT][Save PRT]...
This is research which will probably pay off in the future versions of Krakatoa, XMesh etc. 
I would also like to mention that I benchmarked the PFlow using 1 Frame Integration Step which produces very bad results, and some particles are leaving the grid, so the final render is quite unusable. Setting PFlow to Half Frame Integration Step does not produce much better results, but the pure simulation time doubles from 213 to 427 seconds.
Here is the PFlow output with 1 Frame step:
Stoke produces much smoother results even with 1 Step / Frame and no particles get lost:
thats a very helpful explanation! thx exciting times for tools!