Introduction

One of the weird rabbitholes I fell into while working on the GJK implementation was figuring out how to find the nearest point on a tetrahedron to a query point. This also relates tightly to the idea of finding which Voronoi region a given point corresponds to–in fact, I elected to update my projection routine to also report which region a given point fell into.

The implementation of the thing itself is a bit annoying, since we have to calculate a bunch of barycoords and then figure out which domain (in increasing dimensionality) we may be falling into, but testing them is even more frought.

Current State of the Elixir Rigid Physics Library

• 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 (done)
• Add collision detection framework for finding contact manifolds (abandoned)
• Add collision restitution code
• Add friction
• Add joints and motors
• Add more types of bodies beyond boxes (we’re going full convex hull, God help me)
• Figure out how to spread the simulation across multiple processes
• Figure out how to spread the simulation across multiple nodes

Changing course

So, I kinda need a break on this. It’s been about ten weeks of banging on it, and the last few haven’t been nearly productive enough–my experience is telling me I need to either switch sub-tasks, or pull the ripcord entirely and switch to something else while I wrap up here at RC.

Introduction

Yesterday, my colleague Anna here at RC got to talking about her game, and being a bit stuck on how to get Javascript to do what she wanted.

The game itself sounds to me like it is a sort of visual novel, which can be summarized as:

• There is a current game state, being a current node in the story and an inventory.
• The current game state is projected into a form that users see.
• Users can take actions from story nodes to move to other story nodes or re-enter the same story node.
• Actions are made available based on a predicate run against the game state.
• Actions may modify game state in various ways, e.g. adding or removing inventory items.

This is a super simple and rough thing, but we can implement without too much trouble and get something worth hacking on.

Current State of the Elixir Rigid Physics Library

• 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 (done)
• Add collision detection framework for finding contact manifolds (in progress, see below)
• Add collision restitution code
• Add friction
• Add joints and motors
• Add more types of bodies beyond boxes (we’re going full convex hull, God help me)
• Figure out how to spread the simulation across multiple processes
• Figure out how to spread the simulation across multiple nodes

Since last update

I fixed a bunch of little annoying things that made working with (and debugging) the engine unpleasant.

A sketch of the problems

The current situation harms workers, it harms consumers and society, and somewhat unintuitively it hurts most employers themselves.

Problems for the worker

Developers unlock or maintain vast economies of scale for companies, allowing profits at scales almost unseen in the history of mankind. At the same time, it seems that developers are increasingly cut off from the fruits of their labor and treated more poorly than they deserve.

This is a local image!

Current State of the Elixir Rigid Physics Library

• 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 (done)
• 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

In the process of working through (and doing so. much. reading.) the issues with integrating angular velocity on a quaternion last week, I cut a new release (2.0.0) of Graphmath. Turns out we’d been doing quaternions basically entirely incorrectly, so this was a chance to fix that. Things I fixed:

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.