Improved Collision Handling news - Drag[en]gine

The plan had been to do some more work but a bunch of nasty bugs showed up recently which absorbed quite some time to get rid of. In general though a few things still could be done while a few others have to move on the back burner.

Collision Detection Fixes and Locomotion Improvements

While improving the locomotion system quite a problem showed up with an incorrect sphere-box swept test. Getting this one fixed and working properly consumed quite some time but had to be fixed since player models tend to be represented by spheres and boxes are the best way to represent buildings. Had to go for my own implementation to deal with this problem. In the wake of this a few other collision detection issues had been tackled.

With this problem out of the way the locomotion system could be tackled. The existing system sill has some troubles and is not generic enough yet for my taste. The humanoid locomotion system has been now changed with a new version with a better organized work flow, being more stable and having parameters to alter for different player actors. The basic locomotion with parameters works also for dragonoid characters. This new system splits now the locomotion up into different parts allowing for Animation LODing where desired. In general the process works like this now:

1. Determine movement parameters (is it moving? what direction? what speed? what animation to use?)
2. Physics module carries out kinematic simulation
3. Project to ground (determines body tilt and offsets for proper placement)
4. Apply Animator (all kinds of actor specific animations as determined by 1 including tilt/offset from 3)
5. Apply IK Animator (make feet touch ground)

The nice part on this system is that to create LOD variations of the animation one just has to skip later steps. For example there are 4 possible LOD stages for animations in general:

1. Full animation with tilt and IK (all steps)
2. Full animation with tilt(steps 1, 2, 3, 4)
3. Full animation (steps 1, 2 and 4)
4. No animation (steps 1 and 2)

Typically these are applied on distance hence 4 would be the farthest away and 1 the closest. IK is usually the most time consuming step with full animation (animation blending and procedural animations) following with some distance. Applying no animation at all is obviously the fastest. These choices are all done on the game script level so you have full control if you want to use such loding and in what way.

Multi-Colliders and IK

To get multi-colliders eventually working a few changes had to be made especially adding proper support to Bullet for Rigged Colliders. Rigged Colliders are similar to Component Colliders with the only difference that Component Colliders work with a component (a player model for example) and a Rigged Component only with a rig (the skeleton of a player for example). The later one is important for multi-colliders.

Multi-Colliders simply refers to using multiple colliders for scene geometry instead of only one. Trying to move a player actor up stairs for example results in an unpleasant experience since the player is in many games a sphere or ellipsoid and pushing such a sphere up stairs feels exactly like that: pushing it up there. A solution to this is using a separate mesh for player movement (for example a ramp instead of stairs). This though is rather restrictive though. The Drag[en]gine on the other hand allows to use instead multiple colliders for individual scene geometry. Since colliders only collider when their layer masks have at least one bit in common you can create various levels of colliders for example one level for thightly fitting scene geometry or one for smooth player AI or more for handling different kinds of player actors. How many layers you use is up to you and colliders can be also used for mutliple layers if required (for example flat ground is plat ground for all so it has all layer bits set instead of using 3 colliders). In the DragonScript Scripting Module this is implemented the way that scene geometry has 1 Component Collider (the tight fitting collider) and additional Rigged Colliders for player movement and more. The reason why not all are Component Colliders is that a Component Collider manipulates the attached component hence only one should be attached to a component at each time. Rigged Colliders though are independent so perfectly fitting for the purpose of adding additional logic. The image below shows the stairs in the building on the left side with the tight fitting rig and on the right side with the player movement rig. Both are individual rig files on disk so they can be easily modified and exchanged if required. As you can see in the player movement rig the railings are solid all the way down. This way player movement works as you would expect it no matter how the geometry looks yet still a rag-doll for example would properly get caught in the railings as it is affected by the tight fitting layer.

In addition rig resources have been expanded with IK parameters. These are the typical parameters to limit the direction in which a bone can be rotated during IK calculation and matches in general the parameters Blender uses. Unfortunately the IK solver is still having quite some issues. For some reason I can't get it working yet the way it should. But that's not important for a first release as it's Animator Module specific problem and therefore goes on the back burner for the time being.

Outlook

With this engine work done some game related work is next. A new HUD prototype has been done and some game mechanics will be changed but more next time.