简介：这份资源面向学习Direct3D图形编程的开发者与计算机图形学爱好者，以D3D9.0结合Visual C++ 10实现太阳系运行的可视化模拟，涵盖摄像机动态控制、行星自转与公转、椭圆轨道绘制、纹理贴图及天空盒渲染等核心知识点，适合作为3D场景构建与动画控制的实践案例。压缩包共109个文件，约14.2MB，以cpp与h源码文件为主体，辅以obj、pdb、ilk等编译中间产物，以及jpg纹理素材、tlog日志和sln、vcxproj工程配置，另含可执行文件便于直接运行观察效果。已有547人学习下载。读者可从中获得一套结构完整的D3D9工程源码，理解摄像机视角切换、开普勒定律驱动的公转轨迹与自转周期模拟的实现思路，并借助纹理与天空盒部分掌握提升场景真实感的常用手段，为游戏开发与科学可视化方向积累可复用的编码经验。
1. 太阳系模拟：为什么“轨道自转公转”不是三个动画叠在一起
很多人第一次写太阳系 Demo，直觉是把地球绕太阳转、地球自己转、月球绕地球转，各写一个旋转动画，然后叠在一起。跑起来一看，行星要么飞出轨道，要么自转轴跟着公转一起歪，要么月球被地球“甩”出去。问题不在动画写错了，而在于把“层级变换”当成了“独立动画”。D3D 太阳系这类项目的核心，其实是一套父子变换矩阵的级联：公转是父节点绕原点旋转，自转是子节点绕自身轴旋转，卫星再挂一级。搞懂这套矩阵怎么乘、乘的顺序为什么不能反、每帧怎么从根节点一路推到叶子节点，你才算真正理解“轨道自转公转”这六个字背后的机制。这也是为什么值得把这份 D3D 太阳系资源拆开看——它把层级变换、轨道参数、渲染循环三件事压在一个可运行的最小系统里，翻车点和设计取舍都藏不住。
2. 层级变换：公转和自转为什么必须分开算
2.1 世界矩阵的级联顺序决定了行星会不会“歪”
D3D 里每个物体最终要交给着色器的是一个世界矩阵，它把模型空间的顶点搬到世界空间。太阳系的结构天然是一棵树：太阳是根，行星是子，卫星是孙。常见的实现思路是每个节点持有一个局部变换，世界矩阵等于父节点世界矩阵乘以自身局部矩阵：
// 每个节点每帧更新一次世界矩阵 // parentWorld 是父节点的世界矩阵，local 是本节点的局部变换 // 顺序不能反：先局部，再父级，最后才是世界 XMMATRIX world = local * parentWorld;这里最容易翻车的是乘法顺序。D3D 的矩阵默认按行向量约定，local * parentWorld表示“先应用局部变换，再应用父级变换”。如果你写成parentWorld * local，行星会先被父级搬到轨道位置，再绕自己的原点转——看起来就像自转轴被公转带歪了。血泪经验是：公转矩阵放在父级，自转矩阵放在子级，两者永远不合并到同一个矩阵里。一旦合并，你就失去了单独调轨道倾角、自转轴倾角的能力，后面想加黄赤交角直接没地方下手。
2.2 公转矩阵：绕原点旋转，而不是绕自身旋转
公转的本质是“位置在变、朝向也在变”。如果只改平移量让行星沿圆走，行星的正面会一直朝同一个方向，看起来像在滑行而不是公转。正确的做法是公转矩阵本身就是一个绕 Y 轴的旋转矩阵，旋转中心是太阳所在的原点：
// angle 是公转角度，随帧累加；radius 是轨道半径 // 先平移到轨道半径处，再绕原点旋转，等价于绕太阳公转 XMMATRIX orbit = XMMatrixRotationY(angle) * XMMatrixTranslation(radius, 0.0f, 0.0f);注意这里XMMatrixRotationY(angle)在左、平移在右，含义是“先把行星放到半径处，再整体绕原点转”。这样行星的位置沿圆走，同时它的局部坐标系也跟着转，朝向自然跟着公转方向变化。如果你把平移写在左边，行星会绕自己转而不是绕太阳转，轨道半径直接失效——这是新手最常踩的坑，现象是“行星原地打转不前进”。
2.3 自转矩阵：绕自身轴，轴倾角要单独留一层
自转是子节点绕自己的 Y 轴转，和公转完全解耦：
// spin 是自转角度，比公转快得多 // 自转只作用于模型本身，不影响轨道位置 XMMATRIX spin = XMMatrixRotationY(spinAngle);真正讲究的地方在于轴倾角。地球自转轴相对黄道面有约 23.5 度的倾角，如果直接把倾角塞进自转矩阵，倾角会跟着公转一起转，四季就没了。常见的实现思路是给每个行星节点再加一层“轴倾斜”矩阵，固定在父级和自转之间：
// tilt 是固定的轴倾角，不随帧变化 // 顺序：先自转，再倾斜，最后交给公转父级 XMMATRIX local = spin * tilt;这样自转始终绕倾斜后的轴进行，而倾斜本身不参与公转旋转，季节变化的视觉基础就有了。这份资源里把倾角做成每个行星的独立参数，而不是全局常量，正是为了让水星这种几乎无倾角和地球这种明显倾角的行星能共存于同一套代码。
3. 轨道参数化：角度、半径、周期怎么组织才不打架
3.1 用角速度而不是每帧固定增量
最朴素的写法是每帧给公转角度加一个固定值，跑起来所有行星转速一样，完全不像太阳系。正确的参数化是给每个行星一个公转周期，每帧按时间差换算角速度：
// deltaTime 是上一帧到这一帧的秒数 // period 是该行星公转一周所需秒数 float angularSpeed = 2.0f * XM_PI / period; orbitAngle += angularSpeed * deltaTime;这样水星周期短、转得快，海王星周期长、转得慢，比例关系直接由数据决定，而不是靠手调增量。自转同理，用自转周期换算。这里有个容易忽略的点：角度要取模，否则跑几个小时后浮点精度下降，行星会开始抖动。常见的做法是orbitAngle = fmodf(orbitAngle, 2.0f * XM_PI)，把角度锁在一个周期内。
3.2 轨道半径和行星半径必须分两个量
新手常把“行星离太阳多远”和“行星自己多大”混成一个缩放系数，结果要么行星巨大挤在一起，要么小到看不见。这份资源的结构里，轨道半径决定平移量，行星半径决定模型缩放，两者独立：
| 参数 | 作用 | 典型量级关系 |
|---|---|---|
| 轨道半径 | 决定公转圆的半径 | 外行星远大于内行星 |
| 行星半径 | 决定模型缩放 | 远小于轨道半径 |
| 公转周期 | 决定角速度 | 与轨道半径正相关 |
| 自转周期 | 决定自转角速度 | 与行星半径无直接关系 |
真实太阳系里轨道半径和行星半径差好几个数量级，直接照搬会让内行星小到不可见。常见的工程取舍是对半径做非线性压缩，比如开方或对数映射，既保留“外圈更大”的直觉，又保证所有行星都能看见。这不是物理错误，而是可视化取舍，资源里如果做了压缩，注释里通常会写明“非等比”。
3.3 卫星是第三级：月球为什么不能直接挂太阳
月球绕地球转，地球绕太阳转，所以月球的世界矩阵是“月球局部 × 地球世界矩阵”，而地球世界矩阵又是“地球局部 × 太阳世界矩阵”。如果偷懒把月球直接挂到太阳下面，月球会绕太阳转而不是绕地球转，现象是“月球和地球各走各的”。层级变换的级联天然支持任意深度，代价是每帧要从根节点深度优先遍历一次，把父矩阵传下去：
// 递归更新：先算自己的世界矩阵，再传给子节点 void UpdateNode(Node& node, const XMMATRIX& parentWorld, float dt) { node.world = node.local(dt) * parentWorld; for (auto& child : node.children) { UpdateNode(child, node.world, dt); } }这段递归是整个系统的骨架。它的复杂度是 O(节点数)，太阳系规模下可以忽略，但顺序很重要：必须先更新父节点再更新子节点，否则子节点用的是上一帧的父矩阵，高速公转时会出现卫星“滞后”于行星的视觉错位。
4. 渲染循环与矩阵上传：每帧到底发生了什么
4.1 更新与渲染分离，避免矩阵算一半就画
一个稳定的渲染循环通常把“更新变换”和“提交绘制”分成两个阶段。更新阶段只算矩阵，不碰 D3D 设备；渲染阶段只读矩阵，不改状态。这样做的好处是逻辑清晰，出问题时能快速定位是“矩阵算错了”还是“绘制状态错了”。伪代码结构大致是：
// 每帧入口 void Frame(float deltaTime) { UpdateScene(deltaTime); // 只更新节点矩阵和相机 RenderScene(); // 只做绘制，读矩阵 }如果两个阶段混在一起，某个行星的矩阵在绘制中途被改，就会出现“这一帧画了一半新位置一半旧位置”的撕裂感。血泪经验是：矩阵更新和绘制之间不要有任何共享可变状态，节点矩阵算完就冻结，绘制阶段只读。
4.2 常量缓冲区：世界矩阵怎么送到着色器
D3D 里世界矩阵通过常量缓冲区传给顶点着色器，每个物体绘制前更新一次。常见的坑是常量缓冲区没对齐或者更新时机不对，现象是“所有行星挤在原点”或“矩阵是上一帧的”。关键点在于：常量缓冲区按 16 字节对齐，矩阵本身是 64 字节，通常一个缓冲区放世界矩阵加视图投影矩阵；每次Map写入后要Unmap，并且同一帧内多次写入要注意驱动是否支持“丢弃”语义。资源里如果用了动态常量缓冲区，注释一般会标出D3D11_MAP_WRITE_DISCARD，这是避免 GPU 还在读旧数据时 CPU 覆盖的标准做法。
4.3 深度测试和透明：行星互相遮挡靠什么
太阳系里行星在轨道上前后穿插，谁挡谁必须正确。这依赖深度缓冲：绘制前清深度，每个行星按世界矩阵变换后写入深度，深度测试决定像素是否通过。如果忘了开深度测试，远处的行星会画在近处行星上面，现象是“轨道交叉处行星闪烁”。另一个细节是太阳通常要做自发光效果，可能涉及透明混合，而透明物体需要关闭深度写入并按距离排序，否则会出现“太阳后面的行星透过太阳露出来”的玄学画面。这份资源如果只做基础光照，深度测试就是唯一需要关心的遮挡机制，把DepthEnable打开、深度比较函数设为LESS即可。
5. 避坑与排查：太阳系 Demo 最常见的五类翻车
5.1 行星飞出屏幕或原地打转
现象：运行后行星不在轨道上，要么直线飞走，要么原地自转不前进。原因几乎都是公转矩阵的乘法顺序写反，把平移和旋转的位置对调了。解决：确认公转是“先平移到半径，再绕原点旋转”，即旋转矩阵在左、平移在右；同时检查父矩阵和局部矩阵的级联顺序是local * parentWorld。
5.2 自转轴跟着公转一起歪
现象：行星公转一圈，自转轴方向也跟着转一圈，季节效果消失。原因是把轴倾角矩阵放进了公转那一层，或者自转和公转合并成了一个矩阵。解决：轴倾角固定在自转层，公转只作用于父级；自转矩阵和倾角矩阵相乘后作为局部矩阵，不再和公转矩阵合并。
5.3 卫星被甩出去或滞后于行星
现象：月球不绕地球转，或者明显落后于地球位置。原因一是卫星挂错了父节点，直接挂到了太阳下面；原因二是更新顺序错误，先更新了子节点再更新父节点。解决：确认卫星的父节点是行星；递归更新时严格先父后子，保证子节点用的是本帧最新的父矩阵。
5.4 跑久了行星开始抖动
现象：运行几分钟后行星位置出现细微抖动，轨道不再平滑。原因是角度累加没有取模，浮点数越来越大，精度下降。解决：每帧对公转和自转角度做fmod取模，锁在一个周期内；时间差用双精度或限制单帧最大值，避免卡顿后角度跳变。
5.5 行星互相遮挡关系错乱
现象：轨道交叉处行星闪烁，或者后面的行星盖住前面的。原因是深度缓冲没开、没清，或者透明物体没排序。解决：确认每帧清深度、深度测试开启且比较函数正确；如果有透明效果，透明物体最后画并按相机距离排序，必要时关闭透明物体的深度写入。
6. 设计取舍：为什么这类 Demo 值得从矩阵层重写一遍
把太阳系跑起来不难，难的是跑起来之后每个参数都还能单独调、每个现象都能追溯到某一层矩阵。这份资源真正的价值不在“画了几个球”，而在于它把层级变换、轨道参数化、渲染循环三件事拆成了可以独立验证的层。你可以只改公转周期看比例是否合理，只改轴倾角看季节是否出现，只改更新顺序看卫星是否滞后——每一层都有明确的观测现象对应。这种“可归因”的结构，比一个把所有逻辑揉进一个函数的版本值钱得多。
从设计取舍上看，这里有几组绕不开的权衡。第一组是物理真实 vs 视觉可读：真实轨道半径差几个数量级，照搬会让内行星不可见，所以半径压缩几乎是必然选择，关键是压缩后仍保留“外圈更慢”的周期关系，否则直觉就断了。第二组是层级深度 vs 更新成本：级联变换支持任意深度，但每加一级就多一次矩阵乘法和一次递归，太阳系规模下成本可忽略，真正要防的是更新顺序错误带来的滞后。第三组是角度累加 vs 绝对时间：累加简单但有精度问题，用绝对时间乘角速度更稳，代价是要处理暂停和变速。我一般会选绝对时间方案，因为调试时能随时跳转到任意时刻复现问题。
验证这套机制是否真的理解到位，有个简单办法：把地球的公转周期改成 1 秒、自转周期改成 0.1 秒，看月球是否仍然稳定绕地球转、地球自转轴是否仍然保持倾角。如果月球开始画圈乱飞，说明层级或更新顺序有问题；如果倾角消失，说明倾角矩阵放错了层。这个压力测试能把大部分隐藏的矩阵顺序错误逼出来。
从那以后我每次写带层级的变换系统，都强制先把“父矩阵传子矩阵”的递归骨架搭好、用两个球验证级联顺序，再往里填轨道参数和渲染细节。矩阵顺序这种错误，靠看代码很难发现，靠跑起来看现象一抓一个准。希望帮到你。
本文还有配套的精品资源，点击获取
