Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: View Space Light Position Moving...

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Dec 2007
    Posts
    20

    View Space Light Position Moving...

    Hate to have to post about this, but every post I have found on this exact problem either the talk trailed off or the person never said how they fixed it.
    Im doing deferred lighting in view space, constructing view space position from standard 24bit depth (/stencil) buffer texture. Im setting the model view matrix to just a viewing matrix, reading it back, and multiplying my lights world direction and position with it before passing it to the shader.
    All the lighting looks correct (when not moving, every is correct, relative to walls floor, each other, etc), but when the camera moves, towards the edge of the screen, you can see the lights position moves in the opposite direction the camera moves, its pretty much 1:1. If I strafe left, the lights go right, if I go down, they go up. If I rotate the view, they seem to rotate in the opposite direction.
    Im pretty sure everything is in the correct space or the spot lights wouldnt be pointed correctly, and the point lights wouldnt be where I want them to be (when not moving), theres just this side effect when I move, and I cant figure where else I should be looking.
    Ive been pulling my hair out trying to figure what is causing it any help would be appreciated.

  2. #2
    Intern Contributor
    Join Date
    Jan 2010
    Posts
    82

    Re: View Space Light Position Moving...

    when the camera moves, towards the edge of the screen, you can see the lights position moves in the opposite direction the camera moves, its pretty much 1:1. If I strafe left, the lights go right, if I go down, they go up. If I rotate the view, they seem to rotate in the opposite direction.
    There's something wrong when you dot(-light_dir.xyz, light_spot_dir). Are you sure they are in the correct space especially light_spot_dir?

    I just did a test and made a mistake of not making sure all the vectors needed were in view space. I easily made the mistake because I usually do my stuff in world space.

    When I made the mistake it was because I did not make make sure that the light_spot_dir was in view space as well. So because of that I ended up with the same problem you are having.

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,184

    Re: View Space Light Position Moving...

    Sounds like ravage has got you covered.

    What might help (rather than just looking at whacky lighting results and trying to infer from that) is to render a point/sphere/vector/cone/etc. at the position of the light sources. That'll tell you if your world-space positions (and directions, if you render a vector or a cone for the direction too) for them are correct. If not, look backwards (in how you compute those positions/directions). If so, look forwards (i.e. not transforming position and direction to eye-space properly)/.

  4. #4
    Junior Member Newbie
    Join Date
    Dec 2007
    Posts
    20

    Re: View Space Light Position Moving...

    It seems the spaces are correct, I transform the point light position as a point using the 4x4 view matrix (set with look at and read right back) so it gets translated correctly, same with the spot position, and for its direction i just rotate, each of those vector3s is in world corrdinates before applying the view matrix on the cpu. Im drawing a sphere for each position and an extra axis for the spot orientation axis, they sit where they should be.
    Last night I added an extra render target to the gbuffer for debug and just dumped the position into it using, varying vec3 position = gl_ModelViewMatrix * gl_Vertex, I then used this texture to get the positions for the spot light shader only, and skipped reconstructing the position from the depth, and now only the point light moves with the camera. So it seems to be something with the position reconstruction from the depth.
    I had been doing it the leadwerks way of doing it from a while back, Iv read other ways of doing it but a matrix multiply per fullscreen pixel wasnt very appealing.

    Code :
    vec3 PositionFromDepth(in float depth)
    {
    	vec3 vsPos;
     
    	vsPos.z = (near / (far - (depth * FminN))) * far;
     
    	vsPos.x = ((gl_FragCoord.x * widthInv) - 0.5) * 2.0;
    	vsPos.x *= vsPos.z;
     
    	vsPos.y = (((-gl_FragCoord.y * heightInv) + 0.5) * 2.0) * aspectInv;
    	vsPos.y *= -vsPos.z;
     
    	vsPos.z = -vsPos.z;
     
    return vsPos;
    }

    Im using a texture rect for depth ( vec3 pixelPosition = PositionFromDepth(texture2DRect(us_Texture0, gl_FragCoord.xy).x) ) Im not sure if that has something to do with it, but im pretty sure the problem is something with the reconstruction at this point, because if I work around this code within the spot shader, it stops moving (direction and position remain correct, according to the debug sphere axis drawing), but the point still moves using this, both in the same scene at same time.

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,184

    Re: View Space Light Position Moving...

    Quote Originally Posted by Swoop
    ...So it seems to be something with the position reconstruction from the depth.

    I had been doing it the leadwerks way of doing it from a while back, Iv read other ways of doing it but a matrix multiply per fullscreen pixel wasnt very appealing.

    Code :
    vec3 PositionFromDepth(in float depth)
    {
    	vec3 vsPos;
     
    	vsPos.z = (near / (far - (depth * FminN))) * far;
     
    	vsPos.x = ((gl_FragCoord.x * widthInv) - 0.5) * 2.0;
    	vsPos.x *= vsPos.z;
     
    	vsPos.y = (((-gl_FragCoord.y * heightInv) + 0.5) * 2.0) * aspectInv;
    	vsPos.y *= -vsPos.z;
     
    	vsPos.z = -vsPos.z;
     
    return vsPos;
    }
    This doesn't look right.

    Let's pick this apart.

    First, if "depth" is in-fact a 0..1 WINDOW-space depth value, I can convince myself that vsPos.z will end up being an EYE-space depth value, assuming a perspective projection, assuming w_eye = 1 (which it typically is), and assuming the depth was rendered with glDepthRange 0..1. In general: z_eye / w_eye = fn / [ z_win * (f-n) - f ], and that's what this apparently computes.

    However, the computation of the X and Y EYE-space values (vsPos.x and vsPos.y) looks really funny. First of all, this line:
    Code :
    vsPos.x = ((gl_FragCoord.x * widthInv) - 0.5) * 2.0;
    does appear to compute the NDC-space X value (x_ndc) from a WINDOW-space X value (assuming widthInv is 1/width where width is the 3rd parameter to glViewport). However, the corresponding NDC-space Y value (y_ndc) computation:
    Code :
    vsPos.y = (((-gl_FragCoord.y * heightInv) + 0.5) * 2.0) * aspectInv;
    there's this inversion that I don't think should be there. This would flip up and down. WINDOW-space runs bottom-to-top, and NDC-space runs bottom-to-top. So I don't believe there's any case for inversion here. And I'm not buying the aspectInv term. So I think this first Y line should be:
    Code :
    vsPos.y = (((gl_FragCoord.y * heightInv) - 0.5) * 2.0);

    Then the next couple of lines in the X and Y transforms allegedly take NDC-space X & Y to EYE-space X & Y:
    Code :
    vsPos.x *= vsPos.z;
    vsPos.y *= -vsPos.z;
    At this point, vsPos.z is the negative of EYE-space Z (i.e. -z_eye), so it is positive.

    The only way I can make the X computation fly is if I assume a 90-degree symmetric perspective FOV frustum (r=-l, and r/n = 1). Then it works. But surely we don't want to hard-code a 90-degree FOV symmetric frustum assumption in the position reconstruction logic (??)

    Now as for vsPos.y, there's another odd negation again... That counteracts the negation in the computation of the NDC-space Y value on the previous line. So what we really have here (without that needless confusion) is:

    Code :
    	vsPos.x = ((gl_FragCoord.x * widthInv) - 0.5) * 2.0;
    	vsPos.x *= vsPos.z;
     
    	vsPos.y = (((gl_FragCoord.y * heightInv) - 0.5) * 2.0) * aspectInv;
    	vsPos.y *= vsPos.z;
    So now they're consistent (except for the aspectInv term), and I now buy the computation of NDC-space Y (first Y vsPos.y line). But we have the same problem with the 2nd Y line as with X. And as I mentioned, we have this confusing aspectInv term.

    So I'm not seeing correct EYE-space X and Y computations here at all, unless we assume a symmetric perspective frustum with X and Y FOVs of 90 degrees, and unless we assume aspectInv = 1.0. And surely we're not intentionally hard-coding those assumptions...

    So, crunching some formulas quickly, I "think" what you want to reconstruct the EYE-space position is:

    Code :
    vec3 PositionFromDepth_DarkPhoton(in float depth)
    {
      vec2 ndc;             // Reconstructed NDC-space position
      vec3 eye;             // Reconstructed EYE-space position
     
      eye.z = near * far / ((depth * (far - near)) - far);
     
      ndc.x = ((gl_FragCoord.x * widthInv) - 0.5) * 2.0;
      ndc.y = ((gl_FragCoord.y * heightInv) - 0.5) * 2.0;
     
      eye.x = ( (-ndc.x * eye.z) * (right-left)/(2*near)
                - eye.z * (right+left)/(2*near) );
      eye.y = ( (-ndc.y * eye.z) * (top-bottom)/(2*near)
                - eye.z * (top+bottom)/(2*near) );
     
      return eye;
    }
    which you could simplify a bit by factoring out -eye.z/(2*near).

    And of course, if you assume a "symmetric" perspective frustum (but not necessarily one that is 90 deg FOV), the eye.x/.y lines simplify down to:

    Code :
      eye.x = (-ndc.x * eye.z) * right/near;
      eye.y = (-ndc.y * eye.z) * top/near;

    This is pretty close to what Leadwerks had, except that we're missing those right/near and top/near terms, and there's that unexplained aspectInv term in his code...

  6. #6
    Junior Member Newbie
    Join Date
    Dec 2007
    Posts
    20

    Re: View Space Light Position Moving...

    That point light wont budge, thanks a lot Dark Photon, that was more helpful then you will ever know. Now I just have to make sure this is done for each light.
    For anyone that might come across this post, I can confirm this fixed the problem perfectly.
    Again, thanks to both of you for your help and suggestions.

  7. #7
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,184

    Re: View Space Light Position Moving...

    Great! Glad we got you fixed up.

  8. #8
    Junior Member Newbie
    Join Date
    Apr 2012
    Posts
    6
    Hi. Not getting much luck here am I. Maybe I should have started a new thread. Could a mod move the above post to a new thread please. I read the rules about not posting in old threads. Sorry about that.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •