Is it possible to speed up the PFlow PRT ops?
Hi Charley,
I don’t think it is possible.
Can you describe your precise workflow and what part of it is slow?
If we cannot fix PFlow (and its ops), we might be able to think of another approach?
P.S. I deleted the second post and your comment about it 
thanks Bobo
It always comes down to the particle count. Generally I want to use PRT’s’ to overcome PFlows severe speed issue with birthing on animated geometry. So I will either save PRT’s directly from PFlow birthing on the animated surface, or I may generate a PRT sequence and KrakatoaSkinWrap it to the animated mesh and re-bake that to PRT’s. Then I PRT birth op them in and generally I also need the PRT Update op. This setup updates PFlow nearly as fast as the PRT Loader for particle counts in the neighborhood of 100,000 or less. But when you get up and over 1,000,000, it gets very very slow, even if you are not showing the particles in the viewport (display op set to none). Yet the PRT Loader is able to load the particles at near real-time (off the local drive) It also seems that having the PRT Update Op almost doubles the time for PFlow to update. Could the Birth op and Update op be a single op? Would that help?
Also, if the PRT Loader has a frame offset where it holds for a period of time, PFlow will continue to perform updates although there is no change. it would be cool of the PFlow ops could see that this is the case and not update.
Do you know if the newer Birth File op, the one that is supposed to bring in particles from XSI, is any faster? If so is there a way to leverage that?
On a side note, it would also be helpful if the PRT birth op had a start and end frame like other birth ops. There are times when I have a long PRT sequence and I only want to generate particles through a portion of it. Right now it seems to be based on the animation range. This isnt a huge thing because I can use multiple PRT Loaders and set the one PFlow sees to only be for the duration I want it…but it would be useful.