The Secret that is OpenGL - Getting Started/Resources
Moderator: Coders of Rage
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
The Secret that is OpenGL - Getting Started/Resources
I can't help but be a little frustrated when the only highly recommended book on OpenGL essentially tells me to use their own "tools" instead of actually teaching me OpenGL. It may as well open up and say, "Well, here's a book on OpenGL, and by 'OpenGL' I mean a game engine I built in OpenGL." Is it impossible to find a book that ACTUALLY teaches me all I need to know about OpenGL, without being impossible to understand? I'm not going to bother learning their personal library and then have a bunch of useless knowledge. I think I posted before about how I was considering learning DirectX, but I'm concerned about becoming dependent on one company.
Why can't I find a normal comprehensive book teaching OpenGL? Is Microsoft paying these writers to keep everything about OpenGL a secret?
How did you guys learn about OpenGL? (Aside from the fact that you're geniuses and can probably pick up on something just by looking at it for long enough?)
Thanks guys. Sorry about revisiting this topic.
-Benjamin
Why can't I find a normal comprehensive book teaching OpenGL? Is Microsoft paying these writers to keep everything about OpenGL a secret?
How did you guys learn about OpenGL? (Aside from the fact that you're geniuses and can probably pick up on something just by looking at it for long enough?)
Thanks guys. Sorry about revisiting this topic.
-Benjamin
-
- Respected Programmer
- Posts: 387
- Joined: Fri Dec 19, 2008 3:33 pm
- Location: Dallas
- Contact:
Re: The Secret that is OpenGL
You might find it more difficult to find good DX books :D
The reason being is that MSDN is already VERY comprehensive. I think what you need, and I recommend this to EVERYBODY, is an API-agnostic graphics text. The reason you don't find many OpenGL books is similar to why you don't find many DX books. They're both extremely thoroughly documented. The OpenGL specification is totally documented over there on Khronos's site.
What you need is a graphics text, not a DX/GL text. The API's (no matter which one you choose), will be much much more clear when you understand some graphics principles. For beginners, I recommend "Computer Graphics using OpenGL" by F.S Hill. It's a college text and is a little old, but it's a DAMN good fundamental reference that will teach you not only "how?", but "why?". "Real Time Rendering" is also a classic series by Moller/Haines. "Computer Graphics" (The VanDam/Feiner/Foley/Hughes text) is a classic reference but is more advanced. The GPU Gems series is also great, but again it is also more advanced. These are all API-agnostic text's....so you may see DX and/or GL and a mix of shader languages.
There's no secret....but you need to understand graphics to understand the API. The API is just documentation.
The reason being is that MSDN is already VERY comprehensive. I think what you need, and I recommend this to EVERYBODY, is an API-agnostic graphics text. The reason you don't find many OpenGL books is similar to why you don't find many DX books. They're both extremely thoroughly documented. The OpenGL specification is totally documented over there on Khronos's site.
What you need is a graphics text, not a DX/GL text. The API's (no matter which one you choose), will be much much more clear when you understand some graphics principles. For beginners, I recommend "Computer Graphics using OpenGL" by F.S Hill. It's a college text and is a little old, but it's a DAMN good fundamental reference that will teach you not only "how?", but "why?". "Real Time Rendering" is also a classic series by Moller/Haines. "Computer Graphics" (The VanDam/Feiner/Foley/Hughes text) is a classic reference but is more advanced. The GPU Gems series is also great, but again it is also more advanced. These are all API-agnostic text's....so you may see DX and/or GL and a mix of shader languages.
There's no secret....but you need to understand graphics to understand the API. The API is just documentation.
- bbguimaraes
- Chaos Rift Junior
- Posts: 294
- Joined: Wed Apr 11, 2012 4:34 pm
- Programming Language of Choice: c++
- Location: Brazil
- Contact:
Re: The Secret that is OpenGL
True. In college, I had a Computer Graphics teacher that would divide the class in half: first he explained the concepts, using a whiteboard (and sometimes pens and other weird objects), then he showed us how to do that in OpenGL.
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
Re: The Secret that is OpenGL
Ok. Thanks.
I'll take a look at that text book.
I'll take a look at that text book.
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
Re: The Secret that is OpenGL
I've read through some of "Real-Time Rendering".
Still not sure I understand it. It is all hard to understand. I see the pipeline, which breaks down into other steps, which breaks down into other steps. But that doesn't really help. I still can't figure out how to use OpenGL to do anything.
Do I have to understand GLSL?
How do I use GLSL with OpenGL and C++?
What exactly is the OpenGL context? The definition given is vague and doesn't explain anything.
And how do I use shaders?
How do I get something onto the screen?
What is GLuint?
Why are most of the parameters using terms that I don't understand?
Why does glVertexAttribPointer come up as "identifier not found", while other functions of OpenGL don't have that problem?
How does glut come into this? Why can't I figure out how to use modern OpenGL with glut?
Where do people learn how to use Modern OpenGL?
EDITED.
Still not sure I understand it. It is all hard to understand. I see the pipeline, which breaks down into other steps, which breaks down into other steps. But that doesn't really help. I still can't figure out how to use OpenGL to do anything.
Do I have to understand GLSL?
How do I use GLSL with OpenGL and C++?
What exactly is the OpenGL context? The definition given is vague and doesn't explain anything.
And how do I use shaders?
How do I get something onto the screen?
What is GLuint?
Why are most of the parameters using terms that I don't understand?
Why does glVertexAttribPointer come up as "identifier not found", while other functions of OpenGL don't have that problem?
How does glut come into this? Why can't I figure out how to use modern OpenGL with glut?
Where do people learn how to use Modern OpenGL?
EDITED.
-
- Chaos Rift Junior
- Posts: 272
- Joined: Wed Sep 29, 2004 5:53 pm
- Favorite Gaming Platforms: NES, SNES
- Programming Language of Choice: C/C++
- Location: Umeå, Sweden
- Contact:
Re: The Secret that is OpenGL
I'd recommend checking out the Nehe tutorials. They're great for learning the basics.
-
- Respected Programmer
- Posts: 387
- Joined: Fri Dec 19, 2008 3:33 pm
- Location: Dallas
- Contact:
Re: The Secret that is OpenGL
Technically, no. OpenGL versioning, to be frank, is atrocious. The core specification is defined but not always enforced. OpenGL is implemented by the driver which is supplied by the vendor. Despite many functions and extensions being deprecated, the driver is still free to implement them. So the versioning is a little misleading, but you should try to adhere to it.Do I have to understand GLSL?
For example, if you want to build against OpenGL 4.0, you must know GLSL. Fixed function programming does not exist there. However, if you wanted to mix in older functionality, you should be just fine.
OpenGL is just extremely terrible with this. The versioning is horrendously wonky. There's no unification there.
GLSL is a programming language itself. It shares much of C's syntax but has special keywords and constructs that the GLSL parser understands. You simply write plain GLSL text into a file, read it in, parse and compile (GL has functions for this), and the compiled binary is uploaded to the device as an executable program. Vertex programs execute for every vertex, fragment programs execute for every fragment, and so on...How do I use GLSL with OpenGL and C++?
The context is simply the OS's way of addressing the OpenGL subsystem part of your device. It is a bridge between the OS and the OpenGL device itself. Linux has it's own methods of initializing an OpenGL context, OSX, Win32, etc...What exactly is the OpenGL context? The definition given is vague and doesn't explain anything.
Think of them as small programs (that's really what they are). They execute on the GPU for all of its vertex processors (vertex shaders), and compute cores (fragment shaders, domain, hull, and general computing). Every time a vertex comes in, it runs through that vertex program. After it's compiled, you get a handle to it...like every asset in OpenGL. You then bind it as current before you render...then you render. Then you unbind it. Read more about shader states.And how do I use shaders?
If getting something on the screen is your only goal, as stated before, go to NeHe.How do I get something onto the screen?
It is a typedef for the standard "unsigned int" type. Promotes code portability.What is GLuint?
Because you've just started. For the most part the terms in the text should match up with the API implementation. You might be underestimating what it really takes to fully understand graphics intimately in terms of your education. Many of the concepts are high level, but getting something rendering should not be terribly difficult. Again..what is it that you want? Do you just want pretty triangles on the screen or do you really want to understand what the heck is going on?Why are most of the parameters using terms that I don't understand?
Windows has not supported OpenGL as part of the OS for a number of years now. Even before that it was not regularly updated, therefore much of the NEW functionality is implemented as an "extension" to the core specification. It will not be defined in gl.h, because that header file is probably over 10 years old. You will see it in glext.h. However, you'll see that it's defined as a function pointer, therefore you must use "wgl" (Windows's OpenGL) to obtain the address of that function's implementation before you can use it.Why does glVertexAttribPointer come up as "identifier not found", while other functions of OpenGL don't have that problem?
GLEW is a library that makes this much easier for you.
How does glut come into this? Why can't I figure out how to use modern OpenGL with glut?
GLUT is extremely old and is also not updated and hasn't been for several years. GLUT has nothing to do with OpenGL and is a "utility library" that is auxiliary to OpenGL itself. It's just a helper.
Consume every resource you can. Challenge yourself to write things that you don't think you can write. Do the hard things. Go to forums, chats, etc. The info is definitely out there. Again, you're still new.Where do people learn how to use Modern OpenGL?
- DistortedLance
- Chaos Rift Newbie
- Posts: 26
- Joined: Fri Jul 22, 2011 12:36 pm
- Favorite Gaming Platforms: PC
- Programming Language of Choice: C++
- Contact:
Re: The Secret that is OpenGL
There are several useful (though somewhat annoying to find) resources on learning modern OpenGL (that is, using vertex array objects and shaders without any of the fixed functional pipeline) if you're only interested in the newer stuff - support is pretty ubiquitous, considering OpenGL 2.1 with some extensions isn't too hard to find.
Intro to Modern OpenGL (I really like this one :D)
Arcsynthesis
Modern OpenGL Wikibooks (and this one)
Also, the OpenGL wiki is a fantastic resource with plenty of documentation, tutorials, etc. to help with the process (and it even marks required extensions and deprecated functionality in case you're worried about that). I can't say much about NeHe's tutorials, but I've heard they're fine (be warned that they're rather focused on older OpenGL, or so they were the last time I checked. It might have changed since then).
I highly recommend using something other than GLUT to initialize your window, context, etc. It's rather obsolete nowadays - using OpenGL with SFML or SDL is much simpler, more streamlined, and more powerful. If you're really just interested in getting stuff on the screen, FreeGLUT is a nice alternative.
Intro to Modern OpenGL (I really like this one :D)
Arcsynthesis
Modern OpenGL Wikibooks (and this one)
Also, the OpenGL wiki is a fantastic resource with plenty of documentation, tutorials, etc. to help with the process (and it even marks required extensions and deprecated functionality in case you're worried about that). I can't say much about NeHe's tutorials, but I've heard they're fine (be warned that they're rather focused on older OpenGL, or so they were the last time I checked. It might have changed since then).
I highly recommend using something other than GLUT to initialize your window, context, etc. It's rather obsolete nowadays - using OpenGL with SFML or SDL is much simpler, more streamlined, and more powerful. If you're really just interested in getting stuff on the screen, FreeGLUT is a nice alternative.
- Falco Girgis
- Elysian Shadows Team
- Posts: 10294
- Joined: Thu May 20, 2004 2:04 pm
- Current Project: Elysian Shadows
- Favorite Gaming Platforms: Dreamcast, SNES, NES
- Programming Language of Choice: C/++
- Location: Studio Vorbis, AL
- Contact:
Re: The Secret that is OpenGL
This topic went from eyerollingly vague to useful and completely awesome. I'm going to sticky this as a resource. Thanks to everyone who has contributed so far, and good luck to the OP.
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
Re: The Secret that is OpenGL - Getting Started/Resources
Thanks everyone. I'll keep up the research.
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
Re: The Secret that is OpenGL - Getting Started/Resources
So would it be a bad idea to use the old OpenGL? I mean, is it still used professionally by anybody?
-
- Respected Programmer
- Posts: 387
- Joined: Fri Dec 19, 2008 3:33 pm
- Location: Dallas
- Contact:
Re: The Secret that is OpenGL - Getting Started/Resources
No, it wouldn't necessarily be a bad idea. There are machines in medical, simulations, and in professional settings that still run OpenGL code from 10+ years ago. You're not going to see support for "old OpenGL" evaporate because then you'd have a huge uproar from folks who run legacy code. You won't see it disappear from the driver either. This is why the spec is such crap. I would take it as a suggestion, not a rule.Benjamin100 wrote:So would it be a bad idea to use the old OpenGL? I mean, is it still used professionally by anybody?
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
Re: The Secret that is OpenGL - Getting Started/Resources
I'm still a little confused at what I would want to use the projection matrix for.
- Falco Girgis
- Elysian Shadows Team
- Posts: 10294
- Joined: Thu May 20, 2004 2:04 pm
- Current Project: Elysian Shadows
- Favorite Gaming Platforms: Dreamcast, SNES, NES
- Programming Language of Choice: C/++
- Location: Studio Vorbis, AL
- Contact:
Re: The Secret that is OpenGL - Getting Started/Resources
It's for defining viewing coordinates, perspective, and the bounding volume of the viewport.Benjamin100 wrote:I'm still a little confused at what I would want to use the projection matrix for.
When you set up an orthographic projection or use gluPerspective, you are actually setting this matrix up behind the scenes.
It is the matrix that transforms your geometry from world coordinates to screen coordinates.
-
- ES Beta Backer
- Posts: 250
- Joined: Tue Jul 19, 2011 9:37 pm
Re: The Secret that is OpenGL - Getting Started/Resources
OK,
I understand the pipeline a little better now, but I am trying to use it.
I've got a vertex shader and a fragment shader and a program object.
Now I just need to put in my vertex array.
From what I understand, I need to create a vertex array object
and I need to have a vertex buffer object.
How do I make a vertex buffer object, and where do I put my array of vertices that I want to use?
Thank,
Benjamin
EDIT: Now I have a triangle on the screen, (used "glBufferData" with my array of vertices.)
It seems to be working, except for the vertex shader and fragment shader. I even commented them out and it made no difference in the appearance. Do they have to be compiled inside the loop? (Using GLUT) Does "glUseProgram" have to be in the loop? Is it only "glDrawArrays" that has to be in the loop?
Thanks,
Benjamin
I understand the pipeline a little better now, but I am trying to use it.
I've got a vertex shader and a fragment shader and a program object.
Now I just need to put in my vertex array.
From what I understand, I need to create a vertex array object
and I need to have a vertex buffer object.
How do I make a vertex buffer object, and where do I put my array of vertices that I want to use?
Thank,
Benjamin
EDIT: Now I have a triangle on the screen, (used "glBufferData" with my array of vertices.)
It seems to be working, except for the vertex shader and fragment shader. I even commented them out and it made no difference in the appearance. Do they have to be compiled inside the loop? (Using GLUT) Does "glUseProgram" have to be in the loop? Is it only "glDrawArrays" that has to be in the loop?
Thanks,
Benjamin