AWS Thinkbox Discussion Forums

Partitions

Deprecated Krakatoa MX Beta Bug Reports
#1

Hi,



I’m quite new to Krakatoa, therefore I don’t if this is a bug in build 18 or something I do wrong:



I did my particle animation with about 2 million particles and then saved the animation to disk. After that I wanted to use partitions to increase particle count. Well, but instead of getting more particles I got 10 partitions with about 300.000 particles together. Also the files size is much smaller.



I read the manual twice but haven’t found an hint.

It also worked before when using 100.000 particles or less.



rob.

#2

Hi,



I’m quite new to Krakatoa,

therefore I don’t if this is a

bug in build 18 or something I

do wrong:



I did my particle animation

with about 2 million particles

and then saved the animation

to disk. After that I wanted

to use partitions to increase

particle count. Well, but

instead of getting more

particles I got 10 partitions

with about 300.000 particles

together. Also the files size

is much smaller.



I read the manual twice but

haven’t found an hint.

It also worked before when

using 100.000 particles or

less.







Can you post step by step what you did?

If you were able to save 2M the first time, you should be able to create N partitions with the same count using the SAME setup, just by clicking the Generate Partitions button in the corresponding rollout. No other changes to the scene should be necessary.



We have seen problems with partitions on Deadline using FumeFX operators, but that is an exception.



Normally, you would simply

*Create a PFlow with 2M particles,

*Set Krakatoa to Save Particles mode

*Enter a .PRT output path

*In the Partitioning rollout, set the number of partitions, say, 10

*Press the Generate Partitions button and wait for the 10 partitions to be saved.

*Load all 10 in a PRT Loader and you should have 20 million particles out of the same PFlow.



If you can explain what was unclear in the manual, we will try to fix it (oder wir könnten es ins Deutsch übersetzen ;o)



Cheers,

Bobo

#3

Hm, this was my problem… I thought you can generate partitions only out of cached particles… Seems like it only goes with the original particle system (pflow)

sorry…

#4

Hm, this was my problem… I

thought you can generate

partitions only out of cached

particles… Seems like it only

goes with the original

particle system (pflow)

sorry…





Don’t be sorry - it will help us improve the documentation knowing that we haven’t explained it clearly. (Or we can add a FAQ entry explaining the right steps).



Once the partitions are made, you DO have to use a PRT Loader to combine them into a single denser cloud. But the generation of partitions just manipulates the random seeds of the original systems (PFlow, legacy Max particles, Thinking Particles) to force them to create slight variations of the same cloud. You have explicit control over which types of operators should be changed (randomize position, rotations, spawn, speed etc.) and can exclude single operators, whole PFlow events/TP dynamic sets or whole systems by adding “NOSEED” to their names.


#5

Unrelated, but is there a seed variable set by Krakatoa when making partitions that we can use to control things the Krakatoa doesn’t already increment? So we could say, change the seed of a noise controller or change the seed of a Box#3 sub-operator?


  • Chad
#6

Unrelated, but is there a seed

variable set by Krakatoa when

making partitions that we can

use to control things the

Krakatoa doesn’t already

increment? So we could say,

change the seed of a noise

controller or change the seed

of a Box#3 sub-operator?







Currently there isn’t, but


  1. we could add such a global variable so you could access it (really, all it would have is the increment to change the value by).


  2. we could call a global function each time seeds are processed, so you could define that function to do whatever you want


  3. you could just add your code to the KrakatoaPartitionTasksOnDeadline.ms script (overwriting our version with a custom one)


  4. we could provide a dummy CustomSeedsHandling.ms file in the Krakatoa installation folder that you could edit to add your own functions into, which in turn would be included on startup into the seed functionality of our own seed handling functions (local and network). This way, you could define “private” code to deal with your special cases and we would not overwrite that file if it exists during reinstalls (just like we do with Deadline Private Sanity Checks), thus allowing you to expand our code without actually editing the general scripts.



    Please let me know which way you would prefer.
#7

I think number 1, a global variable that is the current increment would be fine. We could use that to modify a seed with a function if we wanted.



4 sounds interesting, but way more than I need right now.


  • Chad
Privacy | Site terms | Cookie preferences