Bullet Kinematic object doesn´t collide with static geometry

General Discussion
1

I´ve a object with BulletRigidBody.setKinematic(True). I want control it with setPos, setHpr instead forces but want he collide physically with box in scene. I really guess i don´t need a character controller … i just want the object collide with the boxes and with the walls.

The boxes are dynamic BulletRigidBodies and the walls are static ones. My kinematic object collide fine with boxes, but don´t collide with walls :open_mouth:

And boxes itself collide fine with walls :frowning:
All BulletRigidBodies have collide mask BitMask32.allOn().
All visual elements are parent os your respective BulletRigidBodyNode…
All walls are static BulletRigidBodyNode with a shape BulletTriangleMeshShape added.
All Physical elements appear fine in BulletDebugNode (walls exists and are drawing, etc)

What´s wrong ?
:cry:

2

I don’t think anything is wrong. Actually I would expect this (Bullet Kinematic object doesn’t collide with static geometry).

This is the deal with kinematic objects; they are not affected by any physical influence (force, obstacles, …). If you set a kinematic object to a specific position then it jumps at this position, no matter what else is in the same position.

But this is just looking at the situation from one side (the side of the kinematic object). If looking at the situation from the other side you get different results depending on if the other object is static or dynamic.

Dynamic object: The dynamic objects finds out that now/suddenly something is overlapping with it (here: the kinematic object), and it tries to correct this “not-good” situation, by creating forces which move itself (the dynamic object) out of the way. This is why dynamic objects get pushed away by kinematic objects.

Static object: The static object simply doesn’t care if someone else is overlapping with it. It does nothing. Ok, you could say this is a bit inconsequent, since e. g. two rigid static objects should not overlap, because they are rigid. The justification is that it is handy when setting up a scene. It would be very tricky to make sure all static object do not overlap initially, to make sure there is no explosion in the first simulation step.

By the way: this is one big challenge with kinematic character controllers. How should they act on their environment? Obviously they should be stopped by static obstacles (kcc has to handle collision itself!). And obviously they should allow to push away dynamic objects. But how “much”? There should be a difference between light objects and heavy objects. And the direction of the pushing is interesting too. Often capsules are used for kcc. But pushing a box with a capsule can be tricky, since it would have to be exactly in front of the capsule to get pushes “right”. A little offset, and it will slide to the side. Not what one expects from a “guy pushing a crate”. fine tuning is required, and this fine-tuning is dependent on the game logic. Tricky.

3

@texugo

I know you said you might not need a full blown character controller, but what you’re talking about is basically just that :wink:. And it’s not easy to get right, so you might be interested in this:

[New Bullet Character Controller)

Basically character controllers are a very special case of objects. They’re a bit of a no-man’s land. Kinematic objects normally don’t react to static environment and other kinematic objects in any way, because they’re meant to be animated with the engine’s intervals system. It’s the animator’s job to make sure stuff doesn’t sink into statics, while the physics engine makes sure dynamics can be pushed around by or attached (with joints) to kinematics. With character controllers that’s not enough because you can’t predict the movement.

On the other hand, stuff that does react to static environment is dynamic objects, but it’s extremely hard to make a dynamic character controller for reasons I’ve talked about numerous times before.

Thus you just need to handle all collisions by yourself.

Yep, that is indeed an interesting problem. Direction is not such a big deal, because all you need to do is wrap the capsule with a box. I might add that to my Bullet KCC as an option. You might also need masks for that, but in any case that way you can use the capsule for static collisions (thus providing smooth movement) and the box for dynamic collisions (with more controllable pushing behavior).

The mass handling is a bigger problem. I have that on my todo list, because one thing I hate in games is the player character acting like a bull in a china shop, flipping everything over and moving furniture around for no reason. At the same time, it’s nonsense to not use physics just because the KCC is spoiled like that.

This should be possible to fix by modifying the char’s speed based on the mass of the dynamics it collides with. The tricky part is doing that at the right time – otherwise the dynamic stuff will move before we can alter the speed. Sweep tests? Maybe.

Speaking about sweep tests, it would be nice to have one that returns all objects it collided with, instead of just the first.

4

Depending on the game there might be other solutions. Let me draw a small vision:

Assuming the player is waling through debris on the floor, then it is in my eyes fine if this debris is pushes to the side. Thus a capsule (smooth movement) is fine here. The player is not willingly pushing the objects around.

Assuming the player wants to move a crate, that is he willingly manipulates his environment, then a box is better than a capsule, because the box allows “directed” pushing even if the contact point is not exactly in front of the player.

The difference is “willingly”, and thus a STATE of the character. If I remember right in the first Tomb Raider games you had to press a certain key while standing in front of a crate. Lara now assumed a “push” animation, and you could push a crate around. This could have been done by simply swapping the KKC collison shape from capsule to box and back when transiting between such states.

Just an idea. It boils down to being able to change the KKC collision shape at runtime.

5

I remember the PhysX SDK samples for how to use their KKC. PhySX basically offers (talking about the original C++ API) two callbacks for KCC, one which is called when the character collides with another character, and one which is called when the character collides with a dynamic object. It has been the users responsibility to implement these callbacks, by applying proper forces to the colliding dynamic object. Now, in their examples they did store a mass variable on the character, and in the callback they used the product of both masses to determine the magnitude of the pushing force.

Also they used only the horizontal component of the vector between the two objects, because a character would not lift colliding objects or push them into the ground. Well, they left it open to the user to implement a logic which fits it’s game concept, and I believe that they are right in assuming that there is no “one size fits all” algorithm.

6

Good idea. I will research a bit.

7

@enn0x

You’re right about the difference between pushing deliberately and incidentally.

However, I think that willful pushing might work even better using a joint, or a combination of joints. That way you can have the dynamic object move together with the player, allowing them to not only push, but also pull objects. Something like carrying, just with a different kind of joint. Obviously a point when the joint breaks should also be accounted for, like when the dynamic object is pushed over an edge or something like that.

But as you said, that depends on the game.

About PhysX, I’m not sure if it’s doable in Bullet. It would require the dynamic objects to ignore the fact that they collide with the KCC. Let me tell you what I mean.

Right now when there’s a collision between a dynamic object and the kcc, the result is the dynamic being pushed out of the way, as one would expect. But that’s not something I have any control over – it’s the engine doing its job. For me to be able to control the force applied to the dynamic object, that object would need to hold still until I explicitly tell it to move. At the same time, the collision itself would need to be recorded, at least by the KCC. Is that possible?

8

Wow … we´ve a high level discussion here! :smiley: I thinked i have a trivia problem.

@ennox
The explanation about Kinematic Objects behavior clarify me. I´m happy ´cos is not a problem in library. I´m going wrong with it.

@coopertop
Yeah … think again i guess Character Control can fit fine. I download your KCC and try today. :wink:

My actual app is just a scratch, but actions like box push/lift/etc can be a real problem in near future (like tomorrow ) :slight_smile: . My original intent is use Bullet for everything about collisions, maybe i´ve mix up with Panda´s native collision or else … i really don´t know at all.

kkkkkk :laughing:

9

You can’t really mix that because stuff from one system won’t collide with the stuff using the other system.

However, that’s not really a problem. Bullet is really all you need, it’s a one stop shop. In fact, you could even not use physics at all and still use Bullet – only the collision detection part.

Also, if you don’t want something to collide with something else, you can control that as well.