Using Custom Block Renderers - webbukkit/dynmap GitHub Wiki

A number of types of blocks require more complex rendering logic than simple static models tied to specific block ID and metadata values can allow. These include blocks whose presentation is sensitive to neighboring blocks (redstone wire, fences, walls, glass panes, stairs) as well as those that depend upon TileEntity data or other information (skulls, Railcraft tracks, Immibis' Microblocks).

To define a model using a custom block renderer, a "customblock:" line needs to be defined. The base attributes for this line include:

  • id - the block ID that the model is to be used for. At least one id attribute is required, but as many as are needed can be used - allowing the same model to be used for multiple blocks. See Block ID Numbers for details on specifying block ID numbers.
  • data - this provides the specific metadata values that the model is to be applied to. The default, data=*, indicates all metadata values for each of the blocks IDs indicated by the id attributes. Otherwise, one or more data=number attributes can be used to select specific metadata values for the model.
  • class - this provides the fully qualified classname of the class for the custom block renderer. This attribute is required.

The "customblock:" line may also have additional attributes, as indicated by the specific custom block renderer selected.

Custom block renderer always generate a defined sequence of patches (surfaces to which textures can be applied). The indexes of the corresponding patches are defined by the custom block renderer. The texture references supplied by the Texture Definition Files need to be specified by patch<N> attributes in the corresponding "block:" lines.

Existing Custom Block Renderers

The following Custom Block Renderers are provided by Dynmap, and can be used for new custom blocks when appropriate.

Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️