In Retrospect...

So here we are...

At the end of another semester and at the precipice of another learning curve, I find myself reflecting back on the lessons I've learned about Intermediate Graphics, where they're headed in the industry and what purpose they serve in the real world. While this course has taken me through the ins and outs of the OpenGL Graphics Pipeline, how it's used and what we can do with it, I found that I have learned so much more from pouring my mind out and opening up to let the world in on my manner of thinking and the way I choose to express myself. For me, these blogs have been more than just another grade for a passing mark. They've been an exploration of a world I would have never known existed had I not dared to step into it. They have been an avenue for me to speak my mind and share my opinions and more than ever they've been a way for me to study topics I thought far beyond my scope of understanding. Over the past few months I've touched on a lot of important developments in graphic technologies. From game engines to lighting in real-time, from global illumination to Screen Space Ambient Occlusion. And what have I gained putting hours of my life into these blogs if not an insight into a world of graphical prowess that has amazed and kept me wanting more.

Shaders

What started out as a simple way to tell the world about graphical implementations I've been making for homework assignments soon become a deeper discovery of the nature of shading techniques and how they can be used efficiently and effectively to produce stunning and captivating visual feats that push the boundaries of current-generation consoles and make it possible to replace flaws with beautiful graphic effects.

So what is a shader? Let's go back to the basics. A shader is any program that is part of the graphics pipeline and is capable of communicating with a computer's GPU (Graphical Processing Unit). The two primary shaders I focus on in most of blog posts are the Vertex and Fragment shaders. Of course, there are about four or five different types of shaders, but those are beyond the scope of this course (although very cool to play around with and implement). The vertex shader handles the position of all vertices travelling through the pipeline. The job of the vertex shader is mainly to bring vertices form objects space to screen space using the ModelViewProjection matrix which quite basically allows the viewer to perceive the vertices in a reasonable are within their computer screens. These are then passed on with properties such as texture coordinates and colours to the fragment shader where the real magic happens. 

The fragment shader is in charge of accepting fragments from the rasterizer and compiling them into complete primitives on screen using pixels in the frameBuffer as well as interpolation between the vertex colours. The idea behind fragment shaders is not to simply produce the same pixel colour set for the vertex upon entering the shader. Instead, the fragment shader is most commonly used in combination with VBOs (Vertex Buffer Objects), VAOs (Vertex Array Objects), and FBOs (Frame Buffer Objects) to effectively create all kinds of neat graphical effects from motion blur to depth of field and everything in between. 

For really interesting graphic techniques such as bloom or shadow mapping multiple passes will afford you information to store on FBOs - this may be depth or a colour texture. The way you make use of your Frame Buffer Objects is ultimately upto you. Possibly one of the most important lessons and the biggest take away from the course is that once you have a solid framework set up, shaders are all about math and figuring out how to mathematically compute certain attributes based on light, position and colour information. After that, it's all about playing around with parameters, clamps and ranges in order to get your desired effect. 

Although there has never been any set-in-stone ways for using a shader, they are typically used to either make things more realistic or far more unrealistic. This returns to the same  discussion visited and re-visited countless times on my blog. Are post-processing effects a good thing or a bad thing? Do they add to the realism of a game or take away from it? Do they aid gameplay or heavily distract the player from their objective? Well, truth be told the answer is always the same. MODERATION. Shader effects are a terrific way of graphically simulating real-time physics in object interaction and the way light behaves relative to a material's properties. On the other hand, effect like colour grading, toon shading and bloom can be seen as flashy, unnecessary and annoying when used excessively or in the wrong context. Balance is always key when exploiting powerful technology and there must always be a fine line game developers should be weary not to cross for the sake of boasting superior graphical achievements which put them ahead of competitors. 

Frameworks

Oh for the glory of these nifty little programmable devices which aid heavily in the creation of an interactive environment with support for external classes - from shaders to FBOs. Over the course of this semester I have learned to appreciate the role frameworks play in the everyday world of intermediate graphics. A good framework is a versatile one which may be adapted or even built upon to improve the structure to better suit your current needs. In the simplest of terms, a framework is a foundation of support for attempting various graphical techniques as well as debugging should problems arise in your game engine. I have always wished that we had a formal class or tutorial session where we were specifically taught to build frameworks and use them for our shaders throughout the year. This would have been not only helpful but would have opened up a world of exploration for us earlier on in the semester. With that said, I do believe that Frameworks are done best when they are made to suit your needs and your needs alone. You are going to be the end user so you'd better make sure you're comfortable with what your framework supports and what it doesn't. 

In retrospect, the process of building your very own framework helps one understand the structure and processes involved with graphical effect implementations and using shaders, FBOs, VBOs and the lot. Additionally, the more time you spend on your framework, the more you understand it inside out and the more you begin to perceive the reward of generalizing your code to fit your needs and staying away from hard-coding in any context. 

A framework allows you control of your shader implementations and in essence makes you an expert at understanding the graphical pipeline. This is important because a lot of the user-friendly functionality is working towards being deprecated in favor of functionality that puts far more control in the hands of users. If it isn't all that clear as of yet, I'm talking about the move from 'GLSL #version 120' to 'GLSL #verison 330 core'. Here users are allowed to create their own matrices to be used in vertex and fragment shaders and are, in a sense, made to comprehend the reason the processes work the way they do. 

Toggles are always a good idea when it comes to frameworks and are encouraged in lieu of the importance of testing parameter and thresholds. Many game engines, in fact, begin as framework and develop as functionality is gradually added over time. As a foundation, with frameworks, there's nowhere to build but up. 

Game Engines

I have picked up some real jewels of wisdom over these past few months when it comes to game engines and their development. One of the first and most important lessons I've learnt is that a good game engine can take several years to build. It is about dedication and a willingness to put effort into making your engine more accessible for other people to use. This will not only help you delegate work in a team environment but will make it easier for you to build off of your code in later years. A good game engine is like a good framework, a sturdy foundation upon which to develop efficient coding practices. 

Taking a loser look at game engines over the course of the blogs I've written in the past few months, I have learned a lot about how game engines come to be conceived and the sheer manpower it takes to build them. An important lesson in building game engines is to make the lives of your fellow developers as easy as possible. Giver artists more control and they will reward you with the beauty you want to see in-game. In my personal experience, I have picked up more than a few tips here and there in regards to building game engines. For starters, nothing should ever be hard-coded. If it takes up more than ten lines then find a function or a class for it. Generalize your classes and structs as much as possible and don't ever code for the possibility of a single scenario - have a contingency plan for every possible outcome. 

Another important lesson which comes with experienced coding is the notion of planning before the code is written. It is always important to analyze what you need, why you need it and what your plan of implementation is. By writing out your designs on paper and running through the obvious and not-so-obvious logical errors, you will save a lot of time debugging. It is also crucial to remember, as briefly mentioned earlier, programming a game engine is very difficult work. You must always aim to start ahead of time in addition to being determined to keep at it until all the kinks have been worked out. Always keep your code clean, commented and readable with formatting good enough for your mother to understand. 

In Conclusion

I have got to say that I haven't had more fun doing homework then when I do hoguework. It's not only about getting the work done. It's about going out there, finding what the web has to aid you and then attempting to figure out what it all means. The tutorials were brilliant and really helped introduce me to the world of shading. Eventually I began coding  shaders myself and after the initial rough start with FBOs I grew into a natural groove and couldn't stop with so much to experiment with and tons of shaders to try out. 

I have learnt a lot in the past few months and have enjoyed sharing my experience with the world and the worldwide web. With over 1000 views, I guess they seemed to like it too!