moveWithCollisions() can't handle doublesided meshes

Hi, I’m trying to sort an issue in our app where in certain cases our “avatar”, which is moved with moveWithCollisions(), ends up phasing through the mesh… This mainly seems to happen when there are two planes facing opposite directions on top of each other (ie a doublesided plane).

You can see an example here: Babylon.js Playground … in the example, if you use WASD to move the sphere onto a certain side of the plane, one side blocks it correctly but the other side just phases through…

I’ve experienced a similar issue when doing raytracing, and we fixed it by checking the normal of the collision to ensure the angle isn’t bigger than 90º from the object and if so then ignoring that hit… The Babylon collision code is quite complex though and I can’t figure out where to add this kind of logic :sweat_smile:

Does anyone know of a solution to this?

cc @Cedric if you can have a look ?

I’m taking a look.

2 Likes

PR is live

The check/fix is hidden behind a flag, to not break back compat. Check PR for more infos.

Thank you! I’ll try it as soon as it’s available on npm :+1:

1 Like

Unfortunately it doesn’t seem to be solved yet… It works now quite well for doublesided MeshBuilder meshes, but still doesn’t work for imported doublesided meshes… I updated the playground here with a .glb mesh so you can see the issue: https://playground.babylonjs.com/#49RDAG#8

If you use WASD to walk over one of the mounds in the model, you get sucked into it instead of walking over it…

For something as complex as this scene, I would not use moveWithCollision. It is fine for low poly (thing corridors) but as soon as you have more complex geoemtry, I would use a physics engine. It’s not just for quality of collision resolution but also for CPU performance.

Isn’t moveWithCollisions() more performant than using a MeshImpostor? I see this warning in the babylon docs:

Use only when necessary - will lower performance. Cannon’s mesh impostor only collides against spheres and planes

Also, this moveWithCollisions() issue is still a bug that needs to be fixed, right?

I can take a look at using the physics engine for this as well in the mean time, but it may take some work to switch in our app…

Ammojs for example has pretty good spatial partionning for triangle collision detection. And movewithCollision may iterate multiple times to correct the velocity.

Without a simplified geometry that reproduces the bug, it will be hard to fix

Ok, so there seems to be an entirely separate problem as well, related to models that have negative scaling… Here’s an updated playground: https://playground.babylonjs.com/#49RDAG#9 … the top two mounds have been corrected in Blender, and the bottom two are the original uncorrected ones.

This means that we’re able to fix these models as well, so I think we can consider this one closed… I don’t know if Babylon is meant to be able to handle models with inverted scaling or not though…

I think it should work indeed. @Cedric is a king at fixing those :slight_smile:

It’s not an issue with the code but with the meshes.
I checked with the inspector and there is no negative scaling on any imported meshes.
But when I enable back face culling in the material, I see the face winding is inverted for the mesh that brings issues.
Basically, the mesh with problem is inside out. Face winding is important for collision detection.

1 Like