基于Vulkan+C++的渲染器如何处理含多种顶点格式的GLTF节点

避免Shader变体爆炸的可行方案 #

• 利用Vulkan 1.3核心支持的VK_KHR_dynamic_vertex_input扩展（旧版本可作为扩展启用）：该扩展允许你在录制命令缓冲时动态指定顶点输入布局，无需在创建Pipeline时固定属性数量、顺序和偏移，同一份着色器可以直接兼容不同的顶点输入格式，不用为属性顺序、存在性差异创建独立Pipeline。
• 着色器侧通过推常量/UBO传递属性存在掩码：用一个整型变量的每一位标记对应GLTF标准属性是否存在，比如第0位标记POSITION是否存在、第1位标记NORMAL是否存在，着色器读取属性前先判断对应位是否置位，未置位直接返回GLTF规范定义的默认值（如NORMAL默认vec3(0,0,1)、TEXCOORD默认vec2(0,0)、COLOR默认vec4(1,1,1,1)等）即可，无需在CPU侧为缺失属性填充默认值，大幅减少模型加载时的数据处理开销。
• 单元素Accessor特殊处理：加载时检测到属性对应Accessor的count为1时，不要将其展开为顶点数组，直接将该值存入对应Draw Call的UBO/推常量中，着色器直接读取常量值即可，既省内存也避免了无意义的数组拷贝。
• 按需编译Shader变体：不要预先生成所有可能的顶点格式对应的变体，改为在加载模型时，对首次遇到的顶点格式组合动态生成对应着色器代码（可以通过拼接GLSL宏定义、或者直接修改SPIR-V字节码实现），编译后缓存到本地，后续遇到相同格式直接复用。绝大多数实际场景用到的顶点格式组合不会超过20种，完全不会出现变体爆炸的问题。

减少Pipeline切换的优化方案 #

• 按Pipeline状态分组提交：加载完所有场景资源后，对所有Primitive按顶点格式、材质、着色器、绑定资源等状态做排序，相同状态的Primitive集中提交，不用按照Node层级顺序渲染，可将全局Pipeline切换次数降低一个数量级。
• 同Node下的Primitive预合并：如果同一个Node下的多个Primitive使用相同材质、兼容的顶点格式，可以在加载阶段将其合并为单个Primitive，直接消除同Node内的Pipeline切换需求。
• 通用顶点格式兜底：对占比最高的几种顶点格式（比如POSITION+NORMAL+TEXCOORD_0、POSITION+TEXCOORD_0等）提前预编译优化版的专用着色器，少见的格式统一走动态输入的通用着色器即可，兼顾性能和通用性。

内容的提问来源于stack exchange，提问作者Vulkanoid