Animated mesh won't collide with static mesh if speed too high

Hi everyone,

Please have a look at:

The red dots mark the trajectory of the bullet. The bullet should collide with a wall piece. But the bullet goes right through.

You can work around this by

a) make the wall MotionType.DYNAMIC (line 20) or
b) make the bullet MotionType.DYNAMIC (line 27) or
c) lower the speed of the bullet (line 47)

Neither of those fixes are practical in my local project. What might work is go with a) but set gravity to 0. On impact, reset.

Note that there are some difference compared to my local project (in case it is relevant):

  • In the Playground the physics hit boxes of the wall pieces are completely off.
  • In the Playground, it seems, that you can change source/target vectors to whatever and the bullet still does not collide. In my local project, this only happens rarely.

Best wishes

Let me add @Cedric and @carolhmj to the thread for the physic

1 Like

@Joe_Kerr did you try it with raycast? I think it’s the best option for (very) fast moving simple bodies

@Cedric Yes, raycasts work great! :smiley:

But why is speed a factor? Doesn’t Havok use continuous collision detection? I thought this would fix these kind of noclip bugs :pleading_face:

Anyway, say you want to ensure that a call to PhysicsBody.setLinearVelocity will always result in a proper collision: what would be the speed and size constraints - where by

  • “speed” I mean the number you scale the direction vector of PhysicsBody.setLinearVelocity and
  • “size” the moving mesh’s size or radius in Babylon.MeshBuilder?

My assumption (might be wrong) here is that the smaller the size / greater the speed, noclip risk increases.

There are more infos on Havok and CCD here:

Thanks @Cedric for the pointer. But upping the speed limit does not fix it: | Line 116: apply hack; Line 75: move body

Apologies if I am mistaken but the above issue is not really an issue about max speed per se, is it? Assuming I didn’t do sth stupid somewhere, I would expect that whatever the speed/size of the moving object, collision detection will never fail. Otherwise any speed can potentially cause collision detection to fail. This would be a very frightening sword of damocles hanging there - additionally to the one already hanging there from the did-sth-stupid possibility… :grinning:

Just gonna jump in here; kinematic bodies shouldn’t be colliding with static ones at all because neither can actually be moved by the solver, so the fact that you can workaround it with option (c) indicates we probably have a bug and are doing more work than necessary in some scenarios. Cedric is right, though; using a raycast would be a lot better - firing a kinematic bullet like that can have all sorts of undesirable effects; for example, it will hit objects on the opposite side of the wall before you get to dispose the bullet.

1 Like

Ohh noo, please don’t fix it :grin: Seriously though, you convinced me already. Using raycasts now.

1 Like