End crystals render incorrectly sometimes with Complementary and Euphoria Patches since Sodium 0.6.0-beta.3
djmrFunnyMan opened this issue ยท 16 comments
Bug Description
Sodium had a weird regression which causes the voxelized end crystal effect from Euphoria Patches to jitter a lot.
I know sodium's the cause because I compared on the same minecraft & iris version so the only difference was sodium.
The issue first appears in Sodium 0.6.0 Beta 3 more specifically in this commit 3fd78d9
Video:
https://github.com/user-attachments/assets/36ad60ce-f938-4462-940d-18803f08e059
Reproduction Steps
- Download Complementary R5.3 and Euphoria Patcher 1.4.3
- In the shader import these settings:
ComplementaryUnbound_r5.3 + EuphoriaPatches_1.4.1.txt - Create a world with seed -1632576596065209744
- Use command
/execute in minecraft:the_end run tp @s -31.54 107.00 -0.43 292.05 32.40
Log File
Crash Report
Does this reproduce with the latest release of sodium?
Yes it persists in all versions since beta 3. If it was already fixed I wouldn't report it.
It was not clear whether this is still an issue given that your logs use outdated versions. Thank you for clarifying.
Per the changelog of Sodium 0.6.0-beta.3:
Improved compatibility with some resource packs that use custom shaders in entity rendering.
This probably has something to do with the regression. But we'd need a bisect to know for sure. The relevant commits are:
the issue first appears in commit 3fd78d9
It's probably a shader bug
I guess since the order has changed to match Minecraft Vanilla, the shaders haven't been updated.
Both gri and I don't really understand this issue, unfortunately. Quote from gri "so I don't think I understand what's going on much better than you" :p
I only know that according to Acer aka @djmrFunnyMan it worked before this commit
I don't know what is causing the issue here, as the commit the bug was bisected to looks correct to me, and hasn't caused regressions elsewhere.
IMS, Jelly and the shader devs all dazed by this issue. Hmmm
Perhaps there's some iris code that relied on the old order? (iris issue after all?)
Btw can I get a latest build but with this commit reverted? Just to be double sure its the cause
Btw can I get a latest build but with this commit reverted?
The commits can be reverted cleanly on trunk. You can checkout the code and run the following commands:
$ git revert adad380b98cd768e84572676ce6ae1a589f2657f
$ git revert 3fd78d94d6672813b613173900c880768b1656d2
$ gradle build
Considering there is nothing in the shader-side code that relied on specific vertex ordering I think it's most likely this is an Iris issue where some code in Iris hasn't been updated to work correctly with the vanilla vertex order.
Which will probably be an tremendous pain to find.
Unless an Iris side fix is found, would reverting these commits be on the table? Or is core shader support higher priority?
The patches are not going to be reverted. They are fixing problems that are more severe than what you have demonstrated.
If someone knows what is causing the problem and can submit a patch to resolve this bug, and it doesn't re-introduce the problems the original patches were fixing, then we will accept that.
