btHeightfieldTerrainShapes or equivalent approach

[Gogo]

I've been looking into Bullet's collision shapes for an iphone game I'm working on (a game with essentially pinball-like gameplay). Ideally, I'd like to have arbitrary odd shapes used on the playing field, so after looking at the collision shapes available, it looked like using a btHeightfieldTerrainShape filled with the per-pixel collision data of the game's map would allow me to do this. I've implemented this and it works very well, however performance on an actual iphone is pretty poor (4fps!). After looking into it a little more, I seem to notice that the btHeightfieldTerrainShape is actually a triangle mesh (is this correct?) which results in a lot of work for the humble iphone cpu.

So, my question is, is it possible to acheive this kind of functionality with better performance, perhaps with a different approach? Or is the only realistic option on iphone to restrict collisions to the simple primitive collision types?

[Erwin Coumans]

The btHeightfieldTerrainShape uses a heightfield and not a triangle mesh.

Bullet doesn't perform well when build without optimizations. Is this 4fps in optimized -O2 build?

Can you provide a performance dump, calling CProfileManager::dumpAll(); after stepSimulation?
Thanks,
Erwin

[Gogo]

Thanks for the reply, useful to know that it isn't actually a triangle mesh. However, I actually abandoned the btHeightfieldTerrainShape approach since my initial post as I assumed it just wouldn't be fast enough. I will try again with it shortly though and post here with the results from the CProfileManager call.

Btw the 4fps result was from a regular release build, no other compiler options were tweaked. I'll try to test with the other optimization flags also.

[Gogo]

Okay, implemented the btHeightfieldTerrainShape back in, getting about 6fps this time (with a slightly different scene). This is the log from calling CProfileManager::dumpAll() after stepSimulation:

----------------------------------
Profiling: Root (total running time: 114.266 ms) ---
0 -- stepSimulation (99.97 %) :: 114.229 ms / frame (1 calls)
Unaccounted: (0.032 %) :: 0.037 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 114.229 ms) ---
...0 -- synchronizeMotionStates (0.05 %) :: 0.062 ms / frame (2 calls)
...1 -- internalSingleStepSimulation (99.90 %) :: 114.116 ms / frame (1 calls)
...Unaccounted: (0.045 %) :: 0.051 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 114.116 ms) ---
......0 -- updateActivationState (0.01 %) :: 0.013 ms / frame (1 calls)
......1 -- updateCharacters (0.00 %) :: 0.004 ms / frame (1 calls)
......2 -- updateVehicles (0.00 %) :: 0.003 ms / frame (1 calls)
......3 -- integrateTransforms (0.05 %) :: 0.052 ms / frame (1 calls)
......4 -- solveConstraints (0.10 %) :: 0.116 ms / frame (1 calls)
......5 -- calculateSimulationIslands (0.01 %) :: 0.016 ms / frame (1 calls)
......6 -- performDiscreteCollisionDetection (99.68 %) :: 113.755 ms / frame (1 calls)
......7 -- predictUnconstraintMotion (0.05 %) :: 0.056 ms / frame (1 calls)
......Unaccounted: (0.089 %) :: 0.101 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 0.116 ms) ---
.........0 -- processIslands (58.62 %) :: 0.068 ms / frame (1 calls)
.........1 -- islandUnionFindAndQuickSort (12.93 %) :: 0.015 ms / frame (1 calls)
.........Unaccounted: (28.448 %) :: 0.033 ms
............----------------------------------
............Profiling: processIslands (total running time: 0.068 ms) ---
............0 -- solveGroup (64.71 %) :: 0.044 ms / frame (1 calls)
............Unaccounted: (35.294 %) :: 0.024 ms
...............----------------------------------
...............Profiling: solveGroup (total running time: 0.044 ms) ---
...............0 -- solveGroupCacheFriendlyIterations (13.64 %) :: 0.006 ms / frame (1 calls)
...............1 -- solveGroupCacheFriendlySetup (15.91 %) :: 0.007 ms / frame (1 calls)
...............Unaccounted: (70.455 %) :: 0.031 ms
.........----------------------------------
.........Profiling: performDiscreteCollisionDetection (total running time: 113.755 ms) ---
.........0 -- dispatchAllCollisionPairs (99.88 %) :: 113.623 ms / frame (1 calls)
.........1 -- calculateOverlappingPairs (0.00 %) :: 0.005 ms / frame (1 calls)
.........2 -- updateAabbs (0.08 %) :: 0.096 ms / frame (1 calls)
.........Unaccounted: (0.027 %) :: 0.031 ms


Hope the info is useful. Anyway, I suppose this is unlikely to be fast enough to use on iphone in the short term, so I guess the best solution for me at the moment is to restrict collision shapes to the basic primitives really. Here's hoping for the future though!

[Zenja]

I'm rendering a 771x723 multitextured terrain and using Bullet physics on the iPhone, and I get around 45fps. Other than an occassional tunnelling effect where my fast moving objects penetrate terrain, performance of btHeightfieldTerrainShape on the iPhone is great.