We are using krakatoa for maya 2016. When I’m writing the partitions I’m hoping to get some particle spread and random velocity.
It only seems to save out this information for the very first frame of the of each partition. This is evident in the viewport and also a corresponding prt file size that is larger for the first frame of the sequence.
Any help would be greatly appreciated.
-Nick
Hi Nick,
Are you using any form of particle caching in Maya?
The Krakatoa Partitioning requires the particles to be “free agents” during the simulation.
It has two different approaches to randomization.
If the distribution is fully procedural (based on a random seed), then varying the random seed option would be the simplest approach. By incrementing the random seed, each partition will seed particles elsewhere throughout the emitter, producing a unique initial pattern which will affect all future frames.
If you are using an Initial State that enforces the positions of all particles on the first frame only, then using the random jittering of the position and/or velocity lets you somewhat vary the initial positions taken from the Initial State data. However, on all later frames after the first, the particles should be free to move according to the fields and other factors defined in the simulation. The randomization of positions and velocities is performed only on new-born particles, which explains why you see a difference on the first frame only.
However, if you have an active Maya Particle Cache applied to the simulation, the positions of all particles will be fully determined by it, and we won’t be able to vary the future behavior of the particles after they are born - we let the simulation run without modifying it beyond the first frame, and if the cache is resetting the positions and velocities to the stored data, we cannot do anything about it.
A workaround would be to use the Repopulation operator to seed completely new particles around the single set of cached base particles, but the looks would be very different from what you would get with correct partitioning, so I don’t recommend it in this case.
In short, if you have a cache on your system, turn it off - the saving of PRT partitions is technically a form of caching anyway. It will be slower, but should produce what you expect. If you are not using a cache and you are still not getting the right behavior, we might need to see a simple test scene to reproduce the problem as you might have encountered some bug we are not aware of…
Hey Bobo,
You got it right. I was using particle caching for speed and a means of version control. I get what your saying about the particles needing to again through the simulation again instead of something like a post process. I’m running the prt saver of the live particles now and it seems like its behaving a little more as expected.
Thanks
Also a colleague here is helping me to get the partioning part into deadline so after a couple errors he fired off a question for me to ask you .
“we are on 7.2.0.18 R and trying to submit a krakatoa particle partioning job through the krakatoa MY 2.6.2 and it seems the farm through an error on line 167 of mayabatch in the startJob function. relating to not finding anything for ast.literal (extrajobinfo) we also dont seem to have kmy2prtjob.mel anywhere on the job system… is that a new mel file? that doesn’t come with krakatoa?
throws an error*”
The kmy2prtjob.mel script is generated dynamically by the KMY2PRT_Saver.mel script - if you open it and search for that filename, you will see where it is written using all the settings provided by the dialog. So it should be saved in the temp folder of the submitting workstation, and would become an auxiliary file of the Deadline submission. If you explore the Job folder via the Deadline Monitor, do you see that script in there?
I will have to pass this error report to the Krakatoa MY and Deadline Integration teams though, as I am not sure what the exact problem with the extrajobinfo is.
Thanks for the report!
For the problem exporting over Deadline, would you be able to open up the MEL script console before you submit the job to Deadline.
Then when you hit submit, can you copy/paste the text that is printed to the console so we can try to debug what is happening?