Real-Time Physics Simulation Forum

Hi,

in our game we use a low number of rayTests each each frame.
The performance for this was very good. However, as the levels grew the cpu usage exploded.

When looking at the rayTest and sweepTest source i see they check ALL(!) AABBs in the physics world. This explains the high cpu usage.
Wouldn't it be possible to use the broadPhase algorithm to solve this linear relation?

The current implementation unfortunately breaks our game.
Is there eventually already a function that gets back all objects within a AABB from the broadphase?

After more digging in the Forum i've seen more people suffer from this problem.

Erwin encouraged to use btIndexedMesh/btBvhTriangleMeshShape. This will help people to boost casting performance when having lotsa static single meshes.

Unfortunately in our game the bottleneck are the ~100 non static collision objects, which can't be joined.

Currently, Bullet slows down when performing rayTest on all objects.
It performs a brute force AABB calculation and test.

We should include broadphase improvements;
1) don't recompute the AABB for each object but get it from the broadphase
2) instead of traversing all objects, use the broadphase acceleration
structure. Note: the btDbvtBroadphase already has a raytest query, and we can add similar for btAxisSweep3.

Even just doing (1) will speed up things.

It will be schedule for next release, you can track status here:
http://code.google.com/p/bullet/issues/detail?id=109

Thanks for the feedback,
Erwin

Hi Erwin,

thats exciting news.

Thanks a lot!

(1) is implemented, can you test the latest trunk/SVN revision?

http://code.google.com/p/bullet/downloads/list

(2), making use of btDbvtBroadphase, using the ray-AABB tree traversal, will follow later,

Hope this helps,
Erwin

Several rayTest optimizations have been implemented in the latest trunk:

• The dynamic AABB tree, btDbvt, is used as broadphase acceleration structure
• Some performance issues with the btQuantizedBvh midphase, used for btBvhTriangleMeshShape, has been resolved
• broadphase AABB's are now used, instead of computed on-the-fly. So make sure to call stepSimulation or 'updateAabbs' on the dynamics world before using rayTest.

This gives a huge speed up in our benchmarks. Can you try the trunk revision 1388 and let us know if your performance problem is solved now?
http://code.google.com/p/bullet/downloads/list

Hope this helps,
Erwin

Hello Erwin,
In our project we also need fast raycast and overlap queries, so I use tree structure of btDbvtBroadphase. I found bug function btDbvtAabbMm::Intersect for rays return invalid rusults for some volumes.

I don't have time to search bug and add some new function in which I use btRayAabb2.

After I merged with latest revision and replaced my code by bullet implementaion I found out that bug is still exist, so broad pahse raycast accleration didn't work

shil wrote:I found bug function btDbvtAabbMm::Intersect for rays return invalid rusults for some volumes.

The btDbvt/btSoftBody collideRay/castRay had inconsistent API using ray direction instead of rayFrom/rayTo. It is now consistent with the btCollisionWorld::rayTest API. Also, the implementation is now using btRayAabb2 from src\LinearMath\btAabbUtil2.h. There is a test to compare results with btRayAabb (enable #define COMPARE_BTRAY_AABB2 in Bullet/src/BulletCollision/BroadphaseCollision/btDbvt.h)

Can you test with the latest Bullet trunk revision 1390 to see if the issue has been resolved?
http://code.google.com/p/bullet/downloads/list

Thanks a lot for the feedback,
Erwin

Erwin Coumans wrote:

shil wrote:I found bug function btDbvtAabbMm::Intersect for rays return invalid rusults for some volumes.

Can you test with the latest Bullet trunk revision 1390 to see if the issue has been resolved?
http://code.google.com/p/bullet/downloads/list

Thanks a lot for the feedback,
Erwin

Bug is fixed. Thank you very match!

Hi Erwin,

thanks a lot.

We now updated to the latest revision. The linear relation in rayTest is gone!

Unfortunately, it seems box/trimesh collisions got around 10% percent slower in the latest revision. Do you know a reason for this?
The trimeshes are also animated and do this each frame:
world->getBroadphase()->getOverlappingPairCache()->cleanProxyFromPairs(body->getBroadphaseHandle(),world->getDispatcher());

Before we used the official v2.72.

if using a thin long kinamatic capsule geometry to replace the ray.
(use the nesrest contract point to compute the distance form the ray source).
will it have the adventage of the boradphase with a little bit trade off of accuracy?