Particles and clouds not rendering properly behind stained glass and solid blocks

This happens to me as well.

CPU: AMD Ryzen 5 2600
GPU: AMD Radeon RX 570
OS: Solus Budgie 4.1
Minecraft running on Java 8 (OpenJDK version 1.8.0_232-solus)

This is the same for me:

CPU: Intel Core i5-8250U
GPU: Intel UHD Graphics 620
OS: Ubuntu 20.04 LTS
Java: OpenJDK 11.0.7

However, if I switch drivers and let the game render with my GeForce MX150, it works fine.

Same issue here:

CPU: Intel Core I5-6600

GPU: AMD rx-5700

OS: Arch Linux

Java: 1.8.0_252

Same issue but with fabulous graphics.

When set to fancy or fast graphics the clouds aren't visible at all through glass. (But thats the behaviour also in 1.15 if I'm not mistaken)

OS: Arch Linux x86_64
Kernel: 5.7.0-2-tkg-pds
Resolution: 1920x1080, 1920x1080
DE: Plasma
WM: KWin
CPU: AMD Ryzen 7 2700X (16) @ 3.700GHz
GPU: AMD ATI Radeon RX Vega 56 / MESA Stable 20.0.7
Memory: 32128MiB

Java openjdk 11.0.7

Seems to be the case with water as well, only applies to Stained Glass.

Fancy

Fabulous!

This does still happen on my end with pre 3

OS: Arch Linux x86_64
Kernel: 5.7.0-2-tkg-pds
Resolution: 1920x1080, 1920x1080
DE: Plasma
WM: KWin
CPU: AMD Ryzen 7 2700X (16) @ 3.700GHz
GPU: AMD ATI Radeon RX Vega 56 / MESA Stable 20.0.7
Memory: 32128MiB

Java openjdk 11.0.7

@unknown: Please open a new ticket - also make sure you can reproduce this with Java 8, Java 11 is not supported.

@Galaxy_2Alex @test226 I have opened a ticket for 1.16-pre3 running on Java 8: MC-188519

Just checked this out again in pre 3. The issue is still there. Both clouds and particles.

This is still happening to me in pre-5.

@Dawn: When enabling Fabulous, do you receive a warning?

I did get the warning. It mentions "Vendor detected: [X.Org]" and "OpenGL Version detected: [Mesa]". Here's my specs.

OS: Manjaro Linux x86_64

CPU: AMD Phenom II X4 955 (4) @ 3.200GHz

GPU: AMD ATI Radeon RX 550 640SP / RX 560/560X

DE: Xfce

WM: Xfwm4

Java: 1.8.0_242 64bit

Still exists in pre-6 for me. I have another computer using a Radeon RX 580 and it has no issues.

As pointed out by the warning when switching to Fabulous!, your gpu driver is not supported by this option.

Is there any explanation as to why it's not supported? What is it my gpu driver might be missing that is preventing elements from rendering in the correct order?

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.

Thank you so much! That makes sense I guess, and is unfortunate. I hope it gets figured out on either end eventually. I'll try your suggestion with proprietary vendor drivers and let you know what happens.

Hi, there is a open ticket at the mesa bug tracker:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/3144

Maybe if there is some spare time available for this issue, someone might take a look.

This appears to be a problem on your end.

Minecraft renders to six layers:

• Diffuse (framebuffer 2, color0: texture 6, depth: texture 7)

• ItemEntity (framebuffer 30, color0: texture 97, depth: texture 98)

• Translucent (framebuffer 29, color0: texture 95, depth: texture 96)

• Particles (framebuffer 31, color0: texture 99, depth: texture 100)

• Clouds (framebuffer 32, color0: texture 101, depth: texture 102)

• Weather (framebuffer 33, color0: texture 103, depth: texture 104)

However, when it comes time to blend these layers together, the samplers in the shader are as follows:

• DiffuseSampler: 6 (Diffuse layer color0)

• DiffuseDepthSampler: 7 (Diffuse layer depth)

• TranslucentSampler: 95 (Translucent layer color0)

• TranslucentDepthSampler: 82 ❓

• ItemEntitySampler: 97 (ItemEntity layer color0)

• ItemEntityDepthSampler: 84 ❓

• ParticlesSampler: 99 (Particles layer color0)

• ParticlesDepthSampler): 86 ❓

• CloudsSampler: 101 (Clouds layer color0)

• CloudsDepthSampler: 88 ❓

• WeatherSampler: 103 (Weather layer color0)

• WeatherDepthSampler: 90 ❓

Looking at the apitrace some more, it looks like you e.g. replace textures 81 and 82 with 95 and 96. I bet you're saving the new texture ID for TranslucentSampler but forgetting to save the new TranslucentDepthSampler texture ID at the same time.

3134239 glBindFramebuffer(target = GL_FRAMEBUFFER, framebuffer = 0)
3134240 glDeleteTextures(n = 1, textures = &82)
3134241 glDeleteTextures(n = 1, textures = &81)
3134242 glBindFramebuffer(target = GL_FRAMEBUFFER, framebuffer = 0)
3134243 glDeleteFramebuffers(n = 1, framebuffers = &22)
3134244 glGenFramebuffers(n = 1, framebuffers = &29)
3134245 glGenTextures(n = 1, textures = &95)
3134246 glGenTextures(n = 1, textures = &96)
3134247 glBindTexture(target = GL_TEXTURE_2D, texture = 96)
3134248 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_NEAREST)
3134249 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
3134250 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_CLAMP)
3134251 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_CLAMP)
3134252 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_COMPARE_MODE, param = GL_ZERO)
3134253 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_DEPTH_COMPONENT, width = 1280, height = 720, border = 0, format = GL_DEPTH_COMPONENT, type = GL_FLOAT, pixels = NULL)
3134254 glBindTexture(target = GL_TEXTURE_2D, texture = 95)
3134255 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_NEAREST)
3134256 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)
3134257 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_CLAMP)
3134258 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_CLAMP)
3134259 glBindTexture(target = GL_TEXTURE_2D, texture = 0)
3134260 glBindTexture(target = GL_TEXTURE_2D, texture = 95)
3134261 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA8, width = 1280, height = 720, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = NULL)
3134262 glBindFramebuffer(target = GL_FRAMEBUFFER, framebuffer = 29)
3134263 glFramebufferTexture2D(target = GL_FRAMEBUFFER, attachment = GL_COLOR_ATTACHMENT0, textarget = GL_TEXTURE_2D, texture = 95, level = 0)
3134264 glFramebufferTexture2D(target = GL_FRAMEBUFFER, attachment = GL_DEPTH_ATTACHMENT, textarget = GL_TEXTURE_2D, texture = 96, level = 0)
3134265 glCheckFramebufferStatus(target = GL_FRAMEBUFFER) = GL_FRAMEBUFFER_COMPLETE
3134266 glBindFramebuffer(target = GL_FRAMEBUFFER, framebuffer = 29)

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

OK, so your shader class has List<String> holding sampler names and a List<Object> which can either hold instances of your framebuffer class, instances of your texture class, or a boxed integer representing a raw OpenGL texture ID.

If the list entry is a framebuffer class instance, you use the instances's OpenGL color attachment ID member variable, if it is a texture class instance you use the instance's OpenGL texture ID member variable, and if it is an Integer object you use the integer directly.

When you're parsing the shader JSON, textures are inserted by boxed Integer ID (you don't seem to ever insert texture class instances even though this is technically supported), auxiliary color samplers are inserted as framebuffer class instances, and auxillary depth samplers are inserted by the boxed Integer ID of the framebuffer instance's depth attachment.

Your framebuffer class supports reinitialization where it deletes the OpenGL framebuffer object and the OpenGL texture objects and then creates new OpenGL textures and and new OpenGL framebuffer in-place. When this happens, though, it never gets communicated back to the shader class instance that has a reference to the framebuffer class instance. So because the shader class rereads the framebuffer class's color attachment ID every time it uploads the uniforms, the correct color texture is used, but since the depth texture ID is only read once when the JSON is originally parsed, it'll continue using the stale value from the original framebuffer class instance.

Presumably the framebuffer class only gets reinitialized on Mesa for some reason and never gets reinitialized on other platforms, which is why this appears to be a Mesa-only problem. Or maybe the other platforms immediately reuse the deleted textures IDs, and the stale depth texture ID happens to get reused as the new depth texture ID by pure luck.

Just a reminder that this is still happening in 1.16.1 with Mesa drivers.

@Dawn: The error message when selecting "Fabulous" makes it quite clear that right now, it is not supported yet for Mesa drivers. As you also can see above, the developers are looking into it for future releases.

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.

Thanks for the reply Felix Jones. I don't actually know much about code myself so I'm not sure how to describe it in a report. I can, however, make a new report with your suggested links and maybe others could add to it/edit it while it is being addressed? Which I'm very glad to hear it's being worked on. : ) That's the most I can do, but if it helps I'll go on and make the report. MC-192894