平面着色需要这么多顶点复制吗?

你说得对,对于平面着色,你必须复制位置。也就是说,因为顶点是位置、法线和所有其他属性的完整元组。

然而,这种重复对渲染时间几乎没有影响。是的,它增加了一些内存开销,但就渲染过程而言,相同数量的数据被传输并合并到渲染过程中。事实上,整体上某些属性的重复使缓存更具可预测性,因为不涉及数据间接性(即根据渲染的人脸查找不同的法线)。因此,这实际上具有理论上的性能提升。

你做得完全正确。

事实上,最便携的平面着色实现将需要为每个绘制的三角形复制顶点,这会带来内存使用的开销(在复杂几何体的情况下相当大)。它也可能影响渲染性能,但这取决于硬件(现在不应该被注意到)。这就是基本的WebGL 1.0所允许的。

然而,WebGL 2.0和WebGL 1.0 OES_standard_derivatives 扩展提供了另一种选择-通过导数直接在Fragment Shader中计算三角法线:

#extension GL_OES_standard_derivatives : enable
...
varying vec4 Position;
varying vec3 View;
...
void main()
{
  vec3 Normal = normalize (cross (dFdx (Position.xyz / Position.w), dFdy (Position.xyz / Position.w)));
  if (!gl_FrontFacing) { Normal = -Normal; }
  ...
  gl_FragColor = computeLighting (normalize (Normal), normalize (View), Position);

这需要每个片段的照明(例如。 Phong shading 而不是Gouraud阴影)。着色结果与在CPU上复制顶点和预先计算三角形法线并不完全相同,但视觉效果将是相同的——具有可区分三角形的平面着色。

实际上, GL_OES_standard_derivatives 被广泛采用。 事实上,桌面OpenGL 2.0中的GLSL 1.1从一开始就支持派生版本(不需要扩展)——只有OpenGL ES 2.0(以及WebGL 1.0)决定将其排除在外。

然而,有人抱怨各种GPU上的衍生实现。精确的导数计算成本高昂,因此GLSL规范允许返回更快的近似值,这对旧的图形硬件至关重要。在实践中,这种方法对平面遮阳效果很好,尽管有一个 OpenGL ES implementation (Qualcomm) 具有返回值符号翻转的奇怪行为。

例如,这里有一个 research 几年前为Android设备完成的(不知道WebGL是否会遇到同样的问题——网络浏览器可能会将损坏的实现列入黑名单,或者对已知的驱动程序错误应用一些解决方法):