AWS Thinkbox Discussion Forums

Krakatoa + Phoenix FD - Partitioning problem

Hallo,
I am trying to add some more particles to my basic scene with Phoenix FD 2.2. I have liquid and splashes and want to increase the number of splashes by krakatoa.
When I hit the partitioning button, krakatoa says:
MaxKrakatoaPhoenixParticlIestream() Cannot use particles without a position from source: “splashes”
So how Can I solve it? (Partitioning of other particle systems-sources works good)
Thanks Tomas

Hi Tomas,

Krakatoa MX doesn’t actually support the partitioning of PhoenixFD foam and splashes, since the particles are generated by a pre-run simulation, so we can’t just increment a random seed and re-save the particles as we do to partition other types of particles.

The error message that you saw is indeed a bug though, which we will look into resolving in a future version. If you need to save the particles generated by a PhoenixFD simulation to PRT, in the mean time, a simple workaround would be to create a Krakatoa PRTSource object, and connect it to the PhoenixFD simulation. Then in the Krakatoa UI, de-select Phoenix as a valid source to save particles from and make sure PRTSource is selected. In the UI of the PhoenixFD object, you’ll also need to uncheck “Only if selected” in the “Preview” rollout. You should then be able to save the particles to PRT as usual. Also note that if you select “Color” as a channel to save, the saved particle’s “Color” channel will contain the wire color of the PRTSource. If you want them to be white, as Krakatoa interprets them as when it directly renders from a PhoenixFD object, you’ll need to either set the PRTSource’s wire color to white, or change the value of the channel using a Magma modifier.

Hallo,
thank you for your answer. I will try your way now.
But can I save prt directly from phoenix, load it in to prt loader and then do a partitioning? I have tried it yesterday late night and seemed to me no other particles has been added by partitioning. The result looked as same as the original file before partitioning. Weird.

Hi Evan,
I have tried your way of PRT source. But even in this case, I have problem with seeds in partitioning. As you can see from the screen, I have 20 partition counts, so you can see in the vieport that PRT source have 54 particles and loaded particles after partitioning have 1080 (54*20). That is correct. But in render or viewport, all particles are on exact same positions, so looks like the seed parameter does not work.
I think I have the same problem in workflow of: Phonenix save prt, then load PRT by PRT loader, do partitioning.

Does work Krakatoa with Phoenix in a way of partitioning by seed parameter? I just want to add some more particles to my foam on ocean.
Again thank you so much.
Tomas.

If you read once again what Evan explained in his very first reply, NO, you cannot Partition a Phoenix simulation. So what you got is what was expected - every partition has exactly the same positions:

However, there are a few things you could try:

  • You could try resimulating the Phoenix manually to produce variations, and save each point cloud independently to a PRT sequence. However, I am unsure if you can control the particle seeding in such a way that the combined cloud would look like what you are after. Also, it would be awfully slow. I have never tried this, but I had to mention it as an idea.

  • The PRT Cloner modifier lets you seed new particles based on existing ones:

    • The Repopulation mode specifically puts the source particles on a grid, and then creates new particles based on the grid values. This does NOT produce the same effect as partitioning, since the new particles are seeded on every frame independently and are not directly driven by the simulation. But if you need a very dense particle cloud, it can be useful.

    • The Radius mode seeds N particles in a spherical shape around the original particle position. The result is very similar to what the following few methods would produce, but it is performed at render time, and thus does not have the huge disk space usage of partitions, as you can use a single PRT sequence to produce any number of random copies.

  • In Krakatoa MX 2.6.1, you have a special channel that marks each particle in a PRT Loader with a PartitionIndex denoting the file sequence on the PRT Loader’s list. So it is possible to apply random offsets to the particles after the fact via the newly introduced Random Operators. Thus, even if you have 10 partitions with identical positions, you could use the PartitionIndex and a Random operator to shift the positions procedurally after the fact with a Magma Modifier.

  • In earlier days of Krakatoa, we had provided another way to partition an existing PRT file using a Noise modifier. The results would be somewhat like the ones from the previous idea with the Magma. Since the Noise modifier of 3ds Max does have a Random Seed value, and using a very high-frequency noise can shift the positions and velocities a tiny bit, enough to produce a fuzzy version of the original cloud. So you save on PRT from Phoenix, load in a PRT Loader, add a Noise modifier, set it to very high frequency, and then Partition that…
    thinkboxsoftware.com/krak-pa … sting-fil/

  • A similar Magma approach from older versions of Krakatoa where there were no Random operators used a Noise Magma operator to allow a PRT Loader to be partitioned. thinkboxsoftware.com/krak-pa … sing-magma

So there are a lot of possible workarounds, but the output will not be the same as what partitioning a Particle Flow driven by the velocity field of a single Phoenix or FumeFX simulation would be. When partitioning Particle Flow, the INITIAL distribution is randomized, and then the motion is the same for all particles according to the simulation data. So the outcome is the same as emitting N times more particles in one go, except that it is performed in smaller batches. With the above methods, the positions and velocities would be modified on each frame of the existing sequence, producing a rather fuzzy look. It might not be worth it.

Privacy | Site terms | Cookie preferences