Sodium

embeddedt/embeddium#110

Sodium+Fabric API:

2023-11-21.20-13-33.mp4

Fabric API:

https://cdn.discordapp.com/attachments/394433849251332096/1176601861537669160/2023-11-21_20-14-51.mp4

2023-11-21.20-17-25.mp4

Note: No github template was used, because I don't know if it's a bug or a feature request.

The fix is in 1.20.5-rc1

Fixed in 1.20.5

The problem is caused by how we apply transformations to the packed normal data of each vertex. In vanilla, these transformations happen before the values are compressed/truncated. But with Sodium, we apply the transformations to the already truncated values, which means there is very little precision left at that point (only 8 bits per component). This is why the behavior you are seeing is so unstable.

I don't see an easy way to fix this without radically altering how the VertexBufferWriter works. We would have to move the encoding step to the very end (before it's written into a buffer), and have it only consume full-precision normals. This would break any other mods relying on Sodium's interface, and it would probably come with a performance penalty.

The issue might be that Fabric API's mixin does not take effect on Sodium's call to Direction.getFacing here:

sodium-fabric/src/main/java/me/jellysquid/mods/sodium/mixin/core/render/immediate/consumer/OverlayVertexConsumerMixin.java

Line 88 in 0ae058b

    
           Direction direction = Direction.getFacing(transformedNormal.x(), transformedNormal.y(), transformedNormal.z());

If that is the case, the best solution is probably for Sodium to ship its own version of the fix (suitably optimized, since Fabric still uses the dot product rather than comparing magnitudes).

EDIT: The cause is more nuanced than this, as replacing the getFacing call with Fabric's implementation manually does not fix the issue.

fixed in 24w05a
https://bugs.mojang.com/browse/MC-193656

Share to