i have a massfx flow with just 1 shape and changing particle count so new ones get birthed and older ones die, i want to cache the flow using Krakatoa and then load it to a PRT Loader and mesh it using Frost
when i just save the particles it does not work at all there are no collisions happening, so i thought probably there is a reason why this is not working but then i tried to add a “Cache” / “Cache Disk” operator (Use At: Viewport/Render / Sampling: Integration Step) so should Krakatoa not just take the particles i see in the viewport and save them ? thats not happening, when i set my Integration Step of Particle flow to “Frame” its really screwed up although it looks perfectly fine in the viewport, when i set it to “Half Frame” the result looks quite smooth but in like 5 % of the frames the rotation does not update so it looks choppy in the animation
can anyone imagine why this is not working although pflows render/viewport chache looks perfectly smooth in the viewport ?
cached channels: Position / Velocity / ID / Age / Lifespan / Orientation / Scale => Radius
max2013 krakatoa 2.1.5.48953
I don’t think we have access to a Max build with MassFX support, so we have never tested what happens when you save one of those flows.
What version of Max are you using exactly? The one from the Suites?
Could you create and upload a VERY simple scene that shows the problem so I don’t have to build one?
its max 2013 Product Version: 15,0 Product Update 4 commercial
but i think this is not related to this max version if i remember correctly i had this issue with max 2011 and box#2 too
here is a simple example:
if you just update the cache operator in pflow and then save the particles in krakatoa and load to PRT Loader 001 you should see it, for me frame 22, 44, 73 … are way off for example the other frames match perfectly krakatoa_massfx_bug_.rar (26.2 KB)
I would say there appear to be two problems here. One is probably Max-related, the other might be Krakatoa’s.
I reproduced the problem as you sent it - frames 11,22,44,73,88… had wrong Orientation and the Position seemed to be one frame in the future.
After switching the Cache to “Integration Step”, the problems actually became less pronounced, but some particles still had slightly wrong Position and Orientation on those same frames.
When the Cache is disabled, the simulation looked completely different. But I believe this is not Krakatoa’s fault. I switched to Scanline renderer and rendered frame 40 with Cache on. Loaded the image in RAMPlayer Slot A. Then I disabled the cache operator and rendered again. Loaded in Slot B and compared - totally different. So it looks like the results of PhysX simulations with and without Cache operator are incompatible. Have you discussed this with Oleg?
We should try to figure out why we are getting incorrect data on frames 11,22,44… when rendering with Krakatoa. I will log that is a bug.
I seemed to recall that this used to work when it was PhysX at least I recall testing a simple PhysX flow and it had no issue, I guess the clencher is the birthing and removing of particles which massFX/PhysX isn’t too keen on anyway (mostly the removing). Oddly enough even in standard massFX/PhysX flows this can cause instability.
ye Johnny i have the same feeling, Bobo i wonder could you meanwhile figure out why the saving of the cached particles isn’t working ? if so can you maybe make a guess when you will have a new built, still in the December or more likely next year ?
Our plan is to have a new Krakatoa build in December.
Depending on how hard to fix the few problems are that we have logged against build 2.1.5, it could happen earlier or later…
