Felix Jones

I suspect that this issue is a duplicate of MC-220690 as the normal rendering state does not allow back-face culling to be disabled for these blocks, and the only time we've managed to observe this occurring incorrectly is with the 3rd party apps that cause MC-220690

Please may anyone able to reproduce this issue also test for MC-220690 by entering spectator mode and flying under the ground?

One of the crash logs seems to suggest that fixed-function GL functions are being called, despite us now using a GL 3.2 Core context and all these functions being entirely removed from the game.

Is anyone able to reproduce this issue using any game overlay apps? Discord overlay, Steam overlay, Riva Tuner, etc. There's a chance that these are assuming Minecraft is still GL 2.1 and are using unsupported GL functions.

EDIT: fuze.tv is the culprit

Reopening as we've managed to find recreation steps for this issue:

1. Use any graphics mode other than fabulous

2. Turn off entity shadows

3. Place a two high pillar of stained glass

4. Use spawn egg to spawn a cow behind pillar

5. Move side to side, every now and then the cow will disappear

We are assuming the "bright ring" is the area immediately outside the darkest black square in the middle of the shadows.

This looks to be an optical illusion (same one as the checkerboard shadow illusion) as the shadow gradient fades to dark, but 1 block before the darkest point it plateaus to grey before suddenly turning dark, the human brain interprets this as the gradient suddenly turning "brighter" when its colour doesn't change.

Dawn Sunset I recommend you open a new issue that more explicitly describes the problem without mentioning "Mesa" or describing the visual results of the issue, there's a fix in the pipeline but if you want it tracked then a more specific description that doesn't mention "Mesa" nor the warning screen would be acceptable (feel free to link to this comment as a quote so mods know what's going on).

I'd describe the actual true issue as "Transparency layers lose their auxiliary depth buffer ID when resized" as this is a proper issue in the code that effects everyone, but by chance majority of GPU drivers avoid it causing problems due to shear luck.

If you create that issue, link back to here, the Mesa report (https://gitlab.freedesktop.org/mesa/mesa/-/issues/3144) and Nicholas Miell's comment here: https://bugs.mojang.com/browse/MC-187411?focusedCommentId=735586&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-735586 as these all describe the true problem.

In brief, this current "resolved" issue is resolved via the warning screen, however the underlying code issue is still there regardless of the warning screen so is what I'd describe a valid issue (again, don't mention Mesa specific visual issues as they are resolved via the warning screen, just describe the code issue as a code issue please).

Thanks loads.

Much appreciate the analysis, thank you. Will look into this further when possible. It's incredible that only Mesa exposes this flaw 

On the warning screen the details "Vendor detected: [X.Org]" and "OpenGL Version detected: [Mesa]" describe why it is not supported. For some reason Mesa doesn't behave the same as other drivers and at this time we can't figure out if it's an issue in Mesa or an issue with what we're doing, so for now Mesa is unfortunately not supported.

If a Mesa update fixes it their end, then the warning screen will at least let you bypass the check, we can also add the specific Mesa update as a check on the warnlist to disable the warning screen. When we figure out why Mesa is behaving differently we can modify the warnlist along with a game update.

Reason we've done this is to reduce the bug tracker tickets that appear as separate rendering issues, but in reality all fall under the same issue of "a specific GPU driver isn't behaving like all the others".

The specific issue with Mesa is that the auxiliary depth buffers are, for a currently unknown reason, returning all zeros in the shader.

In the meantime, and if you choose to, you could try proprietary vendor drivers for your system if any are available.

This issue is actually a separate issue to that of MC-63020 (which describes an issue regarding frustum culling).

I've re-opened this issue as the original frustum culling bug described by MC-63020 is resolved. This issue should now be used for tracking the bug related to "occlusion culling", which is not fixed.

For reference, the occlusion culling bug is identified by having a chunk disappear directly in-front of the player (not in the very edge of the screen) and re-appears when the player moves into the area of the missing chunk - or when the player destroys a block somewhere around the chunk's boundary.

We've taken this issue to specifically describe a bug regarding chunk "frustum culling" - that is the removal of chunks that are behind the player's viewable area - as the title and details for this issue specifically describe frustum culling with the 45 degree angle point being rather key.

Many of the bugs marked "duplicate" are not actually related to the fixed frustum culling issue, but are a separate issue regarding "occlusion culling" - that is the removal of chunks that are behind other chunks (not necessarily behind the player's viewable area).

MC-63021 will be re-opened and used as the issue tracking for "occlusion culling", which has not yet been fixed.

I've described a technique for resolving this issue here; http://imgur.com/a/xxOUw

It utilises glColorMask() and depth buffer to cap-off the inside of a boat to disable water rendering inside it when the water is underneath the lip of the boat.