Badass JavaScript

A showcase of awesome JavaScript that pushes the boundaries of what's possible on the web, by @devongovett.

CoffeePhysics: A Fast New Physics Engine Written in CoffeeScript

February 29th 2012

Justin Windle has just released a new physics engine called CoffeePhysics, which as it’s name states, is written in CoffeeScript.  It is quite lightweight (minified, it’s just 8KB), but also very powerful.

There are a number of demos that show the performance and features of the library, including attraction, collision, cloth simulation, a balloon of balls around your mouse, and a chain following the mouse.  I’m getting around 60 frames per second or more in most of the demos in Firefox and Chrome, which is pretty darn impressive.

The source code is very readable, as CoffeeScript often is, and seems very modular and well architected.  There are multiple renderers available as well, the most important of these being WebGL, but there is also a canvas 2d renderer as a fallback, and perhaps a DOM renderer in the works (for really old IE?).  It sounds like 3D support is in the works as well.  In the demos posted online, only the WebGL renderer is used, so make sure you check those out in Chrome or Firefox (it does not appear to work in Safari).  The demo source code is all in the repo, so make sure to check that out as well!

I reached out to Justin earlier this morning and asked a few quick questions.  Here are his responses:

Did you have any particular reason for building CoffeePhysics, or was it just for fun?

I was working on some visual demos of genetic algorithms for my presentation at FITC Amsterdam and found myself writing the same simple particle / spring physics over and over, so decided that abstracting it out to an engine would be a good idea. I’ve been keeping an eye on CoffeeScript for some time now and had actually started using it to build the slide engine for the presentation. It felt like a good fit for the physics engine, mainly because of the ease with which I could implement classes and inheritance; allowing me to give the engine a more formal structure which would come in handy when extending the core functionality though new integrators, renderers and particle behaviours.

I’ve wanted a simple physics engine for JavaScript for some time. With a basic point-mass and spring system, it’s possible to create a lot of different effects, all without the need for more complex, processor intensive features. I plan on extending the engine to 3D (it was designed with this in mind since all the math is done with vector operations and so swapping out the 2d vector class for a 3d one will be almost all that’s required at first). I’ll also work on performance (particularly in collision detection) and a more extensive library of particle behaviours, but the main philosophy was simplicity of use and a clean, intuitive API, so keeping it lean and nimble will remain the focus.

What was the most fun/challenging part of building the library or related demos?

Designing the structure of the engine was the most interesting challenge. I’d worked out most of the math required in previous experiments, so in this respect it was simply a matter of combining those techniques. The API and code structure on the other hand was something I wanted to focus on keeping clean, modular and easy to understand. CoffeeScript helped with this, since (much like writing Python) the syntax feels to me almost like writing pseudo-code - I can ‘sketch’ out the class structures, logic and interfaces and then very little is required after that to actually have working code.

How was your experience with performance? What challenges did you face in getting CoffeePhysics or its demos to run fast?

I released it perhaps too early - I wanted to demo it at FITC and so what’s out there now only amounts to the first draft. Therefore, performance hasn’t yet been a huge priority; instead as I mentioned I wanted to create a stable, easy to use and simple engine first then worry about optimisations later. Currently there are a number of issues across browsers and for practical purposes during the (very quick) first development cycle I’ve only been targeting and testing with Chrome.

The physics though is generally very fast to calculate, especially in JavaScript engines like V8. Rendering is always the significant bottleneck and so I quickly moved from canvas to a simple WebGL renderer (with a canvas fallback). This is why (in Chrome at least) the demos run at a solid 60fps. The engine is also a fixed time step engine, meaning that it’s accurate even if some frames are dropped, so unless there’s a huge lag (something I’m working to eradicate in some browsers) then the simulations will run smoothly and the interactions will feel responsive.

There is a lot of controversy around CoffeeScript in the JS community.  How was your experience with it?

I think that CoffeeScript does some important key things very well. Coding is fun and quick, which to me is very important. As I mentioned, easy classes with inheritance are great to have and the compiler is fast enough to make this intermediate step almost unnoticeable. The aspect I like the most though, is the ability to dive in and start writing logic without having to worry about some of those little JavaScript quirks we all code around on a daily basis. The less time between thought and working code, the easier it is to be creative and expressive; something which to me programming is largely about.

I understand the reservations people have and I’ve certainly come across aspects of the language I would like to be different, but when you consider the time and effort that goes into making JavaScript behave sometimes, I’d happily trade that for ease and pleasure of use, in the right circumstances of course.

Anything else you think we should know?

CoffeePhysics is a personal project I decided to release somewhat prematurely and so is not yet in the state I want it to be in for version 1. That said, the whole point of opening it up to the community is to get early feedback and have help with tracking down issues, so I’m not worried about it being unfit for immediate use. I’m also keen to stress that it isn’t intended to be a full blown engine. I’ll be interested to see what I (and hopefully others) can eventually do with it, but my intention is to focus on doing a few basic things well, keeping it fun and easy to use and exchanging features for speed and usability.

Nice work, Justin! Now, go check it out on Github, and play with the demos!