I have been dabbling with Tp, Fume, and Krakatoa.
I noticed that when rendering the same frame and making simple changes from within krakatoa, unlike pflow, krakatoa seems to have to rewrite the TP particle data for that frame.
Am I missing something? (lol, other than using PRT 
)
Best regards,
John
If you start saving PRTs using Partitioning you will be surprised to notice that TP will recalculate each time from 0 to the current frame, causing exponentially slower saving with every next frame. Same applies to rendering a single frame - for Krakatoa, saving a frame or rendering a frame is the same. Other than PFlow, TP does not keep the current state of the system in memory. This applies to any other renderer btw, so if you try rendering with mental ray, you will notice the same behavior - the moment a begin render notification is sent, TP updates from scratch. So I am pretty sure it is the way TP works, not the way Krakatoa talks to it.
The only way to avoid it is to SAVE PRTs using the SAVE PARTICLES button instead of using Partitioning because saving a continuous sequence causes just one update at the beginning, then all frames are updated incrementally. Once you have the PRTs, you can render anything directly, as you suggested.
We barely use TP for Krakatoa work (only for geometry debris/fragmentation which is never Krakatoa related), so the connection is admittedly rather weak at this point and we don’t have any production experience with that combination.
If you save the Tp Dynamic Set ( witch should be part of any workflow from 3.0 + + ) , it shouldnt update… Did you try that Johnny ?
Thanks Bobo,
As I am not at all familiar with the inner workings TP I had found it strange that I was getting much faster straight off results with PFlow but knowing now that TP doesn’t hold particles in memory as pflow does, my understanding is clearer now. I figured I may have missed something, thanks for the clarification.
Rif, thanks, I just tried it, it is wonderful and upon using it with krakatoa the speed increase is now more what I am used too when pulling up test frames.
Just tested Partitioning with and without a TP recorded dynamic set, much better, saving is ridiculously slow without it, and 10 fold better with it.
Workflow adjusted, thanks for the insights 
Ya cool imagine if we had a Prt Saver in the Export OP of Tp or even better , Prt reading .tps files directly … that would be sweeter ! no bypass , direct connection…
PRT loader reading .tps files? That would be cool 
Either way export from tp to prt or Prt reading tps, it would convenient.