用什么网站开发,浙江省住房和建设厅网站,网站怎么做返回主页按钮,专做自驾游的网站查看引用/信息源请点击#xff1a;映维网开发移动VR内容时应避免的PC渲染技术#xff08;映维网 2019年11月25日#xff09;有不少开发者都是以与PC相同的方式来开发Quest游戏#xff0c;但这可能会导致优化性能方面出现大量困难。Oculus软件工程师特雷弗达什#xff08;T…查看引用/信息源请点击映维网开发移动VR内容时应避免的PC渲染技术映维网 2019年11月25日有不少开发者都是以与PC相同的方式来开发Quest游戏但这可能会导致优化性能方面出现大量困难。Oculus软件工程师特雷弗·达什Trevor Dasch的工作是帮助开发者构建高质量的游戏并确保它们能够以稳定的72FPS速度运行。日前达什撰文分享了在为移动VR开发内容时应该避免的PC渲染技术。下面是映维网的具体整理尽管移动芯片组可以支持下面概述的大多数技术但我们强烈建议你不要这样做。不过这并不总是一成不变的规则因为我有看到开发者有实现下述技术但依然达到帧速率的要求。但通过避免下文提及的PC渲染技术你会为自己省下大量的麻烦。1. 延迟渲染延迟渲染或延迟着色这种技术是将光照/渲染计算推迟到第二步进行计算。这样做的目的是为了避免多次渲染同一个像素。延迟渲染主要分为两步在第一步中渲染场景但只是简单地将几何信息位置坐标法线向量纹理坐标和反射系数等等存储在中间缓冲区中在第二步中从中间缓冲区读取信息应用反射模型计算出每个像素的最终颜色。延迟渲染对PC开发非常有效因为它可以将几何图形与照明分离你只需更新每个照明所触达的像素即可在更少的GPU周期内渲染更多照明。为何不适合移动开发原因有很多但主要是因为解析成本。什么是解析费用在我告诉你什么是解析成本之前你首先需要理解基于图块渲染的工作原理。为了以更低功耗实现更高的吞吐量移动GPU如Oculus Quest中的骁龙835通常采用基于图块的架构其中每个渲染目标都分解为块状网格或“图块”从16×16像素到256×256像素之间具体取决于硬件和像素格式。接下来你的几何会“绑定”到图块然后再提交给异步处理器异步处理器执行渲染工作并计算每个“图块”的图像结果。计算完每个图块图像后GPU必须从片上内存中将图块复制回通用内存。这实际上非常慢因为它需要通过总线传输数据。我们将这个转移过程称为“解析”所以花费的时间称为“解析费用”。因为要渲染的每个纹理都需要解析并且延迟渲染需要在计算照明之前渲染大量纹理所以你的解析成本将从正向渲染的大约1ms增加至3ms以上。如你所见你可能没有这样的时间。除了解析成本问题之外延迟渲染仅在几何形状复杂且有多个光源的情况下才能显露出优势。无论如何移动设备都真正实现这两者因为GPU用来处理大量顶点和计算计像素填充的能力有限。目前的答案是坚持采用正向渲染。2. Depth Pre-PassDepth/Z Pre-Pass是一种常见的技术其中所有场景几何图形都作为第一步渲染无需填充帧缓冲区仅生成深度缓冲区值。然后你渲染第二通道检查每个像素的计算深度是否等于深度缓冲区中的值。如果不是则可以跳过对这一片段的着色处理。由于处理顶点的速度通常比像素着色快得多所以可以节省大量时间。为何不适合移动开发首先如果在提交绘制调用之前对几何进行排序通过进行Depth Pre-Pass而节省的片段填充时间应该最少。来回绘制会导致常规深度测试拒绝你的像素所以你只能避免对未正确排序或两个对象在不同点彼此重叠的几何图形进行像素填充。其次这需要绘制调用加倍因为你必须先提交所有内容以进行Depth Pre-Pass然后再才是Forward Pass。由于CPU的绘制调用已经相当沉重所以你需要避免这种情况。第三所有顶点都需要处理两次与通过避免填充少数像素两次而节省的时间相比你通常增加的GPU时间会更多。这是因为移动设备的顶点处理会在PC耗费更多的时间并且处理片段的时间同样相对较少。3. HDR纹理解析成本与图像中的字节数直接相关而不与像素数直接相关所以尽管我们通常以32位RGBA像素来思考量度但如今大多数开发者都在使用HDR纹理即每像素64位。这会将你的解析成本增加一倍并且由于显示器仅支持每通道8位所以你在解析HDR纹理时会浪费大量时间。更不用说移动GPU是针对32位帧缓冲区进行优化。4. 后处理后处理是一种经常用于为游戏施加多种效果的技术如Color GradingBloom照明和运动模糊。具体的实现方式是获取游戏渲染的输出然后对图像运行全屏通道以产生新图像然后再将其呈现给玩家。一些后期处理效果是作为一个额外的通道执行如颜色分级另一些则需要多个通道。对于移动设备后处理的主要问题同样是解析成本。生成第二张图像将引起另一次解析并会立即消耗大约1毫秒的时间。更不用说计算后处理效果所花费的时间取决于效果这可能会占用大量资源。所以最好避免进行后处理。以下是替代常见后处理效果的方案Color grading与其在后处理中执行Color Grading不如在每个片段着色器的末尾添加一个函数调用以执行相同的数学运算。这将产生相同的视觉结果但无需额外的解析。Bloom真正的Bloom效果非常耗时。最好的选择是“伪造”。采用包含blob纹理的billboarding sprite可以产生非常接近的效果。5. 实时阴影我认为这是最有争议的一项技术。一系列具有完整实时阴影的应用已成功支持移动设备。但是这样做存在大量的折衷而我认为值得避免使用。实时阴影的一种常用技术是级联阴影贴图这意味着场景会以各种视口大小进行多次渲染。对于必须由GPU处理的几何这会令次数增加1到4倍这从根本上限制了场景可以支持的顶点数量。它同时增加了阴影贴图纹理的解析成本与纹理大小有关。在GPU管道的另一端在对阴影贴图进行采样时有两个选项硬阴影和软阴影。硬阴影可以更快地渲染但具有不可避免的锯齿问题。由于阴影贴图的工作方式这个测试只能得出二进制结果。你无法对阴影贴图进行双线性采样因为它表示深度值而非颜色值。应该避免使用软阴影因为它们需要将多个采样放到阴影贴图中而这当然很慢。最好的选择是烘烤所有可能的阴影而如果需要实时阴影请寻找另一种方法。如果照明大部分都是漫反射则通常可以接受blob阴影。如果需要强光照明并且阴影表面是平面则几何阴影的效果同样相当出色。6. 深度及帧缓冲区采样对于PC你可以在着色器中采样当前的深度纹理Unity将其显示为_CameraDepthTexture。之所以可行是因为深度纹理只是PC上的另一种纹理并且由于每个绘制调用都接连发生所以深度纹理的状态将是上一次绘制调用之后的状态。但对于基于图块渲染当前深度不在纹理之中而是仅存储在你的图块内存中所以无法将其作为普通纹理进行采样。考虑到上述情况有一个GLES扩展可允许你查询深度缓冲区和帧缓冲区的当前状态。问题是它们非常慢只能支持你对相同像素的值进行采样无法查询附近的像素并且在启用MSAA时它们会产生一系列的问题。启用MSAA时图块实际上具有一个足够大能够容纳所有采样的缓冲区即2×MSAA的像素为2倍4×MSAA的像素为4倍。这意味着默认情况下如果对深度缓冲区进行采样则必须按每个采样执行片段着色器这意味着时间密集度将比预期高2倍或4倍。存在一种“解决方案”即调用glDisableFETCH_PER_SAMPLE_ARM。但这样做的问题是它将仅检索第一个采样的值而不是混合采样的结果所以在启用所述功能后MSAA将被禁用。除非绝对必要否则你应避免它们对帧时间产生的影响。7. 几何着色器几何着色器允许你在运行时生成额外的顶点这对于诸如动态细分等功能十分有用。但是对于基于图块渲染的GPU而言几何着色器会产生问题。生成额外顶点的步骤阻止了合并过程的进行这意味着GPU不能这样做所以它会切换为“立即”模式完全跳过分块过程。可以猜到这非常缓慢。所以最好避免使用几何着色器并且如果有必要选择CPU生成顶点。8. Mirrors/Portals如果你用天真的方式实现它们……对于“天真的方式”我是指分配两个眼睛缓冲区大小的纹理计算反射矩阵然后将场景渲染到两个纹理中。然后你的mirror几何将进行屏幕空间纹理采样从而显示反射。这种方法存在众多明显的缺陷绘制调用增加了两倍。填充的像素比屏幕可见的像素要多。必须解析另外两个纹理。我发现的最低提升是限制了mirror camera的视口并更改了相应的投影矩阵只能在视锥中渲染camera平面边界框。这对上面的第二点问题有所帮助。理想情况下你同时可以使用多视图通过一组绘制调用来渲染左右眼但Unity目前不支持这项功能它不能解决上面的第三点问题 并且会令第二点问题更加恶化因为你只能为两只眼睛使用单个视口所以你必须使用两个mirror边界框的重叠。所以理想的解决方案将首先解决第三点问题这意味着一次绘制mirror场景和非mirror场景。有一种解决方案可以利用修改后的着色器和模板缓冲区。场景中的每种材质都将具有两种版本的着色器一种仅在模板缓冲区中的特定位为0时绘制而另一种仅在1时绘制。然后你将使用材质绘制mirror网格。它会在模具缓冲区中设置所述位使用第一组着色器绘制场景使用反射矩阵设置camera并且在最后使用第二组着色器绘制场景。这将产生你想要的反射同时不会填充超出所需像素的像素并且避免了不必要的解析。然而它无法避免绘制一堆对象两次任何解决方案都无法避免。尽管这听起来很容易但如果是使用Unity你将会遇到很多问题我在Unreal中没有遇到过但你可能会遇到类似的挑战。首先在启用Single Pass Stereo多视图后Unity将不允许你修改camera的投影矩阵所以你不能使用反射camera如果关心CPU性能你绝对应该使用这个camera。其次这没有考虑Late-Latching在渲染线程启动时更新camera矩阵从而尽可能减少延迟。通常来说这是一次纯粹的胜利但如果你使用mirror camera则反射camera的变形将不再与头部变形匹配所以你会得到奇怪的伪影镜面中的元素不会按照预期方式排列。最简单的解决方案是“伪造”。如果你的镜面是静态则只需创建所有世界几何的反射副本然后将其放在场景中即可。你需要使用脚本来移动任何动态对象的“反射”副本从而模仿包括玩家在内的“真实”版本位置但这将是最快、最简单的渲染解决方案无需复杂的矩阵数学。如果可以看到镜子后面你将不得不使用两组具有不同模板蒙版的着色器但如果玩家由于墙壁等原因而无法看到后面则可以只保留一组着色器。9. 总结无论你是从零开始一个新项目还是要从PC移植到移动设备明确哪里可以沿用原有的知识经验哪里又需要采取创新的解决方案是获得最佳游戏效果的关键。 但是你不必遵循本文的建议。请自由探索并寻找最适合自己的方案。---原文链接https://yivian.com/news/69240.html
