Orillusion

帖子

• ---

  Flash退出历史舞台后，Web端3D会迎来怎样的发展？
  A admin

  上一期讨论《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项目
  A admin

  看了这么多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，关注我们，敬请期待后续的分享！

• ---

  Khronos 会议干货 | WebGPU 1.0 即将发布
  A admin

  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的几个最佳实践

  

• ---

  Web or Native 谁才是元宇宙的未来（下）？
  A admin

  上一篇文章我们介绍了 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引擎正在考虑是否兼容HLSL和GLSL
  A admin

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

• ---

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

  随着元宇宙概念的爆炸式出现，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端渲染引擎框架概述
  A admin

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

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

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

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

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

• ---

  WebGPU: compute shader的使用场景有哪些
  S shuangliu

  Compute Shader是允许我们，把本来在CPU端要做很大计算的一些事情放到GPU来做，而并不是在某些特定的场景才会使用。

  利用GPU计算一直都有，在WebGL的中，我们也经常用vertex/ fragment shader 进行复杂计算，主要用于粒子特效的模拟或仿真，但确实使用不方便。一些纯计算 / AI引擎，比如TensorFlow，也会利用WebGL 模拟进行 GPU 并行计算

  WebGPU 开放 Compute shader 后，可以更方便的进行 GPU 计算开发，粒子系统，AI训练，或者物理系统模拟，可以更高效的开发。

  当然，有了compute管线后，一些经典的渲染场景，例如延迟渲染，光线追踪，主动剔除等复杂的渲染计算成为可能，要比WebGL的开发灵活性和能力强很多。

  除此之外，最简单的使用场景，例如把 mvp transform的矩阵计算放在compute shader中进行，要比写在vertex shader中更灵活，gpu性能利用率更高。