Skip to content

Instantly share code, notes, and snippets.

@Ligh7bringer
Created April 22, 2018 12:50
Show Gist options
  • Save Ligh7bringer/d281006eabe20c48bc0229fc76f742a7 to your computer and use it in GitHub Desktop.
Save Ligh7bringer/d281006eabe20c48bc0229fc76f742a7 to your computer and use it in GitHub Desktop.
OpenGL Startup

Travel Guide to OpenGL

I've figured out several things while trying to extend my knowledge of Computer Graphics.

  1. OpenGL can be a bitch if you don't know what you're doing.
  2. There is no worse pain than to experience CMake without knowing what you're doing.
  3. When walking to the depths of hell, it would be nice to have a travel guide.

And that's what this is, a travel guide.

Preface

I found this article really informative and eye-opening. I recommend reading it if you're really into the idea of writing graphics seriously.

Now if you read that and would like to take that advice seriously, then do yourself a favor and follow this guide instead of reading this document. While OpenGL is great, learning it is not necessary to understanding graphics. You will understand more of what OpenGL allows you to do (and what its doing under the covers) by avoiding it altogether. Or at least until you've fully gone through the motions without any crutches.

I can only imagine how good I would be if I had done this myself...

History

OpenGL is an attempt by a group of people known as Khronos to make a cross-platform api for graphics acceleration hardware (GPUs). Khronos isn't really a company, but rather a consortium of various people/companies that mutually vote/collaborate on how apis like this should be designed. They have many more apis and file formats than just OpenGL that each handle something else related to heterogeneous processing.

It is up to the various platforms that OpenGL can be run on to perform that implementation. Thus you have a different implementation of OpenGL (with the same interface) on every operating system.

OpenGL is old. Many consider it too old and too bloated. It was initially designed in the early 90s when GPUs weren't even a thing. It has evolved over the years to make better use of graphics hardware, but still suffers in some ways (on the driver level) of exposing sub-optimal coding paradigms. Look into Vulkan[1, 2] if you're curious as to why this is.

Programming Languages

OpenGL has been ported to many languages. Everything from Python to Haskell has an interface to the api. Javascript is becoming a popular language for 3D graphics through WebGL and Three.js.

I am going to assume for the remainder of the document that you will be using C++, as is common in the world of high performance graphics.

System

Each OS has its quirks.

Apple, for instance does not support OpenGL past version 4.1 and many of their machines only support up to version 3.3. They're really pushing support for Metal.

Microsoft implements OpenGL just fine, but also implement an alternative exclusive to their platform called Direct3D.

Mobile and web platforms have a forked subset of OpenGL called OpenGL ES.

Editor

This is really subjective. I'll list a few that I think are of note.

  • Visual Studio. An amazing IDE for C++. IMO the best. A good reason to develop on Windows.
  • CLion. It works pretty well if you're on Unix-like platform and acts as an alternative to Visual Studio.
  • Nothing beats Vim/Emacs. Beware. This is a rabbit hole.

Making/Building

OpenGL projects usually involve slightly complicated compilation processes. This is primarily because most projects include multiple external libraries to aid in handling boilerplate code. You can go the route of writing your own platform-dependant Makefiles, but that tends to get unwieldy.

An alternative that is used by many (including major game/hardware companies) is CMake.

The proper way to build your project would be to create a CMakeLists.txt file and go from there. If you don't understand the CMake language at first (don't be ashamed, its awful) and just want to get into the C++, you can simply compile through the terminal until your project gets unwieldy. At that point, you're going to have to switch.

From personal experience, I would recommend not dealing with CMake all too much. You can waste weeks trying to get your build just right and have nothing to show for it. Focus on the code.

You can start by following (or stealing) something like Glitter. Their CMake system is simple enough to get you going.

Libraries

There are many libraries that one can include to their OpenGL project to make their life easier. Here is a list of popular ones that plenty of people on the internet frequently suggest.

This is a C library with an interface for window management and input. This is basically a requirement. Without this library, there would be no way to see the output of all of your code. This ain't no WebGL, we don't got no canvas element.

With that being said, GLFW is fairly easy to set up with CMake. You can follow this tutorial and add that to your CMakeLists.txt or you can just use Glitter's.

This is an alternative to GLFW and the decision between the two is mostly up to preference. SDL does A LOT of heavy lifting. It is a very specific way of writing graphics with its own best practices. If you are interested in getting past a lot of the graphics api code and seeing something on the display, then this is a good way to go.

You're gonna need a matrix library of some sort. This is a common one that many recommend. It is a C++ header library and as such, does not need to be compiled.

If you look at the Glitter CMakeLists.txt file, you'll notice that GLM is not added as a subdirectory to be compiled via add_subdirectory(). This is because GLM is a header only library (no .cpp files) and as such only needs to be include through include_directories().

See comment below about GLAD.

This another list of header only files. Many are helpful for things you might find yourself doing, such as loading textures or generating noise.

This is a hefty library which is useful for loading 3D geometry.

Getting Started

I often found it annoying to get up and running with an idea or an experiement I wanted to perform when I was first starting out. Setting up the dependencies and patching together a CMake file desolves all creative juices.

If you want something small and simple for just those scenarios, here are a couple of files that can help: opengl.cpp

The two files above assume you've downloaded both the GLFW and GLAD source and placed them into a directory called "deps".

Resources

I don't plan on this being a full graphics course. There are a ton of other people that have put an incredible amount of time and energy into doing this already. When I was starting out, it was hard for me to filter the good from the bad resources.. How do you know if something is poorly worded if you're just starting out?

Here are a collection of links that I've found over several years that have proven useful resources (some more than others). These are basically what I have in my /Developer/Graphics/ bookmarks bar:

OpenGL Specific

Game Engine Architecture

General Graphics Theory

Graphics Relevant Math

3D Assets

Books

Although physical books are not necessary, and can get pretty expensive, I'll list some here for the interested.

Ending Thoughts

This is by no means comprehensive. I will be updating this periodically once I have acquired a greater understanding of what it is that I'm actually doing. Until then...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment