将虚幻引擎内容流送到多个平台
比较 HTML5、WebGL 和像素流送
| 简介
常见的办法是,首先确定目标受众可能使用的性能最低的平台,然后确定受众能够接受的质量级别,最后以此为基准开发内容。然而,这种方法的弊端是会普遍 降低所有最终用户的体验 。
而且在这类部署中,负责为最终用户显示实时内容的设备同时还需下载相关的数据和代码,并将结果渲染到屏幕上。将数据下载到设备中容易产生多种问题,比如为了减小下载文件的尺寸或者加快下载速度,有时不得不 牺牲一些画面质量 。
| 发布内容时面临的挑战
在一些基于 WebGL 或 HTML5 技术的传统或现代解决方案中,显示内容的真实程度和交互体验取决于消费者的设备性能,特别是该设备的硬件性能、显示机制和操作系统。这就意味着如果要让内容尽可能地触及到更多用户,就要以性能最低的设备为基准开发应用程序,并在所有其它平台上共享该应用,或者针对各个平台开发出多个版本的应用程序,以便满足 不同平台 用户的需求。
在创建流送解决方案时,开发人员面临的一大挑战是如何通过 多个通信渠道 交付内容,并且无论最终用户使用哪种设备,都能保证画面的真实感以及交互性,并忠实还原品牌的外观和感受。要实现这一目标,就需要将共享应用程序本身与运行它的高端硬件分离开来,让用户的显示设备只负责显示画面。
用户体验的性能和因素
播放速度 ——内容本身可能需要针对实时性能进行优化。首先,你需要界定这些应用程序的受众可接受的播放速度范围。虽然让用户产生沉浸感的公认标准帧率为 60FPS,但有些应用程序可能只需要 5FPS,而其他应用程序则可能需要 90FPS。
图像质量 ——用户体验到的画面质量和真实程度,通常取决于应用程序端的内容设置(包括实时播放相关因素)、编码质量和硬件的 GPU 性能。画面质量预期以及成本考量会影响商业用例的实现方式,从而确定该设置方案的最终输出效果。
技术因素
用户负载 ——用户数量和应用程序的复杂程度将决定单个托管实例能够发送哪些内容,以及需要何种负载平衡来响应并发用户。一个拥有高真实度和完全交互式体验的车辆配置器,可能需要一万个拥有相同设置的实例。所需服务器的数量取决于首次交互发生时所需的速度,其往往是一项关键因素。
流送带宽 ——如果目标用户使用某个特定平台,