Meshes passing through each other using moveWithCollisions

Questions
1

Heya, I’m using moveWithCollisions for a little demo game and ran into an issue where the meshes overlap and pass through each other. I made a PG that reproduces the behavior using two box meshes. If one of the meshes is smaller and higher than the other, then moving them towards each other along the x axis produces this behavior. Is there a way to keep them from overlapping using the built-in collisions system? Thanks! :beers:
https://playground.babylonjs.com/#I0BD7L#1

overlapping meshes
overlapping meshes2854×1223 89.1 KB

2

I got the meshes to stop overlapping by adjusting their ellipsoids, but now they’re colliding too soon and the smaller mesh with the smaller ellipsoid is pushing the bigger mesh with the bigger ellipsoid when it should be the other way around.

So far I can’t find any ellipsoid configurations where the meshes collide without overlapping and passing through each other.
https://playground.babylonjs.com/#I0BD7L#4

3

@Cedric is gonna be famous :slight_smile: but @RaananW is amazing at physx/collisions too.

1 Like
4

The collisions with ellipsoid might not be the solution for your use-case. It’s more tailored for camera/ vs world collision. There is no way to set an ellipsoid that englobes a box perfectly. It will always be too big or too narrow. I would usggest to use a physics engine like ammojs instead.

4 Likes
5

Thanks for the helpful clarification! :slightly_smiling_face: I guess an option to use a box instead of an ellipsoid would be needed to support box-shaped meshes well.

With the physics engines I get better collision detection, but I’m having a hard time controlling the interaction between objects.

Do you know if there’s a way to make a ball bounce to the same height forever using any of the supported physics engines?

I’ve got the restitution set to 1 and the friction at 0 for both the ball and the ground, with the ball’s mass at 1 and the ground’s at 0. These settings are as close as I’ve been able to get so far.

With Cannon and Oimo, the ball bounces higher and higher each time. With Ammo, it stops bouncing and comes to rest after a bit. Also, especially for Cannon, the behavior doesn’t seem the same each time I run the playground - is there some randomness involved I wonder?

Thanks again! :beers:
https://playground.babylonjs.com/#2B84TV#30

6

Physics engine are non deterministic. Because of float precision and other factors, you may not get the exact simulation based on almost same inputs (delta time, positions,…)

With a restitution of 1 and friction of 0, you should get an almost infinitely bouncing ball. Maybe other parameters I don’t remember should be taken into account.

1 Like
7

With Cannon for example, on some runs it bounces higher and higher each time and on some runs it bounces less each time and very slowly comes to rest, so the behavior is very different. I’ll keep playing with the various impostor options and see if I can get it working better. I tried searching for it but either it’s not a common thing to demo or I’m not searching the right phrases… :thinking:

8

Have you tried enabling deterministic lockstep in your engine settings? The above-referenced floating point issues tend to manifest as energy conservation violations, which means the ball either gains energy from nothing with a collision or loses it to nothing (ie not transferred anywhere in the system). Deterministic lockstep may help with that to an extent

1 Like
9

Thanks, that’s interesting and did improve the issue, but Canon in particular is still too unstable to be useful for this goal it seems. Sometimes it will even bounce higher each time for a few seconds, then bounce lower each time for a few seconds, and go back and forth like that, on other runs it will just do one or the other LOL. :sweat_smile:

10

Though @RaananW might have some further tips for Cannon, I think Ammo is better known for its level of precision

You could try setting friction to a very small but non-zero value, or you could use an afterPhysicsStep observer to “correct” the system’s parameters

HTH

2 Likes
11

Thanks, I think I might end pivoting back to using simple custom physics. I can prob get things working how I want easier that way, since that’s how I’ve done it in the past.

Otherwise I think I would need to do manual corrections, like you suggested, because even slight changes to the jumping height could add up significantly over several minutes of game play… :slightly_smiling_face: :beers:

1 Like