Fragments are the basic building block of interactive animation in CryMannequin. You play an animation by wrapping it in a fragment, and then play the fragment instead. More specifically fragments are layered sequences of animation clips & Procedural Clips. This means that you can lay out a couple of animation clips in a sequence, or layer them on top of each other, and treat them as one. Fragments are referred to by a FragmentID and Tags. Multiple fragments can have the same fragmentID and tags, then we say that there are multiple options.
Fragments play on Scopes. (there can only be one fragment playing on a scope at a time)
When going from one fragment to another, Transitions are used.
Creating and Editing Fragments
Fragments are created in the Mannequin Fragment Browser and edited in the Mannequin Fragment Editor.
Storage
Fragments are stored in an Animation Database File (ADB).
Which ADB file a fragment you edit ends up in is determined as follows:
- First the system looks at the scope you are editing a fragment on. (e.g. FullBody).
- This scope has a certain scope context. This is defined in the controller definition (e.g. the FullBody scope might work on the MainCharacter scope context).
- Then the system looks at which ADB file is assigned to this scope context in the current preview setup, which is edited in the context editor (e.g. the MainCharacter scope context has MainCharacterAnims.adb assigned to it).
- The fragment will end up in this ADB file. It is possible for this ADB file to have optional rules that move the fragment into another ADB file, a sub-ADB. This is edited in the animation DB editor (e.g. there might be a rule that moves fragments for the "hit" FragmentID into the sub-adb MainCharacterHitAnims.adb).
Fragment ID Description
A FragmentID is the main label under which a fragment is stored.
The FragmentID represents an animation state like "Moving", "Idling", "Reloading", "Firing", etc... The game requests fragments by specifying this FragmentID. Contrary to what the name 'FragmentID' might suggest there are typically many fragments that fall under the same FragmentID. For example you can have many different "Moving" fragments: they represent either random variations or context-specific variations (moving while crouched, moving while standing, etc).
Typically a programmer defines a FragmentID for every basic animation state and then animators can create fragments for those FragmentIDs.
FragmentID or Transition?
A good rule of thumb to define what should be a FragmentID: Reduce the states to the minimum, logically required to control the flow of the system. These are all the code needs to drive and can be taken as your key FragmentIDs.
For example this is how a Weapon Crafting feature could look like:
If we need animations between FragmentIDs these are best handled as Transitions. This reduces code and makes the system easier to modify purely through data:
A grey area is the customization step. The swapping of a part needs to sequence removing a specific old part and inserting the new (left of the picture).
Or we could just request an alternate customize stance (change a tag specifying the stance and request a new fragment) and then let the transition system handle removing the old part and apply the new part. This would also let the animators drop in a single animation to do both steps if they wished.
Creating & Editing FragmentIDs
FragmentIDs are created, renamed and deleted in the Mannequin Fragment Browser.
You edit them in the Mannequin FragmentID Editor.
Storage
FragmentIDs are stored in a FragmentID Definition File (xxxActions.xml), which is referred to from the main character setup, the Controller Definition File (xxxControllerDefs.xml).