6 Custom Block Definitions
mikeprimm edited this page 2013-11-28 07:41:25 -08:00

Dynmap supports a data-driven method for defining support for new Minecraft Blocks, which may be used to support customized block types, such as those provided via certain plugins and client modifications. These definitions are VERY sensitive to the internal implementation of the Dynmap ray tracer, and may change or become obsolete on future releases with little or no notice - when practical, this will be avoided, but do understand this before investing too heavily in this.

How blocks are rendered

The rendering of block in Dynmap is accomplished via a number of distinctive mechanisms, reflecting the needs of the different types of blocks defined by Minecraft and by its mods. In all cases, the rendering of a block consists of two core elements: a model defining the shape of the block to be rendered, and a set of textures used to apply color to the various surfaces of that shape. Thanks to the very 'blocky' nature of Minecraft, the majority of blocks are shaped like simple cubes: consequently, most blocks do not need a custom model, and can instead be assumed to be a simple solid cube.

Support files for custom blocks defined by add-on mods are provided through the definition of two files for each mod: one defining the texture mapping (following the naming convention '*-texture.txt', and placed in the 'renderdata' directory (or in a subdirectory under that directory)), and a second defining the models for blocks that are not simple cubes (following the naming convention '*-models.txt', and also placed in the 'renderdata' directory, or a subdirectory). For mods that have nothing but simple cubes, no *-models.txt file is required (as the model for any block without a model defined is assumed to be a simple cube).

Creating Texture and Model Definition Files

Defining Blocks