中秋国庆& Creator 3D v1.2 发布,好事乘三!

大噶猴,在预祝大噶中秋国庆双节快乐的同时,Cocos 也带来了 Creator 3D v1.2 介个船新版本,几需体验七天,里造会跟我一样,爱向杰款引擎!

好吧,说正经的,这次Creator 3D v1.2 带来了前所未有丰富的更新内容,致力于让 Creator 覆盖的 3D 游戏品类持续扩大,品质大幅提升。

本视频中展示了近一年来使用 Creator 制作的各种 3D 游戏片段,期待在 v1.2 之后,更多使用 Cocos 制作的高品质游戏上线!

关于未来的规划,v1.2 版本是 2D 和 3D 引擎融合前最后也是最重要的一次大版本更新,Cocos Creator 3D 这条支线也将停止在 v1.2.x 版本上。在 2020 最后的几个月内,我们将尽全力带给大家 2D 和 3D 融合后的 Cocos Creator v3.0 版本。

在保障 3D 引擎平滑升级和原生性能大幅度提升的前提下,还会延续 Creator v2.x 在 2D 游戏领域的既有优势。

届时 Creator 引擎将涅槃重生,开启我们最为重要的新旅程:将 Cocos Creator 打造为世界级游戏引擎。

长文预警:本次内容更新过于丰富,可能诱发满足感和阅读沉迷,请不要忘记分享和点赞哦~

重大功能更新

编辑器插件系统
Cocos Creator 3D 的编辑器在 Creator 2.x 的基础上做了大幅度升级,其中最重要就是编辑器框架重构为更彻底的微内核模式,几乎所有功能模块都是以插件形式存在于编辑器中。

3D 引擎从诞生之初就天然支持插件扩展,只是由于各个模块消息和插件机制的整理进度,所以之前版本中一直没有开放插件体系。在最新的 v1.2 版本中,我们完成了基础的插件机制文档和各个模块的插件接口、消息等,终于可以开放给开发者们,满足大家定制工作流的需求。

新建一个插件非常简单,只需要在扩展菜单中创建即可。扩展管理器中则可以管理所有扩展插件,你可以将扩展插件设置为全局或者是仅当前项目生效。

对插件开发感兴趣的开发者可以关注下面两个文档链接:

编辑器插件文档
构建插件文档

在 v3.0 版本中,我们的插件商店也将迎来升级,同时包含 2.x 和 3.x 版本的插件,也会投注更大的努力在插件生态体系上,帮助开发者通过插件获得收入。

光影增强
在之前的 Creator 3D 版本中,我们对光影的支持还不够完善,仅能够支撑一些较简单的项目需求,具体限制是有两点:

同一视角下,动态光源只允许两盏
阴影只支持 Planar Shadow 平面投影
而在 v1.2 中,引擎对光源和阴影都做了重构和升级,目前已完成

基于多 Pass 的多光源支持,不过主方向光仍然只支持一盏
基于 Shadow Map 的方向光动态阴影,使用方式和之前的 Planar Shadow 平面阴影保持一致
Shadow Map 支持 pcf 软阴影
光源和阴影的渲染都支持 GPU Instancing 合批

Shadow Map 阴影功能和之前版本中的 Planar Shadow 功能合并在场景的全局阴影选项中,开发者可以自由选择使用何种阴影,Planar Shadow 性能更好但只支持平面,Shadow Map 支持向所有物体上投射阴影。在 v1.2 的未来小版本还会对聚光灯支持 Shadow Map 动态阴影,也会加强阴影计算的范围自适应等功能。

编辑器内游戏预览
v1.2 新增了 Game View 预览视图,支持在编辑器内直接运行游戏。开发者在顶部主工具栏的预览按钮左侧可以找到一个新的预览模式选择下拉框,可以选择使用浏览器或 Game View 进行预览。在 Game View 预览的状态下,场景编辑器、属性面板下的所有操作都会被实时更新到 Game View 窗口中。

也可以使用暂停按钮进行实时调试,使用步进按钮逐帧执行。

物理模块增强
与动画模块一样,物理模块的功能也在不断的增强之中,v1.2 之中我们基本补全了游戏中需要的刚体碰撞体,并且开始添加各种约束组件的支持,对物理类游戏的支持得到了极大地增强。下面是具体的新功能:

物理碰撞组独立使用 PhysicsSystem.PhysicsGroup 类型,不再与 Node.Layers 共享分组配置
项目配置中添加物理碰撞组设置面板
添加单形、圆锥、平面、地形等碰撞体
添加点到点、铰链约束组件
网格碰撞器添加凸包近似功能
碰撞体添加获取包围盒和包围球的接口
优化物理事件
重构碰撞点数据


以下为控制人物在地形上行走的演示:

构建系统优化
构建系统的优化项主要是以下几点:

开放自定义构建插件,可以参考插件系统中的构建插件文档
引擎支持构建成文件分离的多模块结果,这将带来以下多个好处:引擎多模块并发加载、动态加载模块、微信引擎插件支持选择不同物理引擎后端
构建结果的 settings.js 改为 settings.json,并放置在 res 下,允许作为资源上传服务器
构建任务原来的查看构建配置已经换为修改构建配置,直接修改就会保存记录
构建平台选择上拆分了原有的 Native 平台,方便定制构建流程,输出结果与之前一致

动画编辑器体验优化
动画编辑器是我们一直在持续优化的重要模块,本次 v1.2 又完成了新一轮体验上的优化,具体优化如:

支持节点树面板中节点的搜索与显示过滤
支持复制粘贴节点上的所有动画数据
动画编辑器的复制粘贴改为使用系统剪贴板,支持跨编辑器的复制粘贴动画数据(节点、轨道以及关键帧)
支持多选节点后批量添加属性轨道
关键帧选取和取消选取操作优化(Ctrl + 鼠标点击选中关键帧可取消选中)
动画编辑器支持多选关键帧后继续点击编辑曲线或者选中未选中关键帧

在这些优化基础上,动画编辑工作的效率将得到更大的提升,比如多选节点后,批量添加关键帧,在 Inspector 中批量编辑关键帧动画数据,可以轻松同步属性的修改到不同节点上;再比如从某个编辑好的节点上复制粘贴完整动画数据到另一个节点上。

具体动画编辑器的所有使用细节可以参考使用文档

脚本系统优化
在脚本系统方面,v1.2 完成了引擎分模块导出,这样做的好处主要有两个:第一,提高加载引擎过程中的并发数量,优化加载时间;第二,支持子模块的动态导入,以物理模块为例,目前已支持 wasm 和 asm.js 版本的动态选择,在支持 WebAssembly 的环境中直接加载 wasm 格式的 ammo 库(bullet),其他环境下自动加载兼容性更好的 asm.js 格式 ammo 库(bullet)。

除此之外,我们也优化了编辑器中脚本编译的性能,尤其是对存在大量脚本的项目,可以大幅度提高脚本更改时的效率。同时,预览项目也会应用项目设置中的引擎模块选择,加强了预览和构建体验的统一性。

支持 ASTC 压缩纹理
v1.2 新增 ASTC 压缩纹理支持,相比于 ETC 和 PVR 等传统压缩纹理格式,ASTC 是功能和性能都更优秀的下一代移动端压缩纹理统一标准。在 v1.2 中,我们还优化了压缩纹理的配置方式,在项目配置中开发者可以建立压缩纹理的预设配置,贴图的配置中只需要选择预设即可,大大节省了之前需要逐贴图配置的时间。

此外,在不支持 ASTC 和 ETC2 这类先进压缩纹理的环境下,我们也专门为 2D 和 UI 的半透明贴图支持了透明通道分离的压缩纹理格式。参考压缩纹理使用文档

全局雾效
这是一个本来计划在 v1.1.1 中添加的功能,但引擎组出于对稳定性的负责任态度,我们决定未来不在第三位小版本中添加功能,所以被延期到 v1.2 中。目前的雾效功能是采用顶点着色器来计算混合因子并用于片元着色器中的颜色混合,除了支持常规的 Linear、Exponential、Exponential Square 雾化处理算子以外,还支持了 Layered 处理算子。使用上只需要在场景节点上,进行全局雾效的配置即可。


具体使用请参考全局雾使用文档

合并部分 Creator 主版本功能
我们已经开始合并部分 Creator v2.x 主版本的功能,为 v3.0 做准备,下面是 v1.2 阶段已经完成的功能合并:

统一组件命名风格,请参考 API 变动章节
ScrollView 和 PageView 组件的修复和功能
Toggle 和 ToggleContainer 组件的修复和功能
RichText 组件的修复和功能
EditBox 组件的修复和优化
Graphics 组件优化
Tween 模块功能和行为同步

可视化 Macro 配置
很多开发者可能用过引擎中的内置宏配置:cc.macro,之前的使用仍然有诸多不便,比如有一部分需要在引擎启动前设置才能够生效;引擎的启动流程修改也偶尔会改变设置时机和行为。为了解决设置宏配置的麻烦,我们在编辑器的项目配置中直接支持了可视化配置,参考项目设置文档的引擎宏配置章节

模型资源预览
编辑器中选中模型后可以对模型资源进行全方位预览,也可以查看默认材质中使用的各种贴图。

在未来的版本中我们还会支持骨骼动画的预览方便做裁切。

渲染层重构
从今年年初开始,我们已经加大了对原生渲染器的研发投入,即将在 v3.0 中推出高性能的多后端渲染器。不仅兼容 Vulkan、Metal 等现代渲染后端,在渲染管线层面也尽可能为了发挥现代渲染后端的性能做了大量重构,这些重构也在 v1.2 中落地了一部分,比如多层 Descriptor Set 抽象取代 BindingLayout;支持 Dynamic uniform buffer 机制;Pipeline State Object 的底层复用;资源化渲染管线。这些重构让渲染层更加健壮,也为高性能的原生渲染器做好了准备,敬请期待今年底即将发布的 v3.0。

暴露地形和 2D 组件材质选项
从 v1.2 开始,我们开放了地形组件和 2D 渲染组件的材质属性,所以大家可以自己制作材质并替换。对于地形,只需要在 Terrain 组件上设置 effect 资源。而对于 Sprite 等 2D 渲染组件,也只需要在组件属性面板上设置默认的 Material 资源。

API 变动和 Breaking changes

1. 组件类名大规模重构
为了符合 Cocos Creator v2.x 的 API 规范,我们将 3D 中组件类名包含 Component 后缀这样的命名方式舍弃了,并做了数据的自动升级和代码的兼容,请放心升级。不过建议开发者还是要在代码中搜索所有类似命名方式的使用,并尽快更改为无 Component 后缀的类名。可以使用下面正则表达式进行全局搜索(打开大小写敏感和正则匹配)

2. 废弃节点上 UI 相关接口
被废弃的接口如下:

属性:width、height、anchorX、anchorY
方法:getAnchorPoint、setAnchorPoint、getContentSize、setContentSize
请先获取节点上的 UITransform 组件,再使用对应的接口,比如

node.getComponent(UITransform).setContentSize(size);

3. 标准材质小修改

标准材质中删除 PBR 贴图自定义通道的功能,只接受 glTF 标准定义的通道排布,即 RGB 分别对应 occlusion、roughness、metallic。如有使用其他排布组合请升级贴图资源。

部分重要更新

由于 v1.2 开发周期较长,包含了数百个大小不同的修改记录,所以在此仅简要列出部分较重要的修改列表供参考。

编辑器更新
增加小秘书入口
新增模型线框功能,在场景窗口右上角有一个工具按钮,点击后可以开启线框显示
立方体贴图现在将支持从一张包含了 6 面的图像中导入(按特定顺序排列)
插件化 preferences,支持插件内定义数据,自动渲染到 preferences 面板
新增设备管理器,可以自定义预览设备的分辨率(在 preferences 里)
插件化 project,支持插件内定义数据,自动渲染到 project 面板
新增 Message List,显示插件对外开放的消息列表,点击“开发者”菜单项的“消息列表”即可打开
新增 Shortcuts 功能,允许自定义快捷键,点击“Cocos Creator”主菜单项的“快捷键”即可打开
Inspector 增加离开时自动保存配置,离开正在编辑的资源的时候自动保存(不配置的时候会弹窗)
脚本导入之前按字典序排序,不再是随机顺序
当构建到原生类平台时,将匹配目标 JavaScript 运行环境来编译脚本,比如 ES6
内置 Mesh Optimizer 工具到模型资源界面
支持导入包含空 Mesh 的模型
减少烘焙库运行的内存占用
内置 primitives 模型支持烘焙 Light map 接受烘焙阴影
引擎更新
渲染管线资源化重构,优化序列化数据结构
在 instantiate 和 addComponent 失败的时候不再返回 null,而是直接报错给用户处理
修复多点触摸时不会派发所有触摸点的问题
增加 sys.getSafeAreaRect 方法,用来获取手机屏幕的安全显示区域
补充 Morph target 在快游戏等平台上的实现(除支付宝小游戏)
优化 Light map 接缝处的漏光现象
Light map 支持 instancing 合批
注意事项
Xcode 12 更新后,我们临时发现工程上有一些小问题,在 iOS 模拟器上运行会报错,主要是因为架构选择中没有包含 X86 架构,大家可以在 Xcode iOS 工程配置中删除 VALID_ARCHS(在 Xcode 12 中已被弃用)。

以上就是本次更新的内容,点击前往官网查看完整更新说明,大有任何意见或者建议,欢迎通过论坛等渠道向我们反馈喔,感谢大家的宝贵支持,让我们的沟通更高效!

:+1: 给力

用1.2.0建了一个空的项目。。。还没做什么 过了一会而就抛出了这个错误。。。清理后,等会又会抛出来。。

都是一些小小游戏,缺乏一些有说服力的优质3D游戏作品,期待未来更好的cocos creator3.0,也希望未来有更加优质的作品建立在ccc之上

2赞

请问约束组件的文档有么?或定义类在哪?求大佬指点一下!

1.2版本的物理碰撞检测不对啊,我还专门去看了遍文档,以下两条都存在问题,而且碰撞矩阵加了删不掉,还有些小bug

触发事件可以由触发器和另一个触发器或者另一个碰撞器产生。
碰撞事件需要由两个碰撞器产生,并且至少有一个动力学刚体

开发到一半又退回1.1重新做了一遍。看来节假日的时候还是少发大版本为好,估计都没心情搞了。

改了之后 成这样了?

麻烦说下具体的问题,可能是使用方式改变导致的误会

是的,目前就是这样的设计,因为碰撞矩阵是按位的,其实添加了只要不用不会有任何影响,不需要删除,只需要在组件上设置目前需要的组就可以了

问题就是,代表玩家的模型上有(刚体组件、碰撞盒组件),子节点手部模型(有碰撞盒、没有刚体),代表舞台的模型(有碰撞盒、没有刚体)。为了确认是不是使用方式的问题,再仔细看了遍文档中提到的以下两条规则,1.2版本使用的是第一条规则,那1.1版本使用的是第二条规则吗?前天晚上发现没有得到自己想要的碰撞效果和触发事件,就做了以下效果的测试,没有仔细研究节点链的情况,就又用回了已经熟悉的方式。

对于节点链的情况,目前有两个思路:
1、每个节点只要有物理组件,就是一个元素,也就是说父子节点的组件无依赖关系,需要多个形状,往该节点上添加相应的Collider组件。
2、从自身节点开始往父链节点上搜索,如果找到了RigidBody组件,则将自身的Collider组件绑定到该节点上,否则整条链上的Collider组件将共享一个RigidBody组件,元素对应的节点是最顶层的Collider组件所对应的节点。

1.1 效果

1.2效果

关于触发事件和碰撞事件,在1.2中,如果我想把一个只带碰撞盒或触发器的节点划分到指定组里时,就必须给这个节点添加刚体,无论它的父级节点是否有刚体,不然它就属于默认组是这样吗?我之前的困惑就是以为没有刚体的触发器已经被划到了父级节点的组里,然后在碰撞矩阵里设置,没有得到我想要的效果。

应该是这样,指定分组必须用刚体,之前版本中使用的是节点的 Group,所以会有比较简单的级联,在 1.2 版本中,我们分离了节点 group(用于渲染)和碰撞体 group(用于物理),所以才会有这个差异,具体的话等 @JayceLai 节后回答

好的,我做的小游戏目前用1.1的实现方式确实要比1.2方便些,先链个试玩链接:https://d119.itch.io/beat-him,本来昨天想再分享个开发过程的视频,不过废话太多剪视频剪了好久,稍后补上。

1赞

3.0 版本的 类 还是通过 cc.xx调用 还是沿用 cocos 3d 的 去掉cc 。。后期从1.2 改为 3.0使用时。会不会代码编写用法上差异巨大。

期待新Cocos Creator, 特别是原生平台的表现。

希望原生平台能流畅

3.0的内测版什么时候会出来

删除资源,一直转圈