# How would I move a character In an RPG with Bullet Physics/Ogre3D?

lately I have been having problems with moving my character in my Ogre3D game. Basically I am moving the character with bullet's RigidBody->translate() function, but when doing so and bumping into a wall, I go slightly through it and then get bounced back. I am wondering if there is another good way to move my character(who has a sphere collision shape) around in a simple Plane-type world with walls?

The libraries I am using that are relative to this are 'Ogre3D' and 'Bullet Physics'.

Although I haven't worked with the bullet physics engine specifically, I've done something very similar in another physics engine. The way that I solved it was to set the rigid body's linear velocity instead of translating it directly. Movement and collisions were then automatically handled by the physics engine update phase.

From the documentation there seems to be a btRigidBody::setLinearVelocity method that you can use. So for instance, if you don't want any accelerations happening, just set the linear velocity to an appropriate value whenever the character is moving, and set it back to (0,0,0) when the character is supposed to stop (i.e. when the player releases the key).

As for which values to use, the usual approach would be to start with desired speed of your character (as a float/scalar) and then multiply it by a normalized vector that is pointing in the direction you want to move. From what I can see the btVector3 class already has methods for all of this.

Alternatively, you might consider treating the character as a complete physics object, and handle movement using either the applyForce or applyImpulse methods. These would result in a body acceleration, so your characters will have momentum and the results will probably look nicer this way. But you need to take some extra measures, for instance, by making sure the linear velocity never exceeds a certain limit, either by clamping it or playing around with damping/friction. So it will be a bit harder to implement and finetune.

Experiment with both approaches and then choose the one that behaves closest to your needs.

• Alright, thanks for the quick answer, Im going to try this out right away. – Molmasepic Mar 1 '12 at 4:27
• The LinearVelocity trick worked just as a expected like a charm! There were a few kinks that I had to fix up but its working 100% Thanks so much for the answer! – Molmasepic Mar 1 '12 at 5:48

For the record, my experience with physics is using Chimpunk in a 2D game engine, but I'm pretty sure this concept translates into 3D just fine.

I'm assuming that your character is a physics body with weight and such. The best way to do this is to do a very simplified simulation of walking. Think of it like this: If you're standing, your feet have a lot of friction, so you don't just slide around. When your moving, it's roughly equivalent to removing that friction (since you're not resisting the movement with your feet) and applying a direction force. I'm not saying that you should individually simulate each foot pushing on the ground -- a rigid body is what you want.

• When your character isn't actively trying to move, make their velocity damping high so that they'll remain stationary.
• When your character is moving, lower their velocity damping and apply a force in the direction of movement. Set your damping and force so that the character moves at a reasonable speed.
• If the character is in the air, set the damping very, very low. If you want to be realistic, don't allow them to apply any force to change their direction while in the air. You can strike a happy medium here by allowing them to apply a much smaller force, giving them some limited ability to adjust their trajectory while airborn.

Here's where get gets a little complicated:

• If the character is already moving and they change direction, you'll need to compensate for your momentum by adjusting the direction in which you apply the force. For instance, if your character is moving due north and turns due east, you need to apply your force in a direction that's half way between the opposite of the character's current direction of travel and their intended direction of travel. As the direction of travel changes, adjust the force so that it's always half way between the two, and your character will quickly and smoothly change directions.

If you tune your force and damping correctly, applying a force will always give you the most realistic result, particularly if the character is going to be pushing objects around. Translating is going to be the worst way to do it, since the physics engine doesn't really consider that to be movement. Setting the velocity directly is somewhat better, but in my experience the best results can be obtained by using force and damping.

Hopefully I explained this well enough. Feel free to ask if you need clarification. :)

For bullet 2.87 it appears the proper method is to have a tick callback that updates at the internal simulation update rate (possibly many 100s of Hz), and setWorldTransform() on kinematic bodies will smoothly update the position:

This part is in the manual:

// set the rigid body as kinematic
rigid_body->setCollisionFlags(
rigid_body->getCollisionFlags() | btCollisionObject::CF_KINEMATIC_OBJECT);
rigid_body->setActivationState(DISABLE_DEACTIVATION);
...


This part was more tricky to figure out:

void externalTickCallback(btDynamicsWorld *world, btScalar timeStep)
{
// get object passed into user data point
Foo* foo = static_cast<Foo*>(world->getWorldUserInfo());
... loop through all the rigid bodies, maybe foo has them
{
if (rigid_body->getCollisionFlags() & btCollisionObject::CF_KINEMATIC_OBJECT)
{
btVector3 kinematic_linear_vel = ... // get velocity from somewhere
btTransform trans;
rigid_body->getMotionState()->getWorldTransform(trans);
trans.setOrigin(trans.getOrigin() + kinematic_linear_vel * time_step);
// TODO support angular velocity
rigid_body_->getMotionState()->setWorldTransform(trans);
}
}
}
...
my_dynamics_world->setInternalTickCallback(tickCallback, static_cast<void*>(this), true);


This was helpful documentation in btRigidBody.h https://github.com/bulletphysics/bullet3/blob/master/src/BulletDynamics/Dynamics/btRigidBody.h:

///- C) Kinematic objects, which are objects without mass, but the user can move them. There is one-way interaction, and Bullet calculates a velocity based on the timestep and previous and current world transform.

setLinearVelocity() does not work for kinematic objects (maybe it used to in earlier versions?). But the dynamics world will understand setWorldTransform() and calls to getLinearVelocity() on the kinematic object will return the velocity set in the tick callback (it probably returns an average if those velocities were to change from internal tick to tick).

https://github.com/bulletphysics/bullet3/issues/1204 - the issue poster has the right idea but the response isn't helpful.