I received a lot of messages lately stating that latest packs didn’t work anymore with recently released 1.16 Optifine. I wanted to delve a bit deeper into that issue and conducted some tests.
The 512x version was already pretty intensive but it seems that 1.16 itself is a bit heavier on memory than 1.14 used to be: even without additional, specific 1.16 blocks the same resourcepack was much more slow to load and prone to crashes under 1.16 than under 1.14. Accounting for the added 1.16 blocks this strain is even higher.
What it means is that being able to load a pack with 1.14 is no guarantee you’ll be able to do the same with 1.16. I’m looking into ways of alleviating the issue but it’s safe to say memory requirements might be higher than before. If you can’t run a specific pack resolution, you might need to load the immediate lower resolution instead.
I wanted to give you some insight on the tests I conducted and the conclusions I came to. Here’s a quick walkthrough.
First there is something to consider, the Java environment. Most of the time default options and built-in JRE are fine but I’ll show you how to alter this:
Then click the 1.16.1 OptiFine entry
Then you get this screen :
Exécutable Java (or Java Executable) can specify the Java runtime to use. If you leave it blank it’ll use the one shipped with the launcher in the \bin subfolder.
You can use another JRE instead, some can bring better performance, some can have better memory management. If it doesn’t work with built-in JRE you can try OpenJDK instead, in its HotSpot flavor (rumored to have a bit better performance) or the openj9 JVM version (rumored to have a bit better memory usage, I noticed a couple of % difference).
If you use a 3rd-party JRE I strongly recommend to download a .ZIP package and unzip it in a specific directory for Minecraft to use, that way you won’t overwrite your current Java install and possibly mess up some stuff in your system.
When the JRE is comfortably sitting in a folder, change the Java Executable option to use the javaw.exe file in the aforementioned folder.
The Arguments JVM (JVM Arguments) box can let you specify switches for the JVM. Here are the ones I’d suggest.
For the built-in Java runtime:
-Xmx4G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M
For the OpenJDK 14 JRE:
-Xmx4G -XX:+UnlockExperimentalVMOptions -XX:+UseZGC
You’ll notice the args for built-in JRE are mostly default ones. Some people prefer to use the -Xmx switch only, but YMMV. It shouldn’t hurt to leave the args to default for the built-in JRE.
You notice the -Xmx flags are specifying 4G. The value I’d recommend would be the smallest one that doesn’t crash your system. 4G is a safe bet, 2G can also work but might soon no more, too high a value can cause more issues that it would solve (because of Java’s garbage collection mechanism).
Some other things to consider when unable to load a resource pack is the Windows pagefile configuration.
I wanted once to move my pagefile to another SSD drive. Thing is, Windows seems to require a pagefile on the system disk. I then decided to create a small one on the C: system drive (like 500MB or so) and a 32GB one on a small SSD drive (called A: here) dedicated to temp files.
Problem was that Windows didn’t seem to be willing to use the A: drive’s pagefile when the small C: one was full. When trying to load my 512x pack I ran into an out of memory exception, as expected.
To check your pagefile, open your control panel (Win+R, then type sysdm.cpl, then hit enter).
open advanced parameters tab, in the performance box, click parameters:
then in the new window click the advanced tab, and finally in the virtual memory click change.
You can then choose to let Windows handle pagefiles entirely by clicking the Automatically manage paging file sizes for all drives checkbox at the top :
Or you can uncheck that checkbox and disable the pagefile on all drives except for the system one (usually C:) like so :
Lastly you can also choose to specify you own pagefile size (I’d recommend letting Windows handle pagefile size though), just make sure it’s large enough.
If minecraft crashes, you can try increasing that value by clicking the custom size radiobox, setting the indicated values in the Initial size and Maximum size textboxes, then clicking the Set button :
TL;DR Just remember that if you changed your pagefile parameters it can also be a cause for crashes in Minecraft with large resourcepacks.
Miscellaneous performance tips
Check the following switches in the options
> Enable Video Settings>Performance>Smart Animations
> If it’s not enough, set Video Settings>Animations>Terrain Animated to Off
> Activate Video Settings>Performance>Fast Render
> Disable Video Settings>Performance>Smooth World
> Set the Video Settings>Details>Trees setting to Smart
> Set the Video Settings>Details>Biome Blend to 3X3 or even Off
User realgerbagel on CurseForge just gave some feedback about loading the 512x pack with 1.16 and found that lowering/disabling mip-mapping could also lower memory requirements. The drawback is lowered performance because distant blocks will then try and load full resolution textures even if the resulting block only shows as a couple of pixels on the screen.
Another thing I was wondering about is whether using a .ZIP file versus a folder would make a difference. So I downloaded latest .ZIP on the laptop and ran the game with that .ZIP instead of the folders I usually use while designing. It didn’t crash.
I have two computers I can use to debug and benchmark :
- My main desktop machine -called HAWKING– is an AMD Ryzen7 3700x with an nVidia GeForce RTX 2070s (8GB VRAM) and 32GB system RAM.
- My older laptop -called TESLA– is an Intel i7 6700HQ with an nVidia GTX 1070 (8GB VRAM) and 16GB system RAM.
Here are the tests I conducted:
HAWKING - OpenJDK Java 14 JRE - Xmx4G - 512x v1.3.0
HAWKING - OpenJDK Java 14 JRE - Xmx4G - 512x v1.4.0 EA3
HAWKING - OpenJDK Java 14 JRE - Xmx2G - 512x v1.4.0 EA3
TESLA - Built-in JRE - Xmx2G - 512x v1.4.0 EA3Very long load times but eventually works well
Here’s a video I made showing TESLA running 1.16.1 OptiFine with Sildurs 1.28 extreme and Vanillaccurate 512x v1.4.0 EA3
and a video of my main PC loading the final 512x 1.4.0 pack. Loading times are quite large and physical memory is almost fully used but it works and gives decent FPS (the shader displayed here is Loop).
What it means is that for the time being, Vanillaccurate 512x should run on 1.16.1 even with a 16GB RAM system but might require 8GB VRAM. I don’t have a 6 or 4GB VRAM GPU somewhere so I can’t test that. If you can’t run the pack with less than 8GB VRAM you might consider go for a lower resolution.
But if you have 16GB system RAM and 8GB VRAM then 512x should definitely work on your system. I’ll closely monitor memory requirements to make sure I don’t cross some threshold that would cause the pack to be unable to run on 16GB RAM/8GB VRAM systems though.