Too many constraints and dynamic objects in simulation?

[Gickl]

Hi,

i want to simulate a tracked vehicle and started with the first short track shown in the picture ( 28 links, 2 wheels --> 30 constraints). the track itself is working alright. but the frame rate is about 4 frames per second...and i actually have to simulate 2 chains with more links...

is this a general problem of Bullet caused by too many objects and/or constraints or is it possible to simulate such things with other configurations? or in other words, can I do something to get it faster?

Thanks in advance
Gickl

[Gickl]

i just considered if it is better to use the same collision shape for all the links. at the moment i create new collision shapes for all the convex parts of a link, build a compound shape and construct a rigid body with it. would it be better to use only one compound shape and build all the rigid bodies with the same shape but with other motion states?

it is not easy to test at the moment because of my current implementation framework, so i ask...

[dern23]

Are you compiling in Release or Debug? Debug can be up to ~10x slower than release due to the lack of optimizations.

[Basroil]

Way too many constraints in a loop. That thing is going to slow down (every body is checked for collisions) and be unstable (long chains tend to be unstable). Sure you can't just estimate it as two cylinders and a box with custom contact/friction?

[Gickl]

so you mean boxes as chain links? how could i configure the custom contact or friction? i can't imagine that friction would keep the chain on the wheels and that you can simulate high forces on the track...

[Basroil]

Not boxes, box. Rather than have bullet calculate the dynamics you do it yourself. You could probably simplify it even more and just use a single raycast vehicle, but you'll need to check that demo to see if it does what you want.

[Gickl]

if i can't get it faster my idea was to approximate the shape of the track with wheels (cylinders). maybe with interlaced wheels side by side so that there are no gaps between the wheels and that the surface is almost flat...is that what you meant? i would modify the friction so that the wheels behave like a rubber track..

[Basroil]

if i can't get it faster my idea was to approximate the shape of the track with wheels (cylinders). maybe with interlaced wheels side by side so that there are no gaps between the wheels and that the surface is almost flat...is that what you meant? i would modify the friction so that the wheels behave like a rubber track..

Almost, but since you'll be using custom friction callbacks anyway you might as well use two cylinders (for the ends) and a box as tall as the cylinders and as wide as the center of one cylinder to the next in place of the track . That would lower the number of objects to three, one of which is the second simplest primitive in bullet.

[Gickl]

but a box would be a static object relative to the body of the robot...how could i use this box for the robot's advance?

[Basroil]

Tried looking at the raycast vehicle tutorial? It's probably easier to compute the internal reactions easier without bullet.

[Erwin Coumans]

Hi,
the track itself is working alright. but the frame rate is about 4 frames per second...

If the problem is mainly performance, you need to share a performance profile.

Use a CProfileManager::dumpAll() right after a slow 'world->stepSimulation' and share the console output.
This will tell you where the performance goes. You need to execute the profile in Release/optimized mode (-O2). Debug mode is always slow.

I would guess that your performance problem is mainly due to collision detection. If so, try using simple collision shapes (btBoxShape or btConvexHull, and not btBvhTriangleMeshShape or btCompoundShape etc) or disable collision between objects using collision group masks.

Thanks,
Erwin