DH is filling RAM buffer in seconds even after render and load
I'm having trouble understanding how this mod affects RAM usage and how allocating more is supposed to do anything but influence the game to fill and clear the buffer inefficiently. LOD Render Distance radius is set to 56, but it behaves equally at 128 or 256. I have a beefy rig with a 12th gen intel i7-12700KF and an RTX 3070 3GB VRAM and 32GB RAM. CPU is only maxing sometimes, I've tried the CPU configs out. GPU is not being used without shaders.
I read a few other posts, but they didn't really come to good and/or clear conclusions for my curiousity. Currently, moving or looking anywhere will instantly fill a buffer of 11.5GB, previously 8GB. The game is at a constant 20fps while looking anywhere, it maxes at 42 when not moving or looking, with inventory open. This is with or without shaders, they don't affect the overall performance with DH thus far.
I've got a load of mods, many performance mods, and I can run this modpack just fine with shaders on at 80+ FPS more or less stably. DH causes this memory and render lag that will not go away until it's completely removed from the game. Why and how do I fix this if possible? DH shouldn't be affected by other mods, it's just a chunk loader and LOD renderer. I understand preloading a world and disabling chunk loading would help immensely, but what if I want to explore areas outside the preload?
More, turning off distant generation does not resolve this resource issue. It's still filling the buffer in seconds and I now max at 52 FPS in my inventory screen, and I still play at 20 FPS outside of it.
I'm pretty bummed I probably won't get to play with this mod in my desired mod environment, so any help understanding and fixing this abysmal performance would be great. Thanks!
10 Replies
I updated with PC specs
Sems like a memory leak. Send logs please
/logstored
You should send your
latest.log file to provide additional useful information.
Logs are located in the .minecraft/logs directory.
On Windows: %appdata%\.minecraft\logs
On Linux: ~/.minecraft/logs
On Mac: ~/Library/Application Support/minecraft/logs
Please upload the file to mclo.gs instead of sending the raw file. This makes reading the contents of the file a lot easier and improves the chances of you getting the help needed.
After uploading the file, click on Save and send the link.That command should be updated with mod platform info. For example, curseforge stores logs in the logs folder in the instance folders
also, I didn't see the bottom there
Also modlist
You don't need to send the modlist separately, its included in the log
I figured it'd be easier to read
But okay
Not the problem, but as a warning, you're using supplementaries, which is incompatible https://discord.com/channels/881614130614767666/1035937813310484540/1035943534945112096
You could try temporarily removing Yungs Bridges, as its erroring a lot
Yeah I wanted to see how it manifested in the LODs. If it causes giant black LOD chunks, then oh well. Yung's bridges is a pretty wild mod, I will try that.
I'll test both and get back
Okay, without bridges it's purging correctly. There is definitely a memory leak in Yung's Bridges. Unfortunately, the same FPS behavior is present while my CPU and GPU do... not much. 40% peak on both
Turning shaders on does not impact it meaningfully, as expected
Having to restart test without both mods, JEI's recipe load bugged out
No change without supplementaries and Supp^2
I'm gonna reset the config
No dice. At best DH just displays errors now
I figured this out, so Yung's bridges has a memory leak, but WF's Caves Overhaul unfortunately conflicts with something else that breaks the game. DH actually masks this behavior and improves the performance from 1FPS without DH to whopping 24-40FPS with DH. It works well without WFCO.