not getting desired boundaries with simple cube like shapes

[elkizana]

How to get rid of these extra boundaries

[donmccurdy]

It looks like you might be fitting a bounding box to your mesh. For a closer fit, use the convex hull or mesh types: https://github.com/donmccurdy/three-to-cannon?tab=readme-ov-file#api

[elkizana]

result with {type: ShapeType.HULL} :

And this when every "S" is a unique mesh :

[donmccurdy]

@elkizana That's what convex hulls are — think of it like stretching shrink-wrap around an object. If you need a tight fit around concave objects in Cannon.js, then the "mesh" type is your only option, and there are a bunch of performance and support caveats with that, unfortunately.

Ideally your meshes above could be fit with a collection of 'compound' box-shaped bodies, one box fitted to each box-shaped segment of the mesh... But that's not something this library can automate for you. Or if you don't need a full physics engine like cannon.js, then using a navmesh or BVH hierarchy could be alternatives: https://github.com/gkjohnson/three-mesh-bvh.

[elkizana]

@donmccurdy thank you !
Have you looked at https://github.com/lo-th/phy

[donmccurdy]

Very cool! I hadn't seen this yet. It supports higher-end WASM-based physics engines like Havok and Rapier, and might have better options for you indeed.

[elkizana]

how can it have more detailed collision ?

[donmccurdy]

Cannon.js has some significant limitations on collisions with trimesh bodies — discussed in more detail at pmndrs/cannon-es#21. I believe Rapier and Havok have better options for that, but it's always going to be more expensive than colliding with primitive shapes.

In general though, meshes are just a pile of triangles as far as the runtime can see, so it's difficult for an engine to guess how you want to simulate it for performance vs. detail. Usually a good idea to make that decision for the engine if you can.