.skeleton.blk

Purpose of .skeleton.blk

Composite models are constructed from multiple dynamic models that share a common skeleton. Below are the rules for creating a .skeleton.blk file for a composite model.

Examples

Let’s break down the configuration using the example of a tank with various turret and gun options.

name:t="tank_body.lod00.dag"
attachSubSkel{
  attach_to:t="bone_turret"
  skel_file:t="turret_a.lod00.dag"
  skel_node:t="bone_turret"
  attachSubSkel{
    attach_to:t="bone_gun_a"
    skel_file:t="gun_a.lod00.dag"
    skel_node:t="bone_gun_a"
  }
  attachSubSkel{
    attach_to:t="bone_gun_b"
    skel_file:t="gun_b.lod00.dag"
    skel_node:t="bone_gun_b"
    add_prefix:t="G1:"
  }
  attachSubSkel{
    attach_to:t="bone_gun_c"
    skel_file:t="gun_b.lod00.dag"
    skel_node:t="bone_gun_b"
    add_prefix:t="G2:"
  }
}
attachSubSkel{
  attach_to:t="bone_turret"
  skel_file:t="turret_b.lod00.dag"
  skel_node:t="bone_turret"
  add_prefix:t="T1:"
}

Parameter Details

• name:t=: The name of the parent model.

• attachSubSkel: Block for adding a dynamic model.

  • attach_to:t=: Node in the parent skeleton to which the dynamic model is linked.

  • skel_file:t=: Name of the child model.

  • skel_node:t=: Node in the child skeleton that links to the parent skeleton.

  • add_prefix:t=: Prefix for all nodes of the child model.

Explanation

In the .skeleton.blk example above, we add the turret_a and turret_b models to the skeleton generated by tank_body, linking them to the bone_turret. Additionally, we attach the guns gun_a and gun_b to the nodes bone_gun_a, bone_gun_b, and bone_gun_c of turret_a, with gun_b being linked twice to different bones.

Since we are creating a single common skeleton, there cannot be nodes with identical names. To address this, we assign a unique prefix to the nodes of each duplicate. For instance, the nodes of the two copies of bone_gun_b receive the prefixes G1 and G2, while the nodes of turret_b receive the prefix T1.

Important

• When specifying the attachment node, do not account for the automatically added prefixes.

• If a child node is linked to a node with the same name, the previous node is removed from the hierarchy to avoid duplicates.

Hierarchical Dependencies

While it’s possible to create long chains of dependencies, simpler structures are easier to manage. Before adding another level, ensure its necessity.

A multi-level hierarchy might look like this:

name:t="papa.lod00.dag"
attachSubSkel{
  attach_to:t="bone_papa"
  skel_file:t="child.lod00.dag"
  skel_node:t="bone_child"
  add_prefix:t="layer01:"
  attachSubSkel{
    attach_to:t="bone_child"
    skel_file:t="child.lod00.dag"
    skel_node:t="bone_child"
    add_prefix:t="layer02:"
    attachSubSkel{
      attach_to:t="bone_child"
      skel_file:t="child.lod00.dag"
      skel_node:t="bone_child"
      add_prefix:t="layer03:"
      attachSubSkel{
        attach_to:t="bone_child"
        skel_file:t="child.lod00.dag"
        skel_node:t="bone_child"
        add_prefix:t="layer04:"
      }
    }
  }
}

This structure allows for extensive customization while maintaining manageability by using prefixes to avoid naming conflicts and ensure proper hierarchy.