背景
酷家乐的UE中台项目，期望打造统一的酷家乐数据到UE（Unreal Engine，即虚幻引擎）的数据中台，已实现将酷家乐场景转换为UE场景，其中一个重要能力就是将场景内材质数据(vrscene)转换为UE材质格式。通过转换为UE材质后，该材质数据可以被UE引擎识别，用于具体的UE场景中。
由于项目前期UE材质转换算法存在大量效果问题，UE4中台将渲染效果的优化调整为项目当前阶段的核心目标。但另一方面项目前期的UE材质效果评估链路很长。从调整算法后部署材质服务，到确认渲染效果并输出报告，整个操作链路耗时可能长达半小时以上，非常影响算法同学工作效率。
架构设计
初版架构
为了解决UE材质效果验证的低效问题，我们在与相关人员对齐需求概要后，设计出了材质回归平台第一版的架构，涉及的相关服务方包括：
- 渲染回归平台：负责材质渲染测试数据、回归任务状态的管理
- 材质中台：酷家乐的材质处理中台，处理UE材质转换业务（UE材质转换算法就搭载于该服务中）
- 离线计算中台：酷家乐的离线计算业务中台，负责离线计算任务的调度工作
- 离线计算集群：由离线计算中台管理的服务器集群，负责执行定制化的离线计算任务，如图片渲染任务
材质回归平台整体架构设计：
- 回归平台触发材质中台批量材质UE格式转换
- 材质中台通知回归平台UE材质可用
- 回归平台携带UE材质信息，向云计算平台提交一个UE材质渲染任务
- 云计算中台将调度其下的计算集群，创建定制的windows容器下载指定UE材质并执行渲染，然后上传渲染图
- 回归平台收到UE材质的渲染图，通过PSNR和SSIM算法，对比材质转换前后渲染图的差异，得出差异值；同时通过像素差异对比，输出图片差异可视化图像
方案调整
这套方案依赖的docker镜像是一个定制化的windows镜像，预期将包含UE渲染工具和一个渲染图上传工具。然而在前期容器构建调试过程中，我们遇到容器无法识别GPU硬件问题。
而UE渲染工具对GPU设备有强依赖。在一段时间探索确认win容器方案当下不可行之后，我们调整了系统架构设计。新架构的业务流程中，发生较大调整的是原先的云计算中台部分被替换为一台搭载GPU的真实windows物理机，调整架构之后整体的材质回归任务流程如下：
需求迭代
由于UE4中台项目工期非常紧迫，在材质回归平台的早期调试阶段，UE业务方就积极参与试用并提出了很多新需求.
材质转换本地化
回归平台加快了材质回归验收速度，UE算法工程师对转换算法迭代速度加快，这时他们迫切希望能将材质转换中台相关能力本地化部署，方便工程师直接修改算法并部署回归。由此我们对平台需求做出调整并开发新功能，落地了材质转换本地化需求：
- 本地物理机部署材质转换服务
- 回归服务支持发起本地的材质转换流程
- 回归服务负责管理所有本地磁盘的材质缓存
稳定性需求
回归平台使用过程中频繁出现批量材质任务失败，经定位确认主要是以下两种情况导致：
- UE材质转换服务本身存在概率失败（算法问题或网络抖动）
- UE材质渲染图工具渲染失败
- 网络抖动导致的回归任务运行失败
基于业务方的强烈需求，我们通过以下两个方向对平台后端逻辑进行了开发调整，并大幅提升了材质回归流程的稳定性。
UE材质转换任务检测
通过对比UE转换任务与材质渲染任务差异，判断是否出现了上述1类型的异常问题，并适时拉起本地材质转换服务再次运行UE转换逻辑。
渲染线程检测
回归任务状态管理逻辑调整，检测物理机上渲染中的任务数量与数据库中待处理渲染记录后，适时重启渲染任务，防止上述2、3类型的异常问题
其他需求
上面提到的两个需求之外，还有许多其他新增需求点：渲染多并发、动态渲染配置、材质转化提速、本地任务排队、独立基线等等，这里不再赘述了。
项目成果
材质回归平台实现了丰富的UE渲染回归功能选择，包括：
- 选择回归物理节点
- 指定材质所在环境
- 数据转换类型分支
- 自定义材质版本和引擎版本
UE回归任务结果数据展示：直观的基线对比与diff图，给出了通用的图像对比指标SSIM/PSNR，并且通过tag展示UE任务基本信息
截止12月12日已支持6批次测试集总计9000+的UE材质回归，发掘材质效果基础问题30+，回归效率相比原流程提升90%以上
