Welcome to my website.

The Modern OpenGL Meta-Tutorial

Table of Contents

Introduction

The release of OpenGL 3.x/4.x declared much of the functionality deprecated or removed. This has left a lot of people are wanting to know how to learn modern OpenGL coding practices. Other people will have learned OpenGL in the past and now want to get back into it only to find a totally new landscape. And quite a few people are still learning the out of date methods and need to be redirected to the new stuff way.

This page isn't a tutorial itself. It's designed to give you the overall layout for learning OpenGL. Rather than walk you through some specific examples it will give you a description of what something is an why you need it then point you at various other tutorials around. This lets you shop around for the best tutorial or mix and match them.

Old vs. 'Modern'

Firstly it's important to know what the 'old' OpenGL looks like. What you should ideally avoid and why.

Here are some commonly used but deprecated functions:

  • glBegin(...)
  • glEnd()
  • glCallList(...)
  • glColor*
  • glMaterial*
  • glVertexPointer

Also anything that goes between glBegin and glEnd:

  • glVertex*
  • glNormal*
  • glTexCoord*
  • glMultiTexCoord*

All the matrix operations:

  • glRotate*
  • glTranslate*
  • glScale*
  • glMatrixMode()
  • glLoadIdentity()
  • glPushMatrix()
  • glPopMatrix()
  • glFrustum()
  • gluPerspective(...)
  • gluLookAt(..)

The 'old' method refers to what is known as the fixed function pipeline.

Firstly you might actually need the fixed function in a few special case.

  • If you need the older OpenGL ES 1.x. OpenGL ES 1.0 is what older iPhones (1st gen and 3G models befoure 3GS) and Android 1.6 and older used. Of course their 3d performance was limited due to the hardware. And Android 1.6 is only 0.5% of phones now.
  • If you need to support OpenGL version 1.5 or older. This can be the case on some older netbooks with bad graphics chipsets or drivers. 2.0 was released in 2004.
  • If you are using OpenGL SC, the safety critical version of OpenGL with much removed functionality.
  • You just want some pixels on the screen and don't care about doing it the 'right' way or are finding the new stuff too hard (hopefully this page can help with that). The deprecated/removed stuff is still accessible in new versions of OpenGL with the compatibility profile enabled (which is the default). So older stuff should work fine.

You will need to learn some form of modern OpenGL if:

  • You are planning on using WebGL.
  • Using OpenGL ES 2.0 or 3.0
  • Want to use the OpenGL core profile.
  • Want efficient programming.
  • Want to use any shaders at all. Which give you better graphics quality allowing things like per-pixel lighting and normal mapping.
  • Probably for many consoles. Nintendo and Sony have their own graphics API's but they where based on a stripped down subset of OpenGL with the old stuff removed making porting easier. This pre-dates OpenGL ES 2.x/3.x and the core profile maybe next-gen console will be closer to modern OpenGL or just support one of them directly. X-Box is of course Direct3D.
  • Want to take advantage of some of the nicer features that make programming easier such as frame buffer objects shared uniform buffer objects.

Methods of learning

There are really 3 ways for learning/teaching modern OpenGL:

  • Teach all the easier old stuff first, then the harder stuff in bits.

    The problem with this approach is that everything that is taught initially is really only intended to construct a framework on which the harder stuff can be to learned.

    You spend quite a lot of the initial learning time ingraining bad habits of stuff that is supposed to to be promptly replaced and forgotten.

    In addition to that, often the learner isn't made aware of how important some of the concepts actually are. Shaders and Vertex Buffer Objects (VBOs) are given their own little sections tucked away around tutorial 20. In many cased way before that point the person reading the tutorials has gotten the parts they wanted, pixels on the screen. That's enough for them to run off and code their awesome 3D game which was the inspiration for that stuff and leaving the harder shaders until later and the VBO's until performance becomes an issue.

    Often people don't get a fantastic grasp of things like matrices either since they blindly use things like glMatrixMode and glLoadIdentity without understanding them.

    It also doesn't cross over to OpenGL ES 2.x/3.x or WebGL.

  • Teach all the new stuff. Simultaneously, at once.

    The problem with learning modern OpenGL and doing it in a technically correct way, as in using absolutely no deprecated/removed functionality that is exposed in the compatibility profile, is that it requires quit a few components too all be learned simultaneously. Not only is this overwhelming for beginners, if any one of those components is wrong chances are nothing will render leaving the programmer with hours of tedious debugging on a subject that the know little about.

    Specifically you need the following... just to render a cube (often starting with just a flat triangle):

    • Vertex Buffer Objects
    • An understanding of the matrix operations. Since they are no longer part of core OpenGL. You can use a 3rd party library to do most of that but be aware that it is likely to be programming language specific (GLM on C++ for example). Otherwise you can learn the basic linear algebra of how to multiply matrices. How model, view and projection matrices are multiplied together. Learn all the transformation matrices that are required to just to move stuff around the screen and make your 3D graphics API produce 3D graphics.
    • Shaders (which are themselves a few subtopics)
      • The OpenGL API side of things, loading, compiling and linking them.
      • The data binding side of things. Vertex Attributes and Uniform variables. How to get the data into the shaders.
      • The GLSL programming language.
      • The shading algorithms themselves. The vertex*matrix multiplications. Perhaps lighting algorithms and so on.
  • The hybrid way (recommended)

    Rather than either of those I suggest going for something in between. Don't learn any deprecated functionality. But rely on some helpful stuff that most OpenGL implementations that support the compatibility profile will do by default. This lets you tackle the overall problem in small chunks. However this won't work on OpenGL ES 2.x+ or WebGL.

    Plan Outline:

    • Learn to open a blank OpenGL window. This actually isn't part of OpenGL and is going to depend quite a bit on what windowing system you are going to use.
    • Use a VBO to render a single, 2D flat white triangle to the screen. OpenGL with the compatibility profile will render this without needing shaders or matrix operations. It will fallback to fixed function for the rendering and provide you with a viewport with -1.0 to 1.0 for the x & y coordinates. Z coordinates will be ignored.
    • Use a very basic shader. The vertex shader should just pass through to position information and the fragment shader can just draw it.
    • Use a uniform in the shader. A colour for the fragment shader might be a good choice.
    • Make it 3D with perspective. Learn the matrix transformations. How the model view and projection matrices multiply together. Send the matrix to the shader, if you in C++ GLM is a good library to rely on. Maybe update from a triangle to a cube. If you want you can use glSetMatrix to split the matrix operations from uploading them to the shaders but that is a deprecated function.
    • You will probably want to learn debugging at some point. With OpenGL 4.3 (or drivers that expose the extension) you can use GL_KHR_debug.
    • Check every thing is correct by enabling the OpenGL core profile. This will also depend on your windowing system.
    • Learn more advanced stuff. Indexed Vertex Buffers, Shading algorithms such as Blinn-Phong. Texturing. Transparency. Shader effects like blur/glow.
    • Even more advanced stuff. Geometry shaders, Tessellation shaders, Compute shaders.

A tutorial that most closely follows that is the opengl-tutorial.org one.

Also if you look for GLSL tutorials, OpenGL ES 2.0+ tutorials and even WebGL you should be learning the modern practices.

Another approach is the one taken in the OpenGL SuperBible 5th edition. It ships with a helper library that implements the hard stuff but then walks you though replacing all the components with your own. The down side is you spend quite a bit of time learning that library rather than OpenGL and you have to work through the whole thing.

What exactly is 'modern' OpenGL

There are roughly 3 definitions I can think of for 'modern OpenGL':

  • The programmable shader pipeline (as opposed to the old Fixed Function Pipeline).

    The shader pipeline isn't really all that modern. In fact it has been possible since 2004 when OpenGL 2.0 was released.

    This is the stuff that newer OpenGL 3.x+ requires if you want to support the 'core profile' and don't want to rely on the compatibility profile. It's stuff that people should have been doing for quite a while but for the most part people where still taught the old way as it was generally easier. If you searched for "OpenGL tutorial" a while back that's what came up. The official OpenGL Programming Guide (the Red book) taught that all the way to 7th edition even after it became deprecated. There is now a newer 8th edition.

    There are 2 major components. Containers for storing arrays of vertex information (normally Vertex Buffer Objects) and GLSL shaders.

    It works by putting all your vertex data into an array data structure, uploading the data onto the graphics card in a buffer and telling OpenGL to draw it all at once. Once OpenGL receives the draw call it runs that data through your shader programs which process the data and turn it into pixels to put on the screen.

  • The new stuff that was added to OpenGL 3.x and 4.x. Firstly there are a whole heap of nice things that make stuff much easier on the programmer or more efficient. Much of it could have been done other ways with more difficulty or overhead. Some of it has been around for quite a while in extensions. Other things involve some entirely new stuff. It includes things like:

    • FrameBuffer Objects (OpenGL 3.0). Let you choose a 'surface' on which to to render the pixels rather than just directly to your window.
    • Uniform Buffer Objects (OpenGL 3.1). Lets you put all your shader uniform variables into one block. As they are buffers these can be uploaded to the card all at once. They can also be shared between shaders so commonly used uniforms such as matrices can be uploaded only once rather than once to every shader. They do require a little more work.
    • GLSL Subroutines (OpenGL 4.0). Similar to having function pointers. Lets you swap out a function in a shader with another. Better than using if/elseif/else as shaders are run in bulk, all conditional branches in a shader will execute rather than just the true branch, meaning quite a bit of overhead (often it's actually better to just add the results and multiply by 0.0 or 1.0 to enabled and disable features than use if, the subroutines provides an alternative solution but only works on all shaders rather than specific vertices or pixels).
    • Tessellation shaders (OpenGL 4.0). Most notably can be used for level of detail (LOD).
    • Geometry shaders (OpenGL 3.2). Geometry shaders are a bit less notable compared to Tessellation ones but have their uses. Can be used for things like point sprites.
    • Transform Feedback. (OpenGL 3.0, more in 4.0 and 4.3). Geometry and Tessellation shaders allow you to take work off the CPU and thanks to the parallel processing power of modern GPUs do it much faster and don't require you to upload as much data to the GPU. But by themselves they have to be run every frame giving you an overall decrease in performance. However using Transform feedback you can capture the output and put it into a buffer meaning you only have to run the tessellation/geometry shaders once.
    • Less binding. GL_ARB_separate_shader_objects gives you the option of using glProgramUniform* instead of glUniform*. The second one requires you to bind a shader program in advance, the first allows you to specify the id of the shader program in the function letting you skip that step. This saves a function call and makes object orientated programming much nicer. Hopefully in future we will see a full Direct State Access (DSA) extension, t's been one of the most wanted features in OpenGL for a while now however it's been passed over quite a few times. There is an extension that has been around for a while and is apparently well supported on nVidia and ATI. It's not likely to end up in core as it has lots of stuff for deprecated functions. There is also NV_bindless_texture, but nVidia have apparently patented it. (see also NV_GL_shader_buffer_load
    • Improved debugging. (OpenGL 4.3). A new debugging extension (KHR_debug) was added making debugging OpenGL much easier. Adds in things like debug callbacks rather then having to continuously poll for errors. It's Probably useful for development even if you plan on only using an older, more compatible set of extensions. Just turn it off on the release build.
    • OpenGL ES compatibility. Thanks to some recent core extensions, OpenGL 4.1 is a superset of OpenGL ES 2.0 and OpenGL 4.3 is one for OpenGL ES 3.0, this means you can write an OpenGL ES program and have it run on the desktop with little porting. Of course as OpenGL ES 2.0 and 3.0 are subsets of desktop OpenGL if you write a OpenGL ES 2.0 program you will be fairly desktop OpenGL compatible with a little work. But there are some things like shader precision that you will need to take into account. Unfortunately ES 2.0 compatibility was only added recently to OpenGL 4.1 making it hard to support legacy desktop systems, but it should be useful for development.
    • If your just learning for your own sake or you are able to guarantee/require support for the new OpenGL versions you should take advantage of the new functionality.
    • If you expect your project to take a long time and think you will see enough adoption of the new version of OpenGL by the time your finished.
    • Maybe in the future if your developing for a Next-Gen console. Current generation consoles have their own graphics libraries, that was because they where developed befoure there was a OpenGL core. They are similar to a stripped down OpenGL in the same way OpenGL ES is. Now there is OpenGL core maybe we will see that used to save developers work. Then again they might want the vendor lock in, legacy support and ability to keep the same coding style. (This doesn't apply to XBox, being Microsoft they use DirectX). Valve are also releasing a Steam Box that is based on Linux that is likely to support newer versions of OpenGL. In a talk given by Valve and nVidia they recommend using OpenGL for new projects as it works everywhere.
    • It should even be possible to use OpenGL ES on XBox thanks to Google's Project ANGLE.

    Unfortunately quite a few systems don't yet support the newer OpenGL versions. You will have to decide if you need to support those systems.

    For example OSX only supports core OpenGL 3.2, and only lists the core profile (and some extensions) as of OSX 10.8/10.7.4 also mixed legacy support for OpenGL 2.1/2.0 and even as far back as OpenGL 1.4 for 10.7.5 on some hardware). Apple appear to specify what OpenGL versions are supported based on the OS version rather than doing it through driver updates so people buying the latest Macs today won't see anything beyond 3.2 unless they fork over money for a full system update. So if you want to support Apple your going to have to stick with Older versions only.

    Older netbooks are unlikely to support OpenGL 3. Newer Intel drivers are currently only just at 3.x depending on the OS (some are 3.3, but Linux support lags behind at 3.0 currently). Intel do seem to be making rapid progress in the area and have made quite a few opensource releases.

    However some chipsets are unlikely to ever see support due to the hardware being licensed from a 3rd party. Intel's GMA500 (poulsbo) for example is based on Imagination Technologies' PowerVR's SGX535 and has notoriously bad Linux support, 3 differnt actual drivers most of which are closed (psb & EMGD) and only work with specific versions of Xorg and the Linux kernel, have poor performance, require specific settings for different platforms using the same chipset, require patched video acceleration libs for things like mplayer, and don't support many features (rotation on EMGD). There is an opensource one (gma500_gfx) in the kernel but it's 2D only). More anoyingly it is apparently only due to licensing issues, there where quite a few rumors of new better drivers (and even opensource ones) and even a video being released showing what is apparently a fully working Gallim 3D based driver running at a good FPS. This was back around 2009 and none of which ever came to anything. There is a 'high priority'FSF project to reverse engineer the PowerVR chipset but it seems to be close to dead (although there is some recent activity it's unlikely to see any real progress in the time period that the chipset's will remain relevant in).

    OpenGL ES 2.0 of course doesn't support the new features, although it does benefit from the legacy compatibility features present in GL_ARB_ES2_compatibility. As that extention only shipped in OpenGL 4.1 it means you can support newer desktop systems and older embedded systems, but not older desktop systems with the same codebase. It does make OpenGL ES development easier though. OpenGL ES 3.0 supports some new stuff but it was only released recently and so there is very little hardware support. Nothing like Geometry/Tessellation Shaders without using an extension. Similarly there is a compatibility extension (GL_ARB_ES3_compatibilityfor OpenGL 4.3 (which was released at the same time as OpenGL ES 3.0).

    WebGL doesn't support it either as it's only against OpenGL ES 2.0. Perhaps a newer WebGL will be released in future against the OpenGL ES 3.0 spec. It is possible to enable full desktop OpenGL in WebGL but requires tweaking.

    Support is of course hardware dependant. OpenGL 4.x requires Shader Model 4.0 support and 3.x requires Shader Model 3. There are features that could be supported on older hardware, they are often exposed through extensions but you can't guarantee it and some things will never work (at least without a total software fallback, which if combined with transform feedback does make geometry/tessellation shaders a possibility, but seeing drivers support that kind of thing isn't too likely).

    The Steam Hardware survey does show 94.23% coverage for combined DX10/11 most of which should support OpenGL 3.0+ (although that is driver dependant). This is only representative of Steam users though but for some game developers that is their main platform. Steam are also releasing their own Linux based console.

    Depending on what your building you may be able to just require whatever OpenGL version you want. Less doable for mass market but possible if your developing some specialized niche software on a contract (maybe imaging medical data, making simulators for the military, etc...). You could always charge more for legacy support due to the extra development overhead.

    Much of this stuff can be worked around by providing alternative ways to support the same functionality but that's going to make more work for you so it will only be useful if you need to added efficiency of something specific but not for the syntactical candy. If your doing enough of it you could look at making a library the provides transparent fallbacks for legacy systems some simple things like providing fallback functions so if glProgramUniform isn't supported then it will use the older glUniform functions after calling glProgramUse. It might even be possible to provide support for more advanced things like geometry/tessellation shaders by using a software renderer like Mesa provided the performance is good enough (not sure if Mesa support tessellation yet, but does Geometry seems to be there).

  • The ultra modern next-gen stuff.

    OpenGL 4.3 added compute shaders and storage buffers. These can apparently be combined to allow you to use compute shaders on the graphics card for programmable vertex pulling.

    This is fairly new so I don't have any learning resources for that. Have a look at the OpenGL 4.3 review for a better description, also according to that there is a GPU Pro article in the works.

    Realtime global illumination. Get raytraced like graphics.

    Voxel rendering.

    There are likely other nifty things such as culling objects on the card and so on.

    Your also going to be further limiting your supported platforms beyond the 3.x stuff, although it shouldn't be as bad. OpenGL 2.x was around for quite a while. However 3.0 went to 4.3 fairly quickly, 7 versions in 4 years. OSX is the main problem here.

Resources

  • The Official Specifications - Gives you the complete guide to everything.

  • The official OpenGL man pages - A nice big list of functions and their documentation.

  • opengl-tutorial.org - I mainly recommend this one as it breaks up things into small bits and doesn't use deprecated functionality it's also simple to understand. OpenGL 3.3+. C++. GLM, Cmake, Windows/Linux/Mac,
  • ogldev - Seems fairly complete and doesn't seem to use use deprecated stuff. Mostly OpenGL 3.3 and some 4.x later for tessellation. C++
  • open.gl - Modern tutorials, still under development. C++/GLM.
  • OpenGLBook.com - Only a few beginning tutorials but they do following the bit by bit method of learning. Good long section of OpenGL history in the Preface. C.
  • Learning Modern 3D Graphics Programming (arcsynthesis) - Probably the one most commonly recommended by people. This is a bit harder that the one above but more in-depth. Also check out the source code repositry. Been around a bit longer. C++
  • wikibooks - The modern OpenGL wikibooks tutorial. If something is lacking, add it! :)
  • wikibooks - GLSL Programming - Specific for shaders.

  • Lazy Foo - I don't recommend using this as an overall tutorial as it starts of using OpenGL 2.1 until lesson 29 when it introduces OpenGL 3.0 stuff. Some of the later tutorials may be useful for specific concepts.

  • NeHe - It should probably be avoided as it is almost completely based on deprecated functionality. They have classified the tutorials under 'legacy' now. Worth knowing about as for quite a while this was the best source for OpenGL tutorials and it's still the first result returned for a search of "OpenGL Tutorials". There will be some parts that are useful for modern techniques such as VBOs.

  • G-Trac OpenGL reviews - These are a great way to learn all the new features of OpenGL 3.x/4.x and how they fit it. Written by the GLM author.
  • G-Trac OpenGL Samples - Sample code.
  • Udacity Interactive Rendering course - Free, online video lectures. Problemsets and stuff all done in the browser. JavaScript with WebGL.
  • Porting Source to Linux - An interesting talk given by a Valve employee about porting from DirectX to OpenGL using a wrapper layer. Interestingly enough the final version is %20 than the native DirectX one.
  • ANGLE - An OpenGL ES 2.0 to DirectX 9 wrapping layer.

Identifying OpenGL Version

How do you know what version of OpenGL that function comes from? And/or if it's deprecated? The simplest way is to use the raw OpenGL .spec file. It's not designed to be human readable but you can just search for the function name (without the 'gl' prefix at the start) and check the category/version/deprecated sections to see what version of OpenGL it is part of. Enums are in the enumext.spec.

It's a good habit to know exactly what version of OpenGL each function requires. That way you know if you need Shader Model 3.0, 4.0 or 5.0 hardware or if your compatible with OpenGL 2.x.

Important Concepts

Windowing

Opening a Window is out of the scope of OpenGL. It is platform dependant and there are quite a few Options. If you cant get the basic window open and linked against the OpenGL libs your not going to get very far. Windowing toolkits often handle other things such as input, UI widgets, font rendering and so on. Ones that don't provide such functionality can be augmented with other libraries.

  • FreeGLUT - This is the de facto OpenGL Windowing system. Fairly simple and easy to use. It is an open source clone of the closed GLUT. It's only meant to implement GLUT (which itself seems to have been abandoned since 1997) so it won't get much in the way of new features. Not very actively developed (although there was a single 2012 release). It's a C library so it's not object orientated. Cross platform. Supports creating an OpenGL core context.

  • GLFW - A nicer alternative to GLUT. Seems to do everything GLUT does and is still actively developed with new features being added with a major new 3.x version under development. Like glut it's a C library so not much in the way of OOP. Supports creating a OpenGL Core context.

  • Qt - Qt provides a whole widget toolkit including fairly decent OpenGL integration. You get access to things like basic buttons through to a webkit HTML5 render. You can embed OpenGL in Qt and embed Qt widgets in OpenGL, in 2D or 3D. Also has it's own OpenGL binding for things like shaders but then you using Qt rather than pure OpenGL. Another nice thing about Qt is QtCreator which provides a full IDE/Compiler, this can be great for people who are newer to programming. Qt5 under development is fully hardware accelerated. Recently brought from Nokia by Digia (after Nokia's abandonment of Linux for Windows Mobile). Cross platform. C++.

  • SDL - Kind of dated now but there is a 2.x version in the works. Was used by some AAA game titles on Linux like NeverWinter Nights. Does 2D stuff but in software only (hardware in 2.x-dev) and it's a bit of a pain as you have to code in things like setting bytes in your specific colour depth by hand. Also has sound, font rendering, and so on as separate libs. Does do an OpenGL core profile. C lib again. Supports core context).

  • SFML - Kind of a newer alternative to SDL. Object orientated C++ API. Supports OpenGL 3.x+ contexts since version 2.0. Doesn't support core profile yet.

  • EGL - It's the official Kronos specification. But it's only intended for embedded systems. If your developing OpenGL ES on Android or iPhone this will probably be what you use. It is starting to gain some traction with desktop Linux thanks to Wayland. You would be using this on the RaspberryPi as it's OpenGL ES 2.0 based. Only does the basic context stuff, use something else for input (probably platform specific).

  • wgl - The Microsoft Windows one, pronounced wiggle. Closed and Windows only so you probably should avoid using it directly but is part of Windows so no extra library is needed. This is lower level access compared to the windowing toolkits and it probably what they use under the hood (similar to glx on Linux). Also only does the basic context stuff.

  • canvas3D - For WebGL, in the browser with JavaScript. WebGL is based on OpenGL ES 2.0. Works on newer versions of Chrome, Firefox, Safari, Opera. Can be shoehorned into IE with Chrome Frame which would also give you access to other HTML5 stuff, or IEWebGL.

Extensions

OpenGL allows for drivers to add support for new features even if the OpenGL library that ships with that system is out of date. For example Windows only ships with OpenGL 1.1 support. Those systems require extension loading.

  • glcorearb.h - Previously gl3.h. The Core Profile API Header provides the function signatures but doesn't actually do their loading. You can get away with using just this on Linux provided you put "#define GLCOREARB_PROTOTYPES" before the include.

  • GLEW - The defacto extension loading library. Cross platform. 1.9.0 has support for up to OpenGL 4.3.

  • gl3w - A python script to processes the gl3.h file and output extension loading headers.

  • glxx - Object orientated C++ bindings.

  • GL Load - Part of the Unofficial OpenGL SDK. Includes C & C++ bindings.

  • GLee - Latest official releases is stuck at OpenGL 3.0. But there is 4.2 in the git repository.

  • Load them yourself manually. Use glXGetProcAddress on Linux/Mac, wglGetProcAddress on Windows or eglGetProcAddress for EGL.

  • Parse the OpenGL spec files and build your own loader. - This might be a bit time consuming. The spec files are in a odd format and have quite a few bugs in them since they seem to be human written and designed to be fed through a bunch of Perl scripts rather than parsed properly. Might be worth looking at the [3rd party XML version](https://bitbucket.org/alfonse/gl-xml-specs/downloads), they have various fixes. You may also be interested in the source for the man pages (not the legacy stuff is now in the man2 directory, not man.). Also there is some old documentation about parsing it from a Haskel project.

Rasterization?

TODO

Data is specified in raw 3D coordinates. However your computer monitor is flat and only displays 2D. Even 3D monitors just use 2 different flat images to trick the eyes and provide the illusion of depth (unless your reading this in the future on some futuristic holographic volumetric voxel based display). Rasterization is the art of taking this 3D data and turning it into 2D pixels on the screen that provide the illusion of 3D.

Firstly the rasterization process must convert the 3D coordinates into 2D coordinates. It does this by multiplying them by the matrices.

There are three main matrices. Model, View and Projection. The Model matrix is used to move the object around the scene, rotate it and scale it. The View matrix is used to move and rotate your camera around the screen. Projection applies things like perspective that makes things get smaller when they are further away from the camera, this is where things like field of view go.

In the past vertices and their attributes where pushed to the graphics card one at a time in-between glBegin(). Now days vertex data can be uploaded in bulk. Vertex Buffer Objects. Vertex Array Objects.

Shading?

TODO

Shading can refer to shading caused by lighting (choosing the color of the pixels) or GPU shaders (which also include geometry/tessellation/compute). Shading Algorithms, Blinn, Phong. Compiling and linking shaders. Binding shader attributes. GLSL Shaders. New useful shader syntactical candy: shader subroutines, layout keyword, std140 layout. Shadows (shadow mapping, shadow volumes).

Frame Buffer Objects?

TODO

Render to a texture. Render to multiple targets in a single shader pass.

Rendering Pipeline?

TODO

General 3d data structures. Spacial data structures: Quadtrees, Octrees, BSPs, Kd-Trees. Order independent transparency with linked list textures. Deferred Rendering. Tessellation shaders for LOD. Object picking, color or raytracing.

  • David C. Bishop