PDA

View Full Version : How to begin with openGL with no previous API background?



curious
07-28-2015, 05:50 AM
So, I recently have been introduced to APIs and the first one is this OPENGL. It is very difficult to collect info and get started immediately. Also each tutorial just begins with an example and its very difficult to get along. Found a few references on the internet and I am not sure should I go on with it or not.

So here's the real question: How to begin with opengl so as to grasp everything clearly? I am a good programmer but have never worked with any APIs at all. I just worked with basic programming libraries. I am a total noob with graphics as well.:doh:

Dark Photon
07-28-2015, 06:43 AM
If you've worked with basic programming libraries, then you've used APIs -- the APIs those libraries present.

Before we address how do you learn OpenGL, let's instead ask what do you want to "do" with OpenGL? That's going to drive the answer to your question.

curious
07-28-2015, 08:25 PM
If you've worked with basic programming libraries, then you've used APIs -- the APIs those libraries present.

Before we address how do you learn OpenGL, let's instead ask what do you want to "do" with OpenGL? That's going to drive the answer to your question.

I would like to render graphics for games basically and if anything else interesting comes up along the way then that as well.

Right now the basic line drawing algorithms(DDA and Bresenham's) are not comprehensible for me. This is where I would like to begin. The very basic of the implementations.

mynameisjohn
07-28-2015, 08:42 PM
This may be bad advice, but from one beginner to another, you may want to hold off on OpenGL till you feel you have a solid grasp on graphics fundamentals. When I say that I don't necessarily mean things like Bresenham's algorithm, but I do mean things like homogeneous transforms, perspective and orthographic projection, texture maps, barycentric coords, etc.

If you're interested in learning about the algorithms you mentioned, you may end up getting bogged down with just setting up OpenGL and lose sight of what you're doing. What you really want to do is draw a line between two points, so why not learn how to generate a pixel buffer (using straight C or C++ code) and fill in some pixels to draw your lines? That will teach you about color formats, how images are laid out in memory, etc. Once you've got that down, you can work on rendering your image into a frame buffer or a texture and displaying it with OpenGL.

In my experience, you don't feel like you're getting anywhere with OpenGL until you understand where your data is and how it's being managed. It requires both a low level knowledge of the graphics pipeline and a high level knowledge of the graphics transforms used to get your geometry on the screen. Until you feel confident with that stuff and the OpenGL calls involved you often feel like you're just copying and pasting around black boxes that somehow work, which isn't very educational. Unfortunately getting that understanding takes (or took me, at least) quite some time, as well as quite of lot of copying and pasting other peoples' code...

Of course, I could be wrong and you may be some kind of pro, but if you want the freedom to experiment with concepts it may take you more time than you thought to get OpenGL to give you that freedom. At the end of the day, my advice to you is to simultaneously pursue both a conceptual understanding of computer graphics and a concrete understanding of how OpenGL takes data from your ram and displays it on the screen.

curious
07-28-2015, 09:13 PM
This may be bad advice, but from one beginner to another, you may want to hold off on OpenGL till you feel you have a solid grasp on graphics fundamentals. When I say that I don't necessarily mean things like Bresenham's algorithm, but I do mean things like homogeneous transforms, perspective and orthographic projection, texture maps, barycentric coords, etc.

If you're interested in learning about the algorithms you mentioned, you may end up getting bogged down with just setting up OpenGL and lose sight of what you're doing. What you really want to do is draw a line between two points, so why not learn how to generate a pixel buffer (using straight C or C++ code) and fill in some pixels to draw your lines? That will teach you about color formats, how images are laid out in memory, etc. Once you've got that down, you can work on rendering your image into a frame buffer or a texture and displaying it with OpenGL.

In my experience, you don't feel like you're getting anywhere with OpenGL until you understand where your data is and how it's being managed. It requires both a low level knowledge of the graphics pipeline and a high level knowledge of the graphics transforms used to get your geometry on the screen. Until you feel confident with that stuff and the OpenGL calls involved you often feel like you're just copying and pasting around black boxes that somehow work, which isn't very educational. Unfortunately getting that understanding takes (or took me, at least) quite some time, as well as quite of lot of copying and pasting other peoples' code...

Of course, I could be wrong and you may be some kind of pro, but if you want the freedom to experiment with concepts it may take you more time than you thought to get OpenGL to give you that freedom. At the end of the day, my advice to you is to simultaneously pursue both a conceptual understanding of computer graphics and a concrete understanding of how OpenGL takes data from your ram and displays it on the screen.

So I should first familiarize with graphics.h and like libraries?

GClements
07-29-2015, 06:38 AM
So I should first familiarize with graphics.h and like libraries?
Classical 2D graphics algorithms in the style of graphics.h have little in common with OpenGL.

Most modern 2D graphics APIs (the model used by PostScript, PDF, SVG, OpenVG, cairo, HTML 5 canvas etc) are closer to OpenGL than to graphics.h.

In particular, Bresenham's algorithm is largely of historical interest. A key feature is that it only requires integer arithmetic. Once upon a time that mattered, nowadays it doesn't (the first generation of programmable GPUs used floating-point almost exclusively; integer support came later).

If you want to learn about 3D (or modern 2D) graphics, forget about stuff like graphics.h and start with linear algebra, homogeneous coordinates, barycentric coordinates, etc.

curious
07-29-2015, 11:32 PM
If you want to learn about 3D (or modern 2D) graphics, forget about stuff like graphics.h and start with linear algebra, homogeneous coordinates, barycentric coordinates, etc.

Any references?