Project Title: RigidBody Simulation
Development: C++ / OpenGL
My Role: Physics Programmer
This simulation was definitely a challenge from the start, and will require additional improvements to continue building upon the basic RigidBody system. This project involved learning about the basic theory behind RigidBody interactions, understanding the necessity for long-term implementations of broad-phased collision detection, as well as different methods for quickly providing narrow-phased collision detection. Furthermore, there was a lot of Matrix / Quaternion math to parse, primarily relating to the contact generation and resolution procedures.
Likely the easiest to implement, RigidBodies are able to readily collide with the ground. This initial process allowed for a testing area following the process of implementing the RigidContacts, Intersection Tests, and Collision Detection functions. Each RigidBody has a trait, determining which type of BoundingCollision should be accessed during collision detection. While in previous implementations the ground was represented by a simple Y coordinate, within this simulation it is possible to include defined planes, as well as half-space collisions. This allows for objects to collide with walls from one side, or detect any collision when beyond the plane.
Due to the transition from implementation to testing, the ground collision provided a means to eventually debug and resolve all related issues when utilizing Spheres and Boxes. Most of these issues related to subtle adjustments required to fix penetration, include the duration of the frame, and properly apply certain Matrices. However, a larger issue arose with the Matrix class that involved swapping it for an alternative to focus on the Physics Simulation.
Initially, I had implemented an NxN Matrix structure, which meant that the user could technically create a dynamically sized Matrix. While this was a ambitious maneuver, and although most of the functionality to manage the Tranpose, Inverse, and Determinant calls worked, there were still bugs relating to the passing of Matrix objects and the internal allocation of the memory array. As a result, values were being loss through various operations, ultimately hindering progress when testing the actual Physics simulation. Credit goes to Chris McCooey for providing an alternative set of Matrix33f and Matrix44f to act as placeholders to continue working with the simulation, but eventually it will be worthwhile to implement the previous Matrix structure and resolve the memory corruption issues.
Once the process of dynamically registering all RigidBodies with each other for collision detection was finalized, the majority of the initial collisions panned out as expected. A few bugs with Box collisions arose, mostly due to the fact that certain variables were not applied properly during the contact normal creation. Furthermore, the process of detecting the Box's collision with the ground took a bit due to the fact that the graphical rendering and collision box were not actually aligned, and required an offset and multiplication of the collision box's half size to fix. However, once these small issues were cleared, there were no issues with Box-Sphere collisions.
The two major obstacles during this simulation involved the Matrix errors, along with the lack of rotation following the conclusion of the project. The actual rotation velocity is calculated, but ultimately untested within the scope of the project. This would further involve taking another iteration to graphically represent the orientation of objects, and then continue testing the actual result of rotational force. Also, the Matrix class can eventually be re-added, and ideally there may be a focus on fixing the allocation issues when constructing / deconstructing the object during Inverse / Transpose operations.