Noticed that I can’t use pflow’s quantity multiplier with krakatoa file birth op… --Quick request: either make that work, or add a load every nth particle in the file birth operator. (make it a bit more like the prt loader…?) The system is a bit heavy with this many particles coming in (million or so over 400 frames)) would be nice if it could speed it up by having it skip particles.
Noticed that I can’t use
pflow’s quantity multiplier
with krakatoa file birth op…
–Quick request: either make
that work, or add a load every
nth particle in the file birth
operator. (make it a bit more
like the prt loader…?) The
system is a bit heavy with
this many particles coming in
(million or so over 400
frames)) would be nice if it
could speed it up by having it
skip particles.
That’s pretty tricky. The K. File Birth has to compare the IDs of the particles in the files to decide which have to be born. But the order of particles in a PRT file is not stable, because a Particle Flow returns particles based on the accumulated containers of all its events - when a particle moves from one event into another, it will change its relative position inside the PRT file, while its Born ID will remain the same. But we also do not know what Born IDs will be in the file, and the only way to correctly determine which one is being born and which one is dying in the sequence is to load all particles.
If we would assume that certain Born IDs would always be skipped, for example if you are doing 50%, every second ID would have to be ignored, loading only odd IDs like 1,3,5,7 etc, then it would work once.
But if the PRT sequence contained only odd IDs because somebody already loaded it with 50% into PFlow and then resaved to PRT (which preserves the original Born IDs), loading a second time would suddenly not skip anything!
We discussed this problem when developing the operators and decided that the only way the birth feature could work correctly would be to ignore the quantity multipliers and always process all particles.
If you want to do less particles but can ignore the birth data implied by the PRT sequence, you can always use a regular Birth operator to create as many particles as you want, then assign the Positions and Velocities using K.File Update to drive them around. If the Born IDs of these particles match the ID channel of the PRT sequence, you could still send them out with a K.File ID Test to die, but you wouldn’t be able to give birth based on the files…
I hope you can see the problem and why we had to do what we did. We will take another look in 1.2, but I cannot promise there is a good solution.
All good bobo, thanks for the info!
All good bobo, thanks for the
info!
Actually our fearless leader seems to have some ideas how to solve this, so we will try to implement your wish in 1.2. :o)