MC-276877Chests are far more expensive to render than most other blocks
The bug
Chests, including trapped chests and ender chests, are considerably more resource-intensive to render compared to other blocks in the game, even those with more complex models. This is due to a multitude of factors:
- For rendering, chests utilise block entities, unlike most other blocks, which use block models. Since chests only animate when interacted with, having a block entity used for rendering every part of a chest at all times is unnecessary and is responsible for the majority of chest-related lag.
- Each closed chest renders three planes that are never visible in normal gameplay: specifically the back of the lock, and the two interior textures. These are only visible when the chest is in an open state.
- In addition, the lid of the chest and the main body of the chest use separate cuboids for rendering, meaning that the four outer horizontal faces use two quads each when only one is strictly required.
- Finally, due to not using the entity model system, chests against solid opaque blocks will not have their faces culled, causing them to still be rendered despite the fact they will never be visible.
As chests are widely used in very large amounts in storage systems, chest lag in personal worlds is a common issue.
How to reproduce
Two resource packs are attached to this ticket: one which introduces models for chests based on the json model format, and one which remodels placed cobwebs to use the model for single chests.
- Download and apply the "chest-fix-resources" pack, and the "chest-performance-test" pack on top of it
- Create a The Void superflat world with doDaylightCycle and doWeatherCycle disabled
- Set your render distance to 3, FOV to default, and disable VSync
- Use F3+2 to open performance graphs
/tp @s 16.5 -60 16.5 135 -22.5
/fill -8 -60 -8 7 -45 7 cobweb
, observe
/fill -8 -60 -8 7 -45 7 chest[facing=south]
, observe
/fill -8 -60 -8 7 -45 7 barrel
, observe
Expected results
Chests wouldn't hurt performance by a lot.
Actual results
They do. We can confirm that the block-entity rendering is the main issue rather than simply the presence of a block entity, as barrels did not cause the same levels of lag.
How to fix
The issue here is obvious - most of the lag comes from the fact that, despite chests being stationary 99% of the time, a block entity is still used for rendering them, when this would only be necessary for the opening/closing animation.
The attached resource pack includes model files for a "closed" chest, an "open" chest with no lid, and a model for the lid itself. Equivalent models for large chests are also included.
Closed chests could be rendered using standard block models 100% of the time. For open chests, since the main body of the chest remains stationary, it too could be rendered using just a block model. The only thing requiring a block entity for rendering would be the lid, as it would be in motion when closing and opening the chest (much like is the case for the book on an enchanting table).
As part of fixing this, I've also split up each chest texture into one texture file for each face (and one texture file for each chest type's lock), located in the textures/block directory rather than the textures/entity/chest directory. These split textures, alongside being easier and more intuitive to customize than the current strangely-mapped format, should also take up much less space on an atlas (81 spaces in total, compared to the current 192) due to there being much less dead, unused space in the texture file.
Retiring block-entity rendering would also fix several other issues for chests, such as MC-69683 and MC-231102, as well as the problem where they de-render too early at a distance.
Linked Issues
Normal
Created Issue:
Chests are far more expensive to render than most other blocks
Relates to
MC-276855.The bug
Chests, including trapped chests and ender chests, are considerably more resource-intensive to render compared to other blocks in the game, even those with more complex models. This is due to a multitude of factors:
- For rendering, chests utilise block entities, unlike most other blocks, which use block models. Since chests only animate when interacted with, having a block entity used for rendering every part of a chest at all times is unnecessary and is responsible for the majority of chest-related lag.
- Each closed chest renders three planes that are never visible in normal gameplay: specifically the back of the lock, and the two interior textures. These are only visible when the chest is in an open state.
- In addition, the lid of the chest and the main body of the chest use separate cuboids for rendering, meaning that the four outer horizontal faces use two quads each when only one is strictly required.
- Finally, due to not using the entity model system, chests against solid opaque blocks will not have their faces culled, causing them to still be rendered despite the fact they will never be visible.
As chests are widely used in very large amounts in storage systems, chest lag in personal worlds is a common issue.
How to reproduce
Two resource packs are attached to this ticket: one which introduces models for chests based on the json model format, and one which remodels placed cobwebs to use the model for single chests.
- Download and apply the "chest-fix-resources" pack, and the "chest-performance-test" pack on top of it
- Create a The Void superflat world with doDaylightCycle and doWeatherCycle disabled
- Set your render distance to 3, FOV to default, and disable VSync
- Use F3+2 to open performance graphs
, observe
, observe
, observe
Expected results
Chests wouldn't hurt performance by a lot.
Actual results
They do. We can confirm that the block-entity rendering is the main issue rather than simply the presence of a block entity, as barrels did not cause the same levels of lag.
How to fix
The issue here is obvious - most of the lag comes from the fact that, despite chests being stationary 99% of the time, a block entity is still used for rendering them, when this would only be necessary for the opening/closing animation.
The attached resource pack includes model files for a "closed" chest, an "open" chest with no lid, and a model for the lid itself. Equivalent models for large chests are also included.
Closed chests could be rendered using standard block models 100% of the time. For open chests, since the main body of the chest remains stationary, it too could be rendered using just a block model. The only thing requiring a block entity for rendering would be the lid, as it would be in motion when closing and opening the chest (much like is the case for the book on an enchanting table).
As part of fixing this, I've also split up each chest texture into one texture file for each face (and one texture file for each chest type's lock), located in the textures/block directory rather than the textures/entity/chest directory. These split textures, alongside being easier and more intuitive to customize than the current strangely-mapped format, should also take up much less space on an atlas (81 spaces in total, compared to the current 192) due to there being much less dead, unused space in the texture file.
Retiring block-entity rendering would also fix several other issues for chests, such as MC-69683 and MC-231102, as well as the problem where they de-render too early at a distance.
Attachments5
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Relates to
MC-276855.The bug
Chests, including trapped chests and ender chests, are considerably more resource-intensive to render compared to other blocks in the game, even those with more complex models. This is due to a multitude of factors:
- For rendering, chests utilise block entities, unlike most other blocks, which use block models. Since chests only animate when interacted with, having a block entity used for rendering every part of a chest at all times is unnecessary and is responsible for the majority of chest-related lag.
- Each closed chest renders three planes that are never visible in normal gameplay: specifically the back of the lock, and the two interior textures. These are only visible when the chest is in an open state.
- In addition, the lid of the chest and the main body of the chest use separate cuboids for rendering, meaning that the four outer horizontal faces use two quads each when only one is strictly required.
- Finally, due to not using the entity model system, chests against solid opaque blocks will not have their faces culled, causing them to still be rendered despite the fact they will never be visible.
As chests are widely used in very large amounts in storage systems, chest lag in personal worlds is a common issue.
How to reproduce
Two resource packs are attached to this ticket: one which introduces models for chests based on the json model format, and one which remodels placed cobwebs to use the model for single chests.
- Download and apply the "chest-fix-resources" pack, and the "chest-performance-test" pack on top of it
- Create a The Void superflat world with doDaylightCycle and doWeatherCycle disabled
- Set your render distance to 3, FOV to default, and disable VSync
- Use F3+2 to open performance graphs
, observe
, observe
, observe
Expected results
Chests wouldn't hurt performance by a lot.
Actual results
They do. We can confirm that the block-entity rendering is the main issue rather than simply the presence of a block entity, as barrels did not cause the same levels of lag.
How to fix
The issue here is obvious - most of the lag comes from the fact that, despite chests being stationary 99% of the time, a block entity is still used for rendering them, when this would only be necessary for the opening/closing animation.
The attached resource pack includes model files for a "closed" chest, an "open" chest with no lid, and a model for the lid itself. Equivalent models for large chests are also included.
Closed chests could be rendered using standard block models 100% of the time. For open chests, since the main body of the chest remains stationary, it too could be rendered using just a block model. The only thing requiring a block entity for rendering would be the lid, as it would be in motion when closing and opening the chest (much like is the case for the book on an enchanting table).
As part of fixing this, I've also split up each chest texture into one texture file for each face (and one texture file for each chest type's lock), located in the textures/block directory rather than the textures/entity/chest directory. These split textures, alongside being easier and more intuitive to customize than the current strangely-mapped format, should also take up much less space on an atlas (81 spaces in total, compared to the current 192) due to there being much less dead, unused space in the texture file.
Retiring block-entity rendering would also fix several other issues for chests, such as MC-69683 and MC-231102, as well as the problem where they de-render too early at a distance.
relates to
![[Mojang] Triage Team](../../../data/avatars/users/89842.png){kind=small}
Relates to MC-276568.
The bug
When loading the game's resources, Minecraft generates mipmapped textures for all types of chests. However, it does not use them at all, wasting game resources.
How to reproduce
A resource pack is attached to this ticket.
- Download and apply the attached resource pack
/fill ~ ~ ~ ~60 ~ ~60 minecraft:chest
/fill ~ ~ ~ ~60 ~ ~60 minecraft:calcite
- Compare
Expected results
The chests would fade into a smooth gray in the distance, much like the calcite does.
Actual results
No such thing happens and we get incredibly grainy Moire patterns.
How to fix
Either make chests use mipmapping like other blocks (easily doable if MC-276877 gets fixed), or don't generate these mipmapped textures for chests at all. Several other atlases (gui, map decorations, mob effects, paintings, particles) don't generate mipmapped versions of themselves, so why should chests if they're not going to be used?
The bug
If a chest with an enchantment glint is equipped on a mob which can have a chest equipped, the enchantment glint will not play. This is unlike saddles, which correctly show the enchant glint.
How to reproduce
- Tame a donkey
/give @s saddle[minecraft:enchantment_glint_override=true]/give @s chest[minecraft:enchantment_glint_override=true]- Equip both on the donkey
Expected results
Both the saddle and chest would display the enchantment glint.
Actual results
The saddle correctly displays the enchantment glint, but the chest does not.
How to fix
Make the chest rendering be handled by the equipment system; this would also fix MC-279508.
Further notes
Chests as items do not display the enchantment glint due to a bug; see MC-69683. This could be fixed by reopening and actually fixing MC-276877, as the item would then no longer be using the block entity rendering system.
Is this different to MC-5417? The two reports seem to describe the same bug, only the other describes the issue more broadly with this one getting into specifics.
Just saw this comment after reporting shulker boxes separately. Perhaps? I think it might be worth contacting Mojang for whether it'd make more sense to have this be three separate reports, since they appear to have triaged that report.
There is the fact that the ticket in question specifically addresses that performance has decreased as of 1.13, so there may be a different issue specifically related to block entity rendering, whereas these three tickets advise to abandon block entity rendering almost entirely, so it may be worth keeping that as a separate report.
Thank you for your report!
After consideration, the issue is being closed as Invalid.
This report does not describe a bug.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
How is a severe performance issue not a bug?
Connor Steppie, this is already being tracked under MC-5417 is what I think mojang is saying.
If that was the case, why didn't they resolve it as such?