Why are static bodies so... non-rigid?

[lkjoel]

Hey everyone,

I'm sort of new to chipmunk, but I did read (most of) the manual. I'm making a 2D top-down shooter (with a 3d perspective), and I'm just wondering why they static bodies (such as walls) are non-rigid (jello-like)? Is there any way to make them solid?

EDIT: Alright, I think I found that this is sort of expected when a huge force is applied to the object. Is it possible to make a SOLID object that CANNOT have anything going through?

EDIT 2: I'm using a BOX shape, not a segment shape

EDIT 3: The "player" object uses velocity to move. I noticed that when using forces, the problem didn't occur, but then the player would not stop moving

Thanks!

[Beta Carotene]

I wont claim to be an expert in chipmunk, but I do know that if you set velocity or positions on every frame, your bodies/shapes will pass through other objects and cause very strange behavior as a result of giving the finger to Mr Newtons laws.

As for objects being... jello like... you're going to have to go into more detail because I cant even imagine what you're describing. I had to put a considerable amount of effort into making objects that acted like soft bodies.

As for preventing objects from passing through each other, if you're talking about slow(er) moving objects, just use application of forces (probably impulses) to move them and you should be fine. If you're talking about small, very fast moving objects, you're going to need to get a little more creative.

Things like bullets are not handled well by chipmunk because it doesn't support continuous collision detection. However, supporting a basic form of it for things like bullets and thin rockets is not difficult. What I did was that I made it so every frame, a bullet would perform a segment query between its previous and current position. If it detected a hit, it would back the bullet up to that point, and then whatever event handling code for bullet collisions would be called.

I don't know if you're getting this intricate. But be aware that segment queries do not seem to detect when they are exiting a shape, they only know when they're entering it. If you're doing entrance/exit wounds, you're going to want to 2 segment queries, one going from prevPos to currentPos and one going from currentPos to prevPos.

If you're getting REALLY intricate and want to determine if you're intersecting a shape within another shape, you can take your intersection point and perform a closest point query. If your closest distance is a number significantly below 0, then you know that you are inside another shape and not just on the border of a single one, so you should not count it as an entrance or exit. But uh.... I'm probably just thinking out loud now, and being silly.

All of the segment query stuff sounds really expensive, but if your bullets travel fast, then no matter how much you spam, you're only going to have a few bullets alive on any given frame, and from what I've seen it doesn't degrade your performance much. Chipmunk queries seem to be pretty efficient as well.

Hope this helps.

EDIT: as for your player not stopping moving, that's because you're applying a force instead of an impulse. Forces will keep applying acceleration of an object until they are resisted against (I think... I don't use them that often). Impulses on the other hand apply a one-time force that will wear off over time. This is most likely what you want.

[slembcke]

I'm pretty certain the jello-like behavior you are describing is objects mushing themselves into your static geometry. That is happening because you are setting the velocity every frame from the sounds of it. You have several options to avoid that:

1) Use constraints to give yourself top-down friction like in the Tank demo.

2) Use forces. Forces aren't integrated until after the position is update but before the contact solver runs. That is why they don't cause the mushy behavior. The part you are missing is that you need to cancel the forces when they are done. Chipmunk doesn't automatically clear forces that are applied to an object.

3) Modify the velocity inside of a velocity update function. This is a not a well documented feature of Chipmunk. The Planet demo has an example of a velocity update callback to override gravity though. Additionally, it works best if you accelerate towards the new velocity instead of setting it directly.

[lkjoel]

@Beta Carotene, Thanks for you explanation! So I did try using impulses, using code like this:

Code: Select all

cpBodyApplyImpulse(player->body, cpvneg(player->body->v), cpvzero);
cpVect vel1 = cpvzero;
// set the value of vel1
cpBodyApplyImpulse(player->body, vel1, cpvzero);

But the issue was the same! My original code, by the way, was this:

Code: Select all

cpVect vel1 = cpvzero;
// set the value of vel1
cpBodySetVel(player->body, vel1);

This is not for a bullet, this is for the player (who moves fast).
@slembcke, ok, I see, and yes, that is true. I tried using forces, but I do not know how to cancel them... could you give an example or something? For 3, I think you lost me... I'm going to try to read the source of the Planet demo though.

EDIT: I don't know if this is related or not, but the space is calculated using:

Code: Select all

cpSpaceStep(space, delta / 1000000);

(delta is in microseconds)

[slembcke]

Impulses are are applied to a body's velocity immediately, so the effect is the same as changing the velocity.

If you use cpBodySetForce(), the force applied to the body will stay the same until you change it again. cpBodyResetForces() is a convenience method that sets the force and torque to zero. A common mistake is to call cpBodyApplyForce() with adds more forces onto existing ones and then never resetting them.

For #3, basically you will be implementing a function like this the following. Instead of calculating a new gravity value, update the velocity, then call cpBodyUpdateVelocity() with the parameters passed to your function.
https://github.com/slembcke/Chipmunk-Ph ... anet.c#L43

Lastly, It's not recommended to use a variable time step. You will have far fewer problems if you use a fixed timestep: http://gafferongames.com/game-physics/f ... -timestep/ (The interpolation stuff at the end isn't super important though)

[lkjoel]

Ok, that makes sense. I saw that the tank demo has the exact same problem that I have if you use a cube to "squish" another cube against the side. I will try using forces though.