Talk:Compute eye space from window space
"Optimized method from XYZ of gl_FragCoord
I implemented this method, and I think I have found some problems with it (that can be fixed to make it work).
- The method still uses indices from the projection matrix to calculate the eye space depth, which is confusing. This method seems to work just as well, and is less confusing: eye_z = ( camera_near / (camera_far - texture_depth * (camera_far - camera_near)) ) * camera_far [ http://www.leadwerks.com/files/Deferred_Rendering_in_Leadwerks_Engine.pdf ]
- The method proposes that [-1, 1] should be used for the range of the coordinates when calculating eye direction. That "almost" works, but I have after some reasoning and testing found that this should probably be the corners of the near plane in eye space.
- My biggest concern with the Leadwerks method is that it's hard-coded to doing things the Leadwerks way. For example:
- #1 is true only if you ignore the possibility of the user changing the depth range. And I don't mean the camera znear/far. I mean glDepthRange. It's part of the Viewport Transform. I'm sure, for the Leadwerks engine, they use a specific depth range. But for a general-purpose algorithm, there needs to be some acknowledgement of that.
- Similarly, the reason why the original code references the perspective matrix, rather than unfolding the operation explicitly, is because this codes makes minimal assumptions about the contents of the perspective matrix. I'm sure the two are mathematically equivalent for the traditional perspective projection matrix. However, the original code will work just fine with an unusual perspective projection.
- For #2, I freely admit that I found it rather dubious when I was told that the NDC-space trick worked. I couldn't come up with an argument against it; the math seemed sound, and I never actually tried it myself. So I don't contest it.
- Thanks for the practical experience, particularly on point #2. Alfonse (talk) 06:05, 17 January 2015 (UTC)