为什么拥有一个单独的投影矩阵却又将模型和视图矩阵结合起来会带来什么好处呢? [英] Why would it be beneficial to have a separate projection matrix, yet combine model and view matrix?

问题描述

学习3D编程时，系统会告诉您最简单的3种转换矩阵:

1. 模型矩阵.该矩阵对于每个模型都是单独的，并且可以根据需要旋转和缩放对象，最后将其移动到3D世界中的最终位置. 模型矩阵将模型坐标转换为世界坐标".

2. 视图矩阵.对于大量对象(如果不是全部对象)，此矩阵通常是相同的，并且它将根据当前相机位置"旋转和移动所有对象.如果您要成像3D场景是由照相机拍摄的，并且在屏幕上呈现的是该照相机捕获的图像，则照相机的位置及其观看方向将定义场景的哪些部分可见以及对象如何显示出现在拍摄的图像上.渲染单个帧时更改视图矩阵的理由很少，但实际上确实存在(例如，通过两次渲染场景并在两者之间更改视图矩阵，您可以在场景中创建一个非常简单但令人印象深刻的镜子) .通常，视图矩阵在绘制的两个帧之间仅更改一次. 视图矩阵将世界坐标转换为眼睛坐标".

3. 投影矩阵.投影矩阵决定如何将这些3D坐标映射到2D坐标，例如是否有透视图(对象离观察者越远，对象变小)或没有(正交投影).投影矩阵几乎不会改变.如果要渲染到窗口中并且窗口大小已更改，或者正在渲染全屏并且分辨率已更改，则可能必须更改，但前提是新的窗口大小/屏幕分辨率的显示纵横比与以前不同.您可能想要更改此矩阵，但有一些疯狂的效果，但在大多数情况下，它对于程序的整个生命周期都是相当恒定的. 投影矩阵将眼睛坐标转换为屏幕坐标".

这对我来说很有意义.当然，总是可以将所有三个矩阵组合为一个矩阵，因为先将向量乘以矩阵A然后再乘以矩阵B与将向量乘以矩阵C相同，其中C = B * A. /p>

现在，如果您查看经典的OpenGL(OpenGL 1.x/2.x)，则OpenGL知道投影矩阵.但是OpenGL不提供模型或视图矩阵，它仅提供组合的模型-视图矩阵. 为什么?此设计迫使您永久保存和恢复视图矩阵"，因为对其应用的模型转换会破坏"该视图矩阵.为什么没有三个单独的矩阵?

如果您查看的是新的OpenGL版本(OpenGL 3.x/4.x)，而不使用经典的渲染管道，而是使用着色器(GLSL)自定义所有内容，那么将不再有可用的矩阵，您必须定义自己的矩阵.仍然大多数人保留投影矩阵和模型视图矩阵的旧概念. 为什么要这么做?为什么不使用三个矩阵，这意味着您不必永久保存和恢复模型视图矩阵，也不必使用单个组合的模型视图投影(MVP). )矩阵，这样可以在顶点着色器中为任何单个顶点渲染节省矩阵乘法(毕竟，这种乘法也不是免费的).

因此总结一下我的问题:与具有三个单独的矩阵或单个MVP矩阵相比，将模型视图矩阵与单独的投影矩阵组合在一起的优点是什么?

解决方案

实用地看它.首先，发送的矩阵越少，与位置/法线/等相乘的矩阵就越少.因此，顶点着色器更快.

第1点:矩阵越少越好.

但是，您可能需要做某些事情.除非您要进行2D渲染或一些简单的3D演示应用程序，否则您将需要进行照明.通常，这意味着您需要将位置和法线转换为世界或摄影机(视图)空间，然后对它们进行一些照明操作(在顶点着色器或片段着色器中).

如果仅从模型空间转到投影空间，则无法执行此操作.您不能在投影后的空间中进行照明，因为该空间是非线性的.数学变得更加复杂.

所以，要点2:在模型和投影之间至少需要一个停顿.

因此，我们至少需要2个矩阵.为什么要使用相机而非相机?因为在着色器中的世界空间中工作很糟糕.您可能会遇到与原点相距较远的翻译相关的数值精度问题.而如果您在摄影机空间中工作，则不会遇到这些问题，因为没有什么东西离摄影机太远(如果有的话，它应该应该在较深的深度平面之外).

因此:我们将摄影机空间用作照明的中间空间.

When you are learning 3D programming, you are taught that it's easiest think in terms of 3 transformation matrices:

1. The Model Matrix. This matrix is individual to every single model and it rotates and scales the object as desired and finally moves it to its final position within your 3D world. "The Model Matrix transforms model coordinates to world coordinates".

2. The View Matrix. This matrix is usually the same for a large number of objects (if not for all of them) and it rotates and moves all objects according to the current "camera position". If you imaging that the 3D scene is filmed by a camera and what is rendered on the screen are the images that were captured by this camera, the location of the camera and its viewing direction define which parts of the scene are visible and how the objects appear on the captured image. There are little reasons for changing the view matrix while rendering a single frame, but those do in fact exists (e.g. by rendering the scene twice and changing the view matrix in between, you can create a very simple, yet impressive mirror within your scene). Usually the view matrix changes only once between two frames being drawn. "The View Matrix transforms world coordinates to eye coordinates".

3. The Projection Matrix. The projection matrix decides how those 3D coordinates are mapped to 2D coordinates, e.g. if there is a perspective applied to them (objects get smaller the farther they are away from the viewer) or not (orthogonal projection). The projection matrix hardly ever changes at all. It may have to change if you are rendering into a window and the window size has changed or if you are rendering full screen and the resolution has changed, however only if the new window size/screen resolution has a different display aspect ratio than before. There are some crazy effects for that you may want to change this matrix but in most cases its pretty much constant for the whole live of your program. "The Projection Matrix transforms eye coordinates to screen coordinates".

This makes all a lot of sense to me. Of course one could always combine all three matrices into a single one, since multiplying a vector first by matrix A and then by matrix B is the same as multiplying the vector by matrix C, where C = B * A.

Now if you look at the classical OpenGL (OpenGL 1.x/2.x), OpenGL knows a projection matrix. Yet OpenGL does not offer a model or a view matrix, it only offers a combined model-view matrix. Why? This design forces you to permanently save and restore the "view matrix" since it will get "destroyed" by model transformations applied to it. Why aren't there three separate matrices?

If you look at the new OpenGL versions (OpenGL 3.x/4.x) and you don't use the classical render pipeline but customize everything with shaders (GLSL), there are no matrices available any longer at all, you have to define your own matrices. Still most people keep the old concept of a projection matrix and a model-view matrix. Why would you do that? Why not using either three matrices, which means you don't have to permanently save and restore the model-view matrix or you use a single combined model-view-projection (MVP) matrix, which saves you a matrix multiplication in your vertex shader for ever single vertex rendered (after all such a multiplication doesn't come for free either).

So to summarize my question: Which advantage has a combined model-view matrix together with a separate projection matrix over having three separate matrices or a single MVP matrix?

解决方案

Look at it practically. First, the fewer matrices you send, the fewer matrices you have to multiply with positions/normals/etc. And therefore, the faster your vertex shaders.

So point 1: fewer matrices is better.

However, there are certain things you probably need to do. Unless you're doing 2D rendering or some simple 3D demo-applications, you are going to need to do lighting. This typically means that you're going to need to transform positions and normals into either world or camera (view) space, then do some lighting operations on them (either in the vertex shader or the fragment shader).

You can't do that if you only go from model space to projection space. You cannot do lighting in post-projection space, because that space is non-linear. The math becomes much more complicated.

So, point 2: You need at least one stop between model and projection.

So we need at least 2 matrices. Why model-to-camera rather than model-to-world? Because working in world space in shaders is a bad idea. You can encounter numerical precision problems related to translations that are distant from the origin. Whereas, if you worked in camera space, you wouldn't encounter those problems, because nothing is too far from the camera (and if it is, it should probably be outside the far depth plane).

Therefore: we use camera space as the intermediate space for lighting.

这篇关于为什么拥有一个单独的投影矩阵却又将模型和视图矩阵结合起来会带来什么好处呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！