btCollisionWorld::convexSweepTest Performance Implications On Switch
Posted: Sat Aug 13, 2022 8:07 pm
I am implementing a collision system involving moving an object composed of a cylinder through the world via btCollisionWorld::convexSweepTest to perform slide movement. The code setup is very similar to that of player slide physics code as seen in https://github.com/RobertBeckebans/RBDO ... r.cpp#L175 in which the slide movement routine may go through several iterations (up to 5) until the direction of movement is parallel with all the collision planes as well as several additional tests for checking stairs, ramps, etc.
I've noticed that the most trivial usage of convexSweepTest on the Nintendo Switch would take up to ~0.5ms to even 1.5ms for just the player alone. There are expectations that there will be multiple objects that will also need to perform slide movement, so performance is already becoming a huge concern. I even found performance to take a significant drop when colliding against creases and other corners. Upon profiling, I saw that the majority of the CPU time spent in was in btGjkPairDetector::getClosestPointsNonVirtual.
The level is composed roughly of ~220 collision objects, which consists of chunks of the level with different filter settings, all using btBvhTriangleMeshShape for the shape type. For moving the object, I use a btCylinderShapeZ for the shape and then calling convexSweepTest to move the object. I also use a custom class that inherits btCollisionWorld::ClosestConvexResultCallback to perform custom filtering as some surfaces are flagged to allow certain objects to collide / don't collide with, such as climbable surfaces, water, shoot-through, etc.
So I am trying to understand *why* its so expensive, even from doing a simple movement from point A to point B. Is it because there are too many static collision objects? I also have setForceUpdateAllAabbs enabled, which otherwise performance would be even worse than what it is right now. Also note that I am testing on a shipping/non-debug build with all optimizations enabled.
I appreciate anyone's time.
I've noticed that the most trivial usage of convexSweepTest on the Nintendo Switch would take up to ~0.5ms to even 1.5ms for just the player alone. There are expectations that there will be multiple objects that will also need to perform slide movement, so performance is already becoming a huge concern. I even found performance to take a significant drop when colliding against creases and other corners. Upon profiling, I saw that the majority of the CPU time spent in was in btGjkPairDetector::getClosestPointsNonVirtual.
The level is composed roughly of ~220 collision objects, which consists of chunks of the level with different filter settings, all using btBvhTriangleMeshShape for the shape type. For moving the object, I use a btCylinderShapeZ for the shape and then calling convexSweepTest to move the object. I also use a custom class that inherits btCollisionWorld::ClosestConvexResultCallback to perform custom filtering as some surfaces are flagged to allow certain objects to collide / don't collide with, such as climbable surfaces, water, shoot-through, etc.
So I am trying to understand *why* its so expensive, even from doing a simple movement from point A to point B. Is it because there are too many static collision objects? I also have setForceUpdateAllAabbs enabled, which otherwise performance would be even worse than what it is right now. Also note that I am testing on a shipping/non-debug build with all optimizations enabled.
I appreciate anyone's time.