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 简直一无是处。