考虑到对 3D 图形渲染的幼稚看法，立体 3D 渲染似乎对开发人员基本上是透明的，并且完全是图形硬件和驱动程序的一个特性。无论 OpenGL 窗口在何处显示场景，它都需要几何、光照、相机和纹理等信息来渲染场景的 2D 图像。
在场景中添加立体 3D 似乎本质上意味着使用两个横向偏移的摄像机，而所有其他场景变量保持不变。唯一的附加信息是使相机相距多远以及使它们的中心光线会聚多远。鉴于此，采用 GL 命令序列并在驱动程序级别交错适当的命令来驱动 3D 渲染似乎是微不足道的。
似乎需要专门编写应用程序才能使用特殊的 3D 硬件架构，这使得实现起来既麻烦又难以实现。我们会期望这成为立体 3D 实现的未来，还是我掩盖了太多重要的细节？
在我的具体情况下，我们使用的是 .net OpenGL 视口控件。我最初希望仅仅拥有启用立体的硬件和驱动程序就足以启用立体 3D。
你的假设是错误的。OpenGL 不会“使用几何体、照明相机和纹理信息来渲染 2D 图像”。OpenGL 使用命令来操作其状态机并使用命令来执行绘图调用。
正如没人在他的评论中提到的那样，核心配置文件甚至根本不关心转换。它现在唯一真正为您提供的是向顶点着色器提供任意数据的方法，以及向任意 3D 立方体提供渲染的方法。无论是否对应于实际视图，GL 不关心，也不应该关心。
请注意，有些人已经注意到驱动程序可以尝试猜测什么是视图，什么不是，这就是 nvidia 驱动程序在进行自动立体渲染时尝试做的事情。这需要一些特定的猜测工作，这相当于对游戏渲染进行实际分析以调整算法，以便驾驶员猜对。因此，它通常是按标题、驱动程序内的更改。一些开发人员已经注意到驱动程序可能会猜错，当这种情况发生时，它开始变得混乱。查看这些问题的第一手资料。
我真的建议您阅读该演示文稿，因为它进一步说明了相机应该指向的位置（两个视图方向是否应该平行等）。
此外，事实证明，对于与视图相关的所有内容，渲染成本基本上是其两倍。一些开发人员（例如，包括Crytek 的家伙，请参阅第 2 部分）发现，在很大程度上，您可以进行一次渲染，并使用额外的数据来伪造图片以生成左眼和右眼图片。这里节省的工作量本身就很有价值，开发人员可以自己做这件事。
不幸的是，立体 3D 渲染比仅添加横向摄像机偏移更复杂。
您可以从原始“单声道”渲染帧和深度缓冲区创建立体 3D。给定场景中（现实世界）深度的范围，每个值的深度缓冲区会告诉您相应像素的距离。给定所需的眼睛分离值，您可以根据距离向左或向右滑动每个像素。但...
您想要两台摄像机最终会聚的平行轴立体（偏移不对称平截头体）还是“前束”立体？如果是后者，您将需要逐个场景调整摄像机角度，以避免“反转”超出会聚点的几何图形。
对于非常靠近观察者的物体，左眼和右眼看到同一物体的完全不同的图像，甚至左眼看到物体的一侧而右眼看到另一侧 - 但单视图会平均这些到前面。如果您想要一个准确的立体 3D 图像，它确实必须从不同的眼睛视点进行渲染。这有关系吗？FPS射击游戏，可能不是。人体手术训练模拟器，你敢打赌。
如果观看者将头向一侧倾斜，则会出现类似的问题，因此一只眼睛比另一只眼睛高。同样，对于游戏来说可能并不重要，对于外科医生来说真的很重要。
哦，你在场景中有抗锯齿或透明度吗？现在你有了一个真正代表不同深度的两个像素值的像素。横向移动一个抗锯齿像素，它可能看起来更糟，因为“下面”的颜色已经改变。侧向移动一个大部分透明的像素，后面的像素会移动得太远。
您如何处理瞄准具十字和类似的 HUD 元素？如果在禁用深度缓冲区的情况下绘制它们，深度缓冲区值可能会使它们在数百米之外。
考虑到所有这些潜在的问题，OpenGL 明智地并没有试图说明应该如何进行立体 3D 渲染。根据我的经验，修改 OpenGL 程序以进行立体渲染比一开始就编写它要省力得多。
Shameless self promotion: this might help http://cs.anu.edu.au/~Hugh.Fisher/3dteach/stereo3d-devel/index.html