Learning Modern OpenGL(codeproject.com)
codeproject.com
Learning Modern OpenGL
http://www.codeproject.com/Articles/771225/Learning-Modern-OpenGL
44 comments
Honestly the thing I found most helpful when learning how opengl works is to write a rasterizer from scratch. Then all of the buffers and shaders and everything made a lot more sense after that.
I agree that simple 'hello triangle' is not that simple any more.
When I taught OpenGL I also used good old fixed functionality - just to show how the basics works. Then (in the next lesson) I usually tried to move to modern style.
Another thing is that Rendering Techniques are moving so fast that it is hard to keep up with the pace.
When I taught OpenGL I also used good old fixed functionality - just to show how the basics works. Then (in the next lesson) I usually tried to move to modern style.
Another thing is that Rendering Techniques are moving so fast that it is hard to keep up with the pace.
> I wish the people in charge of the standard would give some thought to beginners and the increasingly awful learning curve.
Why would they?
I don't mean to be antagonistic, instead I want us to look at the incentives of standards developers. What they're trying to do is make an old API perform new tricks and perform faster. In doing so, they will implicitly be answering the requests of people at the height of their field, as those are the people who need the standard to evolve for their needs.
Beginners aren't even considered. That's a shame in the long run.
Why would they?
I don't mean to be antagonistic, instead I want us to look at the incentives of standards developers. What they're trying to do is make an old API perform new tricks and perform faster. In doing so, they will implicitly be answering the requests of people at the height of their field, as those are the people who need the standard to evolve for their needs.
Beginners aren't even considered. That's a shame in the long run.
You're right; that seems to be the way these people think.
But still, I have an answer for them:
> Why would they [give some thought to beginners]?
Because they want there to be a next generation of OpenGL experts.
Once upon a time there was OpenGL and there was DirectX, and an awful lot of people chose DirectX. Today every week brings a new API/framework/language. Most of these quickly die a well deserved death, but some don't. The competition for developer mindshare is fierce. Why not target beginners?
The answer seems to be that they wanted the API to be cleaner and easier to implement. Starting with GL 3.0 they've been tossing out the old cruft to get a more focused, streamlined API.
That sounds good, but I think it's idiotic. Everyone still implements glBegin anyway. The ARB's approach has made the maintenance of API implementations more complicated, not less.
But still, I have an answer for them:
> Why would they [give some thought to beginners]?
Because they want there to be a next generation of OpenGL experts.
Once upon a time there was OpenGL and there was DirectX, and an awful lot of people chose DirectX. Today every week brings a new API/framework/language. Most of these quickly die a well deserved death, but some don't. The competition for developer mindshare is fierce. Why not target beginners?
The answer seems to be that they wanted the API to be cleaner and easier to implement. Starting with GL 3.0 they've been tossing out the old cruft to get a more focused, streamlined API.
That sounds good, but I think it's idiotic. Everyone still implements glBegin anyway. The ARB's approach has made the maintenance of API implementations more complicated, not less.
> So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at people before they've even successfully animated a polygon.
OpenGL is a fairly low-level API. If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that.
On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end?
OpenGL is a fairly low-level API. If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that.
On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end?
> If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that.
The reason my students are learning graphics programming vary with the student. Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. And of course, this being a university degree program, many of them just want to pick up some elective credit so that they can graduate. So I take a more short-term view. I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What they do with it after that is up to them.
> ... what is the point of leading them into a dead end?
That's a good question -- one I've had to give substantial thought to.
There are really three aspects to VBOs/EBOs.
(1) Capabilities of the graphics system and the data it needs. We are dealing with a system that can render (for example) triangles arranged in strips, specified via 3-D vertex positions and other attributes.
(2) Data format. Arrays of attribute values.
(3) Storage management. Buffer objects.
If I do VBOs from day one, then I am introducing these three aspects all at once. It's tough to catch that they really are separate ideas; the concepts get all jumbled up, and understanding suffers.
OTOH, if I start with immediate mode, then I can focus on the capabilities of the graphics system. What can it do, what information does it need from us, and how do we figure out that information. This is important stuff; it's good to learn issue (1) well without having to worry about the others.
Students also get some quick success. They can write code to do interactive 3-D animation without having to worry about issues (2) and (3).
So then I move to vertex/element arrays, focusing on issue (2).
Lastly, buffer objects, and issue (3) is done.
Yes, some people would call it a waste of time to talk about immediate mode. But even ignoring the above arguments, I can cover immediate mode in an hour, complete with a functioning demo written nearly from scratch. If that's wasted time, then it isn't very much wasted time.
The reason my students are learning graphics programming vary with the student. Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. And of course, this being a university degree program, many of them just want to pick up some elective credit so that they can graduate. So I take a more short-term view. I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What they do with it after that is up to them.
> ... what is the point of leading them into a dead end?
That's a good question -- one I've had to give substantial thought to.
There are really three aspects to VBOs/EBOs.
(1) Capabilities of the graphics system and the data it needs. We are dealing with a system that can render (for example) triangles arranged in strips, specified via 3-D vertex positions and other attributes.
(2) Data format. Arrays of attribute values.
(3) Storage management. Buffer objects.
If I do VBOs from day one, then I am introducing these three aspects all at once. It's tough to catch that they really are separate ideas; the concepts get all jumbled up, and understanding suffers.
OTOH, if I start with immediate mode, then I can focus on the capabilities of the graphics system. What can it do, what information does it need from us, and how do we figure out that information. This is important stuff; it's good to learn issue (1) well without having to worry about the others.
Students also get some quick success. They can write code to do interactive 3-D animation without having to worry about issues (2) and (3).
So then I move to vertex/element arrays, focusing on issue (2).
Lastly, buffer objects, and issue (3) is done.
Yes, some people would call it a waste of time to talk about immediate mode. But even ignoring the above arguments, I can cover immediate mode in an hour, complete with a functioning demo written nearly from scratch. If that's wasted time, then it isn't very much wasted time.
>Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers.
Both of these students will learn more using a framework or game engine than immediate mode OpenGL.
> I teach low-ish level graphics programming so that my students will know low-ish level graphics programming.
What you're teaching isn't the real graphics pipeline anymore or even an abstraction of it. It's limited high level graphics programming that both doesn't teach how modern high level graphics work is done and doesn't teach fundamentals either. You're really just teaching how to write code for 90s fixed function APIs. I agree that it is a valid stepping stone (many of us started there), but I think there are much better options now than there were 15 years ago. Anyway, OpenGL is not an educational library and making the lives of educators easier should not be a concern of Khronos (or anyone). As an educator you can always build your own framework that has the appropriate level of "low-ish" levelness but holds the students hands enough to not confuse them, if you don't feel that current options are sufficient.
Both of these students will learn more using a framework or game engine than immediate mode OpenGL.
> I teach low-ish level graphics programming so that my students will know low-ish level graphics programming.
What you're teaching isn't the real graphics pipeline anymore or even an abstraction of it. It's limited high level graphics programming that both doesn't teach how modern high level graphics work is done and doesn't teach fundamentals either. You're really just teaching how to write code for 90s fixed function APIs. I agree that it is a valid stepping stone (many of us started there), but I think there are much better options now than there were 15 years ago. Anyway, OpenGL is not an educational library and making the lives of educators easier should not be a concern of Khronos (or anyone). As an educator you can always build your own framework that has the appropriate level of "low-ish" levelness but holds the students hands enough to not confuse them, if you don't feel that current options are sufficient.
> I think there are much better options now than there were 15 years ago.
What are these? (Honest question. I am aelf-taught, first in immediate mode so tend to agree with parent comment that this is a sensible approach. If there's a better way of understanding the pipeline than starting this way - I don't know it)
What are these? (Honest question. I am aelf-taught, first in immediate mode so tend to agree with parent comment that this is a sensible approach. If there's a better way of understanding the pipeline than starting this way - I don't know it)
May I suggest a different approach? (No? I will anyway :-)
First, scrap immediate mode. Do as if it doesn't exist.
Second, since modern OpenGL is impossible to teach, write a higher-level layer over modern OpenGL. Tailor that layer to teach what you want to teach. My guess is, you can do even better than the immediate mode —for teaching purposes, I mean.
Third, teach your student how you have implemented the magic, bit by bit. Or teach them some new low-level stuff, and then ask them to implement one of your high level functions. And so on, until they get the whole thing. (Be careful with that approach, though: you probably don't want your students to just plug holes in a program.)
That way, you keep the tight reward loop, and you don't teach obsolete tech. As approachable as it is, you don't want to even suggest immediate mode can be used for serious development.
First, scrap immediate mode. Do as if it doesn't exist.
Second, since modern OpenGL is impossible to teach, write a higher-level layer over modern OpenGL. Tailor that layer to teach what you want to teach. My guess is, you can do even better than the immediate mode —for teaching purposes, I mean.
Third, teach your student how you have implemented the magic, bit by bit. Or teach them some new low-level stuff, and then ask them to implement one of your high level functions. And so on, until they get the whole thing. (Be careful with that approach, though: you probably don't want your students to just plug holes in a program.)
That way, you keep the tight reward loop, and you don't teach obsolete tech. As approachable as it is, you don't want to even suggest immediate mode can be used for serious development.
This! The layer you build can be super small, about 100 lines of code or so, and people can be taught to replace the whole thing rather quickly, and we can stop getting junior programmers that thing it's ok to use OpenGL in immediate mode.
VBOs are really pretty easy to explain though, no? "Look your GPU probably has 1 or 2 GB of its own VRAM, so there's no way we would upload many polygon meshes every frame via 10000s of individual glVertex calls, so just assume something as silly and useless as glVertex doesn't exist to begin with."
On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end?
Because it lets them get feedback along the way while exposing them to some of the concepts they will be using later?
Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that.
Because it lets them get feedback along the way while exposing them to some of the concepts they will be using later?
Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that.
> Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that.
I don't think I can extrapolate your point. It all boils down to what the student wants: quick results or to actually learn OpenGL?
All I'm saying is that if you want to learn OpenGL, there's little point in spending time on de facto deprecated functionality.
I don't think I can extrapolate your point. It all boils down to what the student wants: quick results or to actually learn OpenGL?
All I'm saying is that if you want to learn OpenGL, there's little point in spending time on de facto deprecated functionality.
Students will use the "print" function and printf-style debugging frequently in production coding environments.
Students will never use the OpenGL immediate API in a production coding environment.
One of these is a much better didactic stepping-stone than the other.
Students will never use the OpenGL immediate API in a production coding environment.
One of these is a much better didactic stepping-stone than the other.
But will using the immediate API hepl them grasp some of the concepts of OpenGL? Is there truly nothing that's learned that applies to other tasks in OpenGL? I find that unlikely.
In C, the canonical hello world example can help teach about the program starting point, return codes, argument passing, and IO. This extremely simple program can help the student learn these core concepts, even if in practive their program may ignore all of that for main except what the instruction starting point is.
Was the exercise pointless, or did it help cement core concepts which may help later?
In C, the canonical hello world example can help teach about the program starting point, return codes, argument passing, and IO. This extremely simple program can help the student learn these core concepts, even if in practive their program may ignore all of that for main except what the instruction starting point is.
Was the exercise pointless, or did it help cement core concepts which may help later?
> But will using the immediate API help them grasp some of the concepts of OpenGL?
No, not a single one.
immediate mode had gl_Vertex, gl_Normal, gl_Color. Those are all gone. immediate mode had lighting, that's now hiding the fact that modern GL has no lighting, you have to write it yourself. Old GL has no normal maps, no opacity maps, no specular maps. Old GL had a matrix library. That's gone to.
You learn almost nothing from immediate mode GL that is relevant to modern GL.
You could argue you learn about some common 3D concepts like a projection matrix and a model matrix but since you don't actually work with the math in old GL you aren't really learning anything more than you could learn from any other 3D library built on top of GL.
No, not a single one.
immediate mode had gl_Vertex, gl_Normal, gl_Color. Those are all gone. immediate mode had lighting, that's now hiding the fact that modern GL has no lighting, you have to write it yourself. Old GL has no normal maps, no opacity maps, no specular maps. Old GL had a matrix library. That's gone to.
You learn almost nothing from immediate mode GL that is relevant to modern GL.
You could argue you learn about some common 3D concepts like a projection matrix and a model matrix but since you don't actually work with the math in old GL you aren't really learning anything more than you could learn from any other 3D library built on top of GL.
I agree that it's annoying how complex 'simple' examples are but am not sure the OpenGL standard is the right place to inject a beginner friendly interface. A lot of the complexity like managing buffers and graphics memory are a result of the more capable 3D hardware we have today. A better thing to do would be to have a nice beginning library built on top of OpenGL and which abstracts away a lot of the gory hardware details to expose a simpler immediate mode style or scene graph interface.
Beginners can always use something like Unity3D, or any of the other gazillion libraries that are available. IMO beginner-friendly stuff has no place in the spec.
It seems to me that many people these days aren't willing to invest time to learn certain technologies anymore. They just want to be able to slap a bunch of components together quickly, and don't want to invest time in actually learning anything. Well, good luck doing that with 3D. Even if you manage to find an API that is simple enough, you probably still don't understand the 3D math behind it, or why your renderer is dog slow even though you only draw a handful of triangles
It seems to me that many people these days aren't willing to invest time to learn certain technologies anymore. They just want to be able to slap a bunch of components together quickly, and don't want to invest time in actually learning anything. Well, good luck doing that with 3D. Even if you manage to find an API that is simple enough, you probably still don't understand the 3D math behind it, or why your renderer is dog slow even though you only draw a handful of triangles
I frequently hear WebGL recommended instead as a good place to start; that way you get 'modern' OpenGL without much of the hassle.
The thing is, OpenGL shouldn't be a learning API, especially considering on many platforms (Mac, Android, iOS, Linux) its the lowest level way to get access to all vendor's graphics hardware. The primary customers of the API should be developers of large frameworks, engines and applications and it should be the lowest level abstraction that maximizes performance and compatibility. As GPU hardware becomes less fixed function and more complex the API will naturally become less beginner friendly.
Beginners today should be starting with a game engine or a creative coding framework. There is an abundance of high or mid level options (processing, three.js, Unity 3D, Unreal 4, openframeworks, ShaderToy, etc.) that allow people to play with and learn about different parts of the graphics pipeline while getting immediate and cool results.
Processing, for example, lets people do the equivalent of glVertex\glColor immediate mode calls with far less boiler plate than GLUT, SDL or GLFW, and it's easy for them to add and learn about the transform state, fixed function lighting, shaders, etc.
Beginners today should be starting with a game engine or a creative coding framework. There is an abundance of high or mid level options (processing, three.js, Unity 3D, Unreal 4, openframeworks, ShaderToy, etc.) that allow people to play with and learn about different parts of the graphics pipeline while getting immediate and cool results.
Processing, for example, lets people do the equivalent of glVertex\glColor immediate mode calls with far less boiler plate than GLUT, SDL or GLFW, and it's easy for them to add and learn about the transform state, fixed function lighting, shaders, etc.
I like your idea. When starting with Unity/UDK/etc they would get some basic understanding of how it 3D rendering works. Then, if they want, they could go deeper and learn low level api like DX, OGL
I am glad they don't give thoughts to beginners.
Low Level Graphics APIs are about perf and giving as much access as possible to the hardware in as much as possible a cross platform way.
It's called layering. Let OpenGL focus on the lowest level. Use other libraries for higher levels.
People learning should choose what the right level for them is. Whether it's starting with Unity3D or Unreal and not worrying about the low level details, or going slightly lower level with some other library.
Adding more high-level beginner friendly features to OpenGL is the worst possible thing you could do. It clutters the API and needlessly brings all kinds of baggage with it.
For those who do want to learn though I'd suggest starting with WebGL. It's way way easier. You don't have to deal with all the system specific setup. You don't have deal with figuring out how to get some image loading library to compile and link. If you want to get started instantly use [three.js](http://threejs.org) or if you want to understand how it works try [WebGL Fundamentals](http://greggman.github.io/webgl-fundamentals/)
BTW: Those fundamentals, could easily be adapted to C/C++ and current GL.
Low Level Graphics APIs are about perf and giving as much access as possible to the hardware in as much as possible a cross platform way.
It's called layering. Let OpenGL focus on the lowest level. Use other libraries for higher levels.
People learning should choose what the right level for them is. Whether it's starting with Unity3D or Unreal and not worrying about the low level details, or going slightly lower level with some other library.
Adding more high-level beginner friendly features to OpenGL is the worst possible thing you could do. It clutters the API and needlessly brings all kinds of baggage with it.
For those who do want to learn though I'd suggest starting with WebGL. It's way way easier. You don't have to deal with all the system specific setup. You don't have deal with figuring out how to get some image loading library to compile and link. If you want to get started instantly use [three.js](http://threejs.org) or if you want to understand how it works try [WebGL Fundamentals](http://greggman.github.io/webgl-fundamentals/)
BTW: Those fundamentals, could easily be adapted to C/C++ and current GL.
I'm glad, when I started to learn OpenGL I used web tutorials and most of them were written in immediate mode.
It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all.
There's a big difference between Unity which is "Here's a model, display it at this position and this scale" and writing your own .OBJ loader and arranging vertices and outputting the data to the screen, even if you're doing it inefficiently.
Sure when you use immediate mode it's terrible performance wise and very restrictive, but once upon a time, immediate mode was the only thing. Many people who are skilled started with it, and made use of new features as they became available. Sure jumping in and doing it the right way is better, but it's also really hard.
For a parallel example for C, we have printf to write to a console. In most applications you're not actually using printf to print to an 80x25 console, you're rendering your text to a window or some other output stream. But we leave print in the stdio library, because it's handy for testing things quickly, for learning, for getting quick and dirty output when performance is less important.
Immediate mode is easy. Begin, add vertices, end. You can do a lot with it. You don't want to write a graphics engine in it, but that's no reason to discard it. You don't want to write a client app with console output but that doesn't mean it's irrelevant.
I do agree you shouldn't hold the language back to support these way of doing things, but there's no point in now letting them exist.
WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it, and then there's the reliance on js.
It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all.
There's a big difference between Unity which is "Here's a model, display it at this position and this scale" and writing your own .OBJ loader and arranging vertices and outputting the data to the screen, even if you're doing it inefficiently.
Sure when you use immediate mode it's terrible performance wise and very restrictive, but once upon a time, immediate mode was the only thing. Many people who are skilled started with it, and made use of new features as they became available. Sure jumping in and doing it the right way is better, but it's also really hard.
For a parallel example for C, we have printf to write to a console. In most applications you're not actually using printf to print to an 80x25 console, you're rendering your text to a window or some other output stream. But we leave print in the stdio library, because it's handy for testing things quickly, for learning, for getting quick and dirty output when performance is less important.
Immediate mode is easy. Begin, add vertices, end. You can do a lot with it. You don't want to write a graphics engine in it, but that's no reason to discard it. You don't want to write a client app with console output but that doesn't mean it's irrelevant.
I do agree you shouldn't hold the language back to support these way of doing things, but there's no point in now letting them exist.
WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it, and then there's the reliance on js.
>It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all.
Unfortunately this doesn't always work. For some programs (typically small ones, not really representative of common usage) the deprecated functionality will beat out the modern functionality in performance, until you scale up. I've seen this several times with display lists in particular.
Which will typically leave newbies with the feeling that the new functionality is crappy and slow.
Unfortunately this doesn't always work. For some programs (typically small ones, not really representative of common usage) the deprecated functionality will beat out the modern functionality in performance, until you scale up. I've seen this several times with display lists in particular.
Which will typically leave newbies with the feeling that the new functionality is crappy and slow.
> once upon a time
That's the important point. That one upon a time was invented 23 years ago. It was the wrong model but it took ~15 years to figure out that.
The problem with "beginner mode" is who decides what goes in it? You want what you had 10-15 years ago. Why is that the right level? Maybe it should support 1000 lights instead of 4? But that would require using deferred rendering under the hood. Maybe it should support shadows, oh but which kind as their are 10-15 techniques for shadows each with their own tradeoffs. Maybe you want it to support normal maps, or opacity maps, or specular maps, or glow maps. Maybe it should use physics based lighting because that's far easier for artists.
That's the reason all of that cruft was pulled out. OpenGL is no longer a 3D library. It's a 3D rasterization library. You build a 3D library on top of it. You choose the features you think your beginners need.
If you want your old style immediate mode GL then go use regal (https://github.com/p3/regal). Hopefully people will come out with better ways to start. (like three.js) That old school way is not the best. It was just one of the first. They figured out it was the wrong thing at the OpenGL level and moved on.
I'm happy you're nostalgic about your beginning experiences. People starting out today should start agruably somewhere else though.
> WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it
not nearly as many issues as OpenGL because unlike OpenGL, WebGL has conformance tests
http://www.khronos.org/registry/webgl/sdk/tests/webgl-confor...
That's the important point. That one upon a time was invented 23 years ago. It was the wrong model but it took ~15 years to figure out that.
The problem with "beginner mode" is who decides what goes in it? You want what you had 10-15 years ago. Why is that the right level? Maybe it should support 1000 lights instead of 4? But that would require using deferred rendering under the hood. Maybe it should support shadows, oh but which kind as their are 10-15 techniques for shadows each with their own tradeoffs. Maybe you want it to support normal maps, or opacity maps, or specular maps, or glow maps. Maybe it should use physics based lighting because that's far easier for artists.
That's the reason all of that cruft was pulled out. OpenGL is no longer a 3D library. It's a 3D rasterization library. You build a 3D library on top of it. You choose the features you think your beginners need.
If you want your old style immediate mode GL then go use regal (https://github.com/p3/regal). Hopefully people will come out with better ways to start. (like three.js) That old school way is not the best. It was just one of the first. They figured out it was the wrong thing at the OpenGL level and moved on.
I'm happy you're nostalgic about your beginning experiences. People starting out today should start agruably somewhere else though.
> WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it
not nearly as many issues as OpenGL because unlike OpenGL, WebGL has conformance tests
http://www.khronos.org/registry/webgl/sdk/tests/webgl-confor...
Good overview article, but for a better deep dive into modern OpenGL and 3D graphics in general check out the (free) book at http://www.arcsynthesis.org/gltut/ This is a fantastic resource that describes the theory and practical knowledge of using OpenGL today, like how to set up the programmable pipeline, write shaders, etc.
The History section is well worth reading standalone, as well.
Absolutely fascinating to get stories on the development of Hardware T&L, programmable shaders, the classic ATi/nVidia competition, et cetera.
http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20...
Absolutely fascinating to get stories on the development of Hardware T&L, programmable shaders, the classic ATi/nVidia competition, et cetera.
http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20...
OpenGL has been a huge wall for me.
I always learn only to forget it.
Remembering its quirks is almost impossible, and the recent articles about how inconsistently implemented it is (drivers, vendors, specs..) and how useless the extensions are claimed to be discourage even further.
http://open.gl is a fantastic resource.
Given the amount of cruft OpenGL currently carries, the massive changes (read: rewrite) that will require for it to be a sane modern graphics API and the fact that several Khronos members that would probably not want any significant changes to the API (CAD companies, for example), wouldn't it make sense for the industry to dump OpenGL like yesterday's paper and converge behind a new, modern API? For example, AMD's Mantle.
No, that would make no sense whatsoever. You seem to be somewhat misinformed about GL...
* OpenGL core profile is quite clean and lean. Both apple and intel have already decided not to implement OpenGL compatibility (where all the cruft sits). There are still a few things that can and should be cleaned up, but it's pretty great already.
* Adding an additional API means there will be YET another thing vendors have to support and will be able to screw up, in addition to the already existing plethora of APIs: GL, D3D, DDX/GDI, OpenCL, VDPAU [or something like it], CUDA [or something like it], OpenMAX, Mantle. OpenVG, ... -- nobody is going to drop OpenGL or D3D for something like mantle, because that'd instantly lose you all your customers. Not even AMD.
* AMDs mantle (which is, as far as we know, just a specific thing to their cards and not even portable to any other cards) is not an attempt to make things more stable, but an attempt by AMD to gain more control over the market (something they are in a good position to attempt right now, as they have control of the console market) and to push into the direction of a low-level interface that is strongly tied to their hardware model. Mantle as an API is (as far as we know) even lower-level than GL and D3D, and hence not very suited for most programmers and applications -- there are a lot more things you can do wrong with it.
Don't believe all the FUD you read on hackernews. The main issue with OpenGL right now is that some vendors are doing a shitty job at it, which is mainly due to the heavy influence microsoft had on the gaming industry for a long time. GL is now making a major comeback due to linux, apple and mobile platforms gaining popularity, which will help rectify these issues over time.
* OpenGL core profile is quite clean and lean. Both apple and intel have already decided not to implement OpenGL compatibility (where all the cruft sits). There are still a few things that can and should be cleaned up, but it's pretty great already.
* Adding an additional API means there will be YET another thing vendors have to support and will be able to screw up, in addition to the already existing plethora of APIs: GL, D3D, DDX/GDI, OpenCL, VDPAU [or something like it], CUDA [or something like it], OpenMAX, Mantle. OpenVG, ... -- nobody is going to drop OpenGL or D3D for something like mantle, because that'd instantly lose you all your customers. Not even AMD.
* AMDs mantle (which is, as far as we know, just a specific thing to their cards and not even portable to any other cards) is not an attempt to make things more stable, but an attempt by AMD to gain more control over the market (something they are in a good position to attempt right now, as they have control of the console market) and to push into the direction of a low-level interface that is strongly tied to their hardware model. Mantle as an API is (as far as we know) even lower-level than GL and D3D, and hence not very suited for most programmers and applications -- there are a lot more things you can do wrong with it.
Don't believe all the FUD you read on hackernews. The main issue with OpenGL right now is that some vendors are doing a shitty job at it, which is mainly due to the heavy influence microsoft had on the gaming industry for a long time. GL is now making a major comeback due to linux, apple and mobile platforms gaining popularity, which will help rectify these issues over time.
In a way, it's already started from scratch - that's OpenGL ES. But I fear they want to "unify" the two soon such as that most of the cruft is added to OpenGL ES, too (just a presumption of mine). I think if they continue with ES on its natural path, it will simply become the default graphics APIs for billions of devices, without them doing much to push it one way or the other.
It looks more like Desktop GL might move to mobile devices soon. nvidia seems to be pushing really hard in that direction. But it'll remain to be seen where things go.
I used to feel like this with OpenGL; the ammount of complexity to get my head around was so large that most of it had drained out of my ears between projects.
I've been working on something recently using modern OpenGL though, and i've found it a lot more manageable. Because there's no longer a fixed pipeline -- you have to write your own shaders to be able to do anything 3D graphics related, the pltform is vastly simpler, to the point of being relatively easy to understand, if still a little complex to use.
The API is still quite crusty; there's little in the way of abstraction, and you often have to make quite a few calls to do simple stuff, but it's conceptually a lot cleaner.
I've been working on something recently using modern OpenGL though, and i've found it a lot more manageable. Because there's no longer a fixed pipeline -- you have to write your own shaders to be able to do anything 3D graphics related, the pltform is vastly simpler, to the point of being relatively easy to understand, if still a little complex to use.
The API is still quite crusty; there's little in the way of abstraction, and you often have to make quite a few calls to do simple stuff, but it's conceptually a lot cleaner.
Eh, a lot of the recent articles on hackernews about GL have been fairly low-quality and were badly researched (like the guy who complained about timer queries blocking, because he blatantly didn't understand how CPU/GPU communication works) No need to buy into the FUD.
- if you use core profile, modern GL, there aren't a lot of quirks. It's a fairly nice API overall.
- if you target reasonably modern drivers, you won't typically find many inconsistencies and issues. If you do something unusual (like the latest idtech with megatexture) you might run into driver issues -- but that's just how things are, it's not the fault of the API. New functionality needs testing, and GPUs are still constantly evolving.
- extensions are not useless. There are a huge amount of absolutely fantastic extensions. This is, IMO, the main strength of GL over D3D (and other APIs), which does not have a mechanism like this. If you know the hardware supports a certain functionality, there will most certainly be a GL extension to exploit that functionality, even if you can't with D3D.
- in particular, KHR_debug is the best thing since sliced bread. It allows you to have the GPU driver diagnose your program for you, and give you hints such as:
- things you do wrong
- things you should do differently to increase performance
- general debug information
- information on memory usage and where your buffers are stored
- if you use core profile, modern GL, there aren't a lot of quirks. It's a fairly nice API overall.
- if you target reasonably modern drivers, you won't typically find many inconsistencies and issues. If you do something unusual (like the latest idtech with megatexture) you might run into driver issues -- but that's just how things are, it's not the fault of the API. New functionality needs testing, and GPUs are still constantly evolving.
- extensions are not useless. There are a huge amount of absolutely fantastic extensions. This is, IMO, the main strength of GL over D3D (and other APIs), which does not have a mechanism like this. If you know the hardware supports a certain functionality, there will most certainly be a GL extension to exploit that functionality, even if you can't with D3D.
- in particular, KHR_debug is the best thing since sliced bread. It allows you to have the GPU driver diagnose your program for you, and give you hints such as:
- things you do wrong
- things you should do differently to increase performance
- general debug information
- information on memory usage and where your buffers are stored
I've used Pyglet[1] to experiment and learn OpenGL using Python, although it needed some hacking to open up the 4.3 API on OS X (which only arrived at that version with Mavericks, having been stuck in a sad state for many years).
Also, not even a mention of the OpenGL Red Book[2]?
[1] http://www.pyglet.org/
[2] http://www.opengl-redbook.com/
Also, not even a mention of the OpenGL Red Book[2]?
[1] http://www.pyglet.org/
[2] http://www.opengl-redbook.com/
Jamie King has great videos on OpenGL, among other things, on his YouTube channel. It looks like it was last updated 8 months ago with 99 videos spanning 14 hours. His commentary is awesome, so you will stay entertained.
https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaO...
https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaO...
very well put together for those who are looking to actually learn OpenGL.
Many people have a romanticized view of OpenGL, whereas in fact it is very very hard and confusing.
For beginner teaching purposes, basically any other graphic library is preferable, and can still teach the same core design philosophies that OpenGL uses.
For students / learners who know what OpenGL is, have maybe played around with the Hello World examples online, and want to really delve into the depths of OGL, this is a very good guide.
Many people have a romanticized view of OpenGL, whereas in fact it is very very hard and confusing.
For beginner teaching purposes, basically any other graphic library is preferable, and can still teach the same core design philosophies that OpenGL uses.
For students / learners who know what OpenGL is, have maybe played around with the Hello World examples online, and want to really delve into the depths of OGL, this is a very good guide.
I understand what/how to do VBO's but I don't know how to link it with game dev. If I have a HUD, entities, effects, terrain, do I have one VBO to handle all that data (and update it in my game loop)? Or should I split the VBO's into HUD/entities/effects/terrain/etc?
I've been using and/or teaching GL pretty much since it came out. And every new version makes it more difficult to learn. Once upon a time you did a few glVertex and glColor calls, set up transformations, and maybe some materials and lights, and there you were. If you wanted to be really cool, then you used a texture. Nowadays even a Hello World is supposed to manage various buffer objects that interact in complicated ways, and to include code in multiple programming languages, at least one of which is never used outside of graphics.
So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at people before they've even successfully animated a polygon.
I've had great fun with OpenGL through the years, and I still do, but I wish the people in charge of the standard would give some thought to beginners and the increasingly awful learning curve.