Custom item models that use dye tinting will fail to render their tinted faces in certain conditions. Based on my testing, it happens when:
The item has no "dyed_color" component.
The item is not a placeable block.
The "default" color set in the item definition is a positive number.
The attached resource pack contains a simple item model that displays this. It consists of an upper cube that's tinted and a lower cube that isn't.
How to reproduce:
Install the provided resource pack
Run
/give @s white_wool[item_model="test:test"]This renders correctly.
Run
/give @s stick[item_model="test:test"]This does NOT render correctly (only the bottom cube is visible)
Run
/give @s stick[item_model="test:test",minecraft:dyed_color=4208181]This renders correctly, even though the defined color is exactly the same as the default on the item definition.
Lastly: If you open up the resource pack and go to "assets/test/items/test.json" and change the default color to be any negative number, everything renders as it should with no issues.
Code analysis
The net.minecraft.client.color.item.Firework#calculate and net.minecraft.client.color.item.Dye#calculate use this.defaultColor without wrapping it in ARGB.opqaque.
Linked issues
is duplicated by 2
Attachments
Comments 4
Does the tint source default always check for alpha?
It seems weird that tint source defaults have an alpha check while all fieds that can provide the color (dyed_color, custom_model_data, map_color, potion_contents, firework_explosion, team color, and grass color(map)) don't have that ability.
I took another look to check the other tint sources. All the other ones all explicitly ignore alpha before passing their color to the renderer. DyeTintSource is the only one that doesn't do that.
Okay so, looking at the code via Loom: It looks like what's happening here is that the top two bytes are read as an alpha, and the calculator I was using to convert hex colors to Minecraft's decimal color format didn't account for this.
The reason it works via the "dyed_color" item component is because that component is hard-coded to set the top two bytes to 0xFF (equivalent to subtracting -12,569,035) specifically to avoid this happening. Changing the default dye color in the above pack to -12569035 fixes the issue while using the exact same color.
Fix would probably be for the dye tint source to apply the same byte-change to its value as well, since there's no way to get a transparent color from applying dye anyway.