three.js+WebGL踩坑经验合集(8.3):合理设置camera.near和camera.far缓解实际场景中的z-fighting叠面问题

本篇延续上篇内容:

three.js+WebGL踩坑经验合集(8.2):z-fighting叠面问题和camera.near的坑爹关系-CSDN博客

笔者也是狠佩服自己:一个还没划上句号的文章都能拖了半年才继续写。这次也是运气好,工作上再次遇到叠面问题,可以借这机会继续深入研究。

在重新进入状态之前,笔者先不给大家深入探讨帮助文档说得让人一知半解的,polygonOffset的两个系数m和r的工作原理,而是先承接上篇内容,把camera.far也简单说一说。

上篇我们重点讨论了near以及far/near这两个指标在处理z-figting问题上的重要性,至于far是还没有单独揪出来说。

实际上,这玩意儿也不用太纠结,我们继续沿用上一篇的曲线图进行直观的演示。

因为图像不是直线,所以叠面问题的严重程度不仅仅取决于far和near,还要看我们的应用场景处于曲线的哪个区间,越是陡峭的区间,z深度拉得越开,叠面问题越少。所以笔者在上述演示的基础上完善了下,每200像素绘制一条竖直线,观察在near和far调整的过程中,曲线跟这些竖直线的交点处的斜率变化。

注意:本文说的错开,是看白色曲线的斜率,而非每根紫色线的距离

不难看出,在这个案例中,near越大或者far越大,5个面的z都错得越开。实际上,大多数的业务场景都有这个规律,但至于near和far具体设置多少,这还得看场景物体的具体坐标。这里说的坐标,指的是物体的世界坐标跟camara.matrixWorldInverse相乘后的结果。

由此可见,near和far都尽可能调大,对叠面问题的缓解会有非常大的帮助,结合上一篇文章,我们来小结一下:

1 透视相机下缓解叠面问题的方案,首先要让far/near尽可能大

2 在far/near足够大的情况下,far和near同时调大,能非常有效地缓解叠面问题

3 我们应该根据业务场景来确定项目中最终的near和far值,一是确保物体不被裁切,二是尽可能让物体落在z深度错开程度比较高的区间内,可以用跟笔者类似的方法调出一个满意的结果

4 正交相机无视这些问题

笔者这几天对polygonOffset再次做了深入的研究,api给出的offset计算公式

m*polygonOffsetFactor+r*polygonOffsetUnits

中的r笔者已经搞明白了是啥,下篇会给大家分享,而m值,目前还没搞透,但也有点眉目了,所以下篇先来聊聊r这个系数到底是个什么玩意儿,敬请期待!

相关推荐
数据知道1 天前
视觉伪装(下):WebGL 渲染器与厂商特征的底层伪造与屏蔽
javascript·数据采集·webgl·指纹浏览器
niconicoC1 天前
让 Three.js 场景更真实:我用高斯泼溅和 SparkJS 做了一个可交互的 3D Demo
前端·webgl
sinat_384503113 天前
【无标题】
unity·webgl
山河木马8 天前
无框架-原生webGL渲染-底层入门-1
前端·javascript·webgl
拾忆丶夜9 天前
unity webgl 阴影条纹问题
unity·游戏引擎·webgl
GISer_Jing13 天前
Three.js着色器编译机制深度解析
javascript·webgl·着色器
GISer_Jing14 天前
WebGL|Three.js渲染管线核心技术解析
java·javascript·webgl
丷丩15 天前
MapLibre GL JS第12课:检查WebGL支持
前端·javascript·map·webgl·mapbox·maplibre gl js
平行云15 天前
实时云渲染预启动技术解析:UE数字孪生应用的延迟优化机制(二)
linux·unity·ue5·webgl·实时云渲染·云桌面·像素流
平行云16 天前
实时云渲染预启动技术解析:UE数字孪生应用的延迟优化机制(一)
linux·ue5·webgl·数字孪生·云渲染·实时云渲染·像素流