Object stuck in the floor.

[EddieBytes]

issue1.png (174.97 KiB) Viewed 14662 times

issue2.png (174 KiB) Viewed 14662 times

In issue1.png, the player stands on the block below the green arrow, then he suddenly moves left, quite fast. The player gets stuck in the left wall, as can be seen in the image, he's not falling like he should. Look at the bounding boxes, the player's bb seems to be stuck between the two blocks to the left, where the red arrow is pointing. If the character jumps perfectly vertical (applying an upwards force), he gets unstuck and falls to the bottom block as he should.

In issue2.png, the player runs to the left then he jumps. Upon landing, he gets stuck as can be seen in the image. Again, I think he's stuck between those two blocks, the red arrow is pointing towards where he's stuck. If he moves to the right, towards where the yellow arrow is pointing, he gets unstuck and can progress to the left afterwards.
Apparently the player's bounding box is penetrating the block, he has a Y coordinate of 10.6764. When I then press the right arrow, he gets unstuck and his Y coordinate becomes 10.6765. A block has a width of exactly 1, collision margin 0, mass 0. The character has mass 1 and collision margin set to 50 which I don't understand why it is not reflected in the bounding box, the bounding box clearly still has a width of 1. (actually 0.85, I want the char to fall through 1 width gaps so he must fit).

The two questions:
- why does the character get stuck in these cases?
- why doesn't setMargin do anything to my character's collision box?

Further info:
- the physics initialization code:

Code: Select all

 mCollisionConfiguration.reset(new ::btDefaultCollisionConfiguration);

  mDispatcher.reset(new	btCollisionDispatcher(mCollisionConfiguration.get()));

  mSimplex.reset(new btVoronoiSimplexSolver());
  //mPdSolver.reset(new btMinkowskiPenetrationDepthSolver());
  mPdSolver.reset(new btGjkEpaPenetrationDepthSolver());
  

  mConvexAlgo2d.reset(new btConvex2dConvex2dAlgorithm::CreateFunc(mSimplex.get(), mPdSolver.get()));

  mDispatcher->registerCollisionCreateFunc(CONVEX_2D_SHAPE_PROXYTYPE,CONVEX_2D_SHAPE_PROXYTYPE, mConvexAlgo2d.get());
  mDispatcher->registerCollisionCreateFunc(BOX_2D_SHAPE_PROXYTYPE,CONVEX_2D_SHAPE_PROXYTYPE, mConvexAlgo2d.get());
  mDispatcher->registerCollisionCreateFunc(CONVEX_2D_SHAPE_PROXYTYPE,BOX_2D_SHAPE_PROXYTYPE, mConvexAlgo2d.get());
  mDispatcher->registerCollisionCreateFunc(BOX_2D_SHAPE_PROXYTYPE,BOX_2D_SHAPE_PROXYTYPE,new btBox2dBox2dCollisionAlgorithm::CreateFunc());
  //mDispatcher->registerCollisionCreateFunc(BOX_2D_SHAPE_PROXYTYPE,BOX_2D_SHAPE_PROXYTYPE, mConvexAlgo2d.get());

  mBroadphase.reset(new btDbvtBroadphase());
  //m_broadphase = new btSimpleBroadphase();

  ///the default constraint solver. For parallel processing you can use a different solver (see Extras/BulletMultiThreaded)
  mConstraintSolver.reset(new btSequentialImpulseConstraintSolver);

  mDynamicsWorld.reset(new btDiscreteDynamicsWorld(
    mDispatcher.get(),
    mBroadphase.get(),
    mConstraintSolver.get(),
    mCollisionConfiguration.get()));

  mDynamicsWorld->setGravity(kGravity);

- all objects have btBox2DShape collision shapes.

I'm sorry if the issue has been tackled before, but I searched the forums and google and nothing came up. I initially tried to solve the issue by setting collision margin on my character, but that did nothing.

Thank you in advance for any help you can provide me!

[Mako_energy02]

I can't comment much on the Character issues, since I don't have much experience with them and you haven't shown your character initialization code.

However I can say that your character may be getting stuck due to the lack of a collision margin on your blocks. The collision margin is there to provide padding before an object actually penetrates and to my knowledge(which could be wrong) not having it can cause exactly this issue. If you are worried about the graphics and physics being in sync, you can scale down the physics shape until the margin syncs up with the graphics for the block. To my knowledge the default collision margin is 0.04, and that should be applicable to your world scale.

[EddieBytes]

Thank you mako. I already know about the margin, that is why I mentioned it.
Char init code:

Code: Select all

//
float blockSize = ChunkBlob::kBlockSize;
  mCharWidth = blockSize;
  mCharHeight = blockSize * 2;

  // the collision shape's is slightly less than a block's width
  // so that the char can fall through 1-width gaps
  // also, he's slightly higher than three blocks
  mCollisionShape.reset(new btBox2dShape(
    btVector3(mCharWidth / 2.3f, mCharHeight / 1.7f, 0))); // the vector represents
  // a line from the block's center to one of its corners
  mCollisionShape->setMargin(0.5f);

// snip 
// ..................
// ..............
// /snip
mCharMotionState.reset(
    new CharacterMotionState(this, btTransform(
      btQuaternion(0, 0, 0, 1), 
      btVector3( 
        (btScalar)(x * ChunkBlob::kBlockSize + mCharWidth / 2), 
        (btScalar)(y * ChunkBlob::kBlockSize + mCharHeight / 2), 
        0
      )
    ))
  );


  btScalar mass = 2;
  //if ( y == 0 )
  //  mass = 0;

  btCollisionShape * collisionShape = mCollisionShape.get();
  collisionShape->calculateLocalInertia(mass, mFallInertia);
  btRigidBody::btRigidBodyConstructionInfo charRigidBodyCI(
    mass, mCharMotionState.get(), collisionShape, mFallInertia);

  if ( mCharRigidBody.get() )
    mBlobInstantiator->GetDynamicsWorld()->removeRigidBody(mCharRigidBody.get());

  mCharRigidBody.reset(new btRigidBody(charRigidBodyCI));
  mCharRigidBody->setAngularFactor(0);
  mCharRigidBody->setActivationState(ACTIVE_TAG);
  mBlobInstantiator->GetDynamicsWorld()->addRigidBody(mCharRigidBody.get());

As you can see, I am setting the margin to 0.5 on the characters. The blocks have zero mass so I believe they must also have 0 margin, I think I read that somewhere?. 0.5 is a huge margin, it should be visible on screen, however it is not. If I call getMargin on the collision shape, it returns 0.5, like I set it. Surely the margin must be the issue, but I don't see how and why it's all acting up like this.

[Mako_energy02]

The blocks have zero mass so I believe they must also have 0 margin, I think I read that somewhere?.

I don't think this is correct. I've been leaving the default margin on my terrains for a while without issue. Either way I think it is worth a shot.

As for your character, you are directly controlling a rigid body? I have no idea why it's not behaving with the margin you set. I was kinda hoping you were using a kinematic character controller, cause last I looked it's still quite buggy and there are a number of things that need tweaking, but a regular rigid body should "just work".

[EddieBytes]

Well, I did as you suggested. I shrinked the blocks' collision shape and added some margin. The behavior still occurs. I've set the margin to 0.04 and 0.5 on the blocks, the bounding boxes look the same with either of the values. That's what you are seeing in the image, the blue boxes are the bounding boxes. So, either I am misunderstanding how margin should look on the screen, or I'm not setting the margin properly.

Now, look at this image, issue3.png. The character penetrates block 'a', and while in penetration, moves towards left and collides with block 'b's right edge. That's why I believe it gets stuck, it's hitting the right edge of block b while penetrating block 'a'. I think margins would solve this, however I can't for the life of me figure out why they don't work!

[Mako_energy02]

Code: Select all

mCollisionShape.reset(new btBox2dShape(
    btVector3(mCharWidth / 2.3f, mCharHeight / 1.7f, 0))); // the vector represents
  // a line from the block's center to one of its corners

I had to do a double take on your code, but I don't think the comment there in your code is accurate. I couldn't find anything in the class documentation or source code to indicate it's going to a corner. It simply says the objects half extents, which at least in the case of other 3D collision shapes means the objects AABB divided by two(for simple shapes anyway). In your case I think the vector3 you should be passing in should look more like:

Code: Select all

btVector3(mCharWidth * 0.5f, mCharHeight * 0.5f, 0);

This still doesn't explain your collision margin issue, but it could be related/a part of the issue.


Edit:
Was typing this post while you posted your last post. I don't think the margins are something that would be drawn by the debugger. I haven't seen them in any of the debug drawings I've made in my simulations. I only see the actual shapes(without margin applied).

[EddieBytes]

Yes, they're half extents, you are correct. The values you see there are so that the resulting collision box will actually be smaller than mCharWidth or mCharHeight. They're correct. Yes, if I wanted the collision box to have exactly mCharWidth and mCharHeight dimentions, I would multiply each by 0.5. I'm 100% sure that's not the issue here.

Edit:
Was typing this post while you posted your last post. I don't think the margins are something that would be drawn by the debugger. I haven't seen them in any of the debug drawings I've made in my simulations. I only see the actual shapes(without margin applied).

Well, even so, wouldn't the character float approximately half a block above if I set the margin to 0.5? That would certainly be visible. However, for some reason, it is not, it's actually touching the block under it instead of floating above it.

[EddieBytes]

Ok, I tried increasing the margin, but to no avail.
Any ideas?

[EddieBytes]

Tried changing from btBox2dShape to btBoxShape. I am thus now using cubes. But setting the margin still has no effect. I can't figure out why (
Maybe the bullet's initialization code is wrong? I posted it a few posts above.

[EddieBytes]

Ok figured out the margins issue, they're actually set correctly and work, margins don't add to a btBox2dShape's dimentions, like the documentation sais:

Generally the collision margin will expand the object. This will create a small gap. To compensate for this, some shapes will subtract the margin from the actual size. For example, the btBoxShape subtracts the collision margin from the half extents.

However, the issue still manifests itself. Character penetrates block 'a' then hits (collides with) the right side of block 'b' while moving to the left, and remains stuck.

How would I go about fixing this behavior?

[EddieBytes]

More info:

Whenever the character sits (rests) on top of block 'a', it has an Y coordinate of 10.5. If it's stuck inside block 'a' while trying to go left and colliding with block 'b's right edge, it has an Y coordinate of 10.49, so it's obviously a bit sunk into block 'a'. Maybe this has to do with 'b's friction? the friction between 'b's right edge and character's left edge won't let the character pop back upwards to Y=10.5 ?

I'm really confused here, please lend a hand!

issue3.png (69.18 KiB) Viewed 14598 times

[EddieBytes]

Forgot to mention my character's rigid body does not rotate:
mCharRigidBody->setAngularFactor(0);

I have some more info, I am now displaying collision points in the debugger. The yellow crosshairs represent the collision points. Take a look at the screenshot. The character's collision box penetrates block 'A' because of the speed, then while penetrating, falls on block 'B' due to gravity. Thus, it gets stuck there.

issue4.png (159.85 KiB) Viewed 14592 times

[EddieBytes]

DAMN IT!
I initially thought friction between block and character caused the character to not pop out if it was penetrating the block while touching the adjacent block, like I explain in my previous post. So I set the block's friction to 0. The behavior still occurs.

[EddieBytes]

Come on, really? Has no one else encountered this before?

[marios]

how do you move your player? impulses or kinematic object? If impulses/forces I suggest you to add some force upward. Another way to workaround this is to change player collision object to sphere or capsule