Unity WebGL发展计划

发表于2015-07-10
评论0 2k浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏程序行业精英群

711501594

在今年的三月发布的unity 5.0中,我们展现了WebGL的技术预览。之后,Google停止了(默认下的)Chrome浏览器中对于NPAPI的支持(意味着unity web player将不能在Chrome上使用),这极大促使了Unity的开发者们将WebGL作为一项新的替代技术。一些人已经发布了使用Unity WebGL开发的游戏,但我们仍然听闻有些人在导入现存的Web Player游戏时遇到了问题。需要特别注意的是,WebGL和Web Player ,尽管它们针对的目标相同, 但却是两种非常不一样的平台,这意味着并不是在Web Player能实现的所有功能现在都能在WebGL上一一实现。更值得注意的是,WebGL不仅仅是一项全新的技术,它更是一个可以快速迭代的生态系统,所以我们期待或许在一年之后,这项技术能带来更多不同的可能。

 

因此,我们想跟大家分享在WebGL上即将发生的一些改变,以及我们对于这项技术的未来打算。

 

Unity 5.1中的WebGL

 

在unity5.1中,我们的重中之重是去修复在unity 5.0中首发的WebGL版本中存在的漏洞。并且,我们IL2CPP团队在过去的几个月中一直在致力于修复IL2CPP中的漏洞,在5.1版本中大家会看到相应的提升。因为WebGL使用IL2CPP作为它的脚本运行环境,这些提升也极大帮助了WebGL平台。

 

除了漏洞修复,在Unity 5.1中的另一项新特性:Crunch texture compression(材质压缩)也会使WebGL用户特别感兴趣。该功能可以用JPEG形式的压缩比例去压缩材质,然后进行传输/储存,并在运行时解压成有利于GPU的DXTn材质。这将极大降低WebGL内容的传输大小,因为材质大小往往在资源中占据最重的比例。

 

让我们考虑下5.1版本之后的发展,来看看我们之后的发展计划,以及WebGL平台在未来会推出的版本。

 

内存问题方面

 

当前大家在使用Unity WebGL时遇到的最大问题之一就是,浏览器(特别是Chrome)在尝试运行Unity WebGL内容时会消耗大量的内存。以下是遇到的具体问题:

 

需要为WebGL内容分配锁定的内存空间。这是用于Unity运行的内存。该内存的大小可以在Web Player的设定中进行配置,这部分内存需要支持Unity在特定时间点载入所有对象和素材。你可以使用Unity中的Memory Profiler对使用的空间进行debug。这需要在浏览器堆中有保护的内存空间。如果浏览器的内存较低或是堆损坏,会导致分配内存失败。

 

浏览器需要过多内存进行Javanoxss解析。Unity放出的针对WebGL player构建的JavaScript代码比其他常用的JavaScript代码在体积上要大很多,而JavaScript可能需要大量的内存去解析这些代码。Chrome的V8有时会因为遇到这样的问题而导致崩溃,因为它无法分配出足够的内存进行解析。在Firefox中,这样的问题没有那么严重,因为Firefox使用asm.js对JavaScript进行AOT编译,这会带来更小的内存开销。

 

从许多使用案例来看,以上的问题是当前WebGL遇到的最大的问题,而且这处理起来并不简单。现在,我们能做的是减少代码的发送,我们已经在上个HackWeek(Unity内部头脑风暴活动)对此做了实验,来测试我们能在一个项目中降低多少WebGL的分发体积。经过一周的测试,我们能够创建一个分发包大小仅有1.2MB的简单Unity项目,这是通过代码剥离,提升编译设置,以及删除冗余等方式达到的。然而这些只是理论上的可实现的,其中一些改进是不具推广性的。我们在这一周收获了很多,我也期待从Unity 5.2版本开始构建的产出大小能够大幅度降低。同时,我们也在开发相关的工具,让开发者可以直观可视地了解哪些代码模块被包含在了构建中,有多少代码被生成,以及它们被包含进构建中的原因。我们计划在Unity未来的版本中(最早在5.3版本中)发布这些工具,而这会使极大帮助用户去分析和优化他们的构建产出大小。降低代码产出大小也能极大地优化启动时间,并降低解析代码的延迟时间。

 

但是,我们期望能依靠更先进的浏览器技术来最终改善这些内存问题。所有浏览器都在朝着64-bit的构建发展,这会使得构建的地址空间变大。更重要的是,Mozilla, Google和Microsoft正在研发一种名为WebAssembly的全新技术,将asm.js代码转换为字节码形式,而这些字节码能够非常高效地被编译为原生代码。我们非常期待这项技术,因为它能极大降低读取时间,内存开销和WebGL的分发包大小。

 

数据压缩方面

 

这点与上文谈论的内存问题联系紧密,分发包大小是Unity WebGL当前需要处理的问题根源。分发包大小会影响下载时间和内存使用。为了保持下载时间合理,我们想让数据以压缩的形式被传输。现在,我们依靠http协议中的gzip压缩支持来达到这个目的,因为该技术能让浏览器在下载过程中进行解压处理。然后,使用它其实并不十分便捷,因为它经常需要在服务器端进行手动设置来保证正确运行。此外,gzip与更现代的压缩算法比起来效率大大降低了。

 

在未来的版本中(当前计划为Unity 5.3),Unity会原生支持全平台的数据文件内部的素材压缩,也将使得WebGL用户不再需要依靠http进行素材数据的压缩(我们可能会针对代码做一些定制化的压缩处理)。这会使WebGL内容的分发变得更为简捷,数据也会在被使用前一直保持压缩的状态,进而降低素材的内存占用(我们的一些测试也说明,因为更少的内存带宽占用会使素材的读取时间降低。)

 

性能表现方面

 

我们在去年发布了一些WebGL性能表现的参照基准,对比了基于浏览器和原生环境的情况,发现了在某些领域拥有不俗的性能表现,也通过对比在浏览器,WebGL和原生环境,发现了性能表现的差距。我们希望在未来能够缩小这些差距。我们发现,大多数存在于原生环境与WebGL间的表现差距,可以通过使用SIMD和/或者多线程的方式进行优化。这两项功能在未来会出现在WebGL中。

 

SIMD.js:可以将SIMD支持添加到Javanoxss语言中。Mozilla, Google和Microsoft都在计划添加此项支持。我们可以使用这项技术在WebGL上得到与其它平台相同的表现提升。

 

Shared Array Buffers:可以让WebWorkers (Javanoxss中相当于线程) 分享同样的内存,这使得将当前的多线程代码编译成JavaScript成为可能。Mozilla已经实践了这项技术,他们已经成功地运行了Unity WebGL内容,而这些内容也能通过多线程运行。他们运行了我们的参照项目,在某些方面达到了非常好的基准效果,并比运行多线程取得了更高的分数。Google已经宣布增加Shared Array Buffers支持的计划。

 

移动端支持方面

 

另一个大家关心的问题是,我们何时打算推出Unity WebGL的移动端支持。现在我们并没有做任何打算,并且会尽量避免在移动端运行内容(然而运行并不会出现警告)。总得来说,运行成功率还非常低(一些高端的安卓移动设备产生了不错的结果,但是在大部分用户常用的设备上,效果仍不理想)。在极大改善上述的内存和性能表现的问题之前,我们不会看到移动端太大的改变,但在之后移动端的表现也会得到整体地提升。我们无法给出任何关于移动端支持的具体时间。我们相信随着未来的技术进步,这个方面会有所改观。

 

构建时间方面

 

另一个常见问题是,在WebGL项目中往往会花费很长的时间进行构建。Mozilla现在正在努力将整个emnoxssen 编译工具链移植到原生代码中(当前是基于混合语言操作),我们认为这将加大提升构建时间。在Unity 5.1中我们已经将emscripten升级成了新版本,将JavaScript优化转移到了原生代码中,相较于5.0版本,缩减了构建时间。

 

音效方面

 

现在,Unity WebGL使用一套定制的基于Web Audio的执行音效,这与其它所有使用FMOD的Unity构建平台有所不同。这让我们可以控制所支持的音效格式进行基本的播放,并调节音量和音高。这对任何目前可执行的音效功能都有效(我们会修复不能执行的漏洞)。

 

图像方面

 

WebGL是一个基于OpenGL ES 2.0的Javanoxss API。相比于其他平台,这在某些程度上限制了图像的处理能力,因为OpenGL ES 2.0无法支持许多我们可以在其他平台上实现的特性。Unity现在有一些硬性的编码规定使得图像功能与图像APIs绑定在了一起,这在以前是合适的,因为OpenGL ES 2.0被当做一个“移动”图像API,但当WebGL有可能在更高端的GPUs上运行该代码时,以前的假设就不再适用了。这使得视觉效果难以达到预期,尤其是运用到阴影和新规格的着色器上时。我们正在努力修复这一问题,使得着色器的特性可基于每个项目进行配置,而不是被硬性编码成各个图像API。

 

此外,在GDC2015上,我们演示了在WebGL 2.0上运行的Unity 5原型(基于OpenGL ES 3.0),这也会使WebGL的图像功能更进一步。在Unity 5.2中,我们计划加入实验版的WebGL 2.0支持,但我们不期望浏览器会支持在今年年底前发布版本中的API。

 

浏览器支持

 

现在,Unity WebGL支持Chrome, Firefox和Safari。在主流浏览器支持中,我们还欠缺Microsoft浏览器支持。当前的Internet Explorer版本中有WebGL支持,但是缺少Web Audio支持(所有我们无法播放任何的音频),而且表现也不尽人意。所以虽然IE浏览器可以读取内容,但是当前我们没有官方宣布支持。

 

我们期待在Microsoft Edge发布后情况会有所改变,这个即将发布在Window 10上的默认浏览器将取代IE。IE会支持Web Audio,也会支持asm.js,这会让Unity内容得以更好的呈现。

 

视频方面

 

Unity的MovieTexture现在尚未支持WebGL,理论上视频是可以进行播放的,但是我们现在没有这方面的支持打算,因为我们的MovieTexture音频播放无法在当前WebGL上使用。其实,简单地使用浏览器中的html5视频功能就将功能齐全的视频纹理解决方案整合到Unity WebGL上来。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台