Friday, 10 January 2014

Dawn of a New Day

Day one in our Graphics course with new content and we're jumping right into the heart of graphics: the hardware that makes it possible. I recently built a computer for the first time (with plenty of assistance), my first personal desktop after years of dealing with laptops. I learned very early on that as a gamer one of the most important components I would need was the GPU as it is what handles the majority of the graphics in most decent modern games. This is thanks to the wonders of modern engineering, allowing us the capability of having 1000+ cores, the GPU is capable of hundreds more processes then the CPU with it's 4-8 cores.

The GPU handles the graphics pipeline: the process of converting data into pixels on the screen. It's pretty amazing how we can program a computer to take basic points in space, convert them into simple triangles, and then output a complex model all in a matter of seconds. A lot of this is thanks to the information us programmers assign to each point, or vertex, such as colour and normal.

Okay, so we know what happens to create this image, but how does the image itself work? Digital images are made up of pixels, each consisting of 4-5 channels (RGB + Alpha, Luminance). How this information balances with each other determines the colour that displays. Other data that the graphics pipeline needs to know is textures and UV mapping. A texture is typically thought of as a 2D image that is applied to 3D model to give it colour based on where a UV map says it should go. Other forms of textures include bump and displacement maps; a map that tells the computer where there should be small valleys and ridges that are only affected by light, and a map acts as a bump map that also affects the actual geometry of the model.

Key Order: Modelview -> (eye) -> Projection -> (clip) -> Perspective -> (normalized device) -> Viewport -> (window)
Key Formula: v(new) = P x M x v(old)

Then we find out that we're going to have to reprogram a large portion of our framework... something I've known for a while but liked to pretend we would magically not have to do. In order to both a) do well in this course and b) have a game running with any amount of decent speed, we'll have to take our game out of immediate mode and have it run using more complex, faster shaders and buffers. This semester's going to be a whole lot of work, but I believe in our game and our group and know it will all be worth it in the end :)

No comments:

Post a Comment