Assignment 5 Download!
Arrow Keys move the box forward, backward, left, and right.
WASD Move the camera forward, backward, left, and right.
Space moves camera up, and X moves camera down.
So in this assignment, we moved the rectangle into the third dimension, making it a cube. Starting off, it was pretty simple: just add the z component anywhere you dealt with coordinates. After that, you need to adjust the mesh for the cube to have six sides. I’ve worked on graphics briefly before, and I remember it taking a really long time. So I just hardcoded the values for the cube into the graphics file, just until I got it working. So after getting the easy part out of the way, you have to create a translation that moves the object (and it’s vertices) onto the screen. This involves creating a camera that holds all these fancy matrices that you can just call up every frame and translate the objects into the camera’s coordinate system. If you don’t do this, then the GPU wouldn’t know what to draw. This is adjusted like the position was in the previous assignment. We grab the vertex shader and adjust its constant values. We pass in the matrices that are the translations and rotations to put things in the camera’s view. Then it just ignores everything outside the -1 to 1 boundary.
The changes we made make it possible for us to have objects bigger than 1 unit to fit on the screen. Before, we were just drawing straight to the screen without taking in to account what the world looks like. This also allows us to make our square/cube actually look like a cube, rather than distorting it with window resolution. I did run in to a few issues, but that’s because when I was updating the cube’s position, I was inputting the position in to the worldToScreen matrix. It was a copy paste error and I ran around in circles for a bit trying to figure out why my object wasn’t drawing 😛
So now that we have a world that we can put things in, we added a floor for the cube to sit on. I had to refactor my code, because as I mentioned above, my vertex and index buffers were just…sitting in the graphics.cpp file. Which is bad. I didn’t want to have that spiral away any worse than it already had become. I fixed up my Mesh class, and thanks to Sid G asking about whether we should have more than one index/vertex buffer, it clicked how I could solve that problem. Any renderable will have a material and a mesh. I also have a MaterialManager and MeshManager, so we can keep track of all the materials and meshes we’ve loaded in, and we can just request a pointer to whichever one we need to use for a renderable object. The majority of my time spent on this assignment was actually just moving my mesh system over to reading lua files. SUPER cool. I actually had a lot of fun doing this section of the assignment, however, I did get stuck a lot. And I imagine this will help when we move over to using Maya files. It will probably save me time in the future. The mesh file has the vertices and the colors in one table, and in another, it has the index buffer. I…hope that I don’t need to fix it too much. I can see the index buffer part being particularly vulnerable to mistakes. But I guess doing graphics by hand will always be prone to that stuff.
After that, I broke the controls out so that they’re separate components, so that some things can move (such as the cube), and other things stay put (like the floor). This wasn’t that big of a change. I just made a parent control class and made the cube controller a child of it, and then just have that update position. I could have done the same thing with the camera, but I’d need to refactor a bigger chunk of my code than I’m willing to do right now.
Changing rectangle to cube and adding camera: 3 Hours
Moving mesh system to lua: 3 Hours
Adding floor, fixing control scheme: 30 Minutes
Writeup: 30 Minutes
Total: 7 Hours