Having an issue with partitions not randomly seeding from a realflow simulation.
The partitions seem to load on top of the existing particles without any randomness - the particles are there but seem to have ignored the random seeding.
The initial simulation is loaded in as bin from Realflow, partition saved out, and responds in the same way whether loaded in on the same PRT loader or a separate one,
Partitioning is based on changing the random seed of a live simulation, or, if the particles have an initial state, randomizing the initial position and/or velocity. But a PRT Loader does not have a random seed, and does not advect particles over time, so even if you randomized the position and/or velocity on the first frame, this would not affect the following frames which are explicitly loaded from disk.
Since you are loading a pre-baked BIN file from RealFlow, Partitioning does not really work, and it is not expected to. It is the same in Krakatoa MX btw.
A possible workaround would be to modify the Partition script to not track the IDs of the particles, and thus randomize the positions of all particles on all frames within the Jitter Radius. We can look into that, although I am not sure whether it will look good. The result would be similar to the workarounds available in Krakatoa MX where a high-frequency Noise deformer can be added to a PRT Loader to produce a similar effect: thinkboxsoftware.com/krak-pa … sting-fil/
The other alternative is to use the Repopulate feature of Krakatoa MY and distribute a large number of new particles within the influence range of the BIN particles. thinkboxsoftware.com/kmy-rep … particles/
Unfortunately this will not help you to partition BIN files.
In older builds, the PRT Saver (accessed using the PRT SVR shelf button) could only save particles in PRT format. The new build added a “File Format” dropdown box, which allows you to save particles in PRT, BIN, or CSV format.
As Paul explained, it only means that the output of the Saving script can now be any of the supported formats (PRT, BIN or CSV). This does not mean that INPUT BIN file can be suddenly partitioned into multiple variations.
Some of the development for Krakatoa MY 2.3 expected to enter Beta around Siggraph MIGHT provide a solution though. Stay tuned.
That is an interesting workaround you suggested. I’m not really sure how it would work, but if you could get a voxel field with velocities into Fumefx (based on your BIN sequence), then you could definitely run some nParticles through it, and partition the system using Krakatoa. Can the Realflow BIN loader create an nParticle system, and in turn can Fumefx create a voxel field out of that nParticle system?
The standard way Krakatoa would be used to increase the particle count of a particle sequences is “repopuation” http://www.thinkboxsoftware.com/kmy-repopulating-particles/. Increasing particle counts on pre-baked simulations does tend to stop looking so much like physical motion, because the new particles do not behave like the ones in the simulation, but it does tend to fill in the gaps quite well.