关于带纹理索引的Index Buffer Objects实现正确性的验证问询

我一直受困于带纹理索引的Index Buffer Objects实现，曾尝试自行实现索引系统但效果不佳。目前我认为已找到可行方案，特来确认实现是否正确：

• 我理解索引缓冲对象的优势是避免顶点数组中存储冗余顶点，减少GPU内存占用。以包含glm::vec3位置、glm::vec3法线、glm::vec2纹理坐标的顶点为例，单个顶点占40字节，立方体（12个三角面）无索引时需1440字节，而实际仅8个唯一顶点，冗余严重。
• 平面测试时顶点与纹理唯一属性数量一致，实现简单，但复杂网格如立方体存在8个唯一位置坐标、10个唯一纹理坐标的属性数量不一致问题。
• 我推测在Vulkan/OpenGL/D3D中，需针对这种属性差异创建少量冗余顶点，如立方体中复用2个位置坐标映射剩余2个纹理坐标。
• 以下是我基于圆柱投影UV映射的立方体OBJ文件编写的顶点与索引代码（法线为默认值），请确认该实现方式是否为唯一可行的索引缓冲实现方案：

v 1.000000 -1.000000 -1.000000
v 1.000000 1.000000 -1.000000
v 1.000000 -1.000000 1.000000
v 1.000000 1.000000 1.000000
v -1.000000 -1.000000 -1.000000
v -1.000000 1.000000 -1.000000
v -1.000000 -1.000000 1.000000
v -1.000000 1.000000 1.000000
vt 0.922181 0.858908
vt 0.767621 0.094101
vt 0.853231 0.084485
vt 0.672173 0.891780
vt 0.530632 0.045162
vt 0.425062 0.842841
vt 0.260906 0.067522
vt 0.432410 0.958225
vt 0.033512 0.061229
vt 0.088379 0.806583
s off
f 2/1 3/2 1/3
f 4/4 7/5 3/2
f 8/6 5/7 7/5
f 6/8 1/9 5/7
f 7/5 1/3 3/2
f 4/4 6/8 8/6
f 2/1 4/4 3/2
f 4/4 8/6 7/5
f 8/6 6/8 5/7
f 6/8 2/10 1/9
f 7/5 5/7 1/3
f 4/4 2/1 6/8

struct Vertex 
{
    glm::vec3 pos;
    glm::vec3 normal;
    glm::vec2 texCoord;
};

const std::vector<Vertex> vertices = 
{
    { {+1.000000, -1.000000, -1.000000}, {0.0f, 0.0f, 1.0f}, {0.853231f, 0.084485f} },
    { {+1.000000, +1.000000, -1.000000}, {0.0f, 0.0f, 1.0f}, {0.922181f, 0.858908f} },
    { {+1.000000, -1.000000, +1.000000}, {0.0f, 0.0f, 1.0f}, {0.767621f, 0.094101f} },
    { {+1.000000, +1.000000, +1.000000}, {0.0f, 0.0f, 1.0f}, {0.672173f, 0.891780f} },
    { {-1.000000, -1.000000, -1.000000}, {0.0f, 0.0f, 1.0f}, {0.260906f, 0.067522f} },
    { {-1.000000, +1.000000, -1.000000}, {0.0f, 0.0f, 1.0f}, {0.432410f, 0.958225f} },
    { {-1.000000, -1.000000, +1.000000}, {0.0f, 0.0f, 1.0f}, {0.530632f, 0.045162f} },
    { {-1.000000, +1.000000, +1.000000}, {0.0f, 0.0f, 1.0f}, {0.425062f, 0.842841f} },
    //pos[0] tex[9]
    { {+1.000000, -1.000000, -1.000000}, {0.0f, 0.0f, 1.0f}, {0.033512f, 0.061229f} },
    //pos[1] tex[10]
    { {+1.000000, +1.000000, -1.000000}, {0.0f, 0.0f, 1.0f}, {0.088379f, 0.806583f} },
};

const std::vector<uint16_t> indices = 
{
    1,2,0,
    3,6,2,
    7,4,6,
    5,0,4,
    6,0,2,
    3,5,7,
    1,3,2,
    3,7,6,
    7,5,4,
    5,1,0,
    6,4,0,
    3,1,5
};

你的实现是正确的，但并非唯一可行方案 #

1. 属性不一致时的冗余顶点是标准操作
   你推测的“针对属性差异创建少量冗余顶点”完全正确。在OpenGL/Vulkan/D3D这类图形API中，一个顶点的定义是所有属性的组合——只要位置、法线、纹理坐标中有一个不同，就必须作为独立顶点存储。像你处理立方体的方式，为同一个位置搭配不同纹理坐标创建新顶点，是行业通用的标准做法。

2. 你的代码与OBJ文件的映射是准确的
   对照OBJ文件的面定义（比如f 6/8 2/10 1/9对应代码中的索引5,1,0），你的顶点数组和索引数组完全匹配OBJ的属性关联关系，渲染后会得到正确的圆柱投影UV效果。

3. 其他可行方案说明

   • 无索引直接绘制：放弃IBO，直接存储所有36个顶点（12个三角面×3），虽然内存占用更高，但实现最简单，适合小型网格。
   • 使用顶点属性分离的绑定方式：部分API支持将位置、纹理坐标等属性分别存储在不同缓冲中，通过各自的索引来关联，但这种方式会增加绘制时的状态切换开销，并且多数场景下性能不如你当前的方案。
   • 纹理坐标优化：如果可以调整UV映射规则，让立方体每个位置对应的纹理坐标唯一（比如改用立方体投影UV），就能减少冗余顶点数量，但这属于美术资源优化范畴，而非IBO实现的不同。

总之，你当前的实现是高效且符合图形API规范的最优方案之一，完全可以投入使用。

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