Terrain-Foot Contact for Character Animations in T3D
by Robert Walter · in Torque 3D Professional · 06/09/2009 (8:30 am) · 13 replies
I haven't been able to find a recent or specifically T3D thread on this, and as I'm interested in using a third-person camera view in my game, I'd like to know what level of quality T3D is capable of with regard to the contact between the terrain and the feet of animated biped characters.
Of course they're only demos, but characters always seem to be floating in the videos and demo T3D projects I've seen.
Is there any plan for a built-in system for this? Is there a resource? Can anyone point me to some video examples? And if it is possible, is there a lot of engine tweaking involved to achieve quality results? (I'm an artist, so I have to ask!)
I hate to bring up the competition, but Unity seems to have a pretty cool "locomotion system" ...
http://unity3d.com/support/resources/unite-presentations/walking-and-running-on-uneven-terrain
http://unity3d.com/support/resources/example-projects/locomotion-ik
In short, is this quality possible in Torque and how?
Thanks!
Of course they're only demos, but characters always seem to be floating in the videos and demo T3D projects I've seen.
Is there any plan for a built-in system for this? Is there a resource? Can anyone point me to some video examples? And if it is possible, is there a lot of engine tweaking involved to achieve quality results? (I'm an artist, so I have to ask!)
I hate to bring up the competition, but Unity seems to have a pretty cool "locomotion system" ...
http://unity3d.com/support/resources/unite-presentations/walking-and-running-on-uneven-terrain
http://unity3d.com/support/resources/example-projects/locomotion-ik
In short, is this quality possible in Torque and how?
Thanks!
#2
06/09/2009 (10:35 am)
Ahh another billion dollar feature that I would love to see in T3d =]
#3
Floating characters and ugly mesh penetration are some strong pet peeves of mine, so I would really like to avoid that in my own project.
06/09/2009 (11:19 am)
Thanks for the responses. Good to hear that "they are working on a better solution". That sounds somewhat hopeful — but would it be in the coming T3D retail release? Or is that way down the road?Floating characters and ugly mesh penetration are some strong pet peeves of mine, so I would really like to avoid that in my own project.
#4
Lets hope GG come up with something awesome!
06/09/2009 (11:20 am)
Its one of my pet peeves to, along side the Gun penetrating through objects and terrain >.< Lets hope GG come up with something awesome!
#5
There is no easy solution for this feature.
We need two additional boxes for each leg,both conformable.
06/09/2009 (12:42 pm)
The presentation is very edifying.There is no easy solution for this feature.
We need two additional boxes for each leg,both conformable.
#6
One could move the character's bounding box bottom up until its pivot is a bit above the knees. Then, use raycasts for each feet to keep the character suspended above the surface underlying it and adjust the blend animation for each leg. As a bonus, the character will be able to climb any step height lower than the bounding box bottom without the need for the stepHeight mechanic.
06/09/2009 (12:54 pm)
I've done something like this for four-legged characters years ago, using blend animations for the legs running in their own threads, and using the result of ray casts to adjust the blend animations positions. However, for two-legged characters more changes would be needed regarding the collision.One could move the character's bounding box bottom up until its pivot is a bit above the knees. Then, use raycasts for each feet to keep the character suspended above the surface underlying it and adjust the blend animation for each leg. As a bonus, the character will be able to climb any step height lower than the bounding box bottom without the need for the stepHeight mechanic.
#7
However the collision is the easy part.
You are right for that we should use two additional animation threads for each leg.
This threads will control blend animations.
I mean creating and adjusting the animations is the tricky section.
On the presentation they didn't show what happens when the leg steps on an edge.
It is intentionally adjusted where he steps,he never hits an edge.
And he never trips up like the mantling code.
I also spot the camera is moving along a path.
It is not moving along a target point or following the terrain.
06/09/2009 (1:09 pm)
If we wish to create four-legged characters, we can use just a vehicle.However the collision is the easy part.
You are right for that we should use two additional animation threads for each leg.
This threads will control blend animations.
I mean creating and adjusting the animations is the tricky section.
On the presentation they didn't show what happens when the leg steps on an edge.
It is intentionally adjusted where he steps,he never hits an edge.
And he never trips up like the mantling code.
I also spot the camera is moving along a path.
It is not moving along a target point or following the terrain.
#8
Unfortunately there are a fair amount of things you have to know about the way Torque handles node transforms and the like to integrate such methods. Really IK isn't for the faint of heart :p
06/09/2009 (1:48 pm)
If you want your character's feet to meet the ground, you're basically going to have to do some sort of inverse kinematics. Which means you'll also have to change the method of determining standing states (raycasts are okay for this, but really you want to use a volume for the feet). I wrote the IK solver for the BeTheDinosaur project here at Sickhead, which ended up being a pretty big task (though, now that we've done it, it's actually fairly easy to get working). I suggest taking a look at the IK solver in Blender's codebase, as it uses one of the best techniques for doing IK, though it's more complex than the quite simple cyclic coordinate descent method.Unfortunately there are a fair amount of things you have to know about the way Torque handles node transforms and the like to integrate such methods. Really IK isn't for the faint of heart :p
#9
I expect we'll have something like this kind of approach (capsule bounding boxes for the player) either at release, or very soon after.
06/09/2009 (10:42 pm)
You're right, that's a nice resource, and something Torque 3D probably won't support out of the box. However, an IK animation system is something we'll be looking at closely in the next year. In the meantime, there are other solutions than the method this Unity resource uses that achieve basically the same result without the costly IK computation. Rather than use a box to bound the player, you can use other shapes for collision. A capsule shape is one that's commonly chosen for 3rd person viewing. This gives you pretty cheap collision computation, and much better looking footsteps. Many high-end games do this, and don't use IK. You can get even better accuracy by tuning the collision bounds per player or per player AND per weapon. I expect we'll have something like this kind of approach (capsule bounding boxes for the player) either at release, or very soon after.
#10
I'm using a capsule myself, but my players don't need to collide with any stock objects. The only thing that prevented me from truly replace the AABB with a convex is that most of Torque's collision routines expect Convex objects to return polygons and planes and thus aren't usable with procedural convex shapes like spheres and capsules.
06/10/2009 (6:49 am)
A capsule would be a godsend. The AABB gets easily stuck in corners, while a capsule could slide along anything but full frontal contact. The capsule also fixes the "floating on the bounding box's edge" issue, since it will slide downwards if it's XY center is not supported.I'm using a capsule myself, but my players don't need to collide with any stock objects. The only thing that prevented me from truly replace the AABB with a convex is that most of Torque's collision routines expect Convex objects to return polygons and planes and thus aren't usable with procedural convex shapes like spheres and capsules.
#11
06/10/2009 (11:14 am)
Wouldn't the natural and best solution be the integration of a locomation system?
#12
06/10/2009 (5:22 pm)
@Marc: An IK locomotion system is nice to have, but it's expensive. It's also totally unnecessary for the vast majority of games made. In a few more years, it might be one of those things that more games are using and most people take for granted because the hardware is so much more powerful, but I doubt you'd want to try to make much use of this on any kind of low-end hardware or embedded device that exists today except PS3 / Xbox 360. So it's kind of a niche feature.
#13
I'm an artist and not a programmer, so I'm all for anything "out of the box" that can help me make a better (and better-looking) game. And as one who would not likely be able to create my own fix or workaround, you've definitely got my vote for a capsule to be included in the release!
06/11/2009 (6:09 am)
Very interesting responses, y'all. Way over my head, but interesting all the same!I'm an artist and not a programmer, so I'm all for anything "out of the box" that can help me make a better (and better-looking) game. And as one who would not likely be able to create my own fix or workaround, you've definitely got my vote for a capsule to be included in the release!
Torque Owner JesseL
Pyrotronics-Games