1. Collision and Animation Systems in Games Jani Kajala Lead Programmer / Chief Technology Officer, Pixelgene Ltd. Jani.Kajala@pixelgene.com +358 (0)45 6343767

2. (Other) Uses for Collision Systems  Finding contacts between objects (surprise!)  Visibility culling / probing ‒ Shadows (“What objects/polygons are inside this frustum?”) ‒ AI (“Are any enemies visible from this point?”) ‒ Camera (“Are there any walls nearby?”)  Triggering events ‒ IF player_collides_this_dummy_box THEN alert_enemy ‒ IF player_collides_another_box THEN show_cutscene

3. Simplify Problem (As Always)  Usually first idea is too complex  Simplify collision scenario as much as possible ‒ Simpler to implement ‒ Better performance (likely) ‒ More robust at the end ‒ Etc. etc…  Best if you can avoid collision checks totally!  Examples follow…

4. Minimize Number of Checks Needed  Usually many collision types can be ignored, e.g.  Camera collides usually only against level geometry (either static or dynamic), but not against e.g. player  Character doesn’t collide against Camera either  Bullets don’t collide against each other!  Bullets don’t collide with the shooter or the weapon  Only Player Character can collide cut scene triggers  Car tires might collide only with ground, but not other cars (unless cars can drive over each other)  Etc.

5. Implementation: Classification & Filter  Simple solution, you select category bit for each object group, e.g. level=1, camera=2, character=4, etc.  Then you define, for each object, ‒ A bit flags marking the groups which the object belongs to (e.g. PLAYERCHARACTER=PLAYER+CHARACTER) ‒ A bit mask saying which objects can be collided against  Check if the objects have common bits in their masks / flags or they can be ignored right away: ‒ IF (A.bits&B.category)==0 AND (B.category&B.bits)==0  SKIP A vs. B check

6. Simplify Shapes  Use simpler 3D shapes: ‒ Character = capped cylinder ‒ Car = box + 4 spheres ‒ Camera = sphere ‒ Bullet = Point (or line segment)  Use 2D if possible: ‒ Do characters need to be able to jump on top of each? If not then use 2D ‒ Can cars drive over each other? If not then use 2D

7. Character Collisions  Capped cylinder (capsule) works well for characters ‒ Turning/moving always ok due to symmetry of capsule ‒ Doesn’t get stuck on stairs as sphere on bottom ‘slides up’ the character over small obstacles ‒ Efficient to compute, also character vs. character collisions could be handled with 2D circle vs. circle test!

8. Collisions Against Level Geometry  Polygon detail level cannot be avoided (usually) ‒ Action happens inside the level so hard to approximate ‒ Counter-example: Racing game with collisions & ‘grass slowdown’ done based on distance to race track center line  When checking collisions against level polygons make object vs. single polygon check robust first! ‒ Everything else (BSP etc.) is just optimization (important)  Use your favorite tree structure etc. to optimize number of collision checks so you don’t need to check every single polygon in level ‒ BSP-tree, Octree, OBB-tree, AABB-tree, hash tables, or any combination of those and many others…

9. Integrating Animations to Game  Very much game specific tasks, e.g. ‒ When a character aims with firearm, we need position of the character’s hand, then place the weapon on the hand and aim the weapon to the target… ‒ We might need to find out velocity vector of a foot based on key frame data to avoid feet slipping when walking… ‒ Character can walk and aim simultaneously… ‒ Car might have different textures on tires based on speed (smoother textures to provide sense of motion blur)  Note that a single game object can have many animations and a single animation can be used by many objects

10. Generic Requirements  Support for hierarchy ‒ Characters can have more than 80 bones...  Support for low level transformation access ‒ Needed for aiming, turning tires, etc.  Manual (=by code) selection of ‒ Which (part of) animation to apply ‒ To which objects animation is applied ‒ When the animation is applied (or is it applied at all) ‒ How animations are blended ‒ What is done to object before animation ‒ What is done to object after animation  So simple scene playback is not enough (or is too much!)

11. Example: Character Walking  Simple state-based system: IDLE, WALKING, etc.  First, assume that character is in idle state  Next character blends to walking animation ‒ We can’t instantly change to another animation so we can either use transition animation or blend between two animations. This time blending is fine since standing is quite similar pose as walking  When character is in walking state, we need to move the character in game world ‒ We could use linear speed (as many games do), but we can do better by extracting movement speed from key frame data  When character stops we blend back to standing ‒ Remember to blend down the movement speed as well  By rejecting animation state changes between transition/blends we make sure character doesn’t jerk based on user input

12. Demo: Character Walking  (character_tutorial-divx.avi)

13. Aiming and Shooting  We simplify the situation by assuming that the character aims and shoots ‘quite much’ forward ‒ Makes potentially complex aiming really simple!  Now we need only to blend between aiming-up, aiming-forward and aiming-down poses based on tilt angle ‒ Simple linear blend between two animations will do ‒ Note that we apply this animation to upper body only  Finally we rotate weapon direction to match actual target direction (to give that last touch!)

14. Demo: Aiming and Shooting  (zaxdemo-0.5-divx.avi)

15. Summary  Simplify collisions (and everything else) before implementing  Don’t bother making too fancy animation systems, you need relatively low level access anyway  And last… BUY MY BOOK when it hits the shelves!!! ;) ‒ Making Game Demo, by Chad & Eric Walker and me, published by Wordware Publishing Inc. ‒ It has EVERYTHING… And MORE!!!  Another plug: Looking for game-dev job? Drop email at jobs@pixelgene.com  Thanks, Jani.Kajala@pixelgene.com