29 2 / 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.
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.
There is a lot of controversy around CoffeeScript in the JS community. How was your experience with it?
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.