上周， 引擎技术总监 Panda 、《Lake》制作人 youyou 、布道师 放空 在 B 站围绕《Lake》中真实湖景的打造为大家带来了一场干货满满的直播(完整回放），吸引了1000多名小伙伴围观。抓住许久不见的 Panda 大佬，大家抛出了许多对 引擎规划、功能使用 的疑问：
- Cocos Creator 3.5/3.6 何时发布？
- v2.x 还会维护吗？
- 在提升性能与稳定性上的投入？
- 原生化、自定义渲染管线、后处理特效进展如何？
- ……
你最关心的问题，现在解答！
《Lake》 会开源吗？
youyou： 《Lake》目前还处于 Pipeline 的整理阶段， 在 v3.6 版本，我们对引擎的 Pipeline 做了一个比较好的重构，到时会把《Lake》升级到 v3.6，运行在全新的自定义渲染管线上， 争取那时开源给大家。
还有一点，虽然现在项目已经能比较好地跑在 PC 和手机端的 web 上，但王哲强烈要求我们把它也跑在小游戏平台上，我最近也在进行这方面的努力，现在已经成功运行了，但渲染方面还有可以优化的地方，等把渲染能力调好以后，也会在小游戏平台上把它公布出来。
如果想应用 FSR 超分辨率技术达到《Lake》中的效果，是不是得修改目前的渲染管线？
youyou： 目前 v3.4 渲染管线的自由度可能还没有那么高，这也是做这个项目的原始诉求之一。只有我们引擎团队自己能够比较舒服地使用搭建的管线，才敢给到开发者去使用。目前想在 v3.4 中插入一个渲染模块还是比较麻烦的，需要你比较了解现在的渲染管线的内容， 但在 v3.6 中，我们将实现自定义渲染管线，你想加入渲染模块就比较简单了。
渲染管线是提升游戏渲染能力非常重要的一个环节，决定了整个后效的质量。目前《Lake》应用得已经很深入了——包括平面反射，它是用一个单独的摄像机画出来的，里面也包含了自己的 TAA——我们可以自由地在一个渲染结果上叠加另一个渲染结果。制作这个项目也是为了用它去打磨我们的渲染管线，打磨得比较好之后就会告诉开发者怎么使用。
Cocos Creator 似乎很专注在渲染的提升上，但这些能力开发者可能在实际项目中还用不太到，更关注引擎的基础功能和稳定性。v3.x 会在什么地方发力？
Panda： 首先，我们投入最大的一个方向始终是引擎性能和稳定性的提升。 可能大家看到了我们的《赛博朋克 Demo》、《Lake》，想说我们是不是花了很多资源在上面？ 其实并没有，这些东西远远不是我们投入最大的， 我们最多的资源是花在引擎迭代、基础设施、性能优化、bug 修复、稳定性提升、原生化、工具链等这些开发者们最关心的东西上。
比如说原生化，其实我们对原生的投入非常早。我们在2020年的时候做了 GFX 的原生化，21年 Render Pipeline 原生化，21年中开始做 Render Scene 的原生化，这块复杂度比较高，需要的时间也多，我们将在 v3.6 给大家一个更好的原生化版本，v3.6 中很多上层的东西也已经在原生了。
其实引擎的性能和稳定性是一直有在快速提高的，但引擎是一个复杂的工程，不同人的使用场景不一样、需求也不一样，很难说在短时间内把所有东西都做得很完美，但我们一直都在努力，这也是我们最重视的。
如果用 v3.x 来做 2D 项目，性能上能够得到保证吗？
Panda： 其实在 v2.x 时期，我们的原生性能也是经历了大概一年多的迭代才逐步提升上来。 现在在 v3.x，我们在 JS 引擎环境里面的 2D 性能已经完全和 v2.x 匹配，甚至很多地方已经超过了，因为我们做了很多比 v2.x 更深入的优化。 但是 v3.x 跟 v2.x 相比有一点系统性的劣势，就是它的渲染器是 3D 的，渲染器层面的复杂度造成了我们在 2D 游戏上有一些额外的损耗，这些损耗确实也是不得已的。所以为了弥补这些损耗，我们在上层，2D 渲染的数据整理、合批方面做了更多更深入的、比 v2.x 更好的优化。
但是在原生 2D 性能上，尤其是 spine 上，大家可以感觉到同 v2.x 还有一点差距，这是因为 v3.x 原生化的进展还没有到 v2.x 的那个那个水平，虽然我们已经在用原生的 spine 库在运行 spine 的动画模拟，但是模拟完后数据还得再拷贝到 TS 层，再在 TS 里去提交回原生渲染，是一个很绕的过程。 而这些问题在 v3.6 都会被消除掉， 我们现在正在做 Batcher2D（2D 合批的核心模块）、Render Data 等 2D 基础设施的原生化，这些东西全部原生化了以后，引擎做 2D 合批、2D 渲染的整个过程就全部都是原生的了。
v2.x 还会维护吗？
Panda：v2.x 会继续维护，响应用户需求，但不会再有重大更新。 比如说如果有一些 bug、第三方工具的升级会影响到大家的使用等，那么我们可能会再对 v2.x 进行更新，但新功能不会再增加了，统一放到 v3.x 做支持。
v3.5 和 v3.6 有哪些更新可以提前透露？什么时候发布呢？
Panda： v3.5 这个月底会提测，预计很快就会跟大家见面。 v3.5 重点依然是提升稳定性以及优化编辑器体验。 此外还有一些包体的优化，比如我们把 Animation 这个模块彻底拆分了——很多开发者关心我们的模块什么时候能做得更细一点，v3.5已经做了一部分，还不够多，这部分会持续优化。
v3.6 预计在今年年中正式发布， v3.6 中会实现渲染管线的可定制化，以及 Surface Shader 的定制， 这两者的实现能让大家把渲染的把控力牢牢掌握在自己手中； 同时材质系统也将全面升级。
今年我们针对 美术工作流、版本管理 等也提高了支持力度。目前有专门做 DCC 的同学在研究和优化美术工作流，可能在 v3.5 和 v3.6 都会有一些成果出来。
动画状态机的后续优化？
Panda： 动画状态机在 v3.5 增加了 layer 和 masking 的功能，有了动画层级和遮罩以后就可以做上下半身分离动画了，这是一个很大的进展。未来在动画系统方面会重点研究 重定向、IK、RootMotion 等。
引擎会内置一些好用的特效吗？
Panda： 大家看到《Lake》很漂亮是因为它有很多后处理效果， 这些效果我们将在 v3.6 的定制渲染管线全部完成后再去添加。 并不是后处理效果很难加，而是我们的渲染管线需要有延续性，不能说先出了一个版本以后，过几个版本大家自己做的后处理就不能用了，还得再升级，这对体验是有很大问题的，所以我们一直压着后处理的研发，就是为了等自定义渲染管线完善之后能给开发者一个更完整、稳定的版本。 目前后处理效果大家可以通过 RenderTexture 去添加。
有做 NavMesh 导航寻路的计划吗？
Panda： 目前 NavMesh 已经有一个社区插件了，有需要的同学可以找麒麟子，他那边会给你更完善的解决方案。目前引擎暂时没有直接做 NavMesh 的计划，重心放在基础设施上——看起来我们讲了好几年基础设施，确实是 3D 的基础设施比较多比较难，基础不做好以后很难有个大的提升。
NavMesh 导航网格寻路插件：
Cocos Creator3.x NavMesh导航网格寻路 | Cocos Store
什么时候支持加载远程 gltf？
Panda： 这个事情在规划当中，v3.5 会加入一个 Dynamic Mesh 的能力，就是动态网格。有了动态网格以后，大家就可以从 gltf 里面自己解析网格数据，用动态网格的方式去加载到引擎里。未来引擎的 gltf 导入器可能也会被集成进来或者开放给社区。
Bundle 打包有自动图集为什么还有散图？
Panda： 有可能是因为你的散图是放在 resources 目录底下的，引擎不知道你要不要动态加载它，所以不得不把它打包出来。如果你的自动图集是放在普通目录底下的话，只要你有放在 Bundle 里面，它是不会再出现有散图的情况的。所以不需要动态加载的东西尽量不要放在 resources 目录底下。但这块确实也是很容易让用户误用和混淆， 我们也在考虑怎么样优化指定打包和加载策略的方式。
什么时候优化 git 协同工作流？提交全是冲突。
Panda： git 协同工作流提交重组这间事情是因为我们序列化的结果不稳定导致的，这个我们编辑器那边会去做后续的优化，把构建结果稳定下来。序列化的机制目前也在重构调研。
会不会优化原生打包构建？
Panda： v3.4.2 已经优化了 iOS 的构建流程，感谢社区的反馈，我们之前有很多问题，用户定制不方便，现在实现了一个跳过 Xcode 的构建流程。未来我们也会基于 CMake 做原生构建的插件化，让大家可以引用一些原生的第三方模块，简化构建流程。
有没有办法省掉语言转换过程？
Panda： 省掉语言转换的过程是很难的，但是我们会优化跨语言调用的性能损耗并尽可能减少跨语言调用。目前还是尽可能地把更多的逻辑往 C++ 里面搬，让原生的比重更大一些，然后更重要的还是优化跨语言调用的性能。有用户说跨语言交互会很慢，这个确实是的，跨语言的交互是核心要优化的点，我们现在投入很多资源在做这些。
感谢所有开发者的支持与关注！Cocos 将继续把引擎技术产品做扎实，为开发者提供更加稳定、强大的创作工具，和大家一起追逐梦想，助力行业效率提升！
