Skip to content

Blockstate Format

XFactHD edited this page Apr 29, 2026 · 4 revisions

The metadata specifying how connected textures apply to a block is specified in the blockstate JSON file associated with said block. Next to the metadata, this file must contain a valid vanilla blockstate declaration via the variants and/or multipart entries.

This page explains the custom format and lists the builtin types provided by ConTex.

Example

{
    "neoforge:definition_type": "contex:definition",
    "contex_meta": [
        {
            "type": "contex:full",
            "predicate": "contex:same_block",
            "occlusion_mode": "solid_or_self",
            "state_predicate": { },
            "textures": [
                {
                    "main_texture": "minecraft:block/glass",
                    "compact/hor": "minecraft:block/glass_hor",
                    "compact/vert": "minecraft:block/glass_vert",
                    "compact/cross": "minecraft:block/glass_cross",
                    "compact/full": "minecraft:block/glass_full"
                }
            ]
        }
    ],
    "strategy": "contex:compact",
    "variants": {
        "": { "model": "minecraft:block/glass" }
    }
}

Specification

The connected textures metadata consists of an array of metadata entries and a texture strategy.

Each metadata entry consists of the following elements:

  • A texture type (type),
    • Dictates how the block model checks whether the block is connected to neighboring blocks
  • A connection predicate (predicate)
    • Specifies the comparison to use for checking whether a connection should be made between two adjacent blocks on a given side
    • Can be omitted, in which case it defaults to contex:same_block
  • An occlusion mode (occlusion_mode)
    • Dictates whether an attempted connection can be prevented by a block covering the adjacent block's face being connected to
    • Can be omitted, in which case it defaults to self
  • A state predicate (state_predicate)
    • Dictates which states of the block this metadata entry applies to
    • Consists of a mapping of property names to property values
      • Example: "axis": "y" on a log block would cause this metadata entry to only apply to vertical logs
    • Can be omitted, in which case this metadata entry applies to all states of the block
  • An array of texture entries (textures)
    • Each entry must at least specify a main_texture which must match a texture used by the unmodified model
    • An entry can optionally specify the connection variant textures to use non-standard texture paths
    • Supported variant keys are controlled by the texture type and texture strategy used
    • If variant textures are unspecified
      • The texture paths are computed from the main_texture and variant-specific suffixes
      • The main texture can be inlined in the array instead of being specified in an object containing only the main_texture key (since v13.0.1)

The texture strategy dictates how the model's quads are created from the computed connection state.

Builtin Types

Texture Types

  • Simple
    • ID: contex:simple
    • Applies to all six faces
    • Only checks for connections toward direct neighbors (four connection checks per face)
    • Requires horizontal, vertical and full variant textures for compact strategy
  • Full
    • ID: contex:full
    • Applies to all six faces
    • Checks for connections toward direct neighbors and diagonal neighbors (eight connection checks per face)
    • Requires horizontal, vertical, cross and full variant textures for compact strategy
  • Pillar (variant per axis)
    • ID per axis:
      • X axis: contex:pillar_x
      • Y axis: contex:pillar_y
      • Z axis: contex:pillar_z
    • Applies to the four faces whose normal direction does not match the type's axis
    • Only checks for connections at edges matching the type's axis
    • Intended for pillar blocks which use a single texture for all orientations and rotate it via model or blockstate transformations (i.e. logs)
    • Requires vertical variant texture for compact strategy
  • Rotating Pillar (variant per axis)
    • ID per axis:
      • X axis: contex:pillar_rot_x
      • Y axis: contex:pillar_rot_y
      • Z axis: contex:pillar_rot_z
    • Applies to the four faces whose normal direction does not match the type's axis
    • Only checks for connections at edges matching the type's axis
    • Intended for pillar blocks which use separate textures for horizontal and vertical pillars
    • Requires horizontal and vertical variant textures for compact strategy
  • Omnidirectional Pillar
    • ID: contex:pillar_omni
    • Like Pillar but not fixed to a single axis, instead trying all three axis in Y-X-Z order
    • Requires horizontal and vertical variant textures for compact strategy
  • Simple Carpet (variant per "attach face" direction)
    • ID per direction:
      • Down: contex:carpet_simple
      • Up: contex:carpet_simple_up
      • North: contex:carpet_simple_north
      • East: contex:carpet_simple_east
      • South: contex:carpet_simple_south
      • West: contex:carpet_simple_west
    • Applies to the "attach face" and the opposing face
    • Limits connection occlusion to solid and none on the "attach face" and to none on the opposing face
    • Only checks for connections toward direct neighbors (four connection checks per face)
    • Requires horizontal, vertical and full variant textures for compact strategy
  • Full Carpet (variant per "attach face" direction)
    • ID per direction:
      • Down: contex:carpet_full
      • Up: contex:carpet_full_up
      • North: contex:carpet_full_north
      • East: contex:carpet_full_east
      • South: contex:carpet_full_south
      • West: contex:carpet_full_west
    • Applies to the "attach face" and the opposing face
    • Limits connection occlusion to solid and none on the "attach face" and to none on the opposing face
    • Checks for connections toward direct neighbors and diagonal neighbors (eight connection checks per face)
    • Requires horizontal, vertical, cross and full variant textures for compact strategy

Connection Predicates

  • Same Block
    • ID: contex:same_block
    • Considers two blocks connected if they are the same block
  • Same State
    • ID: contex:same_state
    • Considers two blocks connected if they are the same state
  • Match Block
    • ID: contex:match_block
    • Considers two blocks connected if they match the specified blocks
      • If declared with block, both blocks check against the same value
      • If declared with self_block and other_block, the block trying to connect checks against the former and the block being connected to checks against the latter
  • Match State
    • ID: contex:match_state
    • Considers two blocks connected if they match the specified blockstates
      • If declared with state, both blocks check against the same value
      • If declared with self_state and other_state, the block trying to connect checks against the former and the block being connected to checks against the latter
  • Match Tag
    • ID: contex:match_tag
    • Considers two blocks connected if they match the specified tags
      • If declared with tag, both blocks check against the same value
      • If declared with self_tag and other_tag, the block trying to connect checks against the former and the block being connected to checks against the latter

Occlusion Modes

  • None (none): connections cannot be occluded by adjacent blocks
  • Self (self): connections can only be occluded by blocks matching the connection predicate
  • Solid (solid): connections can only be occluded by opaque blocks which cause the connection target face to be culled
  • Solid or self (solid_or_self): connections can be occluded by either of the above

Texture Strategies

  • Compact
    • ID: contex:compact
    • Assembles the connected faces from four quarter-sized quads using the respective corner's subsection of the variant sprite applicable to the connection state at that corner
    • Requires up to four textures in addition to the unconnected main texture
    • Supported variant textures and their keys and automatic texture suffixes:
      • Horizontal: connected at the left and right edge (variant key: compact/hor, variant suffix: _hor)
      • Vertical: connected at the top and bottom edge (variant key: compact/vert, variant suffix: _vert)
      • Cross: connected at all four edges with corners preserved (variant key: compact/cross, variant suffix: _cross)
      • Full: connected at all four edges with corners removed (variant key: compact/full, variant suffix: _full)
  • Full
    • ID: contex:full
    • Uses a separate sprite for each connection variant, applied to a full-size quad
    • Requires up to 46 textures in addition to the unconnected main texture
    • The supported variant suffixes are concatenations of the compact suffixes and none for unconnected corners in the format <top-left>_<top-right>_<bottom-left>_<bottom-right>
      • A variant is only valid if the two compact variants sharing an edge don't disagree about that edge's connectedness (i.e. vert for top-left cannot be combined with none for top-right)
      • Example: A face using the contex:full texture type and connected upwards, to the left and diagonally top-left would use the sprite suffixed full_vert_hor_none
    • The supported variant keys are the variant suffixes prefixed by full/
    • The variants used by a particular texture type are all possible concatenations of the compact variants used by the type according to the format specified above
    • This strategy does not support models with randomized texture rotations such as stone and grass

Clone this wiki locally