Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 09 Jun 2013
Offline Last Active Jan 17 2015 02:32 PM

Posts I've Made

In Topic: Differences in setting point size in shader and main

17 December 2014 - 01:52 AM

I am using the Nvidia driver 340.84

In Topic: Differences in setting point size in shader and main

16 December 2014 - 07:04 PM

That the points become smaller if they are far away is intended. Dependend on the distance I use a smaller pointsize, therefore this is okay and I use glEnable(GL_PROGRAM_POINT_SIZE) when I am using the shader to set the point size.


But I agree with you that in my understanding of the spec the behaviour should be identical. Which means that in both cases the points should or should not vanish but not vanish in one case and dont vanish in the other one.

I am using a NVIDIA Quadro K2000, I have to look up the driver version tomorrow since I am not at my desktop at the moment.
I will let you know and thanks for making clear that it is probably a driver bug.

In Topic: Trying to do a simple point light shader in GLSL

26 September 2014 - 01:41 AM

you may want to have a look at this: http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/point-lights/
The names are a little different there because its OpenGL 3.3 and there you dont have gl_NormalMatrix and so on by default.
And the shader there also uses ambient and specular light but the basics for the diffuse part are what you want to do.
I am sorry right now I dont have the time to look
deeper into your problem. If nobody will tell you what exactly the problem is, I will look into this after work.


In Topic: Help: GL_QUADS Explanation

25 September 2014 - 02:49 AM

do you have backface culling activated?
Would look like:


GL_BACK is the initial value, therefore it dont have to appear in your code, but it would be good to know if you use "glEnable(GL_CULLFACE)".
I am asking this because even the second order of vertices should not give you the right result if backface culling is enabled and


is not used. glFrontFace sets the winding order of vertices in OpenGL and its default is GL_CCW. Therefore by default the order of vertices should be counter clockwise.
In your second example they are clockwise, which would mean that the quad is oriented away from the screen(viewer) and if backface culling is enabled you should not see anything. (backface culling means that only the front face is rendered and visible)
I think the right order should be as an example:


every other counter clockwise order is fine too.
Even if the quad is divided (which is the only way in modern opengl, where GL_QUADS is deprecated and deleted) in two triangles botth of them (0,1,2) and (2,3,0) have the right winding.

I have no clue why the first result is looking like this, but I dont found a specification how exactly GL_QUADS works.

What I would do is enable backface culling and then try it, because then you are learning it the right way and you dont have to struggle again when you need to use backface culling. And like DiegoSLTS suggests I would use triangles, because this is the way to go in OpenGL 3.0 and higher.

I know that were perhaps alot of information and I did not explain everything in depth, please feel free to ask.

In Topic: Major Rendering Problem - OpenGL and the Oculus Rift

02 May 2014 - 01:19 AM

I just took a glimpse into the code, first thing that attracted me was

int l_Major = glfwGetWindowAttrib(l_Window, GLFW_CONTEXT_VERSION_MAJOR);
int l_Minor = glfwGetWindowAttrib(l_Window, GLFW_CONTEXT_VERSION_MINOR);
int l_Profile = glfwGetWindowAttrib(l_Window, GLFW_OPENGL_PROFILE);
printf("OpenGL: %d.%d ", l_Major, l_Minor);

followed by:


According to the screenshot you are initializing glfw with opengl 4.4 (or glfw does that for you, look into "glfwWindoHint (GLFW_CONTEXT_VERSION_MAJOR /GLFW_CONTEX_VERSION_MINOR, x)" to set it manually), but "glBegin(GL_QUADS)" is removed since 3.3. I am not completly sure why it display something at all. But I would try to either a OpenGL Version where glBegin is not deprecated or removed or alter the program so that it is written in an OpenGL 3.3 (or newer) way.

Another thing is


I think there might be one ";" too many
the else case is not evaluated at all, otherwise you should have either one of those prints in your console. And it shows that the profile is not "GLFW_OPENGL_COMPAT_PROFILE".

I am not sure that this is the main problem but it is worth to give it a try.
Hope that this helps a little bit, otherwise please ask.