← Back to index

Issues with collisions with moving things

Finalspace
#3302
Hi there,

in Handmade Hero we use a line intersection test to determine the actual time of impact for a entity against all other entities. This works fine for non-moving entities we test against, but not for moving entities - except if both entities should stop.

In my case where i use the same technique, but on a different game scenario (2D Platformer) i am facing a problem that two moving entities (Elevator and Player) should not just both stop. Only the player should be corrected and the elevator should move until i stop it.

Is there a way to modify that technique, so that it supports that type of behavior?

Thanks,
Final

Btw i watched the entire series so far and love it. Best game development video series i have ever seen before - even with my 20 years of programming experience i still learned a lot. Thanks for that Casey!
Edited by Finalspace on Reason: Misunderstanding?
Casey Muratori
#3310
Well, we'll get to this in the series when we do final collision detection. But you might be able to hack it for now by just adding the movement of the other object to the movement of the first object? Remember, movement is relative, so you can always turn two moving objects into one moving object and one stationary object :P

- Casey
Finalspace
#3313
Than the deltaP computation must be done for all entities before any other entity movement right?

Then its nearly the same as we use in rigidbody physics, where you calculate the relative velocity vA - vB and use this for impulse computation, except that in handmade hero we just use the frame movement portion instead of full velocity.

I will give it a try ~ looking forward to final collision detection ;-)

Best part about handmade hero is that i can confirm which i know and which i dont. This i really appreciate it.
Finalspace
#3326
Tried it and it does not work. Player is still falling through. So i have two options, use a special code which handles this or use a different technique.
Casey Muratori
#3331
If you're talking about _pushing_ the player and/or supporting them, as opposed to simply detecting collisions, keep in mind that you must make sure that the _velocities_ at the collision match as well! Otherwise obviously things will fall through.

Etc., etc.

- Casey
Finalspace
#3339
I thought it through and i know the reason why its just to not working.
Its obvious. We only scale the deltaP so it just touches the surface including some epsilon, but 23 will never correct any penetration at all - which happens when there are things which move against us.

Back to drawing board.
Casey Muratori
#3344
No, technically that is not it. Penetration correction is definitely good, and we'll do that, but _it is the velocity that is the problem_ as I was trying to say. At a contact point you must make the collision routines obey the fact that the relative velocity of the two bodies there must remain 0. Know what I mean?

- Casey
Finalspace
#3381
cmuratori
No, technically that is not it. Penetration correction is definitely good, and we'll do that, but _it is the velocity that is the problem_ as I was trying to say. At a contact point you must make the collision routines obey the fact that the relative velocity of the two bodies there must remain 0. Know what I mean?

- Casey


Hmm i still dont get it...

Normally you apply an impulse to both velocities multiplied by both inverse masses. If this impulses then are subtracted from the relative velocity then the relative velocity should be zero right? But only in the direction of the contact normal!

In a simple physics engine we do something like this - without any restitution or multiple shapes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
void physicsUpdate() {
  for (every entity) {
    integrate entity velocity to a new state
  }
  contacts = [];
  for (every entity as A) {
    for (every entity as B) {
      if (A != B) {
        calculate contacts for pair A and B and add it to contacts
      }
    }
  }
  baumgarte = 0.2 // We solve the impulses only for 20% to make it more stable
  for (iteration from 1 to 10) {
    for (any contact) {
      relativeVelocity = bodyA.velocity - bodyB.velocity;
      impulseScale = relativeVelocity.dot(contact.normal) / (invMassA + invMassB)
      impulse = impulseScalar * baumgarte
      bodyA.velocity-= impulse * contact.normal * invMassA
      bodyB.velocity += impulse * contact.normal * invMassB
    }
  }
  for (every entity) {
    integrate entity position from new velocity
  }
  
  // lastly we may correct positions using contact.distance so it just touches the surface (This is not needed for simulations, but for games!)
  // This part is really hard... and i never have solved this completely :-(
}


Normal rigid body stuff but without any angular rotation and no position correction at all. Bodies will sink into each other when mass is too heavy. But it works for simple simulations.

But the way we are doing right now is completely different, we integrate when we move the entity and then handle all the collisions against the other entities. The other entity movements are not taken into account at all.

This may be the core problem of the current state of our collision system, but i really like the way the handmade hero collision system works right now, because its fully stable for static against moving things.

Arrggg collisions are so damn hard... every time i do this, my brain goes crazy.
Edited by Finalspace on
Finalspace
#3382
I still cannot get this stuff to work properly.

Look at this fiddle, the player wont be pushing by the elevator... and it has some really weird bugs...

http://jsfiddle.net/o6vzyxxj/

I used relative deltaP and relative dP for my calculations - but looks like hacking it in wont work.
Casey Muratori
#3406
Well, there's just a lot of stuff to talk about here, so I'd rather wait until we go do the final collision detector, because this is all stuff we will cover. I will try to come up with some excuse to handle moving platforms :P

- Casey
Finalspace
#3410
Yeah, looking forward to :woohoo:
Reply to Thread
← Back to index