MDL ASCII Emitter Nodes

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.

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

Lens Flare

Most light sources are also connected to emitters.  Many have annoying lens flare.  Source lens flares use the model fx_placeable01.mdl. If you override that with a version with the flare removed, you can kill the "hot spot" in the center of the light. Here's a version I did to solve the problem.

fx_placeable01.mdl

See also: placeables.2da ("https://nwn.wiki/display/NWN1/placeables.2da?preview=/38175210/38175586/fxpa_flare%20usage.txt")

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

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

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

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