Lyra Edwards

One of the major points of success in the project was the resistance force implementation: gravity, drag, friction etc. were all made with realism in mind, acting upon each object in ways dependent on the object's properties, which coulf be manually set. These included density, volume, and how rough the object was. This allowed objects to behave as expected when taken in isolation, a few issues arose when programming these, an interestign one was the need for a floor value for velocity, not having one meant that objects would infinitely move, just at incredibly low velocities. Another interesting issue was caused by the nature of debugging physics on an object with various forces acting, the introduction of new forces could cause issues that were hard to trace. To combat this, I disabled each force seperately, manually seeing which pairs of forces caused unexpected behaviours, then tracing through code to find any errors, be they in terms of logic or syntax.

Another point of interest was the collision system, objects were made more modular using rigid bodies, static meshes, and other components as you would expect from a modern game engine. This again made debugging easier, but also made the program far more legible and logical. Colliders were added for each objec type, those being planes, boxes, spheres, and then the more advanced oriented boxes and custom meshes. The simple collisions were very simple, except when finding collsions between different types - spheres and boxes required finding the closest point to a sphere on the edge of a box, and determining if the distance to the centre of the sphere was less than the radius. If so, it was colliding, and forces would be appropriately applied. The main difficulty came from oriented bounding boxes, or OBBs. Finding a way to handle collisions between cubes at different angles was tricky, since typical AABB collision fails. Instead, an algorithm called Separating Axis Theorem (SAT). SAT uses quaternions to take every possible axis two objects can overlap on, including the normal vectors (or local X, Y, Z) of each object, and the cross products of each of the objects edge pairs. This provides a total of 15 axes that required testing, and if even one was not overlapping, the objects were not colliding. This took many attempts, and proved difficult to debug due to the complex maths at work, however it proved very accurate. I could then create the code for collision detection between OBBs and other shapes, such as planes or spheres, which came down to a simplified SAT algorithm - planes only care about one axis, so finding the closest point on an OBB to that plane was not difficult, and for spheres, it again came down to finding the closest point on the OBB to the centre of the sphere, then determining distance against the radius.

Once I had this, a glaring inaccuracy with the project was that there was no rotational velocity applied when two objects collide. To remedy this, I had to figure out how to determine the vector on which the force acted, and how that force should be resolved. Interestingly, this became an issue when acting on OBBs, since the other AABBs could not rotate without their collision being broken. A potential future improvement could be to have cubes use OBBs and AABBs dependent on if they are axis aligned or not, but for the purpose of the assessment, they were left separate. I was also ver satisfied with my implementation of an octree, using a predefined depth, the space could be divided into 8 segments, then those again divided for each further depth, this allowed more efficient collision detection, as objects in different regions do not need to be checked against one another, it also leaves really adaptable options for future development, as a larger world could be loaded and unloaded dependent on the player position based on these sections, preventing the need to load a whole level at one time.

I am overall very pleased with the outcome of the assessment, I achieved what I set out to do and feel I have greatly deepened my understanding of physics programming, but also how advanced maths concepts can be used within games programming for simplicity and efficiency. I would like to further expand my knowledge by exploring cloth physics and vehicle physics, which I plan on coding in future since I have found this very enjoyable, and would enjoy getting to program more sophisticated physics systems within industry.

Overall Grade: 1st