I have 16gb of physical ram and I have seen the page file go up to 35gb total 'ram' when under load.
I have also done some more testing. Firstly, max2019 will never cause the problem to occur. I have tested 2019 by artificially limiting ram and committing changes to the 1024 displacement size map. Even when physical ram becomes maxed out windows or max will begin to compress ram and dump it to swap/pagefile. Eventually the commit will finish or crash(more on this later) but it will never cause the problem to occur. Max 2017 on the other hand, will "finish" the commit when the ram limit is reached but the resulting vmf export will be broken. This does not happen in max2017 if ram is not fully used up.
After seeing max 2019 work as it should I decided to stress test it to attempt to recreate the problem. I created a map consisting of 3136 512 displacements. This is almost the entire hammer grid and is something most users will never do. It takes a very long time to import this map and to create a sculpt mesh but it does work.
I applied a displace modifier to ensure every point is modified and began the commit. During commit I did not have any other programs running ensuing maximum ram for max. After a while of being 100% ram usage, my display driver crashed. When it recovered I was greeted with the attached error message. Just for fun I decided to export the level to see if the problem would happen. It didn't, and the exported map was simply the unmodified displacements.
So I think the problem is likely just max 2017(I did have sp3 installed this entire time btw). Still very strange that once the problem occurs it will persist across any version of max until the computer is rebooted.
Anyway I hope this helps!
I have also done some more testing. Firstly, max2019 will never cause the problem to occur. I have tested 2019 by artificially limiting ram and committing changes to the 1024 displacement size map. Even when physical ram becomes maxed out windows or max will begin to compress ram and dump it to swap/pagefile. Eventually the commit will finish or crash(more on this later) but it will never cause the problem to occur. Max 2017 on the other hand, will "finish" the commit when the ram limit is reached but the resulting vmf export will be broken. This does not happen in max2017 if ram is not fully used up.
After seeing max 2019 work as it should I decided to stress test it to attempt to recreate the problem. I created a map consisting of 3136 512 displacements. This is almost the entire hammer grid and is something most users will never do. It takes a very long time to import this map and to create a sculpt mesh but it does work.
I applied a displace modifier to ensure every point is modified and began the commit. During commit I did not have any other programs running ensuing maximum ram for max. After a while of being 100% ram usage, my display driver crashed. When it recovered I was greeted with the attached error message. Just for fun I decided to export the level to see if the problem would happen. It didn't, and the exported map was simply the unmodified displacements.
So I think the problem is likely just max 2017(I did have sp3 installed this entire time btw). Still very strange that once the problem occurs it will persist across any version of max until the computer is rebooted.
Anyway I hope this helps!