Using Vanilla Block Models in Custom Blocks

Bedrock Edition handles block rendering through two distinct pipelines depending on how your block is configured. If you define your block's visuals inside the resource pack's blocks.json file using the blockshape field, the game routes your block through the legacy terrain rendering pipeline. This is the exact same C++ code that draws vanilla stone, grass, and saplings.

Alternatively, if you use the minecraft:geometry and minecraft:material_instances components inside your behavior pack block file, the game routes your block through the data-driven rendering pipeline. In modern Bedrock versions, this pipeline exposes native geometry identifiers such as the standard full cube, allowing you to combine data-driven material control with built-in engine shapes.

For several years, applying a custom shader or render method to a simple 16x16x16 block required exporting a redundant cube geometry file in your resource pack because the minecraft:geometry component could not be omitted when using minecraft:material_instances. Modern Bedrock updates solved this by introducing the built-in minecraft:geometry.full_block identifier.

When you assign minecraft:geometry.full_block to the minecraft:geometry component, the engine generates a standard 16x16x16 unit cube with default per-face UV mapping. You can target individual faces in minecraft:material_instances using the standard compass directions (up, down, north, south, east, west) or cover all remaining faces using the wildcard asterisk (*).

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "wiki:crate"
    },
    "components": {
      "minecraft:geometry": {
        "identifier": "minecraft:geometry.full_block"
      },
      "minecraft:material_instances": {
        "up": {
          "texture": "crate_top",
          "render_method": "opaque"
        },
        "down": {
          "texture": "crate_bottom",
          "render_method": "opaque"
        },
        "*": {
          "texture": "crate_side",
          "render_method": "opaque"
        }
      }
    }
  }
}

To make flowers, saplings, or tall grass without creating a custom geometry file, you can use the built-in minecraft:geometry.cross identifier. This model arranges two intersecting flat planes diagonally across the block space from corner to corner, matching the exact layout of vanilla poppies and oak saplings.

Because a cross model has transparent empty spaces in the texture and leaves both sides of each plane visible to the player, you must adjust your material instance settings. Set render_method to alpha_test so transparent pixels are discarded, and set face_dimming and ambient_occlusion to false so the flat planes do not cast harsh dark shadows onto themselves.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "wiki:blue_rose"
    },
    "components": {
      "minecraft:collision_box": false,
      "minecraft:selection_box": {
        "origin": [-4.0, 0.0, -4.0],
        "size": [8.0, 12.0, 8.0]
      },
      "minecraft:geometry": {
        "identifier": "minecraft:geometry.cross"
      },
      "minecraft:material_instances": {
        "*": {
          "texture": "blue_rose",
          "render_method": "alpha_test",
          "face_dimming": false,
          "ambient_occlusion": false
        }
      }
    }
  }
}

If your custom block does not use minecraft:geometry or minecraft:material_instances in the behavior pack at all, its visual shape and textures are controlled entirely by RP/blocks.json. Inside this file, each block entry accepts a blockshape string that instructs the game to draw the block using one of the hardcoded vanilla terrain tessellators.

This approach is useful when you are making dozens of simple building blocks and want to keep your behavior pack files minimal. However, keep in mind that blocks.json shapes only affect visual rendering. They never change the physical collision or selection boxes of your block; a block given the cross_texture shape in blocks.json will still act like a solid barrier unless you disable minecraft:collision_box in the behavior pack.

{
  "format_version": "1.19.0",
  "wiki:polished_slate": {
    "textures": {
      "up": "polished_slate_top",
      "down": "polished_slate_bottom",
      "side": "polished_slate_side"
    },
    "sound": "stone"
  },
  "wiki:wild_fern": {
    "textures": "wild_fern",
    "blockshape": "cross_texture",
    "sound": "grass"
  }
}

Creators frequently try to reference vanilla block geometries such as stairs, fences, hoppers, or cauldrons inside their custom block's minecraft:geometry component, only to find that the block fails to render. Unlike entity models, most vanilla blocks do not exist as data-driven .geo.json files in the vanilla resource pack. Instead, their vertices are generated on the fly by hardcoded C++ routines inside the game engine.

Even if you apply a legacy blockshape like stairs or fence inside RP/blocks.json, the C++ renderer looks for specific vanilla block states (such as weirdo_direction or upside_down_bit) to determine how to orient or connect the mesh. Because custom blocks cannot register vanilla block properties under the minecraft namespace without causing validation errors, those hardcoded shapes will either crash the renderer, draw in a broken default state, or fail to connect to neighbors. For stairs, slabs, walls, and fences, you must either use the official Custom Block Traits (like minecraft:placement_direction) with your own Blockbench geometry files, or extract and recreate the meshes yourself.

Applies to Bedrock Edition 1.20.60 and newer without any experimental toggles. The minecraft:geometry.full_block identifier became stable in 1.20.60, and minecraft:geometry.cross is supported in 1.20.80 and above.

Read out of the game itself, so the ids match the version you are building for.