0

I've been using the 2d library jbox2d for some time now and been recently looking into the bullet 3d physics engine.

What I'm wondering is what the CPU consumption on a typical quad core, say i5 (I assume bullet is multi threaded?) is going to be.

Even in jbox, it is very easy to create lag and even completely crash a simulation with too much processing and I'm wondering how much more processing power will be lost in a switch to 3d physics using the Bullet engine.

bigcodeszzer
  • 916
  • 1
  • 8
  • 27
  • Ask for confirmation : do you want to compare "bullet3D (C++)" against "jbox2d (Java)"? – javaLover Apr 03 '17 at 09:58
  • It is a C+ library, yes. http://bulletphysics.org – bigcodeszzer Apr 03 '17 at 10:00
  • I had to ask because Bullet3D has been ported to many platforms. – javaLover Apr 03 '17 at 10:16
  • Which is more important to you: the language that the physics engine is implemented in/for or the performance? If it's the performance, it seems you really need to be comparing the C++ implementation of Box2D with the C++ implementation of the Bullet engine. Speaking from experience, I can tell you that the C++ version of Box2D compiled in debug mode will run less than half as fast as it will if compiled in release mode with optimizations enabled. So the optimizations that both libraries are built with will need to be the same too. – Louis Langholtz Apr 04 '17 at 02:30
  • I'm skeptical whether C+ is typically going to be faster than Java. You are correct though, ultimately it is going to depend how it is written. I've not run the program in release mode so I'll have to look into that. Though ultimately I guess I'll just have to test both, look inside the library and run profiler I guess. – bigcodeszzer Apr 05 '17 at 01:14

1 Answers1

0

Large Disclaimer :-

  • I have never used multi-thread for both Physic Engine.
  • I have never used them to create the same application either, because one is 2D, another one is 3D.
  • I will answer from my past memory instead of benchmark them. I accept that it is not a good practice.

If I have to simulate ~100 amount of bodies (2D-rectange in JBox2d, 3D-cube in Bullet) :-

  • C++ compiled with Release mode (optimization turn on)
  • Java compiled with Release mode (not debug mode), using ctrl+F11 Eclipse
  • Computer is not in a stress condition (minium program opened)
  • No constraint (joint for Box2D, btConstraint in Bullet) for both Physic Engines.
  • Body are scattering around (sometimes collide with each other), no stacking.
  • All bodies are not too far away. All with in 1 screen, roughly speaking.
  • I have some game logic, but not too heavy.
  • C++ program is coded well in C++ style (not abuse new/delete, share_ptr much)
  • Windows 7 with specification that can play most current PC games (2017).

I can expect C++ & Bullet-program run faster than Java & Box2D around :- 3 times (quite conservative) - 10 times (common).

Edit:-

I have just remembered a real test case in my old computer a few years ago.

When I ran 400 rectangles in JBox2D, I could barely reach 60 fps with 10-30% CPU in Physic's part .
However, I could add around 4000 cubes in C++ Bullet, and I can get around 60 fps with 10-30% CPU in Physic's part (profiled).

(I note 10-30% because I can't remember the exact number.)

javaLover
  • 6,347
  • 2
  • 22
  • 67
  • I would typically expect the box2d to run 5-10x faster, simply because the math should be more complex, especially for the collision, in 3d. If not, evidently jbox is running very poorly. – bigcodeszzer Apr 03 '17 at 23:21
  • 1
    @bigcodeszzer Yes, the result is surprising for me at that time. But, please consider that you are also comparing performance of different language. C++ can go far faster that Java if it is well-coded and tested in some certain circumstance. This is one of the cases (game) that C++ is generally the winner. ...... To be fair, please test `C++ Box2D` vs `C++ Bullet`. (I have never tested it.) – javaLover Apr 04 '17 at 02:03
  • There technology you used are so vastly different, it can be used to compare. This is an invalid test. – Richard Lalancette Nov 27 '21 at 01:13