When in geometry mode, scattering either custom or built-in geometry over a simple PRT loader, frost crashes constantly any time the timeline is scrubbed. The higher res the geo being scattered over the PRTs, the more consistent the crashing, but it happens every few seconds either way.
Is this a known issue?
Never heard of it.
Sample scene, please!
Also please provide the exact version numbers of Max and Frost.
I just downloaded and installed the latest Frost build v2.1 on a new machine with Max 2018.
Scrubbing the time line showed no issues, all 20K teapots appeared in the viewport, matching the position and orientation of the original particles. No crashes.
I believe I’ve narrowed down where the error is coming from. I can’t explain why it only happens when frost is enabled in the viewport (maybe that doesn’t actually matter and was purely coincidental until now?), but it seems to happen when a particular material is applied to the source krakatoa PRT loader object.
While trying to create a sample scene for you, I noticed the error doesn’t occur when no materials are applied to the prt/frost objects. However, once I apply a certain material to my PRT loader, the scene crashes very quickly.
I’ve attached a sample scene and prt sequence. Open the .max file, retarget the textures/sequences to the ones included in the .rar, and scrub the timeline rapidly. I get a crash within a few seconds of doing that. Sometimes literally within 5 seconds, sometimes closer to 30-40 seconds…but it always happens eventually. It’s worth noting that after the crash occurs and max displays its crash report dialog, my CPU usage remains high…so I’m guessing some threaded function is hanging, and that would explain why the 3dsmax process won’t die even after the main thread hangs. A race condition being the problem would also explain the inconsistent times between crashes.
I’m using 3ds max 2017, Krakatoa 2.6.1 and Frost 2.0.10. I’m on a machine with 4 physical CPUs and 16 total cores if that matters as well.
Here are the files:
tysonibele.com/Junk/prt_crash.rar (76mb)
Thanks!
By the way, when I run the 3dsmax debugger from VS2017, here’s the call stack when the crash occurs. The culprit is vrender2017.dlr, being called from MaxKrakatoa.dlr which itself is called from a thread, it seems.
The material I have applied to my krakatoa prt object is a vray mtl. Maybe there’s some issue with the loader querying the vray shader from a thread?
I’m using Vray 3.60.04, for reference.
It is much harder to reproduce on a 4 core / 8 thread machine, but eventually it crashes.
Thanks for the exceptionally good report and details, good catch!
I will log it as an Issue, in the mean time please refrain from using non-Standard materials with Krakatoa.
Oh good, I’m glad you were able to reproduce it! Luckily the workaround of not applying non-standard materials to a loader is an easy solution.
Cheers!