3ds Max
The nif format was originally designed to replicate the data structure of MAX, and full capabilities for exporting nif files for Morrowind are for 3ds Max versions 3 to 5. Those versions of Max are outdated and no longer available. Max is no longer well documented for Morrowind in the english-speaking community, so don't choose this option if you aren't comfortable with figuring things out yourself.
If you do have access to Max 3 to 5, you can use the public version of Bethesda's own exporter for 3 or 4. The same official exporter works for Max 5 for models that do not require morph (using a morpher.dlm from MAX 4.2 allows exporting morph). An unofficial importer was available: NifPlugin v0.11 is the beta version from 2004, origin of later versions of MaxNifPlugin. Niftools' MaxNifPlugin for newer versions of 3ds Max is incomplete and abandoned but supports simple export features. Several other plugins and forks exist. Newer plugins meant for Skyrim may work to import Morrowind meshes.

• Beginners guide by Thanatos (PDF)
• Notes for Modmakers from Symphony team contains many notes on Max and modelling in general.
• Archived page for more information and tutorials from 2004 as well as some original max files from Bethesda.
• RX31 Animations Toolbox for Morrowind and Oblivion: user script tools for max 5

Like with Blender, there are things that can't be done by the exporters but can be done in NifSkope after exporting the model, for example copying particle animations into the XNIF file of an animated creature or activator.


 

 

Blender

2.82
Find Greatness7's new nif exporter here (beta version), for Blender 2.82. Has animation support.
If you get "ImportError: DLL load failed: The specified module could not be found." you may need to manually install the latest VC Redist.

2.78 - for non-animated - older

2.49 - for animation - older
Besides the new plugin for Blender 2.82, the last stable nif exporter that supported actor animations was for Blender 2.49b, an old version from 2009. Consider updating to 2.82. download and installation instructions for Blender 2.49b and nif plugin
Importing: default import settings. - use these settings for skinned animation
Exporting: export settings, select Morrowind in the list.
Limitations: Blender/Niftools isn't able to import and export everything properly even with the old version.
Expand for issues and solutions:

 

 

Other modelling programs
Because of preference or because the old version of Blender isn't user-friendly, you may want to work in another program first before transfering your model to Blender to export in the NIF format

• Wings3D (free): Wings 3D tutorial with RubberMan
• Maya had a old nif plugin but many features are unsupported
• Gmax is a limited version of Max 4.2 that can be used for simple meshes

 

 

NifSkope
Download link version 1.1.3
Basic use tutorial
Nifskope alchemy for Morrowind
For more advanced uses, Notes for Modmakers from Symphony team contains many notes on the nif format and modelling and much knowledge that can be applied in NifSkope.

Program version:
Use NifSkope 1.1.3 for Morrowind, that version works out of the box.
Later versions of NifSkope abandon the Morrowind renderer in favour of newer games like Fallout, which means graphic options like materials will not look the same as in the game; later versions can also crash or fail to load some meshes with animations or particles and fail to display skinned meshes; and their default settings export nif files that don't work with Morrowind. If you still want to use a later version of NifSkope, go to Options->Settings->NIF, set Version to 4.0.0.2, User Version to 11 and User Version 2 to 11.

Texture paths:
When changing or giving textures, NifSkope will by default give absolute paths, which won't work if users have Morrowind installed in a different folder. You should shorten to relative paths. For example if the full texture path is "C:\Program Files\Bethesda Softworks\Morrowind\Data Files\Textures\A_Bear_Boot2.dds", the relative path is "Textures\A_Bear_Boot2.dds". NifSkope will shorten new paths automatically for you if you go to Render->Settings...->Rendering->Add Folder and set the path of your Data Files folder.
Vanilla files omit the "Textures\" folder from texture paths, but the engine requires it if the texture is in a subfolder.

Common uses of NifSkope: (see Nifskope alchemy for Morrowind for more)

• give "no collision" property: right click, Block->Insert->NiStringExtraData (not to confuse with NiStringsExtraData), give it the name NC and look at its node number, click the top-level node 0, find "Extra Data" and double-click on its Value field, give it the node number of the NC you just created.
• fix broken/visible collision after export: after exporting with old Blender, find the "NiNode" called "collision", change "NiNode" to "RootCollisionNode", names are not needed. You can optionally first click Flags and tick hidden (before changing the node, or add 1 to the Flags value anytime) for NifSkope to hide it when not viewing hidden objects.
• fix wrong ingame position, rotation or scale (when changes were made in blender or nifskope that do not appear in the game): right click the node, Transform->Apply
• copying and pasting nodes between different files works as long as nifskope stays open, nodes must be clicked in the Block List
• deleting nodes or branches from a file: Ctrl + Delete in Block List to remove a node (AND its children, without spilling them into the rest of the file)
• preview textures by dragging the files onto meshes in the 3D window (works if the trishape is clickable - being transparent from alpha property make meshes not clickable)

New textures:
New texture nodes created in NifSkope 1.1.3 with right click->Add... have the wrong scaling type by default; for all texture types (base, detail...) interpolation mode must be changed from FILTER_NEAREST_MIPNEAREST to TRILERP to prevent pixellation (interpolation is for upscaled texture display when an object is viewed at a distance that isn't optimal for any of its mipmaps)
Flags:
Some properties are stored in a "Flags" value, which can be the sum of several values. For instance collision nodes have the value 3, which is 1 (hidden) + 2 (triangle collision). The values have different meanings depending on the node type and NifSkope gives an interface for some of them when clicking the flag icon, but not for NiBSAnimationNode which you have to edit directly (see "NiBSAnimationNode flags" in animation basics below).
NiStringExtraData:
Linked to the root node 0, stores the following properties. You probably won't need several of these 4 properties at the same time, but you can chain more than one by linking in the "Next Extra Data" value of the NiStringExtraData.
"NC" (no collision, "NCO" is the same as "NC"),
"MRK" (make the mesh invisible in the game but visible in the editor; the name of the NiTriShape must start with "Tri EditorMarker"; example in EditorMarker.nif),
"RCN" (for more reliable collision of moving objects, example in in_dagoth_bridge00.nif),
"sgoKeep" (do not cull empty hierarchies, only useful for skeleton nodes, nif "bones", needed on particle effects and their emitters).
Changing scale:
When changing the scale of a mesh in NifSkope, the center and radius of the mesh in NiTriShapeData must be updated to avoid culling errors (like the mesh disappearing near the edge of the screen). Although NifSkope does have a function for this (right click>Mesh>Update Center/Radius), it gives inaccurate results.
KF files:
You can't use "attach kf" in NifSkope Spells for Morrowind kf files. A slow manual workaround is to copy each NiKeyframeController (with only NiKeyframeData under it) into its bones in the NIF file.

Particle effects:
An extensive guide to advanced usage of particle effects and emitters, by Kurpulio, can be found at https://www.nexusmods.com/morrowind/mods/48623

 

 

Texturing
Format:
- DDS is the standard format for Morrowind. Use DXT1 compression if the texture has no alpha channels (has no transparency), use DXT5 if it has varying alpha channels. See this forum link about texture formats and optimisation.
Exporting to DDS is built-in with GIMP version 2.10, and the plugin is also available for the older version 2.8 (download, install). Usually, don't load mipmaps when importing and use "Generate mipmaps" when exporting. You can leave the Mipmap Options to default for Morrowind. In addition, if you have textures with alpha testing similar to tree leaves, you can try to tick "Preserve alpha test coverge" for better results. (Mimapping, also called "pyramidal filtering" or "trilinear interpolation", stores copies of the texture in levels a quarter the size of the prior level, will improve texture aliasing and should be used in almost all cases (for base textures only: detail maps, bump maps... won't use the mipmaps); mipmaps increase VRAM use by a factor of 1.3.)
- TGA is supported (32 or 24 bits, not 16) but is several times larger. Usually not preferred, might be used for more precise alpha channels (where smooth alpha transitions are needed, like halo effects for magic spells) or greater image quality (images in books).
- BMP is supported but has no advantages and shouldn't be used.
If several formats are available, the game will give priority to DDS, then TGA, then BMP, regardless of the extension of the texture specified in nif files and regardless of timestamps. If the same texture exists both in BSA archives and in the textures folder, priority is by timestamp.
Resolution:
Resolution must be by powers of 2, square or rectangle (2x2, 4x4, 8x8, ..., 256x256, 512x512... or any rectangle combination, like 1024x256). Textures that have the same dimensions are more quickly interchanged by VRAM, having a lot of textures with widely varying sizes defeats this; aspect ratios over 8:1 can fragment VRAM and are not recommended, unless required for atlasing (see next).
Keep your uncompressed source textures so you can export higher resolutions later. If you're using vanilla textures as a base, you can sometimes find an uncompressed BMP in the construction set CD, or in the loose data files of the GOG version; if you don't have them you may find some or all of these files in uncompressed dds here (nexus link) or here (mediafire)
Atlasing:
Meshes should use a single shape with a single texture for better performance. See Project Atlas: a texture atlas (also called a sprite sheet) is an image containing a collection of smaller images, usually packed together to reduce the atlas size. Vanilla Morrowind has objects split into different shapes each using its own unique texture. This is bad for performance and is one of the game's primary FPS bottlenecks. More comments on atlasing. For compatibility with atlasing, individual trishape UVs should not tile in both horizontal and vertical directions. In an atlased texture, different parts should be separated by >4 pixels to avoid graphical issues with margins being blended in the downscaled mipmaps.
Naming:
Texture names aren't generally subjected to the same limit (32 character including extension and folders) as meshes, but like meshes, texture names that are too similar to each other will create hash map collision in a bsa. An object using the asset must be loaded and displayed in the current cell (or in preview mode in the CS) for the engine to give the error: "Hash map collision between two files" "Collision between ...". A BSA hash checker (java). See BSA format document on its hash algorithms.
Miscellaneous:
Glow maps: Glow map tutorial - Another glow map tutorial
Dark maps, Detail maps, Decal maps: 4.0.0.2 Nif Documentation. Gloss and Bump maps are not supported in vanilla Morrowind.
To avoid Z-fighting or create easy texture variants, textures can be overlayed over surfaces in Decal slots (an example mesh in Tamriel_Data: tr\d\tr_in_impsmall_jail_tr.nif)
Transparency: NiAlphaProperty flags, usual values are 237 or 4845. Alpha blending parameters use a similar format to Oblivion and Skyrim, some of the same tips apply. See What is color blending?
Double-sided UV: use NiStencilProperty
Possible sources for textures: Archive textures, Spiral graphics (seamless),
 

 

Rigging

•   Rigging Character Assets For Morrowind tutorial for Blender 2.78+

Rigging, skinning or physiquing is making objects animate with bones. Used for creatures and equipment. There is skinned animation (a shape can be influenced by several bones and can be deformed) and segmented animation (the shape moves with a single bone and isn't deformed). Vanilla Morrowind notably uses skinned meshes for objects that get deformed when the player moves: chests, robes, skirts, gloves... Without skinning, segmented animation is also used: in the CS, body parts and equipment can associate separate meshes to body slots (example: pants segmented in Groin, Ankle, Leg and Knee). Equipment body parts with left and right sides only need a "right side" bodypart, the game mirrors the mesh to the left.

Equipment
To be visible when worn in the vanilla engine, equipment needs:
- to be a visible object type (not an amulet, ring or belt)
- to take at least one visible equipment slot, which normally means making a body part invisible (example: open helms replace the "hair" slot, closed helms replace the "head" slot). More on slots:
All equipment slots make their corresponding body part invisible when equipped except both pauldron slots (which is why old mods often use pauldrons as a hack to display objects like quivers on NPCs; standard equipment in the game however uses both a "pauldron" slot and an "upper arm" slot for pauldrons, and sometimes "forearm" as well). A couple slots overwrite and hide other slots (the "skirt" slot overwrites the "groin" and "upper leg" slots, the "head" slot overwrites the "hair" slot) and some object types will hide body parts regardless of the slots they use (a robe object always makes knees, upper legs, groin, chest, upper arms and forearm body parts invisible; likewise a skirt object always makes upper legs invisible, even if it itself includes body parts linked to the upper leg slots). Other body parts can also be hidden by the same object by replacing their slots with nothing (for example to avoid clipping; robes replace the "chest" part, and hide the "ankle" parts). Thanks to skinning, it's possible to use one visible slot and have part of the mesh be rigged to follow another body part entirely, the same way robes follow the whole body (example: replacing the "neck" with a scarf that also includes a mask on the face is practically the only way to create a headwear "helm" that doesn't hide hair in the vanilla engine...), however there are priorities between object types for slots (... in the same example, chest objects have priority over head objects for the neck slot: if a chest object with a neck part like a scarf is worn together with a headwear object with a neck part, the headwear's neck part won't be displayed).

When making skinned meshes for other body parts, the body slot used by the "Body Part" object in the CS matters. Example: to make skinned equipment based on the Neck slot, the main node under Bip01 must be named "Tri Neck", and each NiTriShape in it named "Tri Neck 0", "Tri Neck 1"..., numbered starting from 0 and without skipping any numbers. When a mesh is skinned to Bip01, no shapes will be rendered outside of those that are parented to Bip01 and that follow the above name convention. Equipment can only be skinned to bones found in the NPC's animation file. If equipment has bones of its own that the NPC doesn't have, meshes can be parented to them (segmented animation), but there can't be any skinning in the file or they won't be rendered.

In Blender skinning is applied with the Weight Painting mode. Both the new and old plugins for Blender (2.49b and 2.78/2.79) can export skinned meshes. Each vertex can have influence from no more than 4 bones.

Creatures
When loading a rigged mesh, the engine automatically creates partitions of TriShapes so that each partition has influence from no more than 4 bones. When doing this, the engine doesn't detect if different vertices or edges share the same position, and may leave them with influences from different bones. Since shapes are split where there are UV seams (resulting in separate vertices that share the same position), the whole process can result in creatures with mesh seams where there are UV seams. The issue can be fixed with careful rigging, using Blender to clean insignificant weights, and using its weight painting option Normalize All with a limit of 4 or less.

 

 

Animation basics
Morrowind uses two main types of animation: keyframes and controllers.

• Keyframe animation is either started by scripts (for ACTIvator, LIGHT and DOOR type objects only; example: "OutsideBanner") or called in a hardcoded manner by the engine (NPCs and creatures, with fixed animation names like "idle2", and the head body part for blinking and speaking). Keyframe animation uses three files: NIF, xNIF and xKF (example: "Furn_banner_tavern_01.nif", "xFurn_banner_tavern_01.nif" and "xFurn_banner_tavern_01.kf"). The NIF file can contain both geometry and animation and is used exclusively by the Construction Set (as far as the game is concerned it can technically be reduced to a skeleton with no animations), while the xNIF and xKF files contain only geometry and only keyframe animations respectively and are used by the game. Exceptions: head body parts have text keys but only use the NIF file, and xNIF files can also contain additional animations (examples: NiVisController XDremora.nif, NiBSParticleNode in XKwama Forager.nif).
• Other controller animations run on their own based on time and only need the NIF file. Examples include animated particles (Ex_waterfall_mist_01.nif), UV as in animated texture (Ex_Vivec_waterfall_01.nif), geometry (NiMorpherController), alpha (magic_hit_Levitate.nif - note: such magic effects used by the engine work in NiNode, but for objects they need NiBSAnimationNode with certain flag values or 32, see "NiBSAnimationNode flags" below)...

NPCs: Animation files can be attached to individual NPCs and overwrite only existing animation types (described here), and animation types that aren't overwritten are kept from base_anim (example: "breton dancer girl").

Animations are sampled at 15 FPS, the smallest time between two keys is 0.0667s. In Blender, the default frame number is the time key multiplied by 30, plus 1.

Blender animation tutorials

• NPC Animation tutorial and resource for Blender 2.49b
• Head animation tutorial
• Creature animation tutorial
• Bow animation tutorial
• see animation sections below for more Blender tips

 
3ds Max animation tutorials

• Animated textures and particle effects (in same guide by Thanatos) PDF link
• Morrowind Animation Tutorial by DarkIllusion PDF link
• Animating faces (Rhedd archived)
• Archived thread on MWMM
• Archived page from ThanosTower, including blank animation resources from Bethesda

 

 

Animkit
Liztail's Animation Kit (MMH link, nexus link) is a utility for both players and modders centered around modifying the NPC animation files.
Besides modding tail bones, the main functions for modders are:

• split_kf: Split full animation KF files into smaller single animation ones. Limitations with Split:

- multiple text keys: at worst split can stop as soon as it finds a key with several lines that have different anim 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 kf animations, including frames on which one animation stops and another starts, so an animation file that is split then re-merged by animkit can become much heavier with no added benefit.
- files exported by the blender 2.49 plugin can't be split by animkit.

• merge_kf: Merge small single animation KF files into big multi-animation ones. Limitations with Merge:

- doesn't support several animations with different names starting on same frame; if there are more than one, you'll have to add them back to the text key in nifskope.
- 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 base_anim names only 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 anims 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 kf file, and take into account that not all animations are "Start" and "Stop", some have loops, NPC attacks have different keys...
- merge reorders the timeline and will probably change the order in which the bone keys are chained in the kf. The different times may break compatibility with animated equipment.

• preview_kf: Preview animations by applying each to a nif file with a skeleton. Limitations with Preview:

- the rigged nif can't be directly imported by the blender 2.49b plugin
- creates one nif for each animation in the kf, even if you merge all animations into the same kf 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 kf in NifSkope, click NiTextKeyExtraData, take the time from the last textkey, and edit the second text key to have the time of the last textkey. To fix that nif in NifSkope: remove its NiTextKeyExtraData, open the unmodified merged kf, 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.


 

 

More on Animation


Combining separate animations:
Morrowind animations are all in a single file and that's very inconvenient to work with. To separate and combine KF files only, see AnimKit.
To use animation windows like the Action editor or NLA editor in Blender with those very long files without lagging to seconds per frame, hide some of the bones to hide their animation channels. Consider using bone layers for this.
For Blender 2.49, to separate and combine animations from different files, use File>Append or Link>(click .blend file)>Action>(DefaultAction or name of the action containing animations), then use the Action Editor to browse for the new appended action for all bones; for the root node do the same with File>Append or Link>(click .blend file)>Ipo>(Ipo or name of the curve containing the root animation) then use the Ipo editor with Object mode. To copy or paste from one action to another, first select the bones in pose mode or channels in the editor: picture.


Importing Bethesda's animated creatures into Blender 2.49b:
First try these import settings.
If that still doesn't work, the easiest way is to combine the old plugin's ability to work with animations with the new plugin's ability to import a rigged mesh, and using NifSkope to work between the two. Example:
1. Import the creature's original XNIF file in Blender 2.78+ with the new plugin, then export it again. Now you have a rigged mesh and skeleton you can import into Blender 2.49b.
2. Combining the animation:
- Append method: For some creatures this won't work perfectly or the root node's action could be lost and need to be restored later with NifSkope. Import the creature's original NIF file in Blender 2.49b. Depending on import settings the armature and rigging will be wrong, but nevermind that. Save it as a blender file. Import the XNIF that you exported before from the new Blender, into Blender 2.49b. Use the File>Append method described earlier to take the animation from the blender file you've saved.
- Rig replacement method: using NifSkope, delete the rigged meshes from the creature's original NIF file, and in their place copy paste the rigged meshes from the XNIF file exported with Blender 2.78. Import the new file into Blender 2.49b.
For some creatures if neither of these methods work, pure skeleton method: delete the rigged meshes from the creature's original NIF file using NifSkope, import the skeleton only into Blender 2.49b to work on the animation (you still need to have at least one mesh parented to the skeleton for the plugin to import the nodes as bones), then when you're done with animation work, export the animated skeleton and paste the rigged mesh you want into the file with NifSkope. An alternative is to delete only the skinning data nodes from the meshes before importing into Blender, and either re-rigging the creature for good or just as a temporary rig to work with.


Editing head shapes in Blender:
To repeat the same edits in base, talk and blink shapes, use the shortcut W in Edit mode to get the options Blend from shape or Propagate to all shapes.

Head width:
Heads and hair will be affected by race modifiers, so they will often look thinner or wider in the game/CS than their model really is. Examples with the default vanilla modifiers (see Weight at the bottom of the table): Imperial and Nord males will be stretched 25% wider, whereas Breton and Dark Elf females will be 10% thinner.

Head with multiple shapes:
Additional static shapes can be used, but only the first shape can be animated with Talk and Blink. More animated shapes won't sync with these animation keys and will instead use the NPC's current base anim times if they don't ignore parent animation. If the mesh contains any skinned Tri Head shapes it can't be animated.


Applying animations from a KF file to a skeleton:
Neither NifSkope nor the Blender 2.49 plugin can import Morrowind KF animations into a NIF file. With NifSkope, a slow manual workaround is to copy each NiKeyframeController (with only NiKeyframeData under it) into its bones in the NIF file.


KF: Editing keyframe strings in Nifskope:
When editing text values, pressing Enter applies the change and closes the text box which doesn't let you jump a line. To create line returns, you can press Shift+Enter.

KF: Soundgen
After editing kf keys with line returns in nifskope, keys with several animation group lines beginning with a "soundgen" line may give animation group errors (Bad note string "Sound...). To fix that, move the soundgen line after the animation group lines in that key.

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.

KF: Maximum combined keys
A kf entry can't have more than 5 anim text keys for the same time after sampling at 15 fps (less than 0.0667s difference is not enough) 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.

NPC animation file: X.NIF
When giving a NPC a special animation file, the X.NIF file must contain all the bones used in the "base_anim.NIF" files, the base files (NIF, X.NIF, X.KF) used for all NPC animations. Add tail and toe bones to avoid error messages for users with modified base anim files that include beast bones.
The X.NIF file needs nodes for each body slot: the "Bip01 Neck" node is the bone itself that is needed for animation and skinning, but the "Neck" node is the one that determines where the Neck body slot will be rendered.
"Shield Bone" coordinates give the rotation, position and scale of the shield. "Weapon Bone" gives the rotation, position and scale of the weapon (unlike Shield Bone, Weapon Bone properties are overwritten by the vanilla KF animation file).

Player animation
Although the "player" actor can be given an animation file (in the animation property of the NPC_ record with the ID "player") it reportedly works only if the player's race is not changed during character generation.

Animation types
Animation names are hardcoded (described here). Melee weapon animations (1hand, 2hand, 2close and 2wide) have their own walk or run animations, but bow animations for example use the 1h animations for movement.

NPC animation body groups
Animation groups of bones are lower body (root, lower spine, legs), upper body (spine1 and up) and left arm. Animations can be mixed for the player but also for NPCs: left arm is mixed for torch and ashstorm animations; upper and lower body are mixed when moving with hands in a spellcasting pose... This has less visible and unintended consequences, for instance getting back in melee attack range of an over encumbered NPC can make it attack with its upper body while its lower body doesn't animate; attack animations between "hit" and "follow" use other lower body animations during some frames which is why combat animations jitter...

Extra NPC bones
In the unmodified vanilla engine, NPC bone names are hardcoded for animation: it's possible to use other bone names in the XNIF file to change the translations and rotations of hardcoded bones, but only bones with known names will take animations from the KF file and allow skinned meshes to animate. Bone names recognised by the engine are (from MCP doc, add "Bip01 " before each name):
Lower body group - Pelvis, L Thigh, L Calf, L Foot, L Toe0, R Thigh, R Calf, R Foot, R Toe0, MRT, Tail
Upper body group - Spine1, Spine2, Neck, Head, R Clavicle, R UpperArm, R Forearm, R Hand, R Finger0, R Finger1, R Finger2, R Finger3, R Finger4, Weapon Bone
Left arm group - L Clavicle, L UpperArm, L Forearm, L Hand, L Finger0, L Finger1, L Finger2, L Finger3, L Finger4, Shield Bone
The "Dummy<digit x 2>" node name pattern has a special use in the engine only for mutiple-effect target spells, in e/vfx_pattern02.nif .. e/vfx_pattern08.nif used by the Weapon IDs VFX_Multiple2 .. VFX_Multiple8.

Extra NPC bones: MCP
With MCP's optional feature "improved animation support", arbitrary bone names are possible for animation if they include the name of one of the original bones, and they'll behave as part of that bone's group (lower body, upper body or left arm). OpenMW natively allows arbitrary bone names.

Animated equipment:
Controllers can be used in weapons and equipment with time keys that link them to NPC/player 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.

Root bone:
Any animations of the root bone change the actor's coordinates in the game. For creatures or NPC animations the names of nodes matter. The root node must be called by a specific name for movement to work in the game ("Root Bone" or "Bip01" work for creatures). To move the root node in blender (for walking, running) select the armature in object mode.

Root bone: Minimum movement
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 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 in combat stance which only the player uses by default).

Static NPCs:
For static corpse or mannequin animations in the vanilla engine the NPC animation file can technically be NIF only, but if xNIF and xKF files are missing animation types not included in the NIF will be ignored and not taken from base_anim.

Rotations:
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 "NiBSAnimationNode flags" below in the particles section: relevant flags have the same meanings as for particles.
 

 

Particle effects


Particle systems
Particle systems are generally made of two parts:
- particles that will be generated coming from the emitter (with the emission settings in the Controller)
- pre-calculated particles, with data both in the Controller and in the "Data" type node (like NiRotatingParticlesData)
The pre-calculated particles are needed so the system doesn't start from nothing. Example: when a fire is first rendered, like when entering a cell, if there were only new generated particles, there would be no fire at first and it would progressively appear out of the emitter; instead, the pre-calculated particles are already rendered from the beginning, and by the time those have faded, enough new generated particles will have come from the emitter in a seamless cycle. The nif file has data for position, size (in the Data node), and lifetime, velocity...(in the Controller) of pre-calculated particles (the particles that were active at the time when the system was saved in Max),
The number of pre-calculated particles is defined by "Num active" in the Data node ("Num valid" in the Controller). "Num Particles" still defines the maximum number of new generated particles that can exist at a time - the Controller will not emit more particles until one expires. The individual data of non-active particles, like their positions, are useless in the game (they will come from the emitter anyway) and simply increase nif size, but they are necessary to increase the total number of particles. Usually you won't need a lot more total particles than Particle Lifetime * Emit Rate: if you emit 10 particles per second and they each live 1 second, only 10 particles need to exist at a time. Adjust on average with more particles if lifetime is random.
For cycling particles: the active pre-calculated particles appear when the model is first rendered if the Controller's "Start Time" is 0, regardless of the "Emit Start Time".

NiBSAnimationNode flags:
NiBSParticleNode flags:
Animation properties are stored in the flags value, often 42 as commented by NifSkope. Value 32 (included in 42) is often needed for objects to animate, with exceptions for creatures or animated equipment worn by the player. Continuous creature effects should have 32 included in the flags of the NiBSParticleNode and be cycled (Controller's flag = 8); effects that synchronise with a creature's animation should have 128, and NOT 32, included in the flags of the NiBSParticleNode and should be clamped (Controller's flag = 12). Expand to see more flags:

Controller flags:

Creatures with trailing particles
- Trailing particles must not have the attach flag, 128. In the vanilla engine trailing particles on a creature should have a VisController under them, even one that technically does nothing, to update their position. The reason why is, there is a visual bug without flag 128: particles are rendered at the creature's original position and stay there until they've been looked at. When a creature is created ingame by a script, the particles aren't displayed until the game is saved and loaded or, in interiors, until the player looks towards coordinates 0,0,0 where the particles are placed (but when the cycle is over, the particles will be back at 0,0,0 again). When a creature is placed in the CS or by a levelled list, the same issue happens every time non-cycling particles run if the creature's original position isn't in the field of view. For constantly cycling particles, the same issue also happens if the creature's original position never came in the field of view, or if their visibility ever gets turned off, or if the creature was left behind then followed without the player looking back at where the particles were left.
- Constant trailing particles like the flame atronach's need flag 32 and a cycling Controller (flag 8). Since flag 32 means the particles ignore parent animation, they can't be synchronised with the creature's animation using the Controller's Emit Start and Emit Stop times; instead you should use a visibility controller on the emitter to control when they start and stop, because the emitter can inherit time from the parent even if the particles node doesn't. The emitter won't emit particles while it's not visible, and particles that are already emitted won't be hidden when the emitter becomes invisible.

Creatures with particles that persist between animations
Particles without flag 32 get reset (or have their lifetime skip ahead) between animation cycles or when the parent animation is interrupted, which happens frequently (attack animations interrupted by moving, idles interrupted when combat starts...) and won't look good if the particles suddenly stop being shown before they've had time to fade. To have particles that persist between animation cycles, you should use cycling particles and unhide the emitter as above, with the exception that flag 128 can also be used (128 + 32 = 160) if you don't need them to trail.

Particles LOD
To apply LOD to particles, both the emitter and particles node should be parented to a NiLODNode separately.
When using LOD for anything, the NiLODNode should not be the root node or it will crash the CS.

Multiple controllers
Each controllers should be a unique node and have its own node number. If an identical controller is needed on several nodes, the controller node should be duplicated. It's technically possible to link the same controller under several nodes, like with other node types, but this shouldn't be done with controllers (for instance a VisController used twice can fail for its duration just after being loaded or make its target invisible in menumode like when the inventory is opened).

Particles on body equipment:
For NPC equipment, particles can be used on non-skinned files only, like weapons or any "body parts" that do not get deformed with the base_anim body (note that equiment can use a body slot with a skinned mesh and another body slot with a non-skinned mesh that has particles). Particle emitters on skinned NPC body, clothing or armor are not possible with the particle system of Morrowind because skinned meshes only render the trishape nodes that follow the body slot's name pattern and non-trishape nodes are ignored. No workaround exists before the Oblivion particle system.

Particles on weapons:
Particles can't be synchronised between 1rst and 3rd person camera modes, because there is a separate weapon rendered for each camera mode, each with its own timeline. A weapon is rendered for the first time for the current camera mode when it is drawn, and for the other camera mode when first switching camera. Time starts when it is first rendered and only progresses for the current camera mode: if switching to 1st person, the 3rd person weapon's time is on hold (this is noticeable with particles). When a weapon is replaced with another, or when it is sheathed (by exiting "drawn weapon" pose or by entering spellcasting pose), the rendered weapons of both camera modes at once are cleared. They persist through cell changes, but loading a save of course renders new weapons.

Combining multiple particle effects in NifSkope:
If you always experience an engine crash with a mesh after putting together several particle nodes without Max, especially by duplicating them in NifSkope, you'll need to change vertex IDs in the controller's active particles. Except for 0, vertex ID values used several times by active particles in a nif file seem to make the game crash when trying to display the mesh. "Unknown Short" values that come before the ID may have the same issue. (Active particles are the first particles in the list, for instance if NifSkope shows 30 for "Num Particles" and 17 for "Num Valid" then only the first 17 particles count.)

More about particle effects in Nifskope:
An extensive guide to advanced usage of particle effects and emitters, by Kurpulio, can be found at https://www.nexusmods.com/morrowind/mods/48623