本文来自 Galacean 团队编辑器架构师胡松在“第二届中国网络图形学与 Web3D 高峰论坛 - Web3D 引擎分论坛”演讲的内容,主要就编辑器的架构思路和大家进行交流
资产架构
整个编辑器本质上就是对资产的上传,编辑和导出。
可以看一下核心的资产处理管线,从添加资产,到预上传,然后是上传 CDN,到预初始化,然后是编辑器编辑,最后打包供 Runtime 使用。其中红色标记的部分,是可编程的处理管线。
以 FBX 为例,编辑器在 FBX 预上传的过程中,把 FBX 转成引擎支持的 gltf 格式,在预初始化过程中,如果模型没有切线,没有法线,可以根据顶点和 uv 自动计算。也可以去除掉 DCC 软件中错误添加的灯光和相机。在最后打包时,可以通过 MeshOpt 和 Mesh Quantize 去优化网格,通过纹理裁剪和 KTX2 去优化纹理。
以 KTX2 为例,深入展开编辑器对资产侧的优化。首先我们先看传统的纹理压缩格式,有 ASTC,ios 和 android 高版本支持,效果最佳,兼顾内存和尺寸,PVRTC ios 低版本支持,效果较差, ETC,android 低版本支持的,效果也不太好,BC 是 windows 上支持的,也分有 BC3/BC5/BC7 等等。而 KTX2 支持的 Basisu 超压缩纹理格式,可以在运行时转换成不同的纹理压缩格式,Basisu 内部也有 ETC1S 和 UASTC 两个编码方式,ETC1S 是内存和尺寸最优,UASTC 是效果最佳,兼顾内存。
那我们为何选择 KTX2 呢,像 Unity 引擎,面向不同的平台可以打包不同的纹理格式。而 Web 应用,和 Native 应用不一样,对外暴露的是一个 URL 链接,所有的平台都可以访问,而我们需要通过对应平台支持的压缩纹理格式直接转码成对应的压缩纹理格式。KTX2 兼顾了内存,尺寸、平台兼容,是 Web 侧最佳的压缩纹理格式。
这里是 Khronos 官方的一个效果对比图,可以看出 KTX2 对比于传统的 JPG/PNG 在效果,内存和尺寸上都有优势。
当然大家可能会担心运行时转码的速度,我们已经有一些测试数据,如果使用的是 Khronos 转码器,一张 512 * 512 的图片,只需要 2 ms,而是用 jpg/png,则需要 8 ms。并且 KTX2 的转码是异步的,也可以使用 WebWorker 加速。所以完全无需担心在实际业务中的使用效果。
在我们的编辑器侧也直接集成了编码方案,只需要默认勾选一个按钮,默认使用平衡模式,使用 UASTC 编码,开启 MIPMAP 和 ZSTD 压缩,glTF 里的纹理也会使用 KHR_texture_basisu 扩展转换成 KTX2。
前端架构和视图区
聊完了资产侧,接下来我再说一下编辑器的前端架构和视图区的技术方案。
先说一下 View 层,整个编辑器是基于 React 开发的,我们使用 radix-ui 作为 headless component 作为 UI 组件的基础,使用 stitches.js 的一套 css in js 的方案去开发编辑器样式,再基于自己设计的一套 design token,开发了属于 galacean 的 editor-ui。基于这套方案,只需要定义 design token 就可以很方便地开发不同主题的编辑器。
接下来我们看下 View 层如何和数据管理结合的,首先我们使用 mobx 作为数据管理框架,使用 mobx-react-lite 快速和 View 层进行双向绑定,本质上就是 MVVM 的思维。
但是到引擎侧的内存,就是单向数据流,因为许多 UI 的表达和引擎的 API 不一致,为了更加灵活地处理,我们使用的是触发式的修改。
除了数据模型,viewport 本身也是有很多内容的,我们采取得是一套插件方案,有不同 Viewport 生命周期钩子,通过这套模式,我们可以把不同的组件嵌入到操作区中。而这些组件又来自于 ToolKit 中。
而这些 Viewport 本身的功能,又是源自于 Toolkit 工具,像辅助线,无穷网格,transform gizmo,navigation gizmo,mesh/骨骼查看器。简而言之,视图操作区就是 toolkit + 插件机制。另外所有 Viewport 使用的 toolkit 功能我们都已经开源,大家可以任意使用。
开发协同
最后我说一下编辑器的功能如何去和业务进行协同开发。
在此之前,我想说一下我们为何要做一个云端的编辑器和我们的一个业务形态。我这里先说一下云端编辑器的优势和劣势(如上图所示)。
那为何我们要采取 Web 方案呢?我们先来对互联网公司业务和游戏业务进行一个简单的对比。
首先是业务形态的差异,互动业务大部分比较简单,只有一个小的 3D 展示,无需代码处理交互逻辑,而游戏业务中却充斥着大量的交互逻辑。
而在编辑器使用的合作模式上,也有较大的差异。互联网公司的业务基本上就只有一个 TA,需要大量的外包介入去调整灯光,材质,动画等等。需求是快速编辑,快速协作。而游戏开发则是专业的游戏前端和 TA 一起,需求编辑器功能强大且稳定。
在最终导出的结果也是有差异的,我们的编辑器导出的是一个互动前端组件,一个 npm 包,被引入到前端页面中,需要和前端业务联调进行二次开发;而游戏只需要在编辑器项目中写脚本,直接打包出生产可用的包。
基于以上一些业务差异和业务需求,Web 编辑器更加适合我们的业务需求,也更加符合团队的技术栈,所以我们采用的是一个云端的方案。
当然我们也有需要写交互逻辑和 Shader 代码的时候,我们正在开发一款 VSCode 扩展,在 vscode 中登录 galacean editor,同步项目,在本地的代码编辑器中编写脚本和 Shader,达到无缝体验的一套方案。
最后还是今年的重点方向(和发布会一致)
最后
感谢各位的观看,在 1.1 版本后,编辑器和引擎的发布计划会趋于一致,演讲内容中的一些功能也会发布,也欢迎大家在官网申请内测资格,我们也在计划后续的公测时间。
如何联系我们
Galacean 开源社区群 (钉钉):
Galacean 开源社区群 2 群群号:31065609
Galacean 开源社区群 (微信):
添加群管理员微信:zengxinxin2010, 并备注 “galacean 加群”
网站
官网地址
galacean.antgroup.com
Engine 源码地址
github.com/galacean/en…
Engine Toolkit 源码地址
github.com/galacean/en…