BEPUphysics

Hi again,

This game I'm working on is a skiing game, and I'm looking into ideas on how to implement a skier character for it. I've been interested in attempting a dynamic character approach, using the "ragdoll" and positioning the feet, hips, shoulders, hands and head, and letting BEPU fill in the rest of the skeleton. I think that part should work ok, but I am wondering about the best way to simulate the actual movement (interaction of skis with the snow)..

I thought I'd try an approach of making each ski a vehicle and welding them to the ragdoll's feet, but found that they didn't stay welded too well (the welds weren't solid and the skis drifted around a lot). As much as the vehicle has the physics parameters that I'd need to simulate a ski (eg sliding friction, suspension), I'm not sure it's a good approach to use (obviously vehicles aren't really designed to be welded to the feet of a person)..

The main reason I would like to end up with the dynamic approach is that for flying through the air, it will be much more realistic than a kinematic approach (I think), since the rotation of the whole skier will be calculated using the inertia tensor for the whole body (I think).. Also I cna imagine that the actual skiing motion could end up being quite realistic using that approach.

So, do you have any recommendations on approaches to achieve this? Or is it just not going to work at all?

Thanks

There's a decent amount of complexity involved in just making a single capsule/cylinder ski down a slope, especially when tricks and other common things are implemented. Going beyond that can be needlessly painful.

To keep an articulated structure stable and robust in the face of extremely high relative speeds and forces, updates need to be run more frequently (120 times per second instead of the default of 60 for example) and more solver iterations will probably be useful. To avoid 'floppy' behavior, some system to blend animation driving and physical input is needed on top of any strict movement control.

To make it a tractable in terms of development time, some fakery is needed. It's likely that the difference between a fakery-filled 'physical' version would not be perceptibly better than a even more fakery-filled version (where the skiier is basically a capsule). In fact, a single capsule/cylinder-based version would probably end up being better because more time could be spent refining behaviors instead of trying to just get things stable.

The main reason I would like to end up with the dynamic approach is that for flying through the air, it will be much more realistic than a kinematic approach (I think), since the rotation of the whole skier will be calculated using the inertia tensor for the whole body (I think).. Also I cna imagine that the actual skiing motion could end up being quite realistic using that approach.

An inertia tensor could be precalculated for various poses, giving roughly the same result. Or, the rotations could be faked entirely too, allowing you to do whatever rotational behavior you wanted. Humans are pretty terrible at catching subtly wrong behavior, especially when things are going fast or there's angular motion involved.

My recommendation would be to go with a fixed-orientation dynamic capsule or cylinder. It could find supports like the CharacterController/SphereCharacterController by analyzing contacts, or like the SimpleCharacterController with a ray cast. In addition to the support information, you keep a movement direction at all times (the direction the skis are pointing). Remove velocity perpendicular to the movement direction on the surface, and maybe a little along the movement direction to simulate a tiny amount of friction. Then put the character on a slope and let him scoot around

Once in the air, handling rotation manually (rather than attempting to apply torques to a physical object) would be the easiest thing to do. That also minimizes the physical work you have to do when landing and such. A fixed-orientation character would pose a problem if you wanted loops, though- in that case, a forcibly surface-locked character that is free while in the air would do the trick assuming the character body isn't expected to be in stable collision with other objects. (Forcibly setting orientation to match a surface doesn't play nice with collision response; touching objects will 'squish' out.)

Great, thanks for this...
I have always been under the impression that to get him to ski down the hill in a truly physical way would be a major task in terms of stability. I will do as you recommend and try using a capsule based character for that part.

I still am inclined to want to use the ragdoll/skeleton's dynamic inverse kinematic properties to pose the model as he is skiing, by positioning feet, hips, etc in the correct places and letting BEPU create the final pose.. I'm wondering, is it possible to somehow separate the skeleton's capsules from the physical world to allow for this? (I'm thinking maybe have all the capsules' masses set to 0 might do it).

Going on from that, obviously I would like to have him able to ragdoll in a spectacular fashion in the case of crashing badly. What would be the recommended approach to "switch" between using the character capsule and the ragdoll?

Also, for the flying through the air/doing tricks point of view, I'm still thinking that using the ragdoll with some constraints to pose him in mid air will produce the most realistic results - I find that with these sorts of games that the airborne rotations (especially in the case of doing flips with spins), the rotation always seems to be quite unrealistic.. (Being into skiing in real life I know that the position you're in in the air is vitally important to how you rotate). I guess I'll have to think about it a bit more, and play around with it once I get the main capsule character thing working. But as you say, it could end up being needlessly complex, for instance how to actually control the rotation when you're in the air - in real life, obviously the only way to do this is by changing your "pose". I'm inclined to want to try and simulate it this way, as I'm trying to make more of a skiing "simulator" than an arcade-style game...

I'm wondering, is it possible to somehow separate the skeleton's capsules from the physical world to allow for this? (I'm thinking maybe have all the capsules' masses set to 0 might do it).

Setting masses to zero is one of multiple ways of making an entity kinematic. Kinematic entities do not respond to collisions and do not have dynamic behavior. Instead, they rigidly and perfectly follow the velocity given to them. A constraint between two kinematic entities would do nothing.

It would be possible to position final kinematic nodes and let the dynamic intermediate nodes try to meet those goals, but this is not equivalent to inverse kinematics. It would be extremely easy to get the bones in a configuration where the goal can't be met and things just start to spaz out. Solving spazzing would require a lot of care in configuring the constraints to avoid over-rigidity and also making sure the control bodies are placed reasonably.

In the cases where the bodies aren't spazzing out, it's likely that the dynamic bones won't behave like a human would. They would be floppy in some cases, pointing a weird direction in other cases, and just generally not doing so well.

That could be solved by making more of the bones control elements, but then you're basically just animating a character. If the goal is inverse kinematics, then it's probably best to directly implement inverse kinematics rather than trying to get forward dynamics to act a bit like it.

Going on from that, obviously I would like to have him able to ragdoll in a spectacular fashion in the case of crashing badly. What would be the recommended approach to "switch" between using the character capsule and the ragdoll?

The animation bones would be driven by the animation/inverse kinematic input. On switch, the ragdoll bones use their animation bone relationships to determine where they are placed initially. The correct velocity can also be computed from the animation and the current capsule velocity. Then, make the bones able to collide (add them to the space if they weren't already, or change their collision rules if that was how it was being managed, etc.).

While ragdolling, the animation bones reverse their relationship with the ragdoll bones- instead of defining the position of the ragdoll bones, the ragdoll bones define the position of the animation bones. You may find it useful to only include the relative orientation of physics bones in the graphical transform. The ragdoll bones themselves could separate somewhat during intense collisions (they are springs, after all), and it would be quite jarring to see someone's foot stretch away from their body momentarily.

If you wanted to get real fancy, you could include motors in the constraints connecting the ragdoll bones that weakly attempt to match a 'crashing' animation.

Also, for the flying through the air/doing tricks point of view, I'm still thinking that using the ragdoll with some constraints to pose him in mid air will produce the most realistic results - I find that with these sorts of games that the airborne rotations (especially in the case of doing flips with spins), the rotation always seems to be quite unrealistic.. (Being into skiing in real life I know that the position you're in in the air is vitally important to how you rotate). I guess I'll have to think about it a bit more, and play around with it once I get the main capsule character thing working. But as you say, it could end up being needlessly complex, for instance how to actually control the rotation when you're in the air - in real life, obviously the only way to do this is by changing your "pose". I'm inclined to want to try and simulate it this way, as I'm trying to make more of a skiing "simulator" than an arcade-style game...

Note that, for a ragdoll held by motors strong enough to rigidly stay in relative position, the rotation behavior is totally defined by a single inertia tensor which can be precomputed. The only thing lost by the precomputed approach is when the character isn't able to hold a pose properly.

Additionally, it is quite likely that the motors would not be able to keep things perfectly together when doing intense spins unless there was a pretty high update rate. The precomputed inertia tensor would probably end up being slightly more correct when compared against a real-life properly executed pose.