Are there more details about how collision against aggregates works?

[Zeblote]

I noticed that when I move a large aggregate with thousands of shapes around, physx is running a task every tick to spatially sort the shapes inside it at the new orientation. Is there documentation anywhere on why the algorithm requires this step? I'm wondering if it could be removed somehow, even if that makes the rest of the collision detection slightly more expensive. Perhaps the bounds of the shape colliding with it could be transformed to the orientation of the aggregate instead?

This is assuming that I will never need collision between two massive aggregates, only single shapes or very small ones vs these big ones. There's usually a factor 100 to 1000 between their shape counts, so I'd like to leave the big ones alone (i.e. not re-sort shapes) as much as possible.

[PierreTerdiman]

Is there documentation anywhere on why the algorithm requires this step?

This is part of the "sweep and prune" (a.k.a. "sort and sweep") algorithm.

I'm wondering if it could be removed somehow, even if that makes the rest of the collision detection slightly more expensive.

If you only have to care about the case where one shape collides against an aggregate, then yes. But of course the current code is written to efficiently handle the worst-case.

Perhaps the bounds of the shape colliding with it could be transformed to the orientation of the aggregate instead?

That wouldn't be enough. This assumes that the relative positions of actors within the aggregate don't change, i.e. that the sorting order is not invalidated by the "new orientation". But this is usually not the case: aggregates are usually for dynamic actors who move around relative to each other, so there usually isn't a "new orientation" but rather multiple new orientations - one per actor in the aggregate.

Are you sure you need an aggregate? Maybe you just need a "compound", i.e. one actor with multiple shapes?

This is assuming that I will never need collision between two massive aggregates, only single shapes or very small ones vs these big ones.

Yes, if you only have a single shape to collide against an aggregate then the sorting is not necessary. There is however no special codepath for this at the moment.

Even without any shape colliding against the aggregate, you might need self-collisions (e.g. for a ragdoll in an aggregate). So the sorting can happen even with a single (dynamic) aggregate, each frame, when e.g. the body parts of the ragdoll move around.

There's usually a factor 100 to 1000 between their shape counts, so I'd like to leave the big ones alone (i.e. not re-sort shapes) as much as possible.

How much time is spent in sorting? It's usually "free" compared to everything else around.