Bug Description

WaterColorProvider class does not refer to water fluid FluidRenderHandler registered via Fabric fluid API as it should.
This makes it so registering any of those render handlers for water does not override vanilla colors making it hard to modify it.

Reproduction Steps

tested in dev environment. Vanilla FluidRenderHandler is never called for water while it is called for lava

Log File

no log needed.

Crash Report

no crash occurred

The problem is that Sodium registers its own custom color provider for water so that it can make use of smooth blending (something which Fabric API does not support.)

But it's hard to detect whether a mod is overriding the default fluid handler... Fabric API returns a registry entry regardless of it being the default or provided by another mod. So we don't know when it's the default implementation.

I guess we need to ask Fabric to either expose FluidRenderHandlerRegistryImpl#getOverride or to provide some way for us to obtain the default implementation for comparison purposes.

I don't want to depend on internal details of Fabric API (as those are not stable), so I've opened a pull request here to expose the necessary function to public code.

I see. related to that would it be possible to register other color BlenderColorProviders directly to sodium to benefit from better blending?

Sodium does not expose a public interface for doing that. The registrations are handled internally. We need to work out those details. If you really wanted to, look at an example like GrassColorProvider<T> (which pulls the color directly out of the grass color map for each vertex) and register it in ColorProviderRegistry.installOverrides() via mixin.

Though, again, I don't recommend doing that until we have a stable way to interact with it.

alright, I'll wait for a proper api then

Blocked on upstream changes; pulling it out of the milestone.

The related PR was merged in Fabric API, and has been published with version 0.96.0.