I am absolutely astounded that we are at 1.8.7 and yet there is STILL no sign that this will be implemented any time soon. Quad-core processors are pedestrian these days, and even more powerful CPU's are on the rise. Not utilizing the vast power of these chips for gaming is senseless.
Sounds nice. I have I think 8 cores so this might be very beneficial.
As per what OreCruncher said, the game already uses multi-threading, but in a different way. 1.8 and above has moved world management and dimensions off to their own threads, so the Nether, Overworld and End will each run in their own concurrent threads, meaning a heap of blocks slowing down the Overworld shouldn't affect the Nether.
Optifine also offers a multi-threading option for splitting world generation among several threads, so the world will load better (depending on your CPU of course).
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I run a Modded Minecraft server on a Dell Poweredge 2850 with 2 Xeon quad-core CPUs at 3.4GHz a piece this would be a really nice feature to have as i have noticed 8 threads run but only 1 of my CPU cores are being used and optifine will not run on a headless server as its a client only mod
Notch quit working on minecraft around 2012. The people blaming him haven't done any research. Like orecruncher said minecraft is multithreaded. you can't add more threads cause the cpu supports it. Some stuff need to be synchronised.
Dug out the username and password just to say... I fully support this!
My computer has a great graphics card, 12gb of DDR3 RAM and... a quad-core CPU. I was so annoyed when I looked at task manager and realized only one core was used. It would be GREAT if Minecraft could use all of those cores.
Dug out the username and password just to say... I fully support this!
My computer has a great graphics card, 12gb of DDR3 RAM and... a quad-core CPU. I was so annoyed when I looked at task manager and realized only one core was used. It would be GREAT if Minecraft could use all of those cores.
No offense, but why would you need such a powerful PC for Minecraft xD
Anyway, back on topic, I would agree with this idea. I'd need the extra fps boost!
Rollback Post to RevisionRollBack
I just took the Minecraft Noob test! Check out what I scored. Think you can beat me?!
I've always wanted to see Minecraft programmed in C, instead of Java, and yes, with much milti-threaded support. SDL2 and OpenGL would be great platforms to program Minecraft in. I wonder just how efficient Minecraft really even is.
If terrain is generated by an algorithm, and the "surface area" of large lumps or deep layers of materials is less than 1/4 the total volume of blocks by a large amount, memory can be drastically reduced and performance boosted. Why less than 1/4th? Because if you load every individual block, all you need is to load and store the block id's in an exact order, but if you load the surface area of materials, you need a block id, and three values for 3D coordinates for every block.
This may all ready be the case, but I don't really know. Being programmed in SDL2 would be great though. I support multi-threaded Minecraft.
Rollback Post to RevisionRollBack
I'm just recording the construction process of my Ultimate, minimum redstone Mob Grinder (And having way too much fun with the video editor!)
This needs to be done in a coherent way. At least the chunk loader sould be on a seperate thread, but that would require a redesign of the way chunk loading works in order to have all required chunks loaded and cached before the main thread needs to access that information. But that again xould lead to eccessive tick lag or chests being opened and lag until they show up their content etc, pretty much anything that would need to access the loaded data from the chunk could potentially lag this way because there is basically not enough cache available to have quick access to all the loaded data. Now talking about chunk generation, I have heard that this could be done very efficiently by the gpu but that would probably require a ton of work.
The main thing however is rendering. I have heard that a big part of the rendering of the game is done by the cpu. This sould stop immediately, not by multythreading the rendering workload, but by moving it to the gpu and have one core talking to the gpu about it, which is still not easy and no mod can do because of fears that it would break compatibility with other mods, so this needs to be done in vanilla.
The good thing is, there have allready been taken steps towards this direction by taking rendering away from the hardware, especially in terms of swapping the render_block from 1.7.10 for the 1.8 model system, but modders rebelled against these changes is, due to extensive re-writes ofvtheir mods that are needed in order to port them, even though these changes are for the best
The "rebellion" isn't solely due to the amount of work to update, if an update is good enough for all cases modders will eagerly and painfully update to accompany the change (see the move to String IDs in 1.7 along with moving networking to Netty, or the unification of client and server to the client and internal server in 1.3, or the resource pack system that 1.6 introduced, or the new texture formats that 1.5 introduced...).
The problem with 1.8's model format isn't how bad the rewrites are, those can largely be overlooked as programs generate JSON files for you and you can easily bury the code into classes and extend those classes to automatically run the code without having to do much (I used this to both set the IDs of blocks and items, and set the texture simultaneously in not only Thaumic Machina, but also other mods I've previously worked on). The problem with 1.8's model format is in how bad it is for certain scenarios, specifically anything requiring a dynamic rendering context that is reliant on adjacent blocks and other metadata to determine what to render, for instance Buildcraft's pipes. Under the old model system Buildcraft could selectively hide voxels and swap textures dynamically for any block instance determined by metadata: adjacent pipes and blocks determine which sides are rendered, the type of pipe determines how the pipe should be rendered, gates are dynamically rendered on top of pipes, not to mention red pipe wiring and all the different colours. It's just a matter of using an ISimpleBlockRenderingHandler, which is only called when a block update occurs (versus every rendering tick for TileEntitySpecialRenderers), along with clever logic to determine how a block should render, and this only occurs whenever the block itself is updated. Versus the current model system where Buildcraft has to explicitly define each model state in individual JSON files, which not only is a lot of work, but legitimately cannot be done as the most models that 1.8 offers is 65536 for every single block in the game (65536 for every block model, not just the current model states). IIRC someone worked out that for this to work, there'd be at least some 4 million or so different explicit model states, 4 million plus does not go into 65536.
That's why the model format was hated, not because of how hard it was to move to, but because of how poor a job Mojang did designing the system to be context-independent. Some changes in 1.9 have made things a little easier, though the problems are still there in different forms.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
This needs to be done in a coherent way. At least the chunk loader sould be on a seperate thread, but that would require a redesign of the way chunk loading works in order to have all required chunks loaded and cached before the main thread needs to access that information. But that again xould lead to eccessive tick lag or chests being opened and lag until they show up their content etc, pretty much anything that would need to access the loaded data from the chunk could potentially lag this way because there is basically not enough cache available to have quick access to all the loaded data. Now talking about chunk generation, I have heard that this could be done very efficiently by the gpu but that would probably require a ton of work.
The main thing however is rendering. I have heard that a big part of the rendering of the game is done by the cpu. This sould stop immediately, not by multythreading the rendering workload, but by moving it to the gpu and have one core talking to the gpu about it, which is still not easy and no mod can do because of fears that it would break compatibility with other mods, so this needs to be done in vanilla.
The good thing is, there have allready been taken steps towards this direction by taking rendering away from the hardware, especially in terms of swapping the render_block from 1.7.10 for the 1.8 model system, but modders rebelled against these changes is, due to extensive re-writes ofvtheir mods that are needed in order to port them, even though these changes are for the best
I believe your slightly misinformed...
rendering is basically math computations at a very fast rate. moving them to the gpu would be good/bad. some computers will get a speed boost, while others will be reduced significantly. plus, gpu math is more complicated and the game could need a re-write to fit in gpu operations.
i believe gpu operations are not natively supported by the jvm, project sumatra, aims to bring gpu support directly in the jvm with the support of JIT (just in time).
the 1.8 model system is basically moving to json files, it doesn't take a step further into gpu support.
rendering is basically math computations at a very fast rate. moving them to the gpu would be good/bad. some computers will get a speed boost, while others will be reduced significantly. plus, gpu math is more complicated and the game could need a re-write to fit in gpu operations. 1
i believe gpu operations are not natively supported by the jvm, project sumatra, aims to bring gpu support directly in the jvm with the support of JIT (just in time). 2
the 1.8 model system is basically moving to json files, it doesn't take a step further into gpu support. 3
1 Really depends on what Mojang moves to the GPU. Simple lighting using physically-inaccurate linear (or even exponential) attenuation like what shader packs use to alter how far torch lighting affects can be really simple to calculate, whilst outright using cascading shadow maps to render dynamic shadowing in real-time could be taxing on some lower end hardware. Simple lighting models that use physically-inaccurate attenuation and either no or extremely simple shadowing could get the job done.
2 What HeadsUpHigh is referring to by moving things to the GPU is moving certain rendering tasks like lighting over to the GPU, which would be done through shaders written in GLSL (the OpenGL Shading Language). You talk to shaders through OpenGL, which the game uses an OpenGL binding available in LWJGL. In other words, what HeadsUpHigh is referring to has nothing to do with Java itself, rather the implementation of shaders within the game.
The game uses shaders internally, however what other 3D games typically do in shaders, such as lighting, Minecraft does on the CPU, which kills performance but means that lighting information is readily accessible from anywhere within the game's source code, at any time (theoretically).
3 You are correct in saying that the model format essentially does nothing for moving the game to the GPU, though 1.8 in general included optimisations to the renderer which involves utilising the GPU for more things such as frustum and occlusion culling and integrated shaders support, and multi-threaded rendering and dimension management.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I am absolutely astounded that we are at 1.8.7 and yet there is STILL no sign that this will be implemented any time soon. Quad-core processors are pedestrian these days, and even more powerful CPU's are on the rise. Not utilizing the vast power of these chips for gaming is senseless.
Support, would be great to utilize all four of my cores instead of just 1.
Actually "Minecraft" is multi-threaded, but not the way folks are tossing the word around.
Sounds nice. I have I think 8 cores so this might be very beneficial.
My Scroll.
As per what OreCruncher said, the game already uses multi-threading, but in a different way. 1.8 and above has moved world management and dimensions off to their own threads, so the Nether, Overworld and End will each run in their own concurrent threads, meaning a heap of blocks slowing down the Overworld shouldn't affect the Nether.
Optifine also offers a multi-threading option for splitting world generation among several threads, so the world will load better (depending on your CPU of course).
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I run a Modded Minecraft server on a Dell Poweredge 2850 with 2 Xeon quad-core CPUs at 3.4GHz a piece this would be a really nice feature to have as i have noticed 8 threads run but only 1 of my CPU cores are being used and optifine will not run on a headless server as its a client only mod
Lets see if we can get this in the game
Notch quit working on minecraft around 2012. The people blaming him haven't done any research. Like orecruncher said minecraft is multithreaded. you can't add more threads cause the cpu supports it. Some stuff need to be synchronised.
Dug out the username and password just to say... I fully support this!
My computer has a great graphics card, 12gb of DDR3 RAM and... a quad-core CPU. I was so annoyed when I looked at task manager and realized only one core was used. It would be GREAT if Minecraft could use all of those cores.
No offense, but why would you need such a powerful PC for Minecraft xD
Anyway, back on topic, I would agree with this idea. I'd need the extra fps boost!
I just took the Minecraft Noob test! Check out what I scored. Think you can beat me?!
To take the test, check out
https://minecraftnoobtest.com/test.php
I've always wanted to see Minecraft programmed in C, instead of Java, and yes, with much milti-threaded support. SDL2 and OpenGL would be great platforms to program Minecraft in. I wonder just how efficient Minecraft really even is.
If terrain is generated by an algorithm, and the "surface area" of large lumps or deep layers of materials is less than 1/4 the total volume of blocks by a large amount, memory can be drastically reduced and performance boosted. Why less than 1/4th? Because if you load every individual block, all you need is to load and store the block id's in an exact order, but if you load the surface area of materials, you need a block id, and three values for 3D coordinates for every block.
This may all ready be the case, but I don't really know. Being programmed in SDL2 would be great though. I support multi-threaded Minecraft.
I'm just recording the construction process of my Ultimate, minimum redstone Mob Grinder (And having way too much fun with the video editor!)
Click here to watch
The "rebellion" isn't solely due to the amount of work to update, if an update is good enough for all cases modders will eagerly and painfully update to accompany the change (see the move to String IDs in 1.7 along with moving networking to Netty, or the unification of client and server to the client and internal server in 1.3, or the resource pack system that 1.6 introduced, or the new texture formats that 1.5 introduced...).
The problem with 1.8's model format isn't how bad the rewrites are, those can largely be overlooked as programs generate JSON files for you and you can easily bury the code into classes and extend those classes to automatically run the code without having to do much (I used this to both set the IDs of blocks and items, and set the texture simultaneously in not only Thaumic Machina, but also other mods I've previously worked on). The problem with 1.8's model format is in how bad it is for certain scenarios, specifically anything requiring a dynamic rendering context that is reliant on adjacent blocks and other metadata to determine what to render, for instance Buildcraft's pipes. Under the old model system Buildcraft could selectively hide voxels and swap textures dynamically for any block instance determined by metadata: adjacent pipes and blocks determine which sides are rendered, the type of pipe determines how the pipe should be rendered, gates are dynamically rendered on top of pipes, not to mention red pipe wiring and all the different colours. It's just a matter of using an ISimpleBlockRenderingHandler, which is only called when a block update occurs (versus every rendering tick for TileEntitySpecialRenderers), along with clever logic to determine how a block should render, and this only occurs whenever the block itself is updated. Versus the current model system where Buildcraft has to explicitly define each model state in individual JSON files, which not only is a lot of work, but legitimately cannot be done as the most models that 1.8 offers is 65536 for every single block in the game (65536 for every block model, not just the current model states). IIRC someone worked out that for this to work, there'd be at least some 4 million or so different explicit model states, 4 million plus does not go into 65536.
That's why the model format was hated, not because of how hard it was to move to, but because of how poor a job Mojang did designing the system to be context-independent. Some changes in 1.9 have made things a little easier, though the problems are still there in different forms.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I believe your slightly misinformed...
rendering is basically math computations at a very fast rate. moving them to the gpu would be good/bad. some computers will get a speed boost, while others will be reduced significantly. plus, gpu math is more complicated and the game could need a re-write to fit in gpu operations.
i believe gpu operations are not natively supported by the jvm, project sumatra, aims to bring gpu support directly in the jvm with the support of JIT (just in time).
the 1.8 model system is basically moving to json files, it doesn't take a step further into gpu support.
1 Really depends on what Mojang moves to the GPU. Simple lighting using physically-inaccurate linear (or even exponential) attenuation like what shader packs use to alter how far torch lighting affects can be really simple to calculate, whilst outright using cascading shadow maps to render dynamic shadowing in real-time could be taxing on some lower end hardware. Simple lighting models that use physically-inaccurate attenuation and either no or extremely simple shadowing could get the job done.
2 What HeadsUpHigh is referring to by moving things to the GPU is moving certain rendering tasks like lighting over to the GPU, which would be done through shaders written in GLSL (the OpenGL Shading Language). You talk to shaders through OpenGL, which the game uses an OpenGL binding available in LWJGL. In other words, what HeadsUpHigh is referring to has nothing to do with Java itself, rather the implementation of shaders within the game.
The game uses shaders internally, however what other 3D games typically do in shaders, such as lighting, Minecraft does on the CPU, which kills performance but means that lighting information is readily accessible from anywhere within the game's source code, at any time (theoretically).
3 You are correct in saying that the model format essentially does nothing for moving the game to the GPU, though 1.8 in general included optimisations to the renderer which involves utilising the GPU for more things such as frustum and occlusion culling and integrated shaders support, and multi-threaded rendering and dimension management.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!