Creating physics constraints for orienting models up

Aug 1, 2009 at 11:32 PM

I feel all whiny asking lots of questions :P But here it goes.

The game I'm working on (Boogey-Ground), like most games, requires models to be at a certain orientation. Unlike some games, our "up" orientation changes (our level twists upside down on occasion)

The current fix was to create a simple physics constraint that each entity would update with their up and forward directions and Oops! would add a rotational force in the direction needed. This seems to work reasonably well except for 3 problems :P

1. Turning is slow, if I speed it up I end up with the model wagging back and forward as it's turned too much.

2. The models bounce off the level. I'm not entirely sure that this is the same problem, but it could be that somewhere something's telling it that it's rolling and it's working out how a cuboid would bounce on such a roll... my rotational forces could be not cancelling the rolling, I'm not sure, so far everything I've done has made my head hurt :S

3. We sink through the level. Ok, I'm pretty sure that this isn't the same problem, but I to be honest, I can't remember doing it before I added the constraint, so I'm not sure. The level is a mesh collision shape. It only seems to do it in certain places, or maybe that's because I only stand still at the beginning of the level.

Am I doing something stupid? Is there an inbuilt "you shall always be pointing up" flag that I can modify to rotate to face wherever I want?

Thanks yet again, and apologies for all the questions


Aug 2, 2009 at 12:46 AM

The RigidBody.Acceleration property is the gravity applied to "attached" collision shapes.  You can change this property to modify gravity on a per-object basis.  The default is, of course, a downwards force.  There is no "always be pointing up" flag in the physics.

Remember, the Position and Orientation properties on the RigidBody, CollisionGroup and CollisionShape classes are for physics simulation.  Nothing says you can't draw your characters in the correct orientation with a different custom property that you manage.  I do that in most of my games.  The RigidBody gives me the movement I want.  I use the RigidBody.Position and an orientation based on the RigidBody.Velocity and RigidBody.Acceleration to draw my characters.  For example:

Vector3 up = Vector3.Normalize(-RigidBody.Acceleration).

Vector3 right = Vector3.Normalize(Vector3.Cross(up, Vector3.Normalize(RigidBody.Velocity)));

Vector3 forward = Vector3.Cross(up, right);

Something like that...

Before attempting to get a character running around in your level, can you get a simple CollisionSphere rolling around in your level?  If you get that going, it may give you some insight on how to get your character working.  Just to warn you, the new code doesn't handle box-to-mesh collisions.  I'll be working on that here in a bit,

1.  Did your write a constraint that inherits from Constraint?  Constraints are pretty tricky to get right, especially for orientations.  It sounds like to me that you're adding to much Rotation or Torque when you apply your constraint each step.  What you might try to do is base your Orientation Constraint on the PointToPointConstraint in the framework and attempt to do the same steps.  If you need some help with this let me know.

2.  I think what you stated might be what's going on.  It would be hard to say so, though, because I'm not sure when you are applying your rotational force during the simulation step.  If it's during all other constraint solving there is a good chance collisions are still involved.  You can try and take into account these collision in your constraint but you might just give it a few more iterations to solve.  See, PhysicsComponent.CollisionIterationCount and PhysicsComponent.ContactIterationCount.

3. I think the sinking into the level is cause by your constraint.  I had the same issue with PointToPointConstraint until I added an extra iteration for constaint solving after integration.

I hope this helps.  I'll continue to help when and where I can.  Post some code as well.  That always helps.  Good luck.

Aug 2, 2009 at 1:19 AM


That's exactly what I needed. Turns out I was being a retard :P It never occurred to me that I should orient just while drawing... god knows why. As the other problems seem to be caused by the badly made constraint, I can now safely get rid of that and it _should_ work...

Wow... I really can't believe I didn't think of something that simple :S

Thanks again... a lot