What are some good resources for learning OpenGL 4.1 aimed at someone relatively new to graphics programming?
I'm aware that this was asked before, but I would think that ~9 months would give us more.
I know that OpenGL Programming Guide: The Official Guide to Learning OpenGL, Versions 4.1 (8th Edition) is coming out apparently in October, but is there anything else? It seems like there's been some major changes, and I'd hate to feel like my time studying until this book release was wasted. Sites can work too, provided they are focusing on 4.1.
Thank you.
If you want to learn graphics programming properly then OGL 4.1 is the place to start these days, but if as a beginner you want to hack stuff out then i'd advise you take an easier route (DirectX). Your programming skills have to up there and especially your maths skills aswell (linear algebra). Get a copy of the Spec and the Red/Orange and Blue books, a good book on mathematics for 3d graphics and prepare for alot of pain, pure 4.1 from scratch is hard.
Don't worry about not getting the latest edition of the red book, 3.3->4.1 didn't change a huge amount in terms of new features or paradigm, mainly just removing deprecated functionality.
Mesh loaders can be fulfilled by OpenCTM, GXBase is also quite good.
Don't bother learning OGL prior to 4.1, it's based on a deprecated paradigm and so you will waste time learning stuff that is officially out of date. The super bible has a good amount of code that will help you along the way.
Related
e.g. If I learn the low-level Graphics Pipeline, take a trip on learning the ARB assembly language and understand the logic for certain gpu device driver calls can it help me enhance my knowledge in GPU API programming or is there no correlation whatsover and will I be only wasting my time?
EDIT: Do professionals need to understand this to a degree?
Its definitely a good idea to have a solid understanding of what makes a GPU tick. If you know your card at a deep level, than you can easily identify bottlenecks and get maximum performance. The trouble is, finding up to date information is pretty difficult, unless you go straight to the manufacturers, and they obviously won't tell you everything about how their card works.
That link you posted is a really helpful primer, I've read it myself, but take note of the date. It was posted in 2011, which means it is almost 3 years out of date now. In the GPU world, 3 years might as well be a lifetime.
Here's a few links to nvidia and AMD's developer sites, you would probably find good information there.
http://developer.amd.com/
https://developer.nvidia.com/
ARB assembly language?
No.
You do not need to know that, though many professionals already do as a consequence of being in the industry before GLSL or Cg existed. To be honest, I cannot say that I feel any better off having experience with the ARB assembly language, all of the same concepts are taught in GLSL. And many of the hardware restrictions that applied to ARB FP/VP are no longer valid.
You would probably be doing yourself a disservice by learning it, like learning immediate mode or the fixed-function pipeline, it simply is not relevant to modern hardware/software.
That said, the blog you linked to is a very good thing to read. Do not concern yourself with hardware instruction sets (even the ARB languages are actually a virtual instruction set, translated by the driver later into the hardware's native ISA). Instead, you should understand the pipeline itself.
A high-level overview of the pipeline will do you better in the long-run. Underlying hardware optimization techniques change with each generation, but the fundamental stages of the pipeline remain relatively static (of course new programmable stages are periodically introduced). If you understand the pipeline from a high-level, then you will be prepared to learn about and apply new hardware features as they are introduced.
Not if you 're going to dive in to some obscure chip, but it most certainly helps to understand the basics of the hardware you're trying to control. I've done some console renderer programming in the past that was pretty much on the metal and that has positively influenced higher-level API usage.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Not to start a flame war....
but i am in chapter 4 of the OpenGL superbible and the books organization is NOT helpful for a beginner,
I've been doing a little research on the backstory of each API also but a lot of fingers are pointing towards Direct3D as the future easier API considering their ability to actually progress, add new features and get them out there.
Mainly though, i'm wondering if either have a steeper learning curve since i'm finding OpenGL pretty hard to get going with using my book...
Should I switch to Direct3D if it's easier to learn, and maybe return to OpenGL later if they get going and catch back up to Direct3D again?
by the way i'm hping to learn this stuff in context of studying C++ for a year and future game programming so i would also need to figure out how to get audio, ai, etc set up later too.....
Thanks!! =)
Should you switch to Direct3D? Ask yourself the following questions:
Do you want to be bound to developing for Windows only? [YES/NO]
Are you ready to invest time learning a new API design every time the major version of the API increases? [YES/NO]
Are you okay if new GPU generations' capabilities are available to you only with some major delay until the next major version of the API is released? [YES/NO]
If you answered any of the above with YES, then Direct3D is the right choice. Otherwise I recommend OpenGL:
OpenGL is available on all major operating systems and plattforms as well as on more obscure ones.
OpenGL's API design is astonishing stable, the basic principles have not changed over a decade. Take a look at the open source game Nexuiz Classic, which is largely based on the Darkplaces engine which is a overhaul of the open sourced Quake2 engine (written for OpenGL-1.1) and has been updated to support all modern whistles and bells of shader based rendering.
OpenGL's extension mechanism allows GPU vendors to give access to newest generations' capabilites at release date. With Direct3D you're forced to wait until the next version is released by Microsoft. When NVidia released their GeForce8800 in 2006 it took half a year until Joe Average Developer could write Direct3D code for its new features. However through OpenGL extensions it was immediately accessible for OpenGL programs; I remember the day I bought my GeForce8800 (4 days after official release) built it into my machine and started hacking away with the geometry shaders the same evening.
It sounds to me like you have most of this backwards.
OpenGL is definitely easier to learn than Direct3D -- in particular, you can use immediate mode for simple stuff where you don't care a lot about performance, and delay dealing with vertex buffers and pixel buffers, and so on.
OpenGL used to have a significant performance disadvantage compared to Direct3D, and relatively slow progress in adding new features. New development was turned over to Khronos a while back. While there's some controversy about some steps Khronos has taken, they have done quite well at feature parity, and it's been a few years since I've seen any real performance advantage for Direct3D either.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know there are some question about learning OpenGL.
Here is what I know:
math for 3D
3D theory
Here is what I want to know:
- OpenGL 4.0 Core profile (or latter)
- Shader Language 400 (or latter)
- every part of above (if it do not work across vendors then it still do not bother me)
Here is what I DO NOT want to know
- fixed function pipeline (will not use it ever!)
- older OpenGL's
- Compatibility profile
I prefer bigger portion of info like tutorials, series of articles, books.
PS If you know resources on opengl 3.x core profile, post them too
I cordially dislike negative answers, but I'm afraid I have to give one to this question.
You are ultimately asking for beginner material that uses features unique to OpenGL version 4.0 and above. Well, let's look at some of the unique features of 4.x.
Perhaps the biggest feature is tessellation. What does that mean? It means tessellating primitives to generate more primitives. Before one can even begin to understand what that means, one must first understand how primitives get rendered at all. That uses pre-4.x level features.
But even with a firm understanding of how rendering works, there is still a problem. In order to have any meaningful discussion of tessellation shaders, one must first have a strong understanding of tessellation algorithms. And that is not a simple subject. For a tutorial to teach a user to use tessellation shaders, the tutorial will first have to introduce spline curves and patches or subdivision surfaces. Both of these are lengthy topics that have numerous white papers devoted to them. Only after detailing the algorithms would a user be ready to see how those algorithms are implemented in the tessellation shader.
Or, to put it another way, tessellation shaders are not beginner material. I wouldn't even qualify them as intermediate-level material.
Another big feature of 4.x level hardware is shader image load store (and its companion, atomic counters), core in 4.2. It allows for some very nifty things, including order-independent transparency. However, in order for a user to even begin to understand all of the quirks around it, the user needs to be intimately familiar with the deep workings of modern shader hardware. So any tutorial would first have to explain how modern VLIW/SIMD-based hardware works, as well as how shaders are used with such hardware. Again, this is not trivial material.
Another big feature of 4.x hardware is indirect rendering. That is, putting the parameters to a glDraw call in the buffer object itself. The problem is that there is really only one reason to use this functionality: because the GPU generated data directly into one or more buffers for later rendering. And doing that usually involves some form of GPGPU operation, which is very much not a beginner-level topic.
All of these features are useful and have a real purpose. But none of them should be used by beginners; in some cases, not even intermediate-level programmers should touch them.
Now to be completely fair, there are some 4.2 features that are both non-hardware-based (so they are often implemented on 3.3 and lower versions) and quite useful. Separate program objects, for example. These features hit while I was writing my 3.3-based tutorials, and I considered going back over them and incorporating this functionality. The only reason I didn't is because implementations (drivers) are still not entirely stable with regard to this functionality. But it would be useful to do.
The main point I'm getting across is this: if you are at the stage in your graphics knowledge where you are ready to take advantage of the unique features of GL 4.x hardware, then you also have enough graphics experience that you don't need an explicit step-by-step instructional material to implement features of graphics hardware. You would be the kind of person who could read the GL_ARB_tessellation_shader extension specification and understand how to make them do what you need to.
That being said, if you are interested in material that teaches OpenGL core 3.0 or better, the OpenGL Wiki has a nice collection of such links. In the interest of full disclosure, I did write one of them.
The 5th edition of OpenGL SuperBible has been recently released. This edition reflects OpenGL 3.3 which was released at the same time as OpenGL 4.0, the book only covers the core profile and assumes no prior OpenGL knowledge.
That's what I got from the book's description anyway. I have the 4th edition and it's an excellent resource for OpenGL 2.0, so I assume the new edition along with the latest OpenGL Shading Language book would be just what you're looking for.
Durian Software has an ongoing series of tutorials covering modern OpenGL. They are aimed at OpenGL 2.0 but avoid using any deprecated functionality in later versions.
There is really very little difference between OpenGL 3.0 and 4.1. If you stick to 3.0 or later core profile, you can't use the fixed function pipeline. What you're really asking for is an OpenGL tutorial that does not use the fixed function pipeline.
Jason L. McKesson's excellent tutorial "Learning Modern 3D Graphics Programming" starts out using shaders for the very earliest basics, and never touches the fixed function pipeline.
http://www.arcsynthesis.org/gltut/index.html
I highly recommend it.
I recently stumbled on this online book:
OpenGLBook.com
I haven't read it yet, but description says that it is a free OpenGL 4.0 programming resource in online book format.
Excellent question, really. As a matter of fact, documentation is sparse.
There is a good introduction here : http://sites.google.com/site/opengltutorialsbyaks/
You may also like groovounet's ogl4 samples pack : http://www.g-truc.net/post-0310.html
but I'm afraid that's pretty much it. Lurk on the opengl discussion boards for more info ...
EDIT : found a few seconds ago. Straight from SIGGRAPH http://nvidia.fullviewmedia.com/siggraph2010/02-dev-barthold-lichtenbelt-mark-kilgard.html
http://www.opengl.org/sdk/docs/man4/
There's the man pages for OpenGL 4.1, they prove to be useful when developing.
I think one of the best hopes you have is Joe's Blog. It has a few good introductory articles on modern OpenGL, with more (supposedly) on the way.
Swiftless is updating tutorials to include new context. A good starting tutorial that has been more straight-forward regarding a quick and simple VAO, VBO and render is located at swiftless.com
Have not read it, but OpenGL 4.0 Shading Language Cookbook
The major point of OpenGL 4 is tesselation 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.
free resource:
http://www.arcsynthesis.org/gltut/index.html
everybody, I've just finished my course Introduction to Systems Programming, the last part of it was C++, I learned a lot of stuff, but all I used to write was some console programs, I want to begin to write something new on c++ (something with graphic windows or maybe small game) to improve my knowledge, from which point can I start and which books can You recommend, I found a lot materials but I don't want to waste my time for bad books, so need Your advice, thanks in advance
I once read the book "Tricks of the windows game programming gurus"
http://www.amazon.com/Tricks-Windows-Game-Programming-Gurus/dp/0672323699
All though it was the only book i ever read about game programming, I think it's a great book. All the samples are in C++.
It has a lot of mathematical and physics equations that have to do with simple game programming and graphics techniques. It also teaches you to work with DirectX.
I read it a while back (at least a couple of years) so it could be that it's outdated by now...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a C++ programmer with very extensive server programming experience. I'm however fairly bored at the moment and I decided to tackle a new area: 3D game programming, for learning purposes. Additionally I think this learning project may turn out to be good resume material in the future should I decide to work in this area.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's. If you are curious as to why (feel free to skip this):
It's a real world successful game
All the map textures, models and what not are already done (I'm not interested in learning how to actually draw a texture with photoshop or whatever)
Their file formats have been more or less completely reverse engineered
There is already an identical open source project (wowmapview) that I can look at if I'm in trouble.
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
What's the most used one in the real world?
And, something else that perplexes me: World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Is this something common in games? Why did they do it? I imagine it's a lot of work and from my understanding nobody uses OpenGL anyway (very very few people know about the secret switch at all).
If it's something usually done, do programmers usually create their own 3d engine "wrapper", something like SDL made in house, and based on switches / #defines / whatnot decide which API function to ultimately call (DirectX or OpenGL)? Or is this functionality already built in in sdl (you can switch between DirectX and OpenGL at will)?
And, finally, do you have any books to suggest?
Thanks!
I realize you already accepted an answer, but I think this deserves some more comments. Sorry to quote you out of order, I'm answering by what I think is important.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's.
However I wanted to focus on the actual 3d and rendering engine, not the interface, so I don't think I will be using it [lua] for this project.
From these two snippets, I can tell you that you are not trying to emulate the game engine. Just the 3D rendering backend. It's not the same thing, and the rendering backend part is very small part compared to the full game engine.
This, by the way, can help answer one of your questions:
World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Yep, they implemented both. The amount of work to do that is non-negligeable, but the rendering back-end, in my experience, is at most 10% of the total code, usually less. So it's not that outraging to implement multiple ones.
More to the point, the programming part of a game engine today is not the biggest chunk. It's the asset production that is the bulk (and that includes most game programming. Most lua scripts are considered on that side of things, e.g.)
For WoW, OSX support meant OpenGL. So they did it. They wanted to support older hardware too... So they support DX8-level hardware. That's already 3 backends. I'm not privy to how many they actually implement, but it all boils down to what customer base they wanted to reach.
Multiple back-ends in a game engine is something that is more or less required to scale to all graphics cards/OSs/platforms. I have not seen a single real game engine that did not support multiple backends (even first party titles tend to support an alternate back-end for debugging purposes).
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
Well, this depends strongly on what you want to get out of it. I might add that your option list is not quite complete:
DirectX9
DirectX10
DirectX11
OpenGL < 3.1 (before deprecated API is removed)
OpenGL >= 3.1
OpenGL ES 1.1 (only if you need to. It's not programmable)
OpenGL ES 2.0
Yep, those APIs are different enough that you need to decide which ones you want to handle.
If you want to learn the very basics of 3D rendering, any of those can work. OpenGL < 3.1 tends to hide a lot of things that ultimately has to happen in user code for the other ones (e.g. Matrix manipulation, see this plug).
The DX SDKs do come with a lot of samples that help understand the basic concepts, but they also tend to use the latest and greatest features of DX when it's not necessarily required when starting (e.g. using Geometry shader to render sprites...)
On the other hand, most GL tutorials tend to use features that are essentially non-performant on modern hardware (e.g. glBegin/glEnd, selection/picking, ... see the list of things that got removed from GL 3.1 or this other plug) and tend to seed the wrong concepts for a lot of things.
What's the most used one in the real world?
For games, DirectX9 is the standard today in PC world. By a far margin.
However, I'm expecting DirectX11 to grab more market share as it allows for some more multithreaded work. It's unfortunately significantly more complicated than DX9.
nobody uses OpenGL anyway (very very few people know about the secret switch at all).
Ask the Mac owners what they think.
Side question, do you really think hardware vendors would spend any energy in OpenGL drivers if this was really the case (I realize I generalize your comment, sorry)? there are real world usages of it. Not much in games though. And Apple makes OpenGL more relevant through the iphone (well OpenGL ES, really).
If it's something usually done, do programmers usually create their own 3d engine "wrapper",
It's usually a full part of the engine design. Mind you, it's not abstracting the API at the same level, it's usually more at a "draw this with all its bells and whistles over there". Which rendering algorithm to apply on that draw tends to be back-end specific.
This, however, is very game engine dependent. If you want to understand better, you could look at UE3, it just got released free (beer) for non-commercial use (I have not looked at it yet, so I don't know if they exposed the backends, but it's worth a look).
To get back to my comment that game engine does not just mean 3D, look at this.
I think the primary benefit of using OpenGL over DirectX is the portability. DirectX only runs on windows. However, this is often not a problem (many games only run on Windows).
DirectX also provides other libraries which are useful for games which are unrelated to graphics such as sound and input. I believe there are equivalents which are often used with OpenGL but I don't think they're actually part of OpenGL itself.
If you're going to be locking into windows with DirectX and you are willing to/interested in learning C# and managed code, I have found XNA to be and extremely easy platform to learn. It allows you to learn most of the concepts without dealing with a lot of the really tricky details of DirectX (or OpenGL). You can still use shader code and have the full power of DirectX but in a much friendlier environment. It would be my recomendation but again, you'd have to switch to C# (mind you, you can also put that on you're resume).
You might want to look at some projects that encapsulate the low level 3d api in a higher level interface that is api independent such as Ogre3D. As you are doing this to learn I assume you probably will be more interesting in implementing the low level detail yourself, but you could probably learn a lot from such a project.
if you are really only interested in the rendering part, i can suggest ogre3d. it is clean, c++, tested and cross-platform. i used it in two projects and compared to other experiences (torque3d for example), i liked the good support (tutorials/wiki/forum) and the not so steep learning curve. i think someone can also learn a lot by looking at the sourcecode and the concepts they have used in the design. there is a accompanying book as well, which is a bit outdated, but it is good for the start
the problem with this is, you will be thinking inside this engine and soon you will need gameplay-like (timers, events) elements for simulating and testing your effects or whatever you want to do. so you will end up working around ogre3ds shortcomings (it is not a game engine) and implement in on your own or use another middleware.
so if you really want to touch 3d rendering first, i would take some computer graphics books (gpu gems, shaderx) and see some tutorials and demos on the web and start building my own basic framework. this is for the experience and i think you will learn the most from this approach. at least i did ...
I'm doing some OpenGL work right now (on both Windows and Mac).
Compared to my midnight game programming using the Unity3D engine, usingOpenGL is a bit like having to chop down your own trees to make a house versus buying the materials.
Unity3D runs on everything (Mac, PC and iPhone, Web player, etc) and lets you concentrate on the what makes a game, a game. To top it off, it's faster than anything I could write. You code for it in C#, Java (EDIT: make that JavaScript) or Boo. (EDIT: Boo support has been dropped)
I just used Unity to mock up a demo for a client who wants something made in OpenGL so it has it's real world uses also.
-Chris
PS: The Unity Indie version recently became free.