I’m having a problem saving particles to PRT, i get holes in randome times of the particle simulation.
In the picture you can see the particle flow object at the left, and the PRT loader at the right.
The total particle count is under 200.000, the particle flow limit is 1.000.000, but i tried with a gazillion particles as limit.
No matter what i do, when i bake to prt i get this holes, when I render the particle flow with kraktoa there is no hole at all.
In the second picture you can see the rendered result.
I must admit I have never used the Birth File operator and don’t know if there are any strange side effects when used with Krakatoa.
Would it be possible to download the sequence you are loading with the Birth File from an FTP server so we could test what is going on?
This is totally unexpected, esp. given that Krakatoa gets the particles correctly from PFlow when rendering - saving to disk should be equivalent to rendering, just dumping the data to disk…
Looks like 528 particles are missing - the PRT Loader shows 19008, the total count in the renderer is 38544, which means the PFlow had 19536.
The good news is, I could reproduce the issue.
The bad news is I have no idea what is going on, so I will have to pass it on to the developers.
Note that on the frames where we get a gap, the PFlow fails to advance to the next frame and produces a duplicate frame - at 25 fps scene with 100% playback speed, I got on frame 40 and 41 the same count in PRT Loader, then it lagged by one frame. The gap reappeared every 10-15 frames or so (next duplicate frame was on frames 57-58, then 68-69 and so on). I could also clearly see PFlow producing the bad count while saving by looking at the particle count display in Particle View. I suspect that the problem is somewhere between Krakatoa MX telling PFlow what frame to evaluate and the File Birth producing wrong result, then trying incorrectly to advanced from there (since it has to track the particles according to what’s in the cached files, the duplicate frame causes a gap). I cannot point a finger at neither Thinkbox nor Autodesk at this point, let’s see what the developers will find…
Once gain thanks for reporting and helping with data!
Hey Bobo, I tested a workaround baking the particles first with the “Disk Cache” operator, and after that sving the particles as PRT and it owrks, the hole in the particles dissapear, so probably is something in the “One Click” source operator.
