My idea was to use worldedit to select the entire underground of a large area, and use a command to replace all of the sand/gravel/water/lava/air with just plain old stone. Theoretically, stone should be faster, because it performs less calculations than gravity affected blocks, and isn't animated. So I tested it multiple times, with great success. In some cases, I gained 50fps. However, I suspect the effect may not be so great if your system is already struggling to run the game. Though it still might be a worthwhile boost. Especially if your projects are above ground, and you don't care about the underground blocks being replaced with stone. I think this can be done without Worldedit, using the vanilla fill command, albeit, not quite as easily. Can some other people try this out to confirm whether this is as great as i think it is, or if I just need some more sleep... Lol.
Here is a quick video I made showing 2 test runs, which both returned massive fps gains:
And by the way, do any of you guys know if there's any blocks in this game that are somehow even less demanding than stone? Maybe stone performs some sort of calculations I'm not aware of. And am I right in assuming that light-emitting blocks such as beacons are quite demanding, and in large numbers will increase lag? I have noticed that while in the heart of my city, with loads of light sources, the game slows to a crawl. Which is why I wanted to optimise the underground in the first place. every extra frame counts!
There should be no difference between sand and stone because there are no calculations being done unless a block update occurs; it does not constantly check to see if it should fall or you wouldn't be able to find floating sand, and besides, that is a server performance issue, not a client-sided (FPS) one (unless you still have a single-core CPU as the client and server run on separate threads). Also, light sources by themselves do not cause lag; it is because beacons are tile entities which use a TESR (TileEntitySpecialRenderer) which re-renders the beam every single frame, much as entities render (which is why too many cause lag); by contrast, the game only re-renders "normal" blocks when a chunk update occurs. Particles, including torch flames and water/lava particles, can reduce performance but the game only renders particles within a short distance of the player (blocks further away have no effect at all since most block particles are rendered by randomly selecting blocks around the player and rendering any particle effects they may have).
Rendering animated textures on simple blocks like water does not make a noticeable difference unless you actually stop the animation process itself, which means using Optifine to disable them, since the game updates the textures once per frame regardless of whether they are being displayed (it updates the entire texture atlas which contains the textures for every block; re-rendering every chunk with an animated block would be far too expensive). Another way to reduce lag from animated textures is to tun mipmaps off, since it has to update the textures for every mipmap level, and/or use a lower resolution resource pack (the size of the texture atlas determines how expensive it is to update and upload it to the GPU so just making the animated textures a lower resolution will not do much).
The most significant improvement by far and away is that you greatly reduced the amount of surfaces the game has to render by filling in caves, although the game is supposed to hide chunks that are not visible (prior to 1.8 you could toggle this with the "Advanced OpenGL" setting which made a huge difference for me, as in playing on Normal render distance vs Short, especially in my mods which made the ground much deeper with the size of cave systems scaled up in 3D. Notably, I did not notice any difference in FPS in vanilla vs a triple-depth world when AOGL was enabled, it was that good at hiding unseen chunks. Since 1.8 they use a custom method which may not be as good, plus it runs on the CPU instead of GPU).
The amount of blocks that the game actually has to render is surprisingly small; a Superflat world only has to render 256 faces per chunk regardless of how deep it is (the game, or rather, GPU, does not render the back side of most blocks, which can be seen with blocks like glass, so only the visible surfaces facing you are rendered and a cube can have no more than 3 sides visible at any one time); the "beefy computer" warning for Amplified has more to do with the amount of faces that the game needs to render due to more variable and higher terrain than the amount of terrain itself, and likewise, the biggest way Fast graphics improves performance is by rendering leaves as a solid block (on Fancy the game will render them as transparent blocks, including interior faces, unlike glass, greatly increasing the number of faces being rendered; on Fast a 16x16x16 cube of leaves will have up to 768 visible faces compared to 12288 on Fancy - a factor of 16-fold).
Thanks a lot for the detailed reply. Since I made this post, I have slightly changed the way I go about this optimisation. Instead of replacing certain block types with stone, I now just use the "set command", to make the whole selection stone, regardless of what was there before. It's simpler, and may improve fps a tiny bit more. But yeah I did a test where I erased a chunk , so it was all air, and the fps was lower than if that chunk was all stone, which surprised me, but now that you mention faces, makes more sense.
Thanks! I actually made a suggestion on reddit for this option to be added, and I found out about the option in custom a few minutes ago lol. I won't go using custom until they have it fully implemented though.
My idea was to use worldedit to select the entire underground of a large area, and use a command to replace all of the sand/gravel/water/lava/air with just plain old stone. Theoretically, stone should be faster, because it performs less calculations than gravity affected blocks, and isn't animated. So I tested it multiple times, with great success. In some cases, I gained 50fps. However, I suspect the effect may not be so great if your system is already struggling to run the game. Though it still might be a worthwhile boost. Especially if your projects are above ground, and you don't care about the underground blocks being replaced with stone. I think this can be done without Worldedit, using the vanilla fill command, albeit, not quite as easily. Can some other people try this out to confirm whether this is as great as i think it is, or if I just need some more sleep... Lol.
Here is a quick video I made showing 2 test runs, which both returned massive fps gains:
And by the way, do any of you guys know if there's any blocks in this game that are somehow even less demanding than stone? Maybe stone performs some sort of calculations I'm not aware of. And am I right in assuming that light-emitting blocks such as beacons are quite demanding, and in large numbers will increase lag? I have noticed that while in the heart of my city, with loads of light sources, the game slows to a crawl. Which is why I wanted to optimise the underground in the first place. every extra frame counts!
There should be no difference between sand and stone because there are no calculations being done unless a block update occurs; it does not constantly check to see if it should fall or you wouldn't be able to find floating sand, and besides, that is a server performance issue, not a client-sided (FPS) one (unless you still have a single-core CPU as the client and server run on separate threads). Also, light sources by themselves do not cause lag; it is because beacons are tile entities which use a TESR (TileEntitySpecialRenderer) which re-renders the beam every single frame, much as entities render (which is why too many cause lag); by contrast, the game only re-renders "normal" blocks when a chunk update occurs. Particles, including torch flames and water/lava particles, can reduce performance but the game only renders particles within a short distance of the player (blocks further away have no effect at all since most block particles are rendered by randomly selecting blocks around the player and rendering any particle effects they may have).
Rendering animated textures on simple blocks like water does not make a noticeable difference unless you actually stop the animation process itself, which means using Optifine to disable them, since the game updates the textures once per frame regardless of whether they are being displayed (it updates the entire texture atlas which contains the textures for every block; re-rendering every chunk with an animated block would be far too expensive). Another way to reduce lag from animated textures is to tun mipmaps off, since it has to update the textures for every mipmap level, and/or use a lower resolution resource pack (the size of the texture atlas determines how expensive it is to update and upload it to the GPU so just making the animated textures a lower resolution will not do much).
The most significant improvement by far and away is that you greatly reduced the amount of surfaces the game has to render by filling in caves, although the game is supposed to hide chunks that are not visible (prior to 1.8 you could toggle this with the "Advanced OpenGL" setting which made a huge difference for me, as in playing on Normal render distance vs Short, especially in my mods which made the ground much deeper with the size of cave systems scaled up in 3D. Notably, I did not notice any difference in FPS in vanilla vs a triple-depth world when AOGL was enabled, it was that good at hiding unseen chunks. Since 1.8 they use a custom method which may not be as good, plus it runs on the CPU instead of GPU).
The amount of blocks that the game actually has to render is surprisingly small; a Superflat world only has to render 256 faces per chunk regardless of how deep it is (the game, or rather, GPU, does not render the back side of most blocks, which can be seen with blocks like glass, so only the visible surfaces facing you are rendered and a cube can have no more than 3 sides visible at any one time); the "beefy computer" warning for Amplified has more to do with the amount of faces that the game needs to render due to more variable and higher terrain than the amount of terrain itself, and likewise, the biggest way Fast graphics improves performance is by rendering leaves as a solid block (on Fancy the game will render them as transparent blocks, including interior faces, unlike glass, greatly increasing the number of faces being rendered; on Fast a 16x16x16 cube of leaves will have up to 768 visible faces compared to 12288 on Fancy - a factor of 16-fold).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Thanks a lot for the detailed reply. Since I made this post, I have slightly changed the way I go about this optimisation. Instead of replacing certain block types with stone, I now just use the "set command", to make the whole selection stone, regardless of what was there before. It's simpler, and may improve fps a tiny bit more. But yeah I did a test where I erased a chunk , so it was all air, and the fps was lower than if that chunk was all stone, which surprised me, but now that you mention faces, makes more sense.
IMO, there should be an option when generating a world, to disable caves.
There is!
In the Customized world type under "More Options", first page of customizations, upper right.
You'd want to disable ravines, lakes and lava lakes as well to make the underground solid.
(So far at least that option seems to have been removed in 1.13 though.)
Just testing.
Thanks! I actually made a suggestion on reddit for this option to be added, and I found out about the option in custom a few minutes ago lol. I won't go using custom until they have it fully implemented though.