研发实战：用RenderDoc验证有效渲染方式，优化Quest应用
|
在上图中，你看到的不是十二个单独的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以拒绝其后的像素，则硬件将足够智能并选择不为位于手后面的投影几何像素执行像素着色器。如果你使用了合理的几何图形计数，并且顶点着色器中没有执行任何花哨的操作，则像素着色器通常是渲染管道中开销最多的一环。 （编辑：宿州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
