3d-tiles-tools中B3DM转GLB体积增大的问题分析

问题背景
在使用3d-tiles-tools工具进行B3DM格式到GLB格式的转换过程中，开发者发现转换后的文件体积从1475KB增加到了2081KB，这显然不符合预期。经过深入分析，发现这是工具在处理批量ID(_BATCHID)属性时的实现缺陷导致的。

技术原理
B3DM(Batched 3D Model)是3D Tiles规范中的一种瓦片格式，主要用于存储批量3D模型数据。GLB则是glTF格式的二进制版本，是当前3D模型交换的主流格式。在格式转换过程中，需要将B3DM特有的属性映射到GLB/glTF的标准属性。

其中，B3DM中的_BATCHID属性用于标识模型中的批量元素，在glTF 2.0中对应的概念是_FEATURE_ID_0属性。转换工具需要正确处理这种属性映射关系。

问题根源
通过分析转换前后的GLB文件，发现问题的核心在于：

原始B3DM中的所有图元(primitive)共享同一个_BATCHID访问器(accessor)
在转换过程中，工具为每个图元都创建了新的_FEATURE_ID_0访问器
导致原本共享的批量ID数据被多次复制存储
原始_BATCHID数据也没有被正确清理
此外，还发现一些历史遗留问题：某些非常旧的B3DM文件中，批量ID属性可能命名为”BATCHID”(不带下划线)，这种情况下转换后会出现同时存在”BATCHID”和”_FEATURE_ID_0″属性的冗余情况。

解决方案
针对这个问题，可以从两个层面解决：

临时解决方案
对于急需处理的文件，可以使用glTF-Transform工具进行后处理：

使用dedup()函数去除重复的访问器数据
使用prune()函数清理未使用的资源
这种方法虽然能解决问题，但属于事后补救，不是根本解决方案。

根本解决方案
需要在转换工具中改进实现：

在_BATCHID到_FEATURE_ID_0的转换过程中，只创建一次共享访问器
确保正确识别和处理各种命名变体(BATCHID和_BATCHID)
转换完成后彻底清理原始_BATCHID属性数据
优化属性映射逻辑，避免数据冗余
技术启示
这个案例给我们几点重要启示：

格式转换工具需要深入理解源格式和目标格式的语义对应关系
共享资源的处理需要特别小心，避免无意中的数据复制
对历史遗留格式的支持要全面考虑各种变体情况
性能优化(如数据体积)应该在转换过程中而非转换后考虑
总结
3d-tiles-tools工具在B3DM到GLB转换过程中出现的体积增大问题，揭示了格式转换工具开发中的一些典型挑战。通过分析问题根源，我们不仅找到了解决方案，也加深了对3D模型格式转换技术的理解。这类问题的解决往往需要同时考虑格式规范、实现细节和性能优化的多方面因素。
————————————————
版权声明：本文为CSDN博主「柳帆坦Brittany」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/gitblog_07916/article/details/148991063