We are using Frost to mesh realflow particles, everything is going well and the meshes look great. However, Frost is constantly re-meshing when doing basic tasks in the max ui. For example, assigning a material causes a remesh, when we open our custom submission dialog, it causes a remesh, etc. What events specifically are triggering the remesh so we know if its possible to avoid this? Is there a way to turn off the auto-remesh except when changing frames? I realize we can cache the mesh with xMesh or VRayProxies, but this process takes many hours for our current sim and this makes the iteration times too long when refining sims. Any solution or work around would be appreciated.
Admittedly, the Max notification system is quite coarse in some cases - sometimes just sneezing could cause an update, esp. when using scripted modifiers.
But in the case of Frost, we have attempted to make it update only when really necessary.
It sounds like it does not behave as expected in your case, so we might need some more info about what you are doing with it.
Here is the logic as I see it in v1.2.0 on my machine, YMMV:
*By default, the “Viewport Update” settings are to update when Frost itself changes a parameter in its parameter block, and not to update when the particles change.
*When a change is made to Frost that does not directly affect the meshing parameters, for example a new material is assigned to it, a cached version of the viewport mesh is used and no full update should occur. I can see this in the Log Window in Debug mode - if I mesh 50K particles from PFlow in Anisotropic mode (selected because it is the slowest), I get 1.5 seconds to remesh. If I assign or change the material, I get an update time of 0.007 seconds (thanks to the cache).
*If the “When Frost Changes” option is also unchecked, assigning a material shows no updates of Frost at all (but the viewport display shows the material change). In this mode with both options unchecked, only changes to the scene time or pressing the “Force Viewport Update” should cause a remeshing.
*If the particles are coming from an external source (like a Krakatoa PRT Loader), changes to that object will only affect Frost if the “When Particles Change” option is checked.
*If the particles are being loaded directly into Frost via its own “Particle Files” rollout, the “When Particles Change” option obviously plays no role, but I still cannot find a way to cause unexpected updates.
That being said, it is possible to confuse the Max Notification system if there are cross-dependencies thanks to modifiers referencing other objects and possibly other causes.
So it would be very interesting to learn more about your setup to find to figure out why your Frost is updating too often (assuming you are running the latest v1.2.0.46170 build - if not, you should update).
*Are you loading your particles using PRT Loader or directly into Frost?
*Do you have any modifiers on the Frost object or the PRT Loader (if you use one).
*If you do, do they reference other objects in the scene?
*What materials and maps are you assigning to Frost?
*Does Frost cancel updating correctly when you hit the Esc key during an unwanted remeshing?
So I created the simplest possible test scene: a single frost object that directly loads a realflow bin (not using Krakatoa).
With this scene, our custom submissions dialogs causes a rebuild every time they open or refresh. Tracking it down in our code, I isolated it to a place where we iterate over the cameras in a scene so we can provider a drop down for the user. So code as simple as this will trigger a frost rebuild:
for c in cameras do (print c)
HOWEVER, I noticed when testing just this snippet of code, that it did not update every time! which I though was weird. I’ve been trying to track down what it is that is causing the erratic behavior with no success.
I attached a very simple maxscript utility that just creates a dropdown of the cameras in the scene as an example. Almost every time I open this utility it cause a frost rebuild, but not every time…
as for the other questions:
we are not using the Krak PRT loader at this time, although we have in the past and have seen the same behavior
we are not using any modifiers at this time
the frost object does not have any references to other objects in the scene
we are generally using VRay materials but it doesn’t seem to matter in this case
canceling frost when the update is triggered by my maxscript causes a maxscript interrupt exception to be thrown which is nasty (you can see this yourself with the test script)
This is actually a “bug” in MAXScript. Not really, but we have seen it happen a lot in production, and I have reported it to the Max developers.
In short, using the built-in collections “Cameras”, “Geometry” etc. does NOT access a pre-build array of objects. What happens is that internally, MAXScript does the equivalent to this:
theCameras = for o in objects where superclassof o == Camera collect o
Unfortunately, any call to superclassof() causes an implicit reevaluation of the modifier stack. So calling
for c in Cameras do print c
causes a reevaluation of EVERY SINGLE OBJECT in the scene, regardless of whether it is a Camera or not, just to find out if it is a Camera
It has the added drawback of including the Target of a camera, which is a GeometryClass object with invalid mesh…
This also explains the slowdown you might see sometimes when pressing C to set the viewport to Camera - Max has to run through all scene objects to find out what is a camera and set the viewport or populate the pick camera dialog…
This hits Particle Flow and Frost the hardest because they take a long time to evaluate, but it is true for any complex mesh or modifier stack.
For that reason, every script ever written at Frantic Films / Prime Focus / Thinkbox has the following alternative syntax:
theCameras = for o in objects where findItem Camera.classes (classof o) > 0 collect o
theGeometry = for o in objects where findItem GeometryClass.classes (classof o) > 0 collect o
and so on. This works because classof() does NOT force a full reevaluation, it only checks the result on top of the stack using the cached stack result. It will reevaluate conditionally if the validity interval is invalid, but otherwise will be MUCH faster.
So what you reported about Frost updating is not Frost’s fault, but MAXScript’s!
Interesting read! I’ve also got a question that is pointing into a similar direction. How is it possible to cache Frost meshes? I’ve also got a scene featuring > 50 Million particles coming from Realflow loaded into Frost via PRT loader. We are rendering multiple passes of that scene (more than ten) and because we don’t have a very advanced pipeline around here, each pass has an own scene (splashes_blurred.mb, splashes_noBlur.mb, KCM_Mask_01.mb…etc) and frost is building the same mesh over and over again. It was nice if we could have frost create some cache once and use that cahce for all render scenes that are using that very mesh. Is there a way to do it without building a vrayProxy for the mesh?
Here is also a Naiad-based, but still relevant tutorial about using XMesh with fluids.
Accidentally, the later frames of that sim also had 50M+ particles. thinkboxsoftware.com/xmesh-s … ing-frost/
