OpenGL中gl_FragCoord.z与深度缓冲区值偏差及ES 3.x深度读取问题

问题1：为啥gl_FragCoord.z和深度缓冲区里的数值有偏差？ #

这俩数值不一样，核心原因是坐标空间的转换逻辑，再加上OpenGL对深度值的非线性映射处理：

• gl_FragCoord.z是什么？ 它是当前片元经过透视除法后的*NDC（标准化设备坐标）*z值，默认范围是[-1, 1]（少数上下文可能配置成[0,1]，但绝大多数标准实现是前者）。
• 深度缓冲区存的是窗口空间深度值：NDC的z值会通过glDepthRange（默认范围是[0,1]）做线性映射，转换成窗口空间的深度值，这个才是最终存在深度缓冲区里的数。转换公式大概是这样：

  window_z = (glDepthRange.far - glDepthRange.near) * (ndc_z + 1)/2 + glDepthRange.near
  

• 透视投影的非线性坑：如果用了透视投影，NDC的z值本身就是非线性的——近裁剪面附近的z值变化会被放大，远裁剪面附近的变化会被压得极小。这就导致深度缓冲区里的存储值和实际世界空间的线性深度不是正比关系，而gl_FragCoord.z反映的就是这个非线性的NDC z，直接对比自然会有偏差，得手动把它转成窗口空间范围才能和深度缓冲区的值对上。

问题2：OpenGL ES 3.x里读特定鼠标坐标深度值失败&精度不够的问题分析 #

为啥glReadPixels在ES里读不了深度缓冲区？ #

在OpenGL ES里用glReadPixels读深度缓冲区，有几个很容易踩的坑：

• 默认帧缓冲的深度缓冲区可能不可读：很多移动设备的屏幕帧缓冲（默认帧缓冲）是硬件优化过的，深度缓冲区格式不支持直接读取。解决办法是自己建一个离屏FBO（帧缓冲对象），附加一个可读取的深度纹理或深度渲染缓冲区，把场景渲染到这个FBO里，之后再读这个FBO的深度数据就没问题了。
• 格式和类型不匹配：读深度的时候参数必须对应对，比如格式用GL_DEPTH_COMPONENT，类型要对应GL_UNSIGNED_SHORT（如果是16位深度）或者GL_UNSIGNED_INT（24/32位深度）。参数错了要么读失败，要么拿到一堆垃圾值。
• ES版本的配置要求：OpenGL ES 3.x确实支持读深度缓冲区，但前提是帧缓冲的深度附件配置正确——比如深度纹理得用GL_DEPTH_COMPONENT16/GL_DEPTH_COMPONENT24这类格式，创建FBO的时候要正确把它附加进去。

为啥精度不够，甚至Win10环境下也不行？ #

不管是桌面还是移动环境，精度不够通常和这几个因素有关：

• 深度缓冲区位数太低：很多移动设备默认用16位深度缓冲区，如果你把远裁剪面设得太大（比如大地形要渲染几公里外的区域），远裁剪面附近的深度值会严重丢精度——因为非线性映射下，大部分深度值都挤在近裁剪面附近，远处的分辨率极低。建议换成24位深度缓冲区（如果硬件支持），或者尽量缩小近/远裁剪面的比值（别把远裁剪面设得太离谱，够用就行）。
• 透视投影的非线性精度损失：大地形场景里，要是需要精确的深度值，别依赖深度缓冲区的非线性值，不如额外渲染一个线性深度的颜色纹理——在顶点着色器里算出世界空间的z值，传到片段着色器后输出到一个浮点颜色附件里，之后读这个颜色纹理的数值，精度比深度缓冲区高多了。
• 着色器采样深度纹理的精度问题：如果你是用片段着色器采样深度纹理来拿值，在ES里要注意采样精度——比如用sampler2D配GL_DEPTH_COMPONENT格式时，采样得到的是[0,1]的浮点数，但如果是16位深度，这个浮点数只有16位精度，可能不够用。这时可以试试浮点深度纹理（硬件支持的话），或者把深度值编码到RGB颜色通道里存储。

适合你大地形场景的可行方案 #

光线投射对大地形确实不现实，推荐这两个替代方案：

1. 建一个带深度纹理的离屏FBO，把场景渲染到FBO后，要么用glReadPixels读指定坐标的深度值，要么在片段着色器里直接采样这个深度纹理（看你代码片段的样子，应该是想在着色器里处理？那得确保深度纹理绑定正确，采样参数也没毛病）。
2. 如果深度精度还是不够，就额外渲染线性深度的颜色纹理——把世界空间的z值存在浮点纹理里，之后直接读这个纹理的数值，精度能满足大地形的需求。

内容的提问来源于stack exchange，提问作者PowerNow