Annulus – Developer Diary – Week 3 & 4

A brief summary of the progress over the last couple of weeks:

  • Particles don’t have a fixed acceleration anymore, they respond to forces acting on them due to external factors which are updated each frame.
  • Implemented force generators for particles. Force generators may apply forces to particles registered to them each frame.
  • Added force generators for gravity, springs, anchored springs and bungees.
  • Implemented interface to demonstrate the force generators using SFML-2.4.2 in a Testbed project.
  • Visualized the interaction of particles in case of all the above force generators in the Testbed project.


Force Generators

Unlike in previous iteration, each particle now estimates its acceleration based on the forces accumulated in the integration step (using D’Alembert’s Principle). At the end of the integration step the accumulator is cleared. See code for Particle class. Thus, at the end of each integration step there is no force acting on the particle and all the continuously applied forces (such as gravity) need to be reapplied each frame.

Force generators are an automated mechanism programmed to apply forces over an extended period of time to particles. Moreover, they apply forces to the particles registered to them based on specific logic which can be programmed for each specialized force generator. I have implemented force generators for gravity, basic spring forces, anchored springs and bungees. Similarly, force generators for drag forces, buoyancy and harmonic motion can be implemented.

Each of these specialized force generators can be constructed by the user of the engine and they will automatically register to a static manager contained in the ParticleForceGenerator class. When the World calls the UpdateForces method contained in the static manager, the static manager iterates over the list of force generators contained in it and calls the UpdateForce method on each particle associated with each and every one of them.


Spring-Like Forces

Springs and particles can produce a range of effects such as ropes, water ripples, bridges, etc. Rather, in nature almost everything acts as springs. Collisions between solids are supposed to compress them and act as they act as if they are extremely stiff springs which try to push away each other. This approach to modeling collisions is called the penalty method.

However, if we model everything as springs, the interactions would look extremely spongy for low value of spring constants. At the same time, if we try to implement collision between solids with high spring constants, they spring constants would be really high. This is not feasible since for high spring constants, the forces acting on the particles would be enormous enough to create ever increasing oscillations which would end up sending the particles to infinity. This would also be affected by the frame rate. The worse the frame rate, the worse the oscillations would be.


Visualizing In Testbed Project

Any demo can be created by extending the Demo class in the Testbed project. The user can override the initialize, update and draw methods in the derived class and use it in the main program for demoing. Beware, the version of SFML used in the Testbed project only supports x86 platform.

Apart from this interface to demo different features of the engine, I have implemented three demos which are as follows:

  • The ParticleSpringDemo demonstrates forces acting between two particles connected by a spring.
  • The ParticleAnchoredSpringDemo demonstrates a particle anchored by a spring to the center of the screen and being influenced by gravity at the same time.
  • The ParticleBungeeDemo shows a particle connect to another through a bungee while only one of them is being influenced by gravity.

Annulus – Developer Diary – Week 2

Before talking about my progress in depth, I would summarize everything I did in this week below:

  • Understood what are various approaches towards implementing a physics engine.
  • Reviewed concepts of 3D math and calculus which will be required throughout the development of this engine.
  • Reviewed concepts of physics such as laws of motion which would be required to implement physics for point masses.
  • Implemented physics for point masses (particles), using Newton-Euler integration method and laws of motion.
  • Tested the damping of the motion of particles and their behavior under uniform acceleration by logging their state on the console.

The first thing to consider while making a physics engine is how to approach it and what assumptions to operate under. The first choice is regarding how to treat objects. Whether it should treat objects as a whole rigid body or as a collection of point masses (a mass aggregate engine). Developing a mass aggregate engine has the advantage of not requiring to take care of rotations, for this reason, I will start with implementing a mass aggregate system which I would be extended into a rigid body system. The second thing to consider is how to handle contact resolution, either use an iterative approach to resolve contacts without accounting for their collective effect or use a Jacobian-based approach to resolve their collective influence. The second approach is computationally expensive and might not even succeed in all the cases, for the simplicity and speed of the first approach, I will be using it instead of this Jacobian-based approach. The third and last consideration is regarding whether to use forces or impulses to resolve contacts. Some engines use forces to resolve for contacts while using impulses for collisions. I will be approaching this engine by implementing both collisions and contacts as impulses since the math for impulses is easier than the math for handling forces. Also, this impulse-based approach is suitable in terms of flexibility and can be used as foundation for experimenting with other approaches (Source).


Particle Physics

In a particle (point mass) system, each particle must have a position, velocity and acceleration which we will keep a track of. Refer to Particle.h inside the source code at the end of this blog post. Apart from the member variables mentioned above, each particle has a damping factor and a inverse of mass stored in it.

The damping factor is an alternate to drag in motion of any particle. This factor to the power of time passed since last update is multiplied by the velocity at the end of each velocity calculation in the integrator. Refer to the Integrate method in Particle.cpp. As in the equation, if the damping factor is 1, it means there will be no damping, and as per Newton’s first law, if there were no force acting on a particle which was in a state of motion, because of no damping, it will remain in the state of motion with the same velocity. Similarly, if the damping factor is 0, a particle will stop as soon as there is no force acting on it.

Each particle / point mass has a mass associated with it. However, we are storing the inverse of mass for several reasons. Firstly, all the equations we use, such as the second law of motion to integrate, employ inverse of mass, thus making our calculations faster. Secondly, practically there is implication of using infinite mass, i.e. something with so much mass that no force could possibly move it, if we use inverse of mass, then the expression evaluates to 0 and satisfies the second law of motion. Also, if m = 0, then this expression cannot be evaluated, this is sensible as well since there cannot be anything with practically no mass. If m = 0, then any force would make the acceleration infinite and this isn’t possible. Thus, to account for both calculation speed and theoretical logic, we store the inverse of mass inside Particle class, while making accessors and mutators for manipulating its value.

Lastly, lets discuss the integrator for which estimates the velocity and position for each particle given their uniform acceleration. As mentioned earlier, the method for integrator can be found in Particle.cpp.


Using integration on the expression for acceleration as per the second law, the position should be given by the formula in our integrator:

mPosition += mVelocity * deltaTime + mAcceleartion * deltaTime * deltaTime * 0.5;

However, since deltaTime, i.e. the time since last update is very small. Thus square of deltaTime is almost 0. For this reason, we can simply the equation as:

mPosition += mVelocity * deltaTime; (Used in the integrator code)


Also, by using the integration on second law for updating velocity, we have the formula,

ṗ’ = ṗ + at;

where, p is position, ṗ is velocity (dp / dt), a is acceleration and t is the amount of time passed.

We can update the equation above with damping factor as follows:

ṗ’ = ṗd + at;

However, the equation above is affected by the frame rate, thus we need to make the damping time dependent, we can further modift the equation as follows:

ṗ’ = ṗdt + at; (Used in the integrator code)


Engine Progress

  • Added Particle class with all the logic for particle physics explained above.
  • Updated World class to add support for creation Particles. It also manages the memory for the particles added into the world.
  • Added Body and Shape classes which will be used in the future when working on rigid bodies.




Source Code

Annulus – Developer Diary – Week 1

Hello World

Annulus is a personal project I started working on in this week. As a game programming student at FIEA, UCF, it is going to be the project which I will be working on through the following 8 weeks as a part of the curriculum. I will be posting updated weekly on my website and its source code is available on my GitHub.

I have always been curious about game physics and after working on a game engine in the previous semester, I knew that I wanted to attempt to work on a physics engine as since I wanted to learn more about software/engine architecture apart from programming physics. Annulus is going to be my attempt at a platform agnostic 2D physics engine written in C++!

Specifications / Objective

The specifications of the physics engine I am attempting to make are as follows:

  • A 2-D physics engine supporting rigid body dynamics.
  • Support for bodies having material properties including density, restitution and friction.
  • Support for discrete collision detection.
  • Collisions between convex polygons using Separating Axis Theorem (SAT).
  • Support for constraints, and as a stretch goal, support for handling systems of constraints.

I will also visualize the collision system in a Testbed project using SFML, a cross platform software development API.

Progress Report

For the first week, my objective was to conduct as much physics related research as possible. Decide on which algorithms I will be using and what resources I will be using as a reference. Decide an API for visualizing the project and setting it up and get the game loop running.

I was able to achieve most of the above except for some concepts of physics. I still have to read more theory on constraints and Gilbert-Johnson-Keerthi algorithm for collision detection. However, as mentioned earlier, I have concluded that I will be using SFML for visualizing the project and set up the game loop in Visual Studio 2015.

I will be using Erin Catto’s Box2D as my reference physics engine along with his material provided through GDC archives and tutorials. I have made a pass at understanding the architecture of Box2D and referred to other physics based projects as well.

Engine Progress

  • Testbed Project
    • Set up SFML.
    • Implemented the game loop.
    • Tested the update call to for physics engine.
  • Annulus (Static Library Project)
    • World Class – A class which will manage all physics entities, their allocation and releasing of resources. The user will call methods on the world object in their game loop.
    • Settings Class – Defines the settings with which define the behavior of a world, such as the gravity for the world.
    • GameClock and GameTime Class – Classes which use the chorno time library of C++ to encapsulate objects useful for maintaining game clock.
    • Integrated GLM Math library.

Handling Input From Perception Neuron

Perception Neuron is a MOCAP (Motion Capture) hardware which uses 32 little sensors called neurons. I worked on a project in a team of 6, along with another programmer to make a game using the Neuron in its single arm configuration using only 9 neurons. Check out the demo video of the game below.

Handling the input from the neuron is a simple task for both Unreal and Unity. The plugins provided by the Neuron team for both the engines are easy to understand and use. However, the issue a developer might face while developing for the neuron is accuracy of the hardware itself.

Some developers, including me experienced slight issues due to drift in the position and a decline in accuracy due to rapid movements. If a player would perform a certain action repeatedly, the neuron might behave inappropriately after some time. However, calibrating the device again solves the problem. The only issue is that you don’t want a player to have to stop playing just so that they could recalibrate their neuron.

The way I approached to this issue was that I decided to rely on input from the neurons that behave more accurately. For instance, the neurons over the thumb or the little finger seemed to lose accuracy or behave weird even after calibration sometimes.

I logged the rotations of different bones on the index, middle and ring fingers to see how they vary as the player closes and opens his hand. Using the bones that seemed most appropriate to get data on rotation of the fingers, I toggled booleans which represent whether each of these fingers are closed or open. It would be a good idea to have a margin for the rotation thresholds since the closing of hands seems to get worse over time. So the hand won’t close properly with a longer period of time of use without calibration.

Using the input from these three fingers, I toggled a boolean representing whether the hand is closed. If any two of the three fingers are closed, then this boolean is set. After testing for a while, it seemed to be a good approach to handle the player input since we could have multiple playthroughs without requiring to calibrate the hardware.

Contact me here if would like to know more about this project.

Inventing A Game Mechanic Using Augmented Reality


Afterlife is a project I really enjoyed working on in my fall semester at FIEA, UCF. It is a 2.5D platformer for Android in which a ghost is trying to reach the grave it belongs to. The player has to try to reach the grave before the ghost fades out of existence as in the picture below. To survive the player will have to collect the supernatural crytals in his path which replenish the timer for the ghost’s existence.


However, the above is just the gameplay which provides the player with clarity regarding the game’s objective. In addition to this, augmented reality adds more complexity and possibilities using the smartphone’s camera. The camera on the phone can be used to generate platforms in the game by pointing it to specific images (using Vuforia plugin for Unity). However, as soon as the image is moved out of the camera’s view, the platform would disappear.

The images which may be used for generating platforms in game have been pasted over the six sides of a physical cube which would be held by another person for helping the player as a companion. This creates a whole new game mechanic since the player will have to coordinate their jumping with their companion’s action of rotating the cube. Moreover, the levels have been designed such that the cube would have to be rotated through the jump in order to switch between platforms.

Also, the platforms generated by different faces of the cube give rise to multiple paths. Thus, inducing curiosity in the player to replay a level. They make the player want to look for alternate paths and know what else is present in a level. After all there is an Easter egg to find!

Check out a demo video of this project on my YouTube channel. Contact me here to know more about this project.