[Solved]Performance problem with bullet into a thread

[spy32]

Hi,
we're currently programming a game engine, which primarily uses three threads: One for rendering, one for client calculations and one for server and physic calulations. The render thread can run with the highest possible frame rate. The client & the server thread are forced to run at 50 fps (20 ms frame duration). That's what we accomplish with thread sleeps.
For better comprehension:
Server & Physics thread: Fixed frame rate: 50 fps
Client thread: Fixed frame rate: 50 fps
Render thread: Variable frame rate. Runs as fast as possible.

However bullet needs more than 2 ms per frame to perform its internal physic calculations, although our test scene is very basic and just contains a few box shapes, a character controller and a terrain. It's even that basic that our render thread runs (at my machine) with > 900 fps. The much more complex samples which are shipped with each bullet release are performing much better on my machine. Another significant fact is, that this problem seems to not exist on Linux machines. Has anybody else had a bad experience with running bullet into a thread?

Thanks,
Christian

EDIT: Added a zero to '2 ms'. (Thanks to marcusl)

[spy32]

Does nobody have any idea? I would provide more information, if you have said me what's needed.

[S.Lundmark]

It would be very helpful if you could provide a dumpAll from the bullet performance debugger, or some sort of timings to display what kind of issues you are experiencing regarding bullet performance.

What platform are you running? If it's a pc, what type of hardware?

Character controllers are usually quite expensive, they use convex-casts which in some cases can be very expensive.

Still, >2ms sounds like a lot. Are you sure that you are not running in debug? Running the libraries in release tend to speed up performance quite a bit.

/S

[spy32]

I am sure that I am running in debug mode with debug libraries and no optimations at all.
But we tried release mode and it's still far to low fps for such a basic scene.

My system:
Core 2 Quad Q6700 @ 2.66 Ghz
ATi Radeon HD4850
4096 MB DDR2 RAM
Asus P5QC mainboard

As you can see this PC really has to be capable to do this.
I gonna send you the profiler dumps as soon as a I get them from a team mate of me.
Thanks for your response,
Chris

[marcusl]

50 fps => 20 ms, not 2 ms.

Also, thread.sleep() is not usually very precise. I'd not use that for values below 15-30 ms (at least not on Windows).

[JanK]

Indeed, on windows "sleep" usually sleeps for at least 10ms.

"I am sure that I am running in debug mode with debug libraries and no optimations at all. "

That is confusing. Compile EVERYTHING in release, link to Bullets release-libs and then try again. Otherwise discussing performance problems is pointless, no matter how fast your CPU is.

Jan.

[Erwin Coumans]

Please provide a performance dump, using

Code: Select all

stepSimulation(deltaTime);
CProfileManager::dumpAll();

during a slow simulation frame.

Thanks,
Erwin

[spy32]

Thanks for your responses, but actually the point is that it runs fine on linux but not on windows. So I guess it has something to do with the issue that Sleep() in windows doesn't work correctly with an argument smaller than 10 [ms]. Erwin, I'm going to provide you a full profiler dump very soon (For some reasons my dumper isn't working as it should.)

-----------------------------------
Fix:
I've just tried the release version of bullet and it runs super smooth. I really didn't know that the additional debug information is slowing down bullet that drastically and that compiler optimations are really that efficient. Thanks for the hint. Therefore a profiler dump isn't still nesscary. Maybe you should write somewhere in the manual, that the debug build is decreasing the simulation performance hugly. (Cannot remember that I read that anywhere)