GLM：：正交+ GLM_COORDINATE_SYSTEM =怪异？

Question

虽然我是新的opengl，并寻求帮助，我认为需要一些澄清Z轴，深度测试和GLM:正交。一到两周以来，人们一直在胡思乱想，一切从一开始就被“颠倒”了。

所以我用：

• glDepthFunc(GL_LESS);
• glDepthRange(0.0f, 1.0f);
• glm::ortho(0.0f, 800, 0.0f, 800), 0.0f, 1.0f);
• Z-轴是Y/800(高度)，Y= 20的物体在Y= 10后面。

Okej，所以一切都应该加起来，小Z在前面，大在后面，但是没有。一切都是相反的。

根据这个thread和glDepthFunc/glClearDepth的默认值，当MVP提供给着色器时，一切都应该在左手坐标中。

因此，当我阅读链接线程时，我发现glm：：东正应该将右坐标(因为这是每个人在示例中都使用的)转换为左手坐标。听起来很棒，那为什么不起作用呢？

当你查看GLM的图书馆时，你会发现glm：：东正，glm：：正交glm和glm：：正交the，这听起来非常令人心碎。如果我使用glm：：正交it，所有的东西加起来都很完美，因为它把我所有的坐标都转换成左手。那么为什么glm：：骨科不为我做这件事？

在编译GLM库时，通常会有这样的设置。当调用glm：：GLM_COORDINATE_SYSTEM时，系统是否会将glm：：正交as或glm：：正交as作为缺省值，则由GLM_COORDINATE_SYSTEM控制。令我惊讶的是，glm：：正交glm并不是默认的。

如果你查看GLM的源代码，你会发现这些行，

#define GLM_LEFT_HANDED                         0x00000001      // For DirectX, Metal, Vulkan
#define GLM_RIGHT_HANDED                        0x00000002      // For OpenGL, default in GLM

#ifdef GLM_FORCE_LEFT_HANDED
#       define GLM_COORDINATE_SYSTEM GLM_LEFT_HANDED
#else
#       define GLM_COORDINATE_SYSTEM GLM_RIGHT_HANDED
#endif

OpenGL是右撇子，不需要将矫形转换为左手？

所以我的问题是，

• 为什么GLM认为OpenGL是右撇子？
• 是否有OpenGL在处理着色器时会以MVP作为右手的情况？

如果这没有任何意义，请纠正我。我也很困惑:)

Answer 1

我认为你的主要困惑与这个问题有关：

为什么GLM认为OpenGL是右撇子？

OpenGL既不是右手，也不是左撇子.OpenGL只是一个呈现API，而不是一个坐标系统。

在一个典型的呈现管道中，您确实有许多不同的坐标系统，例如：

• 弹出空间/模型空间
• 世界空间
• 眼睛空间/照相机空间/视野空间
• 剪辑空间
• 归一化设备坐标
• 窗边沿

这些坐标系中的每一个都可以有自己的约定，包括自己的惯用。

带有固定函数管道和集成矩阵堆栈的遗留OpenGL考虑了一些协调约定(但它也没有完全强制您使用这些约定)。

因此，经典的OpenGL约定是：

正规化设备空间/窗口空间左手，x指向右边，y向上，z指向屏幕，眼睛空间用x向右，y向上，摄像机看着-z方向。对象和世界空间通常也只是右手(因此视图转换只是旋转+平移，而不是镜像)。

手感的翻转是在投影矩阵中完成的。没有其他传统GL的惯例是，近景和远剪辑平面的位置总是定义为指向观看方向的距离，因此glOrtho(..., 2,5)实际上设置了一个转换，它将z_eye=-2映射到z_ndc=-1，z_eye=-5映射到z_ndc=1。

如果您看一下我jst所写的映射，它应该可以解释这个奇怪之处：

Okej，所以一切都应该加起来，小Z在前面，大在后面，但是没有。一切都是相反的。

正如你所看到的，“小”z (-5)在后面，“大”z (-2)在前面，就像它应该在一个右手坐标系中一样。

当您没有设置GLM_FORCE_LEFT_HANDED时，glm使用与传统GL相同的约定。它将通过在函数矩阵中翻转z来建立一个右手视图空间(并假设所有后面的空格、NDC和窗口空间都配置为左撇子)。

如果您设置了GLM_FORCE_LEFT_HANDED，它将不会沿z引入镜像，但它仍然将near和far视为查看方向的距离，即现在的+z。这将导致建立一个左手视图空间(只要NDC和窗口空间也设置为左撇子)。

是否有OpenGL在处理着色器时会以MVP作为右手的情况？

这些都只是惯例。YOu必须以一种或另一种方式来决定他们，而且没有人比其他人更好。只有当您有不同的部件或部件使用不同的约定时，THis的内容才会变得有趣(而且很烦人)，在这里您必须非常小心地在正确的位置正确地转换数据。