Views
Actions
Difference between revisions of "Tinted Textures"
Ferri Arnus (talk | contribs) |
(Update to 1.17) |
||
Line 1: | Line 1: | ||
− | Many blocks and items in vanilla change their texture color depending on where they are, such as grass. Models support specifying “tint indices” on faces, which are integers that can then be handled by <code> | + | Many blocks and items in vanilla change their texture color depending on where they are, such as grass. Models support specifying “tint indices” on faces, which are integers that can then be handled by <code>BlockColor</code>s and <code>IItemColor</code>s. See the wiki for information on how tint indices are defined in vanilla models. |
− | === | + | === BlockColor / ItemColor === |
− | Both of these are single-method interfaces. <code> | + | Both of these are single-method interfaces. <code>BlockColor</code> takes a <code>BlockState</code>, a (<code>nullable</code>) <code>BlockAndTintGetter</code>, and a (<code>nullable</code>) <code>BlockPos</code>. <code>ItemColor</code> takes an <code>ItemStack</code>. Both of them take a parameter <code>tintIndex</code>, which is the tint index of the face being colored. Both of them return an <code>int</code>, a color multiplier. This int is treated as four unsigned bytes, alpha, red, green, and blue, in that order, from most significant byte to least. For each pixel in the tinted face, the value of each color channel is <code><nowiki>(int)((float)base * multiplier / 255)</nowiki></code>, where <code>base</code> is the original value for the channel, and <code>multiplier</code> is the associated byte from the color multiplier. Note that blocks do not use the alpha channel. For example, the grass texture, untinted, looks white and gray. The <code>BlockColor</code> and <code>ItemColor</code> for grass return color multipliers with low red and blue components, but high alpha and green components, (at least in warm biomes) so when the multiplication is performed, the green is brought out and the red/blue diminished. |
If an item inherits from the <code><nowiki>builtin/generated</nowiki></code> model, each layer (“layer0”, “layer1”, etc.) has a tint index corresponding to its layer index. For blocks, the “particle” layer is index 0. | If an item inherits from the <code><nowiki>builtin/generated</nowiki></code> model, each layer (“layer0”, “layer1”, etc.) has a tint index corresponding to its layer index. For blocks, the “particle” layer is index 0. | ||
=== Creating Color Handlers === | === Creating Color Handlers === | ||
− | <code> | + | <code>BlockColor</code>s need to be registered to the <code>BlockColors</code> instance of the game. <code>BlockColors</code> can be acquired through <code>ColorHandlerEvent$Block</code>, and an <code>BlockColor</code> can be registered by <code><nowiki>BlockColors#register</nowiki></code>. Note that this does not cause the <code>BlockItem</code> for the given block to be colored. <code>BlockItem</code> are items and need to colored with an <code>ItemColor</code>. |
<syntaxhighlight lang="java"> | <syntaxhighlight lang="java"> | ||
public void registerBlockColors(ColorHandlerEvent.Block event){ | public void registerBlockColors(ColorHandlerEvent.Block event){ | ||
− | event.getBlockColors().register( | + | event.getBlockColors().register(myBlockColor, coloredBlock1, coloredBlock2, ...); |
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | <code> | + | <code>ItemColor</code>s need to be registered to the <code>ItemColors</code> instance of the game. <code>ItemColors</code> can be acquired through <code><nowiki>ColorHandlerEvent$Item</nowiki></code>, and an <code>ItemColor</code> can be registered by <code><nowiki>ItemColors#register</nowiki></code>. This method is overloaded to also take <code>Block</code>s, which simply registers the color handler for the item <code><nowiki>Block#asItem</nowiki></code> (i.e. the block’s <code>BlockItem</code>). |
<syntaxhighlight lang="java"> | <syntaxhighlight lang="java"> | ||
public void registerItemColors(ColorHandlerEvent.Item event){ | public void registerItemColors(ColorHandlerEvent.Item event){ | ||
− | event.getItemColors().register( | + | event.getItemColors().register(myItemColor, coloredItem1, coloredItem2, ...); |
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
This registration must be done client-side, in the initialization phase. | This registration must be done client-side, in the initialization phase. |
Revision as of 17:51, 2 August 2021
Many blocks and items in vanilla change their texture color depending on where they are, such as grass. Models support specifying “tint indices” on faces, which are integers that can then be handled by BlockColor
s and IItemColor
s. See the wiki for information on how tint indices are defined in vanilla models.
BlockColor / ItemColor
Both of these are single-method interfaces. BlockColor
takes a BlockState
, a (nullable
) BlockAndTintGetter
, and a (nullable
) BlockPos
. ItemColor
takes an ItemStack
. Both of them take a parameter tintIndex
, which is the tint index of the face being colored. Both of them return an int
, a color multiplier. This int is treated as four unsigned bytes, alpha, red, green, and blue, in that order, from most significant byte to least. For each pixel in the tinted face, the value of each color channel is (int)((float)base * multiplier / 255)
, where base
is the original value for the channel, and multiplier
is the associated byte from the color multiplier. Note that blocks do not use the alpha channel. For example, the grass texture, untinted, looks white and gray. The BlockColor
and ItemColor
for grass return color multipliers with low red and blue components, but high alpha and green components, (at least in warm biomes) so when the multiplication is performed, the green is brought out and the red/blue diminished.
If an item inherits from the builtin/generated
model, each layer (“layer0”, “layer1”, etc.) has a tint index corresponding to its layer index. For blocks, the “particle” layer is index 0.
Creating Color Handlers
BlockColor
s need to be registered to the BlockColors
instance of the game. BlockColors
can be acquired through ColorHandlerEvent$Block
, and an BlockColor
can be registered by BlockColors#register
. Note that this does not cause the BlockItem
for the given block to be colored. BlockItem
are items and need to colored with an ItemColor
.
public void registerBlockColors(ColorHandlerEvent.Block event){ event.getBlockColors().register(myBlockColor, coloredBlock1, coloredBlock2, ...); }
ItemColor
s need to be registered to the ItemColors
instance of the game. ItemColors
can be acquired through ColorHandlerEvent$Item
, and an ItemColor
can be registered by ItemColors#register
. This method is overloaded to also take Block
s, which simply registers the color handler for the item Block#asItem
(i.e. the block’s BlockItem
).
public void registerItemColors(ColorHandlerEvent.Item event){ event.getItemColors().register(myItemColor, coloredItem1, coloredItem2, ...); }
This registration must be done client-side, in the initialization phase.