douira

I've conduced a test, and removing the `FluidState.shouldRenderBackwardUpFace` check makes this issue go away, however it also substantially changes how flooded caves look from the inside and generates twice as much geometry for their water surfaces. To both make sure inside upper water faces are generated for flowing water and flooded caves don't regress, a better heuristic for distinguishing these cases is needed, i.e. this bug is kinda complicated.

I've attached a comparison image.

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.

I've been experiencing this issue, but with the updater, since a launcher update that must have happened just hours ago. The launcher would not update repeatedly (and crashed itself) until I tried it with a VPN. The native updater log contains many entries like this:

[Info: 2023-03-16 02:54:30.093181: NetQueue.cpp(573)] NetQueue: Action finished: https://redstone-launcher.mojang.com/beta/v2/objects/842d75962928a1059cd38e216481ef7d8494014b/allayreveal.zip
[Info: 2023-03-16 02:54:30.093369: NetQueue.cpp(615)] Action finalized: https://redstone-launcher.mojang.com/beta/v2/objects/842d75962928a1059cd38e216481ef7d8494014b/allayreveal.zip
[Info: 2023-03-16 02:54:30.111511: NetQueue.cpp(484)] NetQueue: Primary ip: 13.107.237.45, Host: redstone-launcher.mojang.com
[Error: 2023-03-16 02:54:30.111538: NetQueue.cpp(533)] NetQueue: Action failed with result "transfer closed with 7719726 bytes remaining to read" (18) : https://redstone-launcher.mojang.com/beta/v2/objects/4c99d76dba6199b18a47aff290f867a1dfd6e606/allayidle.zip
[Info: 2023-03-16 02:54:30.111551: NetQueue.cpp(573)] NetQueue: Action finished: https://redstone-launcher.mojang.com/beta/v2/objects/4c99d76dba6199b18a47aff290f867a1dfd6e606/allayidle.zip
[Info: 2023-03-16 02:54:30.111712: NetQueue.cpp(594)] Action should retry: https://redstone-launcher.mojang.com/beta/v2/objects/4c99d76dba6199b18a47aff290f867a1dfd6e606/allayidle.zip
[Info: 2023-03-16 02:54:30.111732: NetQueue.cpp(695)] NetQueue: Starting net action https://redstone-launcher.mojang.com/beta/v2/objects/4c99d76dba6199b18a47aff290f867a1dfd6e606/allayidle.zip

This still happens in 1.16.5 for me. It doesn't happen all the time but it seems to happen more when the FPS is low. I've added a video of it. Skipping through it frame-by-frame reveals what happens.

You need to attach the crash report itself, not a picture of the window. How to find the crash report is described here: https://minecrafthopper.net/help/guides/finding-minecraft-data-folder/

This is happening to me on 1.15.2

I still get this issue on a 1.9.2 server: (Is this another bug or the same one ?)
[15:35:35] [Server thread/WARN]: Keeping entity Zombie that already exists with UUID 4b8f8373-7dcf-4863-97b7-b970749d8da3
[15:35:35] [Server thread/WARN]: Keeping entity Zombie that already exists with UUID 39332185-ef35-44b6-b052-29746acacac3
[15:35:35] [Server thread/WARN]: Keeping entity Enderman that already exists with UUID 3c3fa926-1e41-4a22-ba32-c63d24b71954
[15:35:35] [Server thread/WARN]: Keeping entity Pig that already exists with UUID 25985b03-21a5-4e9a-8ea2-4e37f59aa08a
[15:35:35] [Server thread/WARN]: Keeping entity Bat that already exists with UUID 149bb2ca-cd28-4349-9c5a-6a54765b9cca