接触3D程序设计，难免要认识各种坐标系统，并在各个系统之间进行转换，直接使用程序代码实现公式是个方法，然而3D的世界中经常运用矩阵运算，因此，认识齐次坐标也是必备的，因为，这不单只是数学，与程序代码本身的效率也有很大的关系！

这是左手还是右手？

在3D世界中，最常运用的是直角坐标，然而却有多种不同的表示方式，也就是X、Y、Z轴正方向会有各自不同的表示，软件或链接库可能采用不同系统，这是种困扰，然而木已成舟，开发者只能在运用链接库之前，先分辨它们到底采用哪个系统，粗略来说，直角坐标系统可以分为两种：左手坐标（Left-hand Coordinate）、右手坐标（Right-hand Coordinate）。

对于前者，把左手拿出来，姆指指向若符合X轴正方向，食指符合Y轴正方向，而掌心往上符合Z正方向的话，那么该系统是采用左手坐标，例如，WebGL裁剪空间（Clip Space）就是左手坐标系统；对于后者，就是把右手拿出来，姆指与食指对应X、Y轴后，看看掌心往上是不是符合Z轴正方向，如果是的话，就是采用右手坐标，例如glMatrix、Three.js就属于这类右手坐标系统。如果你一开始设计3D对象时，是采用左手坐标，然而接下来想要套用glMatrix呢？表面上看来，右手坐标似乎只是将Z轴正方向反过来，对glMatrix是如此，然而对其他链接库或软件就不一定了。

例如，OpenSCAD、Blender是右手坐标，然而，它的X、Y是代表2D平面，Z代表高度，也就是说，同为右手坐标系统，还是要注意一下三个轴各自的意义为何；至于3D雕塑软件的部份，似乎偏好左手坐标，例如：Sculptris、SculptGL，不过，它们的z轴正方向是朝上，而不是像WebGL裁剪空间的z轴代表深度。左手坐标或右手坐标的差别，会影响到坐标转换时导证出来的公式结果，如果试图结合两种不同系统的链接库，就必须自行实作转换，不然绘制出来就会是错误的画面。例如，一个右手系统的(x,y,z)要换成左手系统的话，并不是只有(x,y,-z)一种转换方式，(−x,y,z)、(x,−y,z)、(−x,−y,z)、(−x,y,−z)、(x,−y,−z)，也都是转换为左手坐标的可能方式。

这是哪个空间？

刚开始接触WebGL时，至少会接触两个空间：裁剪空间与屏幕空间（Screen Space）。对WebGL来说，屏幕指的就是Canvas，基本上，若顶点正确出现在裁剪空间中，WebGL会自动处理屏幕空间的绘制，不过，如果要处理像鼠标点选的问题时，就必须处理绘图坐标至裁剪空间的转换问题。要绘制的几何对象是由一组顶点定义，虽然裁剪空间是左手坐标，然而这组顶点可以基于左手或右手坐标定义，也就是说顶点定义在一个独立的对象空间（Object space），或说是局部空间（Local Space），这个空间有个独立原点，顶点都是相对于该原点而定义。接着，我们会缩放、转动、移动这些几何对象，实际上这些转换动作，是将这些对象中的顶点，转换至世界空间（World Space）。也就是开发者建构的3D世界，在世界空间中可能有许多对象，然而可能只想绘制出某范围内的对象，这就像是有个相机，世界很大，然而，只有相机内看到的范围才会被绘制出来，这个范围称为观察空间（View Space）。

开发者可能会用左、右、上、下，以及近面、远面边界，来定义观察空间，而观察空间会透过一些计算，对应至裁剪空间，这个过程称为投影，常见的作法有正交投影或透视透影──正交投影不会创造出远近感，然而，透视透影会因为视体（Viewing frustum）的视场角度（fov）等参数不同，呈现出不同的远近感。简单来说，从对象空间、世界空间、观察空间一直到裁剪空间等，必须经过多个空间转换，才能顺利地绘制出想要的3D对象，这些转换，说穿了，就是一连串的线性转换数学公式，然而，透过矩阵运算的话会更好，因为这会牵涉到程序运算时的效率问题。

这是点还是向量？

若要透过矩阵运算来执行空间转换，此时，就不得不接触齐次坐标（Homogeneous coordinate）。多半的说词是，齐次坐标在进行仿射转换（Affine Transformation）时很方便，像是混合缩放、转动、移动等操作的转换时计算方便，不过，实际上，齐次坐标还可以用来区别点与向量的差别。若单纯只使用直角坐标，(a, b, c)会是代表什么呢？一个点？一个向量？谁知道！

使用齐次坐标的话，(a, b, c, 1)表示这是个点，而(a, b, c, 0)表示是个向量。至于为什么会这么定义，事实上，这会牵涉到一些线性代数的基础，有兴趣的话，我们可以看看〈Understanding of homogeneous coordinates〉（https://bit.ly/2KECitX）。齐次坐标用第四个分量来代表点，这表示直角坐标中的同一个点(Px, Py, Pz)，与之对应的齐次坐标可以有无数个，也就是说(1, 2, 3, 1)、(2, 4, 6, 2)、(3, 6, 9, 3)等都代表着同一点(1, 2, 3)，也就是说，对于齐次坐标中的点(Px, Py, Pz, w)，对应的直角坐标点是(Px/w, Py/w, Pz/w)。

这就表示，当转换公式涉及某分量的除法时，透过齐次坐标可以化为矩阵运算。例如，公式转换中，若x'=near*x/z，y'=near*y/z，z'=z，就可以用齐次坐标[near * x, near * y, z, z]来表示；也就是说，计算用的矩阵若以列为主（row-major）撰写的话，会是[near, 0, 0, 0, 0, near, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0]。一旦线性转换公式可以化为矩阵运算，那么，就能将各种转换予以组合，最后得到一个矩阵，也就是说，若打算进行缩放、旋转、平移等n个转换操作，对象是1,000个顶点，直接用函式实作个别转换公式的话，必须进行n*1000的呼叫；相对地，如果使用一个结合了n个转换的矩阵，就只需要1,000次计算，若转换对象是图像的像素的话，这样的差异会更为惊人。

不是都有链接库/框架吗？

是的，3D程序设计也会有现成的链接库或框架，来做这类的转换操作，然而，别以为这样，就可以轻松了事。最起码，还是要先搞清楚它采用的坐标系统，以及相关的参数意义，最好的方式，是亲自导证一次缩放、旋转、平移、投影等矩阵等是怎么来的，这会让开发者在转换坐标系统时，更为得心应手。对齐次坐标与矩阵转换有兴趣的话，不妨可以看看〈Interactive guide to homogeneous coordinates〉，该文从程序人的角度，提供互动的方式，来协助你认识齐次坐标与矩阵转换。别以为这只是数学，正如该文中所谈到的：「认识选择的框架背后的数学，写出来的程序代码才会有效率」。