CCG V3-1 Conversion:Part 7 Creatures

From NWN1 Custom Content Guide

Creatures

Okay, here we go. This is what you have all been waiting for: creating new monsters. This is an advanced tutorial. It requires you to understand almost everything we have done so far:

• NWN Explorer
• Hakpaks
• 3D Modeling
• 2D portraits
• 2da files
• Voicesets

I want to build a giant crab. I’ve done Wave, Whelm and Blackrazor for S3 – White Plume Mountain. I can find a gynosphinx and scorpions on NW Vault. But I don’t have a crab. The modules I have seen so far fake it with other creatures. I want a real giant crab.

Where do we begin? Well, let’s find something that at least vaguely resembles the final product. Crabs and spiders share a lot of features. There are a lot of spider models so I am going to use one of them.

Part 1: Understanding How NWN Represents Creatures

Let’s look at how NWN represents a creature by actually building an existing one in the Aurora Toolset. Try this exercise:

1. Open up the Aurora Toolset.
2. Create a new Module (we will call it Creature Tutorial for lack of a better name). Use the Area Wizard to create at least one Area. Use the defaults to set up the area and choose something simple like a Dungeon.
3. Select Wizards | Creature Wizard.
4. Click Next.
5. For Monster Type select Vermin.
6. Click Next.
7. Do not add any special classes.
8. Click Next.
9. Go with the default Gender, Appearance and Portrait.
10. Click Next.
11. Faction can be Hostile.
12. Click Next.
13. Enter a name (Crab Wannabe).
14. Click Next.
15. Add to the Special, Custom1 category.
16. Click Next.
17. Check the Launch Creature Properties checkbox.
18. Click Finish.

Image:Ccg fig 37.jpeg

When you create a custom monster you can use whatever model you choose but you are limited, of course, to models in the game. You can also choose your own Portrait and Voiceset. Check out the Appearance tab. For a simple model like this you do not have the ability to change any of the model pieces that make it up.

So there is our crab. The only problem is, it looks like a spider. But now that you have seen the different parts of a creature model we will need to look at, let’s get started on turning that spider into a real crab.

Part 2: The Creature Resource File

I’ll bet you thought you knew how this worked by now and that the section after I showed you the toolset would talk about naming standards. Well it isn’t. The basic naming standards for creatures are pretty arbitrary because you use the appearance.2da file to identify your new creature and specify its model. Inside each model there are some naming standards and we will get to them – but we will do that later because they relate more to animation than any specifics in the game itself.

I’m going to step out of the usual flow I normally give you and start with the resource file. I will show you how you can take an existing creature, create a new version of it, texture that new version and use it as a new model. In this case, we will make a crab that looks just like a spider but is orange. Kind of a sorry-looking crab but don’t’ worry, it is just a starting point.

What we have to do is add a new creature resource in the appearance.2da file. Again, we will get the appearance.2da file from \source\2dasource.zip (Bioware had to change it to add their Kobolds, Rats and Gnolls).

1. Copy the new appearances.2da file to the directory for your model and icons.
2. Open appearance.2da.
3. Go ahead and take a look at it. Scroll down until you get to the giant spider entry. You should see this:

158        Spider_Dire             2128         Spider_Giant... 
159        Spider_Giant            2129         Spider_Giant... 
160        Spider_Phase            2130         Spider_Giant... 

1. These different entries describe the many creatures in the game. I don’t show all of the columns here because there are too many.
2. Copy the Spider_Giant entry and paste it at the bottom.
3. Modify the entries as appropriate for your new creature.

H – high
L – low

0 for no
1 for yes

0 for no
1 for yes

0 for no
1 for yes

0 for no
1 for yes 

1. Now, extract the model for the giant spider (c_spidgiant.mdl). It is in data\models_01.bif.
2. Use NWNMdlComp to decompile the binary model file (see the directions in the Weapons section of this tutorial). Rename the file ASCII model file to c_crab.mdl.
3. You need to rename the Aurora base item from c_spidgiant to c_crab. While you are at it, rename the internal model reference for the texture that it uses from c_spidgiant to c_crab. We will create a new texture in a moment. You can do this either by editing the ASCII model file directly or by opening the model in your modeling tool and doing it there. This is not a tutorial on modeling, per se, so I leave that as an exercise to the reader (we’ll have lots of opportunities to look at the model file later when we start to turn the spider into a real crab). The simplest way is to open the .mdl file in a text editor and do a global rename.
4. Now, extract the texture file for the giant spider (c_spidgiant.tga). It is in data\textures_01.bif.
5. Rename it to c_crab.tga.
6. Open it in your image program (Picture Publisher for me).
7. It is made up of variations of black and green. While it is too early to start repainting it to a crab shell, lets at least make it orangish so that it does not look like a lime green, nuclear, glowing crab. I did this by making it greyscale, turning it back into an RGB image, and then shifting the hue of the greyscale image to orange/red. This is what it looks like. Still makes a pretty sad looking crab but be patient.
   • Image:Ccg fig 38.jpeg
8. Back through the same routine. Load the new 2da file, model, and texture into your hakpak.
9. Load up your module in the Aurora Toolset.
10. Point it at your hakpak. Save, close and reopen your module.
11. Now you can create a new crab using the Creature Wizard. You no longer have to create a vermin.
    • Image:Ccg fig 38b.jpeg

It looks a bit like a horseshoe crab now although it still has a spider’s portrait. We will tackle the portrait next and then we will get to actually turning our orange spider into a crab.

Part 3: Creating the 2D Portrait

Let’s make the creature portrait. There really isn’t anything new to show you here. The format for creature portraits is the same format as PC and NPC portraits. Go back and review that section if you cannot remember it. Even the naming standards are the same. In our case, our portrait files are po_crab_<size flag> where <size flag> is l, m, s and t. That’s right, no h size. This is because you don’t need the h(uge) portrait for creatures. The h(uge) portrait is only used in NWN on the character creation screen which is not valid for creatures.

I am not a big graphic artist with 2D images. But I can use Picture Publisher fairly well. Here is a trick you might find useful (at least if you are modeling real-life animals). Find a photo that works well for you. Rotate, crop and resize it as I showed you earlier to the Huge size. Don’t forget to leave the blank space at the bottom (the Large portrait is 128 x 200 with another 56 pixels at the bottom). Now, the problem is, the standard Bioware portraits are drawings. A photograph looks out of place. But all is not lost. Many good drawing programs have filters. I applied a watercolor filter to my photograph, play with the controls a bit, and it gives me something that looks like a drawing. Here is mine:

Image:Ccg fig 39.jpeg

Now create 4 more versions of this in different sizes. Edit portraits.2da to make the new portrait available and appearance.2da (the PORTRAIT column I indicate above) to tie it to your new creature. Then add all six files to your hakpak and bring it up in your module. Now you can change the portrait for your creature to this one.

Image:Ccg fig 40.jpeg

Seems like a lot of work just so I can call an orange spider a crab (don’t make me have to tell you to be patient again).

Part 4: Creating the 3D Model

While you can create a lot of different models with the basic steps in Parts 2 and 3 of this tutorial, this isn’t enough if you want an entirely new creature that does not have the same shape as an existing creature. I want a real crab, not an orange spider. So now we have to tackle our model. To do this, you need to know the basics of 3D modeling, including a basic understanding of animation. If you don’t have that yet, go get it – I’ll explain what NWN needs in terms of animation and nodes but you won’t learn the details of how to do animation, keyframes, or Inverse Kinematics here.

The Model

Creature models for NWN are meshes, like other NWN models. However, they are segmented:

1. Load the crab model into gmax by opening the Import MDL sub-menu in the NWN MDL Tool pane (not the File | Import… function) and using the Browse pushbutton to select the ASCII file you created in Part 2.
   • Image:Ccg fig 41.jpeg
2. You can minimize the MDL window after you open the file. Take a close look at the model you loaded.

Note the base object – this is used to link attributes to models (animations, etc.). The crab is a child mesh of the base. If you completed Part 2 already, the name of the base should already be c_crab. You will see that the model has one mesh object for each leg section (24 in all), one for the main body, one for the thorax, etc. Anywhere you want a creature to be able to bend or move independently, you need a separate mesh.

If you select these parts you will find their naming standards are not specific to the model. This is how NWN re-uses animations. Parent animations refer to part-names. In this case, the spider’s legs are Capsule01, Capsule02, etc. If we leave those names alone, we could use some of the spider animations for our crab without having to duplicate them ourselves. Unfortunately, we will find after playing with the spider animations that they are a little awkward to use for our crab. But we will use them as a base for some of our animations. More on this later.

So with that background, put those modeling skills that you learned elsewhere to use:

• Shorten and fatten up those legs. You may find it easier to do just one set on one side and clone them for the opposite side. It makes modeling and skinning go faster.
• Clone and add an extra set of legs (crabs have 8 legs and 2 arms, spiders have 6+2).
• Squash the bulbous body into a crab shell. Again, you may just want to do half the shell (make sure you can cut it exactly in half on a plane straight through the body) and then clone/mirror it to make the other half. This cuts down on texture space and on the actual work you have to do.
• Model a set of pincers for the front legs. Even though I made them different sizes, I used the mirror/clone trick to duplicate them again.

When we are done it should look something like this:

Image:Ccg fig 42.jpeg

Now, before you proceed, I can guarantee you have a lot of world transforms in your model. These don’t export to NWN. So select your entire model, and break apart all of the pieces (unlink them). Then, with all of the sections still selected, reset the transforms and collapse the new transform onto the stack for each of the pieces. This way you will not have messy problems with your parts being exported in stretched shapes or partial rotations (if your creature ‘explodes’ when you export it and then import it into the game, you probably didn’t ResetXforms properly). Don’t reset transforms on the Aurabase object! This will mess up your animation’s scaling when you export your creature. For more information on ResetXforms, refer to the tutorial on Weapons.

At this point if you are using 3ds Max, it is a good idea to do an "STL Check" (sorry, this is not available for Gmax). This will do a simple sanity check on your objects and faces and look for things like unclosed edges, duplicate polys, or inverted polys, etc. This helps especially to track down problems that show up only in the game.

Texturing

Texturing and animation are actually more difficult than the 3d modeling itself (well, I find it to be true although admittedly my 2d texturing skills are limited). If you have made it this far you are less than one third done so don’t get too excited by all the praise they will shower on you on the Custom Content forum for your model at this stage. The process for texturing is the same as it is for other models. Try to maximize your use of the space on the texture file. Try to avoid unnecessary work and unnecessary space in your texture file by mirroring parts of your creature, etc. In my example, since the crab is almost completely symmetrical, the texture only includes:

Alpha 1 # full opacity
Alpha 0 # full transparency
Alpha 0.5 # half transparency

• half the top shell
• half the abdomen
• one leg segment, top and bottom
• one antenna
• one eye stalk
• one pincer
• one main claw

Part 5: Animation

Now it is time to animate our crab. Let me start by describing how animation works and then how animation in NWN maps back to animation in 3dsMax and gmax (collectively, “Max”), the two most common tools for this. This is not a tutorial on Max animation (use the references at the beginning of this tutorial to build your knowledge in that area). What I will try to do is link common animation concepts back to NWN as part of this background discussion. This should help you map what you know to what you need to do in NWN.

Animation

Think of an animated film of a crab raising one of its legs. Not an exciting film, but a film nonetheless. It would consist of a series of ‘still pictures’ where the crab moves its leg a small bit in each successive picture until the leg is raised up into the air. Each picture is a frame. If you run the frames back in quick succession, your eyes will perceive a moving picture.

Keyframes

Most 3D tools (including the Max tools) support a single animation sequence made up of keyframes. Keyframes are similar to, but not quite the same, as the frames in this animated film. Think of keyframes this way: to have your crab raise its leg again with keyframes, create an initial keyframe with the leg down and a second with the leg raised. Max knows how to interpolate all of the points of motion between A and B to create the actual frames you need (the one you had to do by hand in the previous paragraph). This is called ‘tweening’. So using keyframes is similar to - but more efficient than - drawing every single animation frame in sequence – you only need to worry about the start and ending points.

Now, when you animate a scene in Max (this is what your creature - sitting there like a lump - is: a scene), you are creating a single sequence of keyframes. As Max runs through your animation sequence, it runs as a single, continuous animation or movie.

NWN is different: it supports a series of animation sets and does not want a continuous movie. There are a limited number of sets available (about 154 for PCs and Full creatures and 42 for Simple and Large creatures). You don't usually have to tell the game to use one set or another (like run, walk, etc.) it will call the appropriate animation set on its own based on what is happening in the game. Some are user-controllable through scripting (like greeting) so you can force the animation to occur when you want it to (too bad they all weren't scriptable). What this means is that to animate a creature in Max, you need to create the standard set of 42 or 154 animations depending on the type of creature.

So how do we reconcile Max’s movie with NWN sets? What we do is allocate a different block (or range of keyframes) of the continuous Max movie to each of the NWN animation sets.

Image:Ccg fig 42b.jpeg

The import scripts do this translation: they load the NWN animations into the one big animation in Max and put spacers of 10 frames between each adjacent set or block. Then they create a list of the animations and tie it to the Aurabase object. This cross reference gives the NWN title of each set, plus starting and ending keyframes for each set. Think of it as a big array of pointers into the single Max animation. When you click on the Aurabase you will see this array in the Edit tab.

You can modify the Max animation independently of the Aurabase array. For example, you can delete all of the array entries from the Aurabase. The Max keyframes will still be there, but they would not get exported any longer because the export scripts don’t know about them. But you could still view them in Max. Vice-versa, you could delete the keyframes. The animation sets would get exported but they would be empty so your creature would be motionless.

A final point before we move on: one frame before and after each animation set the import scripts put a 'static' keyframe (the 'rest' position of the creature). This is to keep the last and next animation set from impacting this one (Max interpolates animations assuming a transition from the last populated keyframe to this one. Without these static keyframes you would have all sorts of interesting little transition motions carried over from the last animation set).

Basic Kinematics

Before we reconnect the pieces of our crab and animate it, I want to talk about kinematics. Kinematics and animation are not the same things. We’ve talked about animation as the process of generating frames/keyframes for your model so that it performs the actions you want it to perform. You don’t have to pose your character for every frame like they used to do in the golden age of cartoons – NWN can interpolate many of the intermediate frames from a reduced set (hence the name key frames). But you need to set enough to firmly define the motion you want your model to reproduce.

If that is animation, what is kinematics? Kinematics refers to the techniques you use to move the parts of your model around to create the keyframe poses. There are two main types of kinematics: Forward Kinematics (FK) and Inverse Kinematics (IK). You will typically use both FK and IK when animating a model so you need to understand both.

Let me try an analogy: if you pick up your lunch box (you know, the Star Wars one with the picture of Natalie Portman on it?) in your left hand and run down the street, what does your lunch box do? Provided you don’t drop it, it should follow you down the street. Why? Your lunch box is attached to your hand, which is attached to your arm, which is attached to your body, which is running down the street. That is FK – you move the parent object (your body) and the chain of relationships moves the lunch box (the child object) with it.

Now set your lunch box down and grab the door handle of that passing car (you’re still out on the street, aren’t you?) What happens? In this case, the car moves your hand along with it. This stretches out your arm, pulls your shoulder forward, and eventually drags your body along with it. At least until you smarten up enough to let go (don’t try this at home – this test was conducted by professional stunt people). That is IK – you move the child object (your hand) and it moves its parent and so on up the chain to try to accommodate that motion (until your entire body moves if necessary).

That is how kinematics works. IK and FK are two sides of the same coin.

Forward Kinematics

By joining the pieces of our model together we create an FK setup automatically. To do this properly, the pieces must be linked together in a specific order (from parent to child). In our case, what FK does is allow us to move one of the main pieces (a parent object) - like the crab’s body - and have the other pieces move with it.

First, set the pivot points of each piece to represent where the joint of the piece sits, and where you'd like the piece to angle from. You do this from the centre out (so the pivot points for the legs are at the top of the leg, not the bottom). Also, don’t forget to overlap adjoining limbs a bit so that when they move you don't create gaps between them.

First, focus on the main body parts. Ignore the other nodes (like hand, hand_conjure, etc.) for now – more on those in a bit. Let’s start by linking all of the main body parts together into chains to the base object from the extremities (in this case the crab’s legs inward to its abdomen). The tip of one leg is linked to the middle piece. That middle piece is linked to the top, and the top piece to the abdomen.

Image:Ccg fig 42c.jpeg

Test it by selecting the abdomen only and transforming it (rotate or move). The legs, claws, shell, everything except the nodes should move with it. Note that this inheritance is only one-way; if you select one of the tips of the claws you will find that it detaches and moves freely without affecting its parent. That is because we have not turned IK on yet.

Before we turn on IK, let’s talk about those other nodes (e.g., head, and head_conjure). The nodes are not actual geometry – they are used to indicate to the game where to place certain items or visual effects. Different types of creatures have different nodes. Here is an example if you were modeling a humanoid shape. The parts that contain actual geometry have a _g after them. The parts that are used as place nodes (e.g., where to put a sword in a model’s hand) do not have _g. You should be familiar with the geometry list from the tutorial on armor modeling:

headconjure 
  (node)

head (node)

head_g

neck_g

rbicep_g

torso_g 
impact

lbicep_g

rforearm_g

rootdummy

lforearm_g
lforearm (node)

rhand_g
rhand (node)	

Pelvis_g

lhand_g
rhand (node)

rthigh_g

lthigh_g

rshin_g

lshin_g

rfoot_g

lfoot_g

How does the hierarchy work in this case?

Just as with our crab, the extremities must be linked upwards toward the parent – which in this case is the torso_g (for our crab it was the abdomen, GeoSphere01). To finish the linking, this parent must be is linked to the rootdummy. For example, the hand is linked to the forearm, the forearm to the bicep, the bicep to the torso, the torso to the root dummy.

The head node is parented to head_g. The headconjure node is parented to the model base. So is the handconjure node.

The lforearm node is used for placing a shield. It is parented to lforearm_g.

The lhand and rhand nodes are for weapons. Simple monsters do not have hand nodes and cannot wield weapons. Large monsters do not have a lhand node and as a result cannot dual wield (the rhand node works fine though). These nodes are parented to lhand_g and rhand_g respectively.

The impact node is for animations of being struck and doing damage. It is parented to torso_g.

Rootdummy is parented directly to the model base.

As I mentioned, not all models have all of these nodes. Here is the list:

Make sure you have the appropriate nodes for your model and parent them accordingly.

Inverse Kinematics

Now let us turn our attention to IK. Inverse kinematics (IK) is not absolutely necessary when animating but it makes life a lot easier. It does the opposite of FK by having child objects affect their parents. It allows you to move an end body part and have it move the attached parts back up the chain. For example, if you want to raise a humanoid creature’s hand into a salute with FK, you would need to rotate the humanoid’s shoulder into position, then the forearm, then the hand. With IK active and the right constraints you can just drag the hand into position and the rest of the arm will follow. In our example, you can move the tip of one of the crab’s legs and it will bend and move the other leg segments to make a realistic pose.

IK helps when animating the creature because it makes posing much simpler. You will need to experiment with it a bit – while it may seem challenging to figure it out, I would not recommend working without it. IK and associated constraints are beyond the scope of this tutorial (it is more general modeling stuff). But if you want to use IK, now is a good time to set it up.

There are two ways to use IK in a modeling tool like 3dsmax: interactive IK or by using IK solvers. Interactive IK is the most basic form and with it you use IK to move body parts around as you go through the key frames of your animation sequence – hence the term interactive. After you have set up your FK chain (linked your objects) and set constraints on the joints, you can start Interactive IK from the IK button on the Hierarchy tab. This allows you to move your pieces around using the IK mechanics. To use FK, I generally turn Interactive IK off.

The alternate to Interactive IK is using IK solvers. With IK solvers you set the start position and the goal and let the IK solver figure out how to move the scene objects from start to finish. It is much more complicated to set up but it can be much easier to use when done properly. Look for a good tutorial on bones and IK solvers for details.

Bioware used the Inverse Kinematics in 3dsMax version 3.1 to perform their animation. The v3.1 animation capabilities (also available in 4.x) can still be found in Gmax and higher versions of 3ds max. This is limited to Interactive IK.

This technique is not as ‘good’ as the HI-IK Solvers of 4.x+. By good I mean HI-IK solvers are easy to use and produce natural results when set up properly (do not underestimate the work required to set them up). However, the NWN engine only reads key frames while HI-IK solvers minimize the number of keyframes in a scene. Consequently HI-IK solvers do not work directly with the NWN engine. The HI-IK Solvers can be used but they require 'baking' the object to calculate and embed the keyframes. Scooterpb’s tool has the ability to do this now (although it requires some tweaking after export to make it really look good).

Inheritance

The simplest way to animate your creature is not to animate it at all (or to animate as few actions as possible). What do I mean by that? NWN has the ability to inherit animations from a parent object. If you construct your model with the same objects as a standard model, with the same pivot points and object names, the same size and approximate shape, you can set that standard model to be the supermodel for your creature (you set this feature on the base model object). When you do this, NWN will use the supermodel’s pre-existing animations to control your model.

There are two main families of model type that define their allowed animations: Player (which includes the “Full” type from appearance.2da) and Simple (which includes Large).

Player animations cover the full range from spell casting and weapon animations to non-combat animation. There are 154 animations in a player model. Player animations are generally used for humanoid creatures (refer to the description of appearance.2da which defines Model Types).

Simple animations are for creatures and they cover a much smaller range. Most are combat, walking and running animations. There are 42 animations in a simple model. The basic models are arranged in a hierarchy that looks like this:

Image:Ccg fig 45.jpeg

What does this hierarchy show me? The NWN inheritance model means each creature model can have a superset that defines some or all of its basic animations. That superset can, in turn, have its own superset that defines some or all of its basic animations. And so on.

The Player (P) model types are generally used for player characters. They have as a superset a basic humanoid model (a_ba) that only defines special weapon animations (like 2-handed or 2-weapon animations). This model, in turn, inherits non-combat animations such as drinking and saluting from another model (a_ba_non_combat). Which inherits additional weapon and combat animations from a third model (a_ba_med_weap). This in turn inherits spell casting animations from the final model (a_ba_casts).

A variation on the Player model type is the Full (F) model type. This is generally used for humanoid creatures such as the dryad, etc. They have their own basic model that defines special weapon animations (a_fa) but this file inherits the same non-combat, medium weapon, and casting animations as the player types.

Simple (S) types (e.g., cats) define their own unique set of 42 animations (there is no base animation because they are too unique). Some Simple types inherit from another Simple model although this is typically only found in families of creatures (e.g., the Lion inherits from the Dire Cat).

Large (L) types are special as well (these are monsters like demons that have Simple animations but can wield weapons). Like Simple types they usually define their own unique animations although they, too, can do limited inheritance. But Large types can wield weapons? How does that work? If you look at the table below there are no weapon animations specific to Large types. The answer lies in a special rhand node you will find in these models. Armed Large type models simply attach a weapon to that node and then go ahead and use the same combat animations as a non-equipped character. So your Frost Giant attacks in the same way regardless of whether he is using his fists, a club, a spear or a toothpick.

There are exceptions to this hierarchy. Some Full model types override some of the inherited animations (e.g., the Dryad changes some of her animations from the normal human type). There are a few other base models including a_da that are used for special models (a_da is used for the dwarves because the human animations do not scale so well to such a small size).

Below is a table that includes the labels of all of the allowed animations and whether or not they are applicable to certain model types. It also includes the flag which can be used to invoke this animation as a scripted event.

Note one more exception: the a_fa model does not include a plslasho animation. I assume this is an oversight.

Each animation has a tranisition associated with it on the edit rollout. Transition is the amount of time the game takes to blend from one animation segment to another: .5 is a reasonable amount for most animations but look at existing models to get the right mix. The lower the number the less blending between, the higher the number the longer the blend takes.

You can accompany each animation with a list of events. These typically trigger sounds or other effects to make the animation livelier.

The sounds that are played are determined by whatever soundset you assign the creature. Not all creature soundsets have all sounds or least differant sounds for each possible event but it does not hurt to put them in. The trigger will not break if it cannot be played.

Tips and Best Practices

Those are the basics that you need to know about how NWN requires you to handle animations. I don’t cover animation in detail (walk cycles, etc.) What I will do is include a few hints and tips (most of these come from Jupp who does a lot of work on the City of Doors Initiative and Haelix).

When choosing whether to use inheritance or to model from scratch, you really need to look at the model and how well it maps to an existing model. If it is close (e.g., a humanoid), then you are best to start with a supermodel and customize only those animations that truly lend a unique look and feel to the creature. If it is not close, it still helps to see if you can map animations to specific parts of your model. For example, scooterpb’s 3ds Max plugin has facilities to load animations from a second model file and attach them to parts of your model.

Alternately, you can import the creature whose animations you want to use in gmax alongside your model. Then copy the base object over to your object. You now have a list of all of the animations you need and starting timeframes.

As a third option, start with a blank slate. Import the creature whose animations you want to use. Then import your customized model along side it. Attach the parts of your model to the corresponding parts of the base creature. Delete the base creature’s parts and you will have your new model with the full animations intact to use as a starting point.

Once you have worked out your starting point, it is time to animate. Select the base helper object. Select the edit tab and it should show the animation rollout. In that rollout you will see a list of all the relative animations. This should be your starting point.

The basic pattern for animating a specific animation sequence is this:

1. Double click to select the animation sequence you want to work with. The times will be advanced to the start and end of the animation sequence.
2. Copy the at-rest keyframe to the beginning of the animation sequence. This is the keyframe of the model in the default, at-rest position.
3. Copy the at-rest keyframe to the end of the animation sequence. By putting the same keyframe in the first and last positions your creature will animate smoothly from rest, go through the motions, and then come to rest in the same place again. All of this without jerky transitions.
4. Move out to the first keyframe you want to animate.
5. Turn on the ‘Animate’ button and move all the needed parts to position the creature for that keyframe.
6. Go to the next key and repeat 5 until you are satisfied.
7. Go back to the start and play this sequence. If there are anomalies in the movement correct them one keyframe at a time.

It helps if you take another model from NWN and import it into your scene together with yours – put them side-by-side (obviously, choose a model that comes as close to yours as possible in shape and movement). Now you can watch the animations together to get an impression of what each sequence is like.

Here are a few tips on creating clean, small animation files. Check these after you have finished animating your creature and delete invalid keys:

• Some objects should have no animation keys attached to them. These are:
  • The aura base object
  • Headconjure node
  • Handconjure node
  • Head node
  • Impact node
  • Any control objects you have created that are not part of the geometry
• The other nodes (rhand, lhand, and lforearm) can rotate independently of the hands and forearm if necessary to keep the attached weapon oriented properly.
• Only certain key types are valid:
  • Rotation keys are valid and most objects use them (except for the previous list)
  • Movement keys are usually only valid for rootdummy. Since it is the parent of all of the other objects, move rootdummy around to move your entire creature. Everything else is a rotation around rootdummy. If you have a ‘shrinking-expanding’ object that moves like an accordion (well, only angry battle-attack accordions move on their own but you know what I mean - where segments stretch and contract) you may be able to violate this rule (may be able to – I haven’t tested this).

• • Scale keys are invalid. The game engine does not use them.

Part 6: Soundsets

Now that we have our monster moving, it is time to get it talking. Review the section on voicesets. Creature voicesets use the monster template and follow all of the rules in that tutorial. By adding a custom voiceset we can create the clicking of the crab’s claws in anger, distress, etc.

Before we close out on this section, let me make a distinction between creature ‘appearance soundsets’ and ‘voicesets’. We talked about ‘voicesets’ earlier in this tutorial and that information applies to creatures as well. ‘Appearance soundsets’ are another beast entirely. They reflect the ambient sounds a creature makes – an example would be the sound a creature makes if you hit it with a sword. For the sake of completeness, here is appearancesndset.2da. You only need to modify this file if you want to add a new type of sounds to accompany a creature. Otherwise, pick an appropriate row and use it for your creature in appearance.2da.

Part 7: The Creature Blueprint

To give your creature appropriate statistics, skills, feats and special abilities, you need to understand how to create a custom blueprint. A blue print goes into a specific module. Take our crab and all of the files we created (2da files, portraits, etc.) and put them in a hakpak. Attach the hakpak to your module. Create an instance of your creature in the Aurora toolset (like we did in Part 1).

From here you can set the portrait (from Part 3), the voiceset (from Part 6), the description, and the attributes of the creature. Now save our crab by exporting it as an .erf file (Exported Resource File). It can now be packaged together with your hakpak and distributed to others to use (do not load it into your hakpak – a .erf file is imported into the NWN Toolset separately using File | Import…)

Part 8: Danglymesh

Danglymesh is used to create neat effects like hair that sways when you move and flags that blow in the wind (and Aribeth’s jigglyness but we won’t talk about that here. Much.) You achieve it by adding a Flex modifier to your editable mesh in 3dsMax or Gmax. Once you have added it, select the Flex modifier. With it highlighted, you can adjust the flex parameters:

1. Period – how quickly the object moves and how fast it comes to rest.
2. Tightness – how much ‘tension’ there is in the object restricting movement.
3. Displacement – how far the object moves. This value corresponds to the Flex parameter in Max. It represents the amount of the flexed animation that is used (the amount of motion and factors like tightness determine the extent of the flexed animation. A setting of 1 causes the flexed animation to occur unmodified; higher settings cause unnaturally high amounts of stretching, and lower settings cause diminished stretching.

The next step is to paint the weights of the vertices of your mesh to indicate how much each vertex is affected by these jiggly parameters. Drop down the detailed parameters of your Flex modifier and choose the first one. Each of the vertices will appear in a different color. Red vertices are not affected by the Flex modifier much if at all. Yellow vertices are strongly affected and orange is somewhere in between. In the rollout menu you will see an option to paint the weights to change these colors.

At this point there should be no weights associated with any part of the mesh so each vertex painted should appear as pure red. Set the following in the Weight Properties section:

1. Paint Str: -0.1 - all vertices you paint will be start to turn orange or yellow
2. Radius: select a radius that is small enough for you to see the entire brush
3. Feather: 0

Now paint the vertices you want to move with the Flex modifier. Generally, vertices close to a stationary object (say at the base of a ponytail) would be closer to red than those farther away (say at the tip of a ponytail).

You have to export your model and import it into NWN to test these values. I would suggest editing the ASCII model file directly when testing instead of continually going back into Max to adjust and export. You can test danglymesh in the Aurora toolset (grab and shake the object to see how much it responds to movement).

Part 9: Skin and Bones

Most of the NWN animations follow the simple rigid animation techniques we talked about in this section. However, NWN also supports a skin and bone system. The difference between a skin and bone system and rigid animation is simple: with rigid animation, we simply transform and rotate the rigid mesh objects that make up our creature. With a skin and bone system, we move the ‘bones’ (a series of connected, invisible objects) and the bones actually stretch and deform the connected skinmesh to reflect the movement. In the case of rigid animation, all of the vertices in an object rotate around the pivot point of that object. In the case of a skin and bone system, the vertices of the skin rotate around the bones that they are attached to instead.

Skin and bones systems are much more realistic – if set up properly – but they are also more complex to produce, more taxing on the performance of the game engine, and skinmesh objects do not cast shadows in the game.

Scooterpb’s export scripts for 3dsmax support bones and skin for your mesh models (sorry, Gmax does not). Here is some sage advice from Scooterpb on using them properly:

You have to be careful to connect them to your model in a way that's going to be friendly to the NWN game engine. Scooterpb has fixed bugs with skin object import and export in every version of the plug-ins that released, and expect there to still be some set-ups that use skins that may not export properly.

If you want to use bones, here are a few rules to follow:

1. Be sure you need bones. You can attach an HI-IK Solver directly to the component parts in your model - so if you're not dealing with skins, you probably don't need bones (i.e., animate the rigid parts of your model). Having said that, bones do behave slightly differently in the UI than parented meshes do, so you might want them to be able to use some of the more advanced properties (e.g., doing a full two-way character rigging with independently moveable joints and controllers).
2. Do not use a skin to attach a bone to a mesh if the mesh is going to behave like a rigid-body object. In other words, if it is not behaving like a skin (with multiple weights for different vertices), don't make it a skin. If you just want to have the mesh match the movement of your bones, parent the mesh directly to the bone.
3. Link the root bone of your hierarchy to the model helper object, just like any other part. Otherwise, the bones in the chain won't export.
4. If you are using skins, parent them to the model helper object ONLY. Don't parent them to any other part in the hierarchy. Doing so can crash the model viewer and probably will not work in the game either.
5. Pay careful attention to how you set up the hierarchy for your model if you use bones. If you set up a completely different hierarchy for your model because of your bone structure, the game engine will find it difficult to match up a supermodel to your model. This means you will not be able to parent your model to existing animations. Probably not a big deal for entirely new creatures because they often need their own animations. However, if you are creating a PC or Full type creature, those 150+ animations will be time-consuming if you have to do them from scratch. If you are careful about how you match invisible bones to your supermodel’s animations, you may be able to get away with re-using the supermodel. Think it through beforehand.
6. If you make your creature from a skinmesh it will not cast shadows in and of itself. However, you can add non-rendering geometry to the model that will cast their own shadows (although they won’t typically be animated and they won’t match the skinmesh directly).

Batinthehat’s Notes

Here are Batinthehat’s notes on using skinmesh in NWN. Bat claims the information is by no means definitive, but I’ve yet to see anybody do better or improve on it much.

1. Modeling the skinmesh
   • The sort of blending you are going to use for the skinmesh should affect the way you model: If you are using Rigid vertices (vertices move with only one bone, looks less fluid but less of an impact on CPU performance) then you need to define each skinmesh 'segment' clearly or it will lose its shape when it deforms. In an arm for example the bicep should not sit straight on top of the forearm, you need some polygonal padding between the two sections. This will do all the deforming, and the overall shape of the bicep and forearm will be retained.
   • NWN also supports four bones per vertex blending - this takes more out of the CPU but looks much more naturalistic - you can also be a little less stringent about modeling the joints correctly). So far I've not noticed any real slowdown when comparing rigidly weighted models with blended ones.
2. Chopping it all up
   • If the skinmesh part is going to be influenced by more than 10 bones split it up into several chunks. I bisected the manticore at the waist and made the head, tail and wings separate parts as well. I haven't been able to get Scooters plug to export a skinmesh with 15+ skin bones without errors, so I generally play safe and stick to around 10 bones per part. Scooters plug probably supports more that this but I've not checked it out fully.
   • With the Bio scripts you have more leeway - larger, more complex skinmeshes with up to 17 bones are possible. Chopping the model up is still a good habit to get into however, especially if you are creating variants. You don't want to spend ages re-weighting the entire thing if you are just going to be altering the head.

1. How does max determine where on the skinmesh the bone pulls?
   • The size and shape of the bone is actually not that important - it only really affects the way Max draws the initial envelopes of influence. Basically any vertices on a skinmesh that are attached or weighted to a bone transform around the bones pivot point rather than the pivot of the skinmesh. If the vertices of the skinmesh are weighted to several bones they'll sort of average out their rotations/movements etc between the bones pivots, based on how heavily they are weighted to each individual bone.
   • Think of the envelope as determining the "loyalty" of the skin mesh to the bone’s movements. If you increase the concentration of the envelope past the actual bone, it will move as if the bone where longer/wider than it really is (depending on the concentration and the presence of other bones).
2. Prepping the mesh
   • Center the pivots. Each part that you'll apply skinmesh to should be ResetXformed. Collapse the stacks on each skinmesh part & fix the direction of the normals. Everything needs to pass an STL check so drop the STL modifier on top of each part and cap all holes, make sure there are no loose vertices etc.
   • Once everything passes an STL check you should collapse and link each part to the model base (or to another object that is ultimately linked to the base). Make sure that each skinmesh part has an individual name, or it won't render properly in-game.

1. Apply Skin
   • Apply the Skin modifier to one of your skinmesh parts. Select Add Bone and add the relevant mesh parts as bones. For a simple lower body robe this would be the legs, shins, feet, pelvis. I usually add the nearest neighboring bones as well, i.e. the torso and let it influence the edges of the skinmesh; it makes the transition between individual parts more seamless.
2. Weighting the mesh
   • There are two ways of weighting the skinmesh - you can either alter the position, scale, falloff, etc. of the envelopes to approximate each bones influence or you can collapse the envelopes entirely and paint the vertex weights by hand. For low-poly NWN models I find it easier to paint by hand – it is a bit more time consuming but it causes less problems with blending. It also offers more control over the way the mesh deforms.
   • Expand the Skin modifier and select Envelopes. Clicking on one of the greyed out bones in the viewport or in the rollout will display the envelope of influence. On an unmodified model these will probably be overlapping. If you switch your viewport to a solid view and turn on edged faces you'll see that each vertex within the envelope is given a color. The color of a vertex is a visual representation of the amount of influence the selected bone has over it.

1. Collapse the envelopes
   • First thing to do is collapse the envelopes. Click on one of the circular radius control handles and either move it to the centre of the bone or type 0 in the radius part of envelope properties. Do this for the other envelope radius and for all the other bones.
2. Painting weights - first pass
   • Select one of the bones and click on the Paint Weights button in the skin rollout. For the first pass of the weighting process it is a good idea to block the model out with rigid vertices (each vertex tied to only one bone) and check if it works without error in NWN. Sometimes rigid weights are all that is needed, though you might need to blend the weights if the model demands it or deforms badly.
   • At the moment there should be no weights associated with any part of the mesh so any vertex painted will appear as pure red. But just to make sure for the next bone set the following in the Weight Properties section:
     1. Paint Str: 1.0 - all vertices you paint will be turned red
     2. Radius: whatever is appropriate
     3. Feather: 0
   • Now paint any vertices you want to move with the selected bone.
   • Select the next bone and repeat the process. If you're using a model with existing animations you've got the luxury of checking out how the skinmesh deforms. The dusty was based on the a_ba_non_combat super and needed quite a lot of edge turning under the skin modifier before it looked alright.
   • Once you've done the same with any other skinmesh parts check it in-game.
3. Blending weights - second pass
   • Select a skinmesh part you've blocked out with rigid vertices, select Envelopes and in the Weight Properties section:
     • Paint Str: 0.1
     • Radius: whatever is appropriate
     • Feather: 0
   • Now it is just a matter of over-painting neighboring vertices until the mesh deforms in the way you want. Something to bear in mind with blended skins in NWN is that only 4 bone weights per individual vertex are supported.
   • So tread carefully or horrible things will happen.

Finally, let me add my own observations about skinmesh:

1. PC Skinmesh
   • Refer to the tutorial on PC creatures for details on how to set up a PC model. If you want to use a skinmesh as part of a PC model, there are some rules you must follow:
     • Parent the skinmesh(es) directly to the Aurabase object. The bones must follow the usual hierarchy so that they animate properly but the skinmesh ties directly to the Aurabase. This is because the skinmesh is not transformed directly by the animations – it is transformed by its dependency on how the bones move.
     • Any bones weighted into the skinmesh must appear before the PC nodes in the model hierarchy (more specifically, before the geometry-based PC nodes – it is okay if the bones appear after pure nodes like headconjure, handconjure, and rootdummy). Because of this, you cannot use a skinmesh in place of a PC component piece – it must be part of the main model pfx0 or pmx0. The hierarchy that works best for me is:

	Base object
		- Headconjure
			- Handconjure
			- Skinmesh(es)
			- Rootdummy
				- Bones
				- PC model nodes

1. • • If you break this rule, you will get strange behavior where some nodes of the skinmesh get caught up in your geometry nodes and stretch out of proportion. How did I discover this? Blind luck. I happened to do my first model in this order so it worked. I did my second in a different order and it did not work. It took some detective work to figure out why. Here is the Wemic hierarchy chart:
       • Image:Ccg fig 45b.jpeg

« Custom Armor and Clothing | Creatures | Custom Races »

Main Page | CCG TOC