Bug Description

I'm a developer for a custom block mod that involves registration of custom biome color handlers using the net.minecraft.client.color.block.BlockColors::register method. The custom biome handlers implement both the net.minecraft.client.color.block.BlockColor functional interface (with method getColor(BlockState state, BlockAndTintGetter world, BlockPos pos, int tintindex)) and the net.minecraft.world.level.ColorResolver functional interface (with method getColor(Biome biome, double x, double z)). I'm not entirely sure if the latter is considered deprecated, but it seems like only the BlockColor interface is used in the vanilla rendering pipeline to calculate biome color -- this allows for the handler to be made conditional on the tintindex values defined in the block's model.

I'm working on a block where multiple colormaps are used for different faces -- using tintindex: 0, tintindex: 1, etc. in the model definition along with a custom handler that accesses the corresponding color buffer. An image of how this looks with a simple demo block without Embeddium is shown below.

However, Embeddium overrides the vanilla rendering pipeline and appears to use the ColorResolver interface for determining biome color instead, which prevents the use of multiple tintindex values in the custom color handler. As a result, my test block is no longer rendering correctly. An image of the same block with Embeddium is shown below. The same colormap is used for all sides regardless of tintindex.

Is it possible to switch this version of Embeddium to use the getColor method from the BlockColor interface to be consistent with vanilla's implementation?

Reproduction Steps

I'm playing on Minecraft 1.18.2 with Forge 40.2.14. I'm using embeddium-0.3.18+mc1.18 and testing with this development version of my modpack (source code here; see latest commit). The test block in question is westerosblocks:test_multi_colormap.

Log File

The following is a stack trace that I've printed from within the getColor(Biome biome, double x, double z) method:

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]/com.westeroscraft.westerosblocks.WesterosBlockDef$CustomColorMultHandler.m_130045_(WesterosBlockDef.java:613)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.world.biome.BiomeColorCache.updateColorBuffers(BiomeColorCache.java:90)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.world.biome.BiomeColorCache.getColor(BiomeColorCache.java:63)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.world.WorldSlice.m_6171_(WorldSlice.java:294)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/org.embeddedt.embeddium.render.world.WorldSliceLocal.m_6171_(Unknown Source)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]/com.westeroscraft.westerosblocks.WesterosBlockDef$CustomColorMultHandler.getColor(WesterosBlockDef.java:592)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]/com.westeroscraft.westerosblocks.WesterosBlockDef.lambda$registerVanillaBlockColorHandler$8(WesterosBlockDef.java:1310)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.model.quad.blender.FlatColorBlender.getColors(FlatColorBlender.java:18)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.model.quad.blender.ConfigurableColorBlender.getColors(ConfigurableColorBlender.java:33)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.render.pipeline.BlockRenderer.renderQuad(BlockRenderer.java:179)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.render.pipeline.BlockRenderer.renderQuadList(BlockRenderer.java:165)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.render.pipeline.BlockRenderer.renderModel(BlockRenderer.java:124)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.render.chunk.tasks.ChunkRenderRebuildTask.performBuild(ChunkRenderRebuildTask.java:132)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.render.chunk.compile.ChunkBuilder.processJob(ChunkBuilder.java:325)

[20:31:52] [Chunk Render Task Executor #6/INFO]: TRANSFORMER/[email protected]+mc1.18.2/me.jellysquid.mods.sodium.client.render.chunk.compile.ChunkBuilder$WorkerRunnable.run(ChunkBuilder.java:369)

Actually, looking at the stack trace, it appears Embeddium does call the correct getColor overload. The problem is that you do an explicit check for the BlockAndTintGetter being RenderChunkRegion (this assumption will not hold with custom renderers like Embeddium, or possibly even another content mod's block rendering) and if it's not that, you fall back to calling world.getBlockTint here.

FWIW, it's not really thread-safe to access the client level from these color handlers since they are not being run on the client thread during chunk meshing. That said, vanilla doesn't provide a proper thread-safe biome getter on BlockAndTintGetter, so you might have no choice but to fall back to Minecraft.getInstance().level if you need biomes here and the getter is not a RenderChunkRegion.

I'm not maintaining 1.18.2 anymore due to it not seeing much use compared to newer versions at this point. Block color provider handling is much different in the 1.20.1 version, and it's likely your issue is already fixed by those changes. If you are not able to update, I'd suggest just writing a mixin for Embeddium 1.18.2 that fixes the behavior on your block(s).

Ah, that's too bad. But thanks for the quick reply. Any pointers for where to get started on a mixin for Embeddium?

That makes a lot of sense. I'll experiment with the BlockAndTintGetter check to see if I can add a fallback for custom renderers, in that case. I really appreciate you looking into it further.

EDIT: Looks like the fallback you suggested worked! Thanks again.