Clip coords to gl_FragDepth

[nickels]

It is my understanding that after the modelview projection, the scene is laid out in from of the camera with the negative z axis extended away from the camera? So in this space things with larger z coord will eventually overwrite those with smaller (possibly negative) z value in the depth buffer?

But it is also my understanding that out of the fragment shader the gl_FragDepth values are from [0, 1], with smaller values overwriting those with larger (under standard GL_LEQUAL)?

Is that the standard setup?

In which case, doesn't the z value get flipped at some point? Is this reflection built into the standard opengl projection matrix functions?

What am I missing here?

(* I'm trying to write light view projection matrices for shadow mapping and my world space is in left handed coords, so I'm trying to mimic the glScalef(0,0,-1) that works for the regular modelview projection)...

[nickels]

The answer is, I think, here:

http://www.songho.ca/opengl/gl_projectionmatrix.html

"Note that the eye coordinates are defined in right-handed coordinate system, but NDC uses left-handed coordinate system."

So the projection should, in fact reflect the z coords!!

To some extent, I guess, shaders allow you to work in whatever coords one likes. But there is still some fixed functionality even in those that intervene!!

[Dark Photon]

It is my understanding that after the modelview projection,

modelview "transform". I wouldn't use the word projection here, which infers you speak about the PROJECTION transform too.

...the scene is laid out in from of the camera with the negative z axis extended away from the camera? So in this space things with larger z coord will eventually overwrite those with smaller (possibly negative) z value in the depth buffer?

Yes, assuming they pass culling.

But it is also my understanding that out of the fragment shader the gl_FragDepth values are from [0, 1], with smaller values overwriting those with larger (under standard GL_LEQUAL)?

Yes, but there you're talking about a different coordinate space.

Eye-space = Eye at 0,0,0; -Z axis stretches out in front of eye

Window space = Depth runs 0..1 (typically) from near clip to far clip (see glDepthRange)

between these we have:

Eye-space -> (PROJECTION) -> Clip-space -> (Perspective divide) -> NDC-space -> (Viewing transform) -> Window-space

In which case, doesn't the z value get flipped at some point?

For values in the view frustum:

Eye-space = Z = -near_val...-far_val
Clip-space = Z/W = -1...1
NDC = -1..1
Window-space = 0..1

So yeah, in the PROJECTION transform (with a perspective projection), things get flipped.

[nickels]

Yes, modelview 'transform', my bad.



(Eye coords left, NDC right)

If the link and diagram above is right, then it is in the projection that the 'flip' occurs. He goes on to derive the projection (perspective and orthogonal) and they are, in fact, different from the directx convention by this coordinate flip... (and directx NDC depth coords are [0, 1] so the scaling is different)...

thanks!

[Dark Photon]

and they are, in fact, different from the directx convention by this coordinate flip... (and directx NDC depth coords are [0, 1] so the scaling is different)...

Yeah RenderMorphics->WGF->Direct3D flipped number of things just for the hell of it. IrisGL / OpenGL had already defined this. But do the exact same thing? No way! Then it would look like we copied.

In at least one case, Direct3D flipped back to doing it the OpenGL way: D3D10: pixel edges are even integers and pixel centers are .5,.5 offsets from the corner. Rather than 0,0 being the center of the upper-left pixel. The old way was causing devs too much grief.