Skip to main content
GameDev.net gamedev.net
🔒 Locked

Bullet physics keep jittering about

Started by dascandy Jan 27, 2010 at 3:12 PM 8 replies 8.1k views
Original Post
dascandy
dascandy
Hi, I'm working on a remake of a 15-year old game. I'm currently trying to iron out the startup problems of getting all the parts of the engine to work together and the one I'm stumped on is the physics. The lighting is also still wrong (the shadows, at least) but that hasn't been given enough attention yet so I still expect to be able to solve that myself - so disregard that in the video. My problem is that everything that exists in the world keeps moving about as if there's some kind of inherent "keep-moving" force in each object. None of the objects has any forces applied whatsoever, either during startup or when running. Still, they keep moving as if there's some purpose to it. I can't find out what's causing this. What I do notice to be plain wrong is the distance between the boxes at the top. I'm fairly certain their physics models match up with their drawn models but they won't touch. I'll check on that later. What's also kind of odd (and for which the physics model does line up for certain) is the barrel that starts rolling towards the camera at about 0:10. I haven't a clue why it does that. I'm hoping that somebody recognises this problem from some kind of setting error or size error that I would be making. I'm very unproficient with Bullet so I am pretty sure (99%) that it's user error - but I don't even know where to start looking. The movie is at
">Youtube. Thanks, Peter
bzroom
bzroom
I'm not sure what the bullet terms are since i dont have the code in front of me. But it appears that you have no sleeping and possible are trying to achieve zero penetration. There is an allowed penetration factor which sould cause things to settle more nicely. Combined with sleeping, objects should come to rest.

Other areas of interest are your mass and inertia properties, friction, step time, solver type. Can you show us basically all your setup code? should be ~8-10 lines for the world and another 8-10 for the body. Anything with a parameter that you changed from the default.
dascandy
dascandy
Okay, here they come:

In the physics class definition as members:
	btDbvtBroadphase broadPhase;	btDefaultCollisionConfiguration configuration;	btCollisionDispatcher dispatcher;	btSequentialImpulseConstraintSolver solver;	btDiscreteDynamicsWorld world;


In the constructor:
Physics::Physics() : broadPhase(), configuration(), dispatcher(&configuration), solver(), world(&dispatcher, &broadPhase, &solver, &configuration){	world.setGravity(btVector3(0, -10.0f, 0));}


In the add-object function:

void Physics::AddObject(Object &object, ObjectType &objectType){	btVector3 fallInertia;	objectType.physicsModel->calculateLocalInertia(object.mass, fallInertia);	MotionState *motionState = new MotionState(object);	const Quaternion &rot = object.getRotation();	const Vector3 &trans = object.getTranslation();	motionState->setWorldTransform(btTransform(btQuaternion(rot.x,rot.y, rot.z, rot.w), btVector3(trans.x, trans.y, trans.z)));	btRigidBody::btRigidBodyConstructionInfo constructionInfo(object.mass, motionState, objectType.physicsModel, fallInertia);	TODO_W("Fix this damping / sleeping threshold stuff - it still jitters");	constructionInfo.m_angularDamping = 0.3f;	constructionInfo.m_linearDamping = 0.5f;	constructionInfo.m_linearSleepingThreshold = 0.2f;	constructionInfo.m_angularSleepingThreshold = 0.2f;	constructionInfo.m_restitution = 0.5f;	btRigidBody *body = new btRigidBody(constructionInfo);    body->setFriction(0.9f);	world.addRigidBody(body);	object.physicsHandle = body;}


In the movie the damping was 0.002f (for both). If I read this damping as I think it should be read (I think it's a factor per frame) then any object should lose about 99.999999999999% (rounded off) of its velocity every second. After a full minute they're still jittering about - the shading keeps changing so they're not sleeping. One of the boxes (the one in front of the fence in the movie) does come to rest now.

The first problem I found - I had started modeling with the assumption that a unit was about 25 cm, then rescaled it to 40 without fixing the physics models. All physics models are either a primitive or a a compound primitive (in this case, the box is literally just a box and the barrel is two cylinders).
Dirk Gregorius
Dirk Gregorius
First I would suggest that you use default damping values. I also recommend setting the restitution to zero. Then what margins are you using - keep the defaults here as well? What collision primitives are you using (boxes or convex meshes)? Finally what is your timestep? Use a fixed timestep of 1/60 ms at ~10 iterations.

Bullet has a great forum so I suggest to ask your questions there!


-Dirk
bzroom
bzroom
Here's literally all i'm doing on rigid body creation. Things work pretty great right out of the box. My world is in metric units. If your world is not then you'll need to scale all of your values appropriately as documented in the help docs.

if (mass != 0) colShape->calculateLocalInertia(mass, localInertia);			motionState = new btDefaultMotionState(startTransform);btRigidBody::btRigidBodyConstructionInfo rbInfo(mass, motionState, colShape, localInertia);			body = new btRigidBody(rbInfo);


World creation:
collisionConfiguration = new btDefaultCollisionConfiguration();dispatcher = new btCollisionDispatcher(collisionConfiguration);broadphase = new btDbvtBroadphase();solver = new btSequentialImpulseConstraintSolver;dynamicsWorld = new btDiscreteDynamicsWorld(dispatcher, broadphase, solver, collisionConfiguration);dynamicsWorld->setGravity(btVector3(0,-10,0));
bigneilm3
bigneilm3
Make sure to clamp your forces with tolerances to zero out (make them stop) once they slow to a certain point.

Also make sure the rendering engine doesn't have to paint the screen unless something changed.
JustChris
JustChris
One thing you might want to check is your step simulation call. Bullet recommends you use the default 1-parameter call so that maxSubSteps is always 1 and fixedTimeStep is 1/60.

I am also new to Bullet and never had a many problems with this though, unless I used a very large number for fixedTimeStep (like 1/5). The larger your fixed timestep, the less computations the engine has to do within a certain time but it creates more inaccuracies with the simulation.

Usually objects are ruled out from collision checking once they reach a certain velocity and don't get checked until another object comes in contact with it. But I never dealt with setting dampening thresholds or any similar adjustments.
Electronic Meteor - My experiences with XNA and game development
dascandy
dascandy
Inspired by bzroom 's hint about removing the custom code I had that I thought would fix it, I removed all the settings. I had set them way higher before which kind of fixed it; removing them altogether seems to have stopped the objects just about fully. If I'm close enough I can see they haven't frozen but they don't keep jittering about. I'll post a new movie online when I get more behaviour in.

Thanks for the help! I'm going to need it again if/when I do need to use those settings...

JustChris, I'm calling it with a 1/60th second timestep and max 5 substeps (because my laptop can't get over 15fps atm - new one is on the way). That wasn't it for me. Thanks for the tip though.
bzroom
bzroom
Make sure that you never pass a dt of zero to bullet. It will cause problems with the interpolation.
dascandy
dascandy
Quote:
Original post by bzroom
Make sure that you never pass a dt of zero to bullet. It will cause problems with the interpolation.


Thanks for that tip. I'm pretty sure (as my current average dt is about 100) that that won't be the problem right now. It may be in the future though.

On a sidenote, I have a new youtube movie that shows the physics working a lot better now - instead of uncontrolled jitter I can now create an explosion. Thanks again for the help!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.