对于Web3D领域的两个非常优秀的引擎，大家肯定都不陌生，他们就是Three.js和Babylon.js。

说到构建WebGPU引擎，你一定会问为什么不是Three.js或Babylon.js？

Three.js是JavaScript语言开发。2010年，西班牙开发者Ricardo Cabello (Twitter: mrdoob)在Github上放出了第一个public版本。

Three.js 官网
https://threejs.org/

我们熟知的WebGL是在2009年被Khnoros组织提出，可以说Three.js的发展史，就是WebGL标准的发展史。

**Bablyon.js是TypeScript语言开发，**是由微软内部团队，于2013年主导的另外一款引擎。它的封装更加高层，功能也相对复杂很多，而且拥有很多比较成熟的工具，比如Node Material Editor。相比Three.js，Babylon.js可以说更像一款比较成熟的Web3D游戏引擎。

Babylon.js 官网
https://www.babylonjs.com/

但是由于timing的原因，Github上的Star数量，截止2022年2月，Three.js（78.8k）远高于 Babylon.js（15.8k)，Three.js依然是基于WebGL标准下最为流行的Web 3D引擎。

为什么不是Three.js or Babylon.js?

WebGPU标准的发展，也一直被广泛关注。Three.js和Babylon.js，已经在相应的分支，**做了WebGPU能力的接入和一些Demo的展示。**我们看到了他们的实现和demo，也更加的相信，WebGPU引擎这件事儿，大概率他们做不成。

因为Three.js和Babylon.js两个引擎架构都是为了WebGL而设计的，而WebGPU对比WebGL可以说发生了翻天覆地的变化，取消了全局状态机，给了开发者过多的权限来控制内存，增加了Compute Shader等等。因此，Three.js和Babylon.js不能说是支持了WebGPU，只能说接入了WebGPU，但是由于历史包袱，根本无法发挥出来WebGPU的优势。

口说无凭，通过一系列的测试，我们得出这样的结论。测试结果

Three.js的WebGPU Demo，跟WebGL Demo来比，几乎没有什么提升。封装更加高层和复杂的Babylon.js，WebGPU 的Demo的实现竟然比WebGL还要慢。

相比之下，目前我们的Orillusion官方放出的Demo，比WebGL引擎快了将近5倍。下一个版本的对比特性，我们已经快了10倍。如果发挥到WebGPU性能的极致，可以快出30倍。

https://demo.orillusion.com/ecs/example/asteroids.html

如果Three.js和Babylon.js真的想做一款可以充分发挥WebGPU性能的引擎出来，那只能壮士断腕，对引擎框架进行彻底的重构。因为Three.js和Babylon.js的历史包袱太重了，他们有大量的用户，有大量的功能实现，完全放弃而进行重新开发，这是需要巨大勇气的，而且我们目前没有看到任何这样的迹象。

所以有的时候，做的早不一定做的好，这也就是技术迭代带来的新机遇。

我们可以等未来某天Three.js和Babylon.js重构架构支持WebGPU，可能是半年？甚至是一年？但是，在这么好的一个时间节点，为什么中国的团队不能做出一款同样优秀的Web 3D引擎，实现弯道超车呢？

之前我们擅长于场景创新和商业模式创新。但是，在这样一个好的时间节点，我们应该把精力放在底层的技术研究上：这是一种思维模式的改变，更是一种认知的改变。

元宇宙正在朝我们走来，3D渲染的场景未来会暴增。有了核心的3D底层技术，上层场景才会有无限的可能。中国的技术开发者需要时间，中国的基础软件需要时间。在这个过程中，Orillusion希望能做出一点儿贡献。

我们期望打造第一个WebGPU中文社区，如果你看到了这篇文章，说明你已经是社区的种子成员了！欢迎你的加入！

目前社区处于内测期，新用户注册需要内部成员邀请，管理员审核之后才可以发帖、回帖。

为什么要开放社区？

为了让Orillusion的用户之间有更多的交流，并且可以将自己的经验分享给他人，让大家有一个开放自由的平台去讨论与WebGPU，引擎，渲染甚至更广泛的话题。

为了鼓励大家，本社区设立了“威望”机制。当您发出的话题或者回复补其他用户点“顶”即可获得一定的威望值，我们会根据大家的威望值固定时间发送一些小礼物。

最后,

希望大家一起努力建造一个开放、自由、专业的社区环境。

——————————————

社区管理员 小欧

随着元宇宙概念的爆炸式出现，3D渲染技术再次受到了巨大关注度。

沉浸、3D世界、虚拟社交、虚拟购物，这些都是元宇宙的概念实例。就像电影《失控玩家》那样，人们畅想通过AR/VR以及其他互联网技术，把现实世界的楼房街道、天气温度、人际关系等投射到虚拟世界，构建“元宇宙”，拥有一个网络分身。

但目前来看，要想实现这一构想，开发者们还有很长一段路要走。毕竟“元宇宙”的背后是庞大的3D虚拟世界构建，需要海量且高质量的3D内容支撑，以还原真实世界。R星引擎的游戏《荒野大镖客》除了游戏世界里各种各样让人拍案叫绝的细节之外，在画质上3D世界渲染的技术细节也仍然让人惊叹。

3D渲染技术的迭代路线分成了两种技术方案：Native和Web。

Native，是我们的电脑、手机等硬件设备，通过安装本地的应用程序APP，直接通过图形API和相关驱动调用显卡的计算和渲染能力，完成真实物体的3D渲染数字化的过程。

Web，是通过浏览器，在网页页面中，实现现实世界的数字化渲染的过程。

打趣的说，选择Native技术栈还是Web技术栈，这是一个哲学问题。两种技术方案都有自己的优势和劣势，同时双方的生态也都比较丰富，很多项目从最终的技术实现角度来说，选择哪一条路线都可以完成。

Native 3D渲染的发展

1992年，Khronos制定了第一代的渲染引擎的图形学的框架叫做OpenGL 1.0，包括现在很多电脑用的基本上3D应用都是基于OpenGL。OpenGL也在不停的发展，目前最新版是2017年发布的OpenGL 4.6版本。同时，也出现了专门为移动端设计的OpenGL ES版本。由于OpenGL是开源和跨平台的，不方便为Windows做优化，1996年，微软作为第一大操作系统的提供商，发布了自己的图形API Direct3D。DX5/DX6/DX9有很多游戏的代表作，《古墓丽影》《极品飞车》都是当时的作品。

发展到了2009年，微软提出了DX11版本，有一个比较大的特性，计算着色器。简单说就是在图形的渲染能力上，可以更加充分的调用显卡的并行计算能力。

2014年，微软发布了下一代图形渲染API DX12，同年6月份，苹果在WWDC大会上发布了自己的图形学API Metal。2015年，Khronos发布了Vulkan。最早是发布的 OpenGL，随着显卡能力的提升，OpenGL的全局状态机设计离线，已经无法调用和优化先进现代显卡的能力。可以说Khronos不在会全力以赴的长期升级和维护OpenGL，反而选择发布了全新架构的现代图形API，即Vulkan。

2014年这个节点，就形成了三种现代图形学API并驾齐驱的情况。目前所有电脑上的游戏，或者一些3D应用，包括CG渲染动画，为了达到最好的渲染效果，几乎都会采用这三种现代图形API。

Web 3D渲染的发展

总体来说，在Web上渲染3D内容的相关技术发展还是比较缓慢的。最早的时候在浏览器是无法实现3D内容的，需要安装Flash插件。在校内网时代，那些农场类的游戏应用，以及在浏览器里看视频音频，几乎都需要安装Flash插件。2020年的时候，因为有一些安全的问题和其他种种原因，Adobe宣布停止维护Flash这项技术。

在Flash的发展过程中，出现了HTML5的标准，简称H5。2008年的时候，H5雏形出现。人们不需要在浏览器里面装Flash的插件，能够直接播放视频音频，包括通过Web原生的Canvas组件实现一些动画效果。

真正的Web 3D的技术标准的出现，是WebGL。由于浏览器天然具备的易分享等优势，在Web中展示和渲染3D内容一直都具有大量的需求。Khronos在2009年启动WebGL标准的讨论和制定工作。WebGL思路很简单，就是依靠浏览器的内核，对OpenGL ES版本做打包和封装，然后就可以让浏览器里的这些JS前端开发者直接用Web环境去调用底层的图形学能力，最终展示3D内容。当然也就意味着WebGL能力被限制到了OpenGL的时代。

Web的技术在持续快速的发展。尤其2014年，Native侧已经出了三大现代图形API了: DX12, Vulkan, Metal。在2017年的时候，W3C就提出在Web侧发展下一代图形学的技术标准,即WebGPU。跟WebGL一样，WebGPU的思路就是对三个现代图形API直接打包，然后在实现跨平台的同时，让浏览器里面直接可以调用这三个现代图形API能力，实现高质量的渲染效果，调用GPU的强大计算能力。

WebGPU Wiki
https://en.wikipedia.org/wiki/WebGPU

我们熟知的Unity和Unreal就是典型的Native技术栈下的3D渲染引擎产品，而Web端也有大名鼎鼎的Three.js，Barbylon.js, Cesium.js 和 Playcanvas等等。面对这样两条路线，下面聊一聊关于技术栈选择上的思考。

Web优势1: 生态的发展和普及程度广

从技术角度来看，Web相对于Native的发展相对是缓慢的。因为很多最新的技术都会在Native上最先实现。但是因为Web本身独特的优势，跨平台，易分享，易协同等等，一直都很受技术人员和多种应用场景的青睐。

浏览器厂商的努力也不容忽视，尤其是Chrome。为了保证Chrome 100这个历史时刻的版本能尽早的发布，从94版本开始，将6周一更新提升到4周一更新。（Chrome 94版本也是第一个正式启动WebGPU API的商用版本，而不在是通过Chrome Canary的developer版本才能体验的WebGPU的能力。）

Chromium Blog
https://blog.chromium.org/2021/03/speeding-up-release-cycle.html

浏览器承载的Web生态正在飞速的发展。下面的开源报告中关于开源环境技术方向的统计后端是最多的。但是我们可以看到，第二个就是Web的生态，也证明了Web生态是非常有潜力的。

2020年开源环境技术方向

下面是2020年编程语言的分布报告。最多的是Java，第二就是前端语言JS，如果把HTML语言也包括其中，那Web的语言普及度优势将更加明显。这足以说明Web是一个快速发展具有巨大潜力的技术栈生态。

2020年编程语言的分布

2020中国开源年度报告

https://kaiyuanshe.cn/document/china-os-report-2020/2020%20%E4%B8%AD%E5%9B%BD%E5%BC%80%E6%BA%90%E5%B9%B4%E5%BA%A6%E6%8A%A5%E5%91%8A.pdf

Web优势2: 免安装客户端，跨平台特性

Native端，需要安装APP应用程序，在某些场景，对于用户来说是一个很高成本的行为。可以想象一下，如果你的家装设计师为你设计的室内3D全景渲染图，不是通过微信直接分享给你的（微信本身所有的分享内容都是基于Web），而是要求你要在手机或者电脑上安装一个几百M甚至几个G的应用程序才能观看，那是一种什么体验呢？

Web就很好的解决了这一个问题。我们不在需要为不同的场景安装不同的客户端，而是通过一个URL链接，就可以立刻浏览你想看到的任何内容。

换一个角度去思考，不仅不需要用户安装客户端，而是我们已经通过硬件设备中的浏览器触达到用户了。单独Chrome的全球装机量为26亿，占全部浏览器市场占有率的60%；排名第二个也是采用了Chromium内核的Edge浏览器，市场占有率为18%。

2020年-2021年全球浏览器市场占有率

基于Web环境做任何的内容开发，也都因为这种天然的跨平台特性，实现了降低研发成本的目的。Orillusion团队也极力打造Web端的3D渲染引擎。开发者们不需要在考虑为了一个项目开发不同的APP，来适配不同的操作系统。因为浏览器已经帮我们实现了不同平台的适配工作。只要在一台主机的Chrome里能正常打开，那么在其他主机的Chrome里也可以正常打开。

我们目前梳理了Native和Web在3D渲染这个场景中的发展历史和技术演进。同时，也从开发者生态和免客户端跨平台这两个方面，阐述了一些Native和Web技术路线的对比和分析。在接下来的内容里，我们会给出更加深入的思考，希望大家持续关注。

关于文章前面提出的打趣观点: 选择Native技术栈还是Web技术栈，这是一个哲学问题，也欢迎更多的Native和Web开发者一起留言，加入Orillusion社区参与讨论！

上一篇文章我们介绍了 Web 和 Native 的发展历程，对Web端的跨平台特性以及生态的发展和普及程度广的优势进行了分析，还没有看到的朋友们可以点击下面链接回顾一下哦

Web or Native 谁才是元宇宙的未来（上）？

相信看完这篇文章，你已经有了一些想法，今天我们继续来聊一聊关于Web和Native的技术栈选择，看看你是否也同意小鸥的看法呢～

Web优势3: 超级APP生态的嵌入

任何公司具备了超级APP之后，必然都会考虑打造应用内部的生态，将尽量多的场景和能力在自己的应用生态中统一解决。比如我们日常都会使用的微信、支付宝、淘宝等等。

考虑到应对场景和需求的多变性，支付宝、淘宝、微信都是混合框架，在保留强大的Native能力和性能的同时，又充分利用JS/Web的灵活的前端生态能力，保证开发效率的同时，又能满足快速迭代热更新。春节临近时期，支付宝或者淘宝中都会有很多3D的特效出现，像红包、五福等等。

对于Unity这种Native引擎来说，虽然实现这些3D特效都非常简单，但是由于它完全是在Native框架下的产品，在融合上存在众多技术难点，很难和前端的技术进行无缝的对接。所以，面对这种超级APP的天然流量汇聚地，Unity也无法接入。而最终我们看到的各种3D特效，都是由移动优先、Web优先的Oasis引擎团队打造实现的！

Oasis 引擎 Github 链接
https://github.com/oasis-engine

Web优势4: 易传播、易分享、易协作，天然的SaaS服务形式

由于在Web环境下，通过一个链接就可以把内容分享到不同的平台，不同的人群，这种形式可以达到极致的内容传播效果。最有代表性的就是我们的微信，通过朋友圈，微信群，公众号等等，都可能引起内容分享的病毒式裂变效果。

曾经，我们分享的内容更多的是以图片，文字，视频，音频的形式。随着元宇宙时代的到来，更多样的3D内容也可能会随着一个链接引发内容传播的爆点，这给了内容制作领域更广阔的想象空间。WebGPU标准是实现此场景的关键技术点。

更值得一提的是，基于浏览器通用支持的WebSocket/WebRTC协议，配合如OT等分布式算法可以轻松实现分布式协同，达到多人同步完成一项任务的高效合作模式，这些都是Web得天独厚的优势体现。比如Google Doc，石墨文档，飞书文档等，也都是借助于浏览器环境实现了协作功能。依靠Web协同特性最成功的企业应该是估值超百亿美金的Figma，它的成功同时也引爆了「设计协作」这样一个超过千亿市场规模的SaaS赛道。

说到SaaS服务，是几乎所有的互联网公司都追求的变现形式。这也正是Web另外一个巨大的优势体现，因为几乎所有的SaaS都是以Web浏览器作为媒介来提供服务的。

最近非常火爆的「Gather Town」元宇宙办公服务提供商，全套的技术框架都是基于Web环境实现的，这大大降低了用户使用的门槛，也为他们的传播带来了的巨大的促进作用（他们的客户端也是基于Electron打包，一套代码直接分发成为各个平台的APP进行安装）。

Web优势5: 热加载

不论喜不喜欢“元宇宙”这个词汇，它都无法阻挡的向我们慢慢走来。我们理解的“元宇宙”，是一个无限可能的场景。为了实现这种无限的可能性，就要求元宇宙产品必须具备两个特点：

• 功能的快速更新及无限扩展：未来，我们的产品有了新的feature，一旦经过测试，就应该立刻服务于我们的用户；

• 资源的快速更新及无限扩展：不论是UGC还是PGC，用户在使用产品进行内容创作时，一旦有了新的变化，其他所有的用户应该在第一时间无延迟的情况下进行体验。

Native原生的应用程序是很难实现这些特点的，因为每一次应用程序的发布更新等，都需要重新的编译，甚至还需要应用商店的审核。如果一个技术团队，面对需求变化巨大的场景进行产品研发，任何前端需求的变化都要造成一次APP的重新编译发布，那效率会非常低下。这也是为什么像Flutter，React Native，Weex这种框架会越来越火，因为它们都有着和Web一样的热加载特性。

热加载的原理是利用脚本语言的可解释特性，我们通过直接刷新的形式，或者网络通信，把新的脚本内容直接插入或者覆盖原来需要被解释的代码部分，这样再由实时的解释形语言编译器进行实时运行，就可以达到即时更新的热加载效果。

而Native的应用，都是要进行预编译，简单理解就是最终APP都会变成0101这种东西，那新改变的内容就没有办法在未编译的情况下，被直接执行了。

我们利用Web的天然热加载特性，再配合产品设计的模块化架构以及代码管理的Monorepo机制，就可以轻松的实现产品功能的快速更新及无限扩展和资源的快速更新及无限扩展。总而言之，Web可能更加适合“元宇宙”这种高速变化且具有无限可能性的场景。

小鸥的思考

Web技术栈和Native技术栈并不是一种纯竞争的关系。Native能带来更加极致的性能体验，这是毋庸置疑的事实。不论是Unity，还是Unreal，甚至是依靠接近原生图形API性能的Bgfx架构来开发各种游戏和应用，都体现了Native强大的优势。

Bgfx 引擎Github链接
https://github.com/bkaradzic/bgfx

我们经常打一个比方，即使手机的拍照能力再强，真正的“老法师”也依然会坚持用600去打鸟。即使美图秀秀可以一键生成几乎完美的自拍照，PS的专业级忠实用户依然会死守不放。

因此，选择Web或Native，也不再是一个哲学问题，而是一个场景问题。

如果我们的场景需要追求极致的性能，那就用Native的技术栈去开发，比如Unity和Unreal。他们在游戏场景里几乎垄断的地位，足以证明这一点。**R Star引擎下的《荒野大镖客》**更是成为了行业内的天花板级存在。

如果场景更多的是趋向于便捷，简单，易分享等等特征，选择Web很可能是一个更佳的方案。最重要的是，现在有了WebGPU这样一个跨时代的全新标准，将最大限度的磨平Web和Native对于3D场景呈现上的差距。

曾经的WebGL时代，在3D场景中，Web开发者是很难真正发力的。实现一个优秀的3D场景应用是一个极其痛苦的过程。因为WebGL的性能实在太差了，很多Native可以轻松实现的渲染效果，WebGL都实现不了。但在这种极其艰难的情况下，Web上也出现了众多优秀的应用案例！

现实世界中使用WebGL的25+个应用
https://zhuanlan.zhihu.com/p/369632693

因此，选择Web和Native，可能也不再是一个场景问题，而是一个面对元宇宙爆发时代的未来判断问题。

未来的世界，会有大量的3D内容制作需求，因为3D内容是元宇宙搭建的基础。这也就意味着，我们面对的不是一个存量市场，而是一个增量市场，甚至是一个未知的充满无限可能的市场。众多的Web开发者，都会成为未来3D场景搭建的潜在生产力。Web的技术栈会因为WebGPU标准的到来，出现前所未有的提升和改变。这对于Web前端开发者，是一件太幸福的事情！

面对未来，当更多的年轻人，更多的新人进入到相应行业中，他们要考虑：什么是最适合的， 什么是最简单的，或者哪种选择未来的需求更多，自己更能够成长。Web生态就很有可能爆发出前所未有的优势：易上手，易分享，易迭代，成本低，跨平台，这些特点已然满足了绝大部分的场景。

因此，我们对于WebGPU加持下的Web生态充满了期待！

看了这么多WebGPU的发展和优势，你是不是也有点手痒了，心想，WebGPU听起来那么复杂，到底怎么开始着手？发布一个WebGPU的Project到底怎么做？

我们不知道把大象放冰箱是不是只要三步，但是我们可以告诉大家，有了Orillusion的模板，制作一个WebGPU的项目是多么轻松！

Orillusion提供并部署了Chrome WebGPU Token，运行后，在Chrome 100+ 上即可支持WebGPU内容（支持最新wgsl版本）。

Orillusion WebGPU模板链接:
https://github.com/Orillusion/orillusion-webgpu-samples

在Terminal中，输入以下命令，下载Github库，使用npm或yarn安装库，并运行，浏览器打开localhost:3000，即可看到运行结果，一个小小的三角形。

# Clone the repo
git clone https://github.com/Orillusion/orillusion-webgpu-samples.git
​
# Go inside the folder
cd orillusion-webgpu-samples
​
# Start installing dependencies
npm install #or yarn add
​
# Run project at localhost:3000
npm run dev #or yarn run dev

就是这么简单，相信你已经在自己的电脑上实现了第一个WebGPU小程序，下面我们来看一下，在这个小小三角形下，Orillusion的工程师为我们做了什么吧！

使用Vite打包

前端技术的朋友们比较熟悉的打包工具还有Webpack、Rollup 和 Parcel 等，它们极大地改善了前端开发者的开发体验。Vite 通过在一开始将应用中的模块区分为 依赖 和 源码 两类，通过原生ESM加载，极大的改进了代码编译时间，启动和热更新速度非常快，几乎是毫秒级更新。

对 TypeScript、JSX、CSS 等支持开箱即用，Vite 使用 esbuild 将 TypeScript 转译到 JavaScript，约是 tsc 速度的 20~30 倍，同时 HMR 更新反映到浏览器的时间小于 50ms。这些特点优势对开发者是非常友好的。

使用Vite开发的文件结构如下:

├─ 📂 node_modules/   # Dependencies
│  ├─ 📁 @webgpu      # WebGPU types for TS
│  └─ 📁 ...          # Other dependencies (TypeScript, Vite, etc.)
├─ 📂 src/            # Source files
│  ├─ 📁 shaders      # Folder for shader files
│  └─ 📄 *.ts         # TS files for each demo
├─ 📂 samples/        # Sample html
│  └─ 📄 *.html       # HTML entry for each demo
├─ 📄 .gitignore      # Ignore certain files in git repo
├─ 📄 index.html      # Entry page
├─ 📄 LICENSE         # MIT
├─ 📄 logo.png        # Orillusion logo image
├─ 📄 package.json    # Node package file
├─ 📄 readme.md       # Read Me!
└─ 📄 tsconfig.json   # TS configuration file

安装WebGPU库，配置tsconfig文件

我们的模板库已经安装了@webgpu/types，来支持WebGPU：

npm install @webgpu/types --save

将 vite/client 和 @webgpu/types 添加到 tsconfig 中的 compilerOptions.types 下：

{
  "compilerOptions": {
    .. .. ..
    "types": ["vite/client", "@webgpu/types"]
  }
  "include": ["src"]
}

vite/client 会提供以下类型定义补充：

• 资源导入 (例如：导入一个 .wgsl 文件)

• import.meta.env 上 Vite 注入的环境变量的类型定义

• import.meta.hot 上的 HMR API 类型定义

绘制三角形

Chrome 100+ wgsl 使用新的@ 标签 ，如果wgsl报错无法显示，请更新Chrome版本。

1. 顶点着色器 triangle.vert.wgsl

// 使用最新的wgsl标准
@stage(vertex)
fn main(@builtin(vertex_index) VertexIndex : u32) -> @builtin(position) vec4<f32> {
var pos = array<vec2<f32>, 3>(
  vec2<f32>(0.0, 0.5),
  vec2<f32>(-0.5, -0.5),
  vec2<f32>(0.5, -0.5)
  );
  return vec4<f32>(pos[VertexIndex], 0.0, 1.0);
}

2. 片元着色器 red.frag.wgsl

// 使用最新的wgsl标准
@stage(fragment)
fn main() -> @location(0) vec4<f32> {
  return vec4<f32>(1.0, 0.0, 0.0, 1.0);
}

3. 绘制三角形 basicTriangle.ts

vite/client 可以很方便的引入 string 类型的 wgsl 文件，在链接后添加<?raw>标注即可

import triangleVertWGSL from './shaders/triangle.vert.wgsl?raw'
import redFragWGSL from './shaders/red.frag.wgsl?raw'

通过90行代码，来初始化webgpu的device，调用canvas，创建一个pipeline，传入顶点和片元着色器代码，最后绘制成功！

WebGPU Origin Trial Token

为了方便本地开发，Orillusion 申请了在 localhost 环境中可以使用的 Chrome WebGPU 的 Origin Trial Token，配置在 vite.config.js 中，可以不用下载Chrome Canary版本，也无需手动设置 unsafe-webgpu flag，在普通 Chrome 96+ 中均可支持WebGPU。在WebGPU正式发布前，Orillusion 会定期更新 token。

// vite.config.js
import { defineConfig } from 'vite'
const devToken = 'Amu*****************=='
module.exports = defineConfig({
  plugins: [
  {
    name: 'Origin-Trial',
    configureServer: server => {
      server.middlewares.use((_req, res, next) => {
        res.setHeader("Origin-Trial", devToken)
        next()
      })
    }
  }
  ]
})

小练习

我们介绍了顶点着色器和片元着色器，那么尝试改变下坐标和颜色，来制作专属你的图形！Push到Git里，和我们一起交流分享！

Orillusion WebGPU模板链接:
https://github.com/Orillusion/orillusion-webgpu-samples

我们知道，一个三角形怎么能满足同学们的求知欲呢，Orillusion团队计划发布更多WebGPU的课程，让我们一起来探索WebGPU，关注我们，敬请期待后续的分享！

上一期讨论《Web和Native谁才是元宇宙的未来》一篇中，我们提到了Flash的技术。这里我们更加详细的介绍一下Flash技术以及它的发展过程，以及Flash对Web 3D的影响。帮助我们预测了解，未来Web端3D内容将如何发展。

在Web发展初期，浏览器是一个非常弱小的存在。Web框架本身和JS语言能力都非常弱，也没有任何的标准比如H5可以支持复杂的页面内容。当时的网页几乎只能显示文字，图片，内容也都是静态，没有任何的交互能力。然而用户对于Web平台呈现视频、游戏等丰富交互内容的需求是非常强的。

浏览器厂商为了弥补本身的劣势，就利用开放权限的方式，允许第三方为浏览器开发各种功能的插件，来支撑复杂的功能。到今天为止，某些网银还要求必须只能用IE浏览器打开，而且安装对应的安全插件，就是那个时代遗留下的产物。最著名的插件当数Flash。

为什么Flash那么火

Flash做为插件的原理很简单。因为浏览器本身很多功能都实现不了，那他就提供给外部程序一种介入的方法，或者说是一块区域，在这个区域中显示的所有内容，都完全不在浏览器环境中运行，而是在第三方的插件中去运行。因此，这部分内容就摆脱了浏览器本身的限制，可以用其他编程语言进行各种复杂功能的编写和实现。

浏览器拥有了Flash插件之后，最大的变化就是带来了一波页游繁荣的时代。首先Flash因为它摆脱了浏览器的束缚，可以直接发起TCP和UDP请求，这是网络游戏的基础。

其次，依托于浏览器，所有的页游可以达到即开即玩，无需安装任何客户端，及其方便简单。当然有了Flash之后，浏览器就可以轻松的播放音频视频了，也极大的丰富了人们的生活。

为什么Flash退出了历史舞台？

虽然Flash给Web生态带来了丰富的内容，但是它有一个根本的问题就是破坏了浏览器设计的原则-沙盒机制。通俗说，沙盒机制指的就是，就是自己家里人管自己家的事儿。

明显Flash插件这种机制，在带来的丰富页面内容的同时，摆脱了浏览器的控制，存在很大的安全性问题。每个人肯定都不想，打开一个页面的时候，自己电脑里的文件就被别人窃取了。

除了安全问题，Flash带来的较大的硬件消耗已经不适应移动互联网时代的手机设备了。2010年四月份，当年的苹果CEO乔布斯给Flash写了一封公开信《Thoughts On Flash》，强调苹果设备将不在移动端支持Flash。

《Thoughts On Flash》https://archive.is/pxSTb

是谁替代了Flash？

W3C于2008年发起HTML5标准草案，目的是使得浏览器原生就已经开始支持视频、音频、画布等等元素，减少了Flash外挂。

2011年，Khronos发布了WebGL 1.0 版本，浏览器也开始可以原生支持3D内容的渲染显示了。同年，WebRTC协议推出，也可以在浏览器应用层发起类似于UDP的通信请求，未来还会推出基于HTTP3的Webtransport协议，游戏不在需要Flash了。

随之而来的是WebGL时代。WebGL 是一个跨平台、免版税的开放 Web 标准，用于基于 OpenGL ES 的轻量级 3D 图形 API，通过 HTML5 Canvas 元素向 ECMAScript 公开。WebGL 1.0 公开了 OpenGL ES 2.0 功能集；WebGL 2.0 公开了 OpenGL ES 3.0 API。WebGL 将无插件 3D 带入网络，直接在浏览器中实现。

我们目前在网页上看到的3D动画和渲染都是基于WebGL的。Khronos在2009年启动WebGL标准的讨论和制定工作，在WebGL发布十年的过程中，也出现了很多3D引擎，包括我们熟知的Three.js，Babylon.js等。

当WebGL和HTML5已经足够成熟，可以提供“可行的替代方案”，而无需用户安装和更新专用插件。Flash当年的技术优势，都慢慢的被取代了。

2015 年，Apple 默认禁用其 Safari 网络浏览器中的插件，谷歌的 Chrome 开始屏蔽部分 Flash 内容。

2017年7月，Adobe 宣布将于 2020 年淘汰 Flash，标志着一个时代的落幕。

Flash退出历史舞台，其实并不是被H5或者WebGL打败，而是孕育了或者说促进了新的技术的发展。很多H5标准都是借鉴Flash设计，而且大名鼎鼎的RTMP协议和Flash也有千丝万缕的关系，而且目前几乎所有的摄像头仍然在采用RTMP协议来做推流。

Web 3D未来如何发展？

面临GPU能力的发展，以及渲染要求的不断增加，WebGL标准即将被WebGPU取代。2014年，Native出了三大现代图形API: DX12, Vulkan, Metal。在2017年的时候，W3C就提出在Web侧发展下一代图形学的技术标准，即WebGPU。

WebGPU真正向开发者释放了GPU的计算能力，有了WebGPU，原本那些基于Native端的3D建模工具，像3DMax，Maya， Unity3D等，也将会在Web端得到实现。

同时，由于Web环境拥有天然的跨平台和协同特性，可以避免下载各种重量级终端应用，一个链接就可以完成内容的制作和协同，就像Figma（Web端的2D内容协同制作平台)，依靠Web协同取得了巨大的成功。

无论怎样，时代和技术一直会继续往前，从最初的静态页面，到Flash，再到H5和WebGL，WebGPU，应用内容得到了极大丰富。我们可以预测，有了新的Web 3D渲染标准WebGPU，会再次给人们带来意想不到的惊喜!

你对未来Web端的3D内容制作和演示的发展有什么看法呢？在下方评论区留言给我们吧！

看了这么多WebGPU的发展和优势，你是不是也有点手痒了，心想，WebGPU听起来那么复杂，到底怎么开始着手？发布一个WebGPU的Project到底怎么做？

我们不知道把大象放冰箱是不是只要三步，但是我们可以告诉大家，有了Orillusion的模板，制作一个WebGPU的项目是多么轻松！

Orillusion提供并部署了Chrome WebGPU Token，运行后，在Chrome 100+ 上即可支持WebGPU内容（支持最新wgsl版本）。

Orillusion WebGPU模板链接:
https://github.com/Orillusion/orillusion-webgpu-samples

在Terminal中，输入以下命令，下载Github库，使用npm或yarn安装库，并运行，浏览器打开localhost:3000，即可看到运行结果，一个小小的三角形。

# Clone the repo
git clone https://github.com/Orillusion/orillusion-webgpu-samples.git
​
# Go inside the folder
cd orillusion-webgpu-samples
​
# Start installing dependencies
npm install #or yarn add
​
# Run project at localhost:3000
npm run dev #or yarn run dev

就是这么简单，相信你已经在自己的电脑上实现了第一个WebGPU小程序，下面我们来看一下，在这个小小三角形下，Orillusion的工程师为我们做了什么吧！

使用Vite打包

前端技术的朋友们比较熟悉的打包工具还有Webpack、Rollup 和 Parcel 等，它们极大地改善了前端开发者的开发体验。Vite 通过在一开始将应用中的模块区分为 依赖 和 源码 两类，通过原生ESM加载，极大的改进了代码编译时间，启动和热更新速度非常快，几乎是毫秒级更新。

对 TypeScript、JSX、CSS 等支持开箱即用，Vite 使用 esbuild 将 TypeScript 转译到 JavaScript，约是 tsc 速度的 20~30 倍，同时 HMR 更新反映到浏览器的时间小于 50ms。这些特点优势对开发者是非常友好的。

使用Vite开发的文件结构如下:

├─ 📂 node_modules/   # Dependencies
│  ├─ 📁 @webgpu      # WebGPU types for TS
│  └─ 📁 ...          # Other dependencies (TypeScript, Vite, etc.)
├─ 📂 src/            # Source files
│  ├─ 📁 shaders      # Folder for shader files
│  └─ 📄 *.ts         # TS files for each demo
├─ 📂 samples/        # Sample html
│  └─ 📄 *.html       # HTML entry for each demo
├─ 📄 .gitignore      # Ignore certain files in git repo
├─ 📄 index.html      # Entry page
├─ 📄 LICENSE         # MIT
├─ 📄 logo.png        # Orillusion logo image
├─ 📄 package.json    # Node package file
├─ 📄 readme.md       # Read Me!
└─ 📄 tsconfig.json   # TS configuration file

安装WebGPU库，配置tsconfig文件

我们的模板库已经安装了@webgpu/types，来支持WebGPU：

npm install @webgpu/types --save

将 vite/client 和 @webgpu/types 添加到 tsconfig 中的 compilerOptions.types 下：

{
  "compilerOptions": {
    .. .. ..
    "types": ["vite/client", "@webgpu/types"]
  }
  "include": ["src"]
}

vite/client 会提供以下类型定义补充：

• 资源导入 (例如：导入一个 .wgsl 文件)

• import.meta.env 上 Vite 注入的环境变量的类型定义

• import.meta.hot 上的 HMR API 类型定义

绘制三角形

Chrome 100+ wgsl 使用新的@ 标签 ，如果wgsl报错无法显示，请更新Chrome版本。

1. 顶点着色器 triangle.vert.wgsl

// 使用最新的wgsl标准
@stage(vertex)
fn main(@builtin(vertex_index) VertexIndex : u32) -> @builtin(position) vec4<f32> {
var pos = array<vec2<f32>, 3>(
  vec2<f32>(0.0, 0.5),
  vec2<f32>(-0.5, -0.5),
  vec2<f32>(0.5, -0.5)
  );
  return vec4<f32>(pos[VertexIndex], 0.0, 1.0);
}

2. 片元着色器 red.frag.wgsl

// 使用最新的wgsl标准
@stage(fragment)
fn main() -> @location(0) vec4<f32> {
  return vec4<f32>(1.0, 0.0, 0.0, 1.0);
}

3. 绘制三角形 basicTriangle.ts

vite/client 可以很方便的引入 string 类型的 wgsl 文件，在链接后添加<?raw>标注即可

import triangleVertWGSL from './shaders/triangle.vert.wgsl?raw'
import redFragWGSL from './shaders/red.frag.wgsl?raw'

通过90行代码，来初始化webgpu的device，调用canvas，创建一个pipeline，传入顶点和片元着色器代码，最后绘制成功！

WebGPU Origin Trial Token

为了方便本地开发，Orillusion 申请了在 localhost 环境中可以使用的 Chrome WebGPU 的 Origin Trial Token，配置在 vite.config.js 中，可以不用下载Chrome Canary版本，也无需手动设置 unsafe-webgpu flag，在普通 Chrome 96+ 中均可支持WebGPU。在WebGPU正式发布前，Orillusion 会定期更新 token。

// vite.config.js
import { defineConfig } from 'vite'
const devToken = 'Amu*****************=='
module.exports = defineConfig({
  plugins: [
  {
    name: 'Origin-Trial',
    configureServer: server => {
      server.middlewares.use((_req, res, next) => {
        res.setHeader("Origin-Trial", devToken)
        next()
      })
    }
  }
  ]
})

小练习

我们介绍了顶点着色器和片元着色器，那么尝试改变下坐标和颜色，来制作专属你的图形！Push到Git里，和我们一起交流分享！

Orillusion WebGPU模板链接:
https://github.com/Orillusion/orillusion-webgpu-samples

我们知道，一个三角形怎么能满足同学们的求知欲呢，Orillusion团队计划发布更多WebGPU的课程，让我们一起来探索WebGPU，关注我们，敬请期待后续的分享！

2022年1月25日 Khronos 组织了一场备受瞩目的 WebGL+WebGPU 网络研讨会。

 
会议的主要部分有 ：

• WebGL 的最新消息和版本更新（WebGL 工作组组长 Ken Russell）

• WebGPU规范和WebGPU生态的状态更新（Kai Ninomiya）

• WebGPU的最佳实践案例 （Brandon Jones， Google）

• WGSL着色器语言在线编辑器展示（Takahiro Aoyagi，Mozilla）

• PlayCanvas的更新发布（Donovan Hutchence）

我们总结归纳了有关WebGPU的部分，会议内容参考以下链接。

WebGL + WebGPU Meetup - January 2022
https://www.khronos.org/events/webgl-webgpu-meetup-january-2022

WebGPU规范和WebGPU生态的状态更新

 
WebGPU是Web端的一个新的图形API。它的底层是现代图形API，包括Vulkan，DX12 和 Metal。它采用了pre-validation的方法，例如pipeline objects，bind groups，这些可以避免在运行过程中做draw time validation，并且简化了API 的编程逻辑。另外，相比WebGL，WebGPU还增加了一些新的特性，比如compute shader，shader storage，并且避免了使用global state。

WebGPU也为未来的渲染功能打好了基础，像是bindless ray tracing shader features，尽可能多的暴露native端的一些特性，并且能够跨平台夸浏览器的使用。

WebGPU 目前还处于研发阶段，预计将在2022年第二季度发布第一个版本1.0。同时着色器语言的规范也在快速的更迭中。
 

Orillusion的官网上有WebGPU和WGSL规范的中文版，欢迎小伙伴们来查看，欢迎到我们的GitHub中留言修改。

• Orillusion WebGPU中文文档 GitHub 链接

虽然，WebGPU还处于测试阶段，但已经可以在Chrome和Firefox中使用啦。做本地测试的同学可以使用Chrome Canary或者Firefox Nightly，只需要设置相应的flag就可以。（在正常浏览的时候建议不要开启WebGPU）

• Chrome Canary: 在 about:flags 中，启用enable-unsafe-webgpu

• Firefox Nightly: 在 about:config中，设置dom.webgpu.enabled

• Chrome Origin Trial 注册链接: https://developer.chrome.com/origintrials/#/trials/active

开发者们可以利用Chrome（94+）的Origin Trial，向Chrome申请WebGPU的权限，得到一个Token，放到HTML head里就可以使用特定的API，就可以发布WebGPU的应用给到端用户，在Mac、Windows和Chrome OS系统中都可以。用户不用设置任何的Tag也可以查看WebGPU渲染的内容。

• Orillusion 首页 Demo

大家可以参考一些WebGPU的资料，包括上面介绍的W3C官方文档，以及一些JS库，例如Babylon.js，Three.js，TensorFlow.js以及用Rust编写的wgpu可以对应使用WebAssembly。在WebGPU 1.0 版本发布前后，Orillusion也会开源，迎来第一批KA developers，届时欢迎大家来探讨和使用。

WebGPU使用一种新的着色器语言WGSL， 有一系列的着色器语言编译器，可以将「WGSL, Vulkan SPIR-V」转译成「WGSL，SPIR-V，HLSL，MSL」。大家可以参考Google Tint和Mozilla Naga。

• Google’s Tint：https://dawn.googlesource.com/tint

• Mozilla’s Naga：https://github.com/gfx-rs/naga

WebGPU的最佳实践案例

Brandon Jones在Google工作了9年，是一名Chrome团队的工程师。负责WebGPU的规范文档编辑和开发工作。

最近他开发了第一款完全基于WebGPU的小游戏，Spooky Ball。游戏很简单，里面使用了shadow mapping，bloom filtering for emissive materials, 上传gltf图片，以及一些动画效果。这个小游戏更多是用来测试，WebGPU的API是否可以被正确的使用，并没有发挥WebGPU真正的实力。

• Spooky Ball

Brandon Jones还给出了一些最佳实践案例，我们来看来自Orillusion社区UGC 四季留歌 的站内分享，点击查看！

• WebGPU的几个最佳实践

对于Web3D领域的两个非常优秀的引擎，大家肯定都不陌生，他们就是Three.js和Babylon.js。

说到构建WebGPU引擎，你一定会问为什么不是Three.js或Babylon.js？

Three.js是JavaScript语言开发。2010年，西班牙开发者Ricardo Cabello (Twitter: mrdoob)在Github上放出了第一个public版本。

Three.js 官网
https://threejs.org/

我们熟知的WebGL是在2009年被Khnoros组织提出，可以说Three.js的发展史，就是WebGL标准的发展史。

**Bablyon.js是TypeScript语言开发，**是由微软内部团队，于2013年主导的另外一款引擎。它的封装更加高层，功能也相对复杂很多，而且拥有很多比较成熟的工具，比如Node Material Editor。相比Three.js，Babylon.js可以说更像一款比较成熟的Web3D游戏引擎。

Babylon.js 官网
https://www.babylonjs.com/

但是由于timing的原因，Github上的Star数量，截止2022年2月，Three.js（78.8k）远高于 Babylon.js（15.8k)，Three.js依然是基于WebGL标准下最为流行的Web 3D引擎。

为什么不是Three.js or Babylon.js?

WebGPU标准的发展，也一直被广泛关注。Three.js和Babylon.js，已经在相应的分支，**做了WebGPU能力的接入和一些Demo的展示。**我们看到了他们的实现和demo，也更加的相信，WebGPU引擎这件事儿，大概率他们做不成。

因为Three.js和Babylon.js两个引擎架构都是为了WebGL而设计的，而WebGPU对比WebGL可以说发生了翻天覆地的变化，取消了全局状态机，给了开发者过多的权限来控制内存，增加了Compute Shader等等。因此，Three.js和Babylon.js不能说是支持了WebGPU，只能说接入了WebGPU，但是由于历史包袱，根本无法发挥出来WebGPU的优势。

口说无凭，通过一系列的测试，我们得出这样的结论。测试结果

Three.js的WebGPU Demo，跟WebGL Demo来比，几乎没有什么提升。封装更加高层和复杂的Babylon.js，WebGPU 的Demo的实现竟然比WebGL还要慢。

相比之下，目前我们的Orillusion官方放出的Demo，比WebGL引擎快了将近5倍。下一个版本的对比特性，我们已经快了10倍。如果发挥到WebGPU性能的极致，可以快出30倍。

https://demo.orillusion.com/ecs/example/asteroids.html

如果Three.js和Babylon.js真的想做一款可以充分发挥WebGPU性能的引擎出来，那只能壮士断腕，对引擎框架进行彻底的重构。因为Three.js和Babylon.js的历史包袱太重了，他们有大量的用户，有大量的功能实现，完全放弃而进行重新开发，这是需要巨大勇气的，而且我们目前没有看到任何这样的迹象。

所以有的时候，做的早不一定做的好，这也就是技术迭代带来的新机遇。

我们可以等未来某天Three.js和Babylon.js重构架构支持WebGPU，可能是半年？甚至是一年？但是，在这么好的一个时间节点，为什么中国的团队不能做出一款同样优秀的Web 3D引擎，实现弯道超车呢？

之前我们擅长于场景创新和商业模式创新。但是，在这样一个好的时间节点，我们应该把精力放在底层的技术研究上：这是一种思维模式的改变，更是一种认知的改变。

元宇宙正在朝我们走来，3D渲染的场景未来会暴增。有了核心的3D底层技术，上层场景才会有无限的可能。中国的技术开发者需要时间，中国的基础软件需要时间。在这个过程中，Orillusion希望能做出一点儿贡献。

上一篇文章我们介绍了 Web 和 Native 的发展历程，对Web端的跨平台特性以及生态的发展和普及程度广的优势进行了分析，还没有看到的朋友们可以点击下面链接回顾一下哦

Web or Native 谁才是元宇宙的未来（上）？

相信看完这篇文章，你已经有了一些想法，今天我们继续来聊一聊关于Web和Native的技术栈选择，看看你是否也同意小鸥的看法呢～

Web优势3: 超级APP生态的嵌入

任何公司具备了超级APP之后，必然都会考虑打造应用内部的生态，将尽量多的场景和能力在自己的应用生态中统一解决。比如我们日常都会使用的微信、支付宝、淘宝等等。

考虑到应对场景和需求的多变性，支付宝、淘宝、微信都是混合框架，在保留强大的Native能力和性能的同时，又充分利用JS/Web的灵活的前端生态能力，保证开发效率的同时，又能满足快速迭代热更新。春节临近时期，支付宝或者淘宝中都会有很多3D的特效出现，像红包、五福等等。

对于Unity这种Native引擎来说，虽然实现这些3D特效都非常简单，但是由于它完全是在Native框架下的产品，在融合上存在众多技术难点，很难和前端的技术进行无缝的对接。所以，面对这种超级APP的天然流量汇聚地，Unity也无法接入。而最终我们看到的各种3D特效，都是由移动优先、Web优先的Oasis引擎团队打造实现的！

Oasis 引擎 Github 链接
https://github.com/oasis-engine

Web优势4: 易传播、易分享、易协作，天然的SaaS服务形式

由于在Web环境下，通过一个链接就可以把内容分享到不同的平台，不同的人群，这种形式可以达到极致的内容传播效果。最有代表性的就是我们的微信，通过朋友圈，微信群，公众号等等，都可能引起内容分享的病毒式裂变效果。

曾经，我们分享的内容更多的是以图片，文字，视频，音频的形式。随着元宇宙时代的到来，更多样的3D内容也可能会随着一个链接引发内容传播的爆点，这给了内容制作领域更广阔的想象空间。WebGPU标准是实现此场景的关键技术点。

更值得一提的是，基于浏览器通用支持的WebSocket/WebRTC协议，配合如OT等分布式算法可以轻松实现分布式协同，达到多人同步完成一项任务的高效合作模式，这些都是Web得天独厚的优势体现。比如Google Doc，石墨文档，飞书文档等，也都是借助于浏览器环境实现了协作功能。依靠Web协同特性最成功的企业应该是估值超百亿美金的Figma，它的成功同时也引爆了「设计协作」这样一个超过千亿市场规模的SaaS赛道。

说到SaaS服务，是几乎所有的互联网公司都追求的变现形式。这也正是Web另外一个巨大的优势体现，因为几乎所有的SaaS都是以Web浏览器作为媒介来提供服务的。

最近非常火爆的「Gather Town」元宇宙办公服务提供商，全套的技术框架都是基于Web环境实现的，这大大降低了用户使用的门槛，也为他们的传播带来了的巨大的促进作用（他们的客户端也是基于Electron打包，一套代码直接分发成为各个平台的APP进行安装）。

Web优势5: 热加载

不论喜不喜欢“元宇宙”这个词汇，它都无法阻挡的向我们慢慢走来。我们理解的“元宇宙”，是一个无限可能的场景。为了实现这种无限的可能性，就要求元宇宙产品必须具备两个特点：

• 功能的快速更新及无限扩展：未来，我们的产品有了新的feature，一旦经过测试，就应该立刻服务于我们的用户；

• 资源的快速更新及无限扩展：不论是UGC还是PGC，用户在使用产品进行内容创作时，一旦有了新的变化，其他所有的用户应该在第一时间无延迟的情况下进行体验。

Native原生的应用程序是很难实现这些特点的，因为每一次应用程序的发布更新等，都需要重新的编译，甚至还需要应用商店的审核。如果一个技术团队，面对需求变化巨大的场景进行产品研发，任何前端需求的变化都要造成一次APP的重新编译发布，那效率会非常低下。这也是为什么像Flutter，React Native，Weex这种框架会越来越火，因为它们都有着和Web一样的热加载特性。

热加载的原理是利用脚本语言的可解释特性，我们通过直接刷新的形式，或者网络通信，把新的脚本内容直接插入或者覆盖原来需要被解释的代码部分，这样再由实时的解释形语言编译器进行实时运行，就可以达到即时更新的热加载效果。

而Native的应用，都是要进行预编译，简单理解就是最终APP都会变成0101这种东西，那新改变的内容就没有办法在未编译的情况下，被直接执行了。

我们利用Web的天然热加载特性，再配合产品设计的模块化架构以及代码管理的Monorepo机制，就可以轻松的实现产品功能的快速更新及无限扩展和资源的快速更新及无限扩展。总而言之，Web可能更加适合“元宇宙”这种高速变化且具有无限可能性的场景。

小鸥的思考

Web技术栈和Native技术栈并不是一种纯竞争的关系。Native能带来更加极致的性能体验，这是毋庸置疑的事实。不论是Unity，还是Unreal，甚至是依靠接近原生图形API性能的Bgfx架构来开发各种游戏和应用，都体现了Native强大的优势。

Bgfx 引擎Github链接
https://github.com/bkaradzic/bgfx

我们经常打一个比方，即使手机的拍照能力再强，真正的“老法师”也依然会坚持用600去打鸟。即使美图秀秀可以一键生成几乎完美的自拍照，PS的专业级忠实用户依然会死守不放。

因此，选择Web或Native，也不再是一个哲学问题，而是一个场景问题。

如果我们的场景需要追求极致的性能，那就用Native的技术栈去开发，比如Unity和Unreal。他们在游戏场景里几乎垄断的地位，足以证明这一点。**R Star引擎下的《荒野大镖客》**更是成为了行业内的天花板级存在。

如果场景更多的是趋向于便捷，简单，易分享等等特征，选择Web很可能是一个更佳的方案。最重要的是，现在有了WebGPU这样一个跨时代的全新标准，将最大限度的磨平Web和Native对于3D场景呈现上的差距。

曾经的WebGL时代，在3D场景中，Web开发者是很难真正发力的。实现一个优秀的3D场景应用是一个极其痛苦的过程。因为WebGL的性能实在太差了，很多Native可以轻松实现的渲染效果，WebGL都实现不了。但在这种极其艰难的情况下，Web上也出现了众多优秀的应用案例！

现实世界中使用WebGL的25+个应用
https://zhuanlan.zhihu.com/p/369632693

因此，选择Web和Native，可能也不再是一个场景问题，而是一个面对元宇宙爆发时代的未来判断问题。

未来的世界，会有大量的3D内容制作需求，因为3D内容是元宇宙搭建的基础。这也就意味着，我们面对的不是一个存量市场，而是一个增量市场，甚至是一个未知的充满无限可能的市场。众多的Web开发者，都会成为未来3D场景搭建的潜在生产力。Web的技术栈会因为WebGPU标准的到来，出现前所未有的提升和改变。这对于Web前端开发者，是一件太幸福的事情！

面对未来，当更多的年轻人，更多的新人进入到相应行业中，他们要考虑：什么是最适合的， 什么是最简单的，或者哪种选择未来的需求更多，自己更能够成长。Web生态就很有可能爆发出前所未有的优势：易上手，易分享，易迭代，成本低，跨平台，这些特点已然满足了绝大部分的场景。

因此，我们对于WebGPU加持下的Web生态充满了期待！

Orillusion团队正在收集大家的反馈，希望大家给出更多自己的建议和理解！

随着元宇宙概念的爆炸式出现，3D渲染技术再次受到了巨大关注度。

沉浸、3D世界、虚拟社交、虚拟购物，这些都是元宇宙的概念实例。就像电影《失控玩家》那样，人们畅想通过AR/VR以及其他互联网技术，把现实世界的楼房街道、天气温度、人际关系等投射到虚拟世界，构建“元宇宙”，拥有一个网络分身。

但目前来看，要想实现这一构想，开发者们还有很长一段路要走。毕竟“元宇宙”的背后是庞大的3D虚拟世界构建，需要海量且高质量的3D内容支撑，以还原真实世界。R星引擎的游戏《荒野大镖客》除了游戏世界里各种各样让人拍案叫绝的细节之外，在画质上3D世界渲染的技术细节也仍然让人惊叹。

3D渲染技术的迭代路线分成了两种技术方案：Native和Web。

Native，是我们的电脑、手机等硬件设备，通过安装本地的应用程序APP，直接通过图形API和相关驱动调用显卡的计算和渲染能力，完成真实物体的3D渲染数字化的过程。

Web，是通过浏览器，在网页页面中，实现现实世界的数字化渲染的过程。

打趣的说，选择Native技术栈还是Web技术栈，这是一个哲学问题。两种技术方案都有自己的优势和劣势，同时双方的生态也都比较丰富，很多项目从最终的技术实现角度来说，选择哪一条路线都可以完成。

Native 3D渲染的发展

1992年，Khronos制定了第一代的渲染引擎的图形学的框架叫做OpenGL 1.0，包括现在很多电脑用的基本上3D应用都是基于OpenGL。OpenGL也在不停的发展，目前最新版是2017年发布的OpenGL 4.6版本。同时，也出现了专门为移动端设计的OpenGL ES版本。由于OpenGL是开源和跨平台的，不方便为Windows做优化，1996年，微软作为第一大操作系统的提供商，发布了自己的图形API Direct3D。DX5/DX6/DX9有很多游戏的代表作，《古墓丽影》《极品飞车》都是当时的作品。

发展到了2009年，微软提出了DX11版本，有一个比较大的特性，计算着色器。简单说就是在图形的渲染能力上，可以更加充分的调用显卡的并行计算能力。

2014年，微软发布了下一代图形渲染API DX12，同年6月份，苹果在WWDC大会上发布了自己的图形学API Metal。2015年，Khronos发布了Vulkan。最早是发布的 OpenGL，随着显卡能力的提升，OpenGL的全局状态机设计离线，已经无法调用和优化先进现代显卡的能力。可以说Khronos不在会全力以赴的长期升级和维护OpenGL，反而选择发布了全新架构的现代图形API，即Vulkan。

2014年这个节点，就形成了三种现代图形学API并驾齐驱的情况。目前所有电脑上的游戏，或者一些3D应用，包括CG渲染动画，为了达到最好的渲染效果，几乎都会采用这三种现代图形API。

Web 3D渲染的发展

总体来说，在Web上渲染3D内容的相关技术发展还是比较缓慢的。最早的时候在浏览器是无法实现3D内容的，需要安装Flash插件。在校内网时代，那些农场类的游戏应用，以及在浏览器里看视频音频，几乎都需要安装Flash插件。2020年的时候，因为有一些安全的问题和其他种种原因，Adobe宣布停止维护Flash这项技术。

在Flash的发展过程中，出现了HTML5的标准，简称H5。2008年的时候，H5雏形出现。人们不需要在浏览器里面装Flash的插件，能够直接播放视频音频，包括通过Web原生的Canvas组件实现一些动画效果。

真正的Web 3D的技术标准的出现，是WebGL。由于浏览器天然具备的易分享等优势，在Web中展示和渲染3D内容一直都具有大量的需求。Khronos在2009年启动WebGL标准的讨论和制定工作。WebGL思路很简单，就是依靠浏览器的内核，对OpenGL ES版本做打包和封装，然后就可以让浏览器里的这些JS前端开发者直接用Web环境去调用底层的图形学能力，最终展示3D内容。当然也就意味着WebGL能力被限制到了OpenGL的时代。

Web的技术在持续快速的发展。尤其2014年，Native侧已经出了三大现代图形API了: DX12, Vulkan, Metal。在2017年的时候，W3C就提出在Web侧发展下一代图形学的技术标准,即WebGPU。跟WebGL一样，WebGPU的思路就是对三个现代图形API直接打包，然后在实现跨平台的同时，让浏览器里面直接可以调用这三个现代图形API能力，实现高质量的渲染效果，调用GPU的强大计算能力。

WebGPU Wiki
https://en.wikipedia.org/wiki/WebGPU

我们熟知的Unity和Unreal就是典型的Native技术栈下的3D渲染引擎产品，而Web端也有大名鼎鼎的Three.js，Barbylon.js, Cesium.js 和 Playcanvas等等。面对这样两条路线，下面聊一聊关于技术栈选择上的思考。

Web优势1: 生态的发展和普及程度广

从技术角度来看，Web相对于Native的发展相对是缓慢的。因为很多最新的技术都会在Native上最先实现。但是因为Web本身独特的优势，跨平台，易分享，易协同等等，一直都很受技术人员和多种应用场景的青睐。

浏览器厂商的努力也不容忽视，尤其是Chrome。为了保证Chrome 100这个历史时刻的版本能尽早的发布，从94版本开始，将6周一更新提升到4周一更新。（Chrome 94版本也是第一个正式启动WebGPU API的商用版本，而不在是通过Chrome Canary的developer版本才能体验的WebGPU的能力。）

Chromium Blog
https://blog.chromium.org/2021/03/speeding-up-release-cycle.html

浏览器承载的Web生态正在飞速的发展。下面的开源报告中关于开源环境技术方向的统计后端是最多的。但是我们可以看到，第二个就是Web的生态，也证明了Web生态是非常有潜力的。

2020年开源环境技术方向

下面是2020年编程语言的分布报告。最多的是Java，第二就是前端语言JS，如果把HTML语言也包括其中，那Web的语言普及度优势将更加明显。这足以说明Web是一个快速发展具有巨大潜力的技术栈生态。

2020年编程语言的分布

2020中国开源年度报告

https://kaiyuanshe.cn/document/china-os-report-2020/2020%20%E4%B8%AD%E5%9B%BD%E5%BC%80%E6%BA%90%E5%B9%B4%E5%BA%A6%E6%8A%A5%E5%91%8A.pdf

Web优势2: 免安装客户端，跨平台特性

Native端，需要安装APP应用程序，在某些场景，对于用户来说是一个很高成本的行为。可以想象一下，如果你的家装设计师为你设计的室内3D全景渲染图，不是通过微信直接分享给你的（微信本身所有的分享内容都是基于Web），而是要求你要在手机或者电脑上安装一个几百M甚至几个G的应用程序才能观看，那是一种什么体验呢？

Web就很好的解决了这一个问题。我们不在需要为不同的场景安装不同的客户端，而是通过一个URL链接，就可以立刻浏览你想看到的任何内容。

换一个角度去思考，不仅不需要用户安装客户端，而是我们已经通过硬件设备中的浏览器触达到用户了。单独Chrome的全球装机量为26亿，占全部浏览器市场占有率的60%；排名第二个也是采用了Chromium内核的Edge浏览器，市场占有率为18%。

2020年-2021年全球浏览器市场占有率

基于Web环境做任何的内容开发，也都因为这种天然的跨平台特性，实现了降低研发成本的目的。Orillusion团队也极力打造Web端的3D渲染引擎。开发者们不需要在考虑为了一个项目开发不同的APP，来适配不同的操作系统。因为浏览器已经帮我们实现了不同平台的适配工作。只要在一台主机的Chrome里能正常打开，那么在其他主机的Chrome里也可以正常打开。

我们目前梳理了Native和Web在3D渲染这个场景中的发展历史和技术演进。同时，也从开发者生态和免客户端跨平台这两个方面，阐述了一些Native和Web技术路线的对比和分析。在接下来的内容里，我们会给出更加深入的思考，希望大家持续关注。

关于文章前面提出的打趣观点: 选择Native技术栈还是Web技术栈，这是一个哲学问题，也欢迎更多的Native和Web开发者一起留言，加入Orillusion社区参与讨论！

Web渲染引擎框架最有名的比如ThreeJS，BabylonJS，Cesium等等，已经得到了广大开发者的认可。并且已经被很多成熟的商业项目所引用和对应其场景的优化。但是它们都隶属于上一代WebGL时代的引擎。

WebGPU标准诞生至今，也没有出现一款完全基于WebGPU的全新架构设计的全新Web引擎出现。虽然我们看到Three和Babylon也在做WebGPU的尝试，经过测试发现，效果并不好。

原因就是WebGPU和WebGL是完全两套不一样的API封装和调用逻辑，如果想充分发挥WebGPU性能，只能完全重构其框架，这对于WebGL时代的引擎来说，需要付出巨大的勇气和壮士断腕的决心。

在这样一个时间节点，我们致力于开发一款完全基于WebGPU标准的Web渲染引擎。没有任何历史包袱，目标就是伴随WebGPU标准一起发展，最终实现一款完全开源的，有隔代差距的全新引擎Orillusion。

希望大家和我们一起见证WebGPU和Orillusion的成长。

测试平台

MacOS - v12.01
Chrome canary - v 96 - 101
Processor - Core i7 8700k, 6-Core, 3.7Ghz
Memory - 16GB 2677MHz DDR4
Graphics - Intel UHD Graphics 630

测试项目

使用 Three.js r133, Babylon.js 5.0.0 preview, Orillusion 进行对比测试
创建多个独立 box with basic color material，用 WebGL 和 WebGPU 进行旋转渲染测试
在 800 x 600 分辨率下，对比 box 创建时间 & 渲染帧率 & 内存消耗

DEMO地址

https://contrast.orillusion.com

测试结果

WebGL 渲染

WebGPU 渲染

Orillusion WebGPU 渲染

单独列出orillusion, 因为1w+数量 three 和 babylon 已无法完成正常帧率渲染

说明：

1. Orillusion默认开启多线程计算，n 代表 worker 数量，测试6个线程，整体内存消耗在 10-20 MB
2. 此结果仅为Mac OS测试结果，同配置的window电脑，得益于dx12的特性，性能可增加25% ~ 50%， Intel 集显 uhd630 在 15w 数量下渲染也可保持 60 fps
3. 以上测试为Intel普通集显环境，欢迎补充更多机型的测试结果，得益于WebGPU对底层驱动的适配，如果使用rtx独立显卡，相对WebGL将有更大幅度的性能提升
4. 目前 Chrome v94-v101 对 WebGPU 的优化还没有完成，尤其是writeBuffer 和 mapAsync 的性能，相对于 WebGL 的 bufferSubData，在大数据量的写入场景下慢2-10x (详情可参考 https://forum.orillusion.com/topic/39/chrome-writebuffer-performance)，所以目前的 Orillusion 10w+ 的测试中，拖垮 FPS 的是 writeBuffer 的速度。以30w数据量举例，Orillusion 引擎在 CPU 侧处理所有数据（包括逻辑运算，transform，camera，gpu数据装配等）的速度只有不到10ms，理论fps应该保持60 FPS+，但跟 GPU 同步数据的时间，无论使用 writeBuffer 还是 mapAsync 都要30-50ms，完全拖垮了fps。而相同的数量级下，WebGL 的 bufferSubData 只需要 2-3 ms。Three.js/Babylon.js 整体 FPS 低，除了没有对渲染管线做优化，主要是引擎侧在 CPU 处理数据速度太慢造成的。

测试总结

1. 默认参数/优化下，Three.js 性能强于 Babylonjs，无论创建gemetry的速度还是渲染速度，都快4-5倍左右，内存使用也少1倍以上。原因：babylon相对three属于重量级的引擎了，封装层级太多，提供大量高级api功能，objects套嵌比three多出好几个量级，较为臃肿，内存读取和命中大幅降低

2. Three.js 使用 WebGPU 需要更改部分核心代码，切换到新的 material 实现，目前不能兼容老的material。babylon保持了几乎完美的api结构，切换WebGPU几乎不需要改变任何代码，能完美兼容旧版的api结构，但Babylon的WebGPU渲染性能实在太差，几乎不可用

3. Three 和 Babylon 的性能瓶颈，除了渲染性能外，主要在于大量独立 objects 循环进行 matrix 计算，当场景数量大于5k后，CPU损耗时间将无法忽略，fps明显降低，GPU处于等待状态，资源浪费

4. Three 和 Babylon WebGPU 渲染性能完全没有优势，相比较WebGL，box数量越多，性能反而降低。原因在于：WebGPU没有优化渲染管线，只是简单实现了接口，还是跟webgl渲染管线一致的循环提交buffer 多次darw call的形式，没有按照现代图形管线特性进行优化；尤其是这种大量密集node的场景，WebGPU如果没有利用好group binding进行draw call，性能还不如WebGL

5. Orillusion 无论在创建时间，内存消耗，渲染帧率等各个方面都有压倒性优势，主要原因：

   • ECS架构，没有冗余的Object属性套嵌和层级封装，扁平化组合，提高内存命中和利用率
   • 使用Data-Oriented数据结构设计，能充分利用CPU循环命中内存，大幅提升js计算速度，尤其是针对3D场景的大量matrix计算，有明显提升
   • 得益于ECS和DO的特性，可以充分利用web多线程能力，使得复杂计算可以并行执行，对 matrix计算再次提升性能
   • 充分调用WebGPU的管线特性，将buffer写入/同步和管线渲染分离，尽可能减少CPU和GPU的数据同步次数，减少GPU等待时间
   • 充分利用WebGPU bindgroup 的特性，能将objects充分组合提交，尽可能减少drawcall次数，从而大幅提高渲染性能
   • Chrome 目前 WebGPU 相关 API 还没有优化完成，尤其是 writeBuffer 和 mapAsync 的性能没有完全发挥，是目前 WebGPU 主要的性能瓶颈。

2021年，科技界发生了哪些重大的变化？

随着AR/VR等技术的发展，元宇宙（Metaverse）的概念在这个灰暗的疫情时代，瞬间爆发了，它满足了人们对社交和娱乐的向往，满足了虚拟世界和现实世界的融合。

《失控玩家》剧照

元宇宙并不是一个具体的场景或者技术，它被广泛定义为下一代互联网的形态。这其中需要很多技术的支撑才能得以顺利发展和实现，比如区块链，人工智能，云计算，5G通信，VR/AR，人机交互技术等等。随着Facebook的更名，再次提高了元宇宙在科技界的关注度。

10月29日 Facebook CEO 扎克伯格 将公司改名为 Meta

其中，支持游戏程序代码和图形动画资源的游戏引擎，作为元宇宙场景3D内容制作的底层基础工具，还在高速发展和迭代。目前在端侧已经有了非常优秀的引擎，包括Unity，Unreal等等。

但是，Web环境中始终没有办法实现和桌面级渲染能力相媲美的革命性技术出现。这一现状随着WebGPU标准的提出，即将得到改变。这是非常让人振奋的变革！

什么是WebGPU?

WebGPU是一个API，它为 Web公开GPU 硬件的功能。浏览器封装了现代图形API（Dx12、Vulkan、Metal），提供给Web 3D程序员WebGPU API。

大家比较熟悉的 WebGL 1.0 和 WebGL 2.0 分别是 OpenGL ES 2.0 和 OpenGL ES 3.0 API 的 Javascript 实现的子集。WebGL 的设计可以追溯到 1992 年发布的 OpenGL 1.0 API。这一沿袭可以将 OpenGL ES 大量可用的知识体系和应用程序相对容易地移植到 WebGL 中。

但是，这也意味着 WebGL 与现代 GPU 的设计不匹配，导致 CPU 性能和 GPU 性能问题。这也使得在现代原生 GPU API 之上实现 WebGL 变得非常困难。WebGL 2.0 Compute 的贡献者决定将精力集中在 WebGPU 上。

所以WebGPU不是WebGL的延续，也不对标OpenGL，所以就需要用名称在概念上进行区分。

根据《WebGPU Explainer》中关于WebGPU构建目标的介绍如下：

https://www.orillusion.com/zh/explainer.html

WebGPU最大的优势在于能够更好的利用前端设备的硬件资源，从而使得浏览器在3D以及计算方面的能力得到大大增强。

目前哪些浏览器支持WebGPU？

经过4年多的发展演进，目前支持WebGPU的桌面浏览器有Chrome Canary版本，通过打开flag支持，Chrome 普通94以上版本，通过开发者内测token支持，Firefox 97以上版本也通过flag支持。

经测试，在移动端，目前只有Andriod的Firefox支持WebGPU。

浏览器的版本不断更新，可以参考caniuse发布的WebGPU支持情况，以及各浏览器的版本更细信息。

WebGPU支持情况参考
https://caniuse.com/webgpu

国产浏览器厂商几乎都是基于Chrome内核的，理论上也都已经可以支持WebGPU特性了，有兴趣的小伙伴可以亲自测试下，也欢迎在评论区和社区里留言。

由于WebGPU是W3C制定推进的标准，其他各大浏览器厂商的支持便只是时间问题了。在这样一个相对初期的时间节点，优秀的技术需要被更多的人尽早了解到。

因此，我们为大家营造了第一个 WebGPU的中文社区 ！

重点来啦！！！

Orillusion团队，2021年7月成立，集合图形学，引擎开发，WebGPU应用等各领域的大牛，目标打造第一款基于WebGPU标准的轻量级渲染引擎，并会在不久的将来进行完全开源，方便Web 3D开发者使用，相对WebGL的引擎渲染性能将大大提高。

Orillusion 官网

Orillusion社区目前有哪些内容？

了解WebGPU的API，WGSL使用，请查看Orillusion提供的中文全文翻译。

WebGPU的全部翻译文档已经开源，欢迎大家对翻译不准确的地方做contribution，成为第一个开源社区贡献者！

WebGPU文档翻译Github库
https://github.com/Orillusion/orillusion-web/tree/master/webgpu

WebGPU API 文档一共24章，包括如何使用缓冲区，纹理视图，采样器，资源绑定，计算，渲染管道等，100%对应英文原版API文档，可以对照查看。

https://www.orillusion.com/zh/webgpu.html

WebGPU Shading Language 文档一共16章，包括介绍着色器生命周期，纹理结构，变量类型，代码语句等，同样100%对应英文原版wgsl文档，可以对照查看。

https://www.orillusion.com/zh/wgsl.html

WebGPU Explainer 文档一共四章，包括WebGPU和WebGL的区别，以及如何使用多线程，如何解决错误，和使用案例等，100%对应英文原版API文档，可以对照查看。

https://www.orillusion.com/zh/explainer.html

欢迎更多的小伙伴可以加入我们的Orillusion社区，陪我们一起见证WebGPU的发展。我们会尽自己最大的努力把最干货最前沿的WebGPU技术分享给每一位社区成员，也诚心的希望大家为Orillusion开源社区做出自己的贡献。我们一直坚信，开源社区的技术留痕是每一位技术人员最崇高的追求。因此，我们尊重，我们认可，我们更期待，加入Orillusion，让我们共同进步！

——Link uncharted, 链接未来世界

Orillusion 团队介绍

Orillusion团队由帝国理工大学可视化渲染方向博后创建，团队成员具备顶级的学术背景，包括来自海内外名校的硕士博士，如港大，哈工大，北邮等，而且核心技术研发成员也均为行业内深耕10年以上的技术专家，来自白鹭，AutoDesk等优秀企业。我们也一直持续关注优秀企业和开源社区的相关人才，期待更多热爱开源的小伙伴加入Orillusion，一起改变世界！

团队专注于引擎底层技术研发，主要工作是打造全世界第一款完全开源的WebGPU轻量级通用渲染引擎，目标是在浏览器中实现桌面级的渲染效果，以及支持超大复杂场景的3D呈现。未来团队会一直专注于引擎底层的技术突破，打造优秀的开源软件及开源区，为3D场景爆发时代提供引擎基础工具。