Certain chunks disappearing and reappearing at certain angles, persists in Sodium MC 1.17.1.
DTM06 opened this issue · 14 comments
Version information
mc1.17.1-0.3.2+build.7, mc1.16.3-0.1.0
Expected Behavior
Taken in Vanilla 1.17.1. As seen in the GIF, chunks persist no matter what angle the player is facing.
Vanilla F3 Debug Menu :
Actual Behavior
Taken in Sodium 1.17.1 (0.3.2+build.7). As seen in the GIF, chunks seem to disappear at certain angles. These are the same two scenes, one in the overworld, one in the nether. I've seen this in many other instances, but only selected these two scenes in order to present this issue, Excuse the low resolution GIF, this was necessary in order to meet GitHub upload size requirements.
Sodium F3 Debug Menu :
Reproduction Steps
As I am uncertain of the specific circumstances in which this issue occurs, I have provided a world download of one of the scenes seen in the above GIFs. I've tried playing around in my video settings to no avail, however I have still provided my usual settings for maximum accuracy.
- Mirror my exact video settings as seen in the following screenshots (taken in mc1.17.1-0.3.2+build.7) : https://imgur.com/a/DqGyBrl
- Download the following world file (1.17, but is backwards compatible with 1.16) :
Debug.zip - Read the lectern at world spawn, then right-click the button in front of you.
If all goes to plan, you should be seeing something similar to what I have described.
Java version
1.17.1 : Java 16.0.1 64-bit (Bundled), 1.16.5 : Java 1.8.0_51 64-bit (Bundled)
CPU
Intel Core i5-10400F
GPU
Radeon RX 5600 XT, Driver ver. 21.8.2
Additional information
I am not running any mods apart from Sodium MC.
This issue can be seen in both versions of Sodium that I have tested, those being mc1.17.1-0.3.2+build.7 and mc1.16.3-0.1.0.
This is not a Fabric issue. Running Fabric loader ver. 0.11.6 with an empty mods folder produces the same results as Vanilla.
Higher resolution footage : https://streamable.com/cbhl8b
I've been able to recreate this on a friend's PC, proving that this issue is not isolated to my computer.
going to dump some of the stuff I've noted down in the dev channel on discord.
Orebfuscator4 can cause this behaviour too as it will replace blocks that sodium interprets as real blocks and hits this edge case.
I noticed two different issues. to actually reproduce these is near impossible given mods and plugins will have an effect on it, i did a bit of searching while i could (don't anymore as the obfuscator cache got reset) one seems to be from isCulledByFrustum giving the min value an offset of at least -8f seemed to solve the issue were a whole line of chunks stop rendering, but i do not know exactly why that fixes it and if that just causes issues elsewhere
the other issue that seems to be what causes the single chunk to get culled is something with the VisibilityData/OcclusionData id assume processing as when I used the vanilla data it didn't change anything.
this was present upto the lastest version on the experiments branch
Edit: this seems to be somewhat reproducible if you use the seed -4608201675609978617 & orebfuscator4 on a spigot server -1091 88 -280 and look straight down with fov quake pro.
This is still an issue right now. Is there an estimate as to when this will be fixed yet?
I analyzed the code recently and found out where the issue is. To make it understandable, I wrote an issue analysis. Hope the issue can be fixed soon.
This issue does not commonly occur, but it is also not rare indeed. I believe it has annoyed a lot of players (just see how many duplicates there are in the issue tracker), since it's quite game-breaking and cannot be easily avoided. I know the bugged code is confusing, and you (the authors of Sodium) cannot easily find out the bug, but it's your responsibilities to care for the players' experience by making temporary workarounds. It is long known that the bug is related to Occlusion Culling, so one of the workarounds could be an option for disabling Occlusion Culling, and it is fairly easy to implement, isn't it? However, what you did is to leave the issue open, waiting for God to tell you the way to fix, and leaving millions of players waiting for a fix or a workaround patch which never really comes (until I made a bugfix mod for that). It's a little ridiculous and disappointing. Maybe that's the reason why Sodium (and its accessories) hasn't yet thrown OptiFine into the dustbin of history.
As I know, there has also been another long-standing issue, related to translucency, which affected lots of Minecraft players who major in building. It has been stale for years, and has probably been forgotten. I hope that you could remember that and do something to fix it. Also, I hope you could attach importance to "small" bugs in the future. Only in this way can Sodium and the modern Minecraft modding ecosystem be better and better.
@yezhiyi9670 We have not forgotten about any of these bugs. Maybe you haven't seen, but there has been significant activity the past few weeks to rewrite the algorithm for chunk culling, and maybe tens of thousands of messages on our Discord server. In fact, there are three separate branches. We even tried writing an approach that used software rasterization for occlusion culling, for pixel-perfect results.
so one of the workarounds could be an option for disabling Occlusion Culling
What is the point of having a performance mod if you disable one of the most critical optimizations? Seriously. We very clearly indicate this is alpha software, and we don't say anywhere that it is "better than OptiFine" or otherwise push for it to be used. That's the community's own doing, and do you know what the community does... ? Contribute almost nothing, and then tell us how we don't care about the players or our mod.
Do you have any idea how many of these "why isn't this fixed" problems could be trivially solved if someone offered their time to help, and simply wrote a message asking for pointers? But very rarely does anyone do that.
As I know, there has also been another long-standing issue, related to translucency
This issue is not as simple as you think. We tried to fix it with an implementation of the Weighted Blended OIT (see #519) but players hated the appearance of it.
We then tried to implement a software-based fallback (sorting vertices on the CPU, like what vanilla does), but ran into significant performance issues due to the way Sodium is built.
Then, we worked with others to implement a compute-shader based approach (#1687, though there were other drafts), but we haven't figured out how to actually make that work, and especially not how to deal with the fact that it relies on Compute Shaders and therefore breaks macOS compatibility.
We've also looked into Moment-Based OIT, the most promising technique, but again the problem of needing more than OpenGL 3.3 comes up.
Anyways. That is a really long winded way to say that, yes, of course we are aware of these issues, and we throw a lot of time into solving them!
But rather than opening a pull request and describing the solution you've come up with, you decide to antagonize us on an issue tracker, say we don't care, and make no attempt to actually cooperate. As is the vicious cycle that we face with much of this community. Always demanding that we do better but never actually offering the time and energy needed to make that happen.
Sigh.
We also have a draft PR for fixing this issue in the short term which can be found here. It's slated to be rolled up into the next release once we fix some other issues.
Sorry, I haven't taken a look of the development progress before coming to a conclusion. Now I understand having limited time and energy and can see the efforts you make for solving those long-standing issues and making Sodiun and Minecraft even more amazing.
I've always been an independent developer and an issue reporter. Maybe it's time for me to learn to contribute via pull requests now.
Some players may have no choice but to use Sodium due to performance issues or Vanilla bugs. Maybe this is where the so-said "responsibility" come from.
Players in the community are constantly complaining and saying that the mod authors don't shoulder the full responsibility. Maybe that's because they don't know much about code or contribution, nor the normal workflow of a collabrative Minecraft project, and they just want a explanation about why something can't be fixed for a long time. For example, for the translucency issue, many players including me may wonder why Sodium can't just implement it in the way Vanilla did.
We then tried to implement a software-based fallback (sorting vertices on the CPU, like what vanilla does), but ran into significant performance issues due to the way Sodium is built.
And this could be a proper explanation. If this is broadcasted in some way, for example, on the mod download page, instead of being hidden deeply in issue trackers or pull request workflows, most players may come to accept it and stop complaining in Discords or issue trackers.
As for the Occlusion Culling issue, what I want to say is that sometimes done is more than perfection. Occlusion Culling is indeed an important optimization, but the impact of disabling it may not be as bad as expected (it's still at least better than Vanilla in many common cases, as I and my fellow players tested). Simply giving players an option (stated as a temporary fix) to disable this bugged optimization, to me, is still better than leaving players struggling between poor performance and a bugged experience.
Merging this into tracking issue #1898.