OpenGL实时渲染传输答案

【问题标题】：OpenGL render transmission in real timeOpenGL实时渲染传输
【发布时间】：2010-08-19 14:47:59
【问题描述】：

我正在尝试用 C++ 开发一个用于远程 OpenGL 渲染的工具。基本思路是：

我知道如果我还没有成品，我不应该开始担心优化，但我很确定这会很慢，瓶颈可能是单帧传输通过网络，即使这些计算机连接在同一个 LAN 中。

我正在考虑使用某种视频流媒体库。这样，将使用适当的压缩算法传输帧，从而加快处理速度。

我在这方面走对了吗？在这里使用视频流库是否正确？如果你这么认为，什么是这个任务的好库（在 C 或 C++ 中，最好是 C++）？

感谢您的帮助！

【问题讨论】：

与现有工具（X11、ssh -X、VNC、VirtualGL）有什么区别？
这实际上是一个学习的教育项目，所以我不会使用它们。没有用过这些，所以我不知道具体的区别。但是感谢您提及这些内容，我们会研究它们以获取见解。
听起来像OnLive等人的一半。可能值得研究有关这些的文章。
实际上，这正是 OpenGL（及其前身 IrisGL）在 SGI 工作站上“过去”的工作方式。
不完全。使用联网的 GL（GLX；它是 X windows 的一部分，并且在 Linux 世界中仍然存在并且运行良好！）应用程序的 OpenGL 命令通过网络发送到远程显示器并在那里渲染。当所有场景内容都存储在“显示列表”中并且只需要通过网络发送一次时，这非常有效。

【解决方案1】：

你有两个解决方案。

解决方案 1

-> 复杂，尤其是在处理缓冲区和纹理时；真正的 openGL 代码是在本地执行的，这可能不是我们想要的，但这取决于你。更重要的是，它对远程应用程序是透明的（无需修改源代码，无需重建）。几乎没有网络通讯。

解决方案 2：您所描述的，各有利弊。

如果您选择解决方案 2，请暂时不要担心速度。相信我，openGL 将面临足够的挑战。

从同步模式开始：render、fetch、send、render、fetch、send 然后是异步模式：渲染、开始提取、渲染、提取结束、开始发送、渲染等我想这已经够难的了

【讨论】：

【解决方案2】：

根据您需要支持的分辨率和 LAN 的速度，可能会传输未压缩的数据。

24 位 1280x1024 帧需要 30 Mbit，而对于千兆以太网，这意味着理论上每秒 33 帧未压缩。

如果这还不够，自己添加一个简单的 RLE 压缩相当简单。

【讨论】：

【解决方案3】：

想象一下，必须在两台机器上花费 $ 才能为它们提供适当的图形处理能力。如果您将所有与图形相关的任务集中在一台机器上，您可以避免这种情况并简化客户端开发。客户端的工作只是发送/接收/显示数据，服务器可以专注于处理图形（OpenGL）并将数据（作为帧）发送回客户端。

您提到的瓶颈取决于您身边的几件事：图像的大小以及您发送/接收/显示它们所需的帧速率。

这些是我读过的一些有趣的话题，希望它们能对这个主题有所启发：

【讨论】：