Multiple instances of btDefaultMotionState, all ignored, but one

To summarize the problem (s):

I have two bodies in my world, one of which is the earth, and the other is a falling box called "fallStar".

1) I donโ€™t understand why my bullet world is not aligned with my painted world unless I set the offset btVector3(2,2,2) to MotionState (btDefault). There is no magic magic anywhere in the code to explain the bias. Or at least I could not find any reason, and not in the shaders, anywhere.

2) I expected that I could use several instances of btDefaultMotionState , to be precise, I wanted to use one instance for the falling object and place it somewhere above the ground, and then create another instance for the base, which should just align with my graphics, never without moving.

What I am experiencing with respect to 2) is that for some reason, the instance of btDefaultMotionState for the falling object always also affects one for the earth, without any reference.

Now to the code:

Creating a fallBox:

 btCollisionShape *fallingBoxShape = new btBoxShape(btVector3(1,1,1)); btScalar fallingBoxMass = 1; btVector3 fallingBoxInertia(0,0,0); fallingBoxShape->calculateLocalInertia(fallingBoxMass, fallingBoxInertia); // TODO this state somehow defines where exactly _ALL_ of the physicsWorld is... btDefaultMotionState *fallMotionState = new btDefaultMotionState(btTransform(btQuaternion(0,0,0,1), btVector3(2,2,2))); //btDefaultMotionState *fallMotionState = new btDefaultMotionState(); btRigidBody::btRigidBodyConstructionInfo fallingBoxBodyCI(fallingBoxMass, fallMotionState, fallingBoxShape, fallingBoxInertia); /*btTransform initialTransform; initialTransform.setOrigin(btVector3(0,5,0));*/ this->fallingBoxBody = new btRigidBody(fallingBoxBodyCI); /*fallMotionState->setWorldTransform(initialTransform); this->fallingBoxBody->setWorldTransform(initialTransform);*/ this->physicsWorld->addBody(*fallingBoxBody); 

Now, the interesting parts for me are the necessary offset btVector3(2,2,2) to align it with my drawn world, and this:

 btTransform initialTransform; initialTransform.setOrigin(btVector3(0,5,0)); this->fallingStarBody = new btRigidBody(fallingStarBodyCI); fallMotionState->setWorldTransform(initialTransform); 

If I repeat this part of the code, all bodies again show an offset, but NOT just 5, which I could somehow understand if for some reason worldTransform will affect every entity, but 2.2.2 from .. which I cannot understand at all.

I think this line is useless:

fallMotionState->setWorldTransform(initialTransform); because it does not change anything, whether there or not.

Now to the earth creation code:

 btCompoundShape *shape = new btCompoundShape(); ... just some logic, nothing to do with bullet btTransform transform; transform.setIdentity(); transform.setOrigin(btVector3(x + (this->x * Ground::width), y + (this->y * Ground::height), z + (this->z * Ground::depth))); btBoxShape *boxShape = new btBoxShape(btVector3(1,0,1)); // flat surface, no box shape->addChildShape(transform, boxShape); 

(this part simply creates a composite shape for each surface tile :)

 btRigidBody::btRigidBodyConstructionInfo info(0, nullptr, shape); return new btRigidBody(info); 

Here, I intentionally set the motion state to nullptr , but that does not change anything.

Now Iโ€™m really curious ... I thought the implementation of btDefaultMotionState is a single, but it doesnโ€™t look like that, so ... why the hell does setting a single body motionState affect the whole world?

offset without btVector3 (2,2,2) for btDefaultMotionState

offset with btVector3 (2,2,2) for btDefaultMotionState

The position of my box and its body, as well as the offset

+7
c ++ game-engine bulletphysics game-physics
source share
3 answers

Bullet is a good library, but only a few devote time to writing good documentation.

To set the position of btRigidBody , try the following: -

 btTransform transform = body -> getCenterOfMassTransform(); transform.setOrigin(aNewPosition); //<- set orientation / position that you like body -> setCenterOfMassTransform(transform); 

If your code is wrong only in the given part of the conversion (this is what I think due to code removal), it should be allowed.

Note that this snippet only works for a dynamic body, not a static body.

About CompoundBody: -

If this compound is, for example, shape B contains form C
Setting conversion B will work (set body B ), but not work for C
(because C is just a form, conversion only supports the body.)

If I want to change the relative conversion of C to B , I would create a completely new compound form and a new solid. Remember to remove the old case and shape.

This is a limitation of the library.

PS

I canโ€™t answer some of your doubts / questions, this information is what I collected after the persecution in the Bullet forum for a while and checked it myself.

(I also code the game + game library from scratch using Bullet and other open sources.)

Edit: (about a new issue)

it just falls slowly (along with the ground, which should not move, since I gave it a mass of 0)

I would try to solve it in that order.

Idea a

  • Set mass = 0 instead, because setting the infant mass does not matter.

Idea b

  • First check -> getCenterOfMassTransform() every time-step, does it really crash?
  • If it really dynamicsWorld->setGravity(btVector3(0,0,0)); , try dynamicsWorld->setGravity(btVector3(0,0,0)); .
  • If everything still does not work, try with a very simple world (1 simple object, no connection) and see.

Idea C (now I'm starting desperately)

  • Make sure your camera position is constant.
  • If the problem is still alive, I think you can now create a simple test file and post it on the Bullet forum without much effort.
  • Reducing the number of lines of code = better feedback
+3
source share

What you are describing is not normal bullet behavior. Your understanding of the library is correct.

What you are most likely dealing with is a buffer overflow or a dangling pointer. The code you posted also does not have the obvious, so it will come from another place in your code base. You could track this using a well-located memory breakpoint.

You can "deal" with the header / binary version inconsistency problem, but this is less likely since you are likely to see other important issues.

+1
source share

It just had the same type of behavior as DebugDrawer paused at the top of the world. Having solved it, going to Bullet Physics only the projection matrix, without the model matrix that he has and is multiplied by already:

 glUseProgram(shaderID); m_MVP = m_camera->getProjectionViewMatrix(); glUniformMatrix4fv(shaderIDMVP, 1, GL_FALSE, &m_MVP[0][0]); if (m_dynamicWorld) m_dynamicWorld->debugDrawWorld(); 
0
source share

All Articles