Use of btStridingMeshInterface

[fullmetalcoder]

I'm pretty sure InternalProcessAllTriangles is called when I use btConvexTriangleMeshShape.
Another thing I'm quite sure about (reported on Google code tracker) is that I can get significant performance improvements by reimplementing optimizing InternalProcessAllTriangles() instead of using the default implementation.
And I managed to get further performance improvements by subclassing convex triangle mesh shape and doing the same kind of optimization in getLocalSupportingVertexWithoutMargin() and also in the batched queries even though they are not used often.

just for the record the speedup is measured in term of FPS on a sample app with only three models (one concave terrain and two convex characters loaded, convex characters being controlled by a heavily modified version of the kinematic character controller). I measured a consistent average FPS rise of more than 200% (as reported on the tracker).

I may have a look at convex hull shape but from what you say it really isn't what I nead has I want to share mesh data between graphics and physics, mostly because these are animated meshes and I neither want to have incorrect collision based on a static frame nor to be forced to perform deep copies of that data on every frame.

[reltham]

FYI, Using FPS as your measuring stick is not the best idea. You should get some timing results.

You can jump from 30 to 60 fps when vsynced by having a timing difference of a fraction of a ms. Even without vsync FPS is still unreliable.

[fullmetalcoder]

I know fps are not the best way to measure performance but they do give an idea.
Other figures of interest to quantify performance gain of my modified Bullet version using my custom convex trimesh shape :

valgrind (callgrind) run of the sample app, Bullet r1211 :
* localGetSupportingVertex takes 24% of the global execution time (which includes data loading and all the initialization ...) alone
* average fps around 0.3

same with Bullet r1211 + patch :
* localGetSupportingVertex takes less than 13% now
* average fps above 1.2

Also, what I call FPS is actually 1 / dt where dt is the elapsed time since previous frame; it is computed every frame and vsync can not affect this as it is purely software and I'm using AVERAGE values as references...

[Erwin Coumans]

With 0.3 - 1.2 FPS it seems something is wrong.

1) if you want good performance, don't use btConvexTriangleMeshShape, but the btConvexHullShape.

2) the number of vertices for a btConvexHullShape should be way less then 100. If the graphics mesh contains more vertices, the number of vertices used in the convex collision hull should be reduced using the btShapeHull utility. For animated meshes you can run this utility every frame to refresh the vertices of the btConvexHullShape.

Let's first get Bullet 2.70 out of the door, including your requested improvements (unsigned int and virtual methods) and then discuss further ways to improve the performance for your simulation.
Hope this helps,
Erwin

[fullmetalcoder]

The low fps values reported in the previous post are about normal. If you read carefully you will notice that I was running my sample app under Valgrind, an excellent profiler, which as every profiler makes the program a damn lot slower.

1) how significant would the difference be and why? Isn't there a way to improve btConvexTriangleMeshShape instead?

2) my meshes have 500-2000 tris. The two problem of using a btConvexHullShape are that I would be forced to duplicate the data (bigger memory footprint + time to copy) and to refresh it every frame (not that easy and presumably time consuming if I have to transform it). I guess the duplication is not much of an issue if it only takes less than a hundred vertices but transformation remains...

Good to know that you will include the suggested patches. Have you given a look to the other patch I submitted to the tracker. It is fairly small and allows significant performance improvements as I explained above (only affects btConvexTriangleMeshShape and btPolyhedralConvexShape in a source-compatible way)