云风的 BLOG: fbx 到 gltf 转换问题

我们的游戏引擎采用的资源格式是 gltf 2.0 。

gltf 在这几年发展很迅猛，我认为是 3d 文件格式中标准化做的最好的一个。可惜，游戏行业中，美术创作人员常用的 max maya 等工具对其支持还有瑕疵。Autodesk 在 2019 年作为 contributor 成员加入了 Khronos 组织，在 max maya 这些 Autodesk 工具中看到官方的 gltf 支持应该不会等太久。来自官方的消息，‎在 2020 的 3 月底，gltf 加入官方支持已经处于 Under Review 状态。希望今年内可以看到。

因为 Unity 的流行，fbx 是游戏行业目前的实施标准。但 fbx 是一个私有格式，并没有任何公开的标准文档。而且其格式设计有很多历史包袱，甚至连字段名都因为有 typo 而在解析的时候有多个错别字兼容备选。我们在一年多以前确定使用 gltf 格式时，已经做好了这两年过度状态的准备。工作重点就在 fbx 转换到 gltf 的工具。

fbx 到 gltf 的转换工具看似很多，但实际用起来却有各种问题。这里记录一下我们用过的方案。

一开始，我们引入了 assimp 这个工具。但有一次一个复杂的模型转换失败，我开始尝试修 assimp 的 bug ，顺便阅读了 assimp 的 fbx 导入模块。这个过程发现 assimp 比较臃肿，fbx 的 importer 部分质量也不高。fbx 文件格式本身并不复杂，assimp 用了一系列复杂的方法（可能源于它要解决的问题更麻烦）来解决这样一个不算复杂的问题。

同时，我还发现 assimp 整体的编译速度实在是太慢，超过了整个引擎项目；而且它在 mingw/gcc 上有更多构建问题。我给 assimp 提过的几个 pr 都是解决 mingw 的编译问题。

最后，我们放弃了 assimp 。记得当时还有一个遗留问题一直没有解决：在 Windows 上生成 DLL 版本时，会因为 C++ 导出符号太多，超过 64K 个而链接失败。最后不得 disable 几个不常用的文件格式来绕过该问题。

之后一个短暂的时间里，基于我阅读 assimp 中 fbx 编码器获得的知识，我尝试自己来写一个给 Lua 用的 fbx 解析模块。因为 gltf 是用 json 组织数据的，我认为只要我能把 fbx 的数据结构加载到 lua 表中，再做 gltf 的导入也不会太难。

没过多久我便放弃了这个工作。因为我发现，解析 fbx 本身不难，也不需要太大工作量。但数据结构的转换是一个非常繁杂的工作。一不小心就会有考虑不周的情况。这也是为什么世界上已经存在这么多开源转换工具的项目，临到用时都会碰见问题。以我一己之力，去维护这么一个新项目是脱离初衷的。毕竟我们是在做游戏引擎，而没有那么多人力去维护一个 3d 文件格式转换工具。

经过一番考察，我们选择了 Facebook 发布的 FBX2glTF。在当时看来，大厂出品质量有所保证。而且在 2019 年底看来，这个项目还是颇为活跃的。（最新的发布版 0.9.7 于 2019 年 9 月发布。）不幸的是，之后 Facebook 似乎放弃了维护。

我们在用这个项目的一年间，发现过一两个小 bug 。但是因为上游不再维护（合并 PR），我们改成自己维护一个私有 fork 。

直到最近，使用我们自研引擎的项目陆续开工，发现了更多的 bug 。最近在花了一段时间维护这个转换工具后，我决定再换一个解决方案。

目前的选择是使用 blender 做 fbx 到 gltf 的转换工作。blender 作为一个开源项目，对开发者非常友好。它可以方便的在命令行使用内置的 python 脚本，而不必启动其 GUI 。gltf 唯一官方的导入导出库就是给 blender 做的插件。

同时 blender 对 fbx 的支持也非常好。fbx 最为详尽的非官方文档，就是由 blender 维护的。

最后：

我们的游戏项目已经开工，先招聘程序开发的小伙伴一名。工作地点在广州，属于阿里互娱的正式编制，职位大约是 P6 水平。工作内容是用我们的自研引擎开发一款手机游戏。

由于我们的引擎只提供 Lua 接口，所以开发工作基本上是基于 Lua 开发。熟悉并喜欢 Lua 语言便是基本要求。

由于引擎还不算成熟，会有一些底层的开发（优化？）工作。而且 Lua 作为嵌入式语言，通常也需要用 C/C++ 开发一些模块。这个职位需要有一些 C/C++ 开发能力。

另外，我们引擎使用了大量开源项目。日常开发会涉及编译构建这些开源项目。所以需要能独立解决编译构建中的偶发的问题。同时对 git 的使用会有一些要求。

如果有同学有兴趣，可以根据我 blog 上留下的 email 联系我。

或许我们的这个职位薪资待遇上没有什么特别的吸引力，但我相信阿里互娱可以提供一个不错的发展平台。另外，作为我带的团队，这两年我坚持的理念是：提高工作时间的效率，不用工作时长掩盖效率的低下。我们已经坚持了两年每周五天每天 8 小时工作时间零加班，应该还能坚持下去。

Comments

云风大哥一套技术栈持续的用很多年，替换成本很高了，而且队伍练出来了，不会再换的。
底层C是具备统治能力的，上层选lua或者node描述，适合队伍，有战斗力，就是OK的

Posted by: Xhacker | (14) July 9, 2021 10:37 PM

lua没有搞头了，不如去深度参与一下nim语言，这东西才是正确的方向。语言本身已经很成熟，但目前生态还不是很成熟，元编程能力极其强大，C/C++是对汇编语言的抽象，nim是对C/C++的再一次抽象。nim的套路不是搞什么jit而是直接编译成C/C++代码再二次编译，Python的语法, C/C++的性能相当爽。

https://www.youtube.com/watch?v=8SoJR3sCaR4

Posted by: noop | (13) May 29, 2021 01:02 AM

可以接受远程办公吗

Posted by: cx | (12) May 1, 2021 11:15 PM

云风，提个意见。现在还用lua有点浪费，golang开源的2d引擎也有不少，迟早有商业版的出现，第一个吃螃蟹的总是机遇挑战并存，跟进的就挑战大了。
现在的手机资源已经很充足，相信用GC也不会对一般的2d游戏有多大影响。但语言架构对后续的维护和开发影响很大吧

Posted by: abvic | (11) April 23, 2021 05:34 PM

难过。。应届生技术肯定过不了，真的很想和云风大佬一起共事

Posted by: 后悔摇摆 | (10) April 21, 2021 05:19 PM

965这个实在是给力，就应该这样整，我这种31岁的，没法承受长期99了。昨天晚上学UE4写插件整到11点半，第二天就很没精神了。
可惜就是职级低了点，我目前就处于P7级别的待遇，再加上某些原因实际待遇应该是高于P7。P6就没啥兴趣了。
C++8年，OpenGL4年，OSG贡献者，主要方向图形学。看以后有没有机会和大神共事~

Posted by: Kent | (9) April 21, 2021 01:49 PM

是否有与引擎开发相关的职业?

Posted by: YuqiaoZhang | (8) April 19, 2021 02:53 PM

说错了 965
能推开965，说明boss能顶住很大压力啊
不过，965or996和效率高低关系不大
1.拉齐大家的时间，毕竟工作要协同
2.一个人能做的事，尽可能一个人做，减少沟通，提高效率

能跟大神一起工作，也算是福利啊

Posted by: threezhiwang | (7) March 25, 2021 04:39 PM

我想和云风大神一起上班，但就是怕他不要我

Posted by: 梨花 | (6) March 25, 2021 10:55 AM

不好意思，前面的回复中有错别字和病句，因为无法编辑，所以没法修正，只能向大家 Say sorry 了。

PS. @Cloud 客户端引擎什么时候开源啊，最近刚好要学习 ECS 框架和客户端开发，很想拜读新作。

Posted by: Theo | (5) March 25, 2021 12:29 AM

“提高工作时间的效率，不用工作时长掩盖效率的低下”
真的太赞了，现在很多无能的管理者，在遇到各种问题时，给出的解决文案都是“加班”。这是用员工的工作时长来掩盖自己的无能，更可耻。