In order to avoid the need for an intermediate step, there needs to be an explicit pairing between character hard points and item hard points. Every item needs a hard point for every specific way that it can be held.

As an example, listed below are the hard points for a human character and a gun.

The (client-side) Entity class provides a list of hard points, but only if asked by the specializing class. For example, when a model is loaded, it will find all nodes prefixed with (for instance) 'HP_'. These are then stored in a hardPoint list that is owned by the model.

When an item is equipped, the entity/game arbiter will be asked to match up the item with the correct hard point. For example, if the 'next weapon' button is pressed, the next weapon in the inventory can be attached to the right hand hard point.

The syntax for using hard points from Python is elegant and powerful. To attach model gun to model avatar on hard point hand, use the following syntax:

avatar.hand = gun

A model is checked when it is attached to ensure that it is not attached elsewhere. To retrieve the model attached to avatar's hand, simply use:

model = avatar.hand

If no model is attached, then None is returned.

The model is attached by reference, not by copy, so anything that can be done to the original model reference can be done to the reference retrieved from a hard point.

For example, gun.Shoot() and avatar.hand.Shoot() have the same effect.

A model definition is an XML file specifying:

The Model Editor tool is used to create a .model file that links an object's geometry to its animations and defines the sets of animations/actions that are possible to play on this object.

As with all resource files in the BigWorld framework, .model files are in XML format. They are hierarchical and inherit data from their parent(s), in this way basic animations that apply to a large set of characters can be isolated from more character-specific animations without having to be duplicated.

The example below defines a very simple model:

<jogger.model>

  <nodefullVisual>  jogger  </nodefullVisual>
  <parent>          biped   </parent>

  <animation>
    <name>      jog         </name>
    <frameRate> 30.0        </frameRate>
    <nodes>     jogAnim     </nodes>
    <alpha>
      <Torso>   0.0  </Torso>
      <Pelvis>  1.0  </Pelvis>
    </alpha>
  </animation>

  <action>
    <name>          BIPED_JOG  </name>
    <animation>     jog        </animation>
    <blendInTime>   0.300000   </blendInTime>
    <blendOutTime>  0.300000   </blendOutTime>
    <filler>        false      </filler>
    <blended>       false      </blended>
    <isMovement>    true       </isMovement>
    <isCoordinated> false      </isCoordinated>
    <isImpacting>   true       </isImpacting>
    <match>
      <trigger>
        <minEntitySpeed> 1.0  </minEntitySpeed>
        <maxEntitySpeed> 3.0  </maxEntitySpeed>
        <capsOn>         16   </capsOn>
      </trigger>
    </match>
  </action>
<jogger.model>

Example of .model file

This file describes a character (jogger) which has a geometry defined by the visual file jogger and has a standard set of biped actions via the <parent> tag, which may include walk, run, and jump animations, but also specifies a jog animation.

The animation section includes:

The <action> section describes the action name that is used to play this action from the Python code.

There are model files, with the .model extension, but there are no explicit SuperModel files.

There is the SuperModel class, which holds together and controls the animation and rendering of a number of models. A SuperModel is created based on information in chunk and model files (these are instance-like classes — there is nothing analogous to PyModelInfo.).

Using LOD ratios, the SuperModel class can manage the transition between, say, an avatar being rendered at a high LOD using three separate models, to it being rendered at a low LOD using just one.

Animations are accumulated on the same inheritance hierarchy, and the animation most appropriate to the current LOD level is used. All the animations for all the LOD levels are interpreted and selected from a flat namespace. Attempting to play an animation that does not exist (or does not exist at the current LOD level) selects an infinite length animation of the model's initial pose. Care must be taken to ensure that multi-model SuperModels do not waste time animating unnecessarily (e.g., when all the small parts have an animation overriding the whole part's animation, it would be a waste of time to apply the whole part's animation).

The mesh files themselves specify how a part is connected to others for multi-part supermodels.

The SuperModel class implements the basic functionality of the BigWorld model definition, using the objects provided by Moo. It combines a number of the .model files created by Model Editor (but usually just one) into one conceptual model, managing any animations and level-of-detail chains. The SuperModel class is detailed in SuperModel.

Two classes currently use SuperModels in the BigWorld client, for two different needs:

Both are described in the following subsections.