基于pygame的太阳系模拟器：从轨道计算到性能调优全解析

简介这是一份用于模拟太阳系运行的编程项目压缩包适合对天体动画、图形编程和物理仿真感兴趣的开发者也适合作为教学实例来理解行星运动与参数化交互。资源包共包含二十三个文件其中以二十张PNG图片为主另有HTML页面、JPG位图等整体大小约11.9MBPNG图片对应太阳、行星等不同星体HTML页面可作为前端演示或交互入口JPG位图为原始贴图便于替换或二次加工。包内代码与素材相互配合可实现星球大小、轨道尺寸、颜色及绕行速度的动态调节涉及图像缩放、轨道数学建模与时间步长控制等知识点。目前已吸引五百五十四人学习浏览对动手实践者而言可在现成代码上直接修改参数观察运行效果并从中学习图像处理、基于万有引力的运动计算、界面资源组织与模块拆分思路为进一步扩展成完整可视化系统打下基础。 整理硬盘的时候翻到一个老项目文件夹名叫“模拟太阳系y”这个“y”到底是当时随手打的版本号还是某个英文缩写我已经记不清了。里面装着完整的源代码和一套行星贴图素材我顺手打包成了 rar 存备份。后来几个学 Python 的朋友问我要入门项目我又把这个包翻了出来。用 pygame 写一个太阳系模拟难度不算高但涉及的知识点特别密集时间尺度换算、轨道运动、贴图渲染、交互相机、性能优化一条线串下来几乎把 2D 游戏开发的常用套路都过了一遍。如果你正在找练手项目或者想把天文数据变成可视化程序这套源代码和素材可以直接拿去改。我把代码结构、素材处理、算法选型和踩过的坑全部拆开讲一遍换台机器照着做也能跑出同样的效果。1. 这个 rar 里到底打包了什么打开压缩包先别急着点 main.py我把目录结构贴出来你能一眼看清这个项目的骨架模拟太阳系y/ ├── main.py # 入口主循环 ├── config.py # 全局参数集中管理 ├── planets_data.py # 行星轨道/大小/自转数据 ├── texture_loader.py # 贴图加载与缓存 ├── camera.py # 相机缩放与拖拽 ├── render.py # 绘制逻辑 ├── assets/ │ ├── textures/ # 行星贴图与特效素材 │ │ ├── sun.jpg │ │ ├── mercury.jpg │ │ ├── venus.jpg │ │ ├── earth.jpg │ │ ├── mars.jpg │ │ ├── jupiter.jpg │ │ ├── saturn.jpg │ │ ├── saturn_ring.png │ │ ├── uranus.jpg │ │ └── neptune.jpg │ ├── fonts/ # HUD 字体 │ └── audio/ # 背景音乐默认关闭 └── README.md # 运行说明与依赖列表我习惯把配置单独抽到 config.py而不是散落在各个文件里。理由很直接太阳系模拟里有一堆相关参数——窗口大小、初始缩放倍数、模拟时间倍率、轨道线开关、颜色阈值……如果全部硬编码在调用处改一个参数要全局搜索替换很久。集中管理之后调试时只需要改一处跑一遍就知道效果。assets 目录是这次打包的重点。素材不算多但贴图处理费了我不少时间。每颗行星的贴图我都准备了 1024 像素的 jpg原始的 4096 高清版本没有放进 rar因为加载到 pygame 里之后内存和显存占用都很夸张而且运行时频繁缩放的卡顿感极其明显。土星环单独存成带透明通道的 png因为环不是贴在星球表面的绘制时需要和主体分开放到不同 Surface 上再合成。audio 目录里是一段循环用的轻音乐代码里默认是关掉的毕竟这是一个演示项目多数人跑起来只想安静看轨道。字体文件同样关键。pygame 默认字体不支持中文如果你直接 screen.blit 显示“水星”两个汉字屏幕上会出现两个方框。所以 rar 里带了一个开源中文字体避免换一台机器、换一个操作系统之后字体渲染全崩掉。README 里写了运行环境Python 3.8、pygame 2.0依赖只有 pygame 一个包。这也是我当初选 pygame 的原因之一如果还要让人先装 numpy、scipy对只想复制粘贴跑起来的新手就不太友好了。拿到压缩包之后可以先对照 README 核对文件是否齐全缺了 assets 目录里的任何一张贴图程序启动时都会报错。2. 技术选型逻辑为什么抛掉 Three.js 选了 pygame很多朋友一看到“太阳系模拟”就默认应该用 Three.js 做 3D 场景或者干脆开 Unity 工程。我并不是没考虑过当时先花了一个晚上用 Three.js 搭了个雏形浏览器里确实好看行星是球体光照阴影都有。但做到一半我决定推翻重来换成 Python pygame。原因是这个项目从一开始就不是为了给人展示“我做出了一个多酷的成品”而是当作教学样本给身边想学 Python 和游戏循环的人拆着看。方案上手门槛天文计算生态交付分发代码可读性Python pygame低好可组合 numpy/astropy需装 Python 环境高Three.js中一般浏览器直接打开中Unity高一般打包体积大低pygame 的优势不在渲染效果而在结构透明。整个程序的核心只有三件事处理事件、更新状态、绘制画面。这个循环写出来之后任何人都能看懂“行星每帧做了一次角度计算”这件事和屏幕上的运动有什么关系。Three.js 里你写一句 mesh.rotation.y 0.01背后对应的是复杂渲染管线初学的人很难把这一行和星体运动联系起来出了问题更不知道往哪个方向排查。天文数据的处理也更贴合 Python 生态。轨道周期、距离、偏心率这些数据我用 dict 列表存好后续想换成真实星历数据可以直接接 astropy 的接口。写视觉效果时pygame 的 Surface 操作比 Three.js 的材质系统直观得多毕竟这个项目里所有贴图最终都只是一张矩形图在屏幕上做平移、旋转和缩放不需要什么复杂的光照模型。还有一个实际考虑是分发。pygame 项目可以用 PyInstaller 打包成可执行文件或者直接把源码丢给对方让他跑对新手而言复制粘贴就能运行。Unity 工程动辄几百兆编译一次几分钟对这个量级的项目来说有点小题大做。从代码组织角度讲我刻意把模拟部分和渲染部分拆开了。planets_data.py 只描述“太阳系是什么”render.py 只关心“怎么画出来”二者之间通过一个 Planet 对象对接。这样将来想换图形库或者想接真实星历数据都不会牵扯到另外一半代码。很多自学的人写项目所有逻辑堆在一个文件里两三百行就开始混乱这恰恰是没有做模块划分导致的。这个项目文件虽然不多但每个文件的职责是清晰的这也是打包成 rar 分享时比较值得参考的一点别人拿到的是可以独立演进的结构而不是一团理不清的代码。3. 源代码主干从主循环到行星类的实现细节pygame 的程序结构基本是固定的。main.py 里的主循环是整段源代码的骨架import pygame from config import FPS, SCREEN_SIZE from planets_data import PLANETS from texture_loader import load_textures from camera import Camera from render import render_frame def main(): pygame.init() screen pygame.display.set_mode(SCREEN_SIZE) clock pygame.time.Clock() textures load_textures() camera Camera() planets [Planet(data, textures) for data in PLANETS] elapsed_days 0.0 day_step 2.0 # 每个真实秒对应 2 个模拟天 running True while running: dt clock.tick(FPS) / 1000.0 for event in pygame.event.get(): if event.type pygame.QUIT: running False camera.handle_event(event) camera.update(dt) elapsed_days dt * day_step for p in planets: p.update(elapsed_days) render_frame(screen, planets, camera, elapsed_days) pygame.display.flip() pygame.quit()注意这里我用的是 elapsed_days 这个累计量而不是每帧给行星的小角度增量。这是我踩坑之后总结出来的经验如果每帧都让行星的 angle delta_angle运行几分钟之后浮点误差会持续累积行星位置就会慢慢偏离理论值。而累计时间再带入轨道方程计算角度误差不会随时间放大。这个设计看似简单却是源代码里最重要的一个决策。行星类是整个项目最核心的类它有数据属性轨道半径、公转周期、自转周期、贴图路径和行为方法update 和 draw。关键代码如下class Planet: def __init__(self, data, textures): self.name data[name] self.orbit_radius data[orbit_radius] # 像素 self.period_days data[period_days] # 天 self.rotation_hours data[rotation_hours] # 小时 self.visual_radius data[visual_radius] # 像素 self.texture textures[data[texture_key]] self.angle 0.0 self.x, self.y 0, 0 def update(self, t_days): # 公转用累计时间直接算出角度 self.angle (2 * math.pi * t_days) / self.period_days self.x self.orbit_radius * math.cos(self.angle) self.y self.orbit_radius * math.sin(self.angle)公转周期的数据用“天”做单位调整 day_step 就能控制整套系统的运行节奏。比如 day_step2 的时候地球绕一圈需要 365.25 个模拟天跑完一圈差不多 182 秒人眼看着不会太急躁又能看到水星明显跑得比其他行星快。如果直接沿用现实时间尺度水星转一圈要 88 天观众不到半分钟就会关窗口。自转也用同样的思路用一个自转角度每帧按 rotation_hours 换算增量。但这里有个细节自转方向。金星是逆向自转自转方向和公转方向相反很多人第一次做会忽略导致金星总是朝着反方向转。我的做法是在数据表里用负数表示逆向自转行星类统一取角度增量的符号这样数据层就能表达方向代码层不用写分支。所有行星的轨道数据集中在 planets_data.py 里下面是最初版本的数据表也是整个模拟的坐标系基准行星轨道半径(px)视觉半径(px)公转周期(天)自转周期(小时)水星505881407.6金星758224.7-5832.5地球1009365.2524火星135768724.6木星2202043339.9土星295171075910.7天王星3901230687-17.2海王星480126019016.14. 素材处理与轨道参数从天文数据到像素坐标制作这一层的时候核心思路是“真实的物理数据做底层视觉数据做显示”。轨道半径的真实数值差距太大了水星离太阳 5800 万公里海王星 45 亿公里差了两个数量级。如果按同一个比例尺画水星会缩成一个无法看见的点海王星会在屏幕边缘之外。所以我采用双层数据底层保留真实轨道周期的比例显示层用视觉轨道半径做等比缩放。这也是天文模拟软件里常见的做法属于不会在文档里写、但做出来效果完全不同的细节。贴图素材的来源有两条路。一条是 NASA/Goddard 发布的公共领域行星纹理选 1024 分辨率版本另一条是手动绘制的示意贴图适合找不到合适纹理时应急。不建议直接上 4096 原图pygame 的 transform 缩放性能不够加载也会慢。建议先用 Pillow 批处理成 1024再在 texture_loader 里统一加载转成 pygame Surface 后立刻调用 convert()。convert() 之后的 Surface 在 blit 时能使用硬件加速否则每帧绘制都会慢一截。土星环的素材需要单独说明。它是一张带透明通道的 PNG主体是半透明色带绘制时用它自己的旋转中心对准土星中心。因为环的贴图相对独立用 pygame.transform.rotozoom 旋转会产生临时 Surface旋转本身很费性能所以后期优化时改成只在环相对屏幕方向改变时才重新旋转一次而不是每帧都转。轨道参数方面如果只做圆轨道第 3 节的代码已经够了。但我想让轨道看起来更真实于是在代码里加入了椭圆轨道的支持用开普勒方程计算行星位置。核心解法在这里后面解释为什么这个算法能用于模拟def solve_kepler(M, e, tol1e-6): E M if e 0.8 else math.pi for _ in range(100): dE (E - e * math.sin(E) - M) / (1 - e * math.cos(E)) E - dE if abs(dE) tol: break return EM 是平近点角随时间线性增长e 是轨道偏心率E 是偏近点角。真实行星轨道不是标准正圆尤其水星和火星偏心率不为零。把 E 代回极坐标公式就能得到行星在椭圆轨道上的真实位置。求解过程用的是牛顿迭代因为开普勒方程 E - e·sin(E) M 是超越方程没有解析解。对于 e 0.8 的太阳系行星迭代 5 次以内就能收敛到可接受精度写 100 次上限纯粹是保险。我初始版本只做了圆轨道数据表里也没有偏心率字段。加入椭圆轨道后视觉上最明显的差别是行星的移动速度不再匀速近日点附近明显变快远日点附近变慢这才符合真实观测。虽然对第一次运行的人来说这种速度变化不一定察觉但科学演示项目里细节越真实越经得起别人推敲。轨道参数的另一条验证路径是开普勒第三定律周期平方和轨道半长轴三次方成正比。我在数据表里给出的周期值和轨道半径并非从网上随手抄的而是先确定显示层轨道半径再按真实行星相对距离换算周期这样至少保证行星之间的相对快慢不会乱。5. 从调试到排查第一版跑崩之后的问题记录很多新手遇到问题会直接问“为什么报错”但实际调试中最难的不是修复那一行而是找到问题根源。我把自己在这个项目里真正踩过的坑按排查顺序整理出来每个都能对应到一次实际调试过程不是凭空总结的。5.1 行星位置全堆在屏幕中心最初写轨道数据时想“真实一点”把轨道单位全部写成了真实轨道半径的物理数值结果太阳到水星的距离是几千万公里相机缩放是 1换算到像素后所有坐标都在零点附近。排查时我先打印了转换后的屏幕坐标看到 x、y 全是个位数立刻意识到单位换算没做。解决方法是把所有轨道半径换算成显示层的“像素半径”而不是在物理层转来转去。这个坑的教训是数据层和显示层的单位一定要分离不要混在一个变量里。还有个衍生问题行星全都“画成一团”原因是视觉半径和轨道半径的比例失调。木星视觉半径 20 像素轨道半径若只有 50 像素视觉上木星会占掉大半个轨道。重新设计比例时我保证行星半径占比不超过轨道半径的十分之一视觉上才舒服。这一步没有公式可套纯粹靠调参试出来的。5.2 运行几十分钟后行星位置出现偏差这是我之前提到的浮点累积问题但最初排查方向是错的我以为是数据表写错了浪费了一下午。后来写了一个小脚本打印行星角度和理论角度的差值发现误差随时间线性增长才想到是增量累积导致。改成累计时间之后问题消失。这个案例值得多说一句当程序运行的错误是“越来越偏”而不是“一开始就错”优先考虑累积型错误浮点误差、帧率累计、时间溢出都在这个范畴。5.3 土星环的透明区域变成黑色原因很简单加载 PNG 时用了 convert() 而不是 convert_alpha()。pygame 里 convert() 会把带透明的图像转成 RGB 模式透明区域会被填充成纯黑。排查时打印 surf.get_flags() 就能看到表面缺少 SRCALPHA 标记换成 convert_alpha() 后正常。这个问题其实很常见不只是土星环任何带透明通道的素材都会踩到这个。5.4 窗口最小化再恢复之后行星运行速度不对同一台机器上窗口最小化再恢复之后行星的移动速度明显和之前不一样。因为代码里用的运动增量是每帧计算的帧率波动直接改变速度。排查时我在 HUD 里显示了当前 FPS 和模拟时间发现 FPS 从 60 掉到 30 时行星走过的角度也变成一半。解决方法是统一使用 dt上一帧到这一帧的秒数做乘法让运动速度与帧率无关。这是游戏开发里的基本常识但非游戏背景的编程初学者很容易踩。5.5 字体渲染出现方框用系统默认字体渲染中文变成两个方框这个前面提过。排查方法是在初始化时列出 pygame.font.get_fonts()发现 Linux 和 Windows 的默认字体集合差异很大所以索性在 rar 里带了一个开源字体最稳妥。另一个相关问题HUD 文字如果每帧都重新渲染也会拖慢帧率所以我把显示用的文字 Surface 缓存起来只在数值变化时才更新。5.6 拖拽相机时行星跟着抖原因是相机的 offset 更新和行星位置更新顺序写反了先用了旧的 offset 绘制再更新 offset。排查思路是把相机更新放在行星状态更新之前并打印一帧前后 offset 值确认。这类问题的本质是每帧的更新顺序没有理清pygame 不会替你保证顺序状态更新和绘制之间的依赖关系必须自己维护。6. 性能优化与迭代从 15 帧到 60 帧的调优记录第一版跑起来只有 15 帧左右画面卡顿明显。我一步步优化每一步都有可视的变化整理成表格供参考优化动作帧率原始版本每帧加载贴图15贴图预加载 convert23背景星空预渲染成静态层31行星旋转缓存避免每帧 rotozoom45限制重绘区域为 dirty rect58关闭音乐 缓存 HUD 表面60第一个问题是贴图加载。第一版用“懒加载”写得很聪明行星第一次 draw 时才 load_texture但行星一旦开始运动第一次进入视野时就会卡顿一下。改成启动时统一预加载后帧率提升到 23。这也呼应了前面说的素材预先处理好比运行时处理省事得多。第二个问题是星空背景。原来每帧都绘制几千个静态星星这纯粹是浪费因为这些星星根本不会变化。于是我把星空先画到一张固定的 Surface 上每帧只需一次 blit帧率从 23 提升到 31。第三个问题是行星旋转。行星每帧自转都要调用 rotozoom这个操作非常昂贵因为旋转会重新采样图像而且 Surface 尺寸可能改变。优化方案是预先按不同角度渲染好一组旋转后的贴图存入字典缓存起来运行本文还有配套的精品资源点击获取