One system that is easily underestimated in games is the ground alignment that keeps the characters feet planted on uneven ground. If we were all making games where the ground was flat we wouldn’t have this problem but with the rise of third person games and especially open world games this is a problem that needs to be solved.
As with many problems in character animation this is something that can be solved to varying degrees of quality.
Dynamic ground alignment solutions are written to solve the problem of the character not having his feet planted correctly on slopes. The initial solution to this problem is to write or use a two bone ik solution that constrains each foot to the ground and then solves the bend of the knee to allow the foot to be placed higher than the animated position.
This is done by doing a raycast or shapecast from the position of the foot with an offset upwards and then setting the IK target position to that position + the offset of the foot compared to the ground plane (commonly just the zero plane).
Constraint solving is a topic that you can spend quite a few words on so I suggest looking at this article for an explanation on how to solve it in various ways (see the linked articles as well).
After the IK for the feet is applied the character will still be floating in the air and this is due to the capsule or other collision primitive pushing the pelvis of the character higher than the feet can reach, the solution for that is to balance the pelvis with the detected feet heights and it is generally a good idea for a human character to use the lowest foot position + the local space pelvis position as the new position of the pelvis.
One detail that I like is to have the foot IK constantly active, this is a technique that can be used to reduce animation compression artefacts as the compression imprecision increases the longer down a joint chain you go and if you are using a foot ik target joint that is a child of the root it will have less precision issues than the normal feet joints. You want to do this because compression artefacts like that are easier to spot by a player as they will notice the movement relative to something static easier when it’s something touching that static object.
Another benefit of having foot IK constantly active is that the foot will then react to the changing terrain and will look like it predicts the slope of the terrain, anticipating that the foot will land at a higher position than it was animated for.
Having that foot reacting to the change in height before the foot is planted solves for terrain and slopes quite well but for cases like stairs and geometry like buildings that is stepped rather than smooth this is not quite enough.
To achieve higher quality animation results while moving up and down hills or stairs it is a good idea to actually put content towards it. Utilizing just IK will only give you so much, while going up and down hills a character will change his pose in more ways than knee IK can achieve.
We attempted this just using poses and while that gives you a slightly better result it wasn’t nearly enough for human motion. The solution instead became a blend space of movement for different slope angles. Up, down and two animations for moving along the hill.
Utilizing ground alignment while having those animations does require you to annotate that these animations were authored for a certain slope and the way we achieved that was via a ground plane joint that was the parent of the foot ik targets. That way you can calculate the offset that the feet is above the ground accurately while those animations are being blended together.
Improving on the basics above require an additional investment and this is something that is much easier to tackle when you share tech between teams.
To have the feet not just reacting to changes in terrain and instead predicting the target you can add a system that has precalculated for each animation when the foot will be planted.
In Unreal this can be implemented with an animation modifier that measures the movement of the feet every frame and if that threshold is lower than a not moving threshold the foot can be considered planted. This can then be annotated as animation meta data or an animation notify state that covers the duration that the foot is planted.
With this information you know when the foot is planted and from that information you can calculate the transform that corresponds to the position of where the foot will be planted next for every frame in the animation.
Knowing where the foot will be planted will give you a target position that you can do raycasts/shapecasts against and that will allow you to create a virtual ground plane. With a virtual ground plane you can do a more natural interpolation for the foot and not react excessively to changes in terrain.
However it still only has two sample points and this is where a presentation by Ubisoft on Assassins Creed comes in handy. They essentially implement this virtual plane and then add additional detail to it by doing a shape query over the length of the foot move to catch all the intersection peaks inside that query. This allows the virtual ground plane to anticipate bumps in the ground ahead of time by creating a convex hull.
With that information you know that the feet will never need to go higher and your foot prediction can follow that shape. In case of dynamic obstacles coming in you will probably always want to use a raycast straight down from the foot.
Making the feet stand on valid terrain is a problem that is a hard thing to tackle as nearly every game use an approximate collision against the terrain to keep the character on valid geometry.
This is usually implemented as a capsule, cylinder or pen shape and one problem that commonly occurs is that the character can stand in air with one of his feet.
There are various solutions to this, some are as basic as not letting the capsule move off a platform at all and treat the edge as a wall. Other solutions trigger animations that move the character off the platform if the character is on his way off. Physics simulation solutions exist as well where an edge will be detected as a slope that makes the character slide off.
A clever solution was implemented by Horizon: Zero Dawn where they will do a second shapecast for the foot if the first one failed to find ground within its range. The second one is larger than the first and is designed to catch any geometry that was close enough.
If the second shapecast finds geometry what you can do is pull the foot towards that intersection point so that the character stands on something valid.
This is a nice detail and to make this work even better what you can do is also adjust the position of the pelvis and move it in towards a central position between the feet. Additionally if you are doing this dynamically during movement you can have the character moving along a ledge without creating an animation for that case.
Not really, there are details in the implementation that we have to consider. Every raycast or shapecast should be asynchronous and done for the foot position of the next frame as we want to avoid blocking the rest of the game waiting for the results.
Interpolating results, in action games where input latency is something players actively dislike it is important to have every system reactive to changes and sometimes those changes will change the predicted results greatly so it is important to interpolate even these results.
In animation driven games and where the characters move realistically this is not always necessary but it’s always best to avoid pops in animations.
So this is not really fully solved as long as we are using approximate collision for characters and we can only do incremental improvements. If full body simulation was something that became achievable and stable for character control then we would be able to move further towards realistic motion.