I am currently learning OpenGL via the 5th Superbible. It teaches you the core profile. But I am really confused.
I know that khronos removed the fixed function pipeline in 3.3 and declared some functions as deprecated. But the Superbible now just replaces those deprecated functions with their own functions.
Why should khronos remove something like glRotate or the matrixstack just so that I have to use 3rd party libraries (or my own) instead of the official ones?
Maybe the superbible is flawed?
glRotate() etc was removed because internally openGL deals with the matrices so it is a cleaner design to just have you supply the matrices directly.
Almost all openGL apps of any complexity are going to be doing a bunch of other matrix stuff anyway and will have their own matrix classes it's easier for openGL to just take the result rather than insist on creating them from a bunch of rotate/translate/scale calls.
They could have supplied their own matrix classes - but there are a lot of 3rd party libs you can use. One of openGL's policies (failings) is that it does rely on 3rd party libs to do anything outside the actual graphics. So beginner programs are a tricky mix of GLUT, GLEW, SDL, etc to get anything on the screen - while DirectX has everything out of the box.
Khronos removed these functions from the core profiles, but they are still available in the compatibility ones.
The main reason is one of performance:
In most applications nowadays, the amount of information which must be passed back and forth between the renderer and the application is magnitude larger than ten years ago. So the ARB came up with the buffers (vertex arrays and vertex buffer objects) to maximize the use of the bandwidth available between the main system and the rendering hardware. However, if you start using the VBO mechanism to transfert data, then most of the legacy functions become useless.
That said, besides the need to support legacy applications, which is a sufficient reason for a compatibility profile, I think that this API is still useful for learning purpose.
As for your main question, the above is only valid for the full fledged version of OpenGL, not the ES one, which doesn't support the old primitives, and in this context an emulation layer is necessary.
Related
I have a work laptop that only supports OpenGL 2.1 and i have desktop in my home with OpenGL 4.4. I'm working on a project in my Desktop. So i make my program that compatible with Modern OpenGL. But i want to develop this project in my work laptop. My question is can i make this project compatible with both Legacy and Modern OpenGL?
Like this.
#ifdef MODERN_OPENGL
some code..
glBegin(GL_TRIANGLES);
...
glEnd();
#else
glGenBuffers(&vbo);
...
#endif
What you suggest is perfectly possible, however if you do it through preprocessor macros you're going to end up in conditional compilation hell. The best bet for your approach is to compile into shared libraries, one compiled for legacy and one for modern and load the right variant on demand. However when approaching it from that direction you can just as well ditch the preprocessor juggling and simply move render path variants into their own compilation units.
Another approach is to decide on what render path to use at runtime. This is my preferred approach and I usually implement it through a function pointer table (vtable). For example the volume rasterizer library I offer has full support for OpenGL-2.x and modern core profiles and will dynamically adjust its code paths and the shaders' GLSL code to match the capabilities of the OpenGL context it's being used in.
If you're worried about performance, keep in mind that literally every runtime environment that allows for polymorphic function overwriting has to go through that bottleneck. Yes, it does amount to some cost, but OTOH it's so common that modern CPUs' instruction prefetch and indirect jump circuitry has been optimized to deal with that.
EDIT: Important note about what "legacy" OpenGL is and what not
So here is something very important I forgot to write in the first place: Legacy OpenGL is not glBegin/glEnd. It's about having a fixed function pipeline by default and vertex arrays being client side.
Let me reiterate that: Legacy OpenGL-1.1 and later does have vertex arrays! What this effectively means is, that large amounts of code that are concerned with the layout and filling the content of vertex arrays will work for all of OpenGL. The differences are in how vertex array data is actually submitted to OpenGL.
In legacy, fixed function pipeline OpenGL you have a number of predefined attributes and function which you use to point OpenGL toward the memory regions holding the data for these attributes before making the glDraw… call.
When shaders were introduced (OpenGL-2.x, or via ARB extension earlier) they came along with the very same glVertexAttribPointer functions that are still in use with modern OpenGL. And in fact in OpenGL-2 you can still point them toward client side buffers.
OpenGL-3.3 core made the use of buffer objects mandatory. However buffer objects are also available for older OpenGL versions (core in OpenGL-1.5) or through an ARB extension; you can even use them for the non-programmable GPUs (which means effectively first generation Nvidia GeForce) of the past century.
The bottom line is: You can perfectly fine write code for OpenGL that's compatible with a huge range for version profiles and require only very little version specific code to manage the legacy/modern transistion.
I would start by writing your application using the "new" OpenGL 3/4 Core API, but restrict yourself to the subset that is supported in OpenGL 2.1. As datenwolf points out above, you have vertex attribute pointers and buffers even in 2.1
So no glBegin/End blocks, but also no matrix pushing/popping/loading, no pushing/popping attrib state, no lighting. Do everything in vertex and fragment shaders with uniforms.
Restricting yourself to 2.1 will be a bit more painful than using the cool new stuff in OpenGL 4, but not by much. In my experience switching away from the matrix stack and built-in lighting is the hardest part regardless of which version of OpenGL, and it's work you were going to have to do anyway.
At the end you'll have a single code version, and it will be easier to update if/when you decide to drop 2.1 support.
Depending on which utility library / extension loader you're using, you can check at runtime which version is supported by current context by checking GLAD_GL_VERSION_X_X, glfwGetWindowAttrib(window, GLFW_CONTEXT_VERSION_MAJOR/MINOR) etc., and create appropriate renderer.
I'm working on an OpenGL project, and I'm looking for a triangulation/tessellation functionality. I see a lot of references to the GLUtessellator and related gluTess* functions (e.g., here).
I'm also using GLFW, which repeats over and over again in its guides that:
GLU has been deprecated and should not be used in new code, but some legacy code requires it.
Does this include the tessellation capability? Would it be wise to look into a different library to create complex polygons in OpenGL?
GLU is a library. While it makes OpenGL calls, it is not actually part of OpenGL. It is not defined by the OpenGL specification. So that specification cannot "deprecate" or remove it.
However, GLU does most of its work through OpenGL functions that were removed from core OpenGL. GLU should not be used if you are trying to use core OpenGL stuff.
Here follows a little addition. It should be noted here that there exist in regard to the original gluTess* implementation also more modern alternatives which follow the original concept in terms of simplicity and universality.
A notable alternative is Libtess2, a refactored version of the original libtess.
https://github.com/memononen/libtess2
It uses a different API which loosely resemble the OpenGL vertex array API. However, libtess2 seems to outperform the original GLU reference implementation "by order of magnitudes". ;-)
The current official OpenGL 4.0 Tessellation principle requires GPU hardware which is explicitly compatible. (This is most likely true for all DirectX 11 and newer compatible hardware.) More information regarding the current OpenGL Tessellation concept can be found here:
https://www.khronos.org/opengl/wiki/Tessellation
This new algorithm is better when it needs mesh quality, robustness, Delauney and other optimisations.
It generates mesh and outline in one loop for cases where gluTess needs several.
It supports many more modes, but is 100% compatible with the gluModies.
It is programmed and optimised for C++ x86/x64 with an installable COM interface.
It can also be used from C# without COM registration.
The same implementation is also available as a C# version which is about half as fast on (state of the art NET Framwork 4.7.2).
It computes with a Variant type that supports different formats: float, double and Rational for unlimited precision and robustness. In this mode, the machine Epsilon = 0, no errors can occur. Absolute precision.
If you want to achieve similar qualities with the gluTess algorithm, you need 3 times longer, including complex corrections to remove T-junctions and optimise the mesh.
The code is free at:
https://github.com/c-ohle/CSG-Project
I would like to start learning OpenGL, to use it in software written in C++ language. The natural thing I do when attempting to learn something new is acquiring proper literature and online tutorials.
With OpenGL however, I got stuck. Different literature and tutorials that I have checked almost immediately mention terms, like :
Unofficial OpenGL SDK
GLSL
FreeGLUT
SFLW
GLEW
GLFW
others ...
Even though I checked the websites of these tools or wiki entries, I still don't understand things like : what are they actually with relation to OpenGL, why use one and not another, what do they have in common, what are the differences... And probably most importantly, how do I find what I ( don't ) need ?
So I would very much like to hear an explanation on this topic. Reference to a proper online reading is good as well. Thank you.
Open Graphics Library (OpenGL) is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. As such, it only provides means for drawing basic primitives (like points, lines, triangles), but no high-level functionality. Let's work through your list:
The "Unofficial OpenGL SDK"
This is just a collection of libraries offering some (more or less) often required functionality, like loading image files, or working with 3D objects, or helper libraries for creating and managing OpenGL contexts (it does include some of the other libraries you mention, we're coming to that.) I wouldn't recommend using that SDK as a beginner, but just learn the basics and carefully select the additional libraries you want to use.
OpenGL Shading Language (abbreviated: GLSL or GLslang), is a high-level shading language based on the syntax of the C programming language.
This is not a separate tool, but a central concept of modern OpenGL. You will need it to write your shaders (which are required in modern GL). That's something you definitively have to learn, but the compiler for this language comes with your GL implementation, so this is nothing you have to install separately.
FreeGLUT, GLFW, SFLM
As I already said, OpenGL is defined platform-independent. One still needs a platform-specific API to actually create the OpenGL contexts and "connect" them to the windows (or whatever "drawables" there are on the platform). OpenGL does not even have a concept of a "window", and as such, also no means for input event handling, detecting window resizes. These libraries implement wrappers for those platform-specific GL binding APIs and the window and event management, so you can just create a OpenGL context and a suitable window without having to care about all those platform-specific details. FreeGLUT and GLFW are quite focused on providing a simple framework for OpenGL development, while SFML is a more generic multimedia framework (also supporting things like audio output) and is capable of creating OpenGL contexts and windows. Other such libraries would be SDL (which is often used for games), or Qt which supports OpenGL widgets.
GLEW is short for "OpenGL extension wrangler".
This is a OpenGL loading library. OpenGL is an extensible
API. As such, features might or might not be present on the machine your application is executed. Furthermore, the way the OpenGL is defined on some platforms, only a certain set of functions is guaranteed to be exported by the libraries. If you need features of newer versions, you have to use the extension mechanism. This means that, instead of directly linking a function at link time, you have to query the function pointers at runtime to get access to those functions. To simplify that process, such loader libraries as GLEW do exist. With GLEW, all you need to do is call glewInit() and then you can use any GL function as you like (as long as it is supported by the implementation), forgetting about all those details of the extension mechanism.
What you really "need" of this list: GLSL, but that's not a tool. The other stuff is for convenience, but I highly recommend using some platform-independent window and context management library (GLFW is quite lightweight, but it is hard to tell what you will need. For learning OpenGL, GLFW is surely a good choice.) and also some GL loader like GLEW.
What have changed that makes OpenGL different? I heard of people not liking OpenGL since OpenGL 3.x, but what happend? I want to learn OpenGL but I don't know which one. I want great graphics with the newer versions, but what's so bad?
Generally, every major version of OpenGL is roughly equivalent to a hardware generation. Which means that generally if you can run OpenGL 3.0 card, you can also run OpenGL 3.3 (if you have a sufficiently new driver).
OpenGL 2.x is the DX9-capable generation of hardware, OpenGL 3.x is the DX10, and OpenGL 4.x the DX11 generation of hardware. There is no 100% exact overlap, but this is the general thing.
OpenGL 1.x revolves around immediate mode, which is conceptually very easy to use, and a strictly fixed function pipeline. The entry barrier is very low, because there is hardly anything you have to learn, and hardly anything you can do wrong.
The downside is that you have considerably more library calls, and CPU-GPU parallelism is not optimal in this model. This does not matter so much on old hardware, but becomes more and more important to get the best performance out of newer hardware.
Beginning with OpenGL 1.5, and gradually more and more in 2.x, there is slight paradigm shift away from immediate mode towards retained mode, i.e. using buffer objects, and a somewhat programmable pipeline. Vertex and fragment shaders are available, with varying feature sets and programmability.
Much of the functionality in these versions was implemented via (often vendor-specific) extensions, and sometimes only half-way or in several distinct steps, and not few features had non-obvious restrictions or pitfalls for the casual programmer (e.g. register combiners, lack of branching, limits on instructions and dependent texture fetches, vtf support supporting zero fetches).
With OpenGL 3.0, fixed function was deprecated but still supported as a backwards-compatibility feature. Almost all of "modern OpenGL" is implemented as core functionality as of OpenGL 3.x, with clear requirements and guarantees, and with an (almost) fully programmable pipeline. The programming model is based entirely on using retained mode and shaders. Geometry shaders are available in addition to vertex and fragment shaders.
Version 3 has received a lot of negative critique, but in my opinion this is not entirely fair. The birth process was admittedly a PR fiasco, but what came out is not all bad. Compared with previous versions, OpenGL 3.x is bliss.
OpenGL 4.x has an additional tesselation shader stage which requires hardware features not present in OpenGL 3.x compatible hardware (although I daresay that's rather a marketing reason, not a technical one). There is support for a new texture compression format that older hardware cannot handle as well.
Lastly, OpenGL 4.x introduces some API improvements that are irrespective of the underlying hardware. Those are also available under OpenGL 3.x as 100% identical core extensions.
All in all, my recommendation for everyone beginning to learn OpenGL is to start with version 3.3 right away (or 3.2 if you use Apple).
OpenGL 3.x compatible hardware is nearly omni-present nowadays. There is no sane reason to assume anything older, and you save yourself a lot of pain. From an economic point of view, it does not make sense to support anything older. Entry level GL4 cards are currently at around $30. Therefore, someone who cannot afford a GL3 card will not be able to pay for your software either (it is twice as much work to maintain 2 code paths, though).
Also, you will eventually have no other choice but to use modern OpenGL, so if you start with 1.x/2.x you will have to unlearn and learn anew later.
On the other hand, diving right into version 4.x is possible, but I advise against it for the time being. Whatever is not dependent on hardware in the API is also available in 3.x, and tesselation (or compute shader) is something that is usually not strictly necessary at once, and something you can always add on later.
For an exact list of changes I suggest you download the specification documents of the latest of each OpenGL major version. At the end of each of these there are several appendices documenting the changes between versions in detail.
The many laptops with Intel integrated graphics designed before approx a year ago do not do OpenGL 3. That includes some expensive business machines, e.g., $1600 Thinkpad x201, still for sale on Amazon as of today (4/3/13) (although Lenovo has stopped making them),
OpenGL 3.1 removed the "fixed function pipeline". That means that writing vertex and fragment shaders is no longer optional: If you want to display anything, you must write them. This makes it harder for the beginner to write "hello world" in OpenGL.
The OpenGL Superbible Rev 5 does a good job of teaching you to use modern OpenGL without falling back on the fixed function pipeline. That's where I would start if I were learning OpenGL from scratch.
Their rev 4 still covers the fixed function pipeline if you want to start with a more "historical" approach.
I have some fundamental points/questions about OpenGL, not all involving code but concepts as well. I would be grateful if you could answer, affirm or expand on any of them. I warn you, some might be naive, so please bear with me.
I understand that OpenGL is just a standard, as opposed to a piece of software. For example, 'getting' OpenGL actually involves getting a third-party implementation which doesn't necessarily have to be endorsed by Khronos.
OpenGL usually refers to the combination of the GL utilities (GLU) and the GL utilities toolkit (GLUT). They have methods beginning with glu and glut, resp. and the 'basic' OpenGL methods, that begin with simply gl, are implemented by those that make graphics drivers, i.e. NVIDIA?
I assume that glut methods are OS-specific helpers, for example glutKeyboardFunc() has to be, to interpret the keyboard. So if I wanted a more powerful alternative way to interpret keyboard input, I would just use the OS API. OpenGL itself is purely about graphics, but glut has this sort of thing since graphics is not much without real-time human control.
It seems to me that glu methods may be identical to calling a series of lower-level gl methods. One example I would like to quote is glOrtho() and gluPerspective(). They seem to me to have similar ways of working, but calculating perspective may be more complex, so gluPerspective() is for convenience, but might just resolve to some gl methods.
I have studied basic OpenGL using freeglut at university, and I keep having this vision of a 'hardcore' way of using OpenGL, using only low-level methods. I don't know if this is a totally naive thought, but is there a 'professional' way of writing OpenGL, to get out its maximum functionality? Like, presumably, game developers wouldn't use glutPostRedisplay() for example, right? It seems too easy and convenient, like it hides a lot of what is going on. I suspect this is also true for C++ since GLUT callbacks aren't friendly with methods in namespaces (as I've seen in other questions).
\ 1. I understand that OpenGL is just a standard, as opposed to a piece of software. For example, 'getting' OpenGL actually involves getting a
third-party implementation which doesn't necessarily have to be
endorsed by Khronos.
Indeed.
\ 2. OpenGL usually refers to the combination of the GL utilities (GLU) and the GL utilities toolkit (GLUT). They have methods beginning with
glu and glut, resp. and the 'basic' OpenGL methods, that begin
with simply gl, are implemented by those that make graphics drivers,
i.e. NVIDIA?
No. OpenGL is just the functions beginning with gl…. Everything else (GLU, GLUT) are third party libraries, not covered by OpenGL.
\ 3. I assume that glut methods are OS-specific helpers, for example glutKeyboardFunc() has to be, to interpret the keyboard. So if I
wanted a more powerful alternative way to interpret keyboard input, I
would just use the OS API. OpenGL itself is purely about graphics, but
glut has this sort of thing since graphics is not much without
real-time human control.
Correct. GLUT is a very minimal framework, so using something else is strongly recommended.
\ 4. It seems to me that glu methods may be identical to calling a series of lower-level gl methods. One example I would like to quote
is glOrtho() and gluPerspective().
I think you refer to gluOrtho2D but yes, you're correct. glOrtho is a true OpenGL-1 function. In some way, gluOrtho2D is one of the most useless functions ever:
void gluOrtho2D(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
{
glOrtho(left, right, bottom, top, -1, 1);
}
They seem to me to have similar
ways of working, but calculating perspective may be more complex, so
gluPerspective() is for convenience, but might just resolve to some
gl methods.
Right again, but it's actually quite simple:
gluPrespective(GLfloat fov, GLfloat aspect, GLfloat near, GLfloat far)
{
GLfloat a = 0.5 * atan(fov);
glFrustum(-a*near, a*near, -a*near/aspect, a*near/aspect, near, far);
}
Starting with OpenGL-3 core, the whole matrix manipulation stuff has been removed. In any serious application it's of little use, since you'll manage the matrices yourself anyway.
\ 5. I have studied basic OpenGL using freeglut at university, and I keep having this vision of a 'hardcore' way of using OpenGL, using
only low-level methods. I don't know if this is a totally naive
thought, but is there a 'professional' way of writing OpenGL, to get
out its maximum functionality? Like, presumably, game developers
wouldn't use glutPostRedisplay() for example, right?
Yes this is possible and most game engines indeed do all the grunt work themself.
There is libSDL, which also covers OpenGL. Personally I prefer GLFW or doing the stuff myself, indeed. However this does not change the way one uses OpenGL itself. But this is just infrastructure, and it's mostly just writing boilerplate code. As a beginner you gain only very little by not using an established framework. If your program makes heavy use of GUI widgets, then using Qt or GTK, with its embedded OpenGL widget is a reasonable choice.
However some projects are very hardcore, and implement the whole GUI with OpenGL, too. Blender is the most extreme example, and I love it.
It seems too easy and convenient, like it hides a lot of what is going on. I
suspect this is also true for C++ since GLUT callbacks aren't friendly
with methods in namespaces (as I've seen in other questions).
GLUT callbacks are okay with namespaces (a namespace is just a C++ compilation time thing). But what's not possible is passing class instance methods as GLUT/C callbacks.
You seem to have a pretty good notion of OpenGL and the tookit. Not sure what's more to tell.
I guess (5) is really where one can comment on.
Depending what type of application you are building you are right in thinking that some will choose to build their application only using the native GL calls.
For example, if you build a single document app under windows that has an OpenGl view but also the standard menus and toolbars, there is a strong chance you will want to go straight for c++ and what you call "low level" api.
However, if you build a low paced game in full screen mode, there is no real reason why you should not use Glut or any other toolkit for that matter if it ease the development of your app.
The fact you use GLut or low level calls directly alone doesn't make the app better or worst :)
hope it help