Order of rendering translucent block faces fails to update with camera position

Duplicated by MC-38842

Happened to me in 14w19a with an Intel HD 4000, mipmapping or anisotropic filtering turned off.

How to reproduce

• Create New World

• Select "Customized" World type

• Choose "FrozenOcean" biome

Attached crash report.

Reopened, not a duplicate of MC-35881

@@unknown: You can probably update to OX X 10.9.x for free https://itunes.apple.com/us/app/os-x-mavericks/id675248567?mt=12

Same result with another computer using an Intel HD 5000 and running OS X 10.9.2.

@Kumasasa This OS X version is too unstable on my computer 🙂

WTF ? Unstable software made by Apple ? Impossible.... 😉

@all: Anyone having this issue: Please force a crash by pressing F3 + C for 10 seconds while in-game and attach the crash report ([minecraft/crash-reports/crash-<DATE>-client.txt|http://hopper.minecraft.net/help/finding-minecraft-data-folder]) here.

There is a lot of issues with this issue 😉
Some are due to people confusing this bug with MC-9553. For example the "render like water" part from the title was caused in part by MC-9553 and hasn't been reproducible since it's been fixed. It's also specific to the ice + water setup, and isn't representative of the bug. The title also suggests "elevation and angle" has something to do with this but it doesn't, it happens at any angle. You can check that by pressing F3 + T and the bug will go away until you start moving again. Also the bug desc is really meagre, there's a lot more information that's missing.

I request the following be done:
1. Attachments 2015-06-09_15.51.45.png 2018-08-21_12.50.01.png Screenshot-Slime-Light-Bad.png are showing MC-9553 and not relevant and should be removed
2. Attachments crash-2014-05-13_10.54.01-client.txt crash-2014-07-02_19.22.27-client.txt 2014-05-13_11.03.30.png are not relevant and should be removed
2.5 All other attachments could be removed tbh since they're redundant. But idk your policy on that.
3. Update the title to "Order of rendering translucent block faces fails to update with camera position"
4. Update the description:

The Bug:

Various visual artifacts appear on translucent blocks after movement, because whatever handles sorting translucency layers does not update as you move around.

How to reproduce:

1. Create a superflat world with preset

minecraft:bedrock,minecraft:green_stained_glass,minecraft:red_stained_glass,minecraft:blue_stained_glass;minecraft:the_void

2. Fly up ~10 blocks (doesn't matter much)

3. Use command /tp @p 100 ~ 100 135 45
4. Press F3 + T (then wait for chunks to load)
5. Use command /tp @p 0 ~ 0 -45 45
6. You will notice you cannot see the green and red glass in multiple chunks

Analysis:

There's probably some kind of mechanism that calculates which translucent block faces are closest to the camera, and then sorts them into the correct rendering order, so that blocks render in front of each other as would be expected. However this ordering task seems to only run sporadically (once when a chunk loads, and again if you're close enough to the chunk). This obviously leads to issues where after your position changes blocks are "in front" of blocks that are now in front of them.

As of reproduction step 4 the top face of a red glass block is in front of (closer to the camera) two side faces of the blue glass block above it.
As we teleport behind it the order should switch (the top face of the red glass block is now behind those two blue faces) however the rendering thingy doesn't realize this and still thinks the top face of the red glass is in front of the two blue faces. Because of this mismatch the red glass block doesn't render properly behind those two block faces.

Note: The "two faces" I'm talking about are invisible because the block faces are culled when two of the same translucent block are next to each other. However you can see it's indeed the side faces trying to render behind the red glass, by making a hole in the glass thus making them visible.

Corroborating evidence:

What I just described with the glass world is also what's going on with the ice (the water is ordered "in front" of the two inside faces of ice, while it's actually behind them) and before the fix to MC-9553 was implemented the water would actually follow this incorrect order and render in front of the ice.

And indeed if we load up our glass world before MC-9553 was fixed and repeat the steps we'll notice the red glass blocks are actually rendering in front of the blue glass (and the green renders in front of both). This confirms my analysis I think

However after that fix, when such mismatch occurs the pixels that are incorrectly "in front" of something don't render at all which is why it looks different now. However it's still the same issue!

Expected behaviour

The block faces would be sorted on each frame, so that they always render in the correct order.

Can confirm 1.20.4, singleplayer default world, probably outside of simulation distance

Many thanks to @unknown for his very detailed comment!

Hi, I'd like to give an explanation for why this is happening, what possible solutions are, and why this is a hard problem in general. I just finished writing my Master's thesis about solving translucency sorting in Minecraft, with the implementation having been done in Sodium. My last year was spent trying to solve this problem efficiently, with the result being a sophisticated approach that solves it correctly and with low overhead by replacing quad distance sorting with different sorting techniques. The problem is, that if you dig into the how the geometry behaves, it quickly becomes either a graph or a spatial partitioning problem. Even accepting that sorting quads by distance does not always yield a correct result, it's not clear exactly when quad distance sorting needs to be performed.

Looking at the code, Minecraft checks if sorting needs to be performed every time the camera movement is more than 1 block away from the last time sorting was performed. Then, it iterates through all visible sections and sorts at most 15 of them per frame. It selects either any section if the camera has just crossed a chunk boundary, or specifically sections that are axis aligned with the camera ("axis-sharing"), where at least one axis of the section's coordinates is the same as the camera's section coordinates. Intuitively, this makes sense, since as you move the camera the ordering becomes wrong and needs to be re-done. As most geometry is axis aligned, performing sorting preferentially on axis-sharing sections is an okay approximation.

The bug in this report happens when the camera gets into a position where the sort order of a section is invalid but isn't updated since either the camera has not moved enough to trigger sorting or the sorting budget was prematurely exhausted. Teleporting means the camera registers a movement, but then resets the "last sort position" to the current position without having sorted all sections with invalidated sort orders. If it moves a little, unless it moves across a section border, only axis-sharing sections will be sorted, which doesn't resolve the visual glitch. Additionally, if the camera moves in a specific way near sensitive sections, the allowance of 15 sections getting sorted per frame could get repeatedly exhausted, thus starving certain sections of sorting altogether. Layered water and glass or different types of stained glass showcase the problem very easily, because the camera only needs to move a relatively small angle relative to the section before artifacts become visible. This angle depends on the geometry and the perspective on the section.

A simple fix might be to sort sections even when the camera has not moved and to prioritize which sections get sorted based on how long ago they were sorted, or based on the position the camera was at when the section was last sorted. The problem remains that sorting sections by distance is expensive, especially when it needs to happen very frequently to mitigate bugs like this one. There's a lot of optimizations and different approaches that can be applied to Minecraft's surprisingly tractable translucency sorting problem, albeit with the introduction of significant complexity as I showed in my work.

I hope this helps, I'm happy to answer any more questions about the translucency sorting problem should they arise.

@douira This is unrelated to this bug, however i need answers from you regarding a bug you mentioned you used to encounter or maybe still do, specifically bug MC155104. I am getting this consistently on 1.21. Did you ever find a fix for this? Please get back to me as soon as you can.