I think this issue I have was once mentioned here ( #730 ), and now, after about 2 years, I also ran into that problem while using rapier.js compat version 19.3 (I think this version does not have the compound collider feature fully implemented, so I could not fully verify whether compound colliders "fix" it). The issue is very easy to describe: building a world with a single body having multiple colliders attached to it will eventually lead to very bad performance (slow execution of the step function), while this should not be happening given that there are no other bodies (and that the only body will eventually fall asleep).
Reproduction code
I wrote a simple example using two different physics engines. One is rapier.js, and the other one is planck.js, which is fully written in JavaScript, so it is supposed to be slower in pretty much everything. The code can be accessed through these two (flems.io) links:
rapier and planck.js. All I do is creating a simple world and adding a single body with 2210 convex colliders attached to it. I wrote both codes in a way that makes them very easy to compare line by line.
Observed behavior
The Rapier code first starts slow at around 70 ms per step (expected behavior), and eventually stabilizes at 26 ms per step. planck.js, on the other hand, shows a step time close to 0 from the very beginning (around 0.1 ms per step sometimes), so it is pretty much infinitely faster than the Rapier simulation.
It is expected, based on both common sense and the Rapier documentation, which states, "The main differences between the two approaches is about collision events," that colliders attached to a single body should be considered as a single entity. However, based on the results above, this makes me wonder whether colliders attached to the same body are still processed individually in parts of the pipeline, which could explain the significant performance impact.
So either the documentation is misleading by not mentioning this very important distinction between the two approaches, or this is unintended behavior. If it is the documentation that is wrong, then I feel like this issue could be fixed within a day by simply adding (fixing) a note about the two approaches. However, it is still weird to me that this issue was mentioned before in ( #730 ) and apparently has still not been fixed after 2 years (or maybe it was, but not in the JavaScript version of Rapier).
I think this issue I have was once mentioned here ( #730 ), and now, after about 2 years, I also ran into that problem while using rapier.js compat version 19.3 (I think this version does not have the compound collider feature fully implemented, so I could not fully verify whether compound colliders "fix" it). The issue is very easy to describe: building a world with a single body having multiple colliders attached to it will eventually lead to very bad performance (slow execution of the step function), while this should not be happening given that there are no other bodies (and that the only body will eventually fall asleep).
Reproduction code
I wrote a simple example using two different physics engines. One is rapier.js, and the other one is planck.js, which is fully written in JavaScript, so it is supposed to be slower in pretty much everything. The code can be accessed through these two (flems.io) links:
rapier and planck.js. All I do is creating a simple world and adding a single body with 2210 convex colliders attached to it. I wrote both codes in a way that makes them very easy to compare line by line.
Observed behavior
The Rapier code first starts slow at around 70 ms per step (expected behavior), and eventually stabilizes at 26 ms per step. planck.js, on the other hand, shows a step time close to 0 from the very beginning (around 0.1 ms per step sometimes), so it is pretty much infinitely faster than the Rapier simulation.
It is expected, based on both common sense and the Rapier documentation, which states, "The main differences between the two approaches is about collision events," that colliders attached to a single body should be considered as a single entity. However, based on the results above, this makes me wonder whether colliders attached to the same body are still processed individually in parts of the pipeline, which could explain the significant performance impact.
So either the documentation is misleading by not mentioning this very important distinction between the two approaches, or this is unintended behavior. If it is the documentation that is wrong, then I feel like this issue could be fixed within a day by simply adding (fixing) a note about the two approaches. However, it is still weird to me that this issue was mentioned before in ( #730 ) and apparently has still not been fixed after 2 years (or maybe it was, but not in the JavaScript version of Rapier).