Animations Guidelines

From Project Tamriel Wiki
Jump to navigation Jump to search

Animations make Morrowind creatures, characters, and objects come to life. Animating is one of the more obscure yet important parts of Morrowind asset creation; any developers with experience in the subject are highly valued. Nowadays animations for Morrowind are created using Blender's inbuilt tools and are exported using the Morrowind Blender Plugin, hence this page largely covers the quirks of the NIF file format and Morrowind's engine as they relate to animation.

The information below is currently being revised and expanded.


The processes covered by Blender tutorials are generally applicable to making animations for Morrowind, though some steps and workflows may be inefficient or unnecessary.


Rigging deals with setting up armatures, which are Blender objects consisting of "bones" that are used for complex animations. This usually involves the creation of at least two armatures: The first (often called the "skeleton", "export rig", etc.) is used by meshes and is exported with them. The second (commonly called the "control rig") is typically a modified version of the skeleton that is manipulated to create animations that will be baked onto the former for in-game use. Finally, different bone constraints are added to bones in both of these rigs, either to copy transformations from the control rig to the skeleton, limit the movement of the bones, or make the control rig easier to animate.

Note: Rigging is commonly mischaracterized as being equivalent to "skinning" a model or only creating the skeleton that will be used in-game. Skinning is the process of setting the vertex weights of a model so that it is affected by the animations of a chosen armature, while making the skeleton for Morrowind itself is only one step of the rigging process


General and rigged animations

Shapekey animations

Shapekeys (also known as “morph targets” or “blend shapes”) are different deformations of a mesh whose degree of influence over the shape of the mesh can be animated. In Morrowind shapekeys are most often used for the facial animations of characters, though they can also be used for other animations that bones are not well suited for (e.g. the tongue and mouth of the Hunger daedra).



Modern guides that go over making animations for Morrowind are unfortunately scarce and are usually limited in scope or condition. The following constitute the guides made (relatively) recently outside of this wiki page that are currently known:

Aside from these sources, the Morrowind Modding Community on Discord can be a good place for gathering information and asking questions.


The following is a selection of old sources that remain valuable, though bear in mind that the UI, capabilities, and functioning of Blender and its Morrowind plugin have improved tremendously since these were made:

Note: Vanilla Morrowind assets were developed using 3ds Max, which was also the preferred way to make animations in the early Morrowind modding scene and for which you may still find many guides floating around. However, modern versions of 3ds Max are no longer compatible with the old Morrowind export plugin and it is currently not possible to make animations for Morrowind in that program.


Control Rigs

Greatness7 has created some extremely useful control rigs for the humanoid skeleton used by all characters who are not a beast race as well as skeleton creatures.

The most generous and benevolent writer of these revised guidelines uploads the control rigs and animations of creatures that they have contributed to, so that those who to learn by example (or cleanly modify the animations) can do so. It is overwhelmingly recommended that you do so as well, since making edits to files like these is far easier than doing so to an asset which has been exported to a NIF file.


Blender's UI is not well suited to editing a lot of text keys at once. Therefore, the writer of these revised guidelines (having referenced some scripts given by Lambshark/Sandaron) has uploaded Python scripts that can be used to delete text keys or transfer them between rigs/actions.


Animation types

The NIF file format for Morrowind can be thought of as using two kinds of animations: Keyframe animations and controller animations. The name of the former arises from their use of the NiKeyframeController node, which handles changes in the location, rotation, and scaling of objects or the bones of armatures. The latter refers to all of the other kinds of controllers used by NIF files, which allow for textures, UVs, geometry, and more to be animated.

  • Keyframe animations are either managed by scripts (for ACTIVATOR, LIGHT and DOOR type objects only, with a script like OutsideBanner), or called in a hardcoded manner by the engine (for NPCs and creatures with fixed animation group names, such as Idle2 and WalkForward). Assets with keyframe animations use three files: NIF, xNIF and xKF (for example, dremora.nif, xdremora.nif, and xdremora.kf). The NIF contains both geometry and animations and is used exclusively by the Construction Set to identify which xNIF and xKF files the game should load, while the xNIF and xKF only contain geometry and keyframe animations respectively. When exporting an asset with keyframe animations using the Morrowind Blender plugin, both the "Export Animations" and "Extract Keyframe Animations" must be checked in order to create the xNIF and xKF files. Going forward, these guidelines will simply refer to the NIF file when describing where animations are stored unless otherwise necessary.
  • Controller animations can be exported normally to a NIF file alone unless keyframe animations are also present. Examples include animated particles (Ex_waterfall_mist_01.nif), animated textures (Ex_Vivec_waterfall_01.nif), geometry (B_N_Nord_F_Head_01.nif), alpha (magic_hit_Levitate.nif), and many others.
    • Note: alpha-animated magic effects used by the engine work under NiNode, but for objects they need to be under NiBSAnimationNode with certain flag values or 32. See the NiBSAnimationNode flags section in the Particle Effect Guidelines.



Morrowind samples animations at 15 FPS, so it is advisable to set Blender's frame rate in Output Properties>Format to 15 FPS as well. This ensures that none of the keyframes in an imported file fall between frames in Blender and that all created keyframes are at times that can be played by Morrowind. If you do this in an empty file and save it as the startup file (File>Defaults>Save Startup File), then you never have to worry about setting the frame rate again.

Text keys

Text keys are how Morrowind's animation groups and the events within them (such as sounds and weapon hits) are identified. In Blender (with the Morrowind plugin) the text keys can be found by entering the dope sheet editor, switching from the dope sheet to the action editor, and then (if an action is linked) clicking "Misc" in right toolbar and choosing to "Show Text Keys" in the Morrowind panel. Text keys will become visible in the action editor and can be added, renamed, moved, or deleted from that panel.

Creature animations

Animation groups

Root bone

The root bone of a creature must be given one of two specific names for movement to work correctly in the game, those being "Root Bone" and "Bip01". Although Blender allows for animations to work with multiple root bones, Morrowind requires that all other bones descend from a single one. Otherwise the skeleton will be exported incorrectly.


Animations of the root bone change the actor's position, orientation, and size in the game. If movement animations (walk, run) are missing root coordinate changes or if their movement speed is too slow the engine will give an error saying that it was exported with "Animate in Place" from MAX. For walking, MCP has a default fix that "Allows actors with very slow walk animations (<1 unit/sec) to load without causing animation errors". It only works for walking animations, not running animations and not walking when in combat stance which only the player uses by default.

Creature pose in the Construction Set

When a creature is placed in the Construction Set, it will appear as it does at the end of its final animation group. This is why vanilla Morrowind's creatures usually have Idle as their last animation.

Bounding boxes

Morrowind's creatures only enjoy a very simple form of collision in the form of bounding boxes. In Blender, the bounding box of a creature takes the form of an empty object whose location, rotation, and scale determine its placement and extent. Having the bounding box's empty object be a cube (which the Morrowind plugin imports bounding boxes as) is ideal for visualizing the nature of a creature's collision. The center of a creature's bounding box is also used as the point from which spells are fired.

Shadow meshes

As the name implies, shadow meshes are responsible for casting the shadow of a creature. A shadow mesh is usually a simplified version of a creature's mesh(es) for the sake of performance and parity with vanilla creatures, but it can also just be a copy. Shadow meshes must be given names that begin with "Tri Shadow" and have their flags set to 65 (though some vanilla meshes use other flags).

Character animations

The principles behind creature animations generally apply to character animations as well, though with some additional considerations. Most races use the skeleton and animations in base_anim.nif, with female characters having Idle4, Idle5, and WalkForward replaced by those in base_anim_female.nif. Races marked as "beast races" (such as Khajiit and Argonians) use the digitigrade base_animkna.nif instead. Lastly, files such as base_anim.1st.nif provide 1st person animations.

Movement with weapons

Melee weapon animations (1hand, 2hand, 2close and 2wide) have their own walk and run animations, but others (such as bow animations) just use the 1hand movement animations.

NPC animation files

A keyframe animation file can be attached to individual NPCs in order to overwrite existing animations (as described here and here), and animations that are not overwritten are kept from the base_anim file that the character would normally use. For reference, vanilla Morrowind (only) uses this feature for a handful of NPCs who are all in Suran; each of "dancer girls" use the anim_dancinggirl.nif animation file to replace Idle9. Despite the limited use of this feature by Bethesda, there are no limits to how how many of the animations in base_anim.nif can be replaced by an animation file assigned to an NPC.

There are a couple of requirements for these animation files to work, though neither should be violated if using the NPC rig from Greatness7:

  • All of the bones in base_anim.nif must be present. It may be wise to add tail and toe bones as in base_animkna.nif to prevent error messages for users with (modified) base_anim files that include beast race bones.
  • The animation file needs nodes named after each body part like those in the base_anim files. These nodes are represented as empty objects when imported into Blender and are used by Morrowind to determine where to place each body part mesh.

Bone groups

Bone groups include the lower body (root, base spine, legs, etc.), the upper body (spine1 and up, right arm, etc.) and the left arm (left clavicle, left forearm, etc.). They allow for multiple animation groups to be mixed and play at the same time. For example, the upper body and lower body are mixed when moving with one's hands in a spellcasting pose, the left arm is mixed with the upper and lower body when holding a torch or in an ashstorm, etc. This has less visible and unintended consequences, for instance getting back into melee range of an over-encumbered NPC can make them attack with their upper body while their lower body doesn't animate; attack animations between "hit" and "follow" use other lower body animations during some frames which is why combat animations can jitter.

Animation files with additional bones

In the unmodified vanilla engine, only the bones already present in base_anim.nif can be used in NPC animation files, but MCP's "Improved animation support" feature makes new bones usable as long as their name includes that of one of the original bones and the original bones are still present somewhere. The extra bones will behave as part of that original bone's group (lower body, upper body or left arm). OpenMW natively allows arbitrary bone names.

With this capability, it becomes possible to make races with body structures that are vastly different from those of the base_anim and base_animkna files. The Tsaesci are one example of this, with the legs of a normal race replaced with a serpentine tail. None of the vertex weights of the Tsaesci body parts rely on the leg and foot bones that must remain in the Tsaesci animation file, so these bones have no effect on the movement of the Tsaesci.

Applying animation files to the PC

LUA scripting with MWSE is required for the animations and skeleton of an animation file to be applied to the player character. At the time of writing, Tamriel_Data's LUA Addon does this if the PC is a plantigrade Khajiit race with a tail (e.g. ohmes-raht or suthay).

Head animations

Heads for Morrowind's characters rely on 3 shapekeys: The first is for the base, the second is for talking (where the mouth is open), and the third for blinking (where the eyes are closed).

Exporting head meshes

There is an important final step if exporting a head mesh: Since heads have text keys yet are controller animations, an adjustment needs to be made to the exported NIF. In NifSkope, find the NiGeomMorpherController node and change the flag from 8 to 12 (i.e. cycle to clamp). This allows Morrowind to control when the animations play, otherwise they will awkwardly loop in-game.

Head width

Heads (and hairs) will be affected by race modifiers, so they will often look thinner or wider in-game than their model really is. Increasing the weight of a race makes their heads wider, while increasing the height of race has an inverse effect and makes their heads thinner.

Heads with multiple shapes

Additional static shapes can be used for details such as piercings, but only the first NiTriShape can be animated with the Talk and Blink text keys. Head meshes also cannot contain any skinned meshes.

Miscellaneous tips and requirements

Armatures and parenting

When working in Blender, a skinned object must be the child of whatever skeleton that their armature modifier points to. Otherwise, crashes will occur in Morrowind and in the Construction Set.

Shape keys and skinning meshes

Meshes that rely on both vertex weights and shape keys will not work properly in Morrowind. To get around this, the part of a mesh using shape keys (often the head of a creature) should first be separated from those that are skinned. Next, an empty object should be created and have its parent set to the bone that the mesh would otherwise be skinned to. Making the separated mesh a child of that empty object will allow it to use those shape keys while still moving with the chosen bone. For examples, refer to the hunger and Tamriel_Data's devourer daedra.

Sharing Names

It is important to ensure that bones and objects do not share names, as this will result in errors (for OpenMW at least) and animations that do not work.

Maximum number of text keys

A single frame (or time) can't have more than 5 text keys and there can't be more than 6 different animation groups sharing any part of the animation - otherwise you get a "Too many shared anim groups" warning message.

KF: Sound

Keyframe text keys can use "sound:" directly with sound IDs. The IDs aren't hardcoded and can use any sound created in the CS as long as the ID doesn't contain whitespaces.

Animated Collision Meshes

Collision meshes can be animated, but they cannot be skinned. Therefore, one must animate the transformations of the collision mesh rather than rely on an armature for it.

Animated equipment

Controllers can be used in weapons and equipment with time keys that link them to character animations, but in the vanilla engine attack animations will be overridden by walk or run animations if the bearer is moving. As equipment animated like this relies on key times in base_anim, it will only be compatible with animation replacers that do respect the same time values as vanilla base_anim. Another issue for animated weapons is that if they're used by the player, a different animation file is used for first person perspective, and time keys are not the same as in third person.


Rotation Type and Translations Interpolation key types (in NiKeyframeController/NiKeyframeData):

Rotations should be linear (“LINEAR_KEY”). “When rotating objects or systems, please use a Linear Rotation Controller for the best and most accurate results. TCB & Smooth Rotation are supported but not suggested and may provide wacky results in some cases. Ever have trouble in 3dMax or MaxImmerse getting something to simply rotate 360* without stuttering at the end of its rotation? Use a Linear Rotation Controller.

Controller flags

See the NiBSAnimationNode Flags section in the Particle Effect Guidelines; relevant flags have the same meanings as for particles.


Note: The content below is largely untouched given the relative unfamiliarity of this page's current writer regarding Animkit.

Liztail's Animation Kit (MMH link, Nexus link) is a utility for both players and modders centered around modifying the NPC animation files. The sections below detail other main functions of the utility for modders.

Previously, users of Tamriel_Data would need to use Animkit to create a version of base_anim.nif with tail bones so that some of the new plantigrade Khajiit varieties would have tails as they should. However, this is no longer necessary with the addition of the epos_kha_upr_anim animation flies and the LUA Addon described above.


split_kf splits full animation xKF files into smaller single animation ones.

Note that there is a limitation with Split regarding multiple text keys. At worst, split can stop as soon as it finds a key with several lines that have different animation names and no longer exports any of the animations that come later in the file, without any error message. At best, split divides animations that share the same keys into several xKF animations, including frames on which one animation stops and another starts, so an animation file that is first split and then re-merged by Animkit can become much heavier with no added benefit.


merge_kf merges small, single-animation xKF files into big, multi-animation ones.

There are several limitations with Merge:

  • It doesn't support several animations with different names starting on the same frame; if there are more than one, you'll have to add them back to the text key in NifSkope.
  • It doesn't support scale keys and only supports linear controllers for translation and rotation.
  • Merge accepts only base_anim animation names for text keys, and they are case sensitive: Knockdown will be correctly found and merged, KnockDown will not.
  • Since only base_anim names are used, merge only supports NPC animations. If you want to merge animations from creatures that have the same skeleton as NPCs, you'll first have to adapt for case sensitive keys like KnockDown, and for animations that have names that don't exist for NPCs, like Attack, you'll have to at least temporarily rename the files to other NPC animation names. You may also need to check and rename the text keys inside the corresponding xKF file, and take into account that not all animations are Start and Stop – some have loops, NPC attacks have different keys, and so on.
  • Merge reorders the timeline and will probably change the order in which the bone keys are chained in the xKF. The different times may break compatibility with animated equipment.


preview_kf previews animations by applying each to a .nif file with a skeleton.

A limitation with Preview is that it creates one .nif for each animation in the xKF, even if you merge all animations into the same xKF first. It's only meant to be used to easily preview what each animation key looks like.

To trick Animkit into creating a single .nif instead of one .nif for each animation: open the merged xKF in NifSkope, click NiTextKeyExtraData, take the time from the last text key, and edit the second text key to have the time of the last text key. To fix that .nif in NifSkope: remove its NiTextKeyExtraData, open the unmodified merged xKF, expand NiTextKeyExtraData, remove the NiStringExtraData branch under it, copy the NiTextKeyExtraData, paste it into the previewed .nif and look at its number, click the root node (0 NiNode) and give that number in Extra Data.