What happened?

When using any kind of shader pack while playing on a server using a resource pack to implement custom armour, will the displayed armour look broken and as if the textures got misaligned or something.

From own testing, and through additional information by @LoneDev6 does it seem to happen with pretty much any shader and could be related to overriding the rendertype_armor_cutout_no_cull shader, even while it is present in the server's resource pack.

Additional information, including possible reproduction steps, can be found in the following issue: sp614x/optifine#6391

Screenshots

How the armour should look like:

How it actually looks like with shaders enabled:

Relevant log output

Don't see any relevant log entries worth mentioning here.

Iris and Minecraft Version

iris-mc1.17-1.1.3.jar for MC 1.17.1

Are you running Sodium along with Iris?

Yes

Operating System

Windows 10

What is your GPU?

NVIDIA GeForce GTX 1060

Java Version

16.0.1 (64 Bit)

Additional context

I reported this to the dev of the server plugin that allows custom items, armour, etc. through generating a resource pack and he mentioned that this needs a fix on your end, as the same also happens on OptiFine's end too.

Vanilla core shaders can not work with an Iris/OF shaderpack enabled, they have to be disabled for shaders to work properly

This is not feasible to fix on our end without hardcoding specific fixes and patches for every single server that abuses core shaders to do custom things.

This is the result of Iris not overriding the terrain shader and letting the vanilla one apply:

Similar issues apply to entities. Hopefully, you can see that this isn't a workable solution. The problem is, shader packs expect specific data to be written by shader programs, but core shaders have no knowledge of that.

You are right that there might be a way to fix this. But in computer science, some problems have no general solution. Which means, we'd have to look at every possible variant of these core shaders and manually hardcode a patch for each and every override used by server owners and resource packs. Since there are infinite possible overrides, we'll never actually solve this problem, and will just be wasting our time playing whack-a-mole.

As a result, we've decided to not support this, because doing so with the way that Mojang has laid out core shaders is infeasible.

Also, do note Mojang does not officially support replacing core shaders either, even though it currently works:

Shaders are now included for all supported render states. Any shader except for the blit shader can also be replaced in resource packs. For now replacing these shaders is not officially supported and the way it works may change in the future.

https://www.minecraft.net/en-us/article/minecraft-snapshot-21w10a

There is surely a way to fix this, maybe a complicated way that needs to rewrite parts of the game rendering engine, but this is still an Iris and also Optifine problem.

We sadly cannot accept your answer:

This is not feasible to fix on our end without hardcoding specific fixes and patches for every single server that abuses core shaders to do custom things.

This is a vanilla resourcepacks FEATURE not an hack nor it can be considered "abusing".
Mojang gave us access to shaders via vanilla resourcepacks so we can do whatever we want with them.

We are supposed to use shaders like this. Let's say I make a vanilla shader to make all armors red or a shader to show a wireframe view of the world, they would be valid shaders and not an abuse of the feature, but still it won't surely work with Iris nor Optifine because you override the shaders completely.

So I think this must considered a bug/limitation and you should consider to try to find a solution to support vanilla resourcepacks shaders feature (Mc 1.17+).

Thanks for your time

@coderbot16 Interesting, so basically the Optifine/Iris shaders format is very different from the Vanilla one, also orders of params is different I think? So the pipeline fucks up?

The only solution I currently have in mind would be to recode the custom armors shaders as Optifine/Iris shader and ask the player load them from the client configuration, would work right?

A GPU cannot run more than one shader at the same time, that is a hardware limitation. What you are asking is practically on AI levels of modifying 2 shaders and combining them.

What?
I'm not asking to run more than one shader, where did I say that?

The mod should check each loaded resourcepack to know which shaders they are implementing and stop overriding these particular shaders, then let the game load them from the resourcepack.

Which is basically what the game is already doing with the builtin shaders.

This would lead to the optifine shader not running and visual glitches taking place, due to optifine shaders assuming it’s being ran correctly.

This would lead to the optifine shader not running and visual glitches taking place, due to optifine shaders assuming it’s being ran correctly.

This statement has nothing to do with my previous messages

You can't just use two shaderpacks at the same time

Shaders in both the optifine and iris format assuming everything is running properly, "disabling the part of the shader that the resource pack is using" is not feasible, and would break many shaders.

As coderbot said, shaders would have to be patched on a case by case basis to properly handle core shaders running along with iris shaders, which is not feasible.

It does. OptiFine shaders use composite passes, and the majority of shaders assume the rest of the shader… actually works during the composite pass. If it doesn’t, things usually end up miscolored, misshapen, or even outright invisible.

Well, that wouldn't really work. The main issue is that every shader pack has their own shader programs that the pack expects to be loaded, and often custom effects are implemented in these programs, such as reflections / PBR / etc. If Iris were to let resource packs such as yours override shader pack armor shaders, at a minimum these effects would break on armor because the shader pack's shader program implementing them isn't running. But often a more spectacular form of breakage is that shader packs change how colors are written in order to pass more data to fullscreen passes later on.

On a fundamental level, there is no general solution to this problem. Iris hardcoding detections for these shaders and implementing workarounds is not an acceptable solution because it places a significant maintenance burden on us to keep on adding more hardcoded patches for every single thing people use core shaders for. Therefore, we won't do that.

The only way for resource packs to be fully compatible with complex shader packs is to not touch core shaders at all. Whether that implies removing custom armor usage or creating new formats for resource packs to more sanely provide custom armors remains to be seen. As is, we will not be working on this issue for the forseeable future. That being said, this project is open source - PRs that seek to improve the situation around custom armor and similar things are welcome.

I think the only solution would be to rely on Optifine custom armors and use them as a fallback in case the user has shaders installed.

So if the user has Optifine it would directly load the custom armors without using the custom shader.

Thanks for the clarification and many compliments for your very complex project.

That would work, it might work with Iris too assuming there's a mod that supports the custom armor format. If not then maybe someone should make a mod for that.

You're welcome, glad to clarify things. I've spent some time over the past few days writing a proper document explaining these things to avoid confusion in the future, and hope to have it completed soon.

@coderbot16 thanks a lot!
I think it would be good to also add a little info here in these public docs, since it's were people look to know how game shaders work.
https://docs.google.com/document/d/18AhcnAI55liax72yh70njUomIzezOKshCurfdZPTKwM
https://docs.google.com/document/d/15TOAOVLgSNEoHGzpNlkez5cryH3hFF3awXL5Py81EMk

Closed by adding documentation on why this is unfixable.