I migrated to 2018 about 6 months ago with fairly good results, except for the occasional crash. Lately in the past couple weeks, it has gotten to the point where opening a file, or auto-save, or adding a job to BB takes literally 10-15 minutes! So I did some checking and applied the latest “Update 3” patch which helped briefly, but not it’s back to the same old slowness. Rebooting, etc, doesn’t make a difference and I’m wondering now if there’s a script issue going on. I’m one who escapes out of auto-save (or tries to if I catch it early enough) because I find the frequency so annoying, even if I change the parameters. Anyhow, 2018 has become unworkable for me. In the absence of an official Service Pack yet, any other thoughts? I hate the thought of going back to 2017 since it’s such a headache to install across the farm…
I haven’t had much of any problems with 2018 in that way, anytime I have a file I think is acting up or running slow then I type “gc()” in the listener and that is supposed to clean out any crap that may be affecting the file like slower loading and saving than normal.
So I went through and stripped out all of my network asset paths and replaced them with new paths and that *seemed* to do the trick. Must have been some bad paths, or too many, or something. Anyhow, seems much better now (knocks on wood).
Aside from the long file open time, Max 2018 seems to be working OK (much discussed basic functionality glitches not with standing). Once the file is open File>Save is very fast. Autobak takes quite a bit longer but less than 1 minute.
The long file open time , 12 minutes, that I am experiencing is with a scene that has 9.5 million faces/286 Mbyte file size. Most of the faces are from Forest Pack objects.
A much simpler scene with about 60,000 faces opens in a matter of seconds.
Update:
I checked out my user path config. It was a pretty simple compact list of paths, but I cleaned it up a bit more. Made no difference in my case. Still 12 minute load time.
This project was started with Max 2016. Now I’m re-visiting it using 2018. Size is 9.5 million faces, especially heavy on Forest Pack. I worked on the FP stuff extensively for a good parts of two days… Max never crashed (just takes forever to load/open this file initially)..((probably just set some evil max 5d curse on myself))
Now using 2018.4 and I’m still experiencing the same lo…ng load time on the scene discussed above. Starting a new project now that is not very fqr along and doesn’t have much in it yet and no FP stuff. So far it loads up pretty fast. I think my problem with lo…ng loading time is scene specific
It does seem like the issue is scene-specific. I’m working on a different simple scene and it seems to be humming along well. Once additional thing with the scene in question that I discovered is that I had some xrefs in it. I converted those and it also seemed to help a lot.
If you have complex distributions, and many many objects, it will take a long time to process those on file open.
A telltale sign is the furious single-core activity, with or without memory occupation changes, as seen in the breakdance memes…
I am sure you are correct, the complex distributions and many many objects created by the various Forest Pack scatters are resulting in long file open time. thanks for confirming that is “normal”
Renderings of the scene that takes so long to load are here:
That is a very cryptic sentence<g> and I’m not sure I have it de-cyphered correctly.
<furious single core activity> I have a 10 core processor and I have seen, in task manager, during the long file load process the CPU is pegged at the upper limit @ 99.9%.
<memory occupation changes> Memory occupation is RAM usage? Little to no RAM usage during file open, once open using maybe 25% available memory.
<furious single core activity> I have a 10 core processor and I have seen, in task manager, during the long file load process the CPU is pegged at the upper limit @ 99.9%. Umh, maybe ForestPack does it on all cores.
Other operation, mostly max-related, unfortunately don’t.
But perhaps is something else entirely, i have no truth to offer…
<memory occupation changes> Memory occupation is RAM usage? Little to no RAM usage during file open, once open using maybe 25% available memory.
Yes, that is what i meant. However the full cores usage seems to discount my theory.
