Physics simulation stops when generated convex hulls collide

[isaac-mason]

It looks like there may be some issues with generated convex hulls. When two bodies with generated convex hull shapes collide, the physics simulation stops and the page becomes unresponsive.

I made a simple codesandbox demonstrating the issue: https://codesandbox.io/s/repro-three-to-cannon-hull-collision-issue-68jtcd?file=/src/index.ts

I haven't checked what versions have the issue, but it appears to at least be present in 4.0.2, predating the introduction of the getShapeParameters function. The issue may be somewhere in ConvexHull.js?

[isaac-mason]

Happy to help with looking into this too - just need to find some time 🙂

[donmccurdy]

The THREE.ConvexHull is not used by the simulation at runtime — only to construct a CANNON.ConvexPolyhedron. I would guess that because collisions with other types of shapes still work, and the debug outlines look reasonable, the hulls themselves are valid. The way this hangs the browser, it looks a bit like an infinite loop in collision code?

[isaac-mason]

Thanks @donmccurdy. It looks like this might be a duplicate of this issue: #59

There's an interesting related cannon-es issue linked there: pmndrs/cannon-es#103

I'll find some time to have a read and try a few things, will get back here with what I find.

[isaac-mason]

Potentially relevant: schteppe/cannon.js#459 (comment)

Because of the way that cannon.js is programmed, if the convex triangles are not all connected, then convex-convex collision will not work.

[donmccurdy]

The simplifyGeometry() method is intended to ensure vertices are merged and convex triangles are connected...

three-to-cannon/src/utils.ts

Lines 114 to 122 in 2927293

	/**
	* Modified version of BufferGeometryUtils.mergeVertices, ignoring vertex
	* attributes other than position.
	*
	* @param {THREE.BufferGeometry} geometry
	* @param {number} tolerance
	* @return {THREE.BufferGeometry>}
	*/
	function simplifyGeometry (geometry: BufferGeometry, tolerance = 1e-4): BufferGeometry {

...but we invoke it only if we're merging multiple geometries —

three-to-cannon/src/utils.ts

Lines 17 to 29 in 2927293

	// Single mesh. Return, preserving original type.
	if (meshes.length === 1) {
	return normalizeGeometry(meshes[0]);
	}
	// Multiple meshes. Merge and return.
	let mesh: Mesh | undefined;
	const geometries: BufferGeometry[] = [];
	while ((mesh = meshes.pop())) {
	geometries.push(simplifyGeometry(normalizeGeometry(mesh)));
	}
	return mergeBufferGeometries(geometries);

This might be the cause? Unfortunately it's not as simple as just adding a call to simplifyGeometry above — if we simplify single geometries then we can't get precise parameters for primitive geometries, by accessing things like geometry.parameters.radiusTop for cylinders.

There's a lot in this library that could use serious refactoring and better unit tests, sorry for that. 😮‍💨 If you'd be interested in push access and just making more changes as you see fit, I'm happy to go that direction.

[isaac-mason]

Thanks @donmccurdy for the info! I think it's sent me down a good path 🙂

It looks like the issue may be in how getConvexPolyhedronParameters constructs faces? From reading ConvexPolyhedron.clipFaceAgainstHull in the cannon-es repo, this is my current understanding:

As part of convex-convex collision, a list of connected faces is built for a given hull face. The connected faces list is is populated by searching for faces (convexPolyhedron.faces) with vertices that are shared with the given face's vertices (polyA.indexOf(hullA.faces[i][j]) !== -1 - ConvexPolyhedron.ts:L478).

In getConvexPolyhedronParameters, currentFaceVertex is incremented for each face vertex. So when ConvexPolyhedron.clipFaceAgainstHull is looking for connected faces, it won't find any, as all of the face vertex values produced by getConvexPolyhedronParameters are unique.

[isaac-mason]

There's a lot in this library that could use serious refactoring and better unit tests, sorry for that. 😮‍💨 If you'd be interested in push access and just making more changes as you see fit, I'm happy to go that direction.

No apologies are necessary! Thanks for creating and supporting this lib!

I'm pretty keen to get to the bottom of generating convex hulls that support convex-convex collision! Happy to keep on with this and (hopefully) create a PR once I've got something working.

From there, I'd also be happy to help with general improvements/upkeep, for sure 🙂

[isaac-mason]

Sorry, haven't had much time to progress this.

I did however notice there's a new PR in the cannon-es repo for simplifying the creation of convex hulls: pmndrs/cannon-es#155

I did a quick test, simply pulled the QuickHull class from that PR into three-to-cannon, and convex-convex collision works with the faces it returns.

I'm going to watch that PR for now and see if something can be merged into cannon-es itself. If not, pulling that implementation into this lib could be good too!

[donmccurdy]

That sounds promising, thanks!

[isaac-mason]

Looks like that PR was closed. I'll keep watching the related issue, but in the meantime I'll find some time to create a PR using the same approach to fix this issue!