很多智慧园区、智慧工厂数字孪生或虚拟仿真模型，使用的是Untiy引擎实现开发工作。在一般情况下，如果仅仅是展示用的大屏，项目上基本就直接通过配置高性能的GPU主机,HDMI线连接大屏后，直接在中控室等特定区域展示。
如果Unity模型需要在网页中使用，很多时候优先想到的时候webgl方式实现网页推流使用，但在实际中这个方案并不是一定可行的。下面和点量云流晓芹一起看下这两种情况，你是否也遇到了呢？
1：Unity开发数字孪生模型越做越大，使用人数多，网页使用效果差怎么办？
背景：大型智慧园区数字孪生项目，一期已经交付，使用的是C/S架构方案，在展厅配置了GPU主机，但是交付后发现除了原来的展厅展示接待需求外，日常工作中还可能遇到，需要在中控室以外的地方使用。另外unity模型在后续要接入更多的数据，把模型提供个更多的部门和人员使用。
遇到的问题：Unity模型开发团队基于经验，计划使用webgl推流实现网页交互，但在实际中发现：①模型的数据量很多模型加载的时间非常长②很多人员的电脑并不具备独立显卡，打开Unity模型时非常卡顿，严重影响使用体验 。
2：unity模型采用C/S架构交付，但后续查看不方便，很多用户没有独立显卡，如何实现网页访问？
Unity智慧园区数字孪生模型，也是用的C/S架构方案交付。但后续对外宣传的时候，需要能直接网页访问。使用了webgl方式推流后，很多用户的电脑没有1050的独立显卡，推流后的效果非常差，模糊、卡顿问题严重基本无法使用。
实时云渲染推流是如何解决以上场景中的问题呢？
以上都是非常典型的Unity 数字孪生或虚拟仿真场景下，想要实现网页使用时面临的问题。总结来说是以下普遍会遇到的问题：
①：Unity模型大，打开需要下载到本地的数据多，加载慢
②：用户没有独立显卡，或者显卡性能不足，打开webgl云推流的模型，使用非常卡，用户体验差；
③：webgl在不同电脑上的效果有差别，无法实现多用户效果的统一，兼容性弱
总结来说webgl方式的云推流方案，虽然一部分渲染工作是在服务器中完成，但对于用户本地电脑的算力还是有基础的要求，比如独立的1050或者1060显卡，这是一种B/S和C/S结合的渲染方式。而用户本地电脑一般很少会特意配置独立显卡，尤其是面向的用户比较多时，每个用户的电脑情况有很大不同，因此webgl推流的兼容性相对较弱。
实时渲染系统，是一种纯B/S的技术架构，Unity的模型部署在GPU服务器上，点量云流将模型在服务器上的运行过程直接录屏编码后，传给推流网页前端。用户在前端浏览器中直接打开解码播放视频流，该过程对unity模型是无侵入式的，只是将原本需要本地支持的算力，全部放在了云端GPU服务器中。但这种方案无法节省unity模型运行本身需要的GPU算力。
现在我们回到webgl推流比较常见的3个问题：
①：Unity模型大，打开需要下载到本地的数据多，加载慢
实时云渲染方案中，无需本地下载模型任何相关数据，主要用户设备能播放1080P的视频，即可把推流后的视频流进行解码播放，绝大部分用户都可以实现。Unity模型运行在服务器端，而服务器上配置了高性能的GPU等算力，完全可以满足用户的使用，如果是多用户使用，可以考虑错峰使用提升硬件的使用率。一台服务器配置多张显卡，便于运维管理。
②：用户没有独立显卡，或者显卡性能不足，打开webgl云推流的模型，使用非常卡，用户体验差；
实时云渲染推流对于用户的设备基本没要求，即开即用，因为用户播放的视频流，模型的运行和本地用户的设备无关，都是在服务器上。除非对于前端的画面质量有特殊要求的，比如2K、4K这种需要的网络带宽要高一些。
③：webgl在不同电脑上的效果有差别，无法实现多用户效果的统一，兼容性弱
实时渲染系统的前端推流页面，兼容了用户常见的浏览器，Chrome、Safari浏览器、360极速浏览器（chrome模式）、搜狗浏览器（chrome模式）、QQ浏览器、微信内置浏览器和微信小程序等。兼容性更高，让所有用户看到的效果基本一样。总的来说实时云渲染的方案，对于unity开发的数字孪生和虚拟仿真模型推流，可以解决使用WEBGL方案遇到的的问题。而且用户现有的设备可以继续利旧使用，用户也无需多余的学习成本，保留原来的使用习惯。
当然对于很多场景下，实际使用的用户数是对于并发数的，这种情况下为保证有特殊需求的用户使用的及时性，支持账号密码方式。对于资源不足时，如何实现给更多用户实时渲染，也有多种方式，比如旁观，即随机分配一个或特定实时渲染用户的操作画面，满足不同场景下更多用户使用的需求。
