简介
Unity 引擎开发者宣布于2015年十二月“官方正式支持”WebGL。自此点看来，Unity 可被认为是 3D Web 领域的竞争对手 。因此可以对成熟和完备的 Blend4Web 和 Unity 进行有趣的功能比较。
我创建了三个不同复杂度的测试应用作为基准。这些基准专为两个引擎同时创建，完全对称。他们的场景，对象，纹理，甚至 材质设置几乎相同。没有针对任一方引擎有特别的优化或不利之处。使用默认的开箱即用功能。
虽然在某些情况下，我只能即兴。尤其是，为了使屏幕分辨率的移动设备上相同，一行相应的 Blend4Web 文件代码被添加到 Unity HTML 文件中（我们要公平，对吧？）：
所有场景和模型都在 Blender 准备，然后经过纹理和导出到引擎中。在某些情况下，因为他们应该恰好在哪里，所以我使用 Empty空 物件放置照相机和光源代替(因为这些 Unity 无法从 blend 文件导入)。
比较基于几个标准: loading time加载时间，FPS (亦称 frames per second 帧速率)和 memory consumption内存消耗。此外，加载时间测量两次: 首先，是一次冷 启动与浏览器缓存清除，然后作为从缓存中检索大部分数据的热启动。这有助于我们确定哪些引擎可以在浏览器启动场景时， 有更快，更好的效率。您知道的，人们通常不喜欢等太久...
第一个测试
这项和随后的试验是在谷歌 Chrome 53 浏览器于 PC 机上进行（英特尔 i5-3570，8RAM，GTX 650，屏幕分辨率为 1680х1050），摩托罗拉 Nexus 6，三星 Galaxy S6 Edge 和 苹果 iPad 3（Safari 10 浏览器）。
这是一个非常简单的场景，类似于一个游戏的设计。有几个模型，几个光源和基本的动画。这里没有使用先进的技术。
试验 #1. 加载时间，冷启动（以秒为单位，越少越好）。
测试结果已经很有趣了。我们可看到，Blend4Web加载场景比 Unity 快得多。
这是因为建立一个 WebGL 项目时，Unity，在默认情况下，压缩了文件(相当大)。然后，下载完成后，应用程序在客户端应用 程序中完成对客户端提取。当然，这需要额外的时间。别忘了屏幕加载，这增加了更多的几秒钟，也与 WebGL 本身的初始化 有关。第二个表（热启动）显示两个引擎的效率差异特别惊人：
试验 #1. 加载时间，热启动（以秒为单位，越低越好）。
这是引擎需显示并加载场景的“确切”时间。Blend4Web 几乎一瞬间，而其竞争对手则需要六倍的时间。当然，您可通过移除启动画面来缩短加载时间，付费版的 Unity 会移除它，但这不太可能使得本来的初始化加快。
试验 #1. 帧速率 (越多越好)。
大家最喜欢的 FPS 也就是一个非常重要的标准了。没有人喜欢冻结或停顿。
在这里，Blend4Web 与 Unity 表现几乎不相上下，但只有在 PC 机上。在移动设备上的应用，Blend4Web 以 60 FPS“顶到天了”。不幸的是，似乎没办法在移动浏览器上限制 FPS。而在台式机上，谷歌 Chrome 浏览器则运行在“--disable-gpu-vsync” (禁用 GPU 垂直同步) 选项上。
Unity 显示了一个小不同的结果。只有 Galaxy S6 能够取得扎实的成效。苹果 iPad 3 能只得 9 分，而摩托罗拉设备完全无法运 行测试场景。
试验 #1. 内存消耗，MB（越少越好）。
内存消耗数据是由谷歌 Chrome 桌机浏览器里边的 Task Manager任务管理器 中取得。正如您所见，这两款引擎都表现出很好的效果。
说实话，我期待着一个不同的图片来解释 Unity 应用程序造成的浏览器崩溃。但测试没有显示出内存消耗的主要差异，至少对 于这个简单的场景来说。令人惊讶的是，这使得在 Nexus 上的浏览器崩溃。
第二个测试
接着，这里是“海洋中的海岛”场景。它尚未优化，既笨重又肥大。相信我，我没有做任何事情来使它适合运行在移动装置上 ！
这个场景最复杂的事是让两个引擎看来一样。这在 Blend4Web 很容易 – 模型和景观都在 Blender 里边创造， 水的材质 和环境 也在里边做了，没有什么复杂。
但对 Unity 来说，有些问题。首先，我决定不使用 Unity 提供的地形。雕塑和植树容易且有趣，但这种解决方案尽管很方便，却可能得多花点时间。所以，我直接从 Blender 导出了一个场景，包含景观模型和已放置好的对象。这让我使两个场景尽可能 地相似。
其次，像是树叶从背面透明方面，基本的 Unity 着色无法使用双面材质。我试图用其他现成的材质像“树叶”，但因为某种原 因，它并没有帮助。所以我决定不进一步研究，而是发现了在线的第三方 着色材质，这完美的完成我的任务。
但，就让我们瞧瞧测试结果吧，因为真是令人震惊！
试验 #2. 加载时间，冷启动（以秒为单位，越少越好）。
试验 #2. 加载时间，热启动（以秒为单位，越少越好）。
第一件事是，在运行 Unity 应用程序时，Nexus 的浏览器再次崩溃。Unity 也表现出很长，几乎太长，的加载时间。有趣的是 ，这引擎，“冷”和“热”的启动时间几乎没有区别。Unity 似乎花费了不可思议的时间准备展示的场景。
试验 #2. 帧速率 (越多越好)。
这项测试在性能方面也表现出有趣的结果。两个引擎在 Galaxy 设备上显示几乎相同的 FPS 帧数，但在 PC上的差异非常显着。 有趣的是，在不同的引擎中改变场景的大小也会对 FPS 带来不同的影响。当从相机看着岛上缩小退后时，Unity 到达最高值。 而 Blend4Web 是尽可能靠近岛时，会表现出最好的结果。看来，这两个引擎使用的是不同的优化方法。该表格显示最大可能 的 FPS 值时，而这对于特定引擎是最有利的。
现在，关于苹果 iPad 3 的意外崩溃…是的，您可看到，这已经加入了Nexus 设备。不像摩托罗拉，虽然，它奋勇战斗到了极 限，接着在启动场景之后崩溃了。所以我们能够测量加载时间，但，在这种情况下 Unity 应用程序的工作容量原来是零。
也许原因隐藏在下表中。
试验 #2. 内存消耗，MB（越少越好）。
第三个测试
我当然也不能错过物理这块，所以最后的测试是专为此而来。场景中有个立方体，是封闭的内部空间，里边有几十个小球。立 方体缓慢旋转，使球体滚动。
没有复杂的着色和效果。现场只使用刚体和简单的碰撞。
像往常一样，在这个场景里它花了一些努力使物理现象出现。我想您已经猜出了问题是什么。
这些球体顽强地试图离开笼子，并简单地滚出自己的极限。这现象在两个引擎都发生。最终，在PC平台上，我找到一个可接受 的解决方案，所有对象都如预期的那样，但在移动设备上，这场景看来很可笑。因此，引进了一个新的测试标准:物理稳定，或 “外围球体”，我是这么叫它的。现场景跑了一分钟，然后检查笼子里留下了多少球。留下的球越多，越好。
现在...
试验 #3. 加载时间，冷启动（以秒为单位，越少越好）。
试验 #3. 加载时间，热启动（以秒为单位，越少越好）。
试验 #3. 帧速率 (越多越好)。
注意在移动设备上 Blend4Web 场景同等的 FPS 数值。这是安全的假设，如果不受垂直同步的限制，该引擎可以提供多于60 帧以上的数值。这是因为 Blend4Web 可以在一个单独分开的线程（处理器）中处理物理过程。据我所知，这是 Unity 无法做 到的事情。这是获得如此高 FPS 数值的原因，同时，如您所见，稳定相当性高。
试验 #3. 物理稳定性（球失去的百分比，越少越好）。
如同我所说，Unity 和 Blend4Web 在 PC 平台上的表现都很好。所有的球体都待在它们该待的地方。
Galaxy S6 （Blend4Web）是在移动设备的领导者，而 iPad 3（Blend4Web）无疑是个局外人。Unity 应用程序于此标准测试下失败， 但在 PC 平台除外。
一切的一切，Unity 在 WebGL 的物理表现上，整个留了个不好的印象。加载场景后，屏幕冻结，几秒钟 后，它才终于达到了期待已久的 FPS 数值。这当然只在 PC 。在移动设备上，一切都更加地令人沮丧。少少几秒钟内大部分的 球体就掉出来了。然后，场景几乎空了，所以该应用程序能够实现扎实的每秒 60 帧速率。
这么不靠谱的可能原因，或许是 Unity 的物理行为在以下的记忆内存测试结果撒了谎。
试验 #3. 内存消耗，MB（越少越好）。
与前两个场景相比，第三个证明了更多的内存消耗，两个引擎都相同。
Unity 应用程序以一种非常奇怪的方式表现。就在场景启动后，它消耗了大于 700 Mb 的内存，几秒钟后，这个数值降到400 。甭说，这时候，不给力的移动设备已失去了它们所有的球。因此它们的 FPS 数值不准确，因为它们在渲染一个空的立方体， 里面没有物件。
如何解释这种行为，这我还真不知道，但事实是事实: Unity 在 WebGL 的物理表现无法给人留下好印象。
结语
测试结果证明有点令人惊讶。我希望这篇文章不仅对用户有帮助，且对开发者也有帮助。
这里是链接的文件。请注意，Unity 链接实际上有作用，他们只是没显示装载。并请铭记在心，Unity 载入相对慢得多。
测试 #1: Blend4Web | Unity
测试 #2: Blend4Web | Unity
测试 #3: Blend4Web | Unity
源文件
请随意测试并分享自己的经验！