Advice on optimizing world geometry for use in Bullet

[AshMcConnell]

Hi Folks,

In my test application I have a couple of meshes representing the racing track (world geometry) in my game. I am dropping a couple of cars on there (with box collision shapes).

I have profiled the collision detection and its taking quite a long time (2-3ms typically) on my 3.6Ghz dual core machine.

I have set the 2 track mesh collision objects to static objects using: -

myObj->setCollisionFlags(btCollisionObject::CF_STATIC_OBJECT);

What would be the first things to try when optimizing this? Would I split it up into a quadtree / octtree? and submit many collision meshes?

Any suggestions gratefully received.

All the best,
Ash

[Erwin Coumans]

Are you using the btBvhTriangleMeshShape to store the mesh?

How many triangles is your mesh? Which version of Bullet are you using? Please use Bullet 2.42b (very latest).

UPDATE: Ignore my previous remark about raycasts: raycast are actually benefitting from Bvh (aabb tree) as long as they are short, which is the case for vehicles.

Thanks for the feedback,
Erwin

[AshMcConnell]

Hi Erwin,

Thanks for the quick response as always

I am indeed using the btBvhTriangleMeshShape for both meshes that represent the track.

The 2 meshes have 3528 tris and 10080 respectively.

The 2 "cars" are merely 2 btBoxShapes, I am not using raycasts (at least not yet).

I am using a slightly dated version (2.32). I wanted to check that I was using Bullet the way it was intended to be used before upgrading to the latest version.

Thanks Again,
All the best,
Ash

[AshMcConnell]

Hi Erwin,

I have updated to the latest version and I reckon its about twice as quick. It is executing in around 0.8ms normally, but it occasionally it executes in 2-3ms.

Even 0.8ms seems a little slow for a couple of boxes on a mesh, can you think of anything I could do to quicken things up a little?

By the way, I am just using the collision detection part of Bullet + Physics from a friend.

Here is it working: -

http://www.siroccoracing.com/indev/CollidingLotii2.avi

All the best,
Ash

[AshMcConnell]

Anyone else got any suggestions?

Has anyone benchmarked the difference between a lot of small collision meshes and a big one? Just wondering if it would be faster.

Thanks guys!
All the best,
Ash

PS. Making progress: - http://www.siroccoracing.com/indev/drivingLotus.avi

[Erwin Coumans]

Please upgrade to the latest Bullet 2.42b, it might help a bit.

I assume you are using the btAxis3Sweep broadphase too, and btBvhTriangleMeshShape?

The 2 meshes have 3528 tris and 10080 respectively.

In that case, it seems to be a good idea to just use 2 static triangle meshes in that case, using the btBvhTriangleMeshShape. It all depends, but in general: for static trianglemeshes, its best to gather 'fairly large' meshes, so don't put an enormous amount (thousands) of small static meshes into the broadphase.
There is some maximum amount of triangles per static bvh mesh, around 64k probably. Preferably use a small collection of large triangle meshes, but its not necessary to collect ALL triangles into one. Just keep the amount of static objects 'reasonably' low.

Hope this helps, and thanks for sharing this fun video, the wheels need some tuning so they match the graphics artwork

Erwin

[AshMcConnell]

Hi Erwin,

As long as i'm doing more or less the right thing, I think it's probably fast enough for the minute and hopefully there are some optimizations that might speed things up in the next few months.

I am using the current version with btAxis3Sweep and btBvhTriangleMeshShape.

I think that it is actually only slow occasionally. I output the max and min time for the coldet operation and i get typically: -

smallestColDetTime: (0.06500)
biggestColDetTime: (8.68400)

These results are in release mode.

I'm wondering if something else is interupting the CPUs for a brief second and causing a brief blip.

I've fixed my wheels

http://www.siroccoracing.com/indev/LotusFun.avi if you are interested

Thanks again for the help
All the best,
Ash