A fundamental challenge when designing a game centered around hordes of zombies is how to render a large quantity of animated characters.  A number of solutions exist, but none of them were quite suitable for Dead Shift.  In this post I will introduce a new(?) technique I’ve developed for skinned mesh instancing (aka. crowd rendering) that addresses many of the issues with the one proposed in GPU Gems 3 (and adapted for XNA), making it better suited for crowds of important characters who may require animation techniques such as motion blending.

To start, here is a quick overview of both techniques.

Original Technique:

• Bones are stored in absolute positions, so no blending is possible.
• Animations must be pre-baked at 30fps or 60fps resulting in large memory/storage requirements.
• Not suitable for rendering main characters, requiring a completely separate animation system for them!

My Enhanced Technique:

• Bones are stored in relative positions, along with skeletal hierarchy and bind-pos data needed to blend multiple frames/animations together at run-time.
• Animations can be pre-baked at lower framerates (15fps works nicely) which drastically lowers memory/storage requirements.
• Animation Processing is decoupled from Rendering, allowing arbitrarily complex blending/tweening routines on the GPU and re-use of processed frames between passes (ie. shadow-depth)
• Suitable for all characters in a game, unifying all animation into a single system.

The process for my technique is as follows:

• Pre-bake animations as usual with the GPU Gems 3 technique; output Relative Matrices, NOT Absolute Matrices.  We’ll refer to this as the “AnimationTexture”.
• Store the Inverse BindPos as a frame in AnimationTexture, you’ll need this at runtime.  I find it’s easy to place this at Frame 0.
• Store the Skeletal Hierarchy in a Texture for run-time access… This can be a separate texture, or simply packed into another dummy animation frame.  The important thing here is that we’ll need our shaders to be able to look up the Parent BoneIndex for any given BoneIndex…
• Write an “Animation Processor” shader that reads frames from AnimationTexture for each character instance and generates a new texture, we’ll call this “FinalAnimationTexture”, in the format of the original GPU Gems 3 technique. Each character will need to be assigned a RowID within this new FinalAnimationTexture to read their processed frame.  Hint: If you use Multiple Render Targets, you can spit out all 3 pixels of a bone matrix at once… This eliminates the need to process bones 3x.
• Render Characters as usual, the only difference being that characters reference RowID in FinalAnimationTexture, instead of FrameID in AnimationTexture…
• If bone data is required on the CPU, wait a frame and read it back.  I’ve found it far more efficient to first process all bone data we want to read back into a single texture to avoid multiple GPU to CPU transfers.

The beauty of this technique lies in the “Animation Processor” shader.  Because we don’t need a World Matrix at this stage, we can easily process over 200 character animations in a single draw call.  Also, nobody says you have to use a single “Animation Processor” shader, you could write any number of shaders for different types of animation such as Inverse Kinematics.  All animation frame data simply needs to be written to FinalAnimationTexture, so perform this step however you please.

Now, I’m far too lazy to draw diagrams, write sample code, and go into extreme detail… Sorry!… Feel free to ask questions if you’re interested, and I’ll do my best to answer!  I just wanted to put this idea out there for anyone struggling with a similar problem.

Some useful nuggets of information:

• In order to perfectly sync bones between the CPU and GPU without horribly stalling the GPU, you may have to use the processed animation data from 2-3 frames back (depending on your architecture).  This means keeping a backlog of FinalAnimationTexture copies and using outdated animation info to ensure, for example, that a weapon stays perfectly in a character’s hand.
• If you store your original AnimationTexture as Dual Quaternions (2 pixels per bone), it’s very easy to blend between frames/animations, and you use less memory.  The trick to interpolating dual quaternions is to compare them w/ a dot product and conditionally negate the second DualQuat to ensure blending moves in the right direction…  Interestingly, this step can be pre-computed at build time in the AnimationTexture so that any frame can be blindly lerp()’d with the following frame. *devious*

Come out and play!

Sometimes working on a game can be actual work… scary huh?  Recently I’ve been really getting down into the guts of my engine and adding countless little features, fixing little problems, and ripping out a little more hair…  Some of the changes since I last posted are… *drum roll*

• Added Proper Transparency w/ shadow-casting for grass, trees, etc…
• Fixed Depth buffer issues causing Early-Z probs, Shadow Acne, performance, etc…
• Added a Particle System (Dust, Blood)
• Added Vehicle Physics (something has to kick up dust!)
• Added Weapon Sensors / Injuries (someone has to bleed!)
• Added An Entity “messaging system” to control communication in a thread safe way… instructions like “you die now, I hit you” shouldn’t cause a race condition.
• Purchased a ton more models (houses, knives, machetes, guns, bats, etc, etc, etc, etc, etc, etc) and somehow my Skunkie hasn’t left me for spending money on such crap!

So what’s next?  Well, the DreamBuildPlay 2010 competition is coming up in less than 2 fekkin’ months! I’d really like to enter this year but I don’t know how realistic that is…  I need to rework the (bloated and complex) animation system to fix the horrible looking blending and add some much needed flexibility, and I really need to put more work into the physics and collision systems… If those two major issues work out quickly I may be able to throw something together in time…  Either way, I’ll try to get a new video together one of these days for my 5 or so die-hard fans!

Watch where you're going!

So I’ve been in a programming rut as of late.  I have gotten a little work done here and there, but for the most part I’ve been just sitting on the couch watching a seemingly never-ending LOST marathon.  I decided the other day that if I’m doomed to have coder’s block, I might as well search for some asset packs that I can throw into my game with little effort.  I found a great Broken Cars Pack over at Eivaa Games, and they were nice enough to re-export all of the models for me due to a compatibility issue with their OBJ files.  The pack has since been updated w/ more-compatible OBJ, as well as FBX versions.

So, let’s all be just a little bit productive and build a list of quality asset pack providers for indie game developers.

• Eivaa Games – Small collection (Broken Cars, Foliage, Props, Stones, SoundFX)
• Dexsoft Multimedia – Large collection (Sci-fi, Fantasy, Cartoon, Modern, Vegitation, Characters, Misc)
• FPSCreator – Massive Packs of Assets! (Environment, Props, Characters)
• 3DRT – Large collection (Characters, Vehicles, Environments)
• Evolver – Online Character creator.  Surprisingly high quality characters, and you can choose Format/LOD/skeleton/etc when you buy.
• Animeeple – Massive collection of Motion Captures/Animations… Accessed using (free) outstanding animation software… Compatible with Evolver
• GothaSoft – A single pack of Suburban Houses… They look quite nice though.
• 3d4ya – Medium collection (Characters, Props)
• 3dBud – Medium collection (Characters, Animals)… 3d4ya’s sister site
• GarageGames – Medium Collection (Large Environment Packs, Characters, Props, Sounds)
  • Warning: If you don’t use Torque, read the “Features” of each pack closely! I recently bought a “Combo Pack” and only some sub-packs were usable outside of Torque. Even the packs that specified they contain .OBJ files don’t seem to have them for every model… *grumble*
• Game Stuff – Large collection (Completed Game Levels, Buildings, Weapons, Plants)… A bit pricey/high-poly for my tastes.
• Darkroom Studios – Small collection, mostly repeats from Dexsoft, but some nice additions.
• MonsterPacks – Small collection (Haunted House, Graveyard, Sci-fi, etc)… These may or may not suffer from the same problems as other Torque (GarageGames) packs.

If you know of any other quality resources for asset packs, post a comment and I’ll add it to the list!

What is it with games and crates?

For over half a year now I’ve been tinkering away at my engine, hoping to create some amazing “Dawn of the Dead Theft Auto” game with hundreds of onscreen zombies interacting with thousands of physical objects…  To achieve this I’ve probably tracked down every managed physics engine/demo/snippet in existence, and what I’ve come to realize is that my time would have been better spent setting unicorn traps.  The fact of the matter is that XNA on the Xbox360 could never handle a simulation this complex unless the invading zombie horde was taking a siesta… or we were willing to sacrifice a bit of realism.

Thinking Last-Gen

While XNA is able to harness nearly all of the Xbox360’s GPU goodness, for reasons I won’t get into here we need to treat the CPU more like a Dreamcast.  So we need to ask ourselves if we want a small-scale realistic game, or a large-scale fun game?  If you’re shooting for the former, get the latest copy of JigLibX and make your life easy… If you belong to my unlucky camp and wish to make a large physics-heavy game, be prepared to write your own engine or think up a different game.

Zombie Physics 101

Learn From My Mistakes

While the physics in Dead Shift are far from complete, they’ve shown enough promise that I would like to share some of the things I’ve learned the hard way…

• Verlet Physics are no replacement for Rigid Body Dynamics.  Verlet systems may seem easy to design, but they are hard to control, hard to stabilize, and the countless constraints required will kill your performance anyway.
• Forget about fancy contact resolution, shock propagation, stacking, etc.  When you have a mind-blowingly fast engine, you can think about adding these things.
• You can approximate basically any shape with a series of spheres.  They’re easy to move around, they’re easy to test for collisions with, and you don’t have to worry much about coordinate spaces and costly matrix multiplications.
• KD-Trees are easier to implement than Octrees, and with a decent SAH (Surface Area Heuristic) they can be much faster too!
• Avoid building/clearing temporary Lists at all costs.  Have your collision detection test-as-you-traverse to avoid building lists of polygons or nodes.
• Split up work on multiple cores anywhere you can!
• Research XNA’s specific performance pitfalls on the 360.  Learn everything you can about the Garbage Collector, avoiding call-by-value functions, manual inlining, etc.
• Be prepared to lose sleep, and a bit of sanity.

Here are some resources that I’ve found useful for my little physics experiment:

• XNAMike’s port of some physics code.  I adapted an impulse response method from this sample.  [Forum Post] [Zip]
• Jacco Bikker’s explanation of KD-Trees. [Article]
• Olivier Renault’s example collision code.  Good example of OBB->OBB Separating Axis Theorem. [Forum Post] [Homepage]
• Ralph Morton’s “Icarus” physics engine.  I haven’t had much time to play with this, but it looks to be a very clean and basic engine.  No license, do what you want with it! [Forum Post] [Zip]

Edit (11/28/2009): Added some links to useful resources.

An old shot, but a good one.

Dead Shift is my first true attempt at a console game since I caught the bug about 20 years ago playing MegaMan 1 on the NES.  Over the years I’ve created various mini-games on everything from an Apple ][e, to DOS, to Windows, to a hacked up Dreamcast, but I’ve never made anything close to a full game before.  So when I heard that Microsoft was allowing independent developers to create games for the Xbox360, I dropped everything I was working on to learn more about 3D game development…

Body Harvest!

…was a game for the Nintendo64 that faced years of setbacks and underwent countless redesigns…  The game itself turned out rather buggy and lame, but what they were attempting was so inspiring that I’ve had it stuck in my head since they hyped it in the ’90s…  The idea of exploring post-apocalyptic towns and using what you find to kill off the invading horde is just plain awesome, so that’s what I’m attempting to recreate with Dead Shift… only this time, there’s Zombies, and it’s fun.

What’s the Status?

Currently, the graphics and game engine (codename: “ContagiumX”) is at a very usable point.  Features such as transparency, and better animation blending are lacking, but not absolutely necessary.  Dead Shift’s physics, on the other hand, are coming along at a much slower pace.  XNA has very poor performance on the Xbox360’s Compact CLR, and this makes physics and collision detection run horribly slow in large environments.  My solution has been to write a custom physics and collision system (codename: “SmashX”) that takes these very specific limitations into account, but writing this is no easy task!  As soon as I am able to get SmashX into a usable state (improved sphere->mesh collision, sensors, vehicles, characters), then we should start seeing some serious progress being made on an actual “game” prototype.

And Then What?

To be honest, I have so many ideas for Dead Shift that my head is at risk of exploding… but here is a rough list of the basics that I’m pretty sure will stick in the final game:

• An emphasis on atmosphere, cinematography
• An “open world” town with countless houses and stores to explore
• Hordes of “realistic” zombies.  No super-human powers, magic, reanimation, etc.
• Everything will be usable as a weapon
• Vehicles will be drivable