Mesh Collision Troubles


#1

Does anyone have a good feel for the quirks of the physics engine? I’m working on a racer game and I’m having some issues getting everything to function correctly. Here’s the questions/problems that have come up for me.

  • Mesh based colliders don’t work if the size of the triangles is too disparate form the size of the dynamic mesh. [1] As a result I have to use a denser mesh than I’d like for collision. Unfortunately it seems that larger collision meshes (seems to happen with anything over ~10k polygons) get corrupted somehow with a good portion of the verticies (maybe one vertex out of every tri?) being pulled into a singularity at the origin of the mesh. I can split up my mesh into multiple parts to circumvent this problem, is that my best bet?

  • Mesh based colliders are extremely buggy on dynamic objects, It seems non-primitive collision meshes can only collide with dynamic primitive meshes, and will fall through anything else. I seem to remember it being dis-recommended to use anything but static rigid bodies. If that’s an engine limitation that can’t be circumvented is there any way for me to constrain two or three primitive colliders together to make a more complex shape? Only using primitive colliders for more complex racer shapes would result in some pretty non-intuitive behavior and I’d like to avoid it.


Mesh object collision
#2

Pretty much all physics engine have quirks, as you describe. PlayCanvas’ physics engine is Ammo.js which is the JavaScript port of Bullet. Therefore, you can read the tips that are in the Bullet Manual and they should also apply to PlayCanvas:

https://github.com/bulletphysics/bullet3/blob/master/docs/Bullet_User_Manual.pdf

There’s a PlayCanvas Manual page on physics but it doesn’t (yet) have much in the way of tips for achieving good stability. I would suggest:

  • Avoid long, thin collision mesh triangles.
  • Keep the triangle sizes in your collision meshes reasonably uniform (avoid tiny or huge triangles).
  • Keep masses of dynamic bodies realistic.
  • Avoid allowing dynamic velocities to get too high.

I haven’t seen the problem where collision meshes break down as they exceed a certain number of triangles. Can you share a simple project where this happens? Are you able to get this project to display the problem, but changing the resolution of the terrain?

https://playcanvas.com/project/362224/overview/tutorial-terrain-from-heightmap

Splitting the collision mesh into chunks should avoid the problem, but it would be good to determine whether something can be fixed here…

Mesh based colliders should only be used for static bodies. Doing mesh-mesh collision on concave shapes is extremely slow and Bullet doesn’t support it. We probably need to message this better in the PlayCanvas Editor UI. What you are asking for here is compound collision shapes. This is currently a feature request in the GitHub repo for the engine. The work is not yet scheduled but we recognise it is an important feature and we definitely are keen to add it as time allows.


#3

“Doing mesh-mesh collision on concave shapes is extremely slow and Bullet doesn’t support it.” This makes sense, I’ll read more about it. Does bullet support using a convex hull, that shouldn’t be too slow right?

I’m not sure how I could replicate the problem as the collision mesh is created at runtime so there’s no way for me to see it in game.

I’ve done some additional tests though and I’ve got findings to report!

  • polycount matters but it’s not some fixed breaking point different meshes break down at different points, a plane with 90k faces works fine, but one with 180k faces gets blown up
  • file format doesn’t matter
  • having everything be quads doesn’t matter

I’m honestly at wits end here trying to track this down, any idea what might be causing it?

https://dl.dropboxusercontent.com/u/886534/problems.zip <— here are some meshes, problem2 and planedistorted90k work as collision meshes, the other two don’t

P.S. Is there some way to change the draw distance on the editor camera? I hope to work with tracks that are about 10km x 10km and when I’m in the editor it’s impossible to view the whole thing because it’s past the far clip.


#4

Easy answer: you can edit near and far clip planes for the camera in the editor settings under the Editor section.


#5

Sorry for offtop, but dude, your project is so cool, I got to this straight part of track, and then went as fast as I could, it feels like epic Star Wars racings, and you doing some multiplayer bits.
And landscape is very stylistic cool. Sad you having troubles with collision, but this cool project has loads of potential.

With landscape I would suggest you would want to make chunks and terrain LoD so to have it render faster and have chunks for physics that would be smaller ones. You could generate them as you fly, just need to figure out a way of doing it faster than that slow addTriangle in ammo.js, there might be a method to pass float32array to it, so it will generate trimesh faster, but needs investigation.


#6

@will, could you provide a reference for the statement that Bullet doesn’t support mesh-mesh collision?

I’ve read the Bullet User Manual and page 16 seems to say that Bullet does indeed support mesh-mesh collision using the gimpact algorithm:

By extension, shouldn’t ammo.js support mesh-mesh collisions too then?

I assume that I might be missing or misunderstanding something.


Is there any way to make mesh-to-mesh collision?