> For the complete documentation index, see [llms.txt](https://docs.bestway.com.ua/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bestway.com.ua/modeling/vehicle-model-setup-pipeline/bone-hierarchy-in-vehicle-models/secondary-bones.md). # Secondary bones This section describes the setup of secondary bones, which are a visual complement to the primary bones of model Components. ## Visual details Meshes of additional geometric elements that introduce visual variety to the model without affecting its functionality are referred to as `detail` bones. When the model spawns in-game, these bones are selected randomly, creating different visual variations.

Each `detail` bone must have a unique name in the format detail\ , \ is a sequential number, and be linked in the bone hierarchy to the **primary bone** of the **Component** it visually belongs to. For example, if it adds elements to the hull, it should be linked to the `body` bone (`id=body`), while one affecting the turret should be linked to the `turret` bone (`id=turret`). Each `detail` bone must have a unique name, achieved by adding a sequential number to its name, e.g., `detail1`, `detail2`, etc. **Properties of `detail` bones:**

Property	Description
`poly`	Indicates that the bone will be visible.
`ID=<value>`	Specifies the identifier of the component to which the bone belongs.
Animation (optional)

{% hint style="warning" %} No volumes are required for `detail` bones.\ The game engine does not support volumes of this type. {% endhint %} *** ## Hatches Meshes representing hatches are assigned to `cover` bones.

Depending on the functional design of the hatch, it may consist of multiple independent parts. In this case, each part must be represented by a separate `cover` bone. Each `cover` bone must be linked in the bone hierarchy to the primary bone of the **Component** to which the hatch belongs.\ The bone name must be unique and follow the format `cover`, where `` is a sequential number (`cover1`, `cover2`, etc.). The `ID` of the `cover` bone must match the identifier of the **Component** to which the hatch belongs. **Properties of `cover` bones:**

Property	Description
`poly`	Indicates that the bone will be visible.
`ID=<value>`	Specifies the identifier of the Component to which the hatch belongs.
`AnimationResume=open,cover`	Defines the animation name. This animation plays when the tank crew member enters or exits the vehicle.

{% hint style="warning" %} No volumes are required for `cover` bones.\ The game engine does not support volumes of this type. {% endhint %} *** ## Add-on armor shields bones f the model includes **add-on armor**, it can be configured as part of the vehicle's armor system.\ Each armor piece can be set up as a unique element by separating the mesh into individual shields and assigning each a unique identifier: `ID=shield`, where `` is a unique identifier segment. In most cases, add-on armor shields are symmetrical. Therefore, the `` index in the name can include a combination of `L`or `R` to indicate whether the shield belongs to the left or right side, along with a sequential number.\ For example: `shieldL1`, `shieldR1`.

**Properties of `shield` bones:**

Property	Description
`poly`	Makes the armor shield visible.
`ID=shield<N>`	Unique identifier of the shield. `<N>` represents the shield number.

A **volume** `shield_vol` is linked to the corresponding `shield` bone, defining the physical volume of the armor.

### **Shield attachment bones** Each shield is also linked to its own attachment bone, `shield_binding`.\ These bones serve as anchor points for the shields and define their movement and destruction behavior. A `shield_binding` bone can be either: * An auxiliary invisible bone that exists purely for positioning and hierarchy purposes. * A part of the shield mesh itself, acting as the attachment point. In the bone hierarchy, `shield_binding` bones must be linked to the primary bone of the **Component** to which the shield is attached. For example: * If the shield is part of the hull, the attachment bone should be linked to `body`. * If the shield is part of the turret, it should be linked to `turret`. If the model supports destruction effects for shields, animations or physics constraints can be applied to these attachment bones. **Properties of `shield_binding` bones:** | `poly` (optional) | If the attachment bone is part of the mesh, this property determines its visibility. | | ---------------------- | ---------------------------------------------------------------------------------------------------- | | `ID=shield_binding` |

Unique identifier of the attachment point.
\ represents the shield number.

| {% hint style="warning" %} No volumes are required for `shield_binding` bones.\ The game engine does not support volumes of this type. {% endhint %} *** ## Vehicle identification number The `enumerator` bone represents a model composed of three (or six for U.S. vehicles) polygons, each assigned a unique `id material` corresponding to textures displaying the identification number.

**Number attachment to a model component** In the bone properties, the `ID` of the component where the unit number is visually applied must be specified.\ For tank models, this is typically `ID=body` or `ID=turret`.