---
After watching a Sebastian Lague video on ray tracing
and messing around with shaders on shadertoy.com I found myself incredibly excited for
the computer graphics class I was about to take. The class itself was an excellent introduction into computer graphics
and our lectures were very hands on which was great! We began learning how to draw shapes onto the screen, then how to change their position
and color using shaders, eventually we were able to create meshes for spheres, pyramids, and squares.
I was having a blast with the control I had when using Java and GLSL to create things, so for our final two projects I decided to
make a physics simulation and then build off of that to make a FPS-like (First-Person Shooter). The original
physics simulation implemented rigidbodies, adding forces, friction, and bouncing. This was a blast to play
around with. Making an object have no gravity or friction, and having it bounce around at mach 10 accounted for a lot of my development time.
Demonstration of the physics
Although it's not shown in the video I started messing around with moving the camera and implemented camera shake into the simulation. This isn't used later, but my understanding of how the camera was able to move began here. Just before we were assigned our final project for the class I saw a video of someone that created a very basic FPS using only shaders. That video influenced the functionality I wanted to add into my final project. Building off of the physics simulation was easy because of the way I structured the classes around a component system much like in the Unity Engine. The big changes I implemented during this were object collisions, camera movement and rotations, and dynamic object creation (previously the program required objects to be constant in the scene).
The collisions were simple enough, I never had enough objects in the scene to notice the performance drop of checking a simple signed distance function for each pair of objects. Creating and removing objects was as easy as reserving memory for more objects than I'd have and keeping track of the free locations in that memory. The most challenging part for me was figuring out the camera rotations. I wanted to allow the player to look up, down, left, and right and individually they were easy to implement. The challenge came when I wanted to rotate left or right after changing the vertical orientation of the camera. As seen in the image below if the player looks up (rotate around the Z axis) the X and Y axes are different and rotating around either of them would result in a different orientation than expected.
What the XYZ axes looks like before and after rotating around the Z axis
After playing around with the matrix math I was using for the camera I took a step back and separated the axes. I used one matrix to handle horizontal rotations and a second to handle the vertical. Applying both was as easy as multiplying the horizontal by the vertical (it had to be this order because horizontal rotations don't change the vertical axis).
Demonstration of the FPS