Walking on uneven ground
by Daniel Buckmaster · in Torque Game Engine · 03/01/2009 (9:21 am) · 6 replies
This is tricky. Players by default use a bounding box to collide against things. However, this has the nasty side-effect that if you're standing on sloping ground, the corner of the box collides and leaves both of the character's feet hanging in the air.
My first idea to solve this problem was to use blend animations to move a character down on one side, the side which has the furthest distance to the terrain. There's two problems with this: first, on mild slopes and with larger bounding boxes, you'll be adjusting one foot but not the other. Second, your character's bounding box is still hovering in the air above your head, so you'll collide against things that it looks like you should be able to get under.
My next idea is the one I want an opinion on. How feasible would it be to actually trim the Player's bounding box off at the knees, and add two 'spring' collision raycasts to represent the legs? This would also replace the 'stepping' system, which is a little jammy (the Player is just teleported to the proper position). With two raycasts, you could determine a proper height difference, apply some restorative force to keep both raycasts above the ground, and then blend two leg animations to get the right 'look' to the Player's pose.
My first idea to solve this problem was to use blend animations to move a character down on one side, the side which has the furthest distance to the terrain. There's two problems with this: first, on mild slopes and with larger bounding boxes, you'll be adjusting one foot but not the other. Second, your character's bounding box is still hovering in the air above your head, so you'll collide against things that it looks like you should be able to get under.
My next idea is the one I want an opinion on. How feasible would it be to actually trim the Player's bounding box off at the knees, and add two 'spring' collision raycasts to represent the legs? This would also replace the 'stepping' system, which is a little jammy (the Player is just teleported to the proper position). With two raycasts, you could determine a proper height difference, apply some restorative force to keep both raycasts above the ground, and then blend two leg animations to get the right 'look' to the Player's pose.
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
03/02/2009 (9:38 am)
Thanks for the support. I think I am going to do this - like you said, it will have the side-effect of giving te Player movement a little bouncy feel, as opposed to the hard default physics. This should actually be a reasonably simple change to make, for once :P. I just wonder about the performance implications of making two raycasts per player per tick. I wonder if that's more efficient than the findContact method. 
#3
03/02/2009 (10:39 am)
That sounds to me like an excellent approach. I wouldn't worry about the raycast performance. Two per player per tick is nothing. You wouldn't even be able to measure the impact without a profiler.
#4
03/02/2009 (10:41 am)
Okay, that's brilliant - thanks for the support :). I'll get on it as soon as my current resource obligations are fulfilled ;P.
#5
I've also found some problems dealing with the default Player movement code. The Player will automatically try to rest on the ground, but based on its own ground calculations rather than my raycasts. I don't yet want to totally remove findContacts, since it's a good solution and it works well. But it's also not the only problem - the Player class just seems to like slowing itself down :P. This means that even if you have one leg on the ground, you'll stop, instead of sinking so that the other leg is also on the ground. This only occurs when you've stopped on a slope and then you turn around - otherwise, it works well.
Stepping works, but there are a few issues when coming back to the ground - the Player doesn't seem to rest properly, and will slide along for a while out of control.
EDIT: I solved the stepping problem. Seems that my spring calculations were letting the Player rest just a little bit below his usual height. Since findContact only searches 3cm below the bounding box, it missed the ground. I got it to search in a 6cm height box instead, 3 above the 'ground' level, and it's working nicely.
03/03/2009 (8:10 am)
Despite my current resource obligations remaining unfulfilled, I decided to go ahead with this (it's more interesting :P). I've managed to work up some sort of solution, which actually behaves quite nicely. I have yet to make animations and deal with all the animation thread malarkey, so now it just means that one of Kork's legs sinks into the terrain.I've also found some problems dealing with the default Player movement code. The Player will automatically try to rest on the ground, but based on its own ground calculations rather than my raycasts. I don't yet want to totally remove findContacts, since it's a good solution and it works well. But it's also not the only problem - the Player class just seems to like slowing itself down :P. This means that even if you have one leg on the ground, you'll stop, instead of sinking so that the other leg is also on the ground. This only occurs when you've stopped on a slope and then you turn around - otherwise, it works well.
Stepping works, but there are a few issues when coming back to the ground - the Player doesn't seem to rest properly, and will slide along for a while out of control.
EDIT: I solved the stepping problem. Seems that my spring calculations were letting the Player rest just a little bit below his usual height. Since findContact only searches 3cm below the bounding box, it missed the ground. I got it to search in a 6cm height box instead, 3 above the 'ground' level, and it's working nicely.
#6
ata boy, thats the way to go. 8o)
03/03/2009 (8:28 am)
Quote:Despite my current resource obligations remaining unfulfilled, I decided to go ahead with this
ata boy, thats the way to go. 8o)
Torque Owner deepscratch
DeepScratchStudios