Ok well I want to hear you story of how you learned modern OpenGL if you learned it at all. Go ahead and post your story! I am excited to get reading!
1
How did you learn modern OpenGL?
Started by Riztro, May 16 2011 10:05 PM
15 replies to this topic
Sponsor:
#2 Members - Reputation: 840
Posted 16 May 2011 - 11:34 PM
Just started out the same way as everyone else with my first glBegin triangle, then picked up VBOs for speed, and shaders cause they sounded fun and cool. Really not much more to it than that.
Looking at the big picture the API is not really a big deal. Whether you're using ancient immediate mode opengl, modern DirectX/OpenGL with buffers and shaders, or something else, the underlying graphics theory is all the same. Once you understand the theory behind things, then the API is just a tool for you to use.
"Modern OpenGL" is just shader syntax and API calls, its the theory that's most important to understand.
Looking at the big picture the API is not really a big deal. Whether you're using ancient immediate mode opengl, modern DirectX/OpenGL with buffers and shaders, or something else, the underlying graphics theory is all the same. Once you understand the theory behind things, then the API is just a tool for you to use.
"Modern OpenGL" is just shader syntax and API calls, its the theory that's most important to understand.
My Projects:
Portfolio Map for Android - Free Visual Portfolio Tracker
Electron Flux for Android - Free Puzzle/Logic Game
Portfolio Map for Android - Free Visual Portfolio Tracker
Electron Flux for Android - Free Puzzle/Logic Game
#3 Members - Reputation: 692
Posted 17 May 2011 - 08:16 AM
well, in the beginning of this year I decided to port my "engine" to OGL 3.3 and it didn't go without problems. One thing I really disliked is you can't specify (in SDL 1.2) that you only want to get the OGL 3.3 profile, and because of this I had to use GLEW, and I have to check whether the function I'm using is proper core profile or deprecated. For this I use the official OGL 4.1 reference pages. However now that I have a solid set of functions for rendering I think I can start to use the modern features of OGL 3.3, the new functions, shader stuff etc. Because between 3.3 and 4.1 there is no such huge difference as between 2.1 and 3.3 (you can't use: immediate mode, matrix functions, GLU etc) I think moving to 4.1 will be seamless. I'm really looking forward to using tessellation and compute shaders for advanced effects.
#4 Members - Reputation: 785
Posted 17 May 2011 - 01:58 PM
well, in the beginning of this year I decided to port my "engine" to OGL 3.3 and it didn't go without problems. One thing I really disliked is you can't specify (in SDL 1.2) that you only want to get the OGL 3.3 profile, and because of this I had to use GLEW, and I have to check whether the function I'm using is proper core profile or deprecated. For this I use the official OGL 4.1 reference pages. However now that I have a solid set of functions for rendering I think I can start to use the modern features of OGL 3.3, the new functions, shader stuff etc. Because between 3.3 and 4.1 there is no such huge difference as between 2.1 and 3.3 (you can't use: immediate mode, matrix functions, GLU etc) I think moving to 4.1 will be seamless. I'm really looking forward to using tessellation and compute shaders for advanced effects.
Ya, SDL sucks. Try freeGLUT, although freeGLUT documentation sucks.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
#5 Members - Reputation: 217
Posted 17 May 2011 - 11:08 PM
Just started out the same way as everyone else with my first glBegin triangle, then picked up VBOs for speed, and shaders cause they sounded fun and cool. Really not much more to it than that.
Looking at the big picture the API is not really a big deal. Whether you're using ancient immediate mode opengl, modern DirectX/OpenGL with buffers and shaders, or something else, the underlying graphics theory is all the same. Once you understand the theory behind things, then the API is just a tool for you to use.
"Modern OpenGL" is just shader syntax and API calls, its the theory that's most important to understand.
What do you think the best resource for learning the theory is? Preferably not a book on theory as those can be very wordy and time consuming.
#6 Members - Reputation: 217
Posted 17 May 2011 - 11:10 PM
well, in the beginning of this year I decided to port my "engine" to OGL 3.3 and it didn't go without problems. One thing I really disliked is you can't specify (in SDL 1.2) that you only want to get the OGL 3.3 profile, and because of this I had to use GLEW, and I have to check whether the function I'm using is proper core profile or deprecated. For this I use the official OGL 4.1 reference pages. However now that I have a solid set of functions for rendering I think I can start to use the modern features of OGL 3.3, the new functions, shader stuff etc. Because between 3.3 and 4.1 there is no such huge difference as between 2.1 and 3.3 (you can't use: immediate mode, matrix functions, GLU etc) I think moving to 4.1 will be seamless. I'm really looking forward to using tessellation and compute shaders for advanced effects.
Well what I am wondering is, how do you move your objects around the scene? This is where I am currently stuck. I would like to use shaders for this but I do not know how. I have seen stuff where they call a "uniform" float in a shader then send the data in the c++ program to it. But I tried that and could compile my shader.
#7 Members - Reputation: 252
Posted 17 May 2011 - 11:58 PM
I use both immediate and VBO's in my 2D engine. The immediate mode I still use for rendering my user interface. It's easier to render rectangles, etc.. I do have plans to port them to VBO's in order to also be able to try out DirectX, but never came to it yet. The VBO's (or VB array's for those ancient systems) together with shaders I use for rendering the tiles and objects.
Transforming directly the OpenGL matrices in order to move the objects is one way, but you can also move objects using the shaders using the uniform data variables of shaders. You then only have to tranform the matrix in the shader. I found Lighthouse - uniform variables a good read about them.
Transforming directly the OpenGL matrices in order to move the objects is one way, but you can also move objects using the shaders using the uniform data variables of shaders. You then only have to tranform the matrix in the shader. I found Lighthouse - uniform variables a good read about them.
#8 Members - Reputation: 692
Posted 18 May 2011 - 01:05 PM
Well what I am wondering is, how do you move your objects around the scene? This is where I am currently stuck. I would like to use shaders for this but I do not know how. I have seen stuff where they call a "uniform" float in a shader then send the data in the c++ program to it. But I tried that and could compile my shader.
I have made a maths library called libmymath you can find it at libmymath.sf.net, I use it for handling maths (moving around stuff). To add you can find examples besides the libmymath packages.
You can also use GLM, or CML, or other maths library.
Well, the basic idea is to rotate, translate, scale your objects (scene) on the CPU side (with a maths library) and upload the computed matrices to your vertex shader and use it as a uniform.
In immediate mode you'd use glRotate glTranslate glScale etc.
You can find examples in the above mentioned libmymath library.
#9 Members - Reputation: 692
Posted 18 May 2011 - 01:07 PM
but you can also move objects using the shaders using the uniform data variables of shaders. You then only have to tranform the matrix in the shader.
it is NOT a good idea, because moving stuff around in the vertex shader would be a per-vertex operation, resulting in poor vertex processing performance.
see this post:
http://www.gamedev.n...light-position/
#10 Members - Reputation: 217
Posted 18 May 2011 - 04:39 PM
but you can also move objects using the shaders using the uniform data variables of shaders. You then only have to tranform the matrix in the shader.
it is NOT a good idea, because moving stuff around in the vertex shader would be a per-vertex operation, resulting in poor vertex processing performance.
see this post:
http://www.gamedev.n...light-position/
Well what I mean is, I am not going to put all the math into the shader, I will just pass in variables that will adjust it. I have seen something where they calculate an x and y offset then send them both as a vec2 to a shader then the shader just adds them to the vertex vec4.
#11 Members - Reputation: 252
Posted 19 May 2011 - 01:17 AM
but you can also move objects using the shaders using the uniform data variables of shaders. You then only have to tranform the matrix in the shader.
it is NOT a good idea, because moving stuff around in the vertex shader would be a per-vertex operation, resulting in poor vertex processing performance.
see this post:
http://www.gamedev.n...light-position/
In that post he mentions not to do per vertex operations on the CPU, but leave it to the GPU (thus in a shader). I haven't tried, but I do not think that there will be much performance loss when you transform a vertex by adding a pre-computed offset (e.g. by a physics engine) to it in the shader instead of setting the transform using (in OpenGL) glTransform.
#12 Members - Reputation: 217
Posted 19 May 2011 - 07:56 AM
but you can also move objects using the shaders using the uniform data variables of shaders. You then only have to tranform the matrix in the shader.
it is NOT a good idea, because moving stuff around in the vertex shader would be a per-vertex operation, resulting in poor vertex processing performance.
see this post:
http://www.gamedev.n...light-position/
In that post he mentions not to do per vertex operations on the CPU, but leave it to the GPU (thus in a shader). I haven't tried, but I do not think that there will be much performance loss when you transform a vertex by adding a pre-computed offset (e.g. by a physics engine) to it in the shader instead of setting the transform using (in OpenGL) glTransform.
Well now I just heard about matrices and multiplying them to the verts. It would kinda be like legacy GL but with your own matrices.
#13 Members - Reputation: 692
Posted 19 May 2011 - 09:39 AM
In that post he mentions not to do per vertex operations on the CPU, but leave it to the GPU (thus in a shader). I haven't tried, but I do not think that there will be much performance loss when you transform a vertex by adding a pre-computed offset (e.g. by a physics engine) to it in the shader instead of setting the transform using (in OpenGL) glTransform.
well, I only meant that it you think in massive scale (like a million polys) then it will probably be bad to do everything per-vertex.
#15 Members - Reputation: 785
Posted 19 May 2011 - 02:16 PM
Look at my link if you want matrix functions that look like GL.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
