Strange gravity/force issue

mcaden

28-08-2008 06:37:32

I've implemented my character movement like so:

void Character::translate( Real rtrans)
{
Vector3 trans = mBody->getGlobalOrientationAsOgreQuaternion() * Vector3(0, 0, rTrans);
mBody->addForce(trans, NX_IMPULSE, true);
}


With rtrans being my movement speed(-mMovespeed/2 for walking backwards).

This seems to work great except for one thing. Apparently my character is drunk. He doesn't move in a straight line. He'll veer to one side just slightly, then later veer slightly to another side.

The veering seems to be completely random. It'll veer to one side, I'll restart the app, and it'll veer to the other side over the same patch of ground. The ground is completely flat. The collision is a cube set to the same size as the ogre mesh's bounding box.

The problem seems to arise from trying to get gravity to work.

mBody->addForce(NxVec3(0, -mBody->getMass() * 1.5, 0), NX_IMPULSE);

This causes gravity to work, but while active causes the veering issue explained above.

betajaen

28-08-2008 07:56:07

It may be friction; causing it to turn slightly. Have you tried locking the rotation of it?

mcaden

28-08-2008 08:54:57

ROT_X and ROT_Z are locked, I need ROT_Y because I have to turn the character.

betajaen

28-08-2008 08:56:50

Alright. Lock ROT_Y for a moment to see if it is the friction, if so we can come up with some code to emulate Teflon.

mcaden

28-08-2008 11:13:20

Locked ROT_Y - still moves forward/backward erratically

syedhs

28-08-2008 12:52:57

My suspicion is this: the combined vertical impulse and the force applied along Z axis has caused the resultant forces diagram to be like this:-



instead of:



That is just from my guess when applying vehicle downward impulse every frame because the vehicle accelerates faster this way. The workaround for this is to apply impulse not in exactly along y axis but probably a bit slanted toward back (looks like backslash) so that it cancels off the effect.

mcaden

28-08-2008 13:59:10

Your images aren't showing up for me.


I'm assuming you're suggesting

/
->O


instead of


|
->O


I understand different forcing causing motion problems, but I've only really thought of this when the 3rd axis is thrown in. But rotation along 2 of the axes are locked, and I'm only applying force on 2 axes as well so I wouldn't imagine. I'll give it a shot though...not saying you're wrong, just that I'm not seeing it. :)



EDIT: Tried it, and it did nothing except slowing his forward movement. I tried -1 to the Z axis, -3, and -5 (at -5 his forward movement speed was slowed to a walk) - to no effect.

syedhs

28-08-2008 17:13:12

The downward force is still

|
->O

whenever the character is stationery.

But whenever it moves, you will need to cancel off the 'forward-effect' by calculating the angle (yes the angle is always adjusted depending on the speed) going backward. So when speed = 0, the downward force is (0,-1,0) and when the speed gets higher the z component shouldn't be zero. The character slows down because the z component in your impulse is a little bigger than needed. But I am afraid I dont have the calculation in hand to calculate the y&z value according to speed, although it shouldn't be too complicated.

However, that is just a suggestion as I have not tried it myself, but it should be better than no doing anything. I will do this myself when I am upgrading my vehicle code. But I think there is a better solution out there - I dont know yet.

mcaden

31-08-2008 07:04:24

I think as a workaround I will make it so that it only pushes him down if he's not on the ground.

I'm not really liking it much. It doesn't make sense that it would do this.

If you take a cube in real life and push directly down with one finger, and directly forward on another in the exact center of the face it shouldn't deviate from a straight path....umm...at least I don't think it should...I'm not a physics expert =/