Archive for the ‘OpenGL’ Category

Learning OpenGL: a few months later

Yeah, I know, I failed to post at least once a month, the previous post dates back to April… but hey, did you read the title of the blog?

In this post, in March, I wrote about documentation and libraries I found useful in getting started with modern OpenGL.
After a few months, I have a small addendum to do, both regarding documentation and libraries.


When I wrote the old post, I suggested some tutorials and online documentation I had been consulting, and I wrote that I hadn’t heard of any single book suitable to learn modern OpenGL. A few weeks after my post, the OpenGL Programming Guide (8th edition), also known as “the red book“, was published – and things changed.
I bought it from Amazon (33,50 € – definitely affordable) and spent the last week reading it cover to cover: it’s great stuff, clearly written, well organized, with the amount of detail I expected (not so much to make you feel lost, but enough to give a comprehensive introduction to the API).
I wish I had it when I started learning, and I strongly advise anybody trying to learn OpenGL to buy it right now – it will be a time saver.


I read that the previous editions were heavily criticized for mixing modern OpenGL with deprecated stuff, probably as a result of incrementally updating the book. Moreover, GLSL had its own book (“OpenGL Shading Language”, a.k.a. the “orange book”) that, I guess, you definitely needed to supplement the “red book” if you were using shaders.

The 8th edition, instead, is a complete rewrite: it doesn’t use or describe the deprecated API, and it covers GLSL too. Yay! Thankyou, book authors!


If you read the old post, you might remember that I was quite confused about what was the best image handling library to be used with OpenGL.

I listed DevIL, FreeImage, ImageMagick, OpenGL Image (GLI), and Simple OpenGL Image Library (SOIL).
Recently, I also stumbled on GL Image, part of the Unofficial OpenGL SDK, that looks promising.

The “Unofficial OpenGL SDK” deserves a special mention by itself: it’s a collection of libraries and utilities helpful in getting started with OpenGL development.

I motivated my library-picks (GLFW, GLM, GLEW, Assimp) in my previous post, and I was glad to see that more experienced developers also choosed GLFW and GLM for their SDK. For image handling, the thing I was mostly in doubt about, they provided a custom library: I guess I wasn’t the only one unsatisfied in some way by all the popular libs?
On the paper, GL Image rocks, and only lazyness and the dependancy on GL Load (the SDK alternative to GLEW, that I’m using) have prevented me to try it up to now.

I don’t exclude switching to the SDK: as for the “red book”, I wish it was available earlier. Anyway, it’s worth noting that the SDK currently misses an asset loading library. Why don’t they include Assimp? I’m using it, so I hope they don’t have any good reason! 🙂

A comparison of all the image handling libraries on some key points (formats supported, features, syntax, license, usability, portability, documentation) would be interesting: it looks like a lot of work, but maybe I’ll try to write something about it in the future.

If you were wondering what I am using now, it’s DevIL.
The library API is similar in some way to the OpenGL one, and for the very limited usage I’m doing, no problems arise.
Unfortunately, it looks like DevIL development ceased in 2010 – you’ve been warned.

Anyway, postponing my final choice about image handling, there’s another library I’d like to suggest today: AntTweakBar, a GUI library.

At the beginning, I limited myself to using keyboard/mouse events to select/move objects and adjust colors or other properties in my test programs.
Of course, after a while, I ended up having an unspokable number of unpractical keyboard shortcuts, and no visual feedback about the current state (for example: coordinates of the selected object), that I only printed to the console in response to some key-presses.

Don’t even reach that point: use a GUI library to interact with your OpenGL programs right from the beginning, you’ll save time later.

I think Ant Tweak Bar is a very valuable choice in this field:

  • it’s easy to integrate into your project (with simplified interfacing to popular libs such as GLUT, SDL, GLFW, SFML)
  • it’s portable (Win/Linux/Mac)
  • it looks cool – semi-transparent, floating windows
  • it’s lightweight and easy to switch on/off
  • it provides some GUI components specifically thought for computer graphics: orientation, color, direction
  • it allows grouping and hierarchically structuring components

A GUI component worth a special mention is the “rotoslider”: you use it to change a value, like you do with a normal slider, but the circular motion allows you to:

  • spin around multiple times  (e.g.: each full clockwise rotation increases the value by 100.0), while with a normal slider you are limited by the min/max values associated with the start/end positions
  • vary the precision/speed of the value changing: moving the mouse far from the circle gives precision, while moving it near the circle allows to increase/decrease rapidly

It’ better understood with a picture, taken from the wiki page of the rotoslider:


That’s it for today! I have many half-written posts in my drafts, so I hope to publish something else soon.


Of missing textures, Assimp, the Crytek Sponza atrium, and naked women

Recently, I’m spending a lot of time in the atrium of the Sponza palace.
No, I didn’t move to Dubrovnik, Croatia, nor I’m on vacation: it’s just that the Sponza atrium model, originally created for a rendering contest, has been adopted by the computer graphics community as a test model (especially in the global illumination field), and who am I, working on my master thesis on rendering, to pick something else?

The original model dates back to 2002, but what I’m using is the updated and enhanced version made available by Crytek in 2010.

It features textures, normal maps, specular maps and opacity maps, so there’s plenty of data to be used while rendering.

I’m using Assimp to load models, and I stumbled into a couple problems. I googled about them and found nothing, so I tought that a little post on the subject was worth writing. I mean: if you get lucky and find something not yet on the Internet, you are morally obliged to blog about it before someone else does it! It works like that, right?

Anyway, enough blabbering: the two problems reside in the materials file, sponza.mtl.

  • a texture is missing
    • the material 16___Default refers to gi_flag.tga, not included in the textures archive
  • the specular maps are unreferenced
    • the textures pack features some specular maps (the files named *_spec.tga), but they are never referenced by the materials file

Let’s fix them…

Lenna, save us from the missing texture

Obviously,  the missing texture is the one of the only untextured object in the scene: the big vertical drape.  Copying some other drape texture as gi_flag.tga (or changing the filename in sponza.mtl, of course) gives visually acceptable results.

But didn’t make me happy. What was the original texture like? What if it featured a secret message of some sort? What if it was selected between hundreds, by Crytek professionals, to show some effect I could not even imagine? What if this “I WANT THE RIGHT TEXTURE” thing is just some form of OCD and I must see someone?

I googled for the misterious missing texture, gi_flag.tga but had no luck finding it. I found files named gi_flag.tga in some code repositories using the Sponza model, as I am, but after checking them out, the included gi_flag.tga was always some bogus file put there just to make the asset loader happy.

This poor guy on Stackoverflow asked for the misterious texture too, but had no luck, either.

Finally, my investigations brought me watching this amazing Crytek video, where they use the Sponza model at the beginning and around 2:30.

(also, the video humiliated me and my test renderer a lot)

It somehow solved the mistery: the missing texture is a quite boring red stuff with borders. Yawn.

Disappointement, and I still didn’t have the damn file – but it was time to move on, leaving the gi_flag.tga failure behind me. So, as you may imagine, after some hours of flying around with the camera, testing the shaders, looking if the alpha blending is done correctly, if the normal maps are applied properly, etc, the Sponza palace slowly becomes a boring place. Lion heads. RGB Drapes. Bricks. Plants. More bricks. All static, dead. Depression is around the corner, especially when you waste 3 hours ’cause you forgot to transpose a matrix, or something like that.

Consequently, I tought that selecting missing texture could be an occasion to make the place happier. How? Suddenly, the right answer came to my mind: Lenna.



This picture of Lenna Söderberg, scanned in 1973 from a Playboy issue (to be used as test image for a scientific paper), became a standard test image for compression algorithms and image processing.

I encourage you to visit for the full story.

So, I put a computer graphics iconic image into a computer graphics standard test model.

And the iconic image is a naked woman, turning a bitter failure into an epic win. Hey, that’s how I see it.


Of course, you’re welcome to spread the usage as gi_flag.tga of this Lenna texture I prepared.

Get your favourite version (I know, it’s a difficult choice) and rename as gi_flag.tga, put in the textures folder of the Sponza model, and be happy. It’s 2048×2048, you might want to scale it down to 1024×1024 or 512×512.

I properly cutted the original image to let it fit the drape geometry: I’m a gentleman, and gentlemen never let texture get stretched improperly – that could make women on them look fat.

Where are my specular maps?

This is not interesting and not funny: sponza.mtl is missing the “map_Ks” entries used in the .mtl file format to refer to specular maps. I tought it was some other Assimp quirk (for example, it loads the normal maps as height maps), but when I checked the sponza.mtl file I found no reference at all to the *spec.tga files, so Assimp was innocent.

Luckily, the files are consistently named, so a specular map named “sponza_thorn_spec.tga” can be tied to the material that refers to the “sponza_thorn_diff.tga” texture.

That’s what I did, assigning all the provided specular maps to the appropriate materials.

And here you are the updated sponza.mtl file, so you don’t have to repeat the boring file editing process:

With this, I made the post concretely useful for other people, so I’m forgiven for all the Lenna delirium.


… you now what? I’m dating this post April 1st, I can post whatever I want and still pretend to be a serious person.

Learning OpenGL: getting started and picking the “right” libraries

17/08/2013 update: after this post, you should read this addendum

I’ve been working with 3D graphics in the past, but never at low level. That was something I really wanted to do: high level tools are fun for building stuff rapidly, but you know, you never get that sense of fulfilment from knowing exactly what’s going on under the hood.

For working with 3D computer graphics at low level there aren’t many options to choose from: OpenGL or DirectX. I’m not a big fan of online religion-wars, but for me picking OpenGL was a no-brainer: portability and openness always mattered to me, and anyway OpenGL knowledge nowadays is even more attractive for its applicability on mobile platforms (OpenGL ES)  and the web (WebGL). Also, the common opinion is: once that you know one of the two, switching to the other one is not that hard.

After deciding to learn OpenGL, I started reading documentation and testing small code snippets.

There’s a lot of OpenGL documentation, but when you’re a newbie it’s not easy to choose a book or a series of tutorials that works for you. Getting oriented needs a little time, and there’s another important thing to be aware: the switch from immediate mode to “modern”, shader-driven OpenGL programming, made a lot of available documentation outdated.

Of course you can learn tecniques from old-style tutorials and update their implementations to the current best practices, but that’s something for who already knows the basics – if you are starting to learn, you need some working foundations.

Also, OpenGL is narrowly focused on interacting with the GPU to provide 2D/3D graphics rendering, so to get up and running you basically need a few libraries that handle these tasks:

  • creating an OpenGL context on your operating system (something that is out of the OpenGL specs, and so platform dependent)
  • handling input from at least keyboard/mouse
  • performing mathematical computations commonly used in 3D computer graphics (with vectors, matrices, quaternions…)
  • loading OpenGL extensions
  • loading images to be used as textures
  • loading 3D models (maybe with animations)

So, the main questions are:

  • what documentation?
  • which supporting libraries?

What documentation?

For a quick hands-on introduction that doesn’t involve buying books (and, from what I read online, it looks like there’s not really any single book everybody agrees it’s the best way to learn modern OpenGL: you need to use multiple sources anyway), I think these series of tutorials offer lots of useful information:

  •  (using GLM and GLFW)
    • written for beginners, and so very easy to follow: a good place to start
  • (using a custom math class and FreeGlut)
    • many interesting tutorials, ranging from basics stuff to more advanced topics such as shadow volumes, deferred shading, skeletal animation
  • (using GLM and FreeGlut)
    • a little hard to start with, but often goes deeper than other resources and also provides a good amount of theory. An interesting framework gets built as you proceed with the tutorials, but you often need to take your time and study the code on your own

Other stuff worth checking:

Which supporting libraries?

I propose here my choices, based on my recent experimentation, but beware: I’m not saying these are absolutely the best libraries, I’m saying that I think these are the ones more appropriate, for the little I found out in the past weeks,  in a position similar to mine (learning and experimentation trying to use a modern approach). Next month I could change my mind 🙂

So, context creation/window handling and basic input are often handled by a single library.

Freeglut is a popular choice for this, and was the first library I tested, but then I switched to GLFW.

GLFW looks more actively developed and modern, and provides many options in the creation of the OpenGL context. Freeglut is an open source rewrite of the GLUT library, that dates back to 1998 (!), so while it’s worth checking (at least for understading the structure of the many examples that use it), I think it’s better picking something else.

I prefer the way GLFW handles input (offering both polling and callbacks), and another difference I find important is that it puts you in charge of controlling the main render loop, while with Freeglut you must use the idle/display callbacks.

Alternatively, SDL, SFML and Qt are some bigger libraries that provide lots of other functionalities and aren’t focused on OpenGL, but support it. Even if they might end up being more productive/useful at some point (for example when you are developing a full featured game or a 3D enabled application), I think that they aren’t the right choice for learning purposes and experimentation.

So, the first winner is GLFW.

What about mathematics? In many tutorials/examples I see, a custom minimal math library gets built. Probably, math inclined people like doing that for getting a more deep understanding of the involved data types and operations. I’m not one of them: I think in my life I’ve already learnt and forgot how to invert a matrix too many times, so I’m happy to have a well written and tested library that does that for me. I’m not saying that it can’t make sense at some point (when you start thinking about optimization, device costraints etc) but surely not in learning stage. And excluding efficiency concerns, picking the math library is easy: OpenGL Mathematics (GLM). Why? Simple: its classes and functions are similar to those of GLSL, the OpenGL shading language. You have to write shaders in GLSL, so you have to learn that syntax anyway, so it’s nice being able to use it in C++ code too. I also have been using the Configurable Math Library (CML) for a bit, and while that’s probably a perfectly viable alternative, and a valid C++ math library, I think that for learning purpose the advantage GLM gives with its syntax is unbeatable. Both are header only libraries, and that’s cool.

Second winner: GLM.

What’s next? Extension handling. AFAIK there are only two alternatives: GLEW and GLee. And picking the winner here is easy too:  GLEW is the most recently updated of the two (2012, providing support for OpenGL 4.3, against 2011, supporting OpenGL 3.0)

What about image handling for texturing? As you can imagine, image files handling is a common task also outside the scope of 3D graphics, so many libraries exist. So, it’s about picking between the ones supporting image formats particularly used in texturing, and maybe explicitly written to be used with OpenGL. Honestly I still haven’t made my choice in this area. For production purposes, I’d care about speed (and so, texture compression: you might want to check this paper from Nvidia), but for learning, I think it’s more about what library supports more formats, is painless to add as dependency, etc. I’ve found myself using using DevIL, FreeImage and ImageMagick. I still have to test OpenGL Image (GLI), that’s from the same author of GLM (something that encourages me to try it). Another library on my radar is Simple OpenGL Image Library (SOIL) .

Last step: loading 3d assets. The winner here is Assimp (yeah, I know, some could think Assetimp would have been a better name, but I’m with the developers and their unintentional pun, as explained in the FAQ). It supports a wide range of formats, and for what I know there aren’t similar alternatives.

If you are a 3D artist too and do your own models, or someone does them for you following your directions, you might want to stick to a single format and use a specific loader for that one, avoiding a library dependency. Otherwise, using Assimp looks reasonable, and avoids you wasting time converting models around.

What about skinning and character animation? I’m not at that point yet, and it’s out of my current scope, but if you’re interested in that, I’ve heard about Cal3D. Maybe I’ll look into it in a future post, for now I think I’ve already written too much 🙂

Do you think I missed something important? I would be surprised of the opposite, so feel free to leave me a comment!

Return top