**1**

# How did you learn modern OpenGL?

###
#2
Members - Reputation: **840**

Posted 16 May 2011 - 11:34 PM

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.

Portfolio Map for Android - Free Visual Portfolio Tracker

Electron Flux for Android - Free Puzzle/Logic Game

###
#3
Members - Reputation: **1527**

Posted 17 May 2011 - 08:16 AM

Blog:

http://extremeistan.wordpress.com/

Stuff I wrote:

https://github.com/Yours3lf/libmymath

https://github.com/Yours3lf/linux_gl_fps

https://github.com/Yours3lf/instanced_font_rendering

https://github.com/scrawl/smaa-opengl

https://github.com/Yours3lf/gl_browser_gui

Follow me on twitter:

###
#4
Members - Reputation: **809**

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.

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: **240**

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: **240**

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: **281**

Posted 17 May 2011 - 11:58 PM

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

Github: https://github.com/crafter2d/crafter2d

Twitter: @crafter_2d

###
#8
Members - Reputation: **1527**

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.

Blog:

http://extremeistan.wordpress.com/

Stuff I wrote:

https://github.com/Yours3lf/libmymath

https://github.com/Yours3lf/linux_gl_fps

https://github.com/Yours3lf/instanced_font_rendering

https://github.com/scrawl/smaa-opengl

https://github.com/Yours3lf/gl_browser_gui

Follow me on twitter:

###
#9
Members - Reputation: **1527**

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/

Blog:

http://extremeistan.wordpress.com/

Stuff I wrote:

https://github.com/Yours3lf/libmymath

https://github.com/Yours3lf/linux_gl_fps

https://github.com/Yours3lf/instanced_font_rendering

https://github.com/scrawl/smaa-opengl

https://github.com/Yours3lf/gl_browser_gui

Follow me on twitter:

###
#10
Members - Reputation: **240**

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: **281**

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

Github: https://github.com/crafter2d/crafter2d

Twitter: @crafter_2d

###
#12
Members - Reputation: **240**

Posted 19 May 2011 - 07:56 AM

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: **1527**

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.

Blog:

http://extremeistan.wordpress.com/

Stuff I wrote:

https://github.com/Yours3lf/libmymath

https://github.com/Yours3lf/linux_gl_fps

https://github.com/Yours3lf/instanced_font_rendering

https://github.com/scrawl/smaa-opengl

https://github.com/Yours3lf/gl_browser_gui

Follow me on twitter:

###
#14
Members - Reputation: **1527**

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.

Blog:

http://extremeistan.wordpress.com/

Stuff I wrote:

https://github.com/Yours3lf/libmymath

https://github.com/Yours3lf/linux_gl_fps

https://github.com/Yours3lf/instanced_font_rendering

https://github.com/scrawl/smaa-opengl

https://github.com/Yours3lf/gl_browser_gui

Follow me on twitter:

###
#15
Members - Reputation: **809**

Posted 19 May 2011 - 02:16 PM

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
Members - Reputation: **1527**

Posted 21 May 2011 - 05:07 AM

Blog:

http://extremeistan.wordpress.com/

Stuff I wrote:

https://github.com/Yours3lf/libmymath

https://github.com/Yours3lf/linux_gl_fps

https://github.com/Yours3lf/instanced_font_rendering

https://github.com/scrawl/smaa-opengl

https://github.com/Yours3lf/gl_browser_gui

Follow me on twitter: