Happy Birthday, Miri

About a week ago we finished designing Miri, the lead character in Dead Shift!… Now if that isn’t a milestone, I don’t know what is.  So to mark this momentous occasion, I decided to fix our long-broken animation pipeline…  Just look at that face, she deserves a new animation system, right?

Dead Shift has used BVH (Biovision Hierarchy) motion capture files to animate characters since last summer (Note to self: Finish this fucking game already!)… While the captures themselves were nice, the outcome was less-than-stellar, and sometimes downright weird.  This was due to the complex nature of 3D animation and a little thorn in my side called Calibration: A process of joining the character and animation to an initial “Bind Pose” to ensure everyone’s on the same page.  This process is easy to accomplish in proper animation software such as Animeeple, but a nightmare to work out in kludgy XML files!

So I thought “screw it”, and deleted my entire BVH processor, my custom XML processors to calibrate and tweak animations/skeletons… even my most basic BoneContent processors, animation smoothers… EVERYTHING involving animation in the pipeline was scrapped…  I decided that I wanted all animations to be processed in a simple fixed-FPS manor instead of the crazy per-bone keyframe stuff XNA supports, so I wrote an all new set of “SimpleAnimation” classes.  These classes define animations as a list of keyframes represented by arrays of quaternion rotations and root offsets, and they can easily read from Animeeple’s custom XML format.  Here are some benefits of the new system:

• No Calibration!  Animeeple has already calibrated the animation to the model I’m working with, so I can just blindly copy the data
• Looks Great!  Properly calibrated animations have a wonderful quality to them… (as the next progress video will eventually show)
• Clean! Roughly 1/4th the code and complexity of the previous implementation.
• Predictable! We know that each frame contains information for all bones, which makes my life much easier!
• Features:  Because keyframes are so easy to deal with, I’ve already added things like Automatic Loop Correction, Resampling, Motion Tracking, Triggers/Markers as hints for character logic.
• New animation formats should be easy to support, but for now I’m sticking with Animeeple XML.

Downsides?:

• Models must be loadable by Animeeple, and my new zombie models aren’t… So I do need to find a nice way to convert and clean them up before they can go back into the game…

Please direct any questions and comments to Miri:

Happy Hunting

Ever wonder what's inside that freakish building?

There are a lot of people on both sides of the fence regarding Sketchup as a game development tool.  There are those who tout its ease-of-use, and those who hate the wasteful triangulation that gets performed at all contact points/lines/etc.  I recently decided to design my own levels for Dead Shift, and only rely on purchased assets for items, characters, and filler.  I chose to use Sketchup for this purpose because it’s the only 3D modeler my coder brain can comprehend.  There have been some caveats, so I’m going to share a few hacks and work-arounds for other developers in the same situation.

Problem: Triangluation
Sketchup’s Triangulation of the mesh generates many unwanted polygons.  This can easily slow down rendering and kill the performance of collision detection routines.  This happens because Sketchup considers every point on a plane important, even if the points are simply another object touching a wall.  A common worst-case scenario is extruded text placed on a wall, this will generate so many unwanted polys that it’s almost funny!

Solution:
When you have objects touching, try moving them 1cm towards each other (causing slight interpenetration), or 1cm away from each other (for a slight gap) if you prefer.  As long as the points/lines are no longer perfectly coplanar, they won’t affect the polycount!  I’ve reduced the polycount on a test level by 1,000 only expanding the walls slightly.  It’s a great technique, and allows you to create much more detail with fewer polygons!

Problem: Materials
Sketchup only supports a simple Diffuse texture, and that’s about it.

Solution:
Write a content pipeline extension (or something equivalent if not using XNA) that will parse an XML file and apply custom material info based on the exported material name.  Here’s a rough example:

Exported Material Name: “Bricks001″
XML Example Excerpt:
<Material>Bricks001</Material>
<NormalMap>Path/To/BrickNormals.png</NormalMap>
<SpecularPower>0.25</SpecularPower>

Problem: Entity Placement

There isn’t a good way to place entities without writing custom importer/exporter scripts.

Solution:

Create a material with a name such as: “Entity_MachineGun”.  Create a single-polygon component using this material that points downward.  From your pipeline extension, you can use the bottom vertex of each polygon as a placement position.  You could use other shapes, but I feel the triangle is easiest to deal with.  Note: Sketchup has a nifty little feature to have components always face the camera.

Problem: Collision Meshes
Sketchup doesn’t provide a nice way of managing collision meshes.

Solution:
Create a new Material named “CollisionOnly”, and make it a bright transparent color (to stand out).  Make sure your game is aware that anything using this material should never be drawn (using your pipeline extension, or whatever method you please).  When you want a complex shape to have a simpler collision mesh, simply create a bounding mesh using the “CollisionOnly” material, and make sure the visible shape’s material has collision disabled.

Simple collision mesh

Note:  If you place all collision shapes on a “Collision” Layer, it’s easy to show/hide your collision mesh while editing the level!  Make sure you follow the “Triangulation” tip to ensure the collision mesh doesn’t generate unwanted polygons… or it defeats the purpose!

Misc Tips:

• Always “Explode” your level before exporting.  I use the freely available BombAll.py script to automatically explode everything.

Todo:

• Decals might work nicely with Sketchup by using custom materials… hrmmm

Well, I’m running low on caffeine and should probably be getting back to work… That’s all for now, folks!

Good artists copy, I use Google Image Search

It took me an embarrassing amount of time and sanity to track down a bug that was causing every polygon in the game to explode, preventing me from working on anything else…  Apparently, on my Mac’s GPU at least, the POSITION1 semantic overwrites/conflicts/kills/destroys/violates the POSITION0 semantic, and I was happily using both…  *grumbles*

Anyways!…

In the tradition of Body Harvest, I’m foolishly designing Dead Shift as I go with no real plan.  Recently, Skunkie and I tried to work out the best possible location for the game based on the following criteria:

1. It must be a town that I’m capable of designing in Sketchup, which means simple architecture
2. It must convey a sense of isolation, atmosphere, fallen civilization, etc, and work well with wide cinematic camera angles
3. It must feel like a real place, despite being rather empty (due to my lack of artistic abilities).
4. It must be hard to escape on foot in real life… Muhahaha!

Amazing how much Dead Shift's renderer improves this crap.

The answer was a place we have driven through more times than I can count… A little town called Gila Bend (wiki),  located in the middle of an Arizona desert, about hour or so from the Mexican border.  There are cheesy signs, buildings, and sculptures sprinkled amongst the derelict buildings, motels, and gas stations.  I can’t imagine a more perfect location for a zombie outbreak, and you gotta love that welcome sign.  I’m not going to recreate the actual town, but I will be using it as a source inspiration.

With and Without Parallax Occlusion Mapping

Few things have the ability to slow the unstoppable juggernaut that is Dead Shift development… One of them is Prancer, our 17yr old Chihuahua, needing constant medical attention and trips to the vet/cardiologist… The other is a main sewer line backing up INTO OUR APARTMENT, flooding it with raw sewage, and forcing us to move into my parents’ living room while the poo is cleaned up…

So now that those figurative and literal shit-storms are over, I have gotten some work done, and things are starting to get back to normal.  However, we have made some changes in the direction of Dead Shift… *Drum Roll*

• Perfecting/optimizing SSAO has been taking far too long… so I’m dropping SSAO for the time being, and adding simple horizon-based ambient lighting.
• Acquiring decent level models has proven impossible… so I’m going to be designing the level myself using Google SketchUp because it’s simple and works well for architecture.
• Parallax Occlusion Mapping has been added to the engine to make it easier for me, a non-artist, to add perceived detail.
• The scope is going to be limited… I’m not sure exactly what that’ll entail yet, but I need to start being a bit more realistic if I’m going to finish anything.

So there you have it, now back to work!

Learning SketchUp... Go ahead, laugh.

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 double/triple/quadruple buffering FinalAnimationTexture 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.  Unethical pricing scheme: Edit a character, buy it again… But surprisingly high-quality characters… It’s a tough call…
• 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.
• Incompetech – Amazing collection of Royalty-free music… I love the “Horror” section.
• PanzerFlakes – Royalty-free Game Music… Decent collection…

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.