What happened?

When using Iris 1.1.4 with Sildur's Vibrant Shaders 1.32, the block breaking animation is lit incorrectly when the block being broken is near a light source.

This behaviour does not occur when using OptiFine.

To reproduce, simply place a light source near a block and start breaking it in Survival mode (an example is included below in the screenshots).

Screenshots

Expected behaviour from OptiFine+OptiFabric 1.18.1 HD U H4, Minecraft 1.18.1:

Incorrect behaviour from Iris 1.1.4, Minecraft 1.18.1 (also occurs on 1.17.1 and 1.16.5):

The testing environment:

Minecraft Version

Minecraft 1.18.1, 1.17.1, and 1.16.5

Iris Version

1.1.4

Sodium Version

0.4.0-alpha5+build.9

Operating System

Windows 10

What is your GPU?

NVIDIA GeForce RTX 2060

Java Version

Java 17

Depending on the shaderpack that you're using, some contain gbuffers_damagedblock files and some don't. It just depends on the author, but this does affect if broken block lines are affected by light or not. I don't think this is an issue with IRIS, most likely the shaderpack.

Yeah, there's no gbuffers_damagedblock VSH/FSH anywhere in Sildur's Vibrant.

I suppose that this discrepancy in behaviour between Iris and OptiFine is considered to be not a bug / a won't-fix, then?

I'd still say it's a bug, because IRIS is looking for "Optifine Parity" and it's a difference in behavior. However, I can't speak to how quickly or how high priority it is: if the shaderpack does have the gbuffers_damagedblock, Optifine and IRIS should render exactly the same. Without the file, it's the shaderpack author letting the shader mod decide.

The shaderpack that I'm working on is very loosely based on Sildur's Enhanced Default and DOESN'T have a gbuffers_damagedblock file, so I'll make the testing environment and I'll let you know if the visual difference in block breaking is just a sildur's thing or an IRIS thing.

Testing Environment:

Block breaking result:

Long story short: Seems to be a specific issue to Sildur's Vibrant Shaders.
Solutions: You could check out writing your own shader so you could add the damagedblock file. Or you could get a different shader. Or avoid having lights around blocks that you're breaking. Basically, this is just up to Sildur to fix in the shader. If you're looking for something similar to Sildur's Vibrant, GravityShade is a really lightweight option that has decent lighting and reflections that's being updated pretty frequently.

Interesting, I guess it's a bug on Sildur's end, then.

Does having no gbuffers_damagedblock result in undefined behaviour, then? (In other words — does this only happen to work correctly on OptiFine?)

Regardless, this issue is so minor that I don't really mind it (definitely not enough to warrant switching away from Sildur's Vibrant), — I just wanted to report the issue to (potentially) help make Iris better / help it reach further parity with OptiFine ;P

According to the Optifine Documentation, another gbuffers file will take over in this order: terrain, texturedlit, textured. My best guess is that the math that Sildur uses for lighting calculations just gets a little weird with opacity. Sorry that there's not more help I can give, I could whip up some default damagedblock files just to patch it but it's not my place to mess with Sildur's work. I'd say just update IRIS to 1.2 and play with the settings to see if something changes.

Just out of curiosity, which version of Sildur's Vibrant are you using?

No worries, you don't have to do that ;P

My best guess is that the math that Sildur uses for lighting calculations just gets a little weird with opacity.

Interesting guess, especially given issue #509 which is yet another OptiFine/Iris discrepancy (this time involving what seems to be some kind of floating-point precision discrepancy…?) that leads to small visual issues in Sildur's Vibrant.

Just out of curiosity, which version of Sildur's Vibrant are you using?

1.32 Extreme, but with a custom shaders.settings that changes a bunch of settings to match what I use on OptiFine.

(I have verified that this issue still occurs even with an unmodified copy.)

It's possible that this is caused by either or both of these issues:

• #773
• #1106

Iris doesn't currently initialize some vertex attributes for the block breaking animation / entity / block entity rendering, and when vertex attributes aren't initialized they get filled with undefined values. It would make sense because the terrain program in Sildur's Vibrant makes use of a number of vertex attributes that are not used in its other programs.

Discovered some weird undocumented behavior of OptiFine that could be related. If the shader pack does not provide a gbuffers_damagedblock program, then block breaking animations are rendered with depth writes disabled and as if the current shader program specified /* DRAWBUFFERS:0 */ instead of whatever drawbuffers it is currently using.