Three.js 及其局限性

WebGL刚起步没多久, Three.js不知怎么就红了, 可能是受Google搜索结果影响太大吧.

Three.js自己对自己的描述是专注性能而非易用性. 它提高性能的方法并非是特别精细编写JS代码, 而是把很多计算工作转移到显卡上(利用Shader), 这就给它带来了很多局限性. 如果就一句话总结, 就是Three.js很适合渲染静态模型, 或者少量动画的模型, 同一个模型渲染很多份基本不影响性能. 但是Three.js不能处理复杂的动画模型, 尤其是骨骼动画.

骨骼数量

刚才提到, Three.js依赖Shader处理很多计算, 其中就包含蒙皮计算. 但是浏览器实现WebGL的引擎(如ANGLE), 是对Uniform数量有限制的. 骨头一多, Three.js直接无法处理动画了, 这个限制在大多数浏览器上是58个骨头.

一般来说, 复杂的骨骼动画很少全全交给显卡处理, Three.js 这么做可能就是想拼一下测试评分什么的吧. 实际影响非常大, 现在一般的3D游戏, 小人物有个50根不到的骨头, 稍微精细一点的模型都超过100个. 如果使用Three.js, 发现1/3的模型没法渲染, 再推翻重来真是灾难性的.

蒙皮(骨骼-顶点绑定数量)

在大多数情况, 一个骨骼绑定了1-4个顶点. 这个是大多数3D软件给定的范围, Three.js本身是支持一个定点绑定4个骨骼的, 但是有两个问题.

• 因为涉及到Shader输入的问题, 这个4个是硬编码4个. 如果有第五个出现, 就算改Three.js代码也很麻烦.

• 其Loader只能读取两个, 天知道为什么写成这样, 不过这段可以简单修改Three.js源码使其上升到4个. 

其他碎碎念

• 文档的缺失和基本没人响应的Issue List, 很大程度上增加了它的使用难度.

• 代码里没有足够的Fault Tolerance.

• 紧耦合的封装限制了和其他库协作的可能性.

作为一个由个人领导的开源项目, 要求太高的确很过份. 我这里只是列出一些限制, 供大家决定是否使用Three.js做评估使用, 以免到项目后期才发现好多事情不能做的悲剧.