动效链路可行性调研

动效链路可行性调研

我们没有必要重新发明轮子，但是要记得从头推理一次。

目标：3D快速产出、稳定性、体验流畅度、长尾用户的完整性

问题：

• 视觉&研发交接
• 场景还原度
• 体验流畅度
• 稳定性

该方案是基于个人视角的研发链路梳理，链路主要分为6个部分，目前每个部分的分析主要在整体链路上的角色分工和输入输出的概念判断，细节和上下文还不完善。预期链路目标为支持3D场景下需求快速平稳落地，同时保证体验流畅度和用户覆盖的完整性。

主链路在于资源生产、SDK和稳定性，其次编辑器、资产管理和性能测试。

资源生产

设计师差异 软件差异 引擎差异

3D场景下主要有三类资产，模型/场景/动画，并且根据不同的需求进一步可以细化为建模/贴图/骨骼/特效等不同的设计需求。通常3D场景的效果验收在后期有较多的调整需求，这往往是由于三个差异导致

• 人的差异：不同的设计习惯，可能会造成较多的资源空间浪费，遗留性能问题到后期

• 软件差异：不同的软件的资源导出格式不同，存在较多的规范不统一

• 引擎差异：不同引擎的渲染实现不同，对素材资源的解析不同，导致最终渲染结果产生差别。

因此对于标准生产链路，在资源生产环节应该有一个统一的收口，这也是后续标准化处理流程的前置非技术依赖。这一块整体来说还是依赖经验积累和整理，有多个比较分散的切口：UG大型互动总结/Oasis美术建议/Clone X资源规范，但更多的需要设计视角参与，因为这里整体偏设计效率。目前王昊在这一部分应该有一些经验（涉及SAR的设计对接他都有比较多的参与，王昊作为半固定接口人？偏TA角色）。

https://oasisengine.cn/0.6/docs/editor-art-cn

资源管理

存储 分发

3D/动画相关的资源和一般的活动资源不同，其相对都更重更大。不管是从资源规范还是稳定性考虑。在标准生产链路中这一块需要统一管理，并且预期具有两个关键能力，核心目的在于统一存储方便资源处理，快速下方加速用户载入。
- 存储： 固定且方便接入的路径，自动CDN，离线化能力
- 下发：配合稳定性降级策略，根据机型/系统/场景进行分发

编辑器

设计还原 资源上传 场景搭建 逻辑注入

这一块整体预期其实还不算明晰，但编辑器整体目标是作为设计&研发交付的关键Pipeline，目前感知存在下面5个方面，重要性依次降低：

• 设计还原：支持设计/RD快速在生产环境的渲染引擎下进行还原度检查。

• 场景搭建：支持对3D场景进行快速搭建和编辑操作，这一部分预期会涉及到动画系统复杂度。（对于长尾的降级能力，这里预期还需要降级配置能力，或者在资产导出环节进行配置）

• 逻辑注入：基本通用方式是脚本注入，基于渲染引擎支持的脚本格式，脚本单独开发。但就魔方场景来说，需要针对魔方的上层能力（动作/事件/JSB）进行磨平，但预期涉及主渲染流程的侵入，应该收敛到SDK中。编辑器侧基于SDK的上层接口结合场景搭建交互进行配置式的逻辑注入。

• 资源上传：配合资源管理模块作为资源管理的入口。

• 资产导出：经过场景搭建和逻辑注入后，输出具有相应功能的逻辑功能组件/模块，保证在相同环境下渲染的一致性。

SDK

渲染 管理 功能玩法

SDK建设是整条链路的核心。整体预计分为四个模块：

• 渲染：底层渲染引擎，提供基础的渲染能力和配套渲染控制能力，保证渲染效果
• 控制（controller）：负责链路相关模块的能力串联，性能分析/资源聚合/降级管理等非渲染任务，以及支持外部功能玩法的能力接入，协助支持渲染。
• 功能（avatar/effect/xr）：不管是avatar/effect还是xr本质上是渲染无关，但强依赖渲染能力，属于第三方能力（相机/识别/算法）的功能接入，并且在一定程度上需要侵入渲染主流程。
• 接入：
  • 逻辑注入：针对固定应用场景，配合稳定的上层能力，对底层的主渲染流程进行改造，预期通过配置进行逻辑固化（配置参数的产物是引擎脚本？）。
  • 运行时接入：通过配置生成脚本进行逻辑注入后，生成具有完整逻辑的功能组件，再接通运行时进行动态加载。
    目前这个想法只能算是一个非常初步的想法，还有许多细节需要确认。

性能测试

性能分析 自动验证

目前对这块没有太多的开发经历，但就相关的项目总结来看，涉及互动能力的后期边界case的处理都很比较麻烦，随着方案跟进以及后期效果的演示，不停进行修改和降级处理，导致最终的效果也许和预期有一定差距。因此预期需要提供便捷的性能分析，并对降级策略提供相应分级建议。这里应该主要分为两个方面：

• 性能分析：对固定的互动业务模块提供CPU/GPU等指标的实时/峰值性能消耗分析
• 自动验证：对较大范围的用户生产环境进行自动模拟验证

两块应该是一个整体，仅就性能分析，一般引擎都带有stats，但我们通常仅关注开发环境的Stats表现，生产环境的分析要么很片面在少数高端机型/系统上分析，要么后置到业务测试流程，造成后期工作的积压，甚至可能由于后期测试回归导致降级策略的修改，引发全盘的逻辑。

稳定性

降级策略 环境治理

互动能力整体来说不管是在内外，都还是处于一个推广阶段，做好了容易形成口碑效应，做得不好也容易被砍掉。并且由于实时渲染的性能要求相对较高，低端用户以往通常都比较硬性的直接砍掉，预期用户覆盖率应有较大的空间，良好的降级策略有助于整体的满意度反馈，而云渲染是降级策略的核心。

关于互动的稳定性，主要有两块：针对实时渲染的环境治理，以及基于云渲染的降级策略。其他类似离线化/资源分发相关在资源管理模块进行稳定性监控。

• 环境治理：依赖底层渲染架构对不同环境进行适配和边界处理，并逐步集成深入的渲染能力。
• 降级策略：根据不同用户终端的性能评价和边界状态，进行分布降级（使用云渲染保证视觉体验的一致性）

关于环境治理，分别对web/native环境都在适配，进行黑名单统计，其他关于wasm和webgpu，以及云渲染降级

其他

2D

https://www.yuque.com/baizi/mars/gvsdce