Jump to content

  • Log In with Google      Sign In   
  • Create Account


How did you learn modern OpenGL?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 Riztro   Members   -  Reputation: 240

Like
0Likes
Like

Posted 16 May 2011 - 10:05 PM

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!

Sponsor:

#2 karwosts   Members   -  Reputation: 836

Like
-2Likes
Like

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.
My Projects:
Portfolio Map for Android - Free Visual Portfolio Tracker
Electron Flux for Android - Free Puzzle/Logic Game

#3 Yours3!f   Members   -  Reputation: 1299

Like
0Likes
Like

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 V-man   Members   -  Reputation: 805

Like
0Likes
Like

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);

#5 Riztro   Members   -  Reputation: 240

Like
-1Likes
Like

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 Riztro   Members   -  Reputation: 240

Like
0Likes
Like

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 jeroenb   Members   -  Reputation: 257

Like
0Likes
Like

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.

Crafter 2D: the open source 2D game framework

Blog: Crafter 2D
Twitter: @crafter_2d


#8 Yours3!f   Members   -  Reputation: 1299

Like
0Likes
Like

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 Yours3!f   Members   -  Reputation: 1299

Like
0Likes
Like

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 Riztro   Members   -  Reputation: 240

Like
0Likes
Like

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 jeroenb   Members   -  Reputation: 257

Like
0Likes
Like

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.

Crafter 2D: the open source 2D game framework

Blog: Crafter 2D
Twitter: @crafter_2d


#12 Riztro   Members   -  Reputation: 240

Like
0Likes
Like

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 Yours3!f   Members   -  Reputation: 1299

Like
0Likes
Like

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.

#14 Yours3!f   Members   -  Reputation: 1299

Like
0Likes
Like

Posted 19 May 2011 - 09:41 AM

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.


maths libraries are like legacy GL, but they're (supposed to be) faster than the GL functions.

#15 V-man   Members   -  Reputation: 805

Like
0Likes
Like

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);

#16 Yours3!f   Members   -  Reputation: 1299

Like
0Likes
Like

Posted 21 May 2011 - 05:07 AM

looks nice :)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS