Bedrock Codebase: Shared textures and overlays [Tutorial]

I recently started looking in-depth into resourcepacks on the bedrock codebase version, which is windows 10, pocket edition and some console versions.

I made a quick resourcepack which uses a single texture for ores and applies an overlay which colours each ore differently, I also applied the same technique to wool.

oreswool

Firstly I recommend getting the default assets, which can be easily done with the resourcepack template although this template doesn’t include all the assets it contains enough to do this.

If you want to extract the default resources follow this tutorial on where windows apps are installed then go to Microsoft.MinecraftUWP…/data/resource_packs/vanilla

Change texture path

The main point of the resourcepack is that there is only one texture for multiple blocks with the same pattern, meaning that only one texture needs to be changed if you want to change the design of the blocks, this involves changing blocks to use the same texture instead of the separate texture by default.

This is done through the ‘terrain_texture.json’ located in the textures folder, inside the file look for a compound with the key “texture_data” changing the values inside this compound is how we can have several blocks use the exact same texture.
You only need to specify the blocks that you are changing inside the “texture_data” compound, I recommend removing all the blocks that you don’t change, like I did in my example.

Changing the texture is easy simply changing the “textures” value for the block ie

“gold_ore”: {
“textures”: “textures/blocks/ore_base”
},
“iron_ore”: {
“textures”: “textures/blocks/ore_base”
}

Coloured overlays

Adding a coloured overlay can be done to blocks in bedrock codebase again thorugh the ‘terrain_texture.json’, firstly you will need to change the “textures” value from a texture path to a compound containg the path with the key “path”:

“gold_ore”: {
“textures”: “textures/blocks/ore_base”
}

—– becomes —–

“gold_ore”: {
“textures”: {
“path”: “textures/blocks/ore_base”
}
}

Adding an overlay is done within this new compound added via the key “overlay_color” with the value being a hex value colour code ie “overlay_color”: “#fff056”

“gold_ore”: {
“textures”: {
“path”: “textures/blocks/ore_base”,
“overlay_color”: “#fff056”
}
}

Only tint certain parts of the texture

The final part of this example involves how to get certain parts of the texture not to be tinted, you can see this on the ore textures as the stone texture is not tinted, this is done through the use of a tga texture rather than the standard png texture.

The way that tga’s are used by the bedrock codebase is any part of the texture you don’t want to be tinted should have an alpha of 0, you will need to have the texture you want to not be tinted then set the alpha for the entire of that texture to 0 and the parts that need to be tinted will need an alpha of 255, you will need to save the texture as a tga not a png, you can’t just change the extension manually.

The stone texture has been reduced to 0 alpha which makes it invisible, but in game the stone is not tinted.

I have my example pack up for download you cansee what I did to help you learn how to do this, you can also see how I did the same for wool, as there is a slight difference in how wool is defined in ‘terrain_texture.json’.

Download the One Texture example pack

Bedrock Codebase: Shared textures and overlays [Tutorial]

Bow Texture Dependency

Recently I wrote an entire page dedicated to predicate values, within models.
Only after writing it did I discover an interesting oversight to do with bow models, which I posted on twitter.

In the video you can see the sword change material depending on the pull of the bow, wooden sword is shown when the bow is not being pulled, and a diamond sword will show when the bow is fully pulled back, this will affect the second bow anywhere in the hotbar, the offhand, or even when it’s on the player’s head.

So how did it work?

Firstly it uses two bows, the item in my offhand is another bow with a different damage value, the interesting thing comes from how the second bow had it’s predicates specified.

{ “predicate”: { “damage”: 0 }, “model”: “item/bow”},
{ “predicate”: { “damage”: 0, “pulling”: 1 }, “model”: “item/bow_pulling_0”},
{ “predicate”: { “damage”: 0, “pull”: 0.65, “pulling”: 1 }, “model”: “item/bow_pulling_1”},
{ “predicate”: { “damage”: 0, “pull”: 0.9, “pulling”: 1 }, “model”: “item/bow_pulling_2”},
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0 }, “model”: “item/wooden_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.333 }, “model”: “item/stone_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.667 }, “model”: “item/iron_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 1 }, “model”: “item/diamond_sword” },
{ “predicate”: { “damaged”: 1 }, “model”: “item/bow”},
{ “predicate”: { “damaged”: 1, “pulling”: 1 }, “model”: “item/bow_pulling_0”},
{ “predicate”: { “damaged”: 1, “pull”: 0.65, “pulling”: 1 }, “model”: “item/bow_pulling_1”},
{ “predicate”: { “damaged”: 1, “pull”: 0.9, “pulling”: 1 }, “model”: “item/bow_pulling_2”}

There’s a lot of predicates, so let’s break it down into smaller chunks.

{ “predicate”: { “damage”: 0 }, “model”: “item/bow”},
{ “predicate”: { “damage”: 0, “pulling”: 1 }, “model”: “item/bow_pulling_0”},
{ “predicate”: { “damage”: 0, “pull”: 0.65, “pulling”: 1 }, “model”: “item/bow_pulling_1”},
{ “predicate”: { “damage”: 0, “pull”: 0.9, “pulling”: 1 }, “model”: “item/bow_pulling_2”},

This is the default bow model, it’s been modified so that it will show when using a bow with 0 damage.

{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0 }, “model”: “item/wooden_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.333 }, “model”: “item/stone_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.667 }, “model”: “item/iron_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 1 }, “model”: “item/diamond_sword” },

This is the predicates used to display the swords, the thing to notice between these values and the previous values is the fact that “pulling”: 1 is not used. This is what causes the bow to animate when pulling another bow.
The “pull” predicate does not check whether the player is holding that specific bow in it’s hand, but “pulling” does, so specifying “pulling” will cause the bow only to animate if it is that bow that is being pulled.

The last 4 predicates are the same as the first 4 but are used when the bow is damaged ie when the bow is not unbreakable, so the default bow is used when the bow is not unbreakable.

Download this example resourcepack

This only affects bows and will not work with any other items, also the second bow is a bow itself, which could cause some problems if used as the player could potentially fire the second bow.

I have reported this behaviour to the bug tracker which thanks to another user has some code analysis, including a simple fix, which means this oversight will probably be fixed some time.

Although this means that you need to specify “pulling”: 1 for each override that is used when the bow is being pulled, if you want to have several bow models using different damage values, or you may run into this problem.

Bow Texture Dependency

Patterns in Minecraft’s “Random” Multipart Models

 

Multipart blockstates allow models to be “added together” into one block when certain blockstates occur. You can specify the same blockstate several times for multiple models to be “added” when one specific blockstate has a certain value.

{“multipart: [
{“apply”: {“model”: “model1”}},
{“apply”: {“model”: “model2”}}
]}

This file will always apply two models to the block no matter what. Multipart blockstates allow for several models to be supplied via an array, in this case one model will be chosen at random from the array.

“apply”: [
{“model”: “model1”},
{“model”: “model2”}
]

In this case model1 or model2 will be applied but not at the same time.

Combining both of these features together leads to some interesting behaviour.

This is a blockstate file with 16 models in each array, with 4 arrays total, the arrays are in the same order of colours and in the screenshot you can see that each tower will have the same colour for each step.
This shows us that although the blockstate file chooses a random model, the same array index is used each time for each array, rather than what might be expected to happen which is for a random colour for each step.

This file has 4 arrays but the 2nd, 3rd, and 4th arrays only contain 8 objects, rather than the first which contains 16.
You’ll notice that the top 3 steps are all the same colour but the bottom step is not, but it will still follow a pattern. The black bottom will have black steps on it, but so will the magenta bottom step. Magenta is the first colour missed of the 8 object arrays, so it can be seen that the array will wrap around back to the top of the array when there is less objects in one array than another, but only if the length of the array is a multiple of the length of the other.

 

These screenshots show a blockstate file with arrays containg 16, 8, 4, 2 objects and 15, 5, 3 objects, you should be able to spot the patterns here. Each colour step will only appear on top of a certain number of other coloured steps, you should also notice the exact same tower being made several times in each screenshot.

This final screenshot shows weighted values, you can see although some of the values have been weighted, patterns still emerge. The weighted values are picked more often, you may notice that the link between the top two steps and the bottom two steps has no pattern, meaning that weighting the values has broken some of the predictableness of the models.
It does not matter the order of the lists for the weighted values, they will always appear together, which suggests that the weighted values are pulled out of the array and then treated differently as the array models index will match up, ie the top two steps will be the same colour as long as only the weighted values are moved around the array.

random

Although there is predictable patterns that can be made with multipart blockstates, there is ways to disable them which involves either have the arrays not be the same size or multiples of each other, alternatively giving the values in the list different weights and different weights for the other arrays as well, will produce random model selection as viewed above.

Patterns in Minecraft’s “Random” Multipart Models

Making a Perfect Minecraft Hexadecagon

minecraftA hexadecagon is the closest you can get to a circle when block modelling in Minecraft, although it seems like a lot of patience, a perfect regular hexadecagon can be made in Minecraft very easily
with the use of block modelling programs.

I will talk through the maths that I did in order to work out the measurements for the hexadecagon, and will discuss how to use them for creating hexadecagons in your own models.1

Making this shape in Minecraft will require 8 elements (pictured on the right). I made the size of the sides of the hexadecagon 1. From here I can work out the other size for the elements.

2I have cut down what we’re looking at to explain what is going on better. To work out the interior angles of any regular polygon you can draw lines from corners to the centre of the shape to form isosceles triangles. This will give you n triangles, to work out the angle x which will be the same for all triangles formed in this way is to divide 360 by n, where is the number of sides of the polygon. x = 360/16  x = 22.5

As the triangles we have formed are isosceles the other 2 angles are the same. = (180 – 22.5)/2  y = 78.75

3

From here I used an online triangle calculator to calculate the length of the other 2 sides in the triangle. The length is 2.563. I then created a larger triangle which consisited of the length of the element, (which I was trying to find) and one side of two isosceles triangles which were opposite each other in the hexadecagon p.

p is double the length of an isosceles triangle p = 2.563 x 2  p = 5.126 I again used the triangle calculator to find the length of the element, which worked out at 5.028.
4

This means you can create a perfect hexadecagon in Minecraft by using 5.028 x 1 elements, but this is actually a ratio, meaning you can use elements that are 10.056 x 2 or 15.084 x 3  (this is the size I used for the cauldron). You can use any size element as long as both measurements are multiplied by the same value.

If you wish to make a hexadecagon, akkechi has made some tutorial videos about constructing this shape in cubik studio over on the cubik studio forum simply change the values to be a ratio of 5.028:1.

Making a Perfect Minecraft Hexadecagon

Changes to cobblestone walls

Why change cobblestone walls?
Currently cobblestone walls have a multi-part blockstate file for 5 blockstates: north, east, south, west, and up. Up is the blockstate that I will be talking about.

It is hardcoded into Minecraft for the up blockstate to be set to true under certain conditions: When a wall has no connections, one connection, two connections if they are 90° (ie north and east), three connections, four connections, and finally when a block is above the wall. This means that the blockstate for walls currently contains:

{ “when”: { “up”: “true” },
“apply”: { “model”: “cobblestone_wall_post” }
},

This means that the cobblestone post is applied when any of the above conditions are met.
This also means the only time a wall can actually detect when there is a block above it is when a wall has 2 connections at 180° (ie north and south) this is the only situation in which cobblestone walls won’t have the up blockstate as true. All these situations are shown below note the blockstates on the right of the pictures.

This currently means that you can’t use walls as a multi-part model for when a block is above it unless in very specific situations.
Walls are the only block in Minecraft which have an up blockstate but they can’t be utilised in maps or resourcepacks to create any block model which can change when another block is above it.

How could this be different?
As this is hardcoded into Minecraft we would have to change this, the up blockstate would need to only return true only when there is a block above a wall. The blockstate file would then need to be different:

{ “when”: { “OR”: [
{“north”: “false”, “east”: “false”, “south”: “false”, “west”: “false”},
{“north”: “true”, “east”: “true”, “south”: “true”, “west”: “true”},
{“north”: “true”, “south”: “false” },
{“south”: “true”, “north”: “false” },
{“east”: “true”, “west”: “false”},
{“west”: “true”, “east”: “false”},
{“up”: “true”}
]},
“apply”: { “model”: “cobblestone_wall_post” }
},

This rather long “when” statement should allow for the cobblestone post model to be applied to a cobblestone wall when any of the before mentioned situations occur.
The other “when” statements would need to be added to allow for cobblestone walls to seemingly connect to one another and this blockstate would allow for cobblestone walls to act exactly the same as they do now.

Cobblestone walls would look exactly the same they would also work the same, but they could be changed to the will of a map maker or resourcepack creator to create some rather more technical block models which could be affected by blocks above them.

Changes to cobblestone walls

Entity Modelling Workarounds

A few ideas have been floating around my head recently. With the current lack of entity modelling in the java version of Minecraft, I have been thinking about basic workarounds for this problem.


Mobs – certain mobs will be easier than others, but the general gist is to texture parts of the mob invisible (head and arms will be easiest to replace) and giving the mob models in it’s hands or on it’s head which are then rendered as the mobs arms or head.

Chests – trapped chest will work best as you can detect whether it is open based on the redstone signal output. Placing an entity on top of the chest with the model  be rendered on the entity ie placed in the entity’s head, using the redstone output to allow for a different model to be rendered when the chest is opened.

Boats – with the ability to have two passengers in a boat, one of them could be an entity with a model renedered on it, with the other being a player this would allow for such things as small airships which the player can actually fly.

Entity Modelling Workarounds

What is this?

This post mainly exists to give a little more info on my website.

Well I have finally started to post on my site, I have begun one of hopefully many topics on the more technical side of block modelling in Minecraft. I hope a few people learn something and apply what they know in the future to hopefully enhance and optimise their own block models.

What is this?