Chests 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.

1. Download and apply the "chest-fix-resources" pack, and the "chest-performance-test" pack on top of it

2. Create a The Void superflat world with doDaylightCycle and doWeatherCycle disabled

3. Set your render distance to 3, FOV to default, and disable VSync

4. Use F3+2 to open performance graphs

5. /tp @s 16.5 -60 16.5 135 -22.5

6. /fill -8 -60 -8 7 -45 7 cobweb

   , observe

7. /fill -8 -60 -8 7 -45 7 chest[facing=south]

   , observe

8. /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.