渲染云是什么,有什么用处

“渲染云” 是一种基于网络的渲染服务提供方式，让用户以Web界面、全自主的完成各种渲染任务。从后台看，渲染云需要整合大量的异构硬件、渲染软件和插件，并且将多个渲染平台进行协同管理，实现资源的按需分配、按量计费，国产服务器厂商浪潮第一个提出完整的“渲染云”解决方案，也是他行业云战略的在动漫产业领域里的细分应用。
“渲染云”是为了解决动漫渲染行业的问题而应运而生的。一直以来，国内的渲染平台普遍以“一套系统运行多个应用”和“一个平台多用户共享”的公用渲染制作平台为主，平台软、硬件乃至插件冲突频发，异构现象极为严重，而渲染平台管理和运营也始终停留在以人工为主的原始 *** 作时代，除了渲染可以自动化以外，其余全部依托于人力。同时，从国内动漫资源分配来看，还处于“东强西弱”、“南北分配不均”的资源失衡局面，在经济较发达地区，大部分的动漫渲染平台闲置率居高不下，而在经济欠发达地区，硬件设备和教育资源又极度欠缺，限制了当地文化产业的发展。
渲染云解决方案一举解决了动漫渲染行业的这些问题，它针对用户提供基于Web化的全程服务，实现不同渲染集群、甚至跨Internet不同数据中心之间的渲染任务的均衡分配和管理，提高渲染资源利用效率及投资回报率；终端客户只需要通过Web就可以享受到任务提交、任务进度查看和收费情况等全程服务，使繁琐的动漫渲染演变成为纯基于web的透明的傻瓜化的 *** 作，也让客户能够将精力解放出来，专注于自身制作业务，促进了渲染行业的分工，促进了动漫行业从体制、分工模式上相欧美靠拢。

随着技术的发展和行业的细分，新名词层出不穷，对于不太熟悉的行业或者技术遇到新名词不懂很正常，点量云小芹发现在云渲染中，很多人对于实时渲染还有很多疑问，而疑问比较多的是“什么是实时渲染”，关于这个问题其实做过很多说明，简单来说就是将以前必须安装在本地电脑的程序放在服务器上，用户通过普通电脑、手机、平板、VR眼镜等设备可以直接使用服务器上的程序，有点类似现在比较流行的云桌面，但延迟比云桌面更低而且能支持的软件类型更多，包括智慧城市数字孪生行业中常用的UE4、U3D，建筑行业的3Dmax、revit、bently、CAD等等。服务器将每一帧数据渲染成一幅画面，然后重新编码通过网络传输，呈现在终端屏幕上，而每一帧的数据，都在不断变化，所以每一帧的画面呈现出来，也在不停地动，因此在终端上就是以视频流的方式呈现出来的。

对于用户来说这种使用和以往的计算机使用习惯没有太大的差别，只需要浏览器打开网址即可，极大的降低了使用的门槛。但从技术角度来说却要复杂的多了。毕竟要考虑整个过程各个环节的优化，首先就是要保证程序能正常的运行，那么问题来了，实时渲染是吃CPU还是显卡呢？

实时渲染是吃显卡的，但这个不是实时渲染程序对显卡有要求，而是需要实时渲染的数字孪生程序等需要流化的内容，本身运行需要显卡的支持才能正常运行。这个其实是和程序本身以及该技术方案的路线有关，在本地部署的方案中运行程序其实也需要高性能的显卡，只不过显卡是安装在本地电脑上的。现在将程序放在服务器端，因此服务器上如果让程序正常运行也需要同样的显卡配置。但使用实时渲染的方式，比用本地有好处，首先不仅仅是电脑、手机、平板等其他设备也可以，而且数据是存在服务器上的更安全也方便运维人员后期维护。在就是对于显卡能力强的，还可以实现一块显卡支持多人同时使用，提供使用效率。而且服务器的计算能力一般来说比电脑要好，这也是为什么实时渲染会更快的原因。

实时云渲染示意图

实时渲染指的是根据图形学算法将三维数据绘制到二维位图之中，并将这些位图实时显示。它的本质就是对图像数据的实时计算和输出，要求在短时间内渲染出一张，并显示出来，同时渲染并显示下一张。这种技术仅仅依靠CPU是没办法完成的，还需要依靠显卡实现。那么CPU就不重要了吗，当然不是。CPU也是很重要的制约因素，因为只有它正常运转了加上显卡的图形计算能力，才能跑通整个过程。所以虽然实时渲染吃显卡，但是CPU也很重要，二者相辅相成。

那么云流化软件系统是如何使用的呢？使用是否麻烦呢？要想解决这些疑问，我们首先要明确下什么是云流化技术？其实简单来说有点像远程桌面，但是云流化技术原理和远程桌面有所区别，可以支持大型、重型各类三维程序的直接云端服务器中使用。对用户来说无需花费学习成本，和以前打开网页或者APP的 *** 作完全一样，简单方便。

一、使用步骤

1、将已经做好的水利数字孪生模型比如UE活着unity模型安装在服务器中；

2、在服务器中安装云流化软件系统

3、将要流化的水利孪生模型存储地址添加到点量云流化程序中，形成用户可直接访问的url链接地址。

点量实时云渲染系统使用流程

从以上来看，云流化程序使用非常简单，让各方无需关注内在如何流化，直接通过云流化程序完成借助云端算力运行程序。

页面渲染都是浏览器的工作。
大致分为以下几步：
加载：根据请求的URL进行域名解析，向服务器发起请求，接收文件（HTML、JS、CSS、图象等）。
解析：对加载到的资源（HTML、JS、CSS等）进行语法解析，建议相应的内部数据结构（比如HTML的DOM树，JS的（对象）属性表，CSS的样式规则等等）
渲染：构建渲染树，对各个元素进行位置计算、样式计算等等，然后根据渲染树对页面进行渲染（可以理解为“画”元素）
这几个过程不是完全孤立的，会有交叉，比如HTML加载后就会进行解析，然后拉取HTML中指定的CSS、JS等。

就是多台服务器（最多10台）同时渲染一张。目前最高可达200核400线程，使用分布式渲染，给的都是高配服务器，能为用户节约大量的渲染时间，会收取一定的服务费，一般适合着急用图的时候用。

仍是SPA

需要用到 react-router-config 这个库，它可以根据 route 匹配到对应的组件，拿到当前route对应的组件是实现路由同步的关键，再通过组件的静态API方法获取接口数据

主要是在服务端通过组件的静态API方法获取接口数据后创建store，再通过 window store = store 传递给前端

主要是要将前端的 js 文件附加在服务端渲染的模板 html 文件中

服务端渲染的应用场景：一般只是对重要的页面，如首页才会做，可以提高首屏加载速度，利于SEO。其他页面实际上仍是CSR

预渲染不像服务器渲染那样即时编译 HTML，它只在构建时为了特定的路由生成特定的几个静态页面，等于我们可以通过 Webpack 插件将一些特定页面组件 build 时就编译为 html 文件，直接以静态资源的形式输出给搜索引擎。

1、SPA变为MPA
2、必须使用 History 路由，而不能使用 Hash 路由，所以对于没有做预渲染的页面往往需要服务器配置路由，如nginx 配置如下：

3、对于动态路由，如 /detail/:id ，是不支持的，不过可以换成 query 路由，如 /detailid=
4、应用场景比较有限，能想到的就是骨架屏应用，比如首页，为了速度，我们会用一些骨架屏组件，如果不做预渲染，则骨架屏组件会等整个js文件加载完毕才开始渲染，体验不好。如果做了预渲染，则当html文件加载完毕时就会开始渲染了

---