Learning modern OpenGL - c++

I am aware that there were similar questions in past few years, but after doing some researches I still can't decide where from and what should I learn.
I would also like to see your current, actual view on modern OpenGL programming with more C++ OOP and shader approach. And get sure that my actual understanding on some things is valid.
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware
(what does it mean?) and set of 'side' libraries, to for example create window.
There is the most common GLUT, which I extremely hate. One of main reason are function calls, which doesn't allow freedom in the way how we create main loop. As some people were telling, it was not meant for games.
There is also GLFW, which actually is quite nice and straight-forward to me. For some reason people use it with GLUT. ( which provides not only window initialisation, but also other utilities? )
And there is also SFML and SDL ( SDL < SFML imo ), whereas both of them sometimes need strange approach to work with OGL and in some cases are not really fast.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
Let's mention education part now. There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?

So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware (what does it mean?) and set of 'side' libraries, to for example create window.
DX11 hardware is... hardware that has "supports DirectX 11" written on the side of the box. I'm not sure what it is you're asking here; are you unclear on what Direct3D is, what D3D 11 is, or what separates D3D 11 from prior versions?
FYI: D3D is a Windows-only alternative to using OpenGL to access rendering hardware. Version 11 is just the most recent version of the API. And D3D11 adds a few new things compared to D3D10, but nothing much that a beginner would need.
OpenGL is a specification that describes a certain interface for graphics operations. How this interface is created is not part of OpenGL. Therefore, every platform has its own way for creating an OpenGL context. Windows uses the Win32 API with WGL. X-Windows uses the X-Windows API with GLX functions. And so forth.
Libraries like GLUT, GLFW, etc are libraries that abstract all of these differences. They create and manage an OpenGL window for you, so that you don't have to dirty your code with platform-specific details. You do not have to use any of them.
Granted, if you're interested in learning OpenGL, it's best to avoid dealing with platform-specific minutae like how to take care of a HWND and such.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
This is another misunderstanding. GLUT is a library, not an extension. An OpenGL extension is part of OpenGL. See, OpenGL is just a specification, a document. The implementation of OpenGL that you're currently using implements the OpenGL graphics system, but it may also implement a number of extensions to that graphics system.
GLUT is not part of OpenGL; it's just a library. The job of GLUT is to create and manage an OpenGL window. GLEW is also a library, which is used for loading OpenGL functions. It's not the only alternative, but it is a popular one.
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
OpenGL is not a game engine. It is a graphics system, designed for interfacing with dedicated graphics hardware. This job has nothing to do with things like loading anything from any kind of file. Yes, making a game requires this, but as previously stated, OpenGL is not a game engine.
If you need to load a file format to do something you wish to do, then you will need to either write code to do the loading (and format adjustment needed to interface with GL) or download a library that does it for you. The OpenGL Wiki maintains a pretty good list of tools for different tasks.
There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
The OpenGL Wiki maintains a list of online materials for learning OpenGL stuff, both old-school and more modern.
WARNING: Shameless Self-Promotion Follows!
My tutorials on learning graphics are pretty good, with many sections and is still actively being worked on. It doesn't teach any OpenGL 4.x-specific functionality, but OpenGL 3.3 is completely compatible with 4.2. All of those programs will run just fine on 4.x hardware.

If you are writing a game, I would avoid things like GLUT, and write your own wrappers that will make the most sense for your game rendering architecture.
I would also avoid OpenGL 4.2 at this point, unless you only want to target specific hardware on specific platforms, because support is minimal. i.e., the latest version of Mac OSX Lion just added support for OpenGL 3.2.
For the most comprehensive coverage of machines made in the last few years, build your framework around OpenGL 2.1 and add additional support for newer OpenGL features where they make sense. The overall design should be the same. If you're only interested in targeting "current" machines, i.e. machines from late 2011 and forward, build your framework around OpenGL 3. Only the newest hardware supports 4.2, and only on Windows and some Linux. If you're interested in targeting mobile devices and consoles, use OpenGL ES 2.0.
GLEW loads and manages OpenGL Extensions, which are hardware extensions from different vendors, as opposed to GLUT which is a toolkit for building OpenGL applications, completely different things. I would highly recommend using GLEW, as it will provide a clean mechanism for determining which features are available on the hardware it is being run on, and will free you from the task of having to manually assign function pointers to the appropriate functions.
OpenGL SuperBible is a pretty good book, also check OpenGL Shading Language. Everything you do with modern OpenGL is going to involve the use of shaders - no more fixed functionality - so your biggest challenge is going to be understanding GLSL and how the shader pipelines work.

I'm currently learning modern OpenGL as well. I've also had hard time finding good resources, but here's what I've discovered so far.
I searched for a good book and ended up with OpenGL ES 2.0 Programming Guide, which I think is the best choice for learning modern OpenGL right now. Yes, the book is about OpenGL ES, but don't let that scare you. The good thing about OpenGL ES 2.0 is that all the slow parts of the API have been removed so you don't get any bad habits from learning it while it's still very close to desktop OpenGL otherwise, with only a few features missing, which I think you can learn rather easily after you've mastered OpenGL ES 2.0.
On the other hand, you don't have the mess with windowing libraries etc. that you have with desktop OpenGL and so the book on OpenGL ES won't help you there. I think it's very subjective which libraries to use, but so far I've managed fine with SDL, ImageMagick and Open Asset Import Library.
Now, the book has been a good help, but apart from that, there's also a nice collection of tutorials teaching modern OpenGL from ground up at OpenGL development on Linux. (I think it's valid on other OSes the name nevertheless.) The book, the tutorials and a glance or two every now and then to the Orange Book have been enough in getting me understand the basics of modern OpenGL. Note that I'm still not a master in the area, but it's definitely got me started.

I agree that it's king of hard to get in to OpenGL these days when all the tutorials and examples use outdated project files, boken links etc, and if you ask for help you are just directed to those same old tutorials.
I was really confused with the NeHe tutorials at first, but when I got a little better understanding of C, compiling libraries on UNIX and other basic stuff, it all fell into place.
As far as texture loading, I can recommend SOIL:
http://www.lonesock.net/soil.html
I'm not sure but I recall I had trouble compiling it correctly, but that may have been my low experience at the time. Give me a shout if you run into trouble!
Another usefull tip is to get a Linux VM running and then you can download the NeHe Linux example code and compile it out of the box. I think you just need GLUT for it to work.
I also prefer GLFW before GLUT, mainly because GLUT isn't maintained actively.
Good luck!

The major point of modern OpenGL is tesselation and new type of shader programs so i would like to recommend to start from a standalone tutorial on OpenGL 4 tesselation, i.e: http://prideout.net/blog/?p=48
After manuals and tutorials a good follow-up is to take a look at the open-source engines out there that are based on top of "new" OpenGL 3/4. As one of the developers, I would point at Linderdaum Engine.

"Modern OpenGL programming with more C++ OOP and shader approach" makes me mention Qt. It hasn't been mentioned yet but Qt is a library that is worth learning and is the easiest way to write cross platform C++ apps. I also found it the easiest way to learn OpenGL in general since it easily handles the initialization and hardware specific code for you. Qt has it's own math libraries as well so all you need to get started with OpenGL is Qt. VPlay is a library that uses Qt to help people make games easily so there are obviously some people using Qt to make games as well.
For a short introduction to Qt and OpenGL see my post here.
I will mention that since Qt abstracts some OpenGL code, if you are trying to use the Qt wrappers, the API is slightly different than just OpenGL (although arguably simpler).
As for my vote for good tutorials or book check out Anton's OpenGL tutorials and Swiftless tutorials. Anton's ebook on Amazon is also rated higher than any other OpenGL published resource I have seen so far (and far cheaper).

Related

OpenGL version and programming

I am using VS2010 and freeGlut2.8.1, it seems that the openGL version on computer is 4, (also I am new to openGL) I have kept reading the many of the openGL features of earlier version are no longer used in recent version and the pipeline has changed ... , how come I am coding, using the tutorials on openGL red book which is for version 1 and every thing is working ok???
You shouldn't be using a deprecated version of OpenGL while serious about programming on it. Since glut is old and its design rather rusty, I suggest using a recent windowing API that allows you to program with OpenGL 3.3+. Examples of such windowing APIs include SDL, SFML, GLFW to name a few. Also, the red book on OpenGL although is useful in understanding how OpenGL works doesn't implement it in the most up-to-date manner. There are plenty of other books out there like OpenGL SuperBible or Shader Cookbook that can get you started.
You should have a look at modern OpenGL tutorials
IMHO using glbegin / glend pairs allows one to see the big picture. But their usage is never encouraged any more.

What is the standard OpenGL toolkit?

I'm just trying to get a grasp on OpenGL that I can build from, so all I'm looking for is something basic to build windows etc. One of the things I'm noticing as I read tutorials and such is that it seems like a lot of the information is out of date - for example a lot of tutorials (many of which were written a number of years ago) refer to using GLUT, but GLUT hasn't been updated in over 10 years - eons in computer time. What do people use nowadays? I know freeglut is out there, but there isn't a whole lot of info on it - how to get it set up, etc... what do most people do? What's the simplest way to get a simple window system up and running so that I can start playing around with OpenGL?
You should first understand the difference between Legacy OpenGL which is a fixed function pipeline, and modern OpenGL which is a completely shader driven pipeline. Most online tutorials teach legacy OpenGL because it is easy to get started and has been around a long time. Legacy still works fine, but you probably want to get into modern OpenGL (at least version 3.0). Modern OpenGL is cleaner, and more flexible, but also harder to get started in, and therefore has fewer tutorials. It requires a lot more setup and libraries by the user and there is no "one way" to do things making it difficult to structure a quick tutorial around.
Some good resources for learning modern OpenGL are:
http://www.opengl-tutorial.org/ - Great lessons written by Stack overflow user.
http://opengles-book.com/ - OpenGL ES 2.0 programming guide - OpenGL ES 2.0 is directly compatible with OpenGL 3.0, so it works great for getting started. Even if you don't want to buy the book you can download sample code which is excellent.
http://www.swiftless.com/ - Swiftless Tutorials - Great OpenGL 4.0 and WebGL tutorials.
To your main question I know of 3 main libraries for cross platform OpenGL window creation. I would recommend GLFW for a cross platform tool kit. You could also learn a lot by creating a context directly in your respective platform (WGL window creation on Windows, Cocoa on MacOS X etc) rather than using a windowing library.
GLUT - you are correct it has not been updated in years. It still works, especially for legacy OpenGL, but I'm not sure how good the modern support is.
SDL - Also old and legacy OpenGL (I think this is resolved with 2.0), and includes a lot more cross platform features beyond OpenGL like threads. It is a pretty heavyweight library but I still prefer it over GLUT. A modern, updated SDL was in the works, but i haven't seen anything for it in a long time, possibly discontinued... It also has a nasty license associated with it so watch out for that.
GLFW - My personal favorite. It is clean and lightweight like GLUT and allows you to target modern OpenGL contexts on most major desktop platforms.

Cross platform window library - Integrating OpenGL and DirectX

I'm about to start working on a custom cross platform engine (c++) that will need to be able to support the latest versions of both OpenGL and DirectX. The renderer is chosen before compilation.
I'm looking at cross platform libraries to handle window creation and input that can also handle the latest implementations of DX and OGL - preferably low profile and most importantly: fast. Any recommendations?
Thanks!
SDL is probably the most used cross-platform library for that kinda thing.
You should check out SFML (Simple Fast Media Library). Although SDL is much more well-known due to its older age, SFML is far richer functionality- and design-wise, despite being only a few years old. It can essentially be described as a newer, more modern, and object-oriented SDL (it's C++; SDL is C).
To give you a brief overview of its features:
Cross-platform (Windows, Mac OS X,
and Linux).
Has modules for system-related stuff
(events, timers, etc), windowing,
video (hardware-accelerated OpenGL 2D
graphics), audio, and networking.
Supports all essential and mainstream
image and audio file formats, with
the notable exception of MP3 due to
licensing issues (although this is
available as an extension).
Also supports fonts (FreeType2 is
integrated) and many other things.
I use it for all my projects that need more than just a command line and I love it. I highly recommend it.
It should be able to provide a good base for your idea.
wxWidgets.
The OpenGL and DirectX are somewhat similar yet very different. OpenGL is built with idea to forward developers desire to render to devices if available. DirectX is built with idea to make rendering capabilities of devices available for developer.
Thanks to differences you end up implementing almost everything twice. Manipulating windows is quite minor issue. You do not need exactly same windows since you will use one or another anyway for rendering in them.
It is perhaps best to use different things for creating the windows (like SDL for OpenGL and MS API for DirectX) and wrap it behind common interface. Then the "things" will be also chosen before compilation. Where MS API is not available there you will lack DirectX too, so no need to make it portable.
Irrlicht
Ogre
Both are fast and powerful. They fit great for games, if I'm getting right your intention.

OpenGL Windowing Library for 2009 [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
Trying to decide on a library for creating a window and capturing user input for my OpenGL app, but there are just way too many choices:
GLUT (win32)
FreeGLUT
OpenGLUT
SFML
GLFW
SDL
FLTK
OGLWFW
Clutter
Qt
Others?
GLUT is simply outdated. I liked GLFW but it seems you can't set the window position before displaying it (I wanted it centered, is that so much to ask?) so you see it appear and then shift over, which bothers me. Plus development seems to have stopped on it too. SFML has some nice features, but it uses event polling rather than callbacks which I prefer for decoupling. I don't think I need all the GUI features of FLTK. SDL is slow (doesn't seem to take advantage of the GPU). And the other 3 I don't know much about (FreeGLUT, OpenGLUT, OGLWFW). So which is the lesser of the evils? Are there others I haven't heard about?
I'm just trying to make a simple 2D game. I'm familiar enough with OpenGL that I don't really need drawing routines, but I probably wouldn't complain about other functions that might be useful if they are implemented properly.
SDL allows you to create an OpenGL context that is accelerated (depending on drivers / hardware support).
I know you tagged as C++, however pygame (python) is a great library for creating 2D games, which also supports an OpenGL context. Pygame is built on SDL.
Clutter is a new OpenGL based GUI library with bindings for Perl, Python, C#, C++, Vala and Ruby. I haven't used it myself. From the website:
Clutter uses OpenGL (and optionally
OpenGL ES for use on Mobile and
embedded platforms) for rendering but
with an API which hides the underlying
GL complexity from the developer. The
Clutter API is intended to be easy to
use, efficient and flexible.
GLUT and the other GLUT alternatives should not be used in any sort of production application. They are good for putting together a quick demo application or to try something out, but not for much more than that.
If you're trying to make an OpenGL game, I'd recommend SDL. It focuses more on gaming needs. It most definitely can be used with OpenGL. A brief google for "SDL OpenGL" turned up this link on how to initialize OpenGL with SDL. Enabling OpenGL should also enable hardware rendering with the GPU.
Qt is a reasonable alternative, but it's better if you want to embed OpenGL within a larger, desktop application (think 3D modeling, CAD/CAM, medical visualization, etc) where you need access to standard OS widgets for the UI.
I'd go for Qt. Nice general purpose library + opengl support
IF "learning c++ part of what you're trying to achieve":
then
IF "you only want to learn OpenGL with a fullscreen mode":
USE GLUT //Because it's VERY VERY simple. You can get set up VERY quick
ELSE:
USE QT //Great library, has many many things that will help you. It is portable, it has a nice API
ENDIF
IF "you don't need C++":
then
USE Python //I recommend it, it is fast, no long link times, good api, omg I love this language
Background:
I also tried to make simple 2D games once, I started with C++ and NeHe. I knew nothing about OpenGL and C++ (had Java background). The language overrun me, so did OpenGL. So it was a very hard learning curve.
I don't recommend going that way, since you can get faster results by using a dynamic language (such as Python). So I started learning some years later with python. I could get the "rotating cubes" working much faster.
We have had rather good experiences with ClanLib 0.8 in 2008 and ClanLib 2.1 in 2009 on our C++ course. The productivity of the students (as measured by the quality of their project works) has greatly increased since switching over from SDL. However, it needs to be noted that 2.1 is still very incomplete and one will certainly run into features that are simply not implemented yet.
A couple of groups used Irrlicht (3D engine) with good results.
SFML looks promising, but I haven't had a chance to try it yet.
As others have stated, GLUT is not really suitable for anything serious. The rest of the libraries mentioned are something more of GUI toolkits than game development libraries.
Per recent corespondance with the author, development on OGLWFW has stopped.

Is GLUT dead?

After reading a discussion on Ubuntu Forums concerning GLUT vs. FreeGLUT.
Is GLUT dead for graphics programming? Is SDL all the rage now for OpenGL programming?
In my opinion, GLUT is still great to learn programming OpenGL in. It is no longer maintained, as far as I know.
Do look at : http://www.opengl.org/resources/libraries/glut/ for the official word
Extract from the above link -
"The GLUT library has both C, C++ (same as C), FORTRAN, and Ada programming bindings. The GLUT source code distribution is portable to nearly all OpenGL implementations and platforms. The current version is 3.7. Additional releases of the library are not anticipated.
GLUT is not open source. Mark Kilgard maintains the copyright."
Also look at : http://www.opengl.org/resources/libraries/windowtoolkits/ for alternatives.
You may also want to check out GLUX : http://code.google.com/p/glux/
As far as SDL being the rage, it is great for cross-platform stuff and many people are using it. I personally use Qt for my OpenGL work. Other windowing system alternatives also exist. It is also possible to program natively for windows or X.
Edit Feb 28 2017:
I should clarify that the student looking to jump into the practicalities of OpenGL would be better served by starting with SDL or Qt. As #TM rightly notes in his comment, using GLUT is far removed from the realities of programming a real world rendering application in OpenGL. My opinion that GLUT is good for learning comes from the thought that it is easier to learn when one separates the concern of learning an OpenGL from the concern of learning about the specifics of a Windowing system. Naturally, this may not match your needs.
GLUT is rather simplistic for serious game development. SDL is used by numerous commercial game porting companies. GLUT happens to be good for studying OpenGL and for simple demos. Something like SDL is quite good for actual games.
SDL with its abstractions for other things, such as audio, and SDL's various addon libraries (SDL_image, SDL_mixer, ...) help a lot when writing a full game. Having control over the main loop is also pretty important.
If you are working on an OpenGL application which needs some native GUI as well (for example, a 3D modeler) you may be more interested in using wxWidgets or, as batbrat suggested, Qt.
GLUT is a very useful learning guide, but it's not full featured or useful enough for most real-world applications. I've also encountered minor issues with a few different GLUT implementations and support in some environments, so I've learned to stay away from it for anything but quick demos.
My OpenGL experience has generally been on embedded systems where I have complete control over the output, and there I use X Instrinsics to get the basic OpenGL Window up. It's a bit painful, but it's a small amount of code to get to OpenGL, where the bulk of the work is done.