Defining a Block using a Custom Block Renderer - webbukkit/dynmap GitHub Wiki

To define a custom block with its model provided by a custom block renderer, the first step is to select and configure the renderer in the Model Definition file. This is done using the 'customblock:' line, which must include one or more block IDs (via the id attribute), any needed metadata values (via the data attribute), and the class of the custom renderer (via the class attribute). For example, the sandstone stairs block is defined as follows:

 customblock:id=128,,data=*,class=org.dynmap.hdmap.renderer.StairBlockRenderer

Besides these core attributes, certain custom block renderers will offer (and may require) additional attributes to properly configure the renderer. See the 'Attributes' section of the description for the corresponding renderer for the needed details.

Next, the texture references need to be defined in order to supply the textures needed for the custom renderer. The 'Patches Requiring Textures' section of the custom renderer's description defines the 'patch<N>' attributes that need to be supplied for the block. Using these descriptions, the appropriate 'block:' line must be included in the Texture Definition file, with a 'patchN' attribute for each of the indicates patches. For example, the above custom renderer for stairs requires 3 patches: one for the block sides, one for the tops, and one for the bottoms: for Sandstone Stairs, the corresponding line is:

 block:id=128,data=*,patch0=0:sandstone_normal,patch1=0:sandstone_top,patch2=0:sandstone_bottom,transparency=SEMITRANSPARENT

Note: most custom renderers define blocks that are not full, opaque blocks, so the transparency attribute is generally required on the "block:" line. Use the TRANSPARENT setting for blocks that do not block light to other blocks, or SEMITRANSPARENT for blocks that do block light to other blocks (like slabs and stairs).