Wall Worm Forums

Hi, any update on this matter?

Thank you.

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 will need to investigate. The colors and settings are always working for me so I will need to have more info and look into it.

* What version of Max (and what service packs).
* What version of WW
* WW Free or WW Pro

I remember that I had some sort of viewport glitching issue with 2017 on my older computer, which had an AMD HD 5870. If at any point I continued working on a scene, or even just moving the viewport, it would leak more and more RAM-usage until it crashed. Unfortunatly the issue was tied to 2017, so it's probably not the issue at hand. However, do make sure you have:

• Latest Windows update
• Latest GPU driver
• Latest 3DS Max security Fix (2017)
• Latest 3DS Max Service pack (2017)
• Latest 3DS Max Service pack (2019)

Those are at least what fixed my problems in 2017. For 2019, however, no idea  if you have NVIDIA, you shouldn't even have this problem at all. Perhaps in the end you're lacking the necessary amount of RAM to make the calculations as required by the amount of displacements.

Today I have been dealing with quite a strange issue concerning exporting large amounts of displacements.

I first create a simple map made up of many displacements in hammer. I then import the map into max, create a sculpt mesh, edit the displacements, commit the changes, and finally export the scene as a vmf. When I open this export in hammer everything is all messed up. I have made a video showing the whole process since it is kind of hard to explain how this looks.

I was originally using max 2017 with an older version of wallworm. The first thing I did to try and solve my problem was updating to the latest wallworm, this did nothing. I tried altering the map in many ways, changing the size of displacements, lowering the count of displacements, not creating displacements at all in hammer, etc etc. no change. When changing the size of my displacements from 1024 to 512 I did however begin to get a maxscript garbage collection error on vmf export.

I installed 3ds max 2019, followed the same process, and got the exact same result, but now with no errors at all. I then tried the process on an older computer running max 2013 and wall worm 2.61 and it WORKS ! So this makes me think the problem is with my computer somehow. I have recordings of me editing and exporting displacements in this exact same way from 2018 so something COULD have changed since then.

To make things more confusing, I finally did the unthinkable... I rebooted my pc. I launched max 2017 and did the same process. To my surprise this actually fixed the issue. I still got the maxscript error on export but the file did correctly export and looked totally normal in hammer. Great I thought 'Now I will try the larger 1024 version'!. As you can guess this broke things again across both versions of max. The 1024 version consists of 28x28 1024 cube brushes with a displacement on the top face's.

When I commit changes, max will lock up and slowly begin using a lot of ram. I noticed when using 2017 my ram actually fills up fully before the commit completes. I was running chrome however. It is very strange closing max does not fix the problem.

I try another reboot. This time I load max 2019 and the larger 1024 map first. I did the same process and this time it worked! Next, without closing the working project, I apply a displace modifier to my sculpt mesh and a very basic height map. I did this so every point of the sculpt mesh would be changed, simulating a worse case scenario. I commit all changes, export to vmf, and the map works!

I believe the root of the issue is ram related, but again this may be a problem specific to my system. For now I will just have to split up my sculpt meshes. I don't know if this problem can be fixed or helped in any other way (besides buying more ram).  Hopefully anyone else having this problem will see this post in the google search results and maybe it will help them.

Here is the video I recorded before I figured out that rebooting my computer would fix things.