AWS Thinkbox Discussion Forums

Fost 2.1 & thinkingParticles cache load issue

Frost
#1

Hi,
When using tP directly as source on Frost, after cache and restart, frost make tP to revaluate from scratch tP cache on each frame, even if the cache is on Masterdynamic.

This process is a big pain when rendering on farm with deadline, since in this scenario case, on each frame, the cache will be revaluated from scratch (F000), but with cache on masterdynamic this should not happen, this should jump directly to the frame without evaluated from zero.

On a scene I’m rendering, the process can take 12 to 15 minutes PER frame, due to the cache re-evaluation frame by frame…

Scene File provided (MAx2017):
=> Open Scene, and Cache Masterdynamic
=> Save Scene, then close 3dsMAX (it’s important)
=> Open 3dsMAX, load scene.
=>Open tP interface (to see the particle count on the interface title bar):
-> jump to last frame : and check the particle increasing from F0 and evaluated each substep (this should not happen when using Masterdynamic).

the bug is also reported to Cebas.

This issue happen on my side only with Frost.

#2

We had TP 6.5 installed, I loaded your scene, it complained it was made with 6.6, but worked regardless. I repathed and rebuilt the cache, and had no issues rendering any frame in Frost without any pre-rolling.

I looked into updating to TP 6.6, but the Cebas Product Manager only gives me the option to go to 6.7.135.

It is possible that something broke in TP 6.6, but I have no way of testing that right now. I might give 6.7 a try…

#3

Updated to TP 6.7, still working as expected. Rendering 0 to 250 every 10th frame took under a second per frame on each frame, no pre-rolling. Putting the time slider at 0 and forcing a render of frame 250 via the Range controls also rendered in a second.
So I am pretty sure the MasterDynamic cache did its job right.
To compare, I deleted the cache files, switched to sim cache mode, and repeated the rendering of frame 250 while on frame 0. It took 6 seconds with prerolling…

Tested in both 3ds Max 2017 and 2018.

#4

Have you restart 3dsMAX, then reload the scene saved with the cache applied ?

If we do just after cache, or reloading the cache, it work just fine, but not if we open scene with the cache already applied, here is the case when I have the issue.

And this happen on all my slaves too, regardless of whether I use tP6.6, 6.7beta, max 2017 or max 2018…

Marc A.

#5

That’s the point, Masterdynamic should NOT do a prerolling.
=> disconnect frost from tP, save, reset scene, reload, jump timeline to F250 => no prerolling
=> reconnect frost, save, reset, reopen scene, jump timeline to F250 => prerolling
=> return to F000, just reload cache, jump to F250 => no prerolling : this one it the normal behaviour of Masterdynamic

When Cache on Masterdynamic, this should jump directly to frame then load the particles from that frame.

Somehow with Frost 2.1 connected to tP, Masterdynamic react like a dynamicSet
This happen only with Frost 2.1, imagine this with 1000+frames and/or hundreds of thousands of particles how time consuming this is, and we can’t use a MXS code to hack this on farm because if we manipulate tP interface throw MXS, it will force slaves to grab one tP network-sim licence, then will release it only when the slave have finish the all job).

#6

I saved the scene, closed Max, restarted Max, reloaded the scene, rendered frame 250 via Pickup Frames while the time slider was on 0 - it still rendered from the cache in 1 second without any pre-rolling.

In other words, I cannot seem to be able to replicate the issue in TP 6.7.

You are able to replicate the problem with the simple scene you sent me, right? Could you record a screencam video showing what you are seeing? I would love to watch it and see if there is anything you are doing that I am not doing…

#7

youtu.be/-l0fZQaDEew

video made from the scene above (Max2018 / tP 6.7.135, but same happen with Max2017 and tP 6.6 (official release)).

00:00 => 01:26 : Open scene, increase particle count (*5) and frame count to 500, to make isssue more obvious, then perform cache.

01:26 => 02:02 : directly after caching tP MasterDyn, jump to frame 500, tP jump directly to Frame 500 on cache load, and frost do the job ->That’s what is expected (done 2 times).Save scene and refresh max

02:03 => 04:28 : Reload scene with cache already applied , then jump to last frame and… tP evaluated each substep, even the cache was set on MasterDyn (top left ‘totals’ in tP interface), due to this, it take much much more time (done 2 times)

04:28 => 04:45 I just reload the cache (stop then play, to refresh the cache load on a fresh state), jump to F500 , instant tP update, like expected (done 2 times, just watching the clocks of video we can see there is something weird on previous one)

04:45 => 05:51 : disconect tP from Frost source, save scene, fresh reload of the scene, jump to F500, instant tP update , like expected (done 3 time, with 2 fresh reload of the scene), to show the normal behaviour of cache on Masterdynamic.

05:51 => 06:01 Reconect tP to Frost source, jump to F500, instant tP update.

06:02 => 07:29: save scene with tP as frost source, fresh reload the scene, with tP as frost source, and cache already set on Masterdyn. Jump timeline to F500 (done 1 times)
tP , again, with frost, revaluate MasterDyn on each substep and take much more time due to this.

CPU I9 7940X @ 3,84Ghz (14c/28th)

#8

Thanks for the video, very helpful!

Unfortunately, I can confirm that following your exact steps I am NOT getting the same behavior. But I am getting a different issue:

After resetting and reloading the saved scene (with or without Frost connected to the TP), I tend to get the TP cache not loading at all from disk when advancing the time line. It only updates when going backwards. So for example moving to the last frame does not update TP at all, going back a frame suddenly loads instantaneously. Since this occurs even without Frost in the scene at all (I deleted it), I suspect it is a glitch in TP, or I am doing something wrong with the cache. I tested both TPS sim cache and TPC frame cache, same result. Also, I am not a TP guru, so it is possible I am missing something…

Without being able to reproduce your exact problem, I am not sure how we can determine whether the problem is in Frost itself, in TP, or somewhere in between. The fact that you can reproduce it on two different 3ds Max versions and I cannot might point at a more complex problem. I have to wonder if the hardware could have an influence, as I am running on only 4c/8th Xeon E5-1620 in an HP Z420. Any chance you could run your test on a smaller machine to compare? How big are your render nodes?

#9

I have test on I9, I7 8 6 4 cores (and diffrent generations, so from 4 to last generation), I7 mobile (3rd generation), and even on a I5 (5th generation), all machines with same 3dsMAX and pluggins installed, all reproduced the issue on both max/tP version, and just because I could test it, even an old core 2 quad :slight_smile: .

In fact I already have the same issue on frost 2.0.14.

=> problem do not exist when using tP with FFX, Krakatoa (PRT source, but will happen with PRT source, if I connect frost to PRT source, itself connected to tP), Vray instancer, VRay metaballs…It happen just with frost loading tP…

Really weird, because if it was a hardware thing, this should not happen on all machines on my side…

#10

Ok, so it is probably not hardware-related. I have to wonder why my machine is not experiencing it.
I will have to test on some other machines, too :slight_smile: Unfortunately, this means I have to install TP on them first.

I am also going to assume this is an actual issue even without being able to reproduce it myself, and will pass it on to the Frost developer to see if he can reproduce it and figure out why it is happening…

#11

I’d ask to some tP/frost users, to test this…

If not hardware, but your station is not affected, there is something on mine + slaves + laptop + my others computers too that affect frost/tP…that’s really weird.

#12

Hi Marc,

I tested your scene and it’s working as expected on my side without a problem. I am using max 2018 and TP 6.6 drop 6 release, haven’t updated to new beta yet.

I tried both cache type tpc and tps and both are working as expected.

@Bobo : But I get this issue a lot with TP and Frost.

After doing TP simulation, I create multiple Frost objects and add different groups to different frost to create meshing. Now if I have to redo simulation sometimes or I scrub the timeline, then in some Frost objects TP groups go missing and in TP setup, it gets replaced by All group name instead of specific group name.

This happens a lot. But when I restart 3ds max, it solves the problem. This happens a lot with many scenes but only when multiple frost objects are used. I am not sure if this was reported before but I will try to create file.

EDIT : Just checked that I am on Frost 2.1 as well.

#13

Thanks, so look like I hav something installed, that screw on my machines frost/tP…need to find what. :open_mouth:

#14

Ok, so i try to remove plugins and delete app data, same thing happen.

So I decide to tweak Frost settings, to see if there is something on this side, and …surprise :sunglasses: :sunglasses: :confused: :
=> remove 'enable in viewport : instant update on tP side for rendering, but on viewport side, tP do not refresh, I need to set a frame -1 to have tP update (but as expected, no prerolling on masterdynamic, so it’s super fast

=> removing ‘enable in viewport’, and enabling ‘use render particle’ : now render is as expected (no prerolling on masterdynamic, and tP update too in viewport

=> removing ‘enable in viewport’, and enabling ‘use render particle’, and enabling ‘render using viewport settings’ : render fine, but viewport will update randomly (yes or not on fresh load), if not we need to do timeline -1 Or select Frost, then it work perfectly.

Here what I succed to isolate, but now I have a ‘hack’ to no longer have this prerolling weird thing…

Notes : same tested on 3 machines, to confirm the fix => ok for the 3 ones :slight_smile:

#15

3ds Max has two distinct internal states for updating scene content - Viewport, and Render.
Normally 3ds Max is in Viewport mode, unless you hit the Render button - this switches the internal state to Render mode, and updates all scene objects according to their render settings. For example, modifiers on the stack can be turned off in the viewport, but turned on in the renderer. Some modifiers (for example Turbosmooth) have separate values for the two modes. Some objects have radio buttons to only update at render time (e.g. Mesher compound). Some objects have dedicated viewport and render settings - both PFlow and TP can generate different particles depending on the mode…

The TP cache also has two states - Viewport and Render. So the particles that were cached could be based on the viewport state, or the render state. However I believe that the resulting cache is valid in both modes.

The settings you have manipulated in Frost tie into this Viewport/Render state system. When Enable In Viewport is unchecked, Frost is basically disabled when 3ds Max is not rendering. When you render, it asks TP to give it the render state particles, and meshes them.

When “Use Render Particles” is checked, and “Enable In Viewport” is also checked, Frost will temporarily switch to render state while asking TP for its particles, so the data it would get back would be based on the render settings of TP.

When “Render Using Viewport Settings” is checked, then the render-time meshing settings (the mesh quality controls) are taken from the viewport controls. So what you see in the viewport is what you get in the renderer in terms of mesh density.

When 3ds Max switches between Viewport and Render modes, Frost needs to update on each change. So let’s say you are on frame 0 and have a viewport mesh in the viewport based on the viewport particles. You hit render and it requests frame 250 via Pickup Frames or Custom Range. The scene is switched to Render context, and Frost asks TP to give it the render-time particles from frame 250. TP goes to the cache (if active), and grabs the particles and passes them to Frost. Frost generates the render-time mesh, and passes it on to the renderer. The renderer finishes and 3ds Max switches to Viewport mode. So the viewport needs to be updated with the viewport mesh. Frost asks TP for the particles on frame 0 in viewport mode, then meshes them, and updates the viewport.

It is possible that at some of these steps, the switching between Viewport and Render mode causes TP to ignore the cache and brute-force update the particles. In my setup here based on your scene which I have not modified at all, it appears that the same cache works for both viewport and rendering without brute-force pre-rolling. Which might be a glitch as you have a different experience…

#16

I understand, what diffrent setting do, what I do not understand, is the consequence on all my systems with tP/frost (and only tP, and for tP only with Frost :confused: ).

this still do not explain why all those reaction, that should not happen.

Except all the tweaking part, as soon as i am enabling mesh in viewport on frost side, my tP Masterdynamic evaluate every substep on load, wich is not the normal behaviour of masterdynamic
(when cache set on masterdynmic, you can jump from frame 5 to 3 000, the cache will just load and evaluate the F3 000, but not if i use Frost on a fresh load scene with cache aplyed already on mastedynamic with ‘enable in viewport’ checked…here tp will evaluate F0 1 2 3 4 5 6 et 3 000, not even talking about substep).

If I enable the Frost mesh in viewport, that’s where thing go crazy on all my system (do not look like it’s related to plugins, or appdata max ENU folder files, and look like not everyone is touched (worst look like i’m the first one experiencing this, but i experience this since 2.0.14 for sure :s, but since most of the time after set i disable the viewport mesh, now i know why…it was a good habit)…

Not sure what happen, but at least i found a way to have correct behaviour (just do not save with ‘enable in viewport’ before sending to farm/saving, when using tP as source).

I will try to ask on cebas forum, to see if some other people have this too or not (just sound crazy i’m the only guy having this issue )

#17

The crazy part is that I might be the only one who is NOT experiencing that problem :slight_smile:
I will make sure our Frost developer performs the same test on his computer and see if he can reproduce it.

#18

I’ve post the scene on tP beta forum, wait and see if some other user have the issue too…In any case, that’s weird, but i have a workaround…

#19

@Bobo : Did anyone experienced “Missing group” error when using multiple Frost objects with TP and using multiple groups? I get this a lot. I will try to reproduce this problem.

#20

First time I hear of it.
Thanks for reporting it, please send us a repro scene if you can…

Privacy | Site terms | Cookie preferences