我之前曾经暗笑过，毕设我的题目是一个 Direct3D 的东西，我觉得一个多月就可以搞定。然而，实际上手之后，世界又欺骗了我。今天我讲一下我是如何被几个连锁的问题坑，最终发现并解决了的。
首先，按照项目要求、我的喜好和能力范围，我选择的是 C#/SharpDX 的组合，没有选择 C++ 也没有选择 XNA。不过原理是相通的，所以 DirectX 的教程在大致了解了 SharpDX 的封装风格后还是能用的。我采用的是这个教程的逐步深入方式（学习嘛），而不是 MiniCube 示例的直接上顶点数组+shader的方式。
我跳过了 Lesson 4 ，虽然知道这方式很蛋疼（用多了 WebGL 习惯了 OpenGL 的思路），特别是顶点格式（SetFVF()）。不过看起来后期会用到 VertexDeclaration，好理解多了，一步一步来吧。然而转到 Lesson 5 的时候就出问题了，我的屏幕上什么都没出现。
我是进行了初步的代码理解后就开始设计以后的渲染流程了（分别用 C++ 和 C# 写了简单的架构），所以逻辑并没有教程里的渲染单一三角形那么直观。我想，设备创建之后，也就是初始化顶点数据-写入-绘制而已啊，不到20行的代码怎么就出问题了呢？此时我是比较整体逻辑的，而不是一句句照搬；逻辑上等价就是正确。折腾了一晚上没发现是什么导致的。于是决定返回尝试和教程亲和度最高的 C++。可是，C++ 这边也是什么都出不来。是我的 DirectX 问题吗？新建一个代码文件，粘贴教程内容，编译（CLion 使用 CMake，对构建选项的控制比 Visual Studio 方便得多，增加一个 target，只编译这个就行），运行，嘿，不是 DX 的问题。那么是什么呢？抓狂后迫不得已，一行行对比和教程中的区别。明明消隐（culling）都是关了的。最后发现，我启用了模板缓冲：
presentationParameters.EnableAutoDepthStencil = TRUE;
注释掉（默认 ZeroMemory() 了所以是 FALSE）就好了。然而并不知道为什么会出错……或者我是没有去看模板函数和模板判定……
C++ 那边搞定，终于回到 C# 这边了。按照 C++ 那边调好，还是没有绘制。
偶然之间，发现如果注释掉设置变换矩阵（视图、投影、世界）的语句，依稀能看到点三角形的样子——绘制的范围在 XOY 平面 [-3, 3] 范围，所以能看部分并分辨出来。
最终，将问题发生点锁定在数行代码之内：
Matrix matrix;
matrix = Matrix.LookAtLH(new Vector3(0, 0, 10), new Vector3(0, 0, 0), new Vector3(0, 1, 0));
target.Device.SetTransform(TransformState.View, matrix);
var size = _manager.Control.Size;
// matrix = Matrix.OrthoLH(size.Width, size.Height, -100, 100);
matrix = Matrix.PerspectiveFovLH(MathUtil.DegreesToRadians(45), (float)size.Width / size.Height, 0f, 100f);
target.Device.SetTransform(TransformState.Projection, matrix);
target.Device.SetTransform(TransformState.World, Matrix.Identity);
看到这里，由于 Control.Size 是不会出错的，所以不得不怀疑是 Matrix 的问题，怀疑一个流行库的底层函数的实现有问题！
然后发现，视图和投影共同起作用，无法分离。如果使用正交投影（如注释了的代码）而不是透视投影，能正常显示。
设断点单步调试，发现投影矩阵居然是这样的（宽度 800px，高度 600px）：
[NaN 0 0 0
0 NaN 0 0
NaN NaN 1 1
0 0 0 0]
这个矩阵在同样的条件下，C++ 那边的值是正常的：
[1.72751749 0 0 0
0 2.41421342 0 0
0 0 1 1
0 0 -0 1]
其他两个矩阵第一眼看上去正常。嗯，如果给投影设置一个无效的矩阵，自然就画不出东西了。那么为什么会出错呢？
首先来看看透视投影矩阵。以下的矩阵以 Direct3D、左手系的为准，OpenGL 的和/或右手系会有所不同。
第一种形式是这样的：
关键参数是视场（field of view，FOV，FOV=2θ）、宽高比（aspect ratio）、近剪裁面和远剪裁面距离4个参数。
第二种形式是这样的：
关键参数是矩形的左右上下（LRTB）和远近剪裁面距离6个参数。不过一般投影面是居中的（原点在正中），所以一般会取 L=-R=0.5W、T=-B=0.5H 的值。
然后我们看看 SharpDX 对 Matrix.PerspectiveFovLH() 的实现。我将关键代码列出来。
public static void PerspectiveFovLH(float fov, float aspect, float znear, float zfar, out Matrix result)
{
float yScale = (float)(1.0 / Math.Tan(fov * 0.5f));
float xScale = yScale / aspect;
float halfWidth = znear / xScale;
float halfHeight = znear / yScale;
PerspectiveOffCenterLH(-halfWidth, halfWidth, -halfHeight, halfHeight, znear, zfar, out result);
}
public static void PerspectiveOffCenterLH(float left, float right, float bottom, float top, float znear, float zfar, out Matrix result)
{
float zRange = zfar / (zfar - znear);
result = new Matrix();
result.M11 = 2.0f * znear / (right - left);
result.M22 = 2.0f * znear / (top - bottom);
result.M31 = (left + right) / (left - right);
result.M32 = (top + bottom) / (bottom - top);
result.M33 = zRange;
result.M34 = 1.0f;
result.M43 = -znear * zRange;
}
可以看到，Matrix.PerspectiveFovLH() 用 FOV、宽高比和近剪裁面距离确定了一个四棱锥的底面（矩形），以此作为目标投影矩形的大小，然后传给 Matrix.PerspectiveOffCenterLH() 计算矩阵。然后注意到我传的参数，近剪裁面距离为零——意味着直接计算的话，目标投影矩形是一个零宽度零高度的矩形！然后接下来就是被零除的问题，返回的自然是 NaN。
看来我怀疑对了。
那么近剪裁面距离为0是否是一个可取的值呢？有意义，可以取到。考虑到我们绘制的实际上是一个平截头体（frustum）所交的内容，其极限是一个四棱锥，意义就是从观察点到远剪裁面中由 FOV 和宽高比确定的矩形所形成的四棱锥中的所有内容都会被考虑。谁说“眼前”一定要大于某个值呢？更重要的是，Direct3D 对应的函数（D3DXMatrixPerspectiveFovLH()）很好地处理了0值——同样的参数，在 C++/DirectX 中能正确渲染。寻找一下理论基础，那就是——在矩阵计算形式一中，根本不需要计算宽高。形式一在给定了 FOV 和宽高比时，比形式二更通用；形式二向形式一的转换必须在近剪裁面距离不为零时才能以成立。也就是说，SharpDX 的开发者可能并没有测试这种特殊情况，其他用 SharpDX 写各种 DirectX 程序的人也至少是规避了这个问题（可能是效率影响？），而不巧我撞上了。
所以最后，提出了一个 issue，紧接着提了一个 pull request。PR 的提交自动构建失败是强签名的问题——不过代码本身没错，更改也不影响其他文件——人工查看日志的话应该会明白的。
有一个很有意思的现象，C++ 的 IDE 我选择的是 CLion，编译基于 Cygwin。Direct3D 应用程序的绘制逻辑一般是空闲时渲染的：
MSG msg;
while (TRUE) {
if (PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
} else {
// Idle
Render();
}
}
在这种逻辑下，测试空白的渲染（只有 Clear()），在我的显卡上如果不进行垂直同步（也就是立即渲染），那么原生 D3D 的帧率在2800左右，而 SharpDX 的“改良版”循环（RenderLoop）帧率在6200左右。这刷新了我的认知——而且是在图形渲染上。
我以为是 Cygwin 的 API 包装层引起的效率损失，然后费了好大劲换到 MinGW 上（主要是 CLion 对 MinGW 版本和环境要求很严格），还是差不多的数值。
难道是 SharpDX 的黑科技？