Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jun 2013
Offline Last Active Feb 05 2016 02:52 AM

Topics I've Started

wglMakeCurrent returns TRUE but seems to fail

05 October 2015 - 09:08 AM

Hello everyone,
I have a strange problem. I have an application (3d viewer) which uses OpenGl in 2 threads but has only 1 opengl context. It switches the context between the threads via wglMakeCurrent(HDC, HGLRC) and wglMakeCurrent(nullptr, nullptr). In general this works. But with one special dataset in a special situation wglMakeCurrent(HDC, HGLRC) returns TRUE but after that every OpenGL call is ignored (even the ones directly after wglMakeCurrent).
- GetLastError() returns 0 before and after the call.

- OpenGLDebug context does not give a hint (which is expected since the context seems to be out of order).
- GetCurrentContext returns expected values.
- glGetError returns 0

For debug purposes I do

int i = 0;
glGetIntegerv(GL_MAX_DRAW_BUFFERS, &i);
ASSERT(i != 0);

after the context is out of order this assert fails.
I also logged the context switches and they seem to be correct, the context is bound to zero or one thread (which will do the next calls to OpenGL) at a time.
I have no clue what I could try next, what could be the reason for this behavior.
I use a Quadro K2000 with a 354.13 driver.

Every hint is appreciated.



Differences in setting point size in shader and main

16 December 2014 - 06:11 AM

Hello everybody,
at the moment I am trying to set the point size depending on a zoom level in my OpenGL 3.3 viewer. I found that in my environment there is a difference between using glPontSize in the C++ program and using gl_PointSize in the vertex shader.

When I zoom out the pointsize value gets small, in both cases (I compute the value myself and use the same one in both cases).
In the shader case, the points vanishes at some point due to the small point size I guess (or maybe fading is involved too).
If I set the point size in the main program using glPointSize, the point never vanish completely, I guess it always has a one pixel width.


I wonder what is the reason for this difference. I tried to use multi sampling as well, but in the case of not using the shader I never achieved that the point vanishes completely.


In the OpenGL 3.3 spec in my understanding there is no statement that would indicate that behaviour.
Does anyone has a hint what both cases do internally or can me explain what the difference really is?



Theory of Light Propagation Volumes in Detail

03 October 2013 - 03:57 PM

Ok, I work with Light Propagation Volumes at the moment, there are some things in the theory I dont know how to implement them correct.
This is from http://blog.blackhc.net/wp-content/uploads/2010/07/lpv-annotations.pdf

Lets start with the Reflective Shadow Map and the flux which should be stored in it.
I have a "directional" light source with an arbitrary light Color, a total incoming flux, diffuse material color , width and height of the reflective shadow map texture and an angle theta  between the light direction and the normal.

My flux for this surfel of the map then should be:
fluxOut=diffuse material Color * 1/6 *1/(rsmWidth*rsmHeight)* total flux*cos (theta)

The Injection of light then is, just take the flux and divide it by Pi. for every surfel of the reflective shadow map and add up the values in the appropriate cell of the light volume. Then you have an intensity function in each cell .

Ok now we have the occlusion injection or in my case 2, one from the reflective shadow map and one from the gbuffer.
In the paper above I believe there is onle the injection from the refelective shadow map described, the formula there is
surfelArea= 4.0*distance*distance/(rsmWidth*rsmHeight), distance means the distance from the light source to the object this is clear since the area will grow with the square of the distance but where does the 4 came from??
And for the GBuffer injection I also think about what is the right way to do it. The difference is that one is a orthographic projection and one a perspective (Gbuffer).


Propagation is clear to me,

I compute which amount of flux came from which face of the 6 neighbour cells and reproject this amount and divide it by Pi to get an intensity.
This is just the short version but as I said this is clear to me.

Now I have the volume with the propagated light and now I want to use it for rendering the indirect light into the scene.

Question here is, I have intenstity(I) functions in my volumes and what I need for rendering is the radiance(L).

The function is: L= I/A, so I need either the area of the Fragment or whatever I am just rendering or i can use the intensity to compute the irradiance E: E=I/r².  The LPV paper from crytek says that the are using half the cellsize as r so then I can came up with the irradiance but what I have then to do? I mean L=E/w (w the solid angle, but what is the solid angle in that case)?


If someone has some explanations I would appreciate it, or if some one has questions regarding the described theory feel free to ask.

Problem with Cascaded Light Propagation Volumes

07 September 2013 - 07:26 AM


at the moment I work on implementing cascades for my Light Propagation Volumes implementation and I always have "problems" with the different cell sizes and the results produced by this.
First a picture of the Problem ( I only draw indirect light here, the bottom plane is white and the light Comes from straight above):


As you can see the 3 different cascades are clearly visible, and now a picture where I draw spheres for each cell shaded with the spherical harmonic of this cell (of the cascade with the smallest cells and the one with the biggest cells) :


Here you can see where the problem is, in both displayed cascades the light comes from straight above and therefore the cells near to the bottom are the brightest, thats fine. (The blue line is the bounding box of the cascade with the smallest cell size)
And in both cascades the first 1- 3 or 4 levels of cells (from bottom to top) are receiving a considerable amount of light. The problem is that the cell size is different and therefore in the end with greater cell size the light seems to travell much further than with small cells and this is the problem.


To me this problem is clear and I really have no idea how to really solve this. In the papers about cascaded light propgation volumes, they dont seem to have this problem or because of the fact that usually the center of all cascades is centered around the camera (with some offset sometimes) it might not as obvious but I dont really believe that, they must do something different.
Another way would be to use the cellsize in the propagation of light and try it with a quadratic or some kind of falloff, but even the you would see a difference just because of the different positions of the brightest cells.
My feeling is that there is no really solution, just some fixes which makes this a little bit smoother like Interpolation between cascade borders.

So far I tried to handle each cascade independently and in another approach I even propagate light between cascades which is a little bit better but the described problem is in both cases clearly visible.

If some one has any thoughts or ideas I would really appreciate it.
Thank you



Write to Texture3D, gl_Layer problem

25 June 2013 - 01:11 PM

I have a problem with writing into an other layer than gl_Layer 0, with an 3d Texture attached to my FBO: Here is my code for the texture and FBO generation:


glGenTextures(1, &tex3DLVRed);
glBindTexture(GL_TEXTURE_3D, tex3DLVRed);
glTexImage3D(GL_TEXTURE_3D, 0, GL_RGBA32F, 32, 32, 32, 0, GL_RGBA, GL_FLOAT, 0);
glBindTexture(GL_TEXTURE_3D, 0);

glGenFramebuffers(1, &fboLightInject);
glBindFramebuffer(GL_FRAMEBUFFER, fboLightInject);

glBindFramebufferEXT(GL_FRAMEBUFFER, 0);

My display routine looks like:

glViewport(0, 0, 32, 32);
glClearColor(0.f, 0.f, 0.f, 0.f);           
glBindFramebuffer(GL_FRAMEBUFFER, fboLightInject);

My geometry shader looks like this:

#version 330
layout(points) in;
layout(points, max_vertices = 1) out;

void main() 
	gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
	gl_Layer = 1;

with gl_Layer=0, it works but when I use some other value, for example 1 it does not produce any output. In the Fragment shader I just assign red color for debug purposes.


It would be great if anybody comes up with an idea what to try or where my failure is.

I have an example program which works, therefore I am sure that my hardware is ready for this. but the example is such a complex program that I seem to overlook important instructions.


Thank you