Not sure exactly how the new fancy and fabulous graphics are intended to work, but when set to fabulous on my system the clouds render behind normal solid blocks and particles do not seem to be behind the stained glass. The clouds do not seem to be tinted by the glass color either, telling me they are above it in rendering order.
Linked issues
is cloned by 2
is duplicated by 7
MC-187554
Clouds render over everything else.
Resolved
MC-187654
Translucent Blocks drawn in front of particles when looking through another translucent block on Fabulous! graphics
Resolved
MC-188029
Smoke Particles can't be seen behind glass
Resolved
MC-188056
In Fabulous graphics on Linux, stuff is rendering in the wrong order
Resolved
MC-188060
Rain cannot be seen through stained glass panes
Resolved
relates to 6
MC-186538
Clouds, transparent entities, and particles render behind water when looking through transparent blocks
Open
MC-187568
Entity hitboxes render in front of them when graphics setting is set to fabulous for some users
Resolved
MC-187817
Clouds are not visible through colored glass on fancy
Resolved
MC-188203
Can't see water, transparent blocks, entities, and tile entities through lightning
Resolved
MC-192894
Transparency layers lose their auxiliary depth buffer ID when resized
Resolved
Attachments
Comments 26
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 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
[media]
Fabulous!
[media]
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.
@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
Felix Jones
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)