【发布时间】：2012-07-17 05:30:38
【问题描述】：
我正在阅读 OpenGL Superbible Fifth Edition，他们通过自己的课程讨论使用堆栈。这一切都很好，但他们提到矩阵堆栈已被弃用。为什么它们被弃用？人们用什么来代替它们？
【问题讨论】：
【发布时间】：2012-07-17 05:30:38
【问题描述】：
原因是政治性的，而非技术性的，并且可以追溯到 2000 年代初期。
OpenGL 3 是第一个愿意打破向后兼容性的版本。设计师希望为熟悉着色器并编写自己的矩阵代码的专家用户、游戏程序员和高端可视化编码人员创建一个 API。目的是 OpenGL 3 API 应该与实际硬件非常匹配。 （即使在 OpenGL 1/2 中，矩阵堆栈通常也是在 CPU 端实现的，而不是 GPU。）
从游戏引擎程序员的角度来看，这更好。嘿，如果你必须每隔几年开发一个新的游戏引擎，那么丢弃旧代码有什么大不了的？
此设计过程的结果是 OpenGL 3/4 核心配置文件。
“新一代”OpenGL 发布后，大学和公司中所有不那么专业的编码人员都意识到他们会被搞砸。这些人（像我一样）教授 3D 图形或编写用于研究或设计的实用程序。我们不需要比普通环境漫反射镜面更高级的照明。我们经常需要将来自不同来源的代码混合在一起，而这只有在每个人都使用完全相同的矩阵、光照和纹理约定（如 OpenGL 2 提供的约定）时才容易。
另外，我听说但无法证实，大型 CAD/CAM 公司也意识到他们也会被搞砸。如果您已经获得了付费（而且薪酬很高：比较 Quadro 与 GeForce 或 FireGL 与 Radeon 的价格）客户，那么从十年的开发中丢弃 200 万行代码并不是一种选择。
因此，NVIDIA 和 ATI 都宣布他们会尽可能长时间地支持旧 API。
这种压力的结果是兼容性配置文件。 OpenGL ARB 现在似乎已经意识到，虽然他们希望每个人都切换到核心配置文件，但它不会发生：阅读 OpenGL 4 中镶嵌着色器的扩展规范，它提到 GL_PATCHES 将与 glBegin 一起使用。
【讨论】：
-
谢谢。软件发布和开发中的政治因素也太糟糕了。
Matrix Stack（以及其他矩阵函数）仅在核心配置文件中被弃用。在兼容性配置文件中，您应该仍然可以使用它们。
在我看来，它已被删除，因为大多数引擎/框架都有自定义数学代码和着色器统一样式，用于将矩阵发送到着色器。
虽然对于简单的程序/教程，使用和搜索其他东西非常不方便。
我建议使用：
- glm (http://glm.g-truc.net/)
- 非常简单的数学库 (vsml)
【讨论】：
为什么他们被弃用了
因为没有人在现实世界的 OpenGL 程序中真正使用过它。以物理模拟为例：无论如何，您会将所有对象放置作为 4×4 矩阵存储在物理系统中。所以你就用那个。可见对象确定和动画系统也是如此。无论如何，所有这些都需要实现矩阵数学，因此在 OpenGL 中使用它是相当多余的，因为大多数时候已经存在的矩阵只是简单地放入 glLoadMatrix。
人们用什么来代替它们？
他们以前用过的东西：他们的动画系统、物理模拟器、场景图等等。
【讨论】：
对我来说，第一个也是主要原因是随着可编程着色器的兴起（在第三版 opengl 之后是强制性的），所有自动传输到着色器的变量，例如 GL_PROJECTION 和 GL_MODELVIEW 都被删除了来自着色器，因此用户必须定义自己的矩阵才能在着色器中使用它。由于您必须使用 Uniform 函数手动发送矩阵，因此您不再需要固定变量。
【讨论】：