Sudden Stop At Exporting

[Fyoncle]

java.lang.RuntimeException: No blockstate file for supplementaries:wild_flax at nl.bramstout.mcworldexporter.model.BlockStateRegistry.getStateFromName(BlockStateRegistry.java:98) at nl.bramstout.mcworldexporter.model.BlockStateRegistry.getIdForName(BlockStateRegistry.java:68) at nl.bramstout.mcworldexporter.world.Chunk.renderChunkImage(Chunk.java:392) at nl.bramstout.mcworldexporter.ui.Renderer2D$LoadChunkTask.run(Renderer2D.java:367) at nl.bramstout.mcworldexporter.parallel.ThreadPool$Worker.run(ThreadPool.java:127) at java.base/java.lang.Thread.run(Unknown Source) Exception in thread "D3D Screen Updater" java.lang.OutOfMemoryError: Java heap space at java.desktop/sun.java2d.d3d.D3DScreenUpdateManager.run(Unknown Source) at java.base/java.lang.Thread.runWith(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Exception in thread "Thread-5" java.lang.OutOfMemoryError: Java heap space at nl.bramstout.mcworldexporter.world.Chunk$LoadedChunksGC.run(Chunk.java:63) at java.base/java.lang.Thread.runWith(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError at java.base/java.util.concurrent.ForkJoinTask.reportExecutionException(Unknown Source) at java.base/java.util.concurrent.ForkJoinTask.get(Unknown Source) at nl.bramstout.mcworldexporter.export.ChunkExporter.optimiseMeshes(ChunkExporter.java:1168) at nl.bramstout.mcworldexporter.export.Exporter$ExportChunkTask.run(Exporter.java:262) at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(Unknown Source) at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source) at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source) at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source) Caused by: java.lang.OutOfMemoryError at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source) ... 10 more Caused by: java.lang.OutOfMemoryError: Java heap space

I think i don't have enough ram for this 700x700 world, is that normal

[Fyoncle]

I have 16 GB ram

[Fyoncle]

Stuck at 12 GB ram usage again when i have even more, it said this

java.lang.RuntimeException: No blockstate file for supplementaries:wild_flax at nl.bramstout.mcworldexporter.model.BlockStateRegistry.getStateFromName(BlockStateRegistry.java:98) at nl.bramstout.mcworldexporter.model.BlockStateRegistry.getIdForName(BlockStateRegistry.java:68) at nl.bramstout.mcworldexporter.world.Chunk.renderChunkImage(Chunk.java:392) at nl.bramstout.mcworldexporter.ui.Renderer2D$LoadChunkTask.run(Renderer2D.java:367) at nl.bramstout.mcworldexporter.parallel.ThreadPool$Worker.run(ThreadPool.java:127) at java.base/java.lang.Thread.run(Unknown Source) Exception in thread "D3D Screen Updater" java.lang.OutOfMemoryError: Java heap space at java.desktop/sun.java2d.d3d.D3DScreenUpdateManager.run(Unknown Source) at java.base/java.lang.Thread.runWith(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Exception in thread "Thread-5" java.lang.OutOfMemoryError: Java heap space

[Fyoncle]

Now it used all of my CPU then didnt respond, then closed, opened, closed, opened, freezed, lagged, got invisible, closed, opened....... weiird....

[BramStout]

If MiEx runs out of memory and you have more available, then it could be that the Java Virtual Machine is limiting memory usage. This can happen if you are running 32-bit Java. In the log at the top it'll say what version of Java you are running and whether it's 32-bit or 64-bit. It could also be that the JVM has some max heap size set. You can tell the JVM how much memory it's allowed to take with the following command line argument -Xmx16G this will set the maximum memory that it can use to 16 gigs. You can also set it to some other value.

Memory usage grows linearly with the amount of threads that MiEx uses for exporting. By default MiEx calculates how many threads to use by taking the number of cores and subtracting 4. So if you have a CPU with 8 cores and 16 threads, then it'll do 16-4 which means it uses 12 threads.

You can control how many threads MiEx uses with the environment variable MIEX_NUM_UI_THREADS or the command-line argument -numUIThreads <number> and setting the value to a number. The number is what gets subtracted from the core-count of your CPU, which by default is a value of 4.

So, you could also try specifying a larger number like 8 or 12 and see if that makes an improvement.

[Fyoncle]

If MiEx runs out of memory and you have more available, then it could be that the Java Virtual Machine is limiting memory usage. This can happen if you are running 32-bit Java. In the log at the top it'll say what version of Java you are running and whether it's 32-bit or 64-bit. It could also be that the JVM has some max heap size set. You can tell the JVM how much memory it's allowed to take with the following command line argument -Xmx16G this will set the maximum memory that it can use to 16 gigs. You can also set it to some other value.

Memory usage grows linearly with the amount of threads that MiEx uses for exporting. By default MiEx calculates how many threads to use by taking the number of cores and subtracting 4. So if you have a CPU with 8 cores and 16 threads, then it'll do 16-4 which means it uses 12 threads.

You can control how many threads MiEx uses with the environment variable MIEX_NUM_UI_THREADS or the command-line argument -numUIThreads <number> and setting the value to a number. The number is what gets subtracted from the core-count of your CPU, which by default is a value of 4.

So, you could also try specifying a larger number like 8 or 12 and see if that makes an improvement.

Where to put -Xmx16G? also my java is 64 bit

[Fyoncle]

This ram usages are too high for a world in this size honestly, it wasn't like that before, i could even export bigger worlds with no problem, but MiEx got some broken stuff in the latest release on github i think?

[BramStout]

Where to put -Xmx16G? also my java is 64 bit

If you launch MiEx via the command-line, then you can add that in as a command-line argument for the JVM.

This ram usages are too high for a world in this size honestly, it wasn't like that before, i could even export bigger worlds with no problem, but MiEx got some broken stuff in the latest release on github i think?

How much ram MiEx uses can depend on a few factors. One of the biggest one can be the use of modded worlds. Modded worlds generally have a high variation of blocks, which means lots of unique textures being used. Each texture becomes its own material and MiEx exports a single mesh per material per export chunk. So, the more textures being used, the more meshes being created which increases memory usage. Using atlases can significantly reduce the amount of individual textures and thus help with memory usage.

The current version of MiEx doesn't have broken stuff, but it has some stuff that is inefficient regarding memory usage. But those were things that were always in MiEx. In the next version of MiEx I have spent a lot of time optimising memory usage, which does allow MiEx to export out the same world with about a third the memory.

[Fyoncle]

Where to put -Xmx16G? also my java is 64 bit

If you launch MiEx via the command-line, then you can add that in as a command-line argument for the JVM.

This ram usages are too high for a world in this size honestly, it wasn't like that before, i could even export bigger worlds with no problem, but MiEx got some broken stuff in the latest release on github i think?

How much ram MiEx uses can depend on a few factors. One of the biggest one can be the use of modded worlds. Modded worlds generally have a high variation of blocks, which means lots of unique textures being used. Each texture becomes its own material and MiEx exports a single mesh per material per export chunk. So, the more textures being used, the more meshes being created which increases memory usage. Using atlases can significantly reduce the amount of individual textures and thus help with memory usage.

The current version of MiEx doesn't have broken stuff, but it has some stuff that is inefficient regarding memory usage. But those were things that were always in MiEx. In the next version of MiEx I have spent a lot of time optimising memory usage, which does allow MiEx to export out the same world with about a third the memory.

Even if i allocate max amount of ram i have, MiEx still doesn't work, plus that is not a modded world, plus i used 64 chunk size.

[Fyoncle]

Mineways perfectly worked, but MiEx still doesn't wanna stop killing my CPU when its not even working.

[BramStout]

plus i used 64 chunk size.

What happens when you try exporting the same region but with a chunk size of 16 rather than 64? That should help me figure out what's causing the large amount of memory used

[Fyoncle]

plus i used 64 chunk size.

What happens when you try exporting the same region but with a chunk size of 16 rather than 64? That should help me figure out what's causing the large amount of memory used

I didn't try yet, ill see soon!