tutorial:biomecoloring
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Last revisionBoth sides next revision | ||
tutorial:biomecoloring [2019/05/28 18:43] – mapping changes draylar | tutorial:biomecoloring [2019/10/25 17:41] – rework page draylar | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | In this tutorial, we'll look at adding | + | Ever wonder how grass and leaves change hues depending on the biome, |
- | Remember to keep visual-related logic client-side, (// | + | === Existing Examples === |
+ | First, what existing vanilla content uses color providers? A few examples include: | ||
+ | * grass | ||
+ | * leaves | ||
+ | * leather armor dying | ||
+ | * redstone wire | ||
+ | * plants such as melons, sugarcane, and lilypads | ||
+ | * tipped arrows | ||
+ | The color provider is powerful, but Mojang has opted to stick with individual textures for colored blocks such as concrete, wool, and glass. The primary use case at this point is for biome shaded blocks and small tweaks to existing textures, such as the colored end of a tipped arrow. | ||
+ | |||
+ | The concept behind color providers is simple. You register a block or item to them, and when the block or item's model is rendered, the color provider applies a hue tweak to each layer of the texture. Both providers give you access to the layer of the model, which means you can hue each portion of a model separately, which is the case in leather armor & tipped arrows. This is useful for when you only want to change a few pixels, but not the entire texture. | ||
+ | |||
+ | Remember that the color provider is a client-side mechanic. Make sure to put any code related to it inside a client initializer. | ||
+ | |||
+ | ==== Registering a Block Color Provider ==== | ||
+ | To register a block to the block color provider, you'll need to use Fabric' | ||
<code java [enable_line_numbers=" | <code java [enable_line_numbers=" | ||
- | public class ExampleModClient implements ClientModInitializer { | + | ColorProviderRegistry.BLOCK.register(new BlockColorProvider() { |
- | @Override | + | |
- | public void onInitializeClient() { | + | public int getColor(BlockState state, ExtendedBlockView world, BlockPos |
- | | + | return 0x3495eb; |
- | | + | } |
- | | + | }, MY_BLOCK); |
- | }, YOUR_BLOCK_INSTANCE); | + | |
- | } | + | |
- | } | + | |
</ | </ | ||
- | So, what's happening here? The register method wants a color returned, and in this case, that color is taken from the grass block. Coloring an item is very similar. Like blocks, | + | All we do here is say, "Hi, '' |
- | < | + | The model is also important: the main note here is that you are // |
- | public class ExampleModClient implements ClientModInitializer | + | < |
- | | + | { |
- | | + | " |
- | | + | " |
- | // These values are represented as temperature and humidity, and used as coordinates for the color map | + | |
- | | + | " |
- | | + | }, |
- | | + | " |
- | }, YOUR_ITEM_INSTANCE); | + | { " |
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | | ||
+ | " | ||
+ | } | ||
} | } | ||
+ | ] | ||
} | } | ||
</ | </ | ||
+ | In this instance, we're adding a single tintindex, which is what would appear in the `layer` parameter (layer 0). | ||
+ | |||
+ | Here's the final result-- note that the original model used the '' | ||
+ | {{https:// | ||
+ | |||
+ | |||
- | Finished! |