Block Models [1.8]

The way that Minecraft renders blocks has changed significantly for 1.8.  Previously, the shape of blocks was defined in the java code.  This meant that (for example) a BlockTorch would always have the same shape, and only the textures could be changed.  Minecraft now uses model files to define both the shape and the texture.

To skip straight to some sample code, see here.

The rendering code uses an IBakedModel to tell it how to render a block.  The Model(s) for a given Block are specified using two types of JSONfiles:

1-BlockStates file

Each block has a corresponding BlockStates configuration file located in
assets/minecraft/blockstates, for vanilla blocks, or
{resources}/assets/yourmodid/blockstates for your mod.
By default, the filename is the block name- for your custom blocks this will be the name you provided to GameRegistry.registerBlock().  

The BlockStates configuration file has entries showing where to find the model for each state of the block, for example for the torch:

File: blockstates/torch.json

{

    "variants": {

        "facing=up": { "model": "normal_torch" },

        "facing=east": { "model": "normal_torch_wall" },

        "facing=south": { "model": "normal_torch_wall", "y": 90 },

        "facing=west": { "model": "normal_torch_wall", "y": 180 },

        "facing=north": { "model": "normal_torch_wall", "y": 270 }

    }

}

In this case the torch uses one of two model files- “normal_torch” or “normal_torch_wall”, depending on which way it is facing.  For custom blocks you should use

 “model”: “yourmodid:modelfilename”

Useful vanilla examples to look at include blockstates/cobblestone, bed, and dark_oak_log.
NB - by default, minecraft looks for a blockstates file with a filename that matches your block name.  You can customise this if you want - for example, a different blockstates file for different block variants, or ignoring one of the properties in your IBlockState.  See here for more information.

2-Model file

The appropriate model file, located in
assets\minecraft\models\block\ for vanilla blocks, or
{resources}\assets\yourmodid\models\block for your mod models,
is then used to provide the instructions for rendering the block in its current state.  

This link does an excellent job of describing the format of the block model files.

Useful vanilla examples include models/block/stone, acacia_log, bed_foot.

Some clarifications of some of the key points:

The model consists of a number of rectangular faces (quads), based on cuboid “elements”.  Each quad is defined in two steps:

1. A cuboid is defined by specifying the 3D coordinates of two opposite corners, “from” [x,y,z] and “to” [x,y,z].  A full cube such as a block of stone uses [0,0,0] to [16,16,16] - so for example [8,8,8] is the centre of the block.
2. One or more quads are then defined from the faces of that cuboid – for example, in half_slab.json shown below, the faces are defined using the cuboid from [0, 0, 0] to [16, 8, 16], i.e. a slice 8/16 units high.

This is repeated for all the cuboid “elements” in the model - most models only have one cuboid element, but there can be many - for example the stairs has two - the bottom half slab and the quarter cube "step" on top.

The stairs model is made up of two cuboid "elements"

Each quad is covered with a texture.  The UV coordinates correspond to the texture specified for the quad, in the order [u1, v1, u2, v2] – where [0 – 16, 0 - 16] corresponds to the full texture [width, height].  In the example from half_slab.json below, the down and up faces both use the full texture, but the other faces (east, west, north, south) use only half the texture.  Note that the v coordinate in texture [u,v] coordinates is “upside down”, i.e. [0,0] is the top left corner, not the bottom left corner as you might expect.  So in the example below, the half slab extends from y=0 to y=8, and the texture corresponding to this range is v=8 to v=16.  

Excerpt from models/block/half_slab.json:

"elements": [

  { "from": [ 0, 0, 0 ],

    "to": [ 16, 8, 16 ],

    "faces": {

      "down": {"uv": [ 0, 0, 16, 16 ], "texture": "#bottom", "cullface": "down" },

      "up":   {"uv": [ 0, 0, 16, 16 ], "texture": "#top" },

      "north":{"uv": [ 0, 8, 16, 16 ], "texture": "#side",   "cullface": "north" },

      "south":{"uv": [ 0, 8, 16, 16 ], "texture": "#side",   "cullface": "south" },

      "west": {"uv": [ 0, 8, 16, 16 ], "texture": "#side",   "cullface": "west" },

      "east": {"uv": [ 0, 8, 16, 16 ], "texture": "#side",   "cullface": "east" }

    }

  }

]

Half_slab model

The order of the coordinates is important; if you flip them around, for example [16, 0, 0, 16] instead of [0, 0, 16, 16], then the texture will be flipped left-right.   Quads are only visible from one side - for example, the east face is invisible if you are standing behind it, i.e. looking towards it from the west.
The “texture” field in elements must be a variable texture such as “#mytexture”, and you must define “mytexture” in one of your “textures”: fields.  You can’t use the texture directly, for example the model file below will give you a missing texture on the down face.

Modified excerpt from models/block/half_slab.json:

"elements": [

  { "from": [ 0, 0, 0 ],

    "to": [ 16, 8, 16 ],

    "faces": {

      "down": {"uv": [ 0, 0, 16, 16 ], 

               "texture": "blocks/half_slab_texture",

               "cullface": "down" },

// the down face texture will not work! 

For further explanation of quads and texturing used in Block Models, see here.

Some further notes

The faces sometimes specify a value for cullface.  These are handled slightly differently to non-cullface quads:

1.  Cullface quads might not be rendered, depending on the adjacent block; minecraft will call Block.shouldSideBeRendered() to see whether it should render this face or not.  For example, BlockGlass overrides shouldSideBeRendered(), and returns false if the adjacent block is also a glass block - see the picture below.
   The “cullface” value specifies which direction it points in.  In contrast, non-cullface quads are always rendered.
2. Cullface quads use lighting brightness (ie sky light and block light) taken from adjacent blocks – for example the east face of the block being rendered at [x,y,z] takes its lighting brightness from the block at [x+1, y, z] i.e. located one position to the east.  In contrast, non-cullface quads use lighting brightness from the block being rendered.

BlockGlass.shouldSideBeRendered(): left = vanilla code; right = overridden to always return true

• The “ambientocclusion” flag turns on/off ambient occlusion when rendering this block.  Ambient occlusion is a way to improve the appearance of lighting and shadows, see here for more information.  Generally speaking, ambient occlusion is suitable for full blocks, but not for small or complicated shapes such as a torch or grass.
• The “tintindex” flag is used for faces which get a colour from Block.colorMultiplier() to modify the rendering colour – for example used by grass to change to a brownish colour in drier biomes, or by redstone wire to change the wire brightness according to the power level.  See here for further explanation.
• The “shade” flag is used to control lighting.  If false, it turns off the direction-dependent face brightness (i.e. the up face is drawn brighter than the down face).  See here for some background info on lighting.
• The “particle” texture is the 2D representation of the block, used for (eg) the flying block particles when the block is broken, or the view if the player is inside the block.
• Vanilla has a set of “built in” blocks for which it doesn’t look for models, such as BlockAir, BlockChest, BlockStaticLiquid, defined in BlockModelShapes.registerAllBlocks().  It also does an awful lot of messing around in BlockModelShapes.registerAllBlocks() to define which properties of each block affect the rendering.  This doesn't appear to be necessary for Forge-registered blocks.