So, I tried moving my game over to Bullet this weekend at long last! Unfortunately my initial tests aren't looking too good performance-wise.
I have a large world using the double precision build of bullet. Everything starts off nice with ~8 bodies in there (70 fps) but as more bodies get added (all in the same ~2k locality) the frame rate drops to 9 fps with about 40 bodies (~30 of them are static)! I presume something is going wrong here?
Looking at the profile info (manually - no std output - may have missed something) it looks like most of the time is spent in dispatchAllCollisionPairs. Changing the broadphase between Dbvt and SAP gives no improvement.
Also, if I add a single small terrain object (160x160) using a btHeightfieldTerrainShape, the framerate *starts* at 9 fps!
I know from the demos that bullet can easily handle a setup of this magnitude - is it maybe the double precision that's killing it?
Double precision: performance
-
Dragonlord
- Posts: 198
- Joined: Mon Sep 04, 2006 5:31 pm
- Location: Switzerland
Re: Double precision: performance
Double precision is usually not the problem even if you have only a 32bit system. On 64bit double is actually slightly faster than float.
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Double precision: performance
You are dealing with a fully optimized build of Bullet right? Debug builds are slow.
The single precision floating precision build is generally faster, it has SIMD optimizations not available in double precision. Still, the double precision version shouldn't be that slow.
I'm not sure about the btHeightfieldTerrainShape performance: it isn't being tested and optimized as good as other collision shapes.
Is it purely related to the btHeightfieldTerrainShape? Otherwise you could try to export a .bullet file and attach it to this forum topic, so we can check where the bottlenecks are (btHeightfieldTerrainShape is not yet supported in the .bullet format)
Thanks,
Erwin
The single precision floating precision build is generally faster, it has SIMD optimizations not available in double precision. Still, the double precision version shouldn't be that slow.
I'm not sure about the btHeightfieldTerrainShape performance: it isn't being tested and optimized as good as other collision shapes.
Is it purely related to the btHeightfieldTerrainShape? Otherwise you could try to export a .bullet file and attach it to this forum topic, so we can check where the bottlenecks are (btHeightfieldTerrainShape is not yet supported in the .bullet format)
Thanks,
Erwin
-
Dragonlord
- Posts: 198
- Joined: Mon Sep 04, 2006 5:31 pm
- Location: Switzerland
Re: Double precision: performance
Correct me if I'm wrong but... doesn't x86-64 (aka SSE2) have 16 128-bit registers which you can feed with two doubles per register? So why should it not be possible to do SIMD with doubles?
-
MGB
- Posts: 12
- Joined: Wed Aug 24, 2005 8:54 pm
- Location: uk
Re: Double precision: performance
Unfortunately it is a debug build -- I need to dev with debugging info and don't appear to be able to reconcile the runtime library for a bullet release build (/MTd /MD )
I was comparing to the speed of the demos also built in debug, which run at a reasonable rate with comparable body counts.
It's not purely related to the btHeightfieldTerrainShape.
[ed] Well: resolved the runtime library stuff and the release version is fast with the terrain too... Still, wonder why the debug demos ran ok with higher body counts... maybe debug is a lot more sensitive to the precision.
I was comparing to the speed of the demos also built in debug, which run at a reasonable rate with comparable body counts.
It's not purely related to the btHeightfieldTerrainShape.
[ed] Well: resolved the runtime library stuff and the release version is fast with the terrain too... Still, wonder why the debug demos ran ok with higher body counts... maybe debug is a lot more sensitive to the precision.