« skynet 处理 TCP 连接半关闭问题 | 返回首页 | 服务的创建和退出问题 »

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

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

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

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

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

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

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

10几年前你写的去澳洲学习 BigWorld 那 Blog 里,就已经感叹过人家工作时间的高效了,现在能在工作中执行,真是团队之幸。

我们是 9:30 上班 18:00 下班。中午一个小时午休。并没有 995 。

职级低995没啥吸引

一直想和您共事,怎奈怕技术不过关寒了您的心,心塞。。

Post a comment

非这个主题相关的留言请到:留言本