Is your feature request related to a problem? Please describe.
Sodium causes issues with vanilla core shaders which some resource packs use.

Describe the solution you'd like
A fix I thought of that would probably work best is having sodium read a new custom resource pack file such as "sodium.json" that would be in the root folder so resource packs can use it to toggle features in sodium that break core shaders or etc. That way core shader resource packs could be compatible with sodium users.

Describe alternatives you've considered
Other things I've considered is having the configuration in pack.mcmeta or disable breaking features if the mod detects a resource pack with core shaders in it is applied.

Sodium will likely never support core shaders. As IMS (Iris dev) puts it, It's a great idea done very wrong by Mojang. I know you can do some cool things with them, but you really shouldn't use them. There's a good reason why both Iris and OptiFine completely disallow them.

Core shaders should be seen as implementation and not API.
The shader APIs are called Iris or canvas (or anything else that's upcoming at one point or the other).

Even Mojang mentioned discouraging the use of core shaders iirc.

They mention that in changelog articles, "experimental feature, may change in the future, no support" etc

For reference, I found that the changelog article where this is mentioned is the one for 21w10a, a Minecraft 1.17 snapshot released on 2021:

To me, this Mojang statement about core shader replacement not being supported reads very much like an attempt to reduce backwards compatibility expectations, not that resource pack authors should be discouraged from replacing them, or that doing so would cause unstability. I think it's similar to how e.g. the 1.20.6 experimental preview changes for 1.21 are technically not supported either, even though they work fine and people can totally use them.

Replacing core shaders has increasingly become an important part of the experience of custom vanilla servers and, while it's understandable that they are so tied to the rendering pipeline implementation that supporting them in Sodium is a hard problem, I find the overall tone of "you really shouldn't use them" naive: there is no better way to achieve some effects, but servers demand them, and replacing core shaders works just fine most of the time anyway, so there is no hard reason to not use them. After all, if they were such an internal implementation detail that shall never be touched, why would Mojang even bother making core shaders replaceable in resource packs? It'd be less effort for them to just hardcode shaders in the source.

Would it be welcome to mention this nuance on what Mojang did exactly say on pages like https://github.com/CaffeineMC/sodium-fabric/wiki/Resource-Packs? Besides the fact that such a statement is not "very clear" to me about whether resource pack authors should actually replace core shaders, it was also made in 2021, so it's fair to say it may no longer reflect their actual views on the topic.

There is no issue with the wiki's text and it will not be changed. The facts as it describes are fully accurate. The shader interface is unsupported and unstable, per the direct quote you made. We do not provide any interpretation of those facts, other than it being the case that many effects (disabling fog, changing render layers, etc) can be done via other platform mods while maintaining compatibility with Sodium.

The reality is that, even if we wanted to make core shaders work, any effect you can achieve by manipulating core shaders is going to be significantly slower and more prone to breakage than even the most trivial implementation of a Fabric mod. And since a lot of resource packs copy the default shader files from Minecraft without even modifying them, it would end up being the case that Sodium would just disable itself anytime you joined a multiplayer server, which is not exactly helpful.

So obviously, the conveyed tone in the article is there for a reason. We don't like them, we can't do anything about them, and their usage is antithetical to the point of a user installing an optimization mod.

After all, if they were such an internal implementation detail that shall never be touched, why would Mojang even bother making core shaders replaceable in resource packs? It'd be less effort for them to just hardcode shaders in the source.

And to answer this, no, it wouldn't be. Hardcoding shader strings in source means that you lose shader hot-reload support, which makes development significantly harder (as you'd have to restart the game any time you modify a shader.) The reason it likely uses the resource pack system is just because that system already handles hot-reload, and implementing a new elaborate system on top of resource packs to prevent people from modifying shaders would likely a) not be well received, and b) end up being too much work for minimal gain.

In other words, I understand why people want to modify core shaders, but we are at an impasse here where it is impossible for us to fix anything, and it is impossible for server owners to implement content in any less terrible manner.

Why not make sodium's shaders modifiable by resource packs? Like implementing this mod into Sodium itself.

The shaders are intentionally protected in Sodium from resource packs modifying them, because they have no stable interface, and messing things up there generally causes a GPU hang and/or game crash. If a player joins a server and their graphics driver crashes because the replacement shader is subtly out of date and/or invalid, then users are going to file bugs with us instead of the resource pack author.

Even if that weren't a problem, supporting a system (shader replacement) to implement functionality that really shouldn't be done in shader code, for the sake of "well at least it's familiar", is not a design that I want to be responsible for maintaining, as a volunteer for free software.

The solution people need to look towards is a modding ecosystem where server-provided content can be installed, without needing shader replacement in the first place. And that's just not in scope for our mod.

Implementing a mod like "sodium shader support" into sodium itself is the point of this issue, which is closed as not planned, and that mod in particular has been mentioned in this issue already. You can read the response to that above.

There is no issue with the wiki's text and it will not be changed. The facts as it describes are fully accurate. The shader interface is unsupported and unstable, per the direct quote you made.

But the direct quote I showed says nothing explicit about the stability of replacing these shaders, for example. The only relevant things it says are vague statements about core shader replacement being "not officially supported" (but issues about core shaders were still fixed in the bug tracker?) and that "the way it works may change in the future" (when will that future come?). Mojang did not explicitly discourage the replacement of core shaders, or said that they "are not meant to be modified", unlike the Resource Packs wiki page of this repo.

So obviously, the conveyed tone in the article is there for a reason. We don't like them, we can't do anything about them, and their usage is antithetical to the point of a user installing an optimization mod.

It's fair enough you don't like them, and as a fellow developer who had its fair share of issues with shader support I can sympathize, but replacing core shaders does not necessarily affect performance negatively. You said that many people just copy and paste the vanilla core shaders in their packs, for example. How can replacing the default core shaders with an identical copy of themselves cause performance problems?

And to answer this, no, it wouldn't be. Hardcoding shader strings in source means that you lose shader hot-reload support, which makes development significantly harder (as you'd have to restart the game any time you modify a shader.) The reason it likely uses the resource pack system is just because that system already handles hot-reload, and implementing a new elaborate system on top of resource packs to prevent people from modifying shaders would likely a) not be well received, and b) end up being too much work for minimal gain.

I'm not affiliated with Mojang so of course your guess as to why that was not done is as good as mine here, but it doesn't sound too complex to put a constant boolean property somewhere to ignore loading core shaders from external resource packs for release builds. That way you would get the development experience benefits without coming up with a shader resource loading system, while you'd still prevent this kind of pain down the road from happening.

There is no need for an extended discussion on this, because the conclusion of that discussion has no relevant bearing on whether core shaders are ever supported, or what the text of the wiki page will say.

Even Mojang mentioned discouraging the use of core shaders iirc.

Can you send me the source for that please? Not trying to contradict you but I'm curious where you got that information from.

Can you send me the source for that please?
I'm curious where you got that information from.

They mention that in changelog articles, "experimental feature, may change in the future, no support" etc

However, there is still a way to make vanilla shaders compatible using Sodium Shader Support. Compatibility must be provided by the developer of the resource pack.

It's a great idea done very wrong by Mojang. I know you can do some cool things with them, but you really shouldn't use them.

This is a really lousy reason. I understand that this is an open source, non-profit project, and it is your right to implement what you want, but I also think you should consider why somebody would want to use core shaders "even if they're really bad". But even if you disagree with my use case, and you think everything I'm about to say is stupid, I hope you also understand that you can't possibly understand everybody's wants or use case, and being told that you just "shouldn't use that feature, it sucks" can be really frustrating and unhelpful (this is honestly something I think a lot of people need to hear).

I'm here because I made an experimental Minecraft server that adds custom content and changes parts of the gameplay to match Beta 1.7.3, and obviously part of that is removing the xp/hunger bar*. On that note, I've watched people struggle to download mods on their computer (yes, as recently as 2023, and no it's not always their fault), and I've watched people finally get mods on their computer only for the game to crash for some reason. So it is preferable to use the features built in to Minecraft that people with a vanilla client can use, then to ask the user to install a mod. And don't tell me "everyone has Optifine lol", this is an unproven statistic and as I just said, there are still people in 2023 who can't get mods. And even if it is true, it's hard to rely on OptiFine's feature set when the same features might not be in this mod.

*(Yes, I could work around all this by making parts of the HUD invisible in the resource pack, but then there's a weird gap in the HUD, which sucks, so honestly it's scenario where I lose either way).

Nobody dismissed your use-case. They said there were technical limitations which makes it difficult (well, borderline impossible) for other mods to support. It's not that we don't want to support core shaders, it's that there is no good way to support a resource pack which is modifying internal details of a completely different renderer. The constructs that people expect in vanilla's "core shaders" simply do not exist in Sodium's renderer -- they work in completely different ways.

The initial impression I got from the first message was a dismissal of any use case for core shaders, and none of the other messages in the thread mention this being impossible like you said (although that's what I figured before reading this). It's good to hear that this isn't the official reason.