A chunk section layer that contains more than 65,535 unique baked quads renders every quad past that point with the position and UV data of a different earlier quad. This is a regression introduced in 26.4 snapshot 8, which refactored terrain.vsh to decode a new vertex data packing that stores the baked quad index in 16 bits.
Steps to reproduce:
Install and enable the attached resource pack.
Create a superflat world in creative mode.
Run
/setblock ~2 ~3 ~ minecraft:diamond_blockand/setblock ~6 ~3 ~ minecraft:emerald_block.Look at the top of each block. The emerald block (60,006 quads) has its blue top slab, but the diamond block (66,006 quads) is missing its red top slab, which is drawn with stone geometry instead.
Root cause:
In com.mojang.blaze3d.vertex.SectionBufferBuilder, getOrRegisterBakedQuad returns an unbounded index, and addQuad narrows it to a short with no range check:
int bakedQuadIndex = this.getOrRegisterBakedQuad(quad);
long pointer = this.buffer.reserve(this.layer.vertexBufferFaceSize());
int positionPacked = (packPositionChannel(z) & 0xFF) << 16 | (packPositionChannel(y) & 0xFF) << 8 | packPositionChannel(x) & 0xFF;
MemoryUtil.memPutInt(pointer, positionPacked);
MemoryUtil.memPutShort(pointer + 3L, (short)bakedQuadIndex);terrain.vsh then decodes it as 16 bits:
int bakedQuadIndex = ((int(colorPacked) << 8) & 0xFF00) | ((posPacked >> 24) & 0xFF);
int bakedQuadBufferIndex = vertexBufferOffsets.y + (bakedQuadIndex * PER_BAKED_FACE_INCREMENT) + cornerID * PER_BAKED_FACE_VERTEX_INCREMENT;
Quad 65,536 is stored as 0, quad 65,537 as 1, and so on, so every face past the limit is drawn with another quad's data which pretty much leads to geometry corruption. I also noticed a second detail worth noting, quads are deduplicated per section layer, not per block, so several different large models in the same section count toward the same limit. That means it can happen without any single model reaching 65,536 quads.
Thank you for helping us improve Minecraft! We saved your files: