1.When drop some RealFlow OPs in PFlow(RealFlowFileBirth,RealFlowFileUpdate,RealFlowDeathTest ect…), if just press the Save Paticles Button it works correctly and fast.But when I chose to save some partitions for those paritcles , the partition function can’t save particles correctly.
[Save Paritcles] generated about 651KB date for all 141 frames , but 2 Paritions only generated 712KB date (each partition only generated about 356KB date for 141 frames), and you can compare the defference between [Save only] and [Parition] via below uploaded image.
For instance, [HeroFootSmash_010.prt and HeroFootSmash_011.prt ] , they were 15KB and 9KB , but [HeroFootSmash__part1of2_0010.prt and HeroFootSmash__part1of2_0011.prt] , they were 15KB and 1KB.
It seems while using Parition Function , Krakatoa can’t update PFlow correctly and lose some date.
2.Mmm, and I also have realized other very interesting thing. When I putted a “Cache” in PFlow , then tried Krakatoa’s Particle Partition Function , saving speed is extermely fast , but the consequence still looks strange. It looks like random seed didn’t work well when PFlow has a Cache Node.
I grabbed image from test scene , very simple scene that only have 20 particles in 30 frames , and I save they for 10 paritions with cached and without cached.(20 Paritcles x 10 Partition = 200 Paritcles in scene)
Boths loaded 100% particle in ViewPort
3.And last, Krakatoa also provided parition particles from PRT Loader , and I want to know parition from PRT Loader and parition from PFlow , is the results equal or not?
Can you do this for me please?
*Create a VERY simple scene setup that does not contain any sensitive data, just PFlow/PRT Loaders/whatever is needed to reproduce the problem.
*ZIP the MAX file and upload it here as attachment so we can look at what you are doing and what is going on.
From top of my head, I have no idea what is causing the fluctuation in particle counts.
Also, obviously, the standard PFlow Cache operator is a BAD IDEA (except for sometimes caching particles for faster viewport playback, I wouldn’t use it for anything else). We have provided explicit support for the Disk Cache operator that came with Box #3 though, but for a case like this (low particle counts), it makes little sense to cache anything.
Krakatoa cannot directly partition a PRT Loader because there is no random seed to change. If you attempt to do that, you will get 10 identical partitions.
As explained in the documentation, software.primefocusworld.com/sof … rtices.php
it can partition a PRT Loader that has a Modifier that supports a Random Seed (the only one shipping with Max right now is the Noise modifier and you can set it to very high frequency to randomize the Positions, Velocities and Normals of particles).
Here is my scene
And in RFCache folder , I also included some .bin files generated by RealFlow , if you need you can relocated the file path in RealFlow Birth OP
BTW , all files created in 3DSMax 2010 SP1 and Krakatoa’s version is 1.5.0.37179
Unfortunately, we don’t have the RealFlow operators installed in Max 2010 yet, but I recreated the scene in Max 2008 using your original source files, trying to match the setup.
I am not sure what you expected to happen from the Partitioning, since the RealFlow Operators do not have any Seed property that could be randomized. The only operators with the ability to randomize in your flow were a Speed that was disabled and a Rotation that has no influence on the particle placement.
I attempted to create 10 partitions out of my version of the scene (obviously getting 10 partitions with coincident positions) and all 10 partitions had correct file sizes (no discrepancies as seen in your screenshots).
So I cannot reproduce the problem at this point, but I might be doing something “wrong” if I am getting it right. Also, since there are RealFlow operators involved in PFlow, there is a chance the problem is not in Krakatoa because all Krakatoa does is asking PFlow for the particles and is saving whatever it gets.
You mentioned you were still running 1.5.0. Is there any reason for that? Have you tried 1.5.1? Do you want to try the latest Beta to see if it makes any difference?
Thanks for the explaination how the randomization work , that’s my first time try to take advantage of Krakatoa’s Partitoning randomize with RealFlow OPs , I’m really have no idea what the right way is
And you reminded me ,so I download the 1.5.1.38002 from website and problem was solved
