2da Notes

Before starting on any emitters - which drive VFX - do remember if you are using visualeffects.2da to set the correct Type_FD value, for instance, D for anything with a duration, or B for any beams, else your emitters may be assumed to only be "instant" and unexpectedly stop working after a second or so.

Aurora Emitter (helper object)

Emitters are the basis for a large number of the visual effects found in the game.  Whether it be the fire dripping from your magical sword, the water mists from a water elemental to the pyrotechnics of the most powerful magics. You will find emitters at their base.

Particle emitters in NWN emit one of two basic things, a flat two polygon object with a texture mapped to it, or a 'chunk' in the form of a small model or mdl.

The particles can be emitted from the emitter at an angle or from the emitter to a target object along a path in the case of p2p or Point To Point emitter.

Lightning is merely a specialized p2p emitter that's set up to spew lightning as its used often enough that it's convenient to have a unique set of controls for it.

Because of billboarding the flat particles can appear to be solid rather than flat depending on the various settings or they can be made to stay flat as the camera rolls around. Billboarding is a term that means the engine will constantly move the particle so that it always faces the camera regardless of how the camera is moved, also known as camera alignment in some programs.

The textures that can be mapped to a particle can be animated as well, this is what creates the nifty fire effect. Each particle has a texture sequence that's applied to it that's one frame of a fire animation.

So get to know your emitter, you'll be the better off for it.

Emitter Style






UpdateThe way the emitter generates particles.
  • Fountain: The particles are emitted in a fountain based on the spread value. Anything from a single line to a spherical shape can be accomplished
  • Single: Emits one particle. As an example using this and a gridded texture you could easily display a magic mouth talking. Another setting Loop Single causes this to emit more than once otherwise it emits one time
  • Explosion: The emitter doesn't emit anything until a detonate event is signaled on a keyframe in an animation that includes it. Then it fires off one burst based on its settings. You create events using the Aurora Base. Note that ALL explosion emitters in a single model will react to the detonate event and go off simultaneously.
  • Lightning: Generates Point 2 Point lighting effects. Lightning emitters require a target object to work. The target object is a Aurora Reference which is the child of the p2p emitter.








Renderhow the particles are rendered once generated.
  • Normal: Particles are generated that constantly rotates to face the camera
  • Linked: Same as above except all particles touch and are stretched where necessary to do so. Example use the ring texture and you can generate an almost chain appearance.
  • Billboard to Local Z: Particles face the way they came out regardless of camera movement. Note this will cause them to vanish from the opposite side as particles are one sided. Good idea to turn on twosided for this method.
  • Billboard to World Z: Particles face upwards
  • Aligned to World Z: ?
  • Aligned to Particle Dir: The particles are aligned to the angle at which they leave the emitter. This has a subsetting of deadspace.
  • Motion Blur: Stretches the particles along the path of travel severely and then overlaps them as well




BlendThe 3 blend modes for texture type emitters.
  • Normal: use as simple texture mapped object (including texture alpha channel (if any))
  • Punch-Through
  • Lighten: use lighten mode, so any pixel that is lighter than the background gets displayed - that way you can use textures without an alpha channel, as black will always be see-through

0 (normal)

1 (trail)

Spawn Typedetermines the type of emitter
  • Normal - Emits Particles based on Birthrate per second
  • Trail - Birthrate sets # of particles per meter, leaves a trail when moving

Emitter Parameters

Icon SizeHeight of the cone representing the emitter. Not used at the moment.



cm (Float)X-Size

The X and Y dimensions in cm of the emitter. From this you can see that an

emitter is in fact a square surface from which the particles are emitted. A size of a 0,0 is a single point. A particle is emitted randomly within the boundaries of the x/y values (in cm). So a X and Y value of 100 each would emit in the boundaries of +/- 50 cm of the emitters position.

Since NWmax 0.8 the emitter also creates a shape that shows the actual emitter area.
Note that while the value can be set very high, the NWN engine seems to cap emitter sizes at 500cm x 500cm .





BooleansInherit PropertiesThese determine where the particle gets it's velocity from, other than it's set velocity. Leaving these values blank means there is no inheritance. No inheritance means that the particles created have no tie to the local xyz of the emitter object
  • Inherit: The particles inherit the emitters Z axis and will stick to it like glue, particles in this option will stick to the emitters Z axis (direction its firing the particles in) as well as it's world XYZ, This is used on the weapon effects in NWN like the fire swords. imagine them like a heap of small balls stuck to wires radiating from a larger ball in the middle, if the middle ball is rotated or moved around they all follow it, but in this instance the smaller balls are also following and travelling along the direction of their wires. The player effect in the cone of cold spell uses this, a sphere of snow particles swirling around the player.
  • Local: Visually its the same as inherit from emitter, but instead of particles sticking to the emitter, they stick to where they spawn from. So if you have a moving emitter, the particles will stay where they spawned, regardless of whether the emitter is.
  • Velocity: The particles inherit velocity from the motion of the emitter object
  • Part(icle): If this is on and Inherit velocity is ALSO on the particle will stretch depending on the speed its going at. With it checked on its own its as you mentioned, just the same as the others
renderorderShort IntegerRender OrderA priority to help the Aurora Engine determine the order in which to render different emitters in the scene. The lower the number, the higher priority particles emitted from that emitter have in the scene. So if you had emitter1 set to 0 render order, and emitter2 set to 1 render order, emitter1 particles will appear over the emitter2 particles.
thresholdFloatThresholdFrom Alex Scott at Bioware - the distance away from the gravity point that the particle will be killed off. A value of 0 will let the particles pass through the gravity center and loop back in an orbital pattern. This is for the Point to Point particle type, (Gravity Field) -> the other components are Drag and Grav Pull.
combinetimeFloatCombine timeFrom Alex Scott at Bioware - Combine time = Transition Factor. Point to Point emitters that are labeled Bezier Path have 3 settings, Transition factor, SRC tangent and Trg Tangent. Transition Factor - how long it takes the particles to flow from one point to the other along

the path.

deadspaceFloatDeadspaceFrom Alex Scott at Bioware- View Direction Dead Space - If "aligned" particles travel directly at the camera they are invisible and wasted. Specifying a dead space in degrees ether side of the camera allows for more particles to be spawned in visible directions. A value of 12 is best.

Emitter Particles



VectorStart color
End color
Starting and ending colour of the emitter particles. This is the final colour as the particles life span finishes



FloatAlpha start
Alpha end
Starting and ending alpha value



FloatSize X/Y start
Size X/Y end
Starting and ending height - If you leave the Y-values at 0.0 they will use the same value as the X axis.
birthrateFloatBirthrateThe rate of particle birth per second
lifeExpFloatLife ExpThe life of each particle in seconds
massFloatMassEffectively the weight of the particles - positive values make the particle fall down, negative values make it float up
spreadDegrees (0-360)SpreadThe degree of spread they can leave the emitter by, from 0 to 360 degrees. Where anything over 180 is going backwards from the direction the emitter is facing
particleRotFloatParticle Rotationthe amount of rotation the particle has expressed in rotations per second
velocityFloatVelocityinitial speed of the particle in meters per second
randvelFloatRandom VelocityAn amount from 0 to x that will be added to the base Velocity
bounce_coFloatBounce Coefficientthe degree of bounce a partical will have when it hits a static walkmesh and the Bounce flag is set
blurlengthFloatBlur LengthHow much a motion blur particles stretches.
loopInteger (really Boolean)LoopThis causes single update emitters to loop.
bounceBooleanBounceThe particle bounces against and static walkmesh
m_isTintedBooleanTintedWill tint the particles to the ambient colour of the scene
splatBooleanSplatOn collision the particle is placed flat (face up) on the contacting surface
affectedByWindBooleanAffected by Winddoes wind effect the particles

Emitter Texture/Chunk

textureString (maximum 16 characters as usual)Texturethe texture that this emitter uses
twosidedtexInteger (really Boolean)Two-sidedIf the particle is visible from both sides
xgridIntegerGrid widthnumber of images across the texture
ygridIntegerGrid heightnumber of images down the texture

the number of images to show per second. It'd probably not be a good idea to go over 60 for this.

frameStartInteger (really Float)First Frame0 based index
frameEndInteger (really Float)Last Frame0 based index. A 4x4 texture has 16 images indexed 0 to 15
randomBooleanRandom PlaybackRandom starting point for playback
chunkNameString (maximum 16 characters as usual)Chunkthe model name to use for a chunk. Overrides the texture settings if this field is filled in.

The ones commonly used for emitters are:
plc_chunk_m01 - metal
plc_chunk_s01 - stone
plc_chunk_s02 - stone
plc_chunk_w01 - wood
plc_chunk_w02 - wood

Emitter Advanced

lightningDelayFloatDelayLightning Parameter, how fast the emitter is updated
lightningRadiusFloatPeak RadiusLightning Parameter, the radius in which the Lightning 'impacts'
subdivisionIntegerSubdivisionsLightning Parameter, the number of subdivisions along the line from emitter to the reference object
lightningScaleFloatScaleLightning Parameter, the maximum range a subdivision can fluctuate on the lightning
blastRadiusFloatRadiusThis setting allows a burst of wind to be emitted. This is how big of a radius the wind effects. This causes dangly objects to move, as well as emitter particles that are affected by wind.
blastLengthFloatLengthThis specifies how long the wind stays in effect.

OpacityFrom Alex Scott at Bioware - Opacity scale - How transparent is the blurred section. 0 to 1. (1 being fully visible) Relates to Motion Blurred render style. Opacity and Length scale, both go form 0 - 1.
p2pBooleanUse P2PSets it up as a p2p (point to point) emitter. These require a reference node that must be a child of the emitter. If not, it will crash the game. p2p emitters cannot be used on tiles or placeables. God I hope this gets fixed.

0 - Bezier

1 - Gravity

Bezier/GravityBezier emitters use the SRC and TRG properties, while Gravity emitters use the Gravity and Drag properties.
p2p_bezier2FloatSRC (Source)Tangent The arc length for the first half of a p2p emitter.
p2p_bezier3FloatTRG (Target) TangentThe arc length for the second half of a p2p emitter.
gravFloatGravityProperty of certain p2p emitters that allows the particles to be pulled towards the reference node as if there was a gravitational pull. The higher the value, the faster they are pulled.
dragFloatDragOn p2p gravity emitters, it causes particles to shoot past the reference node then double back towards it. The higher the value, the farther the particles shoot past the reference node.

You can animate some of these properties so that they change during the course of the animation playing (e.g., birthrate). All the value spinners including the color values in the particle menu roll down can be animated. However, the Loop, Tinted, Bounce and Wind check boxs cannot be animated. You will have to play around with others because there may be more which can be adjusted through animation.

There additionally are the standard kinds of fields;

  • position
  • orientation

CPU overhead

From Danmar:

An emitter emits two polygon squares which have textures mapped to them. An emitter with 100 birthrate emits 200 polygons. There is also the fact of longevity. I've not done any real tests to see if birthrate = that many particles existing at one point in time regardless of longevity or if that many particles are generated every X.X seconds and the longer the longevity period the more particles that exist at any one time.

But I digress, at bare minimum an emitter creates 2xbirthrate in polygons.

In addition to the face count they add, emitters also require computation to generate and control from birth to death.

Also the size of the particles can make a big difference. Look at the 'fog/mist' placeables that people have created which use really big particles. These cause intense lag with just a few particles comparitively. Yet I can create a spell effect that has several 100 and 200 birthrate emitters that are small without any lag.

So its a complex question. Size, number, longevity all have to be factored in.

Note: this content was rescued from the Wayback Machine's archive for http://ccg.animecafe.net/index.php?title=Aurora_Emitter

How to (by MerricksDad) [WIP]

A simple series of tutorials using OC content as examples.

Emit A Basic Puff

Key concepts:

  • constructing the emitter plane
  • understanding update, render, and blend
  • picking a texture
  • using a single frame sprite
  • using black and white sprites with Lighten blend type
  • using color, alpha and size
  • understanding life expectancy and birthrate

File: data>models_01.bif>VIM_MAGBLUE.mdl

This VFX is what gets called on impact for spells like magic missile. It has two emitters, one called flares, and one called sparks. Let's look at the flares emitter. Unimportant aspects removed from the listing.

node emitter flares
xsize 0
ysize 0
spawntype 0
update Explosion
render Normal
blend Lighten
texture fxpa_flare
xgrid 1
ygrid 1
colorStart 1 1 1
colorEnd 0.36 0.76 1.0 alphaStart 1
alphaEnd 0
sizeStart 0.5
sizeEnd 0.07
birthrate 70
lifeExp 1
end node

I've taken the liberty of organizing the useful aspects in the order of importance.

The first thing we see is the emitter plane itself. We set the dimension of the emitting region to nothing so that the particle will emit from a single point rather than a rectangle.

Next we need an update type to tell the engine when to produce particles. Update type "Explosion" emits particles when "detonate" events are fired. Those are discussed below. For the purpose of this mini tutorial, just assume it's a triggered event and won't produce particles constantly.

Next is the render type, which is set to Normal. Combined with spawntype 0, this means the particles are emitted a number of times per second based on birthrate (in this case 70) and will always face the camera. However, since this is a "detonate" event, all 70 will come out of the point at once when the detonate event is triggered.

We then see the blend mode "Lighten". This takes the image RGBxA value and adds it to whatever visuals are in the render order behind it. Lighten is used to make "magic" looking effects which simulate light. High-luminance values have a tendency to wash out the color in both the particle and environment. Keep in mind that not all B&W particle textures have an alpha channel.

The chosen texture is fxpa_flare.We can see this image is a single frame particle, which is also specified by xgrid 1 and ygrid 1 in the emitter node. It's a black-and-white image with a black background, so only the portions above true-black will be added in the Lighten blend mode.

The particle is then colored and made partially transparent. colorStart and colorEnd define the initial and time-end colors. In this case it fades over time from white to a blueish color. It also fades from 100% opacity to 0% completely invisible using alphaStart and alphaEnd. Keep in mind that some particle textures have an alpha channel, so your alphaStart and alphaEnd values will be multiplied by the inherent texture alpha value.

The size is also specified and changes over time from 0.5 to 0.07 using sizeStart and sizeEnd. These two aspects specify the rectangular shape if sizeStart_y and sizeEnd_y are not specified, otherwise you can make non-square particles using those other two aspects. If I'm not mistaken, size is approximately in meters.

Finally, lifeExp defines the time the particle remains in existence. In this case 1 second. Particles that reach the end of their lifetime will be erased, even if they were still opaque and large on screen. It's a good practice to make sure particles fade out proportionally with their lifeExp time unless you specifically want something else. In the case of Lighten blend mode, simply shifting to a black color (colorEnd) will do the same thing.

Emit An Animated Puff

Key concepts:

  • using sequential sprite sheets
  • using frame rate and playback
  • using colorized sprites with Lighten blend type

File: data>models_01.bif>vim_exp2flame.mdl

This is your basic animated flame.

Let's take a look at the Flame01 emitter within this file.

node emitter Flame01
xsize 60
ysize 50
spawntype 0
update Fountain
render Normal
blend Lighten
texture fxpa_firebb
xgrid 4
ygrid 4
frameStart 0
frameEnd 15
fps 16
colorStart 1 1 1
colorEnd 1 1 1
alphaStart 0.6
alphaEnd 0
sizeStart 2
sizeStart 4
position 0 0 0.33
inherit 1
birthrate 30
lifeExp 1
end node

This emitter differs from the basic magic blue puff above primarily in that it's a sprite sheet instead of a single sprite. We see that the grid is 4x4, which is defined with xgrid and ygrid.

Because we have a sequential texture animation we also define the start and end frames in the sequence. The number of frames is zero-based so the first frame of 16 is 0 and the last is frame 15.

Next we set the playback speed using fps. In this case, we want the whole animation to play out over 1 second, and we have 16 frames, so we wet the fps value to 16.

In the magic blue puff tutorial above, we saw that the texture was a black and white image, and we used the Lighten blend mode. In this case, we start with a colored texture. We still use the Lighten blend mode, but we don't want to alter the color from the flame red, so we set colorStart and colorEnd to white to preserve the full luminance and hue of the texture.

This emitter uses "inherit 1" which tells the emitter to move all its emitted particles with it when moved. So if the unit to which this flame is applied walks away while burning, then the fire will move with the subject. This emitter uses spawntype 0 and render Normal, which unfortunately means that flames may lay down relative to the camera. Later we'll go over how to keep flames like this upright relative to their emitter or the world z-axis.

Something else interesting about this emitter is that it has a non-zero position of (0 0 0.33), meaning it's lifted off the ground by about a foot. Particles are emitted such that their rectangle is centered on the emitter rectangle plus a randomized offset within the rectangle. In this case the emitter rectangle is 60x50 cm. If the z-axis of the particle isn't boosted a little bit, then the fire particle would clip into the floor. Something to keep in mind.

Finally, this particle uses a "Fountain" update with a birthrate of 30. Over the course of 1 second, 30 particles will be emitted from the 60x50 cm base rectangle.

Emit A Chunk

Key concepts

  • using chunk models
  • using spread, velocity and particle rotation

File: data>models_01.bif>vim_destruct.mdl

Gore! Everybody loves it, so you need bloody chunks. Gibbage! So, let's look at this chunky destruction model.

node emitter Chunk_01
spawntype 0
update Fountain
render Normal
blend Normal
texture NULL
chunkName Red_M_Giblet
sizeStart 0.01
sizeEnd 0.01
birthrate 100
lifeExp 4
spread 6.28
particleRot 1.5
velocity 5
randvel 1
end node

Here again we see the very basics: spawntype 0, update Fountain, render Normal, and blend Normal. But in this case, we don't supply a texture. Instead, we supply a chunkName, which must be a mdl file rather than a texture file. Here we use Red_M_Giblet, which should be a medium sized red chunky gib.

Note here we specify a very small startSize and endSize. The base scale of the chunk is determined by the chunk model itself. Here what we're doing is scaling it downward to 1/100 the initial size.

For whatever the duration of the impact happens to be, we're going to emit 100 juicy chunks per second. However, if we look at the actual animation keys for this emitter, we see this:

length 5.0
node emitter Chunk_01
birthratekey 4
0.00 100
0.43 100
0.47 50
0.50 0
end node

These animation keys say that over the 5 second maximum length of the impact playback, we're going to emit up to 100 chunks within the first 0.43 seconds, and then taper off suddenly to 0 as we approach 0.5 seconds. In this case, we might actually witness about 45 total chunks at max, but it will emit so fast you won't really see them to count them.

Note that we have a spread value of 6.26. This is in radians, so this equates to 2PI or 360°. We're going to spray gore in every direction from the emission point.

We also have a particleRot of 1.5. Over 1 second, we're going to rotate the particle 1.5 times. Since we specified Normal render, the axis of rotation will be along the direction of the camera view, for each viewer. Nobody will notice the spin discrepancy.

From the emitter point, chunks will shoot out at 5+/-1 meters per second, which we specified using velocity and randVel respectively.

This emitter also happens to be a P2P gravity emitter, but we're not going to discuss that here.

If you examine this model further, you'll notice that the builder included multiple chunk emitters in the same model, each emitting different sized chunks. You can also use each emitter to produce different chunk types. For instance, one emitter could throw out bones, while another throws out gore. Or in the case of a placeable armoire, you might want to emit drawers, wood chunks, and clothing articles.

Emit A Trail of Smoke

Key concepts:

  • using trail spawn type or not using it (that is the question)
  • using random sprite sheets
  • using alpha-channel-driven sprites with blend Normal
  • using negative mass

File: data>models_02.bif>it_torch_000.mdl

Torches. Every adventurer needs them, right? But if you want a realistic torch, it won't just emit light and fire, it will also emit smoke. Above we had a nice flame effect which stayed in place with the object parent. A torch has this too, but a torch should trail smoke as the parent object moves. There are two ways of doing this.

If you look at this texture (fxpa_smoke01), it's just a white image. Here I've shown just the alpha channel instead. You'll also note that the texture is twice the quality of the flame texture above.

Now, let's take a look at the emitter node.

node emitter emmiter_smoke
spawntype 0
update Fountain
render Normal
blend Normal
texture fxpa_smoke01
xgrid 4
ygrid 4
frameStart 0
frameEnd 15
fps 30
random 1
mass -0.2
velocity 0
randVel 0.2
sizeStart 0
sizeEnd 2
end node

Ok, the first thing you notice is that we're NOT using the trail spawntype 1. We're simply leaving the particle behind the torch as it moves.

In this case, you can also note the negative mass, effectively producing an anti-grav particle. Gravity-driven particles run by acceleration, which is meter per second per second. This means they speed up over time. The same is true of negative mass particles. In the case of these smoke puffs, the builder also specified a randomized velocity of 0+/-0.2 m/s, making particles sometimes curve out of the bottom of the emitter but then change direction to upward. This prevents all the particles from moving in a straight line and at the same speed.

Texture-wise, notice here that we're using an alpha-only texture with a pure white texture. The particle starts at zero scale and increases to 2 meters. During that time, the buildler also set the alpha to go to zero. So the smoke puff appears to diffuse into the atmosphere as it rises.

The new addition in sprite use here is the "random 1" aspect. This tells the engine to grab a random frame each time it needs one, instead of getting them sequentially. Also note that we're running at 30 fps instead of 16, so we're getting 30 randomized frames per second, creating a noise pattern instead of a sequential animation.

Another possible way of emitting smoke is via a trail spawntype 1. In that scenario the emitter produces puffs of smoke only when the object is in motion. The emission rate is set to X per meter instead of X per second. You can imagine this is not great for torches because emission would halt if the parent unit stops moving.

Emit Via Detonation

Key concepts:

  • using the detonate animation event
  • using the explosion update type

Let's revisit file: data>models_01.bif>VIM_MAGBLUE.mdl

We said above that this emitter uses a detonate event. These are special animation keys not tied to the nodes, but to the model itself. To use them, you simply put events in the named animation sequence like this:

newanim impact vim_magblue
length 1.63
transtime 0
event 0 detonate
event 0 detonate
doneanim impact vim_magblue

Any emitter with update Explosion will emit its particles at that point. If you use detonate multiple times in the sequence, the emitter will fire multiple times, which is what the builder did in vim_magblue.

The format is "event <time> detonate".

If you don't want a specific emitter to blow out at that time, you can set its birthrate to 0 at that particular time.

Emit Lightning

Key concepts:

  • using lightning update type
  • using subdivisions, peak radius, and scale
  • using P2P emitters

Emit Particles And Suck Them Up With Gravity

Key concepts:

  • using P2P emitters
  • understanding gravity, drag and threshold

File: data>models_01.bif>vff_comvortex.mdl

In this model, there's a lot going on, but let's focus on the OmenEmitter01 node:

node emitter OmenEmitter01
xsize 1000
ysize 1000
spawntype 0
update Fountain
render Normal
blend Normal
  p2p 1
p2p_sel 0
texture NULL
chunkName Fx_Rockchunksml
position 0 0 0.3
colorStart 1 1 1
colorEnd 1 1 1
alphaStart 1
alphaEnd 1
sizeStart 0.1
sizeEnd 0.1
birthrate 0
lifeExp 1
mass 0.1
spread 0.175
particleRot 5
velocity 0.9
randvel 0.5
drag 1
grav 2
threshold 1.5

node reference REFm
parent OmenEmitter01
position 0 0 0.63
orientation 0 0 0 0

The first thing we see here is that the size of the emitter is larger than other emitters. What they're doing is building a big area into which the particles will spawn instead of emitting from a single point.

Next, we see that the emitter is standard run-of-the-mill fountain type. Particles will come out of the specified area all the time.

What is different in this case is that the p2p variable is turned on. The p2p type selected is 0, which refers to a gravity-type emitter.

Next we see that texture is disabled, and the builder is instead emitting some rock chunk models. The position of the emitter plane is a little above z=0 so that if the VFX is played at ground level, the chunks won't penetrate the floor.

As with many other chunk emitters, the color is set to full-bright (white) for the entire duration of the particle's life. Likewise, the opacity (alpha) is not changing over the duration, nor is the size. Note that the size of the particle is defined at 0.1 to shrink the initial particle.

Particles are emitted from the wide plane, however the initial birthrate is set to zero. Look in the mdl file down in the animation sequences and we can see that birthratekey sets the value to 30 at the start of play and then turns it back off at nearly 4 seconds of play.

Particles leave the emitter plane with a little bit of mass and velocity, and also come out rotating. Note the spread value of 0.175 radians is approximately equal to 10 degrees. This isn't 10 degrees of the plane, but 10 degrees of directly up from the plane, meaning they're emitting "upward" (but only because this emitter is called by an area effect spell: Implosion).

And finally we get to the good part. We said above that this is a gravity-driven emitter. Particles spawn at random points within the 1000x1000 emitter plane. They have a mass of 0.1 which allows them to be pulled toward the reference node using an acceleration of 2 m/s^2. Think of it like a black hole singularity. The emitted particle will speed up over time to reach the singularity. This emitter also has a drag value of 1, meaning that as the particle approaches the black hole, there's a slingshot effect. This is NOT how surface drag is calculated in physics, so don't try equating those formulae to NWN. And finally, a threshold is set to 1.5, which is the same as setting the radius of a black hole's event horizon. If the particle finds itself within that radius, the particle is destroyed.

P2P emitters MUST have an associated "node reference" as a child node. The name is not important ("REFm"). The position of the reference node is important, as it determines the direction in which emitted particles will travel. Note that the direction is backward. If you play this particular VFX, you will notice that the particles migrate down into a black hole, not upward, but the offset is clearly up on the z-axis relative to the parent. Always think of your reference nodes backward for P2P emitters in NWN.

Notice that the reference node orientation is also 0 0 0 0 aka "undefined". It will inherit it's orientation from the parent, which gets it from the emitter node, which in this case is also not specified, so it will get it from the spell which places the effect. In this case, the spell "Implosion" puts the VFX on the floor and points it upward.

Emit Particles And Project Them Toward A Point

Key concepts:

  • using P2P emitters
  • understanding tangents

Emit Chains

Key concepts:

  • using render Linked
  • using inherit_local

File: data>models_01.bif>vps_tentacle.mdl

Particles can be linked together to form chains. The way this is done is to leave a particle where the emitter was, defining its size. Once the emitter exits the rectangle of the first particle, another particle is produced, creating a chain of particles.

How long each link in the chain lasts is determined by lifeExp.

Using sizeStart and sizeEnd, old links in the chain can be made to shrink or grow over time.

VPS_Tentacle is used for Evard's Black Tentacles. If we watch this animation, we can see that the length of the particle travel is constant. This is because the particle is emitted toward a pre-defined node using a P2P emitter of gravity type.

This effect is paired with inherit_local, which makes particles stay at a position relative to where they were originally spawned.

Emit Wind

Key concepts:

  • using detonate event and explosion update type
  • using radius and length

File: data>models_01.bif>vff_pulswind.mdl

The engine emits wind whenever a detonate event is fired within an animation sequence. To get wind to be notable, you need to specify a radius and length value.

node emitter WIND_Dummy
update Explosion
texture NULL
blastRadius 15
blastLength 1.2

As with any other Explosion emitter, using multiple detonate events within a sequence will emit multiple bursts of wind.

Emitting a lot of wind at once will force grass to lay down more quickly than its animesh properties normally handle. emitting long-length wind will cause grass to lay down for weird lengths.

Emit Darkness

Key concepts:

  • using a light node for other purposes than light

Emit A Particle Under The Caster (Aura or Burst)

Key concepts:

  • using different render alignments

Building A Projectile

Key concepts:

  • using the newly unlocked ProgFx.2da
  • understanding MIRVs

Building A Caster-To-Target Beam

Key concepts:

  • using the newly unlocked ProgFx.2da
  • understanding P2P emitters with progfx

Building A Head-Oriented Particle (helmet, hair, accessory)

Key concepts:

  • using placeable and item models as VFX
  • understanding different render alignments

Intro To Tile Magic

Key concepts:

  • using tile models as VFX
  • aligning a tile walkmesh with an area tile
  • No labels