四维智能分布式远程实时渲染方案

李 杨 邵先杰 李琳娜

(青岛已臻化境影视科技有限公司,山东青岛 266000)

1 引言

影视行业、汽车行业、建筑行业、游戏行业以及最近兴起的“元宇宙”,对三维模型、大型场景、特效、灯光材质等渲染的需求量不断增大。在解决渲染、着色大型场景及高精度模型时,用户一般采用基于本地单机的解决方案来完成场景的加载及渲染流程,此传统渲染、着色、打包流程通常对本地的硬件配置需求较高,不仅增加开发成本,无法保证渲染速度,而且项目(建模或其他基于三维引擎的源文件)制作阶段无法精准回溯到对应版本,从而给开发中的项目带来不可逆的修改/损坏。在此背景下,我们结合工作实践,提出四维智能分布式远程实时渲染(Four Dimensional Intelligent Distributed Rendering)的解决方案。

四维智能分布式远程实时渲染系统为多用户提供在线的静态渲染、实时渲染、场景加载、编译、着色等服务。服务端采用集群模块化任务(Control Module Types,CMT)工作方式,基于智能分布式调度服务(Intelligent Distributed Scheduling,IDS)为用户提供高效的云端渲染和加载解决方案。

与传统意义上的实时渲染概念不同,本文提出的四维智能分布式远程实时渲染是用户端通过传输插件与服务端建立实时的数据传输通道,用户数据上载到服务端,通过集群模块化任务(CMT)及智能分布式调度服务(IDS)分发至执行器(执行渲染或加载任务),任务执行完毕后统一打包输入到用户端或通过Web远程显示渲染任务的输出结果。此系统为用户生成以每次上载节点为时间轴的“第四维度”档案,用户可以此回档到以前的任意节点或建立新的分支。本系统核心思想为:用户以链接云端的方式,依托云端服务器集群,获得高效、实时稳定及安全的开发体验。因其大部分计算都集成在云端,从而大大降低对本地硬件的配置要求,降低了开发成本。

2 四维智能分布式远程实时渲染模型

为应对用户开发中不同的请求场景(静态/实时渲染、着色、打包等),服务端配置了多条业务流程以满足客户不同的开发场景,用户端可根据需要安装如3DMAX、MAYA或UE、Unity等软件的内置插件,通过传输插件与服务端建立连接的方式进行云端渲染操作。

四维智能分布式远程实时渲染总体功能模块如下:

图1 四维智能分布式远程实时渲染总体功能模块

四维智能分布式远程实时渲染使用传输插件与云端建立通信以动态响应本地操作,并将本次的相应操作以“时间”为节点进行云端存储。本系统的实时渲染部分底层执行器为主要基于Unreal Engine 4的动态渲染功能或基于普通帧图(效果图)的渲染。功能分为:①基础帧图(效果图)渲染;②动态响应本地操作(Unreal Engine 操作)输出到WEB端的实时渲染;③动态响应本地操作(主流建模软件操作)输出到WEB端的实时渲染(服务端);④辅助加载,用户端通过请求,服务端可将编译、加载、着色或打包后的文件异步输出到用户端。

2.1 维度一:基础静态渲染服务

适用用户群体:需要借助云端进行单一的帧渲染操作的用户。使用本地软件完成整个场景的制作后,打包上载到服务器进行渲染任务,输出物下载到用户本地。

基础静态模型渲染为常规云端渲染方案,存在小部分需求差别。用户使用流程:用户需要在对应的建模软件中内置插件,在插件中,选择点击渲染后,本地文件通过传输插件与服务器建立通信,上载资源。

用户资源上载到云端存储后交由分析服务器进行如下处理:①校验文件完整性;②.检查场景内外部资源文件是否正常引入;③分析场景复杂度(面数、材质、灯光及其他基本参数)及用时,随后生成分析报告数据转交CMT服务处理。

CMT模块化任务/整合服务处理:CMT会将用户任务根据分析报告进行拆分,如用户渲染场景中的某帧,会在分析完成后生成本任务的分析报告,CMT依据分析报告将本任务拆分成多份任务片段转交于调度中心。如图2所示,调度中心派发任务到执行器进行渲染任务,渲染执行完毕后将任务片段发送回CMT进行结果校验与整合操作,后经过存储与传输服务,最终渲染结果下载至用户端。

图2 静态渲染智能调度渲染

图2所示的渲染流程与传统的渲染农场相比:新增分析服务器与模块化任务/整合服务,提高执行器使用率,从而达到加快渲染的效果。

2.2 维度二:动态响应实时加载服务

适用用户群体:需要借助云端进行如UE4前期的着色、后期的打包及其他需要长时加载的任务,用户本地软件与云端建立实时连接,输出物下载到用户本地。

如图3所示,动态响应实时加载模型,适用于用户在使用三维引擎开发阶段,帮助用户以较低的硬件配置顺利完成前期模型加载及后期的打包工作。

图3 动态响应实时加载模型

步骤1:用户使用三维引擎的内置插件(需配合业务开发,此插件包含传输服务)建立与云端的通信,云端会动态响应用户端的操作。

步骤2:插件通过传输服务将需要加载的文件上载到云端存储。

步骤3:分析服务器校验文件完整性与复杂程度,生成分析报告数据转交CMT服务处理。

步骤4:CMT根据“分析报告”,将本次任务细分多个子任务模块(细分数量由“分析报告”参数决定),后统一打包交由智能调度中心分配到具体执行节点机进行处理。

步骤5:执行器将输出结果汇总到CMT,由CMT整合打包后输出到云端存储中。

输出:该方案结果文件返回给用户的方法有两种:①用户一次性下载全部结果文件至本地对应路径下并完成本次动态加载;②使用动态下载机制,云端存储内收到CMT返回的结果后,用户插件端会动态监测用户所在的三维场景区域并实时监测当前的资源文件分块,分批次下载到用户电脑直至完成。“动态响应实时加载”方案一定程度上解决了部分资源浪费的问题。

2.3 维度三:动态响应实时渲染服务

适用用户群体:模式1为用户在本地只有三维建模软件的情况下,需要输出实时渲染画面至Web页面供用户查看或分享;模式2是用户使用三维引擎时需要输出实时渲染画面至Web页面供用户查看或分享。以上两种模式均需在使用软件中与云端建立实时连接。

动态响应实时渲染模型即云端动态渲染服务,提供完整的用户动态在线实时渲染解决方案,当前系统模型共分为两种,主要模式为用户提供不同的应用场景解决方案。

2.3.1 模式1如图4所示,用户无需使用任何三维引擎即可完成基于WEB服务器显示的实时渲染模式。

图4 动态响应实时渲染模型

步骤1:用户使用建模软件的内置插件(需配合业务开发,此插件包含传输服务)建立与云端的通信,云端会动态响应用户端的操作。

步骤2:插件通过传输服务将需要加载的文件上载到云端存储。

步骤3:分析服务器校验文件完整性与复杂程度,生成分析报告数据转交三维引擎转化器。

步骤4:将3D文件通过“三维引擎转化器”转换为三维引擎文件,转交CMT服务处理。

步骤5:CMT根据“分析报告”将本次任务细分为多个子任务模块(细分数量由“分析报告”参数决定),后统一打包交由智能调度中心分配到具体执行节点机进行处理。

步骤6:执行器将输出结果汇总到CMT,由CMT整合打包后输出到云端存储中。

输出:存储文件部署于WEB服务器,可通过网络访问并实时操作(在实时渲染的场景中查看三维元素)。上述步骤会在用户修改本地建模软件的内容后动态执行并显示于WEB端以做到异步实时渲染的效果。

2.3.2 模式2如图5所示,用户使用三维引擎开发时与云端建立连接动态实时渲染模式。

图5 动态响应实时渲染模型

步骤1:用户使用三维引擎的内置插件(需配合业务开发,此插件包含传输服务)建立与云端的通信,云端会动态响应用户端的操作。

步骤2:插件通过传输服务将需要加载的文件上载到云端存储。

步骤3:分析服务器校验文件完整性与复杂程度,生成分析报告数据转交CMT服务处理。

步骤4:CMT根据“分析报告”将本次任务细分为多个子任务模块(细分数量由“分析报告”参数决定),后统一打包交由智能调度中心分配到具体执行节点机进行处理。

输出:存储文件部署于WEB服务器,可通过网络访问并实时操作(在实时渲染的场景中查看三维元素)。上述步骤会在用户修改本地建模软件的内容后动态执行并显示于WEB端以做到异步实时渲染的效果。

2.4 维度四:“时间可视化”项目存储管理服务

如图6所示,本次分布式存储服务器包含“四维项目存储管理”服务,用户每次通过上述模型进行云端通信时,存储服务会记录当前内容并生成以时间为主的节点,本功能可由用户选择开启或关闭。

图6 四维项目存储管理

用户也可以主动将项目提交到云端存储中进行管理,用户上传项目后会在云端存储中开辟一块专用加密区域,本加密区域受对应权限管控,上传者可分配权限至某组/人,作为后续协同开发的限制条件。

模式1:用户可自行上载或下载本用户权限内的项目,包括项目的历史版本。项目上载用户即默认为本项目的权限管理员。

模式2:用户上载项目后,可邀请/分享至其他用户,被邀请的用户可通过获取权限后下载项目中某个节点的项目文件,并可上载生成新项目分支或合并,从而达成多人协同开发的目的。

3 关键技术

3.1 传输技术

使用多客户端对应服务的方式,实现将当前平台数据实时同步到服务端并对此数据进行存储保存,获取服务端数据到web端进行展示,从而有效降低用户本地硬件配置需求和硬件成本。通过插件集成的方式,当用户需要同步场景时将平台数据(包括当前场景环境数据、模型数据、着色数据等信息)下载到服务端。

此研究需要的数据同步要求较高,既要保证可靠稳定的数据传输,也要保证通信速度快的特点,这样才能达到在云平台同步展示实时渲染场景的效果要求。对应此应用场景,当前主要有TCP和UDP两种传输方式,它们的优缺点比较明显。TCP在传输有效数据之前,存在“三次握手”用来创建客户端与服务端之间的连接,并且在传递数据时,存在确认机制、窗口机制、重传机制、拥塞控制机制,在传递数据完成后,还会断开客户端与服务端之间的连接以节约系统资源。正因如此,TCP为了实现网络信息交互与传递的可依赖性,使用了复杂的拥塞控制实用性方法,请求过程繁琐。由于TCP内置的协议堆叠,对其进行改进比较困难。UDP对比TCP没有繁琐的请求机制、确认机制、窗口机制、重传机制、拥塞控制机制,是一个没有状态的通信协议,所以在信息交互与传递时非常快,但带来的后果就是不可靠、不稳定,很容易出现丢失有效数据的现象,造成数据传输的失效。

因此,针对于此问题使用基于UDP的高速传输同时能够保证可靠性的新型协议是有必要的。

3.2 分布式存储

分布式存储是相对于集中式存储而言的。集中式存储相对分布式存储实现起来比较简单,易于维护一致性,在一定的频繁操作中可以为使用者提供较为满意的性能。集中式存储的缺点也较明显:一是如果该服务器失效,整个系统将出现无法正常工作的现象;二是由于集中式存储中有一个节点专门司职元数据管理,所有元数据都存储在该节点的存储设备上。所有客户端对文件的请求前,都要先对该元数据管理器请求元数据,这样就会出现当元数据操作过于频繁时,系统会出现排队堵塞现象,从而成为整个系统的性能瓶颈。分布式存储很好地解决了集中式存储的这两个弊端。

目前常见的分布式存储架构有中间控制节点架构(HDFS)、安全无中心架构——计算模式(Ceph)、安全无中心架构——一致性哈希(Swift)等。

本系统存储采用分布式系统结构,实现多台存储服务器分担存储负荷,位置服务器定位存储信息的高效方式。其表现如下:

(1)支持自动的分级存储有效管理读缓存和写缓存机制。在管理读缓存中,通过将热点区域数据映射到高速存储中实现提升系统响应速度操作,并且在发现热点区域有变化时就将其移出高速存储以保证性能;在管理写缓存中,先将数据写入高速存储,在合适的时间点自动进行同步落盘操作。

(2)松耦合的网络架构机制。高速、低速存储分开部署或任意比例混合存储;在敏捷开发或不可预测的业务环境情况下,可以尽可能发挥分层存储的优势。

(3)概念数据模型及多副本备份机制。在存储数据之前,先将数据进行分片处理,并将分片后的数据按照有效规则保存到集群节点上;为了保证多个数据副本之间的一致性,使用一个副本写入,多个副本读取的方式;为了满足对于可靠性不同的需求,使用镜像、条带、分布式校验等方式;有效地保证了当读取失败时,可以从其余副本读取数据,写入该副本进行恢复,从而保证了副本的总数一定;当数据长时间保持不一致错误时,系统会自动对数据进行重建恢复,为了对业务产生最小的影响,可设定数据恢复的宽带规则。

(4)数据容灾备份机制。为了实现生产系统各版本数据的有效保存,使用了多时间点快照技术;这种方式还支持同时提取多个时间点样本同时恢复,有效保证多个逻辑错误灾难的定位。

(5)弹性扩展机制。为了避免单点过热,将旧数据自动迁移至新节点实现负载均衡;添加新节点后集群系统的整体容量和性能将实现线性扩展,这种方式实现简单,只需将新节点和原有集群连接到同一网络中即可,整个过程不会对业务系统产生不必要的麻烦。

3.3 智能调度

为了将大量运算任务合理分配至执行器执行,需要依赖于智能调度服务的“智能任务派发机制(根据在线用户数量及任务数量等条件分配任务)”。智能调度服务负责向云端节点机分发任务,用于完成渲染、加载等业务需求并通过节点机实际运用情况合理分配当前资源以提升用户的使用体验。

3.3.1 模块

调度中心:负责管理调度信息,根据后台配置设定选择适合当前使用的调度策略,完成对用户任务的分配与监控各执行器的运行状态与数据统计。

执行模块(执行器):用于执行实际的运算任务,如:渲染、加载、打包等。

3.3.2 架构图

调度服务运行着一个节点管理程序,所有系统内运行正常的节点机都会注册在内,并且实时监控节点机的运行状态及“健康”状况。当业务端发来任务时,调度中心会根据当前的用户数量、任务数量及可用节点机数量分配任务。执行器运行结束后会将结果返回至调度中心,调度中心则通知业务端进行后续处理。

图7 智能调度架构图

3.4 虚幻引擎

本文中的实时渲染将基于UE4做重点技术分析。UE4中包括的着色器、半透明物体、动态阴影、材质等几项配置是影响渲染的主要因素,以下为系统重点优化的配置选项:

3.4.1 渲染几何体

首先确认需渲染物体的顺序,渲染时会对每一个材质进行一次draw call操作。然后通过stat RHI可以查看draw call信息。若draw call信息超过10000次会对性能产生严重影响,如考虑用于手机游戏和vr设备端,可控制1500次左右的调用即可。大量顶点的运动,建议将其移动到顶点着色器中实现。

3.4.2 材质

一般情况下,远处的几何体占用的像素较少,因此可以使用相对复杂一点的着色器,近处几何体反之。着色器指令数一般在90-210之间即可,多出此范围可能会影响渲染性能。

3.4.3 反射

UE4中有三种不同的反射系统 。通常将三种反射混合使用,且每出现一次反射就会重新渲染一次屏幕。

(1)反射环境:反射环境是采集多个点处的静态关卡,将其投射到反射中的简单集合提示上。反射会在编辑的过程中实时更新,但在运行时为静态。每个像素在多个几何体贴图之间混合,以获得最终效果输出。较小的Actor将覆盖较大的Actor,因此可根据设计需要增强区域内的反射视差准确度。简单来说,就是可以将装置放置在空间中来提升反射效果。

(2)反射捕捉Actor:反射捕捉Actor是精心放置在关卡各处的Object,它将反向数据馈送到反射环境中。当前有两个反射采集形状:球体和盒体。形状十分重要,因为它控制着场景的哪个部分将被采集到立方体贴图中、反射中关卡被重新投射到什么形状上,以及关卡的哪个部分可以接收来自该立方体贴图的反射(影响区域)。

(3)屏幕空间反射是一种引擎功能,可帮助将Object置于地面之类的平坦表面上。它在默认情况下是激活的,与反射环境的结果相混合,提供更全面的反射感。默认情况下屏幕空间反射在UE4中处于活动状态,但可以根据设置使用控制台命令_r.SSR.Quality 3_或_r.SSR.Quality 0_切换。。

3.4.4 G缓存和光栅化

因为当物体相对主视角越远,它所覆盖的像素越少,所以应该减少物体的面数来减少着色器的运算量。此项在UE5中可能会有所优化。

3.4.5 静态光照系统

静态光照是预计算光照系统,每次有物体改变(形状、参数、位置等待)就需要重新计算,但是性能很好,渲染很快,可以用于全局光照。

3.4.6 动态光照系统

动态光照使用G-buffer来实现实时渲染,可以随时进行各参数修改,但阴影对性能影响很大,不会产生软阴影与产生全局光照。

3.4.7 雾和透明度

UE4中有两种类型的距离雾:大气雾和指数雾,距离雾指雾会随距离而衰减。大气雾性能相对优秀,指数雾则效果相对突出。

4 系统组成服务/搭建

系统总体架构如图8所示。

图8 四维智能分布式远程实时渲染模型

4.1 用户端

用户将服务插件集成于软件(UE4等)中,赋予其权限后可快捷地将本地项目相关文件同步到云端(手动/自动), 在云端完成计算后,根据用户业务实时显示于WEB或下载到本地。

4.2 云端

运算用户端交互数据、提供WEB实时渲染服务及项目分支管理。

4.2.1 WEB服务器

为用户在线实时渲染提供WEB端操作/显示渲染结果以及提供“时间可视化”项目存储管理服务的访问。

4.2.2 传输服务

传输服务作为用户端与云端重要的服务之一,其性能会影响到云端服务响应速度,调用传输服务方式分为软件内置插件调用与WEB端调用。传输技术详情查看3.1。

4.2.3 “时间可视化”项目存储管理服务

项目分支管理系统,模式分为两种:

(1)主动管理:用户可主动将工程项目上载至服务器,服务器保留各个时间段用户上载的不同项目版本,用户借此可达成多地协同开发或回退版本及分支开发测试、快捷在线渲染等。

(2)被动管理:本服务建立在用户软件内集成云端插件为前提,系统自动将项目同步到云端进行管理并自动生成以关键时间为节点的多版本项目,用户可用此功能进行项目恢复、协同开发或快速渲染等。但此功能项目文件将只存储近7天内容。用户可选择关闭“被动管理功能”。

5 总结

随着对实时渲染及模型加载等运算需求的日益增多,以及对硬件配置的要求提高,降低用户的硬件开发成本及相对缩短开发周期显得格外重要。我们基于测试、技术预研对智能分布式调度的四维智能分布式远程实时渲染方面做出研究,以期为行业提供更加高效的云端渲染和资源加载,通过研究和实践四维智能分布式远程实时渲染方法,依托云端服务器集群为用户提供高效、实时稳定及安全的渲染体验。❖