Phys2D and JBox2D are 2D physics engines written in Java. Both are mainly intended to be used in games for increased realism. They simulate the physical interaction of geometric bodies like boxes, circles and simple polygons. Phys2D has been written by the author of the 2D games development library Slick. JBox2D is a Java-port of the C++ physics engine Box2D.

Since both offer very similar features, I took a closer look at them. Questions that interested me most were: How much performance do these physics engines cost? How do they compare to each other performance-wise? Which is easier to use?

Performance

Test World

In order to test the performance of both engines, I have created a small test framework. A model world containing static and dynamic bodies is used to measure the performance of each engine. The test world consists of a static U-shaped container with several ramps inside of it. This container uses six static bodies. Several rows of dynamic bodies are spawned over the container, so that they drop into it. The number of bodies to be spawned and the shape of bodies can be customised. As body-shape, boxes and circles can be chosen (see images below).

The test world with box-shaped bodies

The test world with circle-shaped bodies

Test Environment

Engine versions:

• Phys2D: 2008-04-06
• JBox2D: 2.0.1

Test system:

• OS: Windows XP SP3
• Java: JDK 1.6 Update 7
• CPU: AMD Athlon64 3700+ (2,21 Ghz, single-core)
• RAM: 2 GB

Tests were run as high priority processes. All other non-essential processes were stopped. The intention was to focus on the engines' simulations with as little outside influence as possible on a normal desktop computer.

Tests

The benchmark application runs a series of tests in the test world. Basically an increasing number of dynamic bodies is dropped into the world. Each consecutive test run starts with more bodies. In each test run the first 600 steps (i.e. as long the bodies are still falling and colliding) are simulated with each physics engine. A step is the execution of an engine's step()-method. The average of one step execution is calculated in milliseconds. Every test run is repeated 10 times to get more robust results. Drawing the current state (e.g. with OpenGL) was not part of the test.

The number of dynamic bodies ranges from 0 to 100. As I was also interested in how much the shape of bodies and the presence of joints affects the outcome, I ran four batches of tests. Two with box-shaped bodies (with and without joints) and two with circle-shaped bodies (with and with-out joints). Tests with joints had about one forth of all dynamic bodies connected to another body.

Configurable settings of both engines were set to comparable values where possible, e.g. 10 iterations and 1/60th of a second per step(). Other values were taken from the examples of the engine in question, e.g. collision space model.

Results

The following diagrams show the test results. The x-axis represents the number of dynamic bodies created in a test run and the y-axis represents the execution time in milliseconds of a single step.

JBox2D is faster across all tests. It is two to three times faster than Phys2D. Even at 100 dynamic bodies JBox2D still offers acceptable performance, compared to Phys2D.

However even Phys2D only requires about two milliseconds for 50 dynamic objects. Up to 30 dynamic bodies, Phys2D stays below or around the one millisecond mark.

The overall total performance impact seems to be rather small unless you use a high number of bodies. If you look at most 2D games I would say the number of dynamic bodies is somewhere between 1 to 50. At 30 to 60 frames per second, that makes the performance impact of a physics engine quite small. Of course it all depends on your CPU.

As can be expected, box shaped bodies are more computationally expensive than simple circles. It is interesting to see that the presence of joints has no detrimental effect on performance. On the contrary, the lack of joints slows both engines down a little bit. The effect is more visible with Phys2D than JBox2D.

Ease-of-Use

While writing the test application it became clear that JBox2D is a very direct port of a C++ library. JBox2D uses a few aspects that are not very Java-ish. It does not use setters and getters but instead provides direct access to public members of classes (e.g. position, angle). In JBox2D you do not create bodies and joints directly, but rather set up a shape or joint definition and ask the world to turn them into a body or joint. Due to the lack of setters you also sometimes have to trigger updates manually, e.g. setMassFromShapes(). When iterating over all bodies in a world, you request the first body and have to call next() on it to access the rest; until you hit null. There are some strange implicit settings, too. For example a zero-weight body is implicitely defined as a static body. Overall its design does not feel very intuitive.

Phys2D on the other hand has a very intuitive Java API. It sticks to familiar principles and does not have the above issues and thus integrates much more nicely into Java code, in my opinion. It was considerably easier to get to work and understand what was going on.

I did not take an in-depth look at all features supported by the two engines. What struck me most however, was that Phys2D offers direct support of polygon shapes. With JBox2D you have to manually create composite bodies, composed of multiple simple shapes. Also Phys2D's resting body and collision detection is more configurable than that of JBox2D.

On the other hand JBox2D offers continuous collision detection (CCD) for fast moving bodies. Normally both engines calculate discrete body positions depending on the time passed in one step. If a body is moving very fast it can pass through another body during a step. CCD is supposed to prevent this for bodies that are defined as bullets in JBox2D. You can also set bounds of the area to be simulated in JBox2D. This can potentially increase performance by ignoring off-screen bodies. In Phys2D you would have to manually do this by disabling bodies; which may be more flexible but requires extra work.

Conclusion

For games with a relatively small number of bodies and no simulated bullets, Phys2D would be my engine of choice. Its API makes it easier to use and it integrates better into Java code. Considering that games usually run somewhere around 30-60 frames per second, it does not really matter whether the physics engine takes half a millisecond or a full millisecond.

Games that use a high number of bodies are better off with JBox2D as it scales much better. On my computer, at around 100 bodies JBox2D still offers acceptable performance while Phys2D starts taking up too much time. JBox2D also has an advantage that it can enable continuous collision detection for bullets.

An engine with Phys2D's design and JBox2D's performance would be great.

Source Code and Jar

If you want to run the tests yourself, download the zip file below and run Phys2DvsJBox2D.jar. If you specify no parameters, the correct parameter usage will be printed to the console. There is a compiled .jar with all required libraries and batch files for Windows in the "bin" directory. See runTestSeries.bat for parameters used in the above tests. Java 5 or higher is required.

Classes de.ciardhubh.phys2dvsjbox2d.jbox2d.JBox2DDisplayTest and de.ciardhubh.phys2dvsjbox2d.phys2d.Phys2DDisplayTest are executable and can be run to display the test world using OpenGL for visualisation. If you want to compile and run the display tests yourself, you need the LWJGL libraries in the classpath. You can download the latest LWJGL version here. In order to run them, you also have to use the parameter -Djava.library.path=C:/lwjgl/native/win32 which should point to the native LWJGL libraries for your system (Windows in this example). The zip-file below comes with LWJGL libraries and batch files to run the display tests on Windows. See the "bin" directory.

Download the test source and .jar here.

Other Engines

There are several other physics engines available in Java. I did not take a closer look at them because they are mostly 3D engines. For reference they are still listed here:

• jME Physics - 3D physics engine interface of the Java Monkey Engine (jME), can use ODE, PhysX and others.
• JBullet - Java port of the 3D Bullet physics library.
• jinngine - A pure-Java 3D physics engine.
• JOODE - Java port of the 3D Open Dynamics Engine (ODE).
• JPhysX - Java wrapper for Nvidia's PhysX.
• Actionscript Physics Engine (APE) - 2D engine for Actionscript (Flash) that also has a Java port available.