Add order-independent transparency for translucent blocks #519
Conversation
The algorithm used is "Weighted, Blended Order-Independent Transparency"[1], which allows for a fast and simple implementation at a small cost to color accuracy. This should solve all issues of translucent faces not rendering behind others, such as with water behind stained glass or with blocks containing translucent faces, such as slime and honey blocks. More testing is required to confirm compatibility with limited OpenGL 2.0 implementations, such as those of macOS or older iGPUs, as well as to determine the impact on performance. Fixes #38 [1]: https://casual-effects.blogspot.com/2015/03/implemented-weighted-blended-order.html
|
Any luck with turning up the opacity of honey/slime blocks? |
|
transparency blending isn't correct,every layer seem to have the same factor, and we cant clearly see depth |
|
There is the following defect with culling the back-face of the 'targeted block' wire mesh: what we are looking at is a tower of white stained glass (6 tall), over white concrete. The first block is targeted, hence has the selected block wire-mesh around it rendered:
Otherwise the improvement in correctness is impressive. I have found that water-bubble columns in stained glass (as found in bubblevators) work properly, and, unlike reported earlier, layered multiplicative blending does work properly for me. |
|
Test setup for transparency blending:
Slime blocks in front of honey blocks behind stained glass work properly (although again blending appears to be different than vanilla, could again be explained by a difference in the blending operator). |
|
The bug where multiple layers of stained glass are not rendered correctly across chunk boundaries is also fixed. In prior versions of sodium, looking through multiple horizontal layers of glass (separated by 1 air layer inbetween), when looking from the bottom (looking towards the sky) would render only one layer for blocks outside the current chunk. This is now rendering correctly. Overall, the improvement in correctness is MASSIVE. Performance drop is negligible with a 256px resource pack. It is more substantial with 16px textures. |
|
|
|
This is a vanilla issue that will not be fixed by this PR. Whether Sodium should fix it is a separate issue. As for the blending issues, I'm aware of them and will work on a fix after I've fixed OpenGL 2.0 support (which is basically only used on macOS). However, this may take a while as I have a lot going on irl right now. |
Does turning on Fabulous graphics fix this? |
No. |
|
Subchunk boundary issue in current Sodium (vk suggested that I upload it here):
|
|
reported here:#38 (comment) |
|
Resource packs without transparency on normally transparent blocks have some faces visible threw them.
|
Are you using this PR, or a sodium release (or sodium-0.1.1 as provided by JellySquid in Nov?). Asking because in my tests this bug was present in prior versions, but is fixed with this PR. |
I said "current Sodium," didn't I? That means the latest release. As your tests confirmed already. Anyway, I don't know whether the PR solves the issue or not as I have not tested it but I'm assuming there might be issues regarding it since vktec said that it was new information that I should upload here so he does not forget about it. He probably wants to at least review the issue. |
|
Ah, I had thought you were observing this behaviour with this PR |
Thanks, this is useful information. I expect it's because those blocks use translucent rendering despite not actually being translucent, meaning they get blended. |
|
Also water bubbles seem to have issues with rendering. |
jellysquid3
force-pushed
the
1.16.x/next
branch
from
12886a1
to
5545895
Compare
|
Do you plan on rebasing this on the current sodium-next, to resolve the merge conflicts? |
|
any luck with this? |
I have merged this PR on top of PR #581 (Indium/LBG patch), on top of build 352 |
|
Updated on top of build 359 |
|
Closing as abandoned. The author (vktec) has talked about not having the time available to continue updating this PR, and many changes have occurred in Sodium since which break this. Furthermore, while WBOIT is a (very fast) approximate function for OIT, it has significant trouble with mostly opaque/translucent surfaces, something which many users reported resulted in major graphical downgrades. Given that the original paper doesn't really acknowledge this outside of saying "don't do it", it's safe to say that this is just an issue with the algorithm and not something we can really correct for. There are other OIT functions such as Moment-based OIT (MBOIT), which appear very promising, offering both decent performance (at least relative to sorting all translucent geometry on the CPU) and good rendering quality even in the cases Minecraft often sees. We may at some point want to investigate these options instead. |
The algorithm used is "Weighted, Blended Order-Independent Transparency", which allows for a fast and simple implementation at a small cost to color accuracy. This should solve all issues of translucent faces not rendering behind others, such as with water behind stained glass or with blocks containing translucent faces, such as slime and honey blocks.
More testing is required to confirm compatibility with limited OpenGL 2.0 implementations, such as those of macOS or older iGPUs, as well as to determine the impact on performance. This PR should not be merged until this testing has been done and any issues addressed.
Fixes #38