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).

1. 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 ]
2. 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.

I find that the method works with these adjustments. I will test this some more, and if no one protests I'll change the article. --Torandi (talk) 13:48, 23 January 2014 (PST)

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)

It should also be noted that, with various new perspective matrices (like those that don't have a camera zFar, those that use D3D conventions with a floating-point depth buffer, inverted depth, etc), they all work just fine my way without any changes to the code. With your way, you'd have to crank through the math for each kind of perspective projection matrix. So general purpose seems to win out here. Alfonse (talk) 18:59, 3 May 2015 (UTC)