研发实战：用RenderDoc验证有效渲染方式，优化Quest应用
|
上面是RenderDoc中的阴影贴图。你会发现阴影通道中有一个用于稍后采样场景阴影的临时深度缓冲区。重要的是要验证总体阴影贴图分辨率，以及与每个级联相关的绘制调用次数。在几乎所有的情况下，随着camera距离的增加和每增加一个级联，较接近的级联将具有较少的绘图调用。请注意橙色的解析阴影一栏。当你将临时缓冲区存储在外部存储中时，这是固定成本。如果必须使用阴影，请确保将分辨率和其他绘制调用保持在尽可能低的水平。 4. 验证共享网格的GPU实例化 GPU实例化是图形API/驱动程序级别的功能，可允许你调度单个绘制调用来渲染多个网格。这里需要遵守一定的规则，包括共享完全相同的管道状态和网格输入。如果一个网格每帧使用了多次（子弹，装饰，粒子和树叶等），则可以通过实例化网格来大幅减少绘制调用。请注意，这不会降低GPU的成本，因为你依然必须投影每个网格。 每当你调度一个实例化绘制，每个网都会收到可以在着色器中使用的实例ID。这样，你就可以将每个网格实例的实例ID与属性信息（如纹理索引，颜色或其他）相关联。我一直十分喜欢举的一个例子是，在赛车游戏中渲染大量人群。你可以通过实例化并使用不同颜色的衬衫来绘制每个人，从而确保一种观众满满的感觉，同时不必为每个网格分别调度单独的绘制调用而产生过多的CPU开销。在这个基本示例中，你将不会使用蒙皮网格……但你可以在GPU进行蒙皮/动画操作来实例化蒙皮网格。这是一种更先进的技术，但同样有着优点和缺点。这里的想法是，你会实例绘制共享的T形网格，然后使用实例ID查找并计算时间戳和姿态信息。这样可以完成混合形状查找，并在顶点着色器中进行蒙皮。或者，你可以提前在计算着色器中批量处理所有混合形状和蒙皮操作，然后使用实例ID查找当前绘制的网格的相关数据的位置。 旁注：GPU实例化是实例立体/多视图渲染的工作方式。使用所述方法的每个绘制调用为每个网格调度两个实例。两个网格映射中的每一个实例ID均绘制到相关的眼睛缓冲区，而顶点着色器将用来索引到模型视图投影矩阵的一个阵列，从而正确地将网格投影到相关的眼睛位置。
在上图中，你看到的不是十二个单独的glDrawElements（36）调用，而是4x glDrawInstanced。glDrawElementsInstanced（36，5）不能一次绘制所有多维数据集的原因是，某些多维数据集违反了Unity中的批处理规则。要判断未对它们进行批处理的原因，你可以通过Unity中的Frame Debugger工具来确定是否调用了glDrawElementsInstanced（36，12），从而将多维数据集的总绘制计数缩减为一个绘制调用。
在上面的Frame Debugger视图中，我选择了第二个实例绘制调用。Unity在“Why this draw call can’t be batched with the previous one”一栏中表示，多维数据集受不同的反射探针所影响。如果它们全部在一次绘制调用中完成，我将需要对所有多维数据集使用单个反射探针。Frame Debugger免除了方程式中的猜测，而你同时可以通过RenderDoc的“Pipeline State”选项卡中使用传统的侦探方法来得出这个结论。只需检查并比较两个实例绘制调用之间的输入资源即可。 5. 渲染队列和z-sorting验证 对于大多数GPU，有一种优化方法可允许硬件拒绝遮挡的不透明像素（从前到后绘制）。例如在VR中，在大多数情况下如果手不透明，则应首先渲染它们。如果在绘制手（可能是接近于camera的对象之一）时写入深度缓冲区，并调度z-test以拒绝其后的像素，则硬件将足够智能并选择不为位于手后面的投影几何像素执行像素着色器。如果你使用了合理的几何图形计数，并且顶点着色器中没有执行任何花哨的操作，则像素着色器通常是渲染管道中开销最多的一环。 （编辑：衡阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
