如何打造数字人动画云端渲染的解决方案？

作者：vivo 互联网前端团队 - Su Ning 为解决拟我形象在多场景展示中依赖 3D 渲染导致的性能与接入问题，本文提出将形象预先导出为视频或动图资源。对比三种技术路径后，最终选择 Puppeteer + H5 渲染帧 + FFmpeg 合成视频 的方案，实现了渲染效果一致、服务端批量处理和低接入成本，为拟我形象的规模化应用提供了高效可扩展的技术基础。 1分钟看图掌握核心观点👇 图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言 一、背景 在拟我形象功能的实际应用中，用户完成形象配置后，普遍存在将该形象应用于多场景展示的需求 —— 例如将其设置为社交平台的动态头像、制作专属表情包、适配手机息屏显示动画，或是生成个性化壁纸等。 然而，这里存在一个关键技术矛盾：拟我形象的渲染依赖 3D 运行环境，若在动态头像、息屏显示等多场景中均实时加载完整 3D 渲染环境，会导致设备性能过载（如移动端耗电加剧、网页端卡顿），同时大幅提高第三方场景的接入门槛（需额外适配 3D 渲染逻辑）。 为解决这一矛盾，核心思路是将用户配置的拟我形象预先导出为指定格式的动画资源 —— 即通过技术手段将 3D 形象转换为轻量级的视频或动图文件，后续各场景仅需直接调用已生成的动画资源即可展示，无需依赖 3D 渲染环境。这一方案能显著降低第三方场景的接入成本，同时保证形象展示的一致性与流畅性。 但新的问题随之产生：如何高效、高质量地完成拟我形象的动效合成？需结合各场景的需求，选择最优的动效合成技术路径，成为当前亟待解决的核心问题。 二、方案选择 想要实现动效视频的合成，可选的方案有三种： 2.1 H5生成动画帧，H5/客户端合成视频 拟我形象本身是一个混合开发方案，H5负责整个捏脸流程的实现，在客户端则提供包括资源缓存等基础能力的实现。如果是输出长度较短的单个动画，如动态头像，可以直接通过操作模型执行指定的动画输出视频帧，再将视频帧合成视频。 合成视频可以在H5端使用FFmpeg或者webcodec，但是前者的导出效率只有端侧的1/20，后者存在很严重的兼容性问题，在移动端上甚至有概率出现黑色闪烁。所以还是选择在客户端进行视频的合成与上传的操作。 2.2 blender api合成动画 端侧合成视频实现简单且容易维护，但是存在很强的局限性：帧输出的过程用户无法进行任何操作，且受限于移动端设备种类多样，不同手机中的导出时长也不统一，导出单段动画还好，如果是导出多段动画，相信在动画导出之前用户已经流失掉了。 这种情况下将渲染放到服务端进行就顺理成章了，我们首先想到的是通过脚本调用blender api进行渲染。 blender -b ./avatar.blend -P render.py -o ./result/ 需要将底模以及所有的服装、发型、配饰等部件放到同一个模型里面，调用前置的python脚本还原用户的配置，然后输出对应的视频。 使用blender渲染的优点是输出视频的质量很高，且Eevee渲染器的渲染速度也很快，但是也会带来一系列棘手的问题： 首先是blend文件的维护，由于不同的部件可能是不同的设计师输出的，最终都要整合到同一个文件中，会导致额外的维护成本。相比于上面的问题，更麻烦的是前端使用的不同部位的glb文件是通过管理后台进行维护，不同环境之间的同一部件可能id、命名都不相同，也就意味着在不同环境下需要维护不同的blend文件；使用后台进行模型文件的管理本意是为了增加配置的灵活性，但是使用单个blend文件进行管理又会失去这种维护性。随着模型和动画的不断更新，这个方案的维护成本很难控制。 即使不考虑开发和维护的成本，使用blender渲染的视频和前端渲染的质量和效果也不一致，相比于H5需要考虑设备的兼容性和性能限制，使用blender渲染的动画确实画质更佳、细节更丰富，但是也会让用户产生“货不对版”的错觉。所以统一不同设备的渲染风格也很重要。 2.3 Puppeteer访问H5输出动画帧，FFmpeg合成视频 综合上面两个方案，在大量动画需要渲染的场景下，既要不阻塞用户，又要保证渲染的一致性。 如果不阻塞用户，那么渲染行为就要放在服务端。 如果保证渲染的一致性，那么最好是使用H5渲染。 答案呼之欲出了，那就是使用Puppeteer或Playwright这种网页自动化工具，加载H5页面进行渲染。结合我们的使用场景，最终选择了Puppeteer。 三、实现思路 针对Puppeteer方案，我们设计了如图的实现路径 具体实现拆分为三个部分，分别为用于帧输出的页面开发、Puppeteer流程设计以及视频合成。