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.

@Kumsasa Hehe, yet I couldn't shut down it without pressing power button, or the computer turned off itself after 5 minutes, etc. 😞

Confirmed for 14w25b.

Confirmed for 14w27b, on Windows 7 64-bit with latest Java 1.8 and Nvidia GTX 670.

The graphical bug seems to occur largely independent of video settings. I have toggled all video settings and the only setting where I was unable to reproduce the bug was with a Render Distance of 2 chunks. With any Render Distance higher than 2 chunks and any other (combination of) video settings I was able to reproduce the graphical glitch.

The only way the glitch disappears is when the rendering resets (for instance when changing certain video settings) or when the player gets closer to the ice.

Confirmed for 1.8pre2 with a GTX 750 Ti

Confirmed for 1.8.1

Confirmed for 1.8.3, on Windows 8.1 64-bit with latest Java 1.8 and Nvidia GeForce GT 640M.

Confirmed for 15w45a

Can't reproduce in 15w46a. Is this fixed?

Was able to reproduce this in 15w46a, so this is not fixed.

Indeed, not fixed. Create a superflat world with this preset and fly around a bit: 3;minecraft:bedrock,20*minecraft:water,minecraft:ice

Confirmed for 15w47a and 15w47c

Confirmed for 15w51b

Confirmed for 1.9-pre1 and 1.9-pre2

I believe this might have to do with the block transparency.

Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.

This is an automated comment on any open or reopened issue with out-of-date affected versions.

Confirmed for 1.11

Confirmed for 18w08a and is way more prevalent now.

This bug sadly ruins the new Frozen Ocean biome. Added some pics from 18w08b

Confirmed in 18w09a

Confirmed in 18w11a

Affects 18w15a

Affects 18w20c

Confirmed for 18w22c

Affects 1.13-pre1

1.13-pre3

Affects 1.13-pre4

Confirmed for 1.13-pre5 with slimeblocks

Also affects 1.13-pre6

Affects 1.13-pre8

Affects 1.13-pre9

Affects 1.13-pre10

Confirmed for 1.13-release!

Still in 18w30b

Still in 18w31a

Still in 18w32a

Still in 18w33a

Still in 1.13.1-pre1

this happens at chunk borders for me in 1.13

Still in 1.13.1 release

Still in 1.13.2-pre1

Still in 1.13.2-pre2

Still in 18w43b

Still in 18w50a

Still in 19w06a despite the fact that the rendering engine has changed.

Still in 19w07a

Still in 19w08a

Still in 19w09a

Still in 19w11a

Still in 19w11b

Still in 19w12b

Gave the report to @unknown since the original reporter is inactive.

I can't reproduce the ice glitch in 19w40a.

I think it might've been fixed by the new rendering engine.

I don't think this can be marked as fixed just yet, the latest snapshot has major issues with mipmaps, causing a moire effect to appear on ice. This issue didn't seem to appear with mipmaps disabled in 1.14.4 either, so we can't be sure it's been fixed just yet.

No, this bug is still effective despite the new rendering engine!

Confirmed in 19w45b

Confirmed in 20w06a

Confirmed in 20w07a

I just made a post about this not realizing that it was already reported here. This is such a huge graphical bug that has been present for so long and I don't know why it hasn't been fixed yet. I really hope Mojang Studios can fix this in the next version of the game. 

Confirmed in Pre-Release 2 for 1.16

this is an really old bug...I hope mojang can fix this because it last for years so it should be considered to fix in higher priority

It already has "Important" priority. On the other hand, the fact that it's an old bug doesn't make it automatically important, the severity of the issue and how much it affects gameplay / players does

Yes, but it's had "Important" Priority since February, and the bug has existed for 7 years. That's too long for any bug to exist in this game. And I would say that it affects the severity of the gameplay greatly, seeing as literally any water build mixed with glass looks terrible when close to it. It would be 1 thing if this glitch didn't load the glass from barely out of chunk distance, but it can happen as close as 2 chunks away. 

Can confirm in 1.17-pre1.

Can confirm in 1.17.1.

Can confirm in 21w39a.

Can confirm in 21w40a.

Can confirm in 21w41a.

Can confirm in 21w42a. Also this appears to be related to chunk borders. As you can see in this screenshot these square patterns align perfectly with chunk borders

Can confirm in 1.18 Pre-release 1.

Can confirm in 1.18 Pre-release 4.

Confirmed in 1.18 Release Candidate 1.

Can confirm in 1.18.

Can confirm in 1.18.1.

I can confirm in 1.18.2

(seems to be happening extremely frequently for me)

In 1.19 Pre-2.

This also affects stained glass. It would probably be worth updating this ticket to mention this to potentially prevent further duplicate reports in the future.

Can confirm in 1.19.1.

can confirm 1.19.1

Can confirm in 1.20.2

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.