After upgrading to version 4048 (dev build) WM became really unstable, random stutters. viewport not loading in… slow response time and the program not responding after literally doing any change to any device, etc etc… the ram usage also became SIGNIFICANTLY higher like 4x, its just stuff that didnt happen when i had 4045 installed and hardware shouldn’t be a problem. I just want to know if there’s an easy solution or if its something that happened to more people
1 Like
If this persists, downgrade to a previous version until a bugfix is released, that’s the only solution I can think of right now.
2 Likes
In terms of higher ram usage, can you share an example file (from WM or your own) that shows this difference? It should go the other way (HR is much more efficient) so that is very concerning.
The viewport behavior issue - by any chance do you have an AMD GPU?
I put a cheap last gen amd card in my older system for testing and was very surpised to find a GPU viewport issue much like you are reporting that doesn’t exist even on much worser (2013-era/laptop) graphics cards.
2 Likes
Currently using an rtx 3060 ti, and that’s what’s set in WM settings, the ram usage in the bottom right corner of the screen went up from 20 - 30gb (4045) to a 100gb+ (4048) Im doing 4k previews but that wasn’t an issue in my previous projects. I attached the file below
Hawadax Island.tmd (526.3 KB)
2 Likes
I suspect that the response time for editing/viewing is from the memory consumption - when WM runs out of memory and has to page things to and from disk, things can get very laggy.
Thank you for providing an example - I confirm your memory issue with that file. This is a high priority item so I will attempt to track it down soon.
2 Likes
Does the reading/writing speed of the disk make a difference?
1 Like
Definitely - paging works much better if your WM temporary folder is on a high speed SSD.
You can test to see if it is the high memory usage causing the viewport lag:
- Click on the preview controller in the bottom-right corner, and selecting “Archive all results”. This will page everything out to disk.
- Select a device. There may be a short lag as the data is brought back from disk, depending on the speed of your SSD.
- Select another device. Same as above
- If you select the first device again, there should be no lag this time.
2 Likes
Yeah. that’s the case here, when it reaches 100gb memory usage it takes a couple of seconds but with anything not much above 32gb its almost instant, the write/read speed of my disk is about 7gb/s so that’d make sense the only concern i have got is the fact that memory consumption wasn’t that high in 4045, regardless thanks for providing the info
1 Like
It appears the root-cause is that in 4047+, Macros are keeping their ‘low res’ preview results even when the macro is closed. When your maximum preview level is set relatively high (which is recommended!), and you have complex/nested macros, it will cause extremely high and unwarranted memory consumption as noted here.
This is an easy fix, but there are many subtle interactions here so it has to be done carefully. For example, keeping that additional preview data allows macros to preview much quicker as they can invalidate only the necessary components that are involved with a parameter adjustment. I’ll have to think on what the right balance to strike here is.
Until then, I would recommend lowering your preview res limit to something much smaller if you are being heavily affected by this issue. You can also always click on the preview controller and “purge results” to remove the excess packets manually.
4 Likes
This is indeed a question worth pondering. I understand what you mean. In order to support dynamic parameter changes, it seems that the outputs of all sub devices of the macro are preserved. I think the simplest way is to add an option in the build settings for users to choose between the two methods, but this may only be a temporary solution.
My current thinking is that in order to support dynamic parameter changes, not all results generated by macro devices must be retained. Only the input data of devices controlled by macro parameters needs to be retained (i.e. data from the input ports of each subsequent device connected to the macro’s Parameters device). Is this the smallest memory usage method I can think of, or have you already done it?
2 Likes
I have set the memory conservation to maximum, Im not sure what else i can do to decrease the ram usage thought
1 Like
Reduce the ‘Refine until resolution’ maximum preview size:
The issue here is preview results are being kept within the macro, and memory conservation settings don’t affect preview builds (so that you can still edit the world effectively). Reducing the maximum resolution the previewer builds to works around the issue.
The next maintenance release will likely revert macro preview behavior back to prior, as although the speedier macro builds are nice, the potentially huge memory cost is too high.
3 Likes
Alright, a setting could be made which enables macro previews so the people who want to work with macros and effectively see how the changes affects the scene can tick it on, but when working outside of macros which eat up a lot of ram the setting could be ticked off
1 Like