Project Overview – Physics Engine


Risk Europe had been a lot of fun to make but I didn’t get much of a chance to do some real game engineering.  Working on a Physics Engine in OpenGL would hit three major areas that I wanted to sharpen my skills in: C++, game physics, and graphics programming.  Looking back; however, I didn’t end up learning much about the fundamentals of graphics programming.  I just learned a tiny bit about OpenGL and called a couple GLUT functions to generate geometry.

My supervisor at Treyarch last year had recommended Ian Millington’s Game Physics book to me and I followed along with it over the course of the project.  I took Millington’s source code directly for his math functions and many of my objects grew to resemble his, so it’s safer to say that I learned how to create a Physics Engine more so than I wrote one by myself.


After setting up OpenGL and getting my stylish grey room on screen I set out to create a particle system.  In this case that pretty much just meant giving a lifetime to an object with a velocity and not displaying it after it “dies”.  I didn’t get into any interesting concepts with the particles.  I imagine that the memory management and rendering of a real particle system would be really cool to dive into but I wanted to focus on physics and move on to rigid bodies.

Here are some boring square particles:

And some spherical “firework” particles that generate five new particles when they die:

Rigid Bodies

After particles I moved onto rigid body physics.  I can’t think of many things to talk about building the engine, the main interesting design decision that Millington went with (and I followed) was iterative collision resolution.  The problem this approach gave me was that objects would noticeably judder when resting on the ground and more so when resting on top of one another.  I spent a long time trying to reduce the judder (putting bodies to sleep after a time, adding friction to slowly release energy from collisions, changing how bouncy the collisions were, etc..) but never fully solved it.  Other than that here are some GIFs of the engine in action (the only two objects other than planes that I support right now are spheres and cubes).

No gravity:

Box into spheres (you can see the boxes juddering towards the end):

Spheres sliding down an invisible angled plane into more spheres and some boxes:


Oculus Rift Integration

For the most part switching over from GLUT to draw my boxes and spheres to the methods Oculus was using for their SDK wasn’t as bad as I thought.  I didn’t form a complete understanding of everything they were doing on their rendering side; I just found a way to add new arbitrarily sized boxes to be rendered and how to use one of the textures they had already initialized.  From there (and after going back and abstracting my engine a bit more from the rendering side) I simply initialized some rigid bodies and included an update step that synchronized the position and orientation of the objects the Oculus SDK was rendering and it worked.  It was a much smoother process than I thought and gave me a pretty big sense of satisfaction that I could then take this engine and apply it to a multitude of other rendering techniques.  Here are some GIFs of the engine in action.

Without gravity enabled:

And with gravity enabled:


And that’s it for the physics engine overview!  You can check out the source code here.