Collision Handler HELP!

[aisquared]

We are making a platformer game and I want the player(sprite) which is a body to jump on a platform(floor body). We are using the collision handler which chiphunk provides and are able to detect the collisions between the platform and the player sprite.

But when it(sprite body) collides to the platform it slightly goes through the platform(floor body) and then settles down on the floor body(platform). Why is that happening?

Why doesn't it just sit on the platform when it first contacts the platform? Or do I have to set the sprite(body) position to the platform X and Y coords after collision?

Can't it do this automatically?

-Imran

[slembcke]

How are you creating and updating your platforms? That should work just fine.

[J .]

I'm experiencing a similar thing using pymunk, with any shape falling onto a horizontal line segment from high enough. Even falling from 150px with gravity (0, 3000), a circle radius 7.5 is affected. I doubt it's my draw function, since that gets the position straight from the body. It's fine when I reduce the timestep to 0.001, but is it normal that this should need to be so low?

Sort of related, I'm also getting 'poly' shapes falling partially through the line if they move to the edges, and the effect is exaggerated for complex shapes and ones that aren't convex. It's weird that they then stay there, perfectly stable, with the line inside them.

[slembcke]

I'm guessing that there is something wrong with both of the static bodies that you two are using. If you added it to the space, Chipmunk will attempt to simulate it make it fall under gravity, possibly getting it out of sync with the static shapes attached to it.

[J .]

No, I didn't add the line's body to the space (then it'd fall at the same rate as whatever's above it and they'd never collide at all). Here's the simplest example I can make:

Code: Select all

import pygame, pymunk, time

pygame.init()
screen = pygame.display.set_mode((640, 480))
pymunk.init_pymunk()
s = pymunk.Space()
s.gravity.y = 1000

c = pymunk.Circle(pymunk.Body(10, 100), 10)
c.body.position.x = 300
l = pymunk.Segment(pymunk.Body(pymunk.inf, pymunk.inf), (0, 400), (640, 400), 2)
s.add(c, c.body, l)

t0 = time.time()
while True:
    if any([event.type == pygame.QUIT for event in pygame.event.get()]):
        break
    s.step(.01)
    screen.fill((255, 255, 255))
    pygame.draw.circle(screen, (0, 0, 0), (int(c.body.position.x), int(c.body.position.y)), c.radius, 0)
    pygame.draw.line(screen, (0, 0, 0), l.body.position + l.a - (0, 1), l.body.position + l.b - (0, 1), 4)
    pygame.display.update()
    t1 = time.time()
    pygame.time.wait(int(10 - t1 + t0))

The circle falls, lands on the line, moves a couple of pixels into it, then moves back up to sit on top of it.

I'm already using version 1.0.0 of pymunk, if it matters.

[slembcke]

What you are describing might just be Chipmunk's normal overlap resolution. Chipmunk doesn't do swept collisions, so depending on how fast the object is moving compared to the size of the timestep it is going to be overlapping the line segment slightly before Chipmunk finds the collision. It then fixes the overlap over the next couple frames.

[atis]

The first time I tried Chipmunk I ran into this overlap issue as well (at least I'm assuming it's that). Depending on what scale you choose for your world, the overlap can get unacceptably huge. Fortunately, there are two undocumented variables that control the overlap resolution behavior (defined in cpArbiter.c, but if using C, you can set them anywhere since they're already declared in cpArbiter.h as externs).

Code: Select all

// Determines how fast penetrations resolve themselves.
extern cpFloat cp_bias_coef;
// Amount of allowed penetration. Used to reduce vibrating contacts.
extern cpFloat cp_collision_slop;

So yeah, tuning these made everything OK. Reducing simulation step or increasing iteration count might also prove useful.

slembcke, it would be nice if those two variables were documented because they're really important! It would be even better if they were part of cpSpace structure (or wherever they make sense) and there was an interface to set them, but maybe there's a reason they're not..... ?

[J .]

Editing these in the pymunk source (...glad it's an interpreted language) made it better for me. Thanks. And yeah, without knowing what a value actually means for them makes it harder to figure what'll work best. (They're in _chipmunk.py for anyone interested, and I just assigned something to cp_bias_coef.value after it was intialised.)