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