It was tested inside Pierre Terdiman's CDTestFrameWork, with OPCODE Boxpruning, Bullet SAP and Bullet Multi-SAP.
In a nutshell:
- The performance of Multi-SAP should become much better: this initial implementation has excessive overhead due to finding/adding/removing objects from the child broadphases: it uses an AABB tree to find the overlapping child broadphases, rather then a grid.
- The Multi-SAP performance is currently better then SAP above 4096 objects when at least 10% objects move (0.01 in above testbed).
- As soon as you have a lot of objects (above 4096), with around 10% moving, SAP and Multi-SAP is much faster then Box Pruning.
- Multi-SAP uses currently btSortedOverlappingPairCache, with deferred removal, so pairs are not removed by the broadphase. Instead, pairs that are no longer overlapping are removed during pair traversal, using an additional check. Sorting deals with duplicats too.
- The regular SAP uses btHashedOverlappingPairCache (re-using Pierre's work).
- As Pierre already mentioned in his SAP document, this can be nicely parallelized (on SPU, multi-core etc), especially when the pair cache is not shared.
//Static case (updating 10% of objects to same position ( -> no swaps)
//number of objects :OPCODE BoxPruning : Bullet SAP : Bullet MultiSAP
//1024: :0.35ms : 0.03ms : 0.15ms
//8192: :21ms : 0.2ms : 5ms
//16384: :92ms : 0.5ms : 28ms
//Dynamic case, 10% objects are moving as fast as this testbed allows (0.01?)
//number of objects //OPCODE BoxPruning / Bullet SAP / Bullet MultiSAP
//1024: 0.35ms, 0.2ms, 0.25ms
//8192: 21ms , 15ms , 13ms
//16384: 92ms, 80ms, 49ms
You can download binary Multi-SAP demo and source code here.
Thanks Pierre for the test. It helped me finding a few bugs that caused this issue of 'additional' pairs you mentioned in this earlier posting.