Particle Effect Guidelines

Particles bring a lot pizzaz to the TES III world, being used for smoke, magic effects, etc. However, particles are also one of the most obscure parts of TES III assets. This page aims to collate useful information on the topic for asset developers.

Tutorials

The most up-to-date information and guides can be found on the Morrowind Modding Community #vfx channel.

• Advanced usage of particle effects and emitters by Kurpulio – an extensive (i.e. really long) video guide.

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. For 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 and more (in the Controller) of pre-calculated particles – the particles that were active at the time when the system was saved in the editor (which was 3ds Max during original Morrowind development).

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.

NIF Flags

NiBSAnimationNode and NiBSParticleNode

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).

For a fuller overview of the flags:

• 1: hidden (not rendered by default, may still be unhidden by a visibility controller)
• 2: triangle collision detection
• 4: bounding box collision detection (usefulness is unknown)
• 8: ignore skin influence (for particles this may be relevant for arrays using a TriShape as emitter instead of the usual NiNode)
• 16: not used in Vanilla files (apparently allows use of shape vertices as emitters for NiBSPArrayController at least in flag 24)
• 32: ignore parent animation (without this the animation will use keyframes from its parent node)
• 64: no randomness (several NiBSAnimationNode nodes will start at different times without this)
• 128: attach particles to parent (if the object's coordinates change, particles will move with it). See also the notes below.
• 256: unknown, only used on the particles emitter of smoke_green.nif

Some examples of how different flags are combined in the single flag float number:

42 = 32 + 8 + 2

96 = 64 + 32

106 = 64 + 32 + 8 + 2

Creatures and Flag 128

In the Vanilla engine, particles only get properly positioned on creatures if the particles node has the flag 128 or has a VisController. If you want particles to trail and don't give them flag 128 you should give them a VisController, otherwise without that flag the particles are positioned at the creature or levelled list's original position and will only appear on the creature if that original position is also in the field of view (for creatures placed by scripts in interiors, that position is 0,0,0 until the game is reloaded). For non-cycling particles, it happens for every new animation. Cycling particles like atronach body flames, if not hidden or left behind by the camera, can stay attached to the creature once they appear on it (or after reloading for creatures placed by scripts).

Particles in the creature model don't scale with the creature without this flag even after reloading.

Attaching particles with the flag 128 means they can't trail behind the creature when it moves. See also the note below in the Creatures section.

SetScale and Flag 128

If NiBSParticleNode doesn't have flag 128 and the scale of the object is changed inside the game, the particles won't be scaled until the game is reloaded, or never for creatures.

Even when using flag 128, if the object is made of more than particles it's not a good idea to make large scale changes in the game anyway. They will look bad since, in the original engine, the effect will be squared for particles compared to the rest of the object: fire will become too big for the shaft of a scaled up torch, or too small if scaled down.

Controller

• 0: cycle
• 2: reverse
• 4: clamp
• 8: active (cycle)
• 12: active (clamp)

In the Vanilla engine, particles can only cycle (flag 8) if the parent NiBSAnimationNode or NiBSParticleNode ignores parent animation (flag 32) for particle arrays, or is attached (flag 128). If parent animation isn't ignored, particle arrays won't be displayed for creatures if the controller doesn't have the "clamp" flag (12), even if they're attached.

Note that Vanilla models with such non-working particles also had the extra data Clamp = which is not taken by the engine. Fixed vanilla models are available

Creatures

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 is that 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 in-game 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 Construction Set 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 need flag 32 and a cycling Controller (flag 8). Such particles can, for example, be seen on the flame atronachs. 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, etc.). Thus, it 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.

Equipment

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 equipment 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 1st 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.

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 Construction Set.

Multiple Controllers

Each controller 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).

Combining Multiple Particle Effects In NifSkope

If you always experience an engine crash with a mesh after putting together several particle nodes, 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.)