Cocos Creator 3.6 今日发布

Cocos Creator 3.6 今日发布。在 Cocos 团队内部,我们一直将 3.6 作为 3.0 的合并版本之后最重要的里程碑版本来看待,一方面这个版本的迭代周期是迄今为止最长的一个版本,另一方面是因为这个版本在多个方面的大幅进化。下面就是 3.6 版本的更新说明,由于更新数量过多(engine:1110 PRs,editor:678 PRs),在此只列出相对重要的更新。

重点更新

图形渲染

Surface Shader 自定义材质

Surface Shader 使用统一渲染流程和结构,可以让用户以简洁的代码创建表面材质信息,指定用于组合的光照和着色模型。相比旧版(Legacy Shader)的优点是更易书写和维护,有更好的版本兼容性,也更不容易产生渲染错误。并且可以从统一流程中获取很多公共特性,如统一的全场景光照和 Debug View 调试功能等。

Creator 也更易扩展出多种常见的复杂材质提供给用户,未来还会支持 Shader Graph 自动生成 Effect 代码,可以极大提高 Shader 开发者的效率。

CSM 级联阴影

普通的阴影贴图有一个致命弱点:当投影面积较大时,对阴影贴图分辨率的需求会超出硬件承载极限。如果不提高分辨率会导致阴影锯齿严重、形状缺失、不清晰,但减小投影面积又会导致阴影可视距离非常短。在阴影可视距离和阴影效果上的平衡调整是一个非常令人头痛的问题。

CSM将视锥按远近顺序划分为多块,近处投影范围更小而远处投影范围更大,相当于一个自适应的阴影贴图,从而提高数倍贴图利用率。它可以在较大的阴影可视距离上具备精细的阴影效果,再也不用把精力花费在参数调校上了。

新增 Rendering Debug View 模式

多种自定义的显示模式,帮助用户更快定位各种材质、光照、阴影显示问题,以及方便用户查看更清晰的特定场景信息,帮助用户做出优化决定。

GGX 环境反射卷积图

由于精确光源的高光都是使用 GGX 的 BRDF 分布,对于环境光源而言也必须使用同样的 BRDF 做球面卷积才可以让两种光源的光照效果对应。此外不同粗糙度的反射光照是存储在对应的 Mip 中,相比于自动生成的 Mip 数据,卷积计算可以修复以下问题:

  • 环境高光的泛光和拖尾现象被极大的削减了
  • 与 Substaince 的标准 PBR 材质工作流效果对不上
  • 平行光高光和环境光高光效果对不上

如图所示:

自动 Mipmaps
GGX 卷积
GGX | 平行光 | Mipmaps

各向异性光照模型

通过 Surface Shader 带来的好处,我们可以充分扩展 PBR 光照模型。在 3.6 已经完整支持了在精确光源和环境光源下,各向同性和各向异性的材质与光照模型。可以对接 Substaince PBR 材质库,制作拉丝纹路的金属、头发、丝绸等等。

其他

  1. 支持设置 Skybox 材质
  2. 增大材质的 Normal Strength 范围
  3. 新增 GLTF specular-glossiness workflow 支持
  4. 更新默认 FBX surface phong 材质支持
  5. 扩展 Blender principled bsdf 材质的 Specular 通道支持
  6. 添加 mixamo.com 模型材质导入支持

编辑器体验

UI 全面升级

V3.6 启用了全新的编辑器 UI,本次改版围绕「更协调」的视觉系统、「更科学」的视觉反馈、「更沉浸」的交互感受,对 UI 和交互进行了一次全方位的梳理。我们希望通过交互来改善视觉感受,通过视觉来影响交互体验,并从这两个层面进一步提高用户体验。未来我们将继续基于 Cocos 的设计目标、设计系统、设计原则进行规范化设计,持续更新迭代,优化核心交互和工作流程。

内置编辑器预览模式

开发效率是 Cocos Creator 非常重视的一项核心优势,在 v3.6 中这项优势得到了进一步提升。除了网页预览和模拟器预览,现在开发者还可以使用「编辑器预览」来运行游戏。编辑器预览将在场景管理器中直接执行游戏逻辑,并且可以实时调试游戏场景。一方面带来更无缝的预览体验,另一方面也补足了在调试方面的短板。

此功能目前处于实验性阶段,欢迎大家在使用过程中给我们更多反馈。未来我们也将持续关注研发效率,在脚本编译、项目调试、构建发布环节持续提升用户的幸福感。

动画嵌入播放器

动画编辑器新增了嵌入播放器功能,可以在任意动画中嵌入其他粒子和动画,并用类似视频剪辑软件轨道的方式进行编排,自由调整时长和播放位置。

在完成编辑之后,嵌入播放器的内容会伴随此条动画剪辑(AnimationClip)一起播放,在 Animation 组件和动画图系统中都能支持。此外,动画嵌入播放器支持添加到 FBX 导入的动画上,可以实现更灵活的特效控制,解决了导入动画难以二次编辑的问题。

目前在 3.6 中提供了粒子和动画两种播放器,可以在实验室设置中启用。

集成多语言支持

为了更好地服务开发者出海,v3.6 提供了内置的多语言工具 Localization Editor(L10n),目前支持文本翻译和资源替换。其定位是与 Creator 深度集成,通过高自动化提高翻译的效率,并且以无代码的方式降低使用门槛,达到任何人都可以开箱即用的目的。

包含的核心功能为:

  1. 支持机器翻译,目前接入了 Google、有道翻译
  2. 支持一键提取各类需要翻译的内容
  3. 支持 Excel、csv、po 文件批量导入导出
  4. 支持多语言实时预览及资源替换

Localization Editor 目前处于实验性阶段,未来将提供更丰富的游戏本地化能力,欢迎大家提供反馈。

场景编辑器

  • 支持表面吸附和顶点吸附
表面吸附 Surface Snapping(按住 ctrl/cmd + shift)
顶点吸附 Vertex Snapping(按住 v)
  • 支持框选功能,可以批量选中多个物体

构建能力

  1. 可以在构建任务中自由选取和组合 Build、Make、Run 等子任务执行
  2. 资源服务地址已作为全平台共用参数,支持一键使用构建内置服务器,方便本地开发测试
  3. 优化了构建内编译引擎与编译脚本的任务调度,独立进程执行,降低构建进程对内存的占用
  4. 允许在偏好设置内添加自定义 cmake 工具供原生构建使用
  5. 构建钩子函数支持 onError 钩子函数用于捕获构建失败的情况
  6. 允许在偏好设置里关闭构建纹理压缩、引擎、自动图集对缓存的使用

其他

  1. 支持 Mesh 资源的缩略图显示
  2. 支持取消对场景编辑器的帧率限制(实验室功能)
  3. 支持直接在 assets 面板筛选 Bundle 文件夹,快速找到 Bundle

基础设施

原生化层级上升

从去年 3.3 版本发布之后,其中最重要的原生化团队就开始了针对 3.6 版本目标的开发工作。这么长的周期其实往往是一些底层根基性重构所必需的,而商业引擎服务于全行业的特殊性决定了它既要紧跟硬件的发展不断挑战最好的性能、最优秀的画面表现力,还要在生产端不断提升生产效率,保持对项目的兼容性和对不同硬件环境的伸缩性适配。这些挑战意味着引擎需要对底层框架进行持续的迭代和重构,有时候是破坏性的,比如从 2D 引擎进化为 3D 引擎,而大多数时候这种迭代是延续性的,比如我们在 3.6 的原生化进展。尽管花费了我们团队一年的时间,进行了多个阶段和多个模块的重构,原生层代码增加了两倍多,但我们仍然在大幅度优化性能的基础上做到了对老项目的兼容。这样的底层重构一方面带来了可见的性能和表现力提升,另一方面,我们往往是为了未来的进一步迭代做好准备,扫清障碍。从 3.6 这个版本的缩影大家可以看到引擎开发永恒的命题:持续不断得自我变革,以适应硬件的更新和用户需求的变化。

2D 渲染性能

3.6 还有一个重要的具有里程碑意义的标志,那就是在 2D 渲染性能上和 2.x 达到了同样的水准,代表着 2.x 用户如果有 3D 需求或持续迭代需求可以放心升级到 3.x。在底层原生化的基础之上,我们进一步将 2D 渲染数据结构、2D 合批管理器和渲染流程都原生化了,让 2D 的合批和提交渲染的流程都在原生进行,以达到类似 2.x 的性能表现。当然,现阶段还有部分遗留的工作没有完全完成,比如 Spine 的合批支持,但这也代表着在原生化的基础之上,3.x 的 2D 渲染性能还将有更高的天花板等待我们去突破。

添加原生插件能力

原生插件可以链接开发者现有的 C/C++ 代码库,绑定接口到JS层并在不同项目间重复使用。 

通过利用 CMake 的能力,插件能灵活地集成源文件、静态库或动态库。C/C++ 接口可以直接使用传统的自动/手动绑定机制,也可以使用3.6 新增的 sebind 高阶接口导出到脚本层。 开发完成后,原生插件可以 zip 包的形式单独分发, 也可以打包到 编辑器插件 一并发布。

详细使用方式请参考 使用文档 和 使用范例

其他

  1. 添加更易用的高层 JS 绑定 Sebind
  2. 集成 Android Game Activity
  3. Downloader 支持在 iOS/Android 平台的断点续传
  4. 添加 `settings` 模块以便用户访问,保存了用户预设的运行时项目配置
  5. 重构引擎启动流程,简化 application.js 逻辑,增加启动阶段的事件

框架能力

Marionette 动画系统更新

  • 动画图支持动画预览
    编辑动画状态机时可以实时预览,过渡与混合的效果,快速调试,无需每次修改之后都要运行游戏才可以查看结果。
  • 动画图支持变量和 Layer 重命名,支持更清晰的自定义的名字,方便修改。
  • 动画图支持过渡线的排序, 清楚看到过渡所使用的优先级。
  • 动画图增加了 “终点起始时间” 属性,允许过渡的目标动画从指定位置开始播放。
  • 动画图现在可以将某个过渡配置为可中断的,以允许指定的过渡被其它的过渡中断,该功能可在实验室设置中启用。

粒子系统更新

  • 新增粒子噪声图模组,为粒子带来更自然,更加可控的随机运动效果
  • 支持 Instanced Mesh,提升发射器的性能
  • 修复粒子编辑面板不支持 Undo 的问题,方便调试
  • 支持子节点树的组合粒子预览控制

其他

  • Mesh 支持动态类型,可以在运行时通过 API 更新网格数据
  • GeometryRenderer 增加曲线类型 Spline(支持 Linear, Bezier, Catmull-Rom 曲线)
  • 支持 3D 空间 SpriteRenderer
  • 在 UI 顶点数据中填充 z 值,以便支持 UI 的 3D Transform
  • 支持渲染组件的优先级排序
  • 支持音频 PCMData 和 sampleRate 获取
  • 地形画刷支持旋转
  • 支持地形高度画刷
  • Light map 烘焙器支持使用 tga 贴图格式
  • MeshRenderer 会自动设置渲染用的 Light map 资源
  • 更新 iOS 原生 EditBox 样式

DCC

FBX/GLTF的 Phong 和 PBR 材质智能导入

3.6 在材质导入上实现了对 Diffuse-Specular 材质模型(包括 Phong 和 SpecularGlossiness PBR)的支持,可将材质参数智能转换到标准 Metallic Roughness PBR 模型中。这样就可以在不更改光照模型的情况下获得接近原 DCC 软件中的材质表现。

Blender |未使用材质转换 |使用材质转换
使用 Phong 材质的 FBX 智能材质导入

不再默认拆分模型

之前的版本由于 uniform 的限制,在 CPU 计算的骨骼动画中,当骨骼数量超过一定值后,无法一次性通过 uniform 存储所有骨骼数据,所以我们在模型导入时有可能拆分模型和骨骼。所以经常收到反馈说自己的一个角色模型会占用多个 DrawCall,主要原因就是这里被自动拆分了。更重要的是由于拆分不能在运行时进行,只能在离线进行,所以我们的拆分标准使用的是最低端的运行时设备和驱动(iPhone 6 WebGL),对骨骼数量限制很大。

所以,Cocos Creator 3.6 对这一问题做了策略优化:

  • 默认情况下不再拆分模型,不对导入的模型数据做修改(也维持以前的模型设置不变)
  • 如果骨骼数量未超过实际运行时驱动的限制,直接使用 uniform 传递
  • 如果骨骼数量超过限制,则使用纹理传递

使用纹理传递骨骼动画数据的方式需要在顶点着色器中访问纹理,这一特性最低支持为 OpenGL ES 3.0, WebGL 2.0。但依靠 GL 扩展,在仅支持 OpenGL ES 2.0 和 WebGL 1.0 设备上,几乎已达到 100% 的覆盖率,所以无需担心兼容问题。

目前保留此选项应该只是为了保持旧项目的兼容性,在适当的时候会考虑移除。


版本升级提示

  • Windows 平台移除 Win32 支持,仅保留 Win64 发布
  • iOS 平台最低版本支持从 iOS 10 变更为 iOS 11(为了使用 C++ 17)
  • 内置材质的命名和编辑器中的命名保持统一,因此 EffectAsset.get、Material.initialize 中使用内置 Effect 时通常需要加上 “builtin-” 前缀。
  • 构建模板中 application.js, game.js, index.js 等文件被更新了,如果有在项目或者构建插件中自定义过模板,请重新生成并做相应修改。详见 升级文档
  • settings.json 格式发生修改,对这个文件做了定制化处理的插件可能会无法使用。详见 升级文档
  •  由于引擎内部会对 Mask 下的节点做特殊处理,在获取 Mask 下的子节点时,建议使用 getChildByName 函数,通过名字而非索引来获取,以避免不可预料的问题出现。
  • Android gradle:替换 jcenter 为 mavenCenter 
  • 添加可从 `cc` 导入的 `native` 模块,包含代码提示,用于替代 `jsb` 全局变量
  • 我们默认关闭了字节开发者工具的 ES6 转 ES5 功能,来解决一些编译遇到的问题。因此我们需要手动将开放数据域模板工程转成符合 CommonJS 规范的写法,否则会因为不能识别 ES Module 导致字节的子域启动失败。如果你的项目也遇到了这个问题,请参考该 PR 修改 `项目路径/build/bytedance-mini-game/openDataContext` 该路径下的工程

前往官网下载体验 v3.6,再次感谢各位开发者的支持与关注!