I always use my Silk Touch to Mine, I like to store my Ores until I need them, then I use my Fortune Pickaxe.
It is much more efficient to directly mine them on the spot though since you can craft resources into blocks and this saves space in every case except for lapis when mined with Fortune and it is generally a small portion of the total ores you'll collect. For example, this is my ender chest after a session where a net yield of 4,932 resources, or about 77 stacks, were compacted into only 12 slots (or about 8.5 full stacks), you may also notice that I collected 741 rails yet I only have 2 in my inventory, since I modded in "rail blocks" that let me craft 9 rails into a block to save space in the same manner as ores, which are next to the diamonds in the last row (mineshafts are unbelievably common in vanilla 1.6.4 (this is from my first world, where I use such modded blocks while caving, but not for permanent storage), I've collected over 1,000 rails on each of several consecutive days before):
Also, you double tool wear since you have to first mine the ores with Silk Touch, which also gives no XP, then again to get the actual drops, in addition to the time spent on placing and mining them again, and unless you bring enough coal with you you'll need to bring a second pickaxe anyway in order to mine it for the coal (in the case of iron and gold ore I accumulate it in my ender chest and inventory until I need more space, then I find an easy to find again area, like the main room of a mineshaft or one of my "return points", and set up a bank of furnaces and continue exploring nearby while it smelts)..
It is much more efficient to directly mine them on the spot though since you can craft resources into blocks and this saves space in every case except for lapis when mined with Fortune and it is generally a small portion of the total ores you'll collect. For example, this is my ender chest after a session where a net yield of 4,932 resources, or about 77 stacks, were compacted into only 12 slots (or about 8.5 full stacks), you may also notice that I collected 741 rails yet I only have 2 in my inventory, since I modded in "rail blocks" that let me craft 9 rails into a block to save space in the same manner as ores, which are next to the diamonds in the last row (mineshafts are unbelievably common in vanilla 1.6.4 (this is from my first world, where I use such modded blocks while caving, but not for permanent storage), I've collected over 1,000 rails on each of several consecutive days before):
Also, you double tool wear since you have to first mine the ores with Silk Touch, which also gives no XP, then again to get the actual drops, in addition to the time spent on placing and mining them again, and unless you bring enough coal with you you'll need to bring a second pickaxe anyway in order to mine it for the coal (in the case of iron and gold ore I accumulate it in my ender chest and inventory until I need more space, then I find an easy to find again area, like the main room of a mineshaft or one of my "return points", and set up a bank of furnaces and continue exploring nearby while it smelts)..
It's usually only worth storing them in that manner if they are Fortuned however, if without a Fortune pickaxe you get much less resources and you need 9 diamonds, coal or iron to make a block to then condense the items into chests for efficient storage.
I like using Silk Touch enchant to store ores until I need them as well. It's rare that I obtain enough of something to need to break the ore then condense the items into blocks. I'm sure the longer I keep the same world the need to do this will increase, but for now Silk Touch is doing me fine.
What I do obtain a large sum of however are things like Stone, Diorite, Granite and Andesite, these are common blocks which necessitated me building warehouse full of chests to store them. I suppose this explains the reduction in FPS I've been getting lately when going to the factory that has these massive storage rooms. But I do need them, especially since I share a server with other people to play on who need to store their gear too.
It's usually only worth storing them in that manner if they are Fortuned however, if without a Fortune pickaxe you get much less resources and you need 9 diamonds, coal or iron to make a block to then condense the items into chests for efficient storage.
Well, I often do say that I do more caving/mining in a single session than most players do in the entire lifetime of a world but surely even the average player can collect a few hundred resources in a single trip, Fortune or not (which only roughly doubles drops, so not that "much less", redstone is only multiplied by 1.33 and even without Fortune you get an average of 9 resources from two ores). For example, somebody got all of this in one hour of branch-mining:
846 redstone dust (= 94 blocks)
498 coal (= 55.33 blocks, not including coal used for torches or smelting)
218 lapis (= 3.40 blocks)
111 iron ingots (= 12.33 blocks, none needed for repairs)
26 gold ingots (= 2.88 blocks)
25 diamonds (three used subsequently for repairs)
13 emeralds
Total: 1,737 resources (about 1,114 without Fortune)
I suppose this explains the reduction in FPS I've been getting lately when going to the factory that has these massive storage rooms. But I do need them, especially since I share a server with other people to play on who need to store their gear too.
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
Yeah I should have thought about that at the time, I guess I didn't want to risk randomly causing Villagers in the trading system to change to Fishermen after failing to remember their job-site blocks which is closest to them, but the performance issue is a much bigger problem, I could amend the decision at a later time but I'd need to farm an enormous load of wood first.
But chests being entities is the reason I am getting my frame rate cut in half to what it usually is, under normal circumstances it would be in the 100fps range, even whilst traveling, but when I am in the factory with the warehouses, it goes down to about 50fps or sometimes even less because of the redstone I use for the semi automated stone and basalt generators.
Why chests count as entities in the game I don't know, barrels are just as good as chests space wise.
It is true you cannot make a double chest variant of the barrels, but what you can do with barrels is place them side by side making the total capacity of them about the same. Additionally barrels can be opened even when there is a block directly above them.
Why chests count as entities in the game I don't know, barrels are just as good as chests space wise.
Both chests and barrels are "tile entities" or "block entities" and are pretty much identical in code except that chests are dynamically rendered in the same way as regular entities are since normal block rendering doesn't support smooth animations like the lid opening and closing (barrels do change their top texture but it only switches between open and closed, similar to furnaces and burning furnaces).
They could however optimize them by rendering closed chests as a single piece instead of 3 separate pieces (base, lid, and latch), as I do for about twice the performance (the reason why shulker boxes aren't as bad is because they only have 2 separate pieces to render), and I've even thought of adding a setting to make chests render like a normal block without an opening/closing animation:
if (lidAngle > 0.001F)
{
// Normal rendering used when chest is opened
lidAngle = 1.0F - lidAngle;
lidAngle = 1.0F - lidAngle * lidAngle * lidAngle;
chestModel.chestLid.rotateAngleX = -(lidAngle * MathHelper.HALF_PI);
chestModel.renderAll();
}
else
{
// Renders closed chests (including items) as a single unit for improved performance
renderClosedChest(chestModel instanceof ModelLargeChest);
}
// ModelChest; note that three separate draw calls are used to render each piece; each also applies various rotations and translations to OpenGL state, which all add even more to the render time
public void renderAll()
{
this.chestKnob.rotateAngleX = this.chestLid.rotateAngleX;
this.chestLid.render(0.0625F);
this.chestKnob.render(0.0625F);
this.chestBelow.render(0.0625F);
}
// renderClosedChest; uses a custom model which only requires a single draw call, and also culls hidden faces (top of
// base, bottom of lid, and back of latch)
public static void renderClosedChest(boolean isLargeChest)
{
if (!compiled) compileDisplayLists();
if (isLargeChest)
{
GL11.glCallList(largeChestDisplayList);
}
else
{
GL11.glCallList(chestDisplayList);
}
}
That said, the 500+ chests in my storage area in my first world still cause FPS to drop by a factor of 3 but I still get about 4 times the capped FPS so the effect is unnoticeable, and the layout means that it is large enough that when standing at one end the other end is so far away that chests are no longer rendering (they have a render distance of 64 blocks, and chests outside the field of view aren't rendered so even when standing in the middle only half are being rendered). It does mean that I have to walk around a lot to get to the chests further way but I only have to make a couple trips to put everything away.
For comparison, I turned flower pots into a tile entity so they can contain any number of plants, but they use standard block rendering for very little impact on performance, even memory usage is not significantly impacted in the example shown, a Superflat world with a layer of flowerpots (each tile entity uses additional memory, which is 32 bytes if I calculated it correctly, but for the number that were loaded this only amounts to about 7 MB on both the client and server; this screenshot was also taken before I made various optimizations to rendering and memory usage in general):
(there is however an issue with even a small number of flower pots with full-size tree models, like these, due to the complexity of the model causing a chunk update to take a long time and cause a lag spike when updated, but steady-state FPS is not affected any more than the same number of real blocks would. Barrels could cause similar lag spikes when opened/closed as they need a chunk update to change their texture)
Both chests and barrels are "tile entities" or "block entities" and are pretty much identical in code except that chests are dynamically rendered in the same way as regular entities are since normal block rendering doesn't support smooth animations like the lid opening and closing (barrels do change their top texture but it only switches between open and closed, similar to furnaces and burning furnaces).
They could however optimize them by rendering closed chests as a single piece instead of 3 separate pieces (base, lid, and latch), as I do for about twice the performance (the reason why shulker boxes aren't as bad is because they only have 2 separate pieces to render), and I've even thought of adding a setting to make chests render like a normal block without an opening/closing animation:
if (lidAngle > 0.001F)
{
// Normal rendering used when chest is opened
lidAngle = 1.0F - lidAngle;
lidAngle = 1.0F - lidAngle * lidAngle * lidAngle;
chestModel.chestLid.rotateAngleX = -(lidAngle * MathHelper.HALF_PI);
chestModel.renderAll();
}
else
{
// Renders closed chests (including items) as a single unit for improved performance
renderClosedChest(chestModel instanceof ModelLargeChest);
}
// ModelChest; note that three separate draw calls are used to render each piece; each also applies various rotations and translations to OpenGL state, which all add even more to the render time
public void renderAll()
{
this.chestKnob.rotateAngleX = this.chestLid.rotateAngleX;
this.chestLid.render(0.0625F);
this.chestKnob.render(0.0625F);
this.chestBelow.render(0.0625F);
}
// renderClosedChest; uses a custom model which only requires a single draw call, and also culls hidden faces (top of
// base, bottom of lid, and back of latch)
public static void renderClosedChest(boolean isLargeChest)
{
if (!compiled) compileDisplayLists();
if (isLargeChest)
{
GL11.glCallList(largeChestDisplayList);
}
else
{
GL11.glCallList(chestDisplayList);
}
}
That said, the 500+ chests in my storage area in my first world still cause FPS to drop by a factor of 3 but I still get about 4 times the capped FPS so the effect is unnoticeable, and the layout means that it is large enough that when standing at one end the other end is so far away that chests are no longer rendering (they have a render distance of 64 blocks, and chests outside the field of view aren't rendered so even when standing in the middle only half are being rendered). It does mean that I have to walk around a lot to get to the chests further way but I only have to make a couple trips to put everything away.
For comparison, I turned flower pots into a tile entity so they can contain any number of plants, but they use standard block rendering for very little impact on performance, even memory usage is not significantly impacted in the example shown, a Superflat world with a layer of flowerpots (each tile entity uses additional memory, which is 32 bytes if I calculated it correctly, but for the number that were loaded this only amounts to about 7 MB on both the client and server; this screenshot was also taken before I made various optimizations to rendering and memory usage in general):
(there is however an issue with even a small number of flower pots with full-size tree models, like these, due to the complexity of the model causing a chunk update to take a long time and cause a lag spike when updated, but steady-state FPS is not affected any more than the same number of real blocks would. Barrels could cause similar lag spikes when opened/closed as they need a chunk update to change their texture)
I have about 500+ chests myself so this explains where the performance issues are coming from, the entities and their chunk updates are putting increased strain on the CPU even with my newer PC that has an AMD Ryzen CPU, no doubt they cause lag on your PC too.
On topic of the thread what me and a friend have done recently is visited the End, beaten Ender Dragon and obtained some Elytras each and Shulker boxes, and he obtained a Dragon Head, something I forgot to get.
Now that I have Shulker boxes large scale builds are feasible, as I can carry supplies back and forth across territory without having to rely on an expensive minecart system.
I would have built a minecart system on my current world to use for transportation of those resources if Mojang hadn't removed Gold Ingot drops from Drowned Zombies, now that they're gone since 1.17 I don't have as much luxury to do this. I could obtain Gold from the Nether, but it is a considerable grind, and I found it wasn't worth my time.
In this case I have to transport items from a Mushroom Island roughly 384 blocks away across a lake surrounded by mainland, which only becomes partially visible with a 24 chunk render distance although I play with 32 chunks render distance most of the time, and this links to a Forest biome, and this is only for the initial project, when the city becomes large enough it would span 1,000 blocks away from the Mushroom Island and all the resources used to build it would need to be transported. I find Shulker boxes to be more efficient for this.
Mojang isn't going to care about what I say though, I am only one person out of the millions who play this game.
My refusal to use mods and cheats also limits what I can do in vanilla Minecraft.
I play survival with friends because we enjoy the thrill of collecting resources then use them to build things,
like the city I have planned, but because of the way Mojang designs their game out of fear of it becoming too broken or cheaty,
build style players like myself don't have a lot of options in what we can do when it involves a time consuming project.
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
Barrels (19w06a): ~280 FPS
Chests: ~5 FPS
Oh my goodness, really!? that much of a difference!?
This made me think of something. I started playing with shaders in 1.16, and after the game updated to 1.18, performance was a lot lower, specifically just around my village. Now I don't have a ton of chests, but collectively there's probably enough entities I guess? Chests, barrels, other job site blocks (not sure how much these matter), item frames, villagers, iron golems, birds, cats, and who knows what else.
Now my first thought was 1.18 was just performance demanding, as it is. But this only happened specifically when playing with shaders, so it wasn't fully explaining it. Nor was "shaders are demanding" as they were fine in 1.16.
I started wondering if it was related to entities and/or shadows. Unfortunately, reducing the shadow texture size did almost nothing.
I was curious and noticed turning the new entity distance setting from 100% to 50% improved it (oddly, turning it from 100% to 500% barely degraded it further), but it was still lower than before. That, and entities weren't rendering from as far as I wanted in many situations. But my guesses were being partly confirmed by this.
BSL updated a bit later and an "entity shadows" setting was added within the shaders. What a difference maker.
The only difference is "entity shadows" on versus off in BSL's settings.
It took a short while to adjust to the lack of shadows from entities but I did, and it is noooooot worth that massive of a performance drop from having them on.
Thankfully my fairly new gaming rig laughs at the face of Minecraft so I don't need to consider blocks based on performance
This build is taking forever..
Didn't find blocks to make the upper walls and towers white, as I wanted to, so ended up using stone colors instead. At least there are many block alternatives in that color.. But the build is looking a bit too gray.. Will see if I can add more details and improve walls later.. But at least now I have outer walls, and can potentially leave them alone while starting to build village within instead..
The bottom part of the wall will definitively get more mossy cobblestone variants later, but tired of messing with walls for now.. Though I guess I should complete the bridge over the water, so the entrance part looks ok..
Three redstone gates in here now, splitting up the 3 areas within, and I think the whole area should be mob proof now.. Used a ton of blocks though. Got empty of cobblestone, stone and dirt at some point, so have digged within the structure to get more blocks, so pretty large areas of hollowed out space within here too now.. Where I'll put up some more auto-farms I think...
Thankfully my fairly new gaming rig laughs at the face of Minecraft so I don't need to consider blocks based on performance
Mine does fine with vanilla Minecraft at normal render distances and such too. I don't think even modern versions demand much there.
It's when you get into shaders, resource packs, higher render distances, or some combination that can cause large performance degradation.
If there's one thing I learned with this game over the last decade, it's that it doesn't care what CPU or graphics card you have if you push certain things too far. This game can and will humble it.
I'm glad to see your hardcore world has progressed into the "building" parts. Those are my favorite parts.
The reason is because every part of an entity requires a separate draw call and these are expensive; a chest requires that the game tell the GPU to render three separate pieces; a chicken has 8 separate pieces, and so on. Worse, the game needs to switch between textures, which is also expensive, when rendering an entity and its shadow, as well as any equipment it has (the game stitches all block textures into a single texture atlas precisely because each draw call can only reference one texture at a time).
To illustrate just how different block and entity rendering is, all blocks can be rendered in as little as 3 draw calls (at least in 1.6.4, when Fancy graphics, or translucent blocks/water are enabled; Fast graphics only requires 2 draw calls, plus a handful of OpenGL state changes):
This code mostly decides if a chunk section is to be rendered and adds it to a list, when is then sent to the GPU to be render everything on screen - using just one draw call (glCallLists) and three OpenGL calls in total (glTranslatef, all at the end of the method). Translucent blocks are similar except they have an additional draw call to render a "mask" which is used to eliminate graphical artifacts like those described by MC-38022 on Fancy graphics (the only issue is that you can't see translucent blocks behind other translucent blocks but that doesn't bother me anywhere near as much as the very obvious artifacts as described in the link, which are also less severe in 1.6.4):
private int renderSortedRenderers(int par1, int par2, double playerX, double playerY, double playerZ)
{
if (!this.fastRender) return renderSortedRenderers_old(par1, par2, playerX, playerY, playerZ);
this.glListBuffer.clear();
int var6 = 0;
boolean var7 = this.mc.gameSettings.showDebugInfo;
int x = MathHelper.floor_double(playerX) - 8;
int z = MathHelper.floor_double(playerZ) - 8;
for (int var8 = par1; var8 < par2; ++var8)
{
ChunkRenderer var9 = this.sortedChunkRenderers[var8];
if (var7)
{
if (var9.skipRenderPass0 && var9.skipRenderPass1)
{
++this.renderersSkippingRenderPass;
}
else if (!var9.isInFrustum)
{
++this.renderersBeingClipped;
}
else if (this.advancedOpengl && !var9.isVisible)
{
++this.renderersBeingOccluded;
}
else
{
++this.renderersBeingRendered;
}
}
if (var9.isInFrustum && !var9.skipRenderPass0 && (!this.advancedOpengl || var9.isVisible))
{
if (var9.shouldRender(x, this.playerHeight, z, this.renderRadius1, this.renderRadius2))
{
int var10 = var9.getGLCallListForPass0();
if (var10 >= 0)
{
this.glListBuffer.put(var10);
++var6;
if (var6 >= MAX_GL_LISTS) break;
}
}
else if (var7)
{
++this.renderersBeingOccluded;
--this.renderersBeingRendered;
}
}
}
if (var6 > 0)
{
this.glListBuffer.flip();
GL11.glTranslatef((float)(-playerX), (float)(-playerY), (float)(-playerZ));
GL11.glCallLists(this.glListBuffer);
GL11.glTranslatef((float)playerX, (float)playerY, (float)playerZ);
}
return var6;
}
By contrast, this is what the game calls to render every single piece of an entity - in the extreme case, horses have 39 pieces (and were likely simplified in part because of how demanding such a complex model is - one of the only times I experience a lag spike while playing is when a horse renders for the first time, due to the cost of constructing its model (it doesn't help that it combines multiple layers of textures), which isn't compiled until an entity is rendered for the first time):
As an illustration of just how costly entity rendering is, 100 chickens has a bigger impact on FPS than going from a default Superflat world, with only a few chunks in view, to a normal world at maximum (16 chunks) render distance, or even in a "mega forest" biome:
This is also why the game is fairly aggressive on entity culling; chickens only render up to 28 blocks away (the distance is based on their size) and the server doesn't send most entities to the client unless they are within 80 blocks (does the "entity distance" slider affect either of these?); in the last two examples above the client isn't rendering any entities despite there being around 400 loaded server-side and around 100 client-side (the "mob counts" is server-side while "E:" is client-side).
The reason is because every part of an entity requires a separate draw call and these are expensive; a chest requires that the game tell the GPU to render three separate pieces; a chicken has 8 separate pieces, and so on. Worse, the game needs to switch between textures, which is also expensive, when rendering an entity and its shadow, as well as any equipment it has (the game stitches all block textures into a single texture atlas precisely because each draw call can only reference one texture at a time).
To illustrate just how different block and entity rendering is, all blocks can be rendered in as little as 3 draw calls (at least in 1.6.4, when Fancy graphics, or translucent blocks/water are enabled; Fast graphics only requires 2 draw calls, plus a handful of OpenGL state changes):
This code mostly decides if a chunk section is to be rendered and adds it to a list, when is then sent to the GPU to be render everything on screen - using just one draw call (glCallLists) and three OpenGL calls in total (glTranslatef, all at the end of the method). Translucent blocks are similar except they have an additional draw call to render a "mask" which is used to eliminate graphical artifacts like those described by MC-38022 on Fancy graphics (the only issue is that you can't see translucent blocks behind other translucent blocks but that doesn't bother me anywhere near as much as the very obvious artifacts as described in the link, which are also less severe in 1.6.4):
private int renderSortedRenderers(int par1, int par2, double playerX, double playerY, double playerZ)
{
if (!this.fastRender) return renderSortedRenderers_old(par1, par2, playerX, playerY, playerZ);
this.glListBuffer.clear();
int var6 = 0;
boolean var7 = this.mc.gameSettings.showDebugInfo;
int x = MathHelper.floor_double(playerX) - 8;
int z = MathHelper.floor_double(playerZ) - 8;
for (int var8 = par1; var8 < par2; ++var8)
{
ChunkRenderer var9 = this.sortedChunkRenderers[var8];
if (var7)
{
if (var9.skipRenderPass0 && var9.skipRenderPass1)
{
++this.renderersSkippingRenderPass;
}
else if (!var9.isInFrustum)
{
++this.renderersBeingClipped;
}
else if (this.advancedOpengl && !var9.isVisible)
{
++this.renderersBeingOccluded;
}
else
{
++this.renderersBeingRendered;
}
}
if (var9.isInFrustum && !var9.skipRenderPass0 && (!this.advancedOpengl || var9.isVisible))
{
if (var9.shouldRender(x, this.playerHeight, z, this.renderRadius1, this.renderRadius2))
{
int var10 = var9.getGLCallListForPass0();
if (var10 >= 0)
{
this.glListBuffer.put(var10);
++var6;
if (var6 >= MAX_GL_LISTS) break;
}
}
else if (var7)
{
++this.renderersBeingOccluded;
--this.renderersBeingRendered;
}
}
}
if (var6 > 0)
{
this.glListBuffer.flip();
GL11.glTranslatef((float)(-playerX), (float)(-playerY), (float)(-playerZ));
GL11.glCallLists(this.glListBuffer);
GL11.glTranslatef((float)playerX, (float)playerY, (float)playerZ);
}
return var6;
}
By contrast, this is what the game calls to render every single piece of an entity - in the extreme case, horses have 39 pieces (and were likely simplified in part because of how demanding such a complex model is - one of the only times I experience a lag spike while playing is when a horse renders for the first time, due to the cost of constructing its model (it doesn't help that it combines multiple layers of textures), which isn't compiled until an entity is rendered for the first time):
As an illustration of just how costly entity rendering is, 100 chickens has a bigger impact on FPS than going from a default Superflat world, with only a few chunks in view, to a normal world at maximum (16 chunks) render distance, or even in a "mega forest" biome:
This is also why the game is fairly aggressive on entity culling; chickens only render up to 28 blocks away (the distance is based on their size) and the server doesn't send most entities to the client unless they are within 80 blocks (does the "entity distance" slider affect either of these?); in the last two examples above the client isn't rendering any entities despite there being around 400 loaded server-side and around 100 client-side (the "mob counts" is server-side while "E:" is client-side).
Pardon me if I didn't fully understand, but I thought it was possible to combine the different parts of the model to make a single mesh, so that it only takes one draw-call per entity.
Has Mojang overlooked this, Or is there some reason why the can't?
The reason is because every part of an entity requires a separate draw call and these are expensive; a chest requires that the game tell the GPU to render three separate pieces; a chicken has 8 separate pieces, and so on. Worse, the game needs to switch between textures, which is also expensive, when rendering an entity and its shadow, as well as any equipment it has (the game stitches all block textures into a single texture atlas precisely because each draw call can only reference one texture at a time).
I don't know how to read code so that bit is entirely lost on me, but this paragraph explains the general consequence of it.
I was just surprised that the performance impact wasn't there there 1.16 but was 1.18. The only time I saw issues in 1.16 was when i was in the cean clearing kelp and would come to the surface and see what must have been hundred (thousands?) of kelp items floating. But my village was fine. Any ideas there on what may have changed (Minecraft itself and OptiFine changed; BSL stayed the same)? Or are you not that familiar with newer versions/OptiFine's changes/shaders? I even tried with it set to peaceful to rule out the potential additional mob spawns from the deeper underground and it made absolutely no difference. It was entirely my village and entirely entity shadows.
And this was confusing. Like why is the above screenshot showing a 32 FPS to 60 FPS (maybe more due to cap) difference from JUST entity shadows being on or off? The majority of the entities are behind me (cows) or should be being culled due to not being directly displayed, no?
Also, does this explain why my VRAM and GPU performance goes so South in jungles specifically? Or might that be because of my love for the bushy leaves resource? It sometimes happens with larger forests but almost always with jungles, even a "custom" one I grew. VRAM in particular seems to get consumed like nothing in a jungle. Worse, once it passes my VRAM amount (or more like a bit below it around 5.6 GB to 5.8 GB) and starts using system RAM, I noticed VRAM use never drops and my performance keeps suffering with stutters, unless I reload all chunks usign F3+A, which resets VRAM use. I'm hoping a video card upgrade will help with more performance (AND VRAM buffer) for using these shaders...
Pardon me if I didn't fully understand, but I thought it was possible to combine the different parts of the model to make a single mesh, so that it only takes one draw-call per entity.
Has Mojang overlooked this, Or is there some reason why the can't?
The game only appears to do this if you call ModelRenderer.addBox (as MCP named it in 1.6.4), and this only works if the individual pieces are fixed relative to each other (no rotation or movement along an axis, such as head, arms, and legs). I'm not sure why they didn't do this for horses, maybe because they took the model directly from Mo Creatures (I'm of the opinion that many modders spend very little effort on optimizations). Conversely, the snout of a pig is rendered at the same time as its head.
Also, when I added fish mobs I initially copied the model from Future MC's source (itself an adaptation of the original source from 1.13+; I used it since this is one of the few places I've found source code from 1.13+ as MCP stopped being updated at 1.12. The code for the entity itself was all written by myself, the main reason I haven't added that many new entities (with unique models) is because of how hard it is to understand how the model rendering works) but later replaced with with my own model which only requires two draw calls and minimal state changes (just the ones that set the entity's initial rotation and position) - the difference in performance was quite remarkable, even just re-rendering the entire model from scratch (via the "tessellator") was significantly faster (the tail is dynamically rendered to create its rotation, rather than using glRotatef or the like):
if (!this.compiled) this.compileDisplayList();
GL11.glCallList(this.fishDisplayList);
// Tail is rendered separately due to movement separate from rest of model
Tessellator tess = Tessellator.instance;
tess.startDrawingQuads();
float maxX = 0.25F * MathHelper.sin(this.tailAngle);
float maxZ = 0.4375F + 0.25F * MathHelper.cos(this.tailAngle);
float u1 = 0.0F / this.textureWidth;
float u2 = 4.0F / this.textureWidth;
float v1 = 5.0F / this.textureHeight;
float v2 = 9.0F / this.textureHeight;
tess.setNormalForSide(4);
tess.addVertexWithUV_N(0.0F, 1.25F, 0.4375F, u2, v1);
tess.addVertexWithUV_N(maxX, 1.25F, maxZ, u1, v1);
tess.addVertexWithUV_N(maxX, 1.5F, maxZ, u1, v2);
tess.addVertexWithUV_N(0.0F, 1.5F, 0.4375F, u2, v2);
tess.draw();
There are many other parts of the vanilla 1.6.4 rendering code which I optimized, for example, the item rendering code is quite bad - each face of a block is rendered separately and more complex items, such as fences, may have dozens of faces; each side of an item frame is an "item block" so this also significantly optimizes item frames (even my earliest optimization to the rendering of maps in item frames gave an amazing performance boost; the vanilla code was updating the entire 128x128 map texture and re-uploading it to the GPU every frame, which I changed so only 1/8 of it is updated every 8 frames, and the texture itself is only re-uploaded to the GPU once every 64 frames, with multiple maps staggered to help ensure they don't all update at once).
Maybe some of the worst rendering code was the way vanilla rendered fonts, using the simplest and least efficient OpenGL, sending each vertex separately, as opposed to use a vertex array or precompiled display list (or VBO, which are pretty which the same thing as modern GPU drivers internally handle them as such) - by rewriting it to use the tessellator the time taken to render the debug screen decreased by an order of magnitude:
For comparison, this is how I rewrote the code - an entire string, including its shadow (the same string rendered twice) is rendered all at once instead of character by character (an exception, I did not refactor Unicode as it isn't used by vanilla text and requires swapping between font textures if different character sets are used, each of which needs a separate draw call anyway):
Similarly, I improved the rendering speed of Fancy clouds by more than an order of magnitude by optimizing the code itself, and caching the rendered model and only updating it when needed (as they/the player moves and at sunrise/sunset, due to the color changing) - in fact, they actually take less time to render than Fast clouds in vanilla! I also fixed MC-997 so clouds can always be translucent and MC-3784 so terrain is properly rendered behind them (note that I fixed both of these before they were fixed in vanilla, although I didn't release an update with the fixes until the following year, a lot of my fixes were originally added to a personal copy of Optifine before I separated them):
Basically, a lot of my optimizations to rendering have been to reduce the amount of direct calls to OpenGL as much as possible; the chunk rendering code I showed before is from my "fast render" code, which cuts out a lot of stuff that the vanilla renderer does, at the cost of floating-point precision errors at far distances (chunks start to jitter, this is a lot like an issue that affected vanilla prior to Beta 1.8, I do have an option to disable it but I never see myself going anywhere near the point where it becomes noticeable; likewise, I actually removed the fix for the bug that caused the Far Lands as it adds unnecessary code, but due to other changes to the noise generator terrain generates normally past at least 30 million, and otherwise, I see no point to going that far out and even added an invisible wall at 30 million that makes it impossible for the player to get past, even if you use an NBT editor (you can otherwise go to the 32 bit limit which crashes the game; preventing such situations is another thing I see as important, e.g. I fixed MC-51418 well before it was fixed in vanilla as part of ensuring all options are valid, the lack of which has caused various versions to crash. Also, due to the way my lightmap code works setting gamma to 100 or something wouldn't work anyway, total darkness is still pitch black).
I don't know how to read code so that bit is entirely lost on me, but this paragraph explains the general consequence of it.
I was just surprised that the performance impact wasn't there there 1.16 but was 1.18. The only time I saw issues in 1.16 was when i was in the cean clearing kelp and would come to the surface and see what must have been hundred (thousands?) of kelp items floating. But my village was fine. Any ideas there on what may have changed (Minecraft itself and OptiFine changed; BSL stayed the same)? Or are you not that familiar with newer versions/OptiFine's changes/shaders? I even tried with it set to peaceful to rule out the potential additional mob spawns from the deeper underground and it made absolutely no difference. It was entirely my village and entirely entity shadows.
And this was confusing. Like why is the above screenshot showing a 32 FPS to 60 FPS (maybe more due to cap) difference from JUST entity shadows being on or off? The majority of the entities are behind me (cows) or should be being culled due to not being directly displayed, no?
Also, does this explain why my VRAM and GPU performance goes so South in jungles specifically? Or might that be because of my love for the bushy leaves resource? It sometimes happens with larger forests but almost always with jungles, even a "custom" one I grew. VRAM in particular seems to get consumed like nothing in a jungle. Worse, once it passes my VRAM amount (or more like a bit below it around 5.6 GB to 5.8 GB) and starts using system RAM, I noticed VRAM use never drops and my performance keeps suffering with stutters, unless I reload all chunks usign F3+A, which resets VRAM use. I'm hoping a video card upgrade will help with more performance (AND VRAM buffer) for using these shaders...
I've seen almost none of the code for any version since 1.13, and mostly just from open-source mods that backport various features (as I mentioned in my last post I originally took the fish model from a mod that backported them) but 1.17 made a major change to rendering - the game no longer uses "fixed-function" OpenGL rendering (1.6.4 technically only needs OpenGL 1.3, or OpenGL 1.2 with a "multitexture" extension - which was released in 1998-2001, and all fixed-function rendering was officially deprecated in 2008 - before development on Minecraft started, I assume that Notch just used what he learned years earlier).
Now, supposedly, using modern OpenGL should give a major performance boost*, especially on modern hardware (no GPU has supported the fixed-function pipeline since the early-mid 2000s, it is all emulated with shaders (in this context, a program the GPU executes to perform some task, much like a CPU) but as if often the case Mojang doesn't seem to have implemented it very well:
*I should note that what I've seen is very mixed; e.g. some claim that VBOs are faster than display lists while others say the opposite, particularly on NVIDIA hardware; the main advantage of VBOs seems to be that you can update them without re-rendering everything from scratch but it appears that Mojang doesn't do this, otherwise chunk updates shouldn't cause lag spikes (I should also note that 1.8 moved chunk updates to a separate thread; this comment claims that OpenGL itself prevents fully multithreaded updates; Optifine did try hacking it (before 1.8) but it often resulted in graphical artifacts). Either way, the efficiency of your own code is also important (as I've noted of vanilla, especially since 1.8), the advice given in the first link also mentions what I've been doing (render multiple things in one go instead of separately).
As far as jungles and VRAM usage goes, more complex geometry directly impacts VRAM usage, though 5+ GB seems very excessive, unless you are using a high render distance (for comparison, my old computer with 256 MB of dedicated VRAM would have issues with Fancy leaves in my own "mega tree" biomes, which have far more leaves/rendered surfaces than jungles (jungles do have vines though, which are each equivalent to two faces; backface culling removes one when drawn to the screen but the vertex mesh still contains both), causing FPS to suddenly drop to single digits when VRAM was exhausted. Given that this was at 8 chunks and each doubling of render distance increases VRAM usage by about 4-fold 32 chunks might use 4+ GB, and while I know about nothing about shaders but I've seen mention of high VRAM usage; this page mentions up to 10 GB of VRAM usage on high-end shaders/resource packs).
Also, I'm not sure how OpenGL stores vertex data in VRAM but each vertex uses 28 bytes in the tessellator buffer (4 bytes each for the x, y, z coordinates, u and v texture coordinates, brightness, and color); a 16x16x16 cube of Fancy leaves has 98,304 vertices (6 faces per block and 4 vertices per face) and requires 2.625 MB; in this scene I analyzed about 1 million leaf blocks within render distance, which at worst-case would require 640 MB of memory (the number rendered to the screen is much less but the data for every loaded non-empty chunk section is stored in VRAM and I imagine this takes up the vast majority of VRAM. Not every leaf block is rendering every face since they are adjacent to a solid block, e.g. logs).
Speaking of leaves, there is no benefit to using Fast graphics (leaves) in current versions due to a bug which has somehow persisted since 1.15 (the game is always rendering the faces of leaves adjacent to other leaves, which are normally culled on Fast graphics since they are rendered as opaque), and is a resurgence of an older bug which originally appeared in 1.8 and was fixed in 1.9 (which may explain why jungles were so bad for my performance in 1.8, though this did not explain the general issues and I don't remember 1.9 doing much):
It is possible that Optifine fixes this but I don't know if it does (other mods do; in general, for newer versions performance mods like Sodium are far superior to Optifine but they don't support shaders or any of the various graphical effects supported by Optifine, though there are mods which implement them separately).
1.17 made a major change to rendering - the game no longer uses "fixed-function" OpenGL rendering.
Oh, okay, I'm going to presume that might be part of it. I was totally unaware of any rendering changes. I thought 1.15 or something was the last time something relatively major happened with that. I never played in 1.17 and just went from 1.16 to 1.18.
As far as jungles and VRAM usage goes, more complex geometry directly impacts VRAM usage, though 5+ GB seems very excessive...
I play at a render distance of 16 in the world in question. I could maybe do 24 at times but even that would be pushing it to run everywhere as it would cause more severe drops in heavy areas, so I just stay at 16. As it is, jungles in particular already do that.
Given what you're saying, it sounds like it shouldn't be having an impact that high? This is generally (a severe example of) what happens within one. And yes I know the performance is low because of the GPU use itself but it's mostly the VRAM use I'm intending to show here.
I do play with triple buffering, as it's necessary to prevent frame rate drops from my refresh rate from being more severe, and I imagine that makes a difference to VRAM, but I'm not sure how much.
That link specifically mentions PBO like features can use a lot of VRAM and I'm not using any of those.
I'm using a 32x resource pack (two for full disclosure, if this does something silly like double the impact?) along with the aforementioned "bushy leaves". I can't go without that, I need them! I'm guessing this is a big part of VRAM use but I didn't know if it should be expected to be that high.
And I'm using anti-aliasing (TAA in the shaders options).
I... think that's the only noteworthy stuff that i can think of that might effect VRAM? Use is usually rather "low" until a jungle (or sometimes a lot of trees/forests) enter the equation.
(Also, now that I loaded that world up, I want to play it, but I've got more progress to "finish" on my hardcore world first.)
It is possible that Optifine fixes this but I don't know if it does (other mods do; in general, for newer versions performance mods like Sodium are far superior to Optifine but they don't support shaders or any of the various graphical effects supported by Optifine, though there are mods which implement them separately).
Yeah, I've been hearing more and more about alternatives, and looked into them a while back.
I tried Sodium or whatever they are on my old laptop, and found performance wasn't a whole lot better than OptiFine, but that laptop's CPU just wasn't ideal for anything past probably 1.12 (or 1.6 really).
For now on my desktop I just stay with OptiFine because it's what I'm familiar with, and is a "one step solution" that offers me good enough performance and supports everything I want. My current performance issues seem specifically with shaders so I wasn't thinking staying with OptiFine was doing me any disservices, but if alternatives become simpler and/or OptiFine presents issues in the future, I'll give them another look.
It is much more efficient to directly mine them on the spot though since you can craft resources into blocks and this saves space in every case except for lapis when mined with Fortune and it is generally a small portion of the total ores you'll collect. For example, this is my ender chest after a session where a net yield of 4,932 resources, or about 77 stacks, were compacted into only 12 slots (or about 8.5 full stacks), you may also notice that I collected 741 rails yet I only have 2 in my inventory, since I modded in "rail blocks" that let me craft 9 rails into a block to save space in the same manner as ores, which are next to the diamonds in the last row (mineshafts are unbelievably common in vanilla 1.6.4 (this is from my first world, where I use such modded blocks while caving, but not for permanent storage), I've collected over 1,000 rails on each of several consecutive days before):
Also, you double tool wear since you have to first mine the ores with Silk Touch, which also gives no XP, then again to get the actual drops, in addition to the time spent on placing and mining them again, and unless you bring enough coal with you you'll need to bring a second pickaxe anyway in order to mine it for the coal (in the case of iron and gold ore I accumulate it in my ender chest and inventory until I need more space, then I find an easy to find again area, like the main room of a mineshaft or one of my "return points", and set up a bank of furnaces and continue exploring nearby while it smelts)..
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?
Well I misspoke, and should've said 'repair or further enchant'. If you add the name before the last book, the last book costs more.
Nothing
It's usually only worth storing them in that manner if they are Fortuned however, if without a Fortune pickaxe you get much less resources and you need 9 diamonds, coal or iron to make a block to then condense the items into chests for efficient storage.
I like using Silk Touch enchant to store ores until I need them as well. It's rare that I obtain enough of something to need to break the ore then condense the items into blocks. I'm sure the longer I keep the same world the need to do this will increase, but for now Silk Touch is doing me fine.
What I do obtain a large sum of however are things like Stone, Diorite, Granite and Andesite, these are common blocks which necessitated me building warehouse full of chests to store them. I suppose this explains the reduction in FPS I've been getting lately when going to the factory that has these massive storage rooms. But I do need them, especially since I share a server with other people to play on who need to store their gear too.
Well, I often do say that I do more caving/mining in a single session than most players do in the entire lifetime of a world but surely even the average player can collect a few hundred resources in a single trip, Fortune or not (which only roughly doubles drops, so not that "much less", redstone is only multiplied by 1.33 and even without Fortune you get an average of 9 resources from two ores). For example, somebody got all of this in one hour of branch-mining:
You can avoid lag by using barrels, which may not be as convenient due to not having a "double chest" variant but they are no harder on rendering than a block like stone, while chests are rendered like entities and have a severe impact (this was tested with 8,000 of each block):
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?
Yeah I should have thought about that at the time, I guess I didn't want to risk randomly causing Villagers in the trading system to change to Fishermen after failing to remember their job-site blocks which is closest to them, but the performance issue is a much bigger problem, I could amend the decision at a later time but I'd need to farm an enormous load of wood first.
But chests being entities is the reason I am getting my frame rate cut in half to what it usually is, under normal circumstances it would be in the 100fps range, even whilst traveling, but when I am in the factory with the warehouses, it goes down to about 50fps or sometimes even less because of the redstone I use for the semi automated stone and basalt generators.
Why chests count as entities in the game I don't know, barrels are just as good as chests space wise.
It is true you cannot make a double chest variant of the barrels, but what you can do with barrels is place them side by side making the total capacity of them about the same. Additionally barrels can be opened even when there is a block directly above them.
Both chests and barrels are "tile entities" or "block entities" and are pretty much identical in code except that chests are dynamically rendered in the same way as regular entities are since normal block rendering doesn't support smooth animations like the lid opening and closing (barrels do change their top texture but it only switches between open and closed, similar to furnaces and burning furnaces).
They could however optimize them by rendering closed chests as a single piece instead of 3 separate pieces (base, lid, and latch), as I do for about twice the performance (the reason why shulker boxes aren't as bad is because they only have 2 separate pieces to render), and I've even thought of adding a setting to make chests render like a normal block without an opening/closing animation:
if (lidAngle > 0.001F) { // Normal rendering used when chest is opened lidAngle = 1.0F - lidAngle; lidAngle = 1.0F - lidAngle * lidAngle * lidAngle; chestModel.chestLid.rotateAngleX = -(lidAngle * MathHelper.HALF_PI); chestModel.renderAll(); } else { // Renders closed chests (including items) as a single unit for improved performance renderClosedChest(chestModel instanceof ModelLargeChest); } // ModelChest; note that three separate draw calls are used to render each piece; each also applies various rotations and translations to OpenGL state, which all add even more to the render time public void renderAll() { this.chestKnob.rotateAngleX = this.chestLid.rotateAngleX; this.chestLid.render(0.0625F); this.chestKnob.render(0.0625F); this.chestBelow.render(0.0625F); } // renderClosedChest; uses a custom model which only requires a single draw call, and also culls hidden faces (top of // base, bottom of lid, and back of latch) public static void renderClosedChest(boolean isLargeChest) { if (!compiled) compileDisplayLists(); if (isLargeChest) { GL11.glCallList(largeChestDisplayList); } else { GL11.glCallList(chestDisplayList); } }That said, the 500+ chests in my storage area in my first world still cause FPS to drop by a factor of 3 but I still get about 4 times the capped FPS so the effect is unnoticeable, and the layout means that it is large enough that when standing at one end the other end is so far away that chests are no longer rendering (they have a render distance of 64 blocks, and chests outside the field of view aren't rendered so even when standing in the middle only half are being rendered). It does mean that I have to walk around a lot to get to the chests further way but I only have to make a couple trips to put everything away.
For comparison, I turned flower pots into a tile entity so they can contain any number of plants, but they use standard block rendering for very little impact on performance, even memory usage is not significantly impacted in the example shown, a Superflat world with a layer of flowerpots (each tile entity uses additional memory, which is 32 bytes if I calculated it correctly, but for the number that were loaded this only amounts to about 7 MB on both the client and server; this screenshot was also taken before I made various optimizations to rendering and memory usage in general):
(there is however an issue with even a small number of flower pots with full-size tree models, like these, due to the complexity of the model causing a chunk update to take a long time and cause a lag spike when updated, but steady-state FPS is not affected any more than the same number of real blocks would. Barrels could cause similar lag spikes when opened/closed as they need a chunk update to change their texture)
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?
I have about 500+ chests myself so this explains where the performance issues are coming from, the entities and their chunk updates are putting increased strain on the CPU even with my newer PC that has an AMD Ryzen CPU, no doubt they cause lag on your PC too.
On topic of the thread what me and a friend have done recently is visited the End, beaten Ender Dragon and obtained some Elytras each and Shulker boxes, and he obtained a Dragon Head, something I forgot to get.
Now that I have Shulker boxes large scale builds are feasible, as I can carry supplies back and forth across territory without having to rely on an expensive minecart system.
I would have built a minecart system on my current world to use for transportation of those resources if Mojang hadn't removed Gold Ingot drops from Drowned Zombies, now that they're gone since 1.17 I don't have as much luxury to do this. I could obtain Gold from the Nether, but it is a considerable grind, and I found it wasn't worth my time.
In this case I have to transport items from a Mushroom Island roughly 384 blocks away across a lake surrounded by mainland, which only becomes partially visible with a 24 chunk render distance although I play with 32 chunks render distance most of the time, and this links to a Forest biome, and this is only for the initial project, when the city becomes large enough it would span 1,000 blocks away from the Mushroom Island and all the resources used to build it would need to be transported. I find Shulker boxes to be more efficient for this.
Mojang isn't going to care about what I say though, I am only one person out of the millions who play this game.
My refusal to use mods and cheats also limits what I can do in vanilla Minecraft.
I play survival with friends because we enjoy the thrill of collecting resources then use them to build things,
like the city I have planned, but because of the way Mojang designs their game out of fear of it becoming too broken or cheaty,
build style players like myself don't have a lot of options in what we can do when it involves a time consuming project.
Wow!
Oh my goodness, really!? that much of a difference!?
This made me think of something. I started playing with shaders in 1.16, and after the game updated to 1.18, performance was a lot lower, specifically just around my village. Now I don't have a ton of chests, but collectively there's probably enough entities I guess? Chests, barrels, other job site blocks (not sure how much these matter), item frames, villagers, iron golems, birds, cats, and who knows what else.
Now my first thought was 1.18 was just performance demanding, as it is. But this only happened specifically when playing with shaders, so it wasn't fully explaining it. Nor was "shaders are demanding" as they were fine in 1.16.
I started wondering if it was related to entities and/or shadows. Unfortunately, reducing the shadow texture size did almost nothing.
I was curious and noticed turning the new entity distance setting from 100% to 50% improved it (oddly, turning it from 100% to 500% barely degraded it further), but it was still lower than before. That, and entities weren't rendering from as far as I wanted in many situations. But my guesses were being partly confirmed by this.
BSL updated a bit later and an "entity shadows" setting was added within the shaders. What a difference maker.
It took a short while to adjust to the lack of shadows from entities but I did, and it is noooooot worth that massive of a performance drop from having them on.
Why is it always entities!?
Thankfully my fairly new gaming rig laughs at the face of Minecraft so I don't need to consider blocks based on performance
This build is taking forever..
Didn't find blocks to make the upper walls and towers white, as I wanted to, so ended up using stone colors instead. At least there are many block alternatives in that color.. But the build is looking a bit too gray.. Will see if I can add more details and improve walls later.. But at least now I have outer walls, and can potentially leave them alone while starting to build village within instead..
The bottom part of the wall will definitively get more mossy cobblestone variants later, but tired of messing with walls for now.. Though I guess I should complete the bridge over the water, so the entrance part looks ok..
Three redstone gates in here now, splitting up the 3 areas within, and I think the whole area should be mob proof now.. Used a ton of blocks though. Got empty of cobblestone, stone and dirt at some point, so have digged within the structure to get more blocks, so pretty large areas of hollowed out space within here too now.. Where I'll put up some more auto-farms I think...
Hi I’m bao/Azkamenk42 I made a village and an an island home working on a small mansion anyone have any ideas for what I should do to the inside
I like fantasy pirates pvp building and destroying
Mine does fine with vanilla Minecraft at normal render distances and such too. I don't think even modern versions demand much there.
It's when you get into shaders, resource packs, higher render distances, or some combination that can cause large performance degradation.
If there's one thing I learned with this game over the last decade, it's that it doesn't care what CPU or graphics card you have if you push certain things too far. This game can and will humble it.
I'm glad to see your hardcore world has progressed into the "building" parts. Those are my favorite parts.
The reason is because every part of an entity requires a separate draw call and these are expensive; a chest requires that the game tell the GPU to render three separate pieces; a chicken has 8 separate pieces, and so on. Worse, the game needs to switch between textures, which is also expensive, when rendering an entity and its shadow, as well as any equipment it has (the game stitches all block textures into a single texture atlas precisely because each draw call can only reference one texture at a time).
To illustrate just how different block and entity rendering is, all blocks can be rendered in as little as 3 draw calls (at least in 1.6.4, when Fancy graphics, or translucent blocks/water are enabled; Fast graphics only requires 2 draw calls, plus a handful of OpenGL state changes):
private int renderSortedRenderers(int par1, int par2, double playerX, double playerY, double playerZ) { if (!this.fastRender) return renderSortedRenderers_old(par1, par2, playerX, playerY, playerZ); this.glListBuffer.clear(); int var6 = 0; boolean var7 = this.mc.gameSettings.showDebugInfo; int x = MathHelper.floor_double(playerX) - 8; int z = MathHelper.floor_double(playerZ) - 8; for (int var8 = par1; var8 < par2; ++var8) { ChunkRenderer var9 = this.sortedChunkRenderers[var8]; if (var7) { if (var9.skipRenderPass0 && var9.skipRenderPass1) { ++this.renderersSkippingRenderPass; } else if (!var9.isInFrustum) { ++this.renderersBeingClipped; } else if (this.advancedOpengl && !var9.isVisible) { ++this.renderersBeingOccluded; } else { ++this.renderersBeingRendered; } } if (var9.isInFrustum && !var9.skipRenderPass0 && (!this.advancedOpengl || var9.isVisible)) { if (var9.shouldRender(x, this.playerHeight, z, this.renderRadius1, this.renderRadius2)) { int var10 = var9.getGLCallListForPass0(); if (var10 >= 0) { this.glListBuffer.put(var10); ++var6; if (var6 >= MAX_GL_LISTS) break; } } else if (var7) { ++this.renderersBeingOccluded; --this.renderersBeingRendered; } } } if (var6 > 0) { this.glListBuffer.flip(); GL11.glTranslatef((float)(-playerX), (float)(-playerY), (float)(-playerZ)); GL11.glCallLists(this.glListBuffer); GL11.glTranslatef((float)playerX, (float)playerY, (float)playerZ); } return var6; }By contrast, this is what the game calls to render every single piece of an entity - in the extreme case, horses have 39 pieces (and were likely simplified in part because of how demanding such a complex model is - one of the only times I experience a lag spike while playing is when a horse renders for the first time, due to the cost of constructing its model (it doesn't help that it combines multiple layers of textures), which isn't compiled until an entity is rendered for the first time):
public void render(float par1) { if (!this.isHidden) { if (this.showModel) { if (!this.compiled) { this.compileDisplayList(par1); } GL11.glTranslatef(this.offsetX, this.offsetY, this.offsetZ); int var2; if (this.rotateAngleX == 0.0F && this.rotateAngleY == 0.0F && this.rotateAngleZ == 0.0F) { if (this.rotationPointX == 0.0F && this.rotationPointY == 0.0F && this.rotationPointZ == 0.0F) { GL11.glCallList(this.displayList); if (this.childModels != null) { for (var2 = 0; var2 < this.childModels.size(); ++var2) { ((ModelRenderer)this.childModels.get(var2)).render(par1); } } } else { GL11.glTranslatef(this.rotationPointX * par1, this.rotationPointY * par1, this.rotationPointZ * par1); GL11.glCallList(this.displayList); if (this.childModels != null) { for (var2 = 0; var2 < this.childModels.size(); ++var2) { ((ModelRenderer)this.childModels.get(var2)).render(par1); } } GL11.glTranslatef(-this.rotationPointX * par1, -this.rotationPointY * par1, -this.rotationPointZ * par1); } } else { GL11.glPushMatrix(); GL11.glTranslatef(this.rotationPointX * par1, this.rotationPointY * par1, this.rotationPointZ * par1); if (this.rotateAngleZ != 0.0F) { GL11.glRotatef(this.rotateAngleZ * (180F / (float)Math.PI), 0.0F, 0.0F, 1.0F); } if (this.rotateAngleY != 0.0F) { GL11.glRotatef(this.rotateAngleY * (180F / (float)Math.PI), 0.0F, 1.0F, 0.0F); } if (this.rotateAngleX != 0.0F) { GL11.glRotatef(this.rotateAngleX * (180F / (float)Math.PI), 1.0F, 0.0F, 0.0F); } GL11.glCallList(this.displayList); if (this.childModels != null) { for (var2 = 0; var2 < this.childModels.size(); ++var2) { ((ModelRenderer)this.childModels.get(var2)).render(par1); } } GL11.glPopMatrix(); } GL11.glTranslatef(-this.offsetX, -this.offsetY, -this.offsetZ); } } }As an illustration of just how costly entity rendering is, 100 chickens has a bigger impact on FPS than going from a default Superflat world, with only a few chunks in view, to a normal world at maximum (16 chunks) render distance, or even in a "mega forest" biome:
This is also why the game is fairly aggressive on entity culling; chickens only render up to 28 blocks away (the distance is based on their size) and the server doesn't send most entities to the client unless they are within 80 blocks (does the "entity distance" slider affect either of these?); in the last two examples above the client isn't rendering any entities despite there being around 400 loaded server-side and around 100 client-side (the "mob counts" is server-side while "E:" is client-side).
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?
Pardon me if I didn't fully understand, but I thought it was possible to combine the different parts of the model to make a single mesh, so that it only takes one draw-call per entity.
Has Mojang overlooked this, Or is there some reason why the can't?
I don't know how to read code so that bit is entirely lost on me, but this paragraph explains the general consequence of it.
I was just surprised that the performance impact wasn't there there 1.16 but was 1.18. The only time I saw issues in 1.16 was when i was in the cean clearing kelp and would come to the surface and see what must have been hundred (thousands?) of kelp items floating. But my village was fine. Any ideas there on what may have changed (Minecraft itself and OptiFine changed; BSL stayed the same)? Or are you not that familiar with newer versions/OptiFine's changes/shaders? I even tried with it set to peaceful to rule out the potential additional mob spawns from the deeper underground and it made absolutely no difference. It was entirely my village and entirely entity shadows.
And this was confusing. Like why is the above screenshot showing a 32 FPS to 60 FPS (maybe more due to cap) difference from JUST entity shadows being on or off? The majority of the entities are behind me (cows) or should be being culled due to not being directly displayed, no?
Also, does this explain why my VRAM and GPU performance goes so South in jungles specifically? Or might that be because of my love for the bushy leaves resource? It sometimes happens with larger forests but almost always with jungles, even a "custom" one I grew. VRAM in particular seems to get consumed like nothing in a jungle. Worse, once it passes my VRAM amount (or more like a bit below it around 5.6 GB to 5.8 GB) and starts using system RAM, I noticed VRAM use never drops and my performance keeps suffering with stutters, unless I reload all chunks usign F3+A, which resets VRAM use. I'm hoping a video card upgrade will help with more performance (AND VRAM buffer) for using these shaders...
The game only appears to do this if you call ModelRenderer.addBox (as MCP named it in 1.6.4), and this only works if the individual pieces are fixed relative to each other (no rotation or movement along an axis, such as head, arms, and legs). I'm not sure why they didn't do this for horses, maybe because they took the model directly from Mo Creatures (I'm of the opinion that many modders spend very little effort on optimizations). Conversely, the snout of a pig is rendered at the same time as its head.
Also, when I added fish mobs I initially copied the model from Future MC's source (itself an adaptation of the original source from 1.13+; I used it since this is one of the few places I've found source code from 1.13+ as MCP stopped being updated at 1.12. The code for the entity itself was all written by myself, the main reason I haven't added that many new entities (with unique models) is because of how hard it is to understand how the model rendering works) but later replaced with with my own model which only requires two draw calls and minimal state changes (just the ones that set the entity's initial rotation and position) - the difference in performance was quite remarkable, even just re-rendering the entire model from scratch (via the "tessellator") was significantly faster (the tail is dynamically rendered to create its rotation, rather than using glRotatef or the like):
There are many other parts of the vanilla 1.6.4 rendering code which I optimized, for example, the item rendering code is quite bad - each face of a block is rendered separately and more complex items, such as fences, may have dozens of faces; each side of an item frame is an "item block" so this also significantly optimizes item frames (even my earliest optimization to the rendering of maps in item frames gave an amazing performance boost; the vanilla code was updating the entire 128x128 map texture and re-uploading it to the GPU every frame, which I changed so only 1/8 of it is updated every 8 frames, and the texture itself is only re-uploaded to the GPU once every 64 frames, with multiple maps staggered to help ensure they don't all update at once).
Maybe some of the worst rendering code was the way vanilla rendered fonts, using the simplest and least efficient OpenGL, sending each vertex separately, as opposed to use a vertex array or precompiled display list (or VBO, which are pretty which the same thing as modern GPU drivers internally handle them as such) - by rewriting it to use the tessellator the time taken to render the debug screen decreased by an order of magnitude:
private float renderDefaultChar(int par1, boolean par2) { float var3 = (float)(par1 % 16 * 8); float var4 = (float)(par1 / 16 * 8); float var5 = par2 ? 1.0F : 0.0F; this.renderEngine.bindTexture(this.locationFontTexture); float var6 = (float)this.charWidth[par1] - 0.01F; GL11.glBegin(GL11.GL_TRIANGLE_STRIP); GL11.glTexCoord2f(var3 / 128.0F, var4 / 128.0F); GL11.glVertex3f(this.posX + var5, this.posY, 0.0F); GL11.glTexCoord2f(var3 / 128.0F, (var4 + 7.99F) / 128.0F); GL11.glVertex3f(this.posX - var5, this.posY + 7.99F, 0.0F); GL11.glTexCoord2f((var3 + var6 - 1.0F) / 128.0F, var4 / 128.0F); GL11.glVertex3f(this.posX + var6 - 1.0F + var5, this.posY, 0.0F); GL11.glTexCoord2f((var3 + var6 - 1.0F) / 128.0F, (var4 + 7.99F) / 128.0F); GL11.glVertex3f(this.posX + var6 - 1.0F - var5, this.posY + 7.99F, 0.0F); GL11.glEnd(); return (float)this.charWidth[par1]; }For comparison, this is how I rewrote the code - an entire string, including its shadow (the same string rendered twice) is rendered all at once instead of character by character (an exception, I did not refactor Unicode as it isn't used by vanilla text and requires swapping between font textures if different character sets are used, each of which needs a separate draw call anyway):
private float renderDefaultChar(int par1, boolean par2) { float var3 = (float)((par1 & 15) << 3) / 128.0F; float var4 = (float)(par1 >> 4 << 3) / 128.0F; float var5 = par2 ? 1.0F : 0.0F; float var6 = (float)this.charWidth[par1] - 1.01F; if (!this.isDrawing) { this.isDrawing = true; fontTessellator.startDrawingQuads(); } this.setColor(fontTessellator); fontTessellator.addVertexWithUV_C(this.posX + var6 + var5, this.posY, 0.0F, var3 + var6 / 128.0F, var4); fontTessellator.addVertexWithUV_C(this.posX + var5, this.posY, 0.0F, var3, var4); fontTessellator.addVertexWithUV_C(this.posX - var5, this.posY + 7.99F, 0.0F, var3, var4 + 0.062421875F); fontTessellator.addVertexWithUV_C(this.posX + var6 - var5, this.posY + 7.99F, 0.0F, var3 + var6 / 128.0F, var4 + 0.062421875F); return (float)this.charWidth[par1]; }Similarly, I improved the rendering speed of Fancy clouds by more than an order of magnitude by optimizing the code itself, and caching the rendered model and only updating it when needed (as they/the player moves and at sunrise/sunset, due to the color changing) - in fact, they actually take less time to render than Fast clouds in vanilla! I also fixed MC-997 so clouds can always be translucent and MC-3784 so terrain is properly rendered behind them (note that I fixed both of these before they were fixed in vanilla, although I didn't release an update with the fixes until the following year, a lot of my fixes were originally added to a personal copy of Optifine before I separated them):
https://www.minecraftforum.net/forums/minecraft-java-edition/survival-mode/297957-what-have-you-done-recently?comment=6404
Basically, a lot of my optimizations to rendering have been to reduce the amount of direct calls to OpenGL as much as possible; the chunk rendering code I showed before is from my "fast render" code, which cuts out a lot of stuff that the vanilla renderer does, at the cost of floating-point precision errors at far distances (chunks start to jitter, this is a lot like an issue that affected vanilla prior to Beta 1.8, I do have an option to disable it but I never see myself going anywhere near the point where it becomes noticeable; likewise, I actually removed the fix for the bug that caused the Far Lands as it adds unnecessary code, but due to other changes to the noise generator terrain generates normally past at least 30 million, and otherwise, I see no point to going that far out and even added an invisible wall at 30 million that makes it impossible for the player to get past, even if you use an NBT editor (you can otherwise go to the 32 bit limit which crashes the game; preventing such situations is another thing I see as important, e.g. I fixed MC-51418 well before it was fixed in vanilla as part of ensuring all options are valid, the lack of which has caused various versions to crash. Also, due to the way my lightmap code works setting gamma to 100 or something wouldn't work anyway, total darkness is still pitch black).
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?
Match it to the style of the other structures and setup a beacon inside with decor. Then put a conduit by the island home and give it the same decor.
I've seen almost none of the code for any version since 1.13, and mostly just from open-source mods that backport various features (as I mentioned in my last post I originally took the fish model from a mod that backported them) but 1.17 made a major change to rendering - the game no longer uses "fixed-function" OpenGL rendering (1.6.4 technically only needs OpenGL 1.3, or OpenGL 1.2 with a "multitexture" extension - which was released in 1998-2001, and all fixed-function rendering was officially deprecated in 2008 - before development on Minecraft started, I assume that Notch just used what he learned years earlier).
Now, supposedly, using modern OpenGL should give a major performance boost*, especially on modern hardware (no GPU has supported the fixed-function pipeline since the early-mid 2000s, it is all emulated with shaders (in this context, a program the GPU executes to perform some task, much like a CPU) but as if often the case Mojang doesn't seem to have implemented it very well:
MC-219639 Performance loss after using OpenGL 3.2 core profile
*I should note that what I've seen is very mixed; e.g. some claim that VBOs are faster than display lists while others say the opposite, particularly on NVIDIA hardware; the main advantage of VBOs seems to be that you can update them without re-rendering everything from scratch but it appears that Mojang doesn't do this, otherwise chunk updates shouldn't cause lag spikes (I should also note that 1.8 moved chunk updates to a separate thread; this comment claims that OpenGL itself prevents fully multithreaded updates; Optifine did try hacking it (before 1.8) but it often resulted in graphical artifacts). Either way, the efficiency of your own code is also important (as I've noted of vanilla, especially since 1.8), the advice given in the first link also mentions what I've been doing (render multiple things in one go instead of separately).
As far as jungles and VRAM usage goes, more complex geometry directly impacts VRAM usage, though 5+ GB seems very excessive, unless you are using a high render distance (for comparison, my old computer with 256 MB of dedicated VRAM would have issues with Fancy leaves in my own "mega tree" biomes, which have far more leaves/rendered surfaces than jungles (jungles do have vines though, which are each equivalent to two faces; backface culling removes one when drawn to the screen but the vertex mesh still contains both), causing FPS to suddenly drop to single digits when VRAM was exhausted. Given that this was at 8 chunks and each doubling of render distance increases VRAM usage by about 4-fold 32 chunks might use 4+ GB, and while I know about nothing about shaders but I've seen mention of high VRAM usage; this page mentions up to 10 GB of VRAM usage on high-end shaders/resource packs).
Also, I'm not sure how OpenGL stores vertex data in VRAM but each vertex uses 28 bytes in the tessellator buffer (4 bytes each for the x, y, z coordinates, u and v texture coordinates, brightness, and color); a 16x16x16 cube of Fancy leaves has 98,304 vertices (6 faces per block and 4 vertices per face) and requires 2.625 MB; in this scene I analyzed about 1 million leaf blocks within render distance, which at worst-case would require 640 MB of memory (the number rendered to the screen is much less but the data for every loaded non-empty chunk section is stored in VRAM and I imagine this takes up the vast majority of VRAM. Not every leaf block is rendering every face since they are adjacent to a solid block, e.g. logs).
Speaking of leaves, there is no benefit to using Fast graphics (leaves) in current versions due to a bug which has somehow persisted since 1.15 (the game is always rendering the faces of leaves adjacent to other leaves, which are normally culled on Fast graphics since they are rendered as opaque), and is a resurgence of an older bug which originally appeared in 1.8 and was fixed in 1.9 (which may explain why jungles were so bad for my performance in 1.8, though this did not explain the general issues and I don't remember 1.9 doing much):
MC-85132 Leaves are not culled in fast mode (1.8)
MC-179383 Leaves not culled with graphics set to Fast (1.15-1.19)
It is possible that Optifine fixes this but I don't know if it does (other mods do; in general, for newer versions performance mods like Sodium are far superior to Optifine but they don't support shaders or any of the various graphical effects supported by Optifine, though there are mods which implement them separately).
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?
Oh, okay, I'm going to presume that might be part of it. I was totally unaware of any rendering changes. I thought 1.15 or something was the last time something relatively major happened with that. I never played in 1.17 and just went from 1.16 to 1.18.
I play at a render distance of 16 in the world in question. I could maybe do 24 at times but even that would be pushing it to run everywhere as it would cause more severe drops in heavy areas, so I just stay at 16. As it is, jungles in particular already do that.
Given what you're saying, it sounds like it shouldn't be having an impact that high? This is generally (a severe example of) what happens within one. And yes I know the performance is low because of the GPU use itself but it's mostly the VRAM use I'm intending to show here.
I do play with triple buffering, as it's necessary to prevent frame rate drops from my refresh rate from being more severe, and I imagine that makes a difference to VRAM, but I'm not sure how much.
That link specifically mentions PBO like features can use a lot of VRAM and I'm not using any of those.
I'm using a 32x resource pack (two for full disclosure, if this does something silly like double the impact?) along with the aforementioned "bushy leaves". I can't go without that, I need them! I'm guessing this is a big part of VRAM use but I didn't know if it should be expected to be that high.
And I'm using anti-aliasing (TAA in the shaders options).
I... think that's the only noteworthy stuff that i can think of that might effect VRAM? Use is usually rather "low" until a jungle (or sometimes a lot of trees/forests) enter the equation.
(Also, now that I loaded that world up, I want to play it, but I've got more progress to "finish" on my hardcore world first.)
Yeah, I've been hearing more and more about alternatives, and looked into them a while back.
I tried Sodium or whatever they are on my old laptop, and found performance wasn't a whole lot better than OptiFine, but that laptop's CPU just wasn't ideal for anything past probably 1.12 (or 1.6 really).
For now on my desktop I just stay with OptiFine because it's what I'm familiar with, and is a "one step solution" that offers me good enough performance and supports everything I want. My current performance issues seem specifically with shaders so I wasn't thinking staying with OptiFine was doing me any disservices, but if alternatives become simpler and/or OptiFine presents issues in the future, I'll give them another look.