Now we're playing with particles![edit | edit source]

Introduction[edit | edit source]

Particles are a special type used in creating a number of different types of effects. Smoke, magic sparkles, sparking fields of color, wobbling fog, the list goes on. Each particle is an instanced plane-shape displaying a specified image. Particles are birthed from a given location, and can move around based on a series of modifiers and controllers to achieve the effect you want. This guide details the ins and outs of all the particle nodes, emitters, controllers and modifiers used in their creation. The following is for working with NIPSysParticleSystem, .nif version 20.0.0.5, and were tested entirely on Oblivion, by Bethesda Softworks. My descriptions are for working with these systems in NifSkope, which is currently at version 0.9.8 at the time of this writing.

I've only had a few days of "serious" play with particles, and a majority of that was while writing this document. I (throttlekitty) have never created particles in another 3d app, where a more appropriate user interface / display is available; I've only made them via NifSkope, so my terminology comes from niflib / Oblivions Scene Graph. In short, I am no expert at creating particle effects, but after writing this guide, I can say that I can alter most of the settings quite predictably. Woo crash course!

The Oblivion CS also renders particles a smidgen differently than the game engine, but you can get an easy estimate. The only Modifier it does differently, is BombModifier, and it seemed to be more of a refresh/update type of thing, the basic shape of my effects were still present.

For testing, I just keep a cell handy with my particle thingy in it, and use the CS to preview it. Hitting the Havok toggle button from the CS icon menu will display the animation. Each time I save my file, I hit "F5" to refresh the model, and give the havok button a tap to restart the animation to see the changes I made. Be sure to have the render view as the active window when you hit F5.

If you're ever curious how something should be set up, Use File> "XML Checker" in NifSkope. Set the dir you unpacked your meshes to, uncheck "Report Errors Only", "threads 1", and hit Block Match. Then select the node type you wish to search for, and hit Run. Any files it found that use the selected node are listed, and are hyperlinked to open in a new NifSkope window.

The Basic Setup[edit | edit source]

In most cases, you want a secondary NiNode attached to the root node. Use this for storing Gravity or Drag nodes or Particle "Emitter" Nodes, name it as you please, but some official files follow the name with "NonAccum" which I don't have a full grasp on.

Now, attach a NiNode to your secondary one (So it will be third in heirarchy from root), it will have a name link with your ParticleSystem node. If you will be naming the ParticleSystem "SparkliesSmall" Name this Node "SparkliesSmall-Emitter" Many particles are done on billboards, you can attach an ExtraData to this node with the StringData of "\r\n\zMode10" to make the node a billboard. Also, you don't want artifacts on your particles. Attach a ZBufferProperty to this node, use Flags=13 / Test_less_equal. And ParticleSystem goes into the Children section. should look like this now:

0 NiNode (root)
-1 BSXFlags (BSX)       <--Don't forget to enable animation here.
-2 Trishapes (or whatever else you may already have here.)
-3 NiNode (my effects)  <--I sometimes refer to this as the "secondary" or "container" node.
--4 NiNode (SparkliesSmall-Emitter)
---5 StringExtraData (UPB)  (has the string "\r\nzMode10, to make the emitter node a billboard)
---6 ZbufferProperty <--The parent node (and children) will share this Property to prevent drawing issues
---7 ParticleSystem (SparkliesSmall)
--8 NiNode (mistBigEmitter)   <--I have a second particle effect also linked to the "secondary" node.
---9 StringExtraData (UPB)  <--again with the billboarding
---10 ZbufferProperty  <--same deal with zbufferproperty
---11 ParticleSystem (mistBig)  <--The second particle system.

ParticleSystem[edit | edit source]

So now we have a ParticleSystem node, it functions just like any other, except that it triggers the game to start a particle stream here. "Controller" is where you link your first controller, discussed below. "Flags" should be set to 14.

Properties: same ol' array of properties here. Generally, you want to use Material, Texture, Vertex Color, and Alpha for a proper setup. The First three are important if you want the particles to render. We already set ZBufferProperty to the previous node, so we don't need to apply it again here. Note also that while you *can* use a normal map with your textures, it's generally not needed or noticable, and likely to be a bump in performance. I also haven't tried it, but you also may be able to attach a Controller to Alpha, Material or Texturing Properties, for further effect. Flickering the Alpha value of an alpha value over time, for example.

Data: For linking in a PSysData block, which is fairly similar to a TriShapeData. I'll go over this node further down.

World Space set to Yes will spawn particles in world space, and their translation/rotations are in world space. "World Space" set to No spawns particles in Object Space, and their translation/rotations are in object space.

 This second option means that particles will move with an object when it does.   (you may need to pick up an updated NifSkope or nif.xml version from the NifTools website to see this option as something other than "Unknown Bool")

Modifiers: This array is for listing the Modifers the ParticleSystem uses, and in which order. Note that NifSkope may display the modifiers in another order if their Node Numbers are misaligned. (You can always use CTRL-UP/DWN to reorder them- keep it clean!)

PSysData[edit | edit source]

This contains data for the particle stream to use, and how many points the Emitter has to emit from. It's mostly placeholder data, from what I can tell.

Num Vertices: Governs how many entries to put in all the arrays, If you change this number, update all the arrays in PSysData.

Vertices: The "XYZ" for each point, they should all be zeroed out.

Sizes: Seems to always be 1, nifskope will populate new entries here with 0, I had a few files that acted funny until I made them 1s, however.

Unknown Floats 5: At this time, I don't know any better than Niflib does.

=Vertex Colors, Unknown Floats 1, and Unknown Floats 6: Just leave'em.

Controllers[edit | edit source]

When copying particles from another file that were "Controller Managed" - That their attributes were controlled by a NiControllerManager earlier in the .nif:

The controllers attached to the particle system need to be changed from "Blend" to "vanilla", and in some cases, need corresponding "data" types attached to them. For example, PsysUpdateController has both a float and bool interpolator. The float interpolator doesn't need keys (but it might work if you need it to). The BlendInterpolator needs to have a BoolData attached, with keys inside it.

Controllers state which modifier they are working for via "Modifier Name", and this data is explicit, so copy/paste.

Controller Flags: Modifier controllers governed by a larger ControllerManager should be set to Active/Clamp. Controllers for an "always on" situation should all be set to Active/Cycle, except for PSysUpdateController, which should ALWAYS be Active/Clamp.

Controllers can run in a large chain, via the "Next Controller" value. Simply enter the node number for the next controller you wish to link. The LAST two in the chain should ALWAYS be: PsysEmitterController>PSysUpdateController. I don't believe that order of other controllers matters.

Controller and Modifier Targets should always point back to the PSysParticleSystem they are a part of.

Keep in mind that all the controllers and modifers all interact together, you may need to go back and forth between the same two or thee values before you hit the sweet spot you're aiming for. Sometimes, what seems like a minor change will have a major impact in how the particles act.

Here's a rundown of the controllers I have seen, then we'll go over the Emitters and Modifers.

PSysController[edit | edit source]

Most every particle stream has one. Define start/stop times as usual.

Modifer Name: Usually its the name of the Emitter- Box, Sphere, Mesh, etc.

Interpolator: Give it a FloatInterpolator, where "Float Value" is the number of particles to spawn at any given time.

IMPORTANT! So I'll repeat it. PSysController>FloatInterpolator controls how many particles are active at a time!

Just remember that your particles will be part of a larger scene in the game, and can be an impact on game performacne. More Particles=Less FPS, nobody really wants a shiny sword with 15k particles shooting out the back, but it sure is something to look at :)

Visibility ControllerDefines the on/offness of the emitter. Takes a BoolInterpolator>BoolData, with "UKNOWN_KEYS". The minimum Number of keys is two. One for start time, one for stop time. If you are doing an "Always On" effect, set both values to 1.

PsysUpdateController: Seems to be the final controller in the chain, I only ever see it with: Active/Clamp, Frequency=1, and Target=(particlesystem)

PSysEmitterSpeedController: Governs the speed of birthed particle travel over time. Takes a FloatInterpolator>FloatData, with Quadratic Keys. It is directed to the Emitter object via "Modifer Name". This type of controller corresponds to the "Speed" value of the Emitter types.

FloatInterpolators "Float Value" eludes me a bit; Values for this controller are very dependant on how the modifers are set to work, and with my test files, I cannot see any difference in changing this value. It may reflect the value of the first key in the following FloatData.

-So, with FloatData, Time is keyframe time, Forward/Backward aren't likely used, since this is a linear sweep. Value is for the "Speed" of the controller: For example, the distance at which particles will travel towards a DragModifier.

PSysEmitter Declination / DeclinationVar / InitialRadius / LifeSpan Controllers: I haven't toyed with them personally, but they will all be pointed to the Emitter object, and work similar to the EmitterSpeedController. Each of them have corresponding entries in the Emitter types, and all take FloatInterpolator>FloatData. See PSysEmitterSpeedController above.

PSysGravityStrengthCtlr: Takes a FloatInterpolator>FloatData, set to Quadratic Keys. Again, this will be used to alter the "Strength" value of the PSysGravityModifier. See above.

PSysModifierActiveController: Takes BoolInterpolator>BoolData, set to Unknown_Key. This is for turning on/off a modifer at a given keyframe. BoolInterpolator should be set to Yes, and as usual, Time is keyframe time, Value is 1=yes/on 0=no/off.

I'm fairly sure I've only ever seen this linked to a DragModifier, but it could be handy for other modifiers, situation depending :)

PSysResetOnLoopCtlr: I've not seen it used, but I'll guess that It re-initializes the particle system when it hits the stop time to loop again. It could possibly be entered as the last controller in a chain?

The Particle Chain[edit | edit source]

Particles have a lifepsan, and at their most complex, they work like this: They are born, can fade in and change color, move some place(s) and/or rotate about, swirl around, flicker, fade out, and die to be reborn. Fantastic creatures they are!

The particle emitter and modifiers work in a chain, partly defined by their location in ParticleSystem's "Modifiers" Array, and each modifiers "Order" value. I don't know if it's possible to change the order, I haven't tested that much so far, due to the interactive nature of the modifiers. So far, from all the files from Bethesda, Modifer Order seems set in stone, and looks like this:

AgeDeathModifier:0 Emitters:1000 SpawnModifier:1000 GrowFadeModifier:3000 ColorModifier:3000 RotationModifier:3000 BombModifier:4000 DragModifier:4000 BSParentVelocityModifier:3000 BSWindModifier:4000 GravityModifier:4000 ColliderManager:5000 PositionModifier:6000 BoundUpdateModifier:7000

So far, I've never seen any of these without their aforementiontioned values, even in cases with more than one of the same Modifer (usually drag or gravity).

Second, they should have a name. Usually, this is copied from the Node Name, with :0, :1, :2 and so on appended. This probably reflects the order in which they were added in Bethesda's editor (3dsMax?) I haven't seen any correlation in their order as far as Oblivion goes. But the name *IS* important to have, especially when working with Controllers. Since the controllers state which modifier they work for by name, controller value / modifier names should be the same.

Modifiers all have a "Target" value, which should always point to the ParticleSystem that they are part of.

Active: Toggles on/offness of a modifier. Useful for muting when previewing effects. But, if you aren't going to use a mod, best to delete it when you're finished.

Emitter types are the first in the chain, and are responsible for putting particles into the scene, even if they are inactive, oddly enough, so let's move on to those.

Emitters[edit | edit source]

There are four main types of emitters: Box, Cylinder, Spherical and Mesh. Their primary function is to define the space/area in which particles are birthed, and from where they are birthed. The first three more or less work the same, so I will discuss those first, and then the Mesh emitter; it emits from points on a supplied mesh for a more defined shape. While writing this, I found a couple more I had never noticed before, those appear last.

Box, Cylinder and Spherical: These three define the type of shape/emission it's all happening from. Their default actions are to emit outward from their faces, so choose what suits your goal.

Speed: This controls the overall strength of particles to gravitate toward or past other modifier nodes. For example, you have a Drag Node set Z30 above the emitter, and DragModifier is set to Z. A low Speed value would make the particles less "attracted" than a high Speed value. (depending on a non-zero value in DragModifiers "Percentage" value.)

Speed Variation: Adds an amount of randomness to the Speed setting. Example: Speed=20, Speed Variation=2. The particles will be birthed with a random speed from 18-20.

Declination: Defines the intial direction of each individual particle. (seems to function for the first axis) Declination Variation: Adds a random range to Declination.

Planar Angle: Defines a second direction. (seems to function for a second axis) Planar Angle Variation: Adds a random range to Planar Angle.

Ok, so I'm not really a math person, and can't describe these well enough. But I think the word "spread" better defines the "Variation" field.

So, say you have a SphereEmitter, shooting out in a stream off to the side, using Declination of say, 12. We could add a Planar Angle Variation of 2 or so to give the stream more of a conical shape with a slight degree of randomness. But, if your "radius" is set too large, you'll have an amount of particles that travel through the sphere area. For a better cone shape, we could lower the radius to 1 or so (depending on needs). Or, we could move all 4 values to 12, and get a pretty good spherical spread moving outward.

Initial Color: Sets the default particle color.

Initial Radius: This sets the "Size" of individual particles. Low=Small (small sparkles) High=Big! (fog or smoke) Radius Variation: Adds a ranged degree of randomness to Initial Radius.

Life Span: How long a particle is alive and active for. Life Span Variation: Adds a ranged degree of randomness to Life Span.

Emitter Object: This points to the node that contains the particle stream. (The secondary one, the one we added "-emitter" to the name of, remember?)

For a BoxEmitter, we have Width, Height and Depth to define the area of the emitter. For a CylinderEmitter, we have Radius and Height to define the area. For a SphereEmitter, just radius to define the area.

MeshEmitter: This is a fun one. Rather than a confined area for emitting, MeshEmitter uses a TriShape or TriStrip to emit from. This can be used for a more refined shape: For example, a scene has an altar with some magical glyphs on the floor around it, in a circular fashion. We want to only emit some firey embers, swaying upwards in a "ring" shape along the radius of this circle, but not the center. We would create a low-poly flat plane, shaped more or less like a ring (a circle with a hole in the middle). Or another example, say a helmet with several thin, semi-curved spikes sticking outward. We want to emit little sparkles along these spikes only, not the rest of the helmet. We would create a low-poly approximation of the spikes (in the same space) to use as the emitter.

Emitter meshes can be visible ones, or invisible. If you don't want it visible, remove the TexturingProperty, and set "Num UV Sets 2" to 0 (and update UV Sets array further down) in TriShapeData. Also remove TangentSpace, if present. It is best to keep the normals of the emitter mesh, however. Keeping the MaterialProperty makes it easier to see in NifSkope, but won't render in Oblivion. Also, set the Flag for the Trishape to "Hidden" to prevent draw issues.

-Num Emitter Meshes: I don't think I've seen a MeshEmitter use more than 1, nor would one really need to. Emitter Meshes: Array for linking a TriShape or TriStrip. The shape must also be the child of another node (like that secondary node, for example.)

Remember we're working in triangles here, so a cube face has two faces/triangles.

Initial Velocity Type: Defines the direction/velocity action of emitted particles: 0: Use Normals: Direction is based on the normal of each vertex. 1: Use Random: Emits in random directions 2: Use Direction: Emits all in a direction specified by Emission Axis.

Emission Type: Picks what aspect of the mesh to emit from.

0: Vertices: Emits from vertex points. 1: Face Center: Emits from the center of each face 2: Edge Center: Emits from the center of each edge. 3: Face Surface: Seems to pick an even spread of points across the surface of a face. 4: Edge Surface: Seems to pick an even spread of points across the surface of an edge. (kinda pretty, actually, on a larger flat plane. Could be useful for drawing simple shapes with some careful geometry)

BSPSArrayEmitter[edit | edit source]

-Note the BS Prefix. This emitter uses a group of NiNodes to use as emitters. Its default action is "At Nodes" and right now, I'm not sure how/if this can be changed (I will update this should info surface). In this mode, Particles are drawn along lines leading from node to node, and only directly from parent/child. It will look similar to how NifSkope draws a line from a node to it's child node(s). This works similar in fashion to MeshEmitter, and is a good alternative to more complex shapes (like drawing words, for example)

To set one up, Create a new NiNode attached to the Root Node, and give it a meaningful name, like "SparkleArrayEmitter". You don't want this node part of your main "emitter" node, I believe. BSPSArrayEmitter's "Emitter Object" is where to link this new Node to.

Now add as many NiNodes to this main "array" node you just created. Move their translations around and create your desired shape. Any NiNode in this array can have multiple children. Many Bethesda files have a StringExtraData with "sgoKeep=1" attached. This is an optimizer setting, but I'm not sure what it does, but it's likely a good idea to keep one for each NiNode. I just copybranch/pastebranch while selecting a NiNode to automatically number and attach it, makes life easy :)

Modifers Should point to the ParticleSystem they are a part of, as usual. Have fun!

Modifiers[edit | edit source]

Ok, getting to the fun stuff now! These modifiers change the particles in a number of ways. As previously mentioned, they have an "Order" defined in ParticleSystem's "Modifiers" array, and by their own "Order" value. Also mentioned, was that they need to have a unique name, especially when working with controllers, who will reference this name. "Target" will always point back to the ParticleSystem they are a part of, and "Active" is yes/no- useful for previewing effects or tinkering around.

There are a few that I think absoultely need to be there: AgeDeathModifier, GrowFadeModifier, PositionModifier, and BoundUpdateModifier.

AgeDeathModifier[edit | edit source]

Always the first modifier, and always points to the SpawnModifier. I'm unsure of its use. "Spawn on Death" is recognized by Oblivion, but I've yet to see it used or do anything. So, just make sure it's Active, and points to the SpawnModifier.

SpawnModifier[edit | edit source]

Again, I'm unsure of it's use as a whole, as I've only ever seen it used to alter Life Span / Life Span Variation, which always seems to reflect the same settings as the emitter. But setting them higher or lower than the emitter's values doesn't seem to have an effect.

GrowFadeModifier[edit | edit source]

Used for fading in/out particles. I'm unsure if The "Generation" values are used, or how to use them. Fading in this case, refers to the size of a particle.

Grow Time: Time it takes to fade from zero to the "Radius" specified in the Emitter. Using zero here means particles will be birthed at their full size.

Fade Time: Time it takes to fade from where a particles size may be to zero. Using zero here means particles will die at the size they are at.

ColorModifier[edit | edit source]

Used for specifying the color and alpha of a particle at specified keyframes. It should be set "active" and via the "Data" value, a ColorData block should be linked, using "Linear Keys".

-Set the desired number of keys in ColorData, and update the key array. "Time" is at what time the next change should happen. Clicking the Color Wheel icon brings up a dialogue allowing you to pick the color, and alpha value to the right. (top is 1, bottom is 0.)

-If your color changes aren't visible, check PSysData, and ensure that Vertex Colors is turned on.

RotationModifier[edit | edit source]

This modifier rotates particles as they travel based on the supplied values.

Initial Rotation Speed: The base speed at which to rotate, which can be given range by: Initial Rotation Speed Variation: Which adds a random range ro the rotation speed/amount.

Rotation Angle/Variation: Most files have these two set at 3.1416 / -3.14159, which defines a full circle (radians). It's probably best to leave this as-is, and just use a low rotation speed if less is needed. However, if you are emitting a "special" image that needs directionality, you can turn off everything else here (or set to 0) to define the orientation of particles. Say you had an image of a arrow, and you need it always pointing a certain direction, for example.

Random Rot Speed Sign: Should apply a random speed to Rotation Speed? Random Initial Axis: Should apply a random angle when a particle is born. Initial Axis: For defining what angle the particles are birthed at. -It could just be the test files I used, but I couldn't get these to do much ofanything for me. That, and particles are generally done on billboards, so these aren't likely to get used often.

BSWindModifier[edit | edit source]

(Note the BS Prefix). This Modifier uses the current cells' wind value in Oblivion as a modifier. Also, this may be an additon by Shivering Isles, as there's only one set of files that use it?: effects\sefxashweather.nif.

Strength: Sets the overall "pull" wind will have on the particles. Using Negative numbers sends them in the opposite direction.

NOTE: This modifier will have no effect if "World Space" is set to no. Also, it doesn't look like interior cells have a "Wind variable, so keep that in mind while testing.

BSParentVelocityModifier[edit | edit source]

(again, the BS Prefix) This will act as a kind of blend mode between World Space and Object Space. "World Space" in the ParticleSystem must be set to "yes" for this to have effect. It's really odd.

Damping: Sets the amount to blend.

A Value of 0 means particles are entirely world space. Higher values give a higher weighting towards object space. Values higher than 1 seem to amplify the amount of rotation/translation from particle to source. A slight movement forward would send the particles forward twice as much, for example. Experiment with very low numbers (0.2 - 0.8, for example)

This modifier has no visible effect when an object is not in motion, or hasn't moved yet.

BombModifier[edit | edit source]

This one is just too cool. It could possibly be a performance hit, so be warned. It works similar-ish to a Gravity or Drag mod, kinda, I have a bit of trouble accurately describing what it does. Like a bomb or a vortex, it alters the path of the particles quite drastically. It can pull in particles, and/or make them orbit (with a negative DeltaV) or push them away (positive DeltaV). You can set it off to the side to create a curve, or for a swirly spiral effect. This node can be wildy varied when used with Drag or Gravity modifiers as well. This modifier needs a lot of experimentation! One, just to see what you can do with it, and Two, to tweak that to your needs.

Bomb Object: Specify another NiNode to use as the bomb object. (This NiNode should be attached to the ParticleSystems' parent NiNode.) Where in XYZ this node is placed affects particle attraction.

Bomb Axis: XYZ that affects which axis has (more) control over the Bomb Effect. This can also correlate with the placement of the Bomb Object and where the particles are in relation to it.

Decay: Seems to affect falloff starting from the outer radius. You may need to turn up "Speed" of your emitter for this to have more effect.

DeltaV: Seems to define the "Strength" of the Bomb. Positive numbers push away from the bomb object, and Negative ones pull inward. Inverting a value in Bomb Axis will act inverted appropriately.

Decay Type: Affects what type to use for "Decay" :) Usually Linear works best. 0: None 1: Linear 2: Exponential

Symmetry Type: Defines what type of symmetry the Bomb uses. 0: Spherical - Bomb is more or less Spherical in treatment of all three Bomb Axii. 1: Cylindrical - Bomb uses two Axii. 2: Planar - Uses one Axii. (i really hope that's the proper declination, it's either that or Axum, don't have a book handy.)

DragModifier[edit | edit source]

This will attract or repel particles towards a specified node, and can redefine their path. A very useful mod.

Parent: Defines the node to use as a drag point. Attach a NiNode elsewhere in your file, Name it something meaningful, like "Drag01". Where in XYZ you place this node in relation to the particles, as well as its rotation.

Drag Axis: Defines which Axis has (more) control over the drag effect.

Percentage: Kind of a touchy value, but its more or less the strength of the effect.

Range: I'm not sure what "shape" this modifier/node is, but I assume spherical. But this setting is the Size of influence.

Range Falloff: Defines the falloff of the shape, where 0=hard edge. I don't know what range this value has.

Many of Bethesdas files use 3.40282e+38 for both these. This ensures the largest shape possible for long distance drags.

This can be a tricky one to use without seeing what you're doing. Where the Drag node is, how it is rotated, what settings the Drag Modifier is using, the type of emission, and the "Speed" of the emitter are enough as they are, but other mods work in a lot of fun ways when it comes to moving particles. It's quite easy to get lost playing with different movements. But, this modifier seems to work before any others, like gravity for example.

-Set the particles to move Up on the Z axis a short way- and set the GravityModifier to move them Down on Z axis with a rather lowish force. The Particles move upward first, hit a smooth curve at their peak, and then fall towards the gravity.

-Or, still moving Up on Z-Axis with the drag modifier, switch the gravity to move along X instead. The particles move up towards the drag, then move sideways towards the gravity, creating a "blanket" effect if you have spawned a fair number of particles.

-Using Drag with a small range/falloff, and positioning the node just to the side of a particle stream will make them curve slightly. Also, with a smallish range, the DragModifier will only affect particles near the Drag Node.

-Some of Bethesdas .nifs use multiple DragModifiers, one for each axis. I'm unsure if this is the same as setting the same Modifier to use multiple axii. Or, one could set up multiple Drag Nodes for a more kinked path. This activity could even be brought further by using a ModifierActiveCtlr, alternating which ones are active for even more complex movement.

GravityModifier[edit | edit source]

Another modifier that attracts particles towards a node. This modifier works differently from DragModifier, and can have a stronger effect. The two work wonderfully together, however!

Gravity Object: Defines the NiNode to use as a gravity object. Create a NiNode with a meaningful name elsewhere in your nif (just not a part of the "emitter" Node.) The rotation of this node will matter in how the directionality of the gravity.

Gravity Axis: Defines which axis has (more) control, or in which direction to pull. Say the Gravity Node is set X0,Y0,Z-10/Y180, R0, P0. (Let's also say that the particle emitter node is X0,Y0,Z0). Setting Gravity Axis x0,y0,z1 will pull particles downward. If we set x1, y0, z0, the particles will have a curve leading into the X axis.

Decay: Sets a falloff of the overall gravity shape. Depending on the speed of particles and Strength of Gravity, you can set a soft falloff where only a portion of particles are fully effected by gravity. Those falling into the falloff area will have less weight towards gravity. Those not in the falloff area are unaffected. 0 Means no falloff.

Strength: The overall pull strength of Gravity. Negative values will push particles away- Antigravity! High values will cause particles to orbit, moreso with Spherical Type.

Force Type: Defines whether to use a Spherical or Planar gravity type. Planar seems to have an even spread, while Sperical attracts nodes inward towards the center of the Gravity Node. Spherical type can also orbit Particles with better control, and will be dependant on which Gravity Axis is in effect. Spherical mode seems to have a smaller range, whereas planar seems to act a bit more "globally"

Turbulence: Adds a degree of randomness to the particles. Very low values here can give a "leaves falling" type effect, where they don't fall quite down, they sway, rock and swirl their way down. This is quite useful for adding believability to many reality-based effects, especially when coupled with a bit of rotation, like waterfall spray, or falling ash.

-On another note, I have a very very small particle stream using a spherical gravity node with an amount of falloff to spread the stream out. Adding turbulence in this case seemed to give particles a certain resistance to gravity (with a 0 for turbulence scale)

Turbulence Scale: Seems to be the random velocity control over turbulence. Using negative values for either of these has no apparent effect.

ColliderManager[edit | edit source]

This modifier works a little differently than others. It uses a NiNode that particles can collide with and/or bounce off of. To set one up, Create a PSysPlanarCollider or SphericalCollider, and link it into ColliderManagers' "Collider" Value. Now create another NiNode elsewhere in your scene, similar to a Drag or Gravity Node, this links into Spherical/PlanarColliders "ColliderObject" link. The translation and rotation of the Collider Node will affect its function.

Planar/Spherial Colliders[edit | edit source]

Defines what shape the particles will be bouncing off of.

Bounce: Sets the amount of bounce particles will have when hitting the collision object. 0=No bounce, and particles will stay there until death, or pulled away by another modifier. (Think of a marble rolling of a desk, for example.)

-Spawn on Collide: Doesn't seem to function.

Die on Collide: Particles will die when they hit the object. This could be useful for masking off certain areas of your particle stream. For example, you have a large array of "rain" particles falling over a large area. There is a static Umbella trishape, and we don't want rain going through it, so we set up the collider(s) to sit roundabouts where the umbrella's hood is.

Spawn Modifier: Link this to the SpawnModifier used by the current ParticleSystems' SpawnModifier.

Next Collider: I haven't tested this yet, but you could set up a daisy-chain of colliders that use the same settings. Like setting up a staircase for particles to bounce down.

Radius: (Sphere only) Defines how large the sphere is.

Width, Height: (Planar only) For defining the surface area of the plane. X Axis, Y Axis: (Planar only) Defines the orientation of the plane, I was unable to turn the plane into a box, however. Depending on your needs, it may be easiest to set X Axis: X1, Y0, Z0, and Y Axis: X0, Y1, Z0. With a Collider Node set at X0Y0Z0 / Y0R0P0, the plane would be laying flat along X/Y, facing towards +Z. Rotating the Collider node from here will affect which direction the particles will bounce.

And that's a decent runthrough of the Particle system and the stuffing for it. Again, Check out my other guides, or seek me out (throttlekitty) on the Elder Scrolls Forums if you have questions or comments!

Working With Nifs 401 : Particles

Contents