It looks like the “Krakatoa_SeedIncrement_UserFunction()” function runs twice per partition having the global “theVal” argument referencing once a positive and once a negative value .
Partition 1 — the Val 0
Partition 2 — the Val 1 and -1
Partition 3 — the Val 2 and -2
…
Is it a known work-flow and we are missing something ?
Additionally was wondering how you guys usually partition a Pflow with a Pre cached PRT loader where there is no seed to change, this is how we do it now :
1_ We partition a single frame PRTv, lets say 10 partition
2_we add them all int a prt loader and flow it inside Pflow
3_With the “Krakatoa_SeedIncrement_UserFunction()” we try to set the render flag of just 1 partition on the PRT loader at a time. so this way we can also partition a prt loader that flows a lot of particles inside Pflow with a complex flow.
Yes, the value passed to the function is the RELATIVE OFFSET to change each Seed value by.
The first call changes the seed to the value needed to save it.
The second call reverts it back to the value it used to be at, so the next time a positive number is passed, it can increment from the right base.
This way, we don’t have to collect and keep track of what the original seeds were, we just push them up once and then back down by the same relative value.
Obviously, you cannot partition something that does not have a random seed.
In the early days of Krakatoa prior to v1.0, there was some attempt to allow the selective loading of one input partition sequence per output partition.
There is currently no way to switch the PRT Loader to load one sequence per partition run, but we have never needed this in production to be frank.
It could be possible to add some script-level control over partition sequences inside the PRT Loader’s list and turn them on and off depending on what partition is being saved instead of hacking it with the user function, but I don’t really feel like complicating the PRT Loader’s UI even more at this point. I hope your “hack” works in practice…