DEVBLOG 9/16/2012

Animating Characters – Part 1 Setup

Apologies, Its been awhile since my last DevBlog however there has been alot going on here at DAE.  First off, we have been redoing almost all animations and implemented new changes to the characters.  So, we listened alot to the feedback we have been getting and one of the top criticisms has been the character’s look and animations… except for the dancing.  Everyone seems to love the dancing while playing, in a negative way.  Anyways, we looked at what we could do to improve the player motifs.

Visuals:
The look of the players has many considerations, and we wanted to avoid common pitfalls we ran into before such as:

1) Implement an easy but advanced rig across all of the players
2) Create a common baseline for shared animations that could be re-purposed across similar skeletons
3) Avoid model interpenetration such as jewelry, backpacks, side strapped knives,….ect.  Specifically, the backpack on Ben was horrible to animate around and still look real(it currently looks subpar in the current game).
4) Avoid the common weightmap issues with collapsing skin folds by using double knee joints, double elbow joints, and better shoulder rotations
5) Topology..topology…topology.  It is very important that the edgeloops are in the correct places in the finger, knee, and shoulder geometry.  The biggest importance is to have the proper amount and placement of edgeloops on the face for believable facial animation.

We decided also to add another dimension to the game, which I won’t talk much here maybe in a future blog, about player options.  We removed the player’s clothes and implemented a body armor that is given to you by the first High Priest of the game.  This suit now allows you to put the gained crystals into its slot for additional special abilities.  You get an innate ability based on the color of the crystal such as increased speed, damage…ect and then one special attack that can be used when needed during battle.  This was something I personally wanted to add to the game a long time ago, but the logistics weren’t feasible then.  So, this not only solved some of the afore-mentioned problems but gave another dimension to the gameplay which was needed.

Implementation:
Well we started working with new concept artists to come up with the new design shown here .

We then started to build a new skeleton system for our new character.  The problem that we faced is that there were alot of ways of doing this but how do we choose the technique that will work good with the Source Engine.  We ended up just trying ones that made sense and testing them.  During this process, we learned even more about the Source Engine and what things you really need to watch out for.  Here is a picture of our Double Knees and Elbows.  We also added 6 additional bones to each arm to control the twisting of the skin in different poses.

Quake C
For those that don’t know much about the Source Engine there is a process of getting models and animations into the engine that really isn’t documented well.  Sure, you will find a useful tidbit here and there but virutally nothing on the new DMX system.  For this reason, we use all of our skeleton animations with the SMD format and the facial animations with the DMX format(I won’t even get into that topic right now).  Okay so what does that mean, well we do the following process:

The problem is #3, writing the QC file is the worst part of this entire process because much of the process is tribal knowledge.  I had the pleasure to work with some of the QC guys during my visit to Valve and they pretty much said “good luck” as they have alot of problems with it also and when they have problems they just make new code options to fix it (undocumented externally).  Luckily, the guys were kind enought to give some example code and run us through some issues we were having.

IK Chains
Okay, the major problem that we ran into using the new double jointed skeleton was with Source’s IkChains.  If you use Maya to create your skeleton and rig there is a common technique that most people do to save time.  They create the left leg and arm then mirror it over so its exact.  I guess the other important thing to point out during the skeleton process is that you must have all of your bones pointing along the POSITIVE X axis to the next child bone.  We do this during the creation process but when you mirror the arm and legs over, the X direction gets reversed pointing away from the child bone.  None of this stuff really matters in the source engine so you could actually be pointing with the Y axis and the animation will work in the game without issue.  My point is that we got the skeleton in the game with a standard idle animation with the arms flapping and legs broadway kicking without any issues.  We then spent a long time building a Rig to go over the new skeleton, and created several base animations.

We were kicking ass as we started to move forward faster with the animations, but then the bomb exploded.  We started to use QC to code the blends together for really good looking animations.  Here is an example of a simple(lol) animation not including the code for the aimmatrix layers.

//*******QC Run Example Code
$animation a_runidle “idle_energygun_119.smd” noautoik frames 0 0 numframes 80 loop alignto Idle_Standing_Align_G1 cmdlist IK_to_BBox
$animation a_runN “run_N_gun1_47.smd” noautoik fps 30 startloop 0 frame 0 47 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runE “run_E_gun1_38.smd” noautoik fps 30 startloop 0 frame 0 38 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runW “run_W_gun1_39.smd” noautoik fps 30 startloop 0 frame 0 39 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runS “run_S_gun1_35.smd” noautoik fps 30 startloop 0 frame 0 35 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runSW “run_SW_gun1_33.smd” noautoik fps 30 startloop 0 frame 0 33 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runSE “run_SE_gun1_35.smd” noautoik fps 30 startloop 0 frame 0 35 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runNW “run_NW_gun1_39.smd” noautoik fps 30 startloop 0 frame 0 39 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1
$animation a_runNE “run_NE_gun1_41.smd” noautoik fps 30 startloop 0 frame 0 41 fixuploop -4 4 LX LY loop cmdlist IK_to_BBox alignto Idle_Standing_Align_G1

$sequence RunN_PumpShotgun_layer “run_N_gun1.smd” fps 30 startloop 19 frame 0 47 fixuploop -4 4 x y z loop iklock lfoot 1 0 iklock rfoot 1 0 weightlist PELVIS100ARMS0 worldspace hidden
$sequence RunN_PumpShotgun_arms ”run_N_gun1.smd” fps 30 startloop 0 frame 0 47 fixuploop -4 4 x y z loop ikrule lhand touch “wrist_R” weightlist CLAVICLES_ONLY hidden
$sequence Run_Pumpshotgun {
a_runNW  a_runN    a_runNE
a_runE  a_runidle  a_runW
a_runSW  a_runS    a_runSE
blendwidth 3 blend move_y -1 1 blend move_x 1 -1 loop
blendlayer RunN_PumpShotgun_layer 0 0 0 0 local
addlayer RunN_PumpShotgun_arms
addlayer aimmatrix_gun1
fadein 0.5 fadeout 0.5
activity ACT_RUN_PUMPSHOTGUN -1
{ event AE_FOOTSTEP_RIGHT 9 }
{ event AE_FOOTSTEP_LEFT 18 }
{ event AE_FOOTSTEP_RIGHT 28 }
{ event AE_FOOTSTEP_LEFT 37 }
}
//*******QC Run Example Code

What this does is:
1) takes a character animation in each of the directions ( N NE E SE S….) and blends them according to its poseparameters
2) blends 2 layers ontop of the previous animation for holding the specific gun type
3) blends in the aimmatrix posed animations depending what where the player is looking controlled by the mouse also via poseparameters
4) Creates a fade in/out from/to the next player animation
5) add events to play footstep sounds based on what frame the animation hits the ground

Finally, I’m getting to where the problem happened, we started to have the left hand slip off of the gun while running full speed and free looking with the mouse.  How do you solve this problem?  Well this is where we started to use IK Chains as means to “take over” the animation instead of relying on the multiple blending layers.  Source IK will actually allow you to manipulate an animation realtime such as “locking” the left hand bone to the gun bone so it doesn’t flap crazy in the air.  Its actually very easy to use.  You just tell it what bone is the endpoint such as the “bone.wrist_left” and it will go up three bones to the shoulder automatically..voila an ingame IK chain similiar to Maya.

When we turned the IK Chains on for the arms and legs, the Right leg and arm flipped backwards…ahhhh!! what the heck happened.  Long story short, we ended jumping into the code to figure out that the IK Chains are hard-coded for the Positive X direction only…..Great news for us as we had done alot of work up to this point(sarcastic).  Luckily, I was able to detach the right arm/leg from the character/rig and fix it.  We carefully Edited the Rig and with some smart choices were able to adapt the rig controls to use the existing animation library without any rework besides re-exporting all the animations again.  In total, we only had a setback of 5 days but it could of been alot worse.  Here is the PIC showing the bones pointing in the WRONG direction for the right side:

Bringing this DevBlog to the end as it is long, but it seems that even with major planning, the best plans can have a big hitch.  Its really the thought process on how to fix the problem that ends up being the solution   Happy Gaming!!! -Dev Out