添加链接
link之家
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
Orillusion 正在参加 2021 年度 OSC 中国开源项目评选 ,请投票支持!
Orillusion 在 2021 年度 OSC 中国开源项目评选 中已获得 {{ projectVoteCount }} 票,请投票支持!
2021 年度 OSC 中国开源项目评选 正在火热进行中,快来投票支持你喜欢的开源项目!
2021 年度 OSC 中国开源项目评选 >>> 中场回顾

Orillusion 是一套基于 WebGPU 图形 API 的 Web3D 渲染引擎,能够媲美 PC 端图形 API 的渲染能力。Orillusion 引擎中使用了非常多的 GPU 开放能力,比如灵活操作的 GPU 缓存(GPU Buffer),强大的着色器(Webgpu Shader/WGSL),以及备受瞩目的 Compute Shader 计算内核,充分发挥 GPU 在非光栅化阶段的并行处理能力。

WebGPU 支持

引擎底层没有考虑到兼容现有的 WebGL 标准,而是完全向最新的 WebGPU 标准看齐。随着 WebGPU API WGSL 的持续发展,开发团队也将快速更新迭代引擎底层 WebGPU 的计算和渲染能力,提升引擎性能优势。

ECS 组件式系统

引擎框架发展至今,业内普遍开始采用 组合优于继承 的开发设计原则。因此,开发团队放弃继承式架构,而选择了最新的 ECS 组件式架构做为引擎的成体设计思路。消除了继承模式中的继承链复杂,功能交织的问题,通过解耦,封装和模块化重新的设计,开发者可以更灵活的进行功能组合及扩展。

面向数据(DO)设计

严格的 ECS 架构要求,要求 Entity , Component System 要完全独立分隔。这种设计范式下对于数据优化和性能是可以得到更大的提升。但是同时也会带来很大的负面问题就是开发成本和难度非常大。因此考虑到开发者的使用难度,以及Web开发者的开发习惯。采用了 ECS 中核心 Data Oritented (面向数据开发) 理念,实现按需 DO 的结构。目前的使用方式为,在 GPU 中创建连续内存,同时在 CPU GPU 之间通过内存映射的方式,实现数据的连续高效传递,减少 CPU GPU 之间数据交换的等待时间和次数。既能提高缓存命中率,实现性能的提升,也同时可以保证整体引擎开发和使用的易用性。

集群光照剔除

这里也就是 Clustered Forward Rendering 中的光照剔除方案。在二维 (Tile) 和三维 (Cluster) 同时对于空间进行块状分割,最后只计算对这个块状空间有光照贡献的光源,完成无效光源的剔除过程,提高计算效率。基于 WebGL Uniform Buffer 有很多限制,光源数量支持比较少,一般在10个以内。 WebGPU 有了具备了 Storage Buffer ,基本上就是直接对标 GPU 显存的限制。只要做好自身的内存管理和优化,就可以充分利用GPU的能力,实现多光源渲染的场景。

物理仿真系统

首先接入了 ammo.js ,做为CPU端的基本物理仿真功能实现。同时正在搭建基于 Compute Shader GPU 端物理仿真引擎,包括粒子,流体,软体,刚体,布料等。在 WebGL 时期,只能依靠顶点和纹理的数据结构进行相应的计算过程,实现复杂,效率不高。通过 WebGPU Compute Shader ,内存和数据结构更加灵活,给了很大的想象空间。目前已经实现了很多优秀的物理仿真案例,更多更强的物理仿真的功能正在快速迭代过程中。

基于物理的材质渲染

实现了最基本的 Blinn-phong 模型材质渲染。为了增加更好的真实感渲染效果,依靠 HDR Light ,也实现了基于 PBR (Physically-based rendering) 的材质渲染。也是目前主流引擎的标配了,是一项比较普及的基本引擎要求。

丰富的后处理特效

后处理特效 是使得渲染内容氛围感提升的重要处理方式。基于 WebGPU compute shader ,目前实现了 HDR 泛光 屏幕空间反射 , 环境光屏蔽 等常用的后处理效果。依靠 WebGPU 的通用计算能力可以更高效的利用 GPU 计算优势,实现非常好的效果。

例如, 屏幕空间反射 (SSR) 是基于屏幕空间大小来实现反射效果。相比平面反射,可以实现场景任意表面反射,而且不需要额外的 DrawCall ,是非常流行的实时反射技术。首先,屏幕空间物体的每个像素需要计算其反射向量。然后,需要判断屏幕空间的 Ray Marching 坐标的深度和深度缓存中存储的物体深度是否相交。最后,适当的调节粗糙度,把交点的颜色做为反射颜色完成着色。这个过程中的计算过程,都通过 WebGPU Compute Shader 来实现,避免了 CPU 的消耗。最终在浏览器中可以呈现出非常良好的反射效果。

更多扩展后处理特效参考 PostEffects

本来 react + vite 用得好好的,前几天看到几只前端在鼓吹 react + nextjs 合流,说什么 nextjs 也支持 spa。 就试着迁移过去,结果把自己坑得七荤八素,最后组件状态保持直接给我劝退了。 spa 是从 ssr 进化出来,但又和 ssr 完全不同的产物。一小撮前端为了实现 seo 优化,逆向退化出 nextjs。 作为远古人,我需要你们逆向退化吗?是 php 实现不了 ssr 还是 python 实现不了 ssr? 就算 nextjs 比 php 和 python 有优势(如可以和 spa 项目共享一部分界面组件库),也不能把 nextjs 吹得无所不能吧。 这个 nextjs 所谓的 react 的未来,在我看来除了 ssr 简直一无是处。