# Avoid triangle-testing when doing collision detection **URL:** \ **Category:** Questions\ **Created:** [November 4, 2022, 6:49pm UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410 "2022-11-04T18:49:35Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![alekop](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/alekop/32/4380_2.png) [@alekop](https://forum.babylonjs.com/u/alekop)\ **Post date:** [November 4, 2022, 6:49pm UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/1 "2022-11-04T18:49:35Z")
I’m seeing expensive triangle-test collision checks even though 1) we have bounding boxes, and 2) the meshes aren’t even colliding yet. Here’s a [playground](https://playground.babylonjs.com/#Y76X5W) with two simple meshes. There’s not much to see, but if you open the Dev Tools, and run `step(player())` in the console, the player box moves forward… The interesting thing is what happens in `abstractMesh._checkCollision`. The stack looks like this: ```auto collider._collide // per-triangle collision abstractMesh._collideForSubMesh abstractMesh._processCollisionsForSubMeshes abstractMesh._checkCollision // we fail the bounding-box test ``` All meshes (player, npc, ground) have bounding volumes, so why are we doing per-triangle tests? How can we avoid it? Per-triangle tests are catastrophically slow with multiple complex meshes on mobile devices. ---
**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\ **Post date:** [November 6, 2022, 4:10pm UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/2 "2022-11-06T16:10:41Z")
Actually, the fast collision check is done with the bounding spheres, and they do collide in your PG. They collide with the ground, but even if you set `checkCollisions = false` on the ground they still collide as the meshes are close to each other. If you move them a bit apart, you will see that you don’t reach `_processCollisionsForSubMeshes`. ---
**Author:** ![alekop](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/alekop/32/4380_2.png) [@alekop](https://forum.babylonjs.com/u/alekop)\ **Post date:** [November 7, 2022, 3:55am UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/3 "2022-11-07T03:55:59Z")
Sure, but in a real game, characters will get close. How do we stop them from bumping into each other, with just bounding volume checks? ---
**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\ **Post date:** [November 7, 2022, 9:09am UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/4 "2022-11-07T09:09:52Z")
I think games use mainly capsules for collision with characters(?), as it’s a better fit for an humanoid. I know we also have capsules, at least for the camera (ellipsoid), but I don’t think we use them for other objects. I guess we could also have some options to check with the bounding box and/or stop checking collisions at the bounding (box or sphere) level. I don’t think this currently exists but @Cedric will know better than me. [EDIT] I stand corrected, we already use ellipsoids for mesh collisions: > **[Camera Collisions | Babylon.js Documentation](https://doc.babylonjs.com/features/featuresDeepDive/cameras/camera_collisions#4-object-vs-object-collision)** > > Dive into understanding camera collisions, mesh collisions, and gravity. ---
**Author:** ![alekop](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/alekop/32/4380_2.png) [@alekop](https://forum.babylonjs.com/u/alekop)\ **Post date:** [November 10, 2022, 5:46am UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/5 "2022-11-10T05:46:08Z")
I tried adding collision capsules as children of complex characters meshes… The idea is that those should be triangle-tested, instead of the complex ones. Doesn’t work well so far… > **[Babylon.js Playground](https://playground.babylonjs.com/#VFFVEM%239)** > > Babylon.js playground is a live editor for Babylon.js WebGL 3D scenes Adding them as parents solves some issues, but causes others. I’m out of ideas… going to sleep. ---
**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\ **Post date:** [November 10, 2022, 8:33am UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/6 "2022-11-10T08:33:37Z")
Maybe you can try using a physic plugin? I think they have their own collision primitives and should be optimized accordingly. Also, let’s see if others have some ideas for you. ---
**Author:** ![alekop](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/alekop/32/4380_2.png) [@alekop](https://forum.babylonjs.com/u/alekop)\ **Post date:** [November 10, 2022, 7:41pm UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/7 "2022-11-10T19:41:49Z")
I think I found a good solution. 1. When a character mesh is added to the scene, also add a collider mesh, at the same position. A cylinder works fine, and has fewer faces than a capsule. Anyway, the ellipsoid is what controls terrain negotiation, so the shape of the caps doesn’t matter. In fact, we can use tubes instead of cylinders to save even more faces! 2. _The collider doesn’t need to be part of the mesh hierarchy at all!_ It’s a separate mesh, named e.g. “collider:\”. 3. To move the character, do: ```auto const currentCollidedMesh = colliderMesh.collider.collidedMesh // Move the collider, then update the character's position colliderMesh.moveWithCollisions(...); characterMesh.position = colliderMesh.position; // Check if we bumped into anything const newCollidedMesh = colliderMesh.collider.collidedMesh if (newCollidedMesh && newCollidedMesh !== currentCollidedMesh) { // new collision } ``` ---
**Author:** ![jeremy-coleman](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/jeremy-coleman/32/15493_2.png) [@jeremy-coleman](https://forum.babylonjs.com/u/jeremy-coleman)\ **Post date:** [November 10, 2022, 9:21pm UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/8 "2022-11-10T21:21:46Z")
This may be helpful. Scroll down a little and you’ll see a table comparison of the different collision shapes each physics plugin uses. These are handled for you by using PhysicsImposter. I suggest ammo, as its 2-3x faster than cannon and has more features. Although, manually handling it has benefits too. Sometimes the abstractions just leave with a feeling of like, wtf am i even doing and just cause more mental overhead. Also, bjs supports collisions without an engine, which can be confusing because with physics enabled, there are 2 ways of doing it. Heres the table: > **[Using A Physics Engine | Babylon.js Documentation](https://doc.babylonjs.com/features/featuresDeepDive/physics/usingPhysicsEngine)** > > Learn how to use one of the available physics engines in Babylon.js. Also the process you described is similar to what happens with the physics plugins. The physics world object for ammo i think is called a ghost object, and you can even adjust the substep timing to run multiple physics ticks before you move your rendered objects ---
**Author:** ![alekop](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/alekop/32/4380_2.png) [@alekop](https://forum.babylonjs.com/u/alekop)\ **Post date:** [November 10, 2022, 10:32pm UTC](https://forum.babylonjs.com/t/avoid-triangle-testing-when-doing-collision-detection/35410/9 "2022-11-10T22:32:21Z")
Thanks. I’ve been tempted to use physics on several occasions, but it seems like a big change at this stage in the project. I tried it early on, but ran into issues with things toppling over, which never got resolved properly. Also the performance on mobile was a concern. But who knows? Maybe I’ll give it another try.