Our goal is to have APEX 1.1 integration ready for the October release of UDK.

Actually the aggregate collision hulls help intersecting meshes as well. I'll explain.

When slicing with perfectly flat planes, the convex hulls of the graphics meshes naturally do not overlap. But when noise is introduced into the slicing surface, the convex hulls will overlap. A while back we treated this by choosing a "midplane" and clipping each chunk's convex volume against that plane. This prevented overlaps, but when the slicing noise had significant amplitude, this often trimmed the collision volumes so much that very little (and sometimes nothing!) was left. So we introduced a maximum trimming amount, based upon a percentage of the chunks' widths. The convex volumes will get trimmed up to that amount, but no more. This prevents the collision volumes from being whittled away too far, but also leads to overlaps, which you're seeing.

When there is only one convex volume per chunk, one is left with this dilemma - shrinking collision volumes or overlaps. We could have introduced a slider to expose the maximum trimming distance, but this seemed too fiddly. A better solution is to allow non-convex representations, which is exactly what we have with the convex aggregates. We still apply the same trimming algorithm to the convex volumes in the aggregates, but since they more closely fit the graphics meshes, the amount of trimming is (usually significantly) reduced. This reduces the chance of hitting the trimming maximum distance, and so the trimmed volumes will not overlap.

You mentioned Voronoi fracture, which we are also planning on implementing.

We are also currently working on a DCC tool integration for destruction authoring, which will allow you edit not only the collision hulls, but the graphics meshes for each chunk.

Bryan Galdrikian
APEX Development
NVIDIA