Current state of the Elixir Rigid Physics library

After a few weeks of on-and-off work (maybe 2 weeks actual work punctuated by coder’s block and wonderful socializing here at RC), my timeline looks like this:

• Create stub physics engine server in Elixir as a GenServer(done)
• Create visualizer for engine state using Three.js and Phoenix Channels (done)
• Add first body type to physics engine: boxes! (done)
• Add framework for doing dynamics sans collisions in engine (in progress, more below)
• Add collision detection framework for finding contact manifolds
• Add collision restitution code
• Add friction
• Add joints and motors
• Add more types of bodies beyond boxes
• Figure out how to spread the simulation across multiple processes
• Figure out how to spread the simulation across multiple nodes

I’m currently kinda blargh on this, since it’s a long road with a lot of work and not a lot of suprises. That said, it’s definetely a bit outside of my comfort zone and has been helping me improve my Elixir understanding (more intuition about processes, more knowledge about debugging, more familiarity with Phoenix Channels) and definitely brushing up on my physics.

Introduction

I’m working at the Recurse Center on a 3D rigid-body game physics engine in Elixir.

What’s that mean?

• 3D is pretty self-explanatory.
• Rigid-body means that the objects being simulated don’t deform due to collisions, so more like steel beams and less like wobbly jellyfish.
• Game physics is meant to describe simulations that are both decent-enough in fidelity for humans to predict behavior of objects and low-enough in fidelity to run in real-time (say, 30-60Hz).
• Engine means it should be reusable across other projects and have a clean API.

I want to see what features APIs some various engines support, and go from there. The API’s I’m looking at are:

Yesterday I spent many, many hours fighting with getting projects setup with CI.

For the Elixir physics engine I’m breaking ground on, I need to setup my usual library infrastructure.

For me, I consider the “bare minimum” for developing a library for other people to be:

1. Master should pass tests at all times
2. 100% test coverage
3. 100% docs coverage of all APIs
4. Proper SemVer
5. Minimum external dependencies if at all possible–easier with mathy stuff

The first three are what cost me hours of my life yesterday.

After a lot of work today, I’ve gotten RSS feed generation implemented for my blog.

I then retooled a VPS I had lying around (apparently hoarding machines happens to my accounts as well as my apartment…) and threw on Ubuntu.

This was then setup to do basic file serving and most of the usual lockdown I do for my serves; a good test run, since I’ll be doing a workshop on accomplishing exactly this while at Recurse Center. :)

This is a demo for my friend Aaron showing some blog image dithering.

A beautiful parrot: