douira
- douira
- douira
- Europe/Stockholm
- Yes
- No
MC-155104
imm_ptl_state.json
I believe the effect of a "fix" for this issue can be simulated by removing ` || !this.isSideExposed(level, posX, posY, posZ, Direction.DOWN, 0.8888889F)` from [this line in sodium](https://github.com/CaffeineMC/sodium-fabric/blob/d2a68153e5bb6ad59258db5b8e3604e8292f565b/src/main/java/net/caffeinemc/mods/sodium/client/render/chunk/compile/pipeline/DefaultFluidRenderer.java#L114). I've attached pictures of my result in two scenes: one in some water next to a tree and another scene under water in a river.
As you can see it's much darker overall and very different looking. I also think that for consistency reasons you'd need to apply the same effect to the sides of blocks, which makes it even weirder. Possibly making all the inner water surfaces underwater full brightness would make the whole scene less dark, but it would certainly be very blue.
IMO this is an art direction question and not simply an issue of "the fluid renderer is wrong". Even if it could be construed as a matter of visual consistency, it's anything but consistent with what I'd expect to see on the inside of a fluid. (Assuming this patch is actually correct)
You can see there's some lighting issues that would need to be addressed but I think it gets the point across. Realistically, it also doesn't make much sense to have inner water surfaces against blocks, because you know, that's not how water surfaces work irl either.(for some reason these images show up very large, idk how to do this better)
without:
with:
without:
with:
![[Helper] ZeNico13](../../../data/avatars/users/31913.png){kind=small}
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
- Create a superflat world with preset:
minecraft:bedrock,minecraft:green_stained_glass,minecraft:red_stained_glass,minecraft:blue_stained_glass;minecraft:the_void
- Fly up ~10 blocks (doesn't matter much)
- Use this command:
/tp @p 100 ~ 100 135 45
- Press F3 + T (then wait for chunks to load)
- Use this command:
/tp @p 0 ~ 0 -45 45
→
You will notice you cannot see the green and red glass in multiple chunks
Expected behaviour
The block faces would be sorted on each frame, so that they always render in the correct order.
Analysis
Ceresjanin123 has done a good analysis in this comment.
douira has done a good analysis in this comment.
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
This is happening to me on 1.15.2
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 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.
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:
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 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.