太长不看版

Node.js + fbx2gltf / obj2gltf / ……（初步模型转换） + @gltf-transform （精修）(+ sharp / ……（贴图处理）)

背景

手里有个网页3D模型展示的项目，内核选了three.js。虽然three.js也可以用FBX之类的传统格式模型文件，但目前来说支持最好的还是glTF格式。

需求

有相当数量的模型资产是以FBX+贴图包的方式储存的，需要按照特定的规则进行转换。

过程

1. Java类库

  由于应用服务器用的是Java，最初想找一个Java类库来处理。

  结果：只找到一些收费类库，试用的效果并不理想。

2. Node.js + fbx2gltf

  glTF官方推荐列表里列出了脸书版fbx2gltf转换器，npm上也找到了Node.js环境下的封装包，就拿来试了下。

  结果：可以用，但接口参数太少，不能完全满足要求。其中，内嵌TGA格式贴图不能自动转换成PNG/JPEG格式最为致命。而fbx2gltf的内核是用C++写的，定制开发搞不定。

3. Node.js + fbx2gltf + three.js (+ jsdom & node-canvas)

  既然最终渲染用three.js进行，而且three.js也有glTF导出功能，就试着引入工程。

  结果：浏览器环境的JS库和Node.js的结合那叫一个酸爽……代价不小，引入jsdom和node-canvas作为浏览器环境模拟，再对three.js中涉及文件读取的类进行改写以后，勉强整合了。

  ………………

  …………

  ……

  然后栽在了贴图转换上（进行了一些相当原始的原生Node.js处理，然后内存不足）

4. Node.js + fbx2gltf + three.js (+ jsdom & node-canvas) + 外部图像处理（自制Java库）

  反正都已经这么地精工程学了，不介意炸得再猛烈一些吧？（

  自己写了个简单的Java图像处理，主要是应对glTF里那些多通道缝合贴图，然后用Node.js的child_process调用。

  结果：能用，满足需求，就是吃内存吃的有点狠，处理速度也有点emmmmm……

  （这个版本存活了很长一段时间）

5. Node.js + fbx2gltf + three.js (+ jsdom & node-canvas) + sharp

  太过地精工程学也不是好事，一开始考虑先把图像处理至少先搞成Node.js的，调查了一段时间找到了sharp，拿来试试。

  结果：单独写贴图转换没啥问题，甚至自己找到TGA和BMP的读取库接到了sharp上，很快！

  然后整合的时候……作为浏览器模拟环境的node-canvas就和sharp打起来了……

  sharp甚至在官网安装说明里专门有一条来解释和node-canvas的冲突……

  幸好只在Windows环境下有这个问题，Linux没有，WSL走起~

6. Node.js + fbx2gltf + @gltf-transform + sharp

  但总是绕着走也不是个事……尤其是WSL下的Node.js还是比Windows版Node.js要慢，那……把three.js扔了？

  总算是找到了目标库：@gltf-transform，支持Node.js环境，glTF格式的把握也很到位。

  不过改代码的时候遇到些麻烦：three.js侧重于渲染，它的模型结构是一棵树；@gltf-transform侧重于数据处理，它的结构……和glTF格式内部结构更接近，各种资产是分类保存的。

不是总结的总结

能用和好用区别还是很大的，地精工程学可以不用还是别用为妙，时间充裕的时候还是多找点工具库对比下。