Dirk, sorry for the late reply, I got back working on my physics engine recently. I've understand your idea. However, do you assume the edge IDs are the hull's edges IDs? And for general convex polyhedra, are you considering a adjacency data structure for filling the in/outcoming edge of a particular vertex?

Maybe I can answer before Dirk reads.

Edge IDs don't need to necessarily line up with whatever hull format you have. You just need a way to uniquely describe when a feature on hull A hits a feature on hull B, for all possible feature combinations.

What Dirk is describing is pretty straightforward to implement if you store hulls with half-edge structure, and in this case an edge ID can just use the half-edge index. So, yes, you definitely need some kind of adjacency structure that lets you describe which edges are connected to which verts for a given face.

What Randy says is correct. Box2D Lite has an example implementation of this and it is straight forward to extend this to 3D.

I'll share here my solution based on the previous recommendations.

Let's see the image below. Let the reference polygon be the box 1 and the incident the box 2. The incident polygon is CW (from the normal POV), and CCW from the current view (as in the figure).



All edges of the reference face side planes are the half-edge IDs. Then, this is how the vertices should be filled in on the Sutherland-Hodgman clipping:

'1' is the reference face and '2' is the incident face (as the image).

// Build faces (keep plane IDs...

// Build incident polygon:
// The incoming edge of each polygon point is the current half-edge id, and the outcoming is the next half-edge of the current one.

(...)

if ( v1 is behind and v2 is in front ) {
//intersection point ip

ip.inEdge1 = null;
ip.inEdge2 = v1.outEdge2;
ip.outEdge1 = planeEdge;
ip.outEdge2 = null;
}
else if ( v2 is behind and v1 is in front ) {
//intersection point ip and v2

ip.inEdge1 = planeEdge;
ip.inEdge2 = null;
ip.outEdge1 = null;
ip.outEdge2 = v2.outEdge2;
}

(...)

// Flip if needed

I've looped through all contact IDs and they're unique and they're matching. A stack of 10 boxes with density 0.2km^3 (2x2x2m) bounces a little bit initially but stabilizes after ~6s, using 10 iterations and warm-starting. Is this a common behaviour? Do you guys have a video or a description of a simple cenario so I can compare with mine?

Looks good and the stability sounds about right as well. In order to test it run your scene with 10, 20, 50, 100, ... iterations. The stack should become stable at some point indicating that your solver converges.