glTF文件网格数据在accessor、bufferView、buffer的分配适配疑问

在glTF格式中，网格对象的位置数据需经过三层间接引用：mesh -> accessor -> bufferView -> buffer。

核心问题 #

网格数据应如何在accessor、bufferView和buffer之间分配？不同分配方式是否有影响？

四种布局方案示例 #

假设有两个均含POSITION属性的网格，位置数据的布局大致有四种选择：

===============================================================
(A) 所有位置数据共用一个accessor、bufferView和buffer
mesh 0 -+
        +-> accessor 0 ---> bufferView 0 ---> buffer 0
mesh 1 -+
===============================================================
(B) 每个网格对应一个accessor，共用一个bufferView和buffer
mesh 0 ---> accessor 0 -+
                        +-> bufferView 0 ---> buffer 0
mesh 1 ---> accessor 1 -+
===============================================================
(C) 每个网格对应一个accessor和bufferView，共用一个buffer
mesh 0 ---> accessor 0 ---> bufferView 0 -+
                                          +-> buffer 0
mesh 1 ---> accessor 1 ---> bufferView 1 -+
===============================================================
(D) 每个网格对应独立的accessor、bufferView和buffer
mesh 0 ---> accessor 0 ---> bufferView 0 ---> buffer 0
mesh 1 ---> accessor 1 ---> bufferView 1 ---> buffer 1
===============================================================

方案(A)生成的glTF文件最简且最紧凑（尤其当两个网格共享顶点位置时），但使用该方案创建含数千个网格的glTF文件并加载到three.js中时出现以下问题：

• Box3.setFromObject无法正确计算网格边界盒（本该仅计算对应网格的顶点范围，却计算了整个accessor或bufferView的所有位置）；
• 单个大buffer（或bufferView/accessor）可能在内存或GPU内存中被多次复制（每个引用它的网格复制一次，总数可达数千次），严重限制了可查看场景的规模。

希望了解：three.js等glTF解析工具的默认处理假设，以及通用的最优布局方案。

解答 #

四种方案的差异与适用场景 #

1. 方案(A)：仅适用于完全共享所有顶点数据的网格（比如多个实例化的相同网格）。但这种方案违背了glTF中accessor的设计初衷——accessor本应描述单个属性的子集范围，而非所有网格的合并数据。当网格顶点不共享时，这种布局会导致解析工具无法区分各网格的顶点范围，进而出现边界盒计算错误、内存冗余复制等问题。
2. 方案(B)：是顶点数据共享时的最优选择。多个网格的accessor指向同一个bufferView和buffer，但每个accessor通过byteOffset、count等参数明确自己的顶点范围。这种布局既保留了文件的紧凑性，又能让解析工具正确识别每个网格的顶点数据，避免内存重复复制，同时边界盒计算也能正常工作。
3. 方案(C)：适合需要单独控制bufferView参数（比如不同的字节对齐、目标GPU缓冲区类型）的场景。多个bufferView可以拆分同一个大buffer的不同区域，既保持了buffer的复用，又能为不同网格的属性设置独立的存储配置。
4. 方案(D)：仅适用于完全独立、无共享数据的网格，或者需要将不同网格的buffer分开加载（比如按需加载）的场景。这种方案的文件体积最大，内存复用率最低，一般不推荐大规模使用。

three.js的处理逻辑 #

three.js解析glTF时，会根据accessor的count和byteOffset来提取对应网格的顶点数据。如果多个网格共用同一个accessor（方案A），three.js无法区分每个网格的顶点范围，会默认将整个accessor的数据绑定到每个网格，导致：

• Box3.setFromObject计算的是整个accessor的顶点范围，而非单个网格的；
• 每个网格都会复制一份相同的大buffer数据到GPU内存，造成严重的内存浪费。

three.js的设计假设是：每个网格的属性对应独立的accessor，accessor可以共享bufferView或buffer，但必须明确自己的数据范围。

通用最优布局方案 #

1. 优先选择方案(B)：当多个网格共享顶点数据时，用不同的accessor指向同一个bufferView和buffer，通过accessor的byteOffset、count参数划分各自的顶点范围。这种方案兼顾文件体积、内存效率和解析正确性。
2. **方案(C)**作为备选：当需要为不同网格的属性设置不同的bufferView参数（比如不同的target）时使用。
3. **方案(A)**仅用于完全相同的实例化网格（此时应结合glTF的mesh.instances机制，而非直接共用accessor）。
4. **方案(D)**仅用于完全独立、无需共享数据的少量网格。

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