« 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

云风大哥一套技术栈持续的用很多年,替换成本很高了,而且队伍练出来了,不会再换的。 底层C是具备统治能力的,上层选lua或者node描述,适合队伍,有战斗力,就是OK的
lua没有搞头了,不如去深度参与一下nim语言,这东西才是正确的方向。语言本身已经很成熟,但目前生态还不是很成熟,元编程能力极其强大,C/C++是对汇编语言的抽象,nim是对C/C++的再一次抽象。nim的套路不是搞什么jit而是直接编译成C/C++代码再二次编译,Python的语法, C/C++的性能相当爽。 https://www.youtube.com/watch?v=8SoJR3sCaR4
可以接受远程办公吗
云风,提个意见。现在还用lua有点浪费,golang开源的2d引擎也有不少,迟早有商业版的出现,第一个吃螃蟹的总是机遇挑战并存,跟进的就挑战大了。 现在的手机资源已经很充足,相信用GC也不会对一般的2d游戏有多大影响。但语言架构对后续的维护和开发影响很大吧
难过。。应届生技术肯定过不了,真的很想和云风大佬一起共事
965这个实在是给力,就应该这样整,我这种31岁的,没法承受长期99了。昨天晚上学UE4写插件整到11点半,第二天就很没精神了。 可惜就是职级低了点,我目前就处于P7级别的待遇,再加上某些原因实际待遇应该是高于P7。P6就没啥兴趣了。 C++8年,OpenGL4年,OSG贡献者,主要方向图形学。看以后有没有机会和大神共事~
是否有与引擎开发相关的职业?
说错了 965 能推开965,说明boss能顶住很大压力啊 不过,965or996和效率高低关系不大 1.拉齐大家的时间,毕竟工作要协同 2.一个人能做的事,尽可能一个人做,减少沟通,提高效率 能跟大神一起工作,也算是福利啊
我想和云风大神一起上班,但就是怕他不要我
不好意思,前面的回复中有错别字和病句,因为无法编辑,所以没法修正,只能向大家 Say sorry 了。 PS. @Cloud 客户端引擎什么时候开源啊,最近刚好要学习 ECS 框架和客户端开发,很想拜读新作。
“提高工作时间的效率,不用工作时长掩盖效率的低下” 真的太赞了,现在很多无能的管理者,在遇到各种问题时,给出的解决文案都是“加班”。这是用员工的工作时长来掩盖自己的无能,更可耻。 10几年前你写的去澳洲学习 BigWorld 那 Blog 里,就已经感叹过人家工作时间的高效了,现在能在工作中执行,真是团队之幸。
我们是 9:30 上班 18:00 下班。中午一个小时午休。并没有 995 。
职级低995没啥吸引
一直想和您共事,怎奈怕技术不过关寒了您的心,心塞。。

Post a comment

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