Physics Framework

Created as part of my Further Games and Graphics Concepts module in semester 2 of my second year. The task was to create a series of physics simulations that would model forces and collisions using the DirectX API. Appropriate system architecture and design patterns were to be considered to ensure a robust and manageable codebase. The simulations were required to demonstrate a mass aggregate system, collision detection and response, and rigid body rotations. Additional implementations to consider would have been a managed particle system, terrain generation or further adapting the rigid body system.

What Did I Learn?

For system architecture, I had learned of the component system design pattern. This allowed for game objects to call functions on themselves to set parameters relating to the component that the function was accessed through. Regarding the below code snippet, each cube in the array could access a given component, i.e. their transform using GetTransform(), and set appropriate values to update the cube's position within the world. Consequently, this design pattern allowed for a more intuitive framework.

 // use component system to modify game object parameters
 for ( uint32_t i = 0; i < NUMBER_OF_CUBES; i++ )
 {
     cubes[i] = std::make_unique( "Cube " + std::to_string( i + 1 ), false );
     cubes[i]->GetParticleModel()->SetMass( 20.0f );
     cubes[i]->GetTransform()->SetScale( 0.5f, 0.5f, 0.5f );
     cubes[i]->GetTransform()->SetInitialPosition( -4.0f + ( i * 2.0f ), 0.5f, 10.0f );
     cubes[i]->GetAppearance()->SetGeometryData( cubeGeometry );
     cubes[i]->GetAppearance()->SetMaterial( shinyMaterial );
 }

Utilizing the component and level system, I was then able to implement the main physics simulations: a mass aggregate system, collision detection and response, and rigid body rotations. The mass aggregate system required a force model which would include a range of relevant forces that would act on a given game object. Here I implemented forces for moving an object: velocity, acceleration, and gravity. This system was further adapted to account for additional forces: friction, laminar and turbulent drag, and thrust.

Collision detection and response was also implemented alongside the mass aggregate system. Upon collision, the system considered the force at which each game object collided, calculated a resolution force and then applied it to both. The result was a collision system that communicates with the mass aggregate system to resolve collisions in real-time while accounting for an object's mass. This collision system works well with multiple objects, however, for even more realistic collisions, the rigid body system adapts this further, accurately simulating the collision between two cubes.

Rigid body simulations were also implemented in the physics framework. These are solid bodies of which have a deformation of zero and a centre of mass that can be chosen and will not change. I learned that to simulate angular rotations, first, the torque, the turning force, had to be calculated, and the inertia tensor computed. Angular acceleration and velocity could then be calculated and applied. After implementing the relevant formulae and performing more accurate collision tests, I was able to properly simulate rigid bodies.

Future Additions

In the future, I would like to further adapt the particle system that I implemented. Currently, it only simulates fire, and so I would like to simulate other particle types such as snow and rain etc. I would also improve the design architecture to allow for more particle systems to be easily incorporated and controlled. This would require a managed particle system as demonstrated by the below image. This would allow for better control and instantiations of new particle emitters in the scene.

An overview of the design architecture for implementing a managed particle system. (van der Burg J, 2000). View on gamasutra.
Further, I would also like to optimize collision checking by implementing spatial partitioning in the form of a quad-tree. This method would ensure that collision checks are only computed between game objects that are closest together, or that are most likely to collide with each other, thus reducing the overall computational cost of collision checking.


Spatial and logical arrangement of an example quad-tree. (Apple, 2021). View on Apple.
Following this, I would like to adapt the collision and rigid body systems to account for more complex models, so that I can create more interesting scenes, with the aim of incorporating this into a game engine in the future.

Feel free to drop a comment below.