Planck.js developer here! I have posted this to reddit before, so I'm just going to include it here too:<p>I have ported/rewritten Box2D physics engine to JavaScript, for cross-platform HTML5 game development. Planck.js includes entire Box2D algorithms, a simple HTML5 Testbed, more than 50 examples and some new game prototypes. The project is pre-released and there may still be minor issues, which I'm working to fix. So far I have spent more than 400 hours for developing this project and it consists of around 20k lines of code.<p><a href="https://github.com/shakiba/planck.js" rel="nofollow">https://github.com/shakiba/planck.js</a><p>My main motivations for working on this project are:<p>- Taking advantage of Box2D's efforts, achievements and community knowledge<p>- Developing readable and maintainable JavaScript code<p>- Optimizing the library for web and mobile platforms<p>- Providing a JavaScrip-friendly API<p>Your feedback is highly appreciated, and I hope you use Planck.js to make some awesome games soon!
It baffles me that all those JS physics library never provide proper docs or even an API reference and always link to the C++ Box2D manual as if it was an acceptable alternative. Always have to guess what the JS equivalent is but even then you're in for a surprise: <a href="https://github.com/shakiba/planck.js/blob/master/CHANGES.md" rel="nofollow">https://github.com/shakiba/planck.js/blob/master/CHANGES.md</a>
You reminded me, that I made a Javascript game with Box2D five years ago: <a href="http://www.loudrider.com/" rel="nofollow">http://www.loudrider.com/</a><p>I was using Box2DWeb <a href="https://github.com/hecht-software/box2dweb" rel="nofollow">https://github.com/hecht-software/box2dweb</a> . It could be good to mention other javascript versions of Box2D and say, what are the differences between them and your library.
I love that you kept the tried and true Box2D API as that'll make porting what I'm working on much easier. I've been using the emscripten version [1] but the automatic port from C++ makes the JS API quite painful at times, especially with the manual memory management that's required to prevent leaks. Thanks for doing this!<p>[1]: <a href="https://github.com/kripken/box2d.js" rel="nofollow">https://github.com/kripken/box2d.js</a>
In most of the demos, you can grab the objects and drag them around. In other demos (like 8 ball) you can 'shoot' them.<p>I wasn't expecting it to be so smooth and precise... this is really great work. It makes me realize why I got a C in physics, because I could never make this!
This seems like really great work.<p>I could have sworn this was done already but looking at all the search results that came up the alternatives seem awful at first glance. At the very least this project is better at marketing.<p>As an aside, does it bother anyone else that the 8-ball demo has two extra pockets in the table?
Off topic:<p>I'm interested in a physics library based on waveform collapse. It seems like performance would be so much better. A body could arc through empty space, without writing any new data to the GPU, just the clock changing, until an "observation" event where you wanted to check whether it interacted with anything, at which point you collapse some number of waveforms into particles, do rigid body math, and then generate new wave equations for the subsequent timeline. There would be no centralized "tick" just a tree of nested timelines forking whenever your code decided to do an observation. When rendering you'd just render all the waves, which means you can do arbitrary precision. You could do 90hz rendering of the waves for head position, while only collapsing particles every half second or so. Do that at multiple scales and you have a physics system with arbitrary fidelity traded off for performance. You can have different ticks at different scales (waves within waves). The properties of a given surface would just be the sum of maybe 3-4 waves at different levels of detail. You could collapse these independently depending on how much compute you wanted to devote at different levels. I think this would pair well with an SDF-based renderer, which lets you have screen-aligned surfaces that kind of act like particles already.<p>It would lead to bizarre physics bugs, but I suspect they would be very interesting and could lead to interesting gameplay. Perhaps they might even help us learn things about how our own universe works.
Cool! Is there a big advantage to a manual rewrite vs emscripten? With emscripten folding in updates from Box2D 'native' would be easier, it seems.
great, included in <a href="http://www.tapirgames.com/blog/open-source-physics-engines" rel="nofollow">http://www.tapirgames.com/blog/open-source-physics-engines</a>
Great work! This is really impressive stuff, and it's applaudable that you saw this project through to the very end!<p>I'm actually seeing some hitching in the car demo on my reasonably fast dev machine, particularly when I'm interacting with the bridge (computing contact forces of a bunch of bodies connected with joints is a lot of work):
<a href="http://piqnt.com/planck.js/Car" rel="nofollow">http://piqnt.com/planck.js/Car</a><p>Have you looked at perf yet? How does the performance of your rewrite planck.js compare to a compiled emscripten version?<p>Would you ever consider using something like ASM.js or WebAssembly? Physics libraries are definitely one of those performance-critical applications where this kind of stuff actually matters a whole lot.
I made a graphics library IvanK.js and made a Box2D demo for it (using Box2DWeb). It ran smooth even back in 2012 :) <a href="http://lib.ivank.net/?p=demos&d=box2D" rel="nofollow">http://lib.ivank.net/?p=demos&d=box2D</a>
I've messed around with various incarnations of Box2D, including at least one other Javascript port. How does this one compare performance-wise? Does doing a full rewrite perform better than the automatically generated Javascript of the other ports?
I'm currently using Box2D intensively in one of my games: www.braains.io
What would be the easiest way for me to replace the existing Box2D implementation with Planck.js?
What I remember from Box2D is that the simulation wasn't deterministic but rather dependent on frame rate for example. Is it the same case for this?