bottleneck on btRaycastVehicle

[mickey]

Hi

Please see attached screen shots.



You can see here that when my vehicle collides with the stack, the step simulation spikes to 85% - leaving only a fraction of time left for rendering.



Actually, a lot of times the updateVehicle and solveConstraints spikes to 30% both. and the rest all goes to performDiscreteCollisionDetection.

My vehicle is using a convex hull shape, but even the default bullet demo box shape spikes as high as 60 - 70% when colliding with the stack. When the vehicle is not colliding with anything except the floor, the simulation takes as much as 60% constantly.

When i removed the vehicle from the dynamics world - leaving only rigid bodies and a kinematic character controller and my btvTriangleMeshShape (30k+ triangles), step simulation only takes 20% - 30%. My collision ground is a static plane and my vehicle initialization is almost exactly the same as the one in the bullet demo if that helps.

Would appreciate any ideas on how to optimize or remove this bottleneck on vehicles, or if any other share similar simulation.

Thanks in advance.

[pico]

Try to update to the latest SVN revision. It has a new rayCast code which may solve your problem.

[mickey]

Apparently it did not help, upgraded to 2.73 rc2-r1498

The simulation slows down the most when it collides with the static scene (using bvhTriangleMeshShape) compared to the other primitive rigid body shapes, but nevertheless the slow down is very noticeable.

Any ideas?

[Erwin Coumans]

How many vertices are used for the convex hull chassis of the vehicle?

Thanks,
Erwin

[mickey]

Hi Erwin,

thanks for trying to help. That would be 1084 vertices. But do note that even if i use a normal box shape like the one in the demo, my FPS still drops dramatically.

Its like whenever the vehicle hits with something the whole simulation would slow down then dramatically fast forward after the collisions.

Please let me know if you need any other information.

Thanks.

[Erwin Coumans]

Hi Erwin,

thanks for trying to help. That would be 1084 vertices. But do note that even if i use a normal box shape like the one in the demo, my FPS still drops dramatically.

That is way too many (even though a btBoxShape is slow). Can you please reduce the number of vertices of the car and the barrels (and any other convex shape) using the btShapeHull utility?

Its like whenever the vehicle hits with something the whole simulation would slow down then dramatically fast forward after the collisions.

Please let me know if you need any other information.

• What kind of CPU are you using (brand/type/clock speed)?
• Which compiler do you use? Do you use an optimized/release or debug build?
• Did you change any default Bullet setting in any way (solverInfo.m_iterations etc)?
• What broadphase do you use and what parameters do you pass the broadphase? Can you try btDbvtBroadphase?
• What parameters do you pass into stepSimulation exactly?
• Can you upgrade to latest RC3 and add a CProfileManager::dumpAll(); after stepSimulaton(), and copy/paste the frame output from the frame that delays.

Thanks for the feedback,
Erwin

[mickey]

Reducing the vertex count using btShapeHull definitely helped cut the bottleneck by 70%. It went down to a mere 38 vertices.

However, the frame drop is still noticeable. Please see 2 screen shots:



The vehicle here rammed a group of rigid bodies and a static shape (gray box(bvhTriangleMeshShape), the solvedConstraint and performDiscreetCollisionDetection both share the same amount of load. Though a lot of times the solvedConstraints would spike 30% more.



Here I just ram the vehicle into a static shape(bvhTriangleMeshShape, shares with the gray box), and only the performDiscreetCollisionDetection takes all the load.

* What kind of CPU are you using (brand/type/clock speed)?
* Which compiler do you use? Do you use an optimized/release or debug build?
* Did you change any default Bullet setting in any way (solverInfo.m_iterations etc)?
* What broadphase do you use and what parameters do you pass the broadphase? Can you try btDbvtBroadphase?
* What parameters do you pass into stepSimulation exactly?
* Can you upgrade to latest RC3 and add a CProfileManager::dumpAll(); after stepSimulaton(), and copy/paste the frame output from the frame that delays.

* Intel Core 2 Quad CPU 2.4 GHZ
* VS 2008, using both debug builds of Bullet and DirectX
* I don't think so
* I tried using btDbvtBroadphase to swap my existing one - btAxisSweep3, could not notice the difference, actually btAxisSweep3 might be faster.
* Hmm.. I just call stepSimulation with a single parameter - 1/60.0f, and let the app run as fast as it can (no vSync)
* My app's now running the latest build, though btPoint3.h seems to be missing, I always needed to copy from an earlier build.

[reltham]

The debug build of bullet is considerably slower. Especially due to things like the vector accessors that optimize out in a release build. In a profile of a debug build, btVector3 accessors (getx, gety, etc) show up as a huge portion of the run, but in release they are gone.

I would never do performance testing in a debug build. Try your tests with a release build (at least of the bullet libs).

[mickey]

Yes you're right. I build against the release libs and my app's running smooth now.

Sorry about that, should have known better.