I’m trying to get a good workflow between Krakatoa MY v2.2, Krakatoa MX 2.1.1, and Stoke MX 1.0.0 but I’m running into a few errors which I’m guessing are version incompatibilities. I can load particles fine from MY in the older version of MX, but the ID channel is a different data type in the newer version (uint vs. int) which causes issues when I try to use Stoke since there’s no valid ID. I thought that maybe I could bypass this by assigning the ID in Maya into the rgbPP of the particles, cache out the PRT, and then in Max and Magma, extract the X value of the Color channel and set the out ID to that value. The connections all work fine, and since Stoke can’t read the PRT Loader directly for distribution or velocity ( gets the Unkown System Error which I believe is a version incompatibility issue ), I wanted to put it through PFlow using the Krakatoa PRT Birth and Update operators and then using that as a source since that seems to work fine when I make PRT’s in Max and can’t load them into Stoke directly with a PRT Loader. BUT, I get the error saying there is no ID channel, which technically there isn’t one baked into the files, only the one I created manually in Magma. Does the PFlow Op only read the files within the PRT Loader or should it take Magma into account? Is this just some crazy workflow and I need to just upgrade? Hahaaa writing it all out seems a bit much, but if anyone has any insight to some workarounds for this it’d be awesome.
I just tested this and it looks like a problem with Stoke. I have both KMX and KMY v2.3 here and the particles came perfectly well from Maya into Max and all KMX tools operated on them without problems, but Stoke would choke. I will log this and let the developers take a look. Since we are working on Stoke 2.0 and possible updates of KMY too, I am sure we can address this soon.
That being said, I am not sure what the problem really is because KMY 2.3 that I have here saves the ID as int64 and it should not interfere with anything in Stoke…
I’m glad to hear that it’s not just me being crazy trying to find a workaround for version issues. So is there anything you can recommend to do now about the problem? Or should I just try to maximize PRT caching times from the original sim and do a normal Krakatoa partition? Stoke is just so much faster and utilizes the resources much better, I feel it’s definitely the best solution for filling volumes and it’d be great to try to utilize it for this project.
So I loaded the particles saved by KMY 2.3 into KMX 2.3 and resaved all channels WITHOUT ANY CHANGES.
I just
*Created a PRT Loader at the origin
*Loaded the Maya PRT sequence
*Set the frame range to match
*Opened the Krakatoa GUI, switched to Save Particles To File Sequence
*Specified a new sub-folder for the output
*Set all channels to be saved that I could see in the source (look in the Krakatoa File Sequence Manager that you can open from the [>>] button in the PRT Loader)
*Right-clicked the SAVE PARTICLES button and selected the frame range
*Hit SAVE PARTICLES.
Once I re-saved the whole sequence, I removed the old KMY sequence from the PRT Loader and added the new resaved one.
Then I made a Stoke from it and it did not complain anymore.
We still have to figure out what causes the error message with the KMY sequence (the error comes from a function that allows MAXScript to query what channels are available in the source). Also I don’t know if the above workaround functions with versions of Krakatoa prior to the current v2.3. I would suggest an update, esp. if you are on support anyway… Please email our Sales dept. and ask for the v2.3 update for KMY and KMX.
Ok, after some more testing I found out that the Stoke error comes from attempting to query the channels layout when there is no valid PRT file.
In Maya, the first frame is typically 1. In Max, the first frame is 0. So when you save a PRT sequence to disk, you have frames 0001 to something.
If you make a PRT Loader in Max and load that sequence and try to pick it in Stoke while on frame 0, Stoke will fail because it cannot ask for the channel layout of a missing PRT file (it should not crash, we will look into that).
In the KMX PRT Loader, just check the “Limit To Custom Range” checkbox and press the “Range” button to set the start and end frames to the existing valid frame numbers (start would be 1 probably). This way, when Stoke asks for the channels layout on frame 0, it will get frame 1 instead and will be happy!
I have logged the error message, but I hope this workaround will let you work with your particles without the need to resave them. If you have issues with the format of the ID channel though, then you need to update to KMY 2.3.
Just tested and everything is working now! It’s so funny how problems like this can end up being such a simple thing but cause such a headache before it’s figured out. Thank you so much for your quick and detailed replies!
One last thing I noticed after testing. The difference in data types uint and int seem to make a difference with how Stoke utilizes the ID channel. When I cache a PRT out of Maya with an ID channel, Stoke doesn’t work properly. It’s weird because it doesn’t error out and it looks like it sims and everything, but then no particles are visible in the viewport or created I think. I’m guessing it works when there is no ID channel because then the PRT Loader automatically assigns each particle an ID which can then be read by stoke properly. I really think it’s just a version issue for that, but I’m still so happy everything is working now.
Thanks again for the great support