Blog about (Web-) Programming, Graphics and Games.


bullet.js - Javascript Physics Engine

I finished porting parts of the JBullet and Vecmath library from Java to Javascript. As the result there is another 3D Physics Engine for Javascript named bullet.js (because its based on the Bullet Physics Engine). Its size is about 200kB. Here is a canvas-demo, showing the engine in action. The demo consists of the same animation with 20 boxes as the java physics demo, I posted before. Thus one can compare the different performances. On my computer I get following frames per second:
  • Java: 300 Fps
  • Javascript Chrome: 45 Fps
  • Javascript Firefox 4b1: 10 Fps
  • Javascript Firefox 3.6: 3 Fps
This shows 2 points. Point 1: Google Javascript is quite performant, Mozilla must still improve things. Point 2: Although Javascript execution speed has great improved in the last years, there is still a big performance gap wrt. Java. Maybe javascript will never run as fast as java, because of its dynamic nature/typing? Time will tell. :)
Anyways, currently there is a canvas demo, but the real purpose of a 3d javascript physics engine would be WebGl. So there will be WebGL demos soon on this blog.
A issue exists with the javascript port: the boxes in the demo sometimes show strange behavior, they bump from the ground and fly through the air.. In the java demo they dont do that, so there must be a bug in the Javascript code. If there is someone who actually understands how the bullet engine works (I dont, I just ported it :) it would be nice, if I get help to find the bug.


Cedric Vivier hat gesagt…

Nice demo :)

However I don't think the FPS given are benchmark-worthy when it comes to measure Javascript execution, when comparing Chrome and Mozilla here I assume most of the difference is not because of V8 versus TraceMonkey but due to the very different canvas implementations (Chrome has a scan-line renderer which is very efficient for that kind of visualization).

Any chance to see a new 'headless' benchmark? :D

pl4n3 hat gesagt…

Interesting, thanks for the comment! I'm thinking about creating a headless benchmark, or one with another 'head', webgl :) If canvas is the main bottleneck here, then that should produce other results.

Anonym hat gesagt…

There must be a "resting" state for objects, when their movement iteration is lower than a certain threshold. This will solve the bouning issue and also save CPU. You will also have to implement a "wake-up" mechanism of course...
- Michael

pl4n3 hat gesagt…

Yes, resting states exist in the engine.