Bug Description

In the base game when rendering leaves for fast graphics, the colour information from transparent pixels are discarded causing the transparent regions in the leaves to turn black. When sodium is installed this doesn't seem to happen, which causes leaves to appear slightly different.

The change is most noticeable if you have mods which add their own leaves, as any painted out regions of the textures are made fully opaque making the trees look more solid than intended.

With sodium + Iris (Note: Left=Modded, Right=Vanilla):

With sodium (no Iris):

Without sodium:

Versions used:
Minecraft: 1.20.1
Sodium: mc1.20.1-0.5.8
Indium: 1.0.30+mc1.20.4
Iris: 1.6.17+1.20.1

Reproduction Steps

• Install sodium
• Load world
• Observe trees

Log File

n/a

Crash Report

n/a

Sodium includes a pack from “Vanilla Tweaks” which replaces the black parts with colored parts to fix a mipmapping issue with an optimization.

The problem is that some image editors delete the color values for fully transparent pixels, leaving behind full-black color values. When the mip-maps are generated for these textures, they sample from the black areas, and it produces texture data that is too dark. This results in some textures (such as the sides of grass blocks) fading to black when viewed at extreme angles, which is very distracting and causes all kinds of other problems for shader packs.

(Additional context: MC-114265)

Sodium detects this situation and attempts to re-compute a "reasonable" value for the purposes of mip-mapping, which avoids the aforementioned bug, but causes leaf blocks in particular to render in a different way. We had to provide replacement textures for these blocks, since they actually want darker rendering, and the energy-correct function we use is not appropriate for that purpose.

Ultimately, it's just that mod authors need to make sure their textures are created properly, by providing a color value in fully transparent areas (even if this value is very near black) so that the inner portion renders darker in Fast graphics mode. This will mean, regardless of Sodium being present, that you a) don't have broken mip-maps, and b) have full control over how the textures render, regardless of the block being on an opaque or cutout render pass.

The problem is that some image editors delete the color values for fully transparent pixels, leaving behind full-black color values. When the mip-maps are generated for these textures, they sample from the black areas, and it produces texture data that is too dark. This results in some textures (such as the sides of grass blocks) fading to black when viewed at extreme angles, which is very distracting and causes all kinds of other problems for shader packs.

(Additional context: MC-114265)

Sodium detects this situation and attempts to re-compute a "reasonable" value for the purposes of mip-mapping, which avoids the aforementioned bug, but causes leaf blocks in particular to render in a different way. We had to provide replacement textures for these blocks, since they actually want darker rendering, and the energy-correct function we use is not appropriate for that purpose.

Ultimately, it's just that mod authors need to make sure their textures are created properly, by providing a color value in fully transparent areas (even if this value is very near black) so that the inner portion renders darker in Fast graphics mode. This will mean, regardless of Sodium being present, that you a) don't have broken mip-maps, and b) have full control over how the textures render, regardless of the block being on an opaque or cutout render pass.

I still don't understand why this shouldn't be considered a bug. If you look at the vanilla blocks they're still different, even with your custom textures "fix".

Also what is going to happen when players have custom resource packs that change leaf textures? You surely can't assume everyone is going to know about this.

"Oh sodium renders leaves different so you have to make your leaves in a special way" sounds like a workaround rather than a solution - I had planned to do that already before reporting anyway.

The fact that Sodium has to replace leaf textures with its own and the issue is still evident tells me that this is something Sodium probably shouldn't be doing in the first place.

I still don't understand why this shouldn't be considered a bug...

I'm not saying there isn't a "bug" here, just that we are not going to fix it, because that would mean regressing other things which we care about more.

If you look at the vanilla blocks they're still different, even with your custom textures "fix".

We asked users for their input and this was overwhelmingly preferred. It's not exact to what Minecraft does, but that exact parity is not a design goal of Sodium, and arguably the existing behavior is completely broken.

There are many other changes in regards to the lighting and coloring of blocks that we make to simplify our implementation & provide better visual fidelity. This is just another one of those things.

Also what is going to happen when players have custom resource packs that change leaf textures? You surely can't assume everyone is going to know about this.

Unfortunately, they will have to modify their textures so that they contain color values in the transparent areas. Resource pack authors should probably be doing this anyways, so that their textures don't cause artifacting when used with mip-mapping in Vanilla. The best we can do is try to document this on our wiki so that the information is easily found.

The fact that Sodium has to replace leaf textures with its own and the issue is still evident tells me that this is something Sodium probably shouldn't be doing in the first place.

Sodium is not purely a rendering optimization mod. It's an alternative renderer (which happens to be much faster) and it occasionally does things differently as a result (albeit in a way that mods can still easily accommodate, such as by editing their textures here.)

I still don't understand why this shouldn't be considered a bug...

I'm not saying there isn't a "bug" here, just that we are not going to fix it, because that would mean regressing other things which we care about more.

If you look at the vanilla blocks they're still different, even with your custom textures "fix".

We asked users for their input and this was overwhelmingly preferred. It's not exact to what Minecraft does, but that exact parity is not a design goal of Sodium, and arguably the existing behavior is completely broken.

There are many other changes in regards to the lighting and coloring of blocks that we make to simplify our implementation & provide better visual fidelity. This is just another one of those things.

Also what is going to happen when players have custom resource packs that change leaf textures? You surely can't assume everyone is going to know about this.

Unfortunately, they will have to modify their textures so that they contain color values in the transparent areas. Resource pack authors should probably be doing this anyways, so that their textures don't cause artifacting when used with mip-mapping in Vanilla. The best we can do is try to document this on our wiki so that the information is easily found.

The fact that Sodium has to replace leaf textures with its own and the issue is still evident tells me that this is something Sodium probably shouldn't be doing in the first place.

Sodium is not purely a rendering optimization mod. It's an alternative renderer (which happens to be much faster) and it occasionally does things differently as a result (albeit in a way that mods can still easily accommodate, such as by editing their textures here.)

Hmm. Okay!

Reasonably explained. Thanks, and sorry for the inconvenience. I hope you have a lovely day.