首页 / 与其他引擎的对比
最近的邻居是 MonoGame，而不是 Unity。如果你在拿一个基于编辑器的引擎 和本引擎权衡，决定性问题不是特性 — 而是你想在窗口里还是在 类里创作场景。
本页是为了有用而不是为了讨好而写。它包含了你应该选择其他方案 的情形，因为一份不这么做的对比不值得读。
这些都是合理的选择。它们的不同之处在于各自停在哪一层。
| 项目 | 它给你什么 | 编辑器 | 内置 3D 渲染器 |
|---|---|---|---|
| SeasonEngine | 渲染器、应用外壳、2D 与 3D 控件、四种图形后端 | 没有，刻意如此 | PBR、阴影、GI、AO、TAA、天空 |
| MonoGame | 一个 XNA 形状的框架：设备、内容管线、精灵批处理、输入 | 没有 | 你自己写，或采用社区方案 |
| FNA | 一个忠实的 XNA 4 重新实现，面向移植现有作品 | 没有 | XNA 时代的效果 |
| Veldrid | 一个图形 API 抽象 — 引擎之下的那一层 | 没有 | 无；那不是它的职责 |
| Zenith.NET | 一个现代 RHI：D3D12、Metal 4 和 Vulkan 1.4 在一个 C# API 之下，带 bindless 句柄和 Slang 着色器 | 没有 | 无；那不是它的职责 |
| Prowl | 一个类 Unity 的开源引擎：.NET 10 上的纯 C#、仅 OpenGL 的渲染器、完整编辑器、资产管线、物理和音频 | 有 | PBR、CSM 阴影、烘焙光照贴图与光照探针、后处理栈 |
| Silk.NET | 到 Direct3D、Vulkan、OpenGL、WebGPU 等的绑定 | 没有 | 无；那不是它的职责 |
| Stride | 一个带场景编辑器和资产管线的完整 C# 引擎 | 有 | PBR、阴影、后处理 |
| Evergine | 范围上最接近的同行；面向工业与 XR | 有 | PBR、阴影、后处理 |
季节引擎的 Direct3D 12 和 Vulkan 后端构建在 Silk.NET 绑定之上，
.csproj 里写得很清楚。任何「C# 中的现代图形 API
访问」形式的功劳都属于 Silk.NET，假装不是如此只会招来最伤人的
纠正 — 由读过源码的人公开做出的纠正。这里提供的是
绑定之上的那四万行。
Veldrid 值得专门提一句：它把抽象问题解决得很好，它的开发已经 基本沉寂了一段时间，而且它从来没有试图成为上面那一层。如果你看过 Veldrid 并且想要本应坐在它上面的那个引擎，那大致就是本引擎 占据的位置。
Zenith.NET 是
「Veldrid 如果今天写会长什么样」的答案，而在抽象层本身上，它是
更现代的作品。它的目标基线比本引擎更新 — Vulkan 1.4
和 Metal 4 — 暴露 bindless 资源句柄、用时间线值追踪完成，
并通过
Capabilities.RayTracingSupported 和
Capabilities.MeshShadingSupported 对内联光线追踪和网格着色进行能力门控。
季节引擎那三样一样都没有：没有 bindless 路径、没有光线追踪、
没有网格着色器。
它在着色器编写上也做出了更好的选择。Zenith.NET 用 Slang 写一次 着色器。本项目手写 HLSL、GLSL、MSL 和 WGSL 作为内嵌 C# 字符串， 每个后端一个变体 — 这就是添加一个 compute 特效意味着写四份内核的原因。那是真实的成本，不是设计上的 美德，而 Slang 是今天起步的渲染器应该走的方向。
类别仍然不同，而这是两者都出现在本页的唯一原因。Zenith.NET 停在 RHI：没有场景模型、没有 PBR 材质系统、没有阴影级联、没有 GI、没有 文本渲染器、没有应用外壳。如果你想要的是在一个干净的现代抽象上 写渲染器，它比本项目的内部实现永远是更好的起点，而且如果它 更早存在，本引擎很可能就构建在那一层之上。如果你想要的是 那一层之上已经组装好的那四万行，那就在这里。
代码优先是共同前提。C# 是共同前提。两者都没有编辑器，而且谁也 不会长出编辑器。所以轴线是：在一个 3D 项目的第一天，框架 递给你什么。
MonoGame 的用户群强烈偏向 2D、像素风和复古向游戏 — 那个 谱系产出了该类型最著名的作品。那些受众不需要 DDGI 或 GTAO，而本引擎的头条特性对他们中的大多数人来说无关紧要。这里面向 的群体更窄：想要带现代光照的 3D、并且拒绝以编辑器为中心的 工作流的 C# 开发者。这是一个更小的群体。这也是今天没有任何 维护中选项的群体，这正是它值得被服务的原因。
如果你是带着现有代码从 MonoGame 过来，迁移有自己的一页： 从 MonoGame 迁移 覆盖了面向 2D 精灵、图像和文本 调用点的 SeasonXNA 兼容层、取代内容管线的东西，以及刻意不受支持的清单。
在你几乎能说出的每一条轴线上，两者都比本引擎更好：生态、工具、 文档、资产商店、招聘、主机支持，以及已经被别人解决掉的问题的 绝对数量。如果这些对你的项目比下面两件事更重要，就用它们。
| 差别 | 它换来什么 |
|---|---|
| 场景是一个 C# 类，不是一个文档 | 场景在拉取请求中做 diff 和合并。没有导入步骤、没有 GUID 注册表、没有需要保持打开的编辑器。整个项目都是文本。 |
| 引擎是你能读的源码 | 当一个通道看起来不对时，你打开文件、读内核并改掉它 — 而不是提交一个 issue 然后等发布。 |
一个被反复提及的说法值得纠正而不是重复：基于编辑器的引擎
处理不了大量实体。它们能。Unity 恰恰为此发布 DOTS 和
BatchRendererGroup，大规模作品也确实是靠它们做出来的。
站得住脚的说法关乎成本，而不是能力 — DOTS 是你围绕它重构项目的
第二种范式，而 InstancedModel 是你往里添加的一个列表。
那是可用性的差别，也是本页唯一的主张。
人们要求做这个对比，是因为两边的特性列表押韵。两个引擎都交付动态 全局光照、级联阴影、时间抗锯齿、物理天空和金属-粗糙度 材质模型。列表的重叠远大于实现的重叠，而那个差距是 本节唯一诚实的主题。
下面每一行都是两个引擎都名副其实地声称拥有的能力。右栏是 主张变得不可比的地方。
| 能力 | Unreal | 本引擎 | 实际的差距 |
|---|---|---|---|
| 动态 GI | Lumen | DDGI 探针体积 | Lumen 在一个开放世界里追踪世界 — 屏幕追踪、软件距离场、可选硬件光线、包括反射。这里是一个有界范围的辐照度探针体积：体积之外的几何采样钳制后的边界探针。对场景很好，对大地图不行。 |
| 几何规模 | Nanite | 视锥与逐级联剔除、GPU 实例化 | 没有对应物，而且不是个小缺口。这个代码库里没有任何形式的网格 LOD 系统 — 没有虚拟化几何，甚至连离散的 LOD 链都没有。你提交的三角形就是你绘制的三角形。 |
| 阴影 | 虚拟阴影贴图 | 级联阴影贴图 | CascadedShadow.MaxCascades 是 3。VSM 在整个世界范围内提供接近像素精度的阴影；三个级联在选定的范围内给你一个好看的场景，并且光照方向被量化以对抗级联抖动。 |
| 时间抗锯齿 | TSR | TAA 加 RCAS 锐化 | TSR 是一个有着多年生产环境锤炼的上采样器。这里是一个胜任的历史重投影 TAA。同一类别，不同的成熟度。 |
| 天空与大气 | Sky Atmosphere、体积云 | 程序化天空、空气透视 LUT | 本页上最接近的真实对等 — 两者都源自同一批大气散射文献。体积云是这里缺失的那一半。 |
| 光线追踪 | 硬件 RT 和一个完整的路径追踪器 | 无 | 没有光线追踪、没有网格着色器、没有 bindless 资源。没有任何参考质量模式可以核对你的光照。 |
| 动画 | Anim Blueprints、Control Rig、IK、MetaHuman | glTF 蒙皮、混合、变形目标 | 片段播放和混合存在。状态机、重定向、程序化绑定或 IK 求解器不存在。 |
Unreal 大约是一个大型工程组织三十年的工作，有已发布的 AAA 作品、主机认证和建立在其上的电影工业。这里是 232 个文件。 在渲染保真度、规模、工具、生态和实战检验上，Unreal 赢下每一行 可衡量的项目，任何暗示相反的页面都是在兜售什么。两者 出现在一起的原因是，它们没有在做同一份工作。
.cs 文件的场景 — 可以在拉取请求中 diff 和合并，没有二进制资产或 GUID 注册表| 你的项目形态 | 答案 |
|---|---|
| 照片级、开放世界，或以主机发布为目标 | Unreal。 这里没有可争论的余地。 |
| 一支有美术、关卡设计师和技术美术的团队 | Unreal。 那些角色需要编辑器和节点图，而这两样这里都没有。 |
| 过场动画、虚拟制片、建筑可视化 | Unreal。 Sequencer 和路径追踪器就是这类工作的整套工具链。 |
| 一款需要物理、VFX、音频和网络代码的游戏 | Unreal。 四个在这里缺席而不是薄弱的系统。 |
| 必须跑在浏览器里的 3D | 本引擎。 Unreal 完全无法面向 Web。 |
| 一支给桌面软件加 3D 的 .NET 团队 — 工具、数据可视化、工业视图 | 本引擎。 Unreal 对那个问题是个沉重的答案，而且它不会是 C#。 |
| 你需要自己修改渲染器内部 | 本引擎。 Unreal 的源码可得但浩瀚；本引擎小到改一个通道只需一个下午。 |
| 3D 与本地模型推理在同一进程中 | 本引擎。 今天没有 Unreal 对应物在售。 |
| 你不想要版税、席位费，只想要一个小依赖 | 本引擎 — 不过也掂量一下 Godot，它免费、更大且支持好得多。 |
压缩成一行：Unreal 是团队制作照片级游戏或电影的合适工具， 而这里是一个 C# 库，用来把一个外观现代的 3D 场景放进你正在写的 程序里。用特性清单在两者之间做选择会误导你，因为清单正是 它们看起来最像的地方，而深度才是它们不像的地方。
| 你的处境 | 更好的答案 |
|---|---|
| 你的工作主要是视觉摆放和迭代 | Unity、Godot 或 Stride。敲坐标每次都会输给拖坐标。 |
| 你在做照片级或开放世界游戏 | Unreal。两者实际差多远，见上一节。 |
| 你需要主机发布 | Unity、Godot、Unreal 或 MonoGame 的主机计划。这里没有主机后端。 |
| 你在做 2D 像素风游戏 | MonoGame 或 Godot。这里的 2D 层能用，但它不是重心，而且没有 tilemap 或物理方案。 |
| 你在移植一款 XNA 作品 | FNA。保真就是它的全部目的。 |
| 你想自己写渲染器 | 原始绑定用 Silk.NET，或者一个 RHI — 想要现代的选 Zenith.NET，想要资历的选 Veldrid。拿一个观点鲜明的引擎再替换掉它的观点，是两头都不讨好。 |
| 你需要一支非程序员团队参与贡献 | 任何基于编辑器的引擎。C# 类不是一个面向美术的界面。 |
| 你需要物理、导航网格或真正的音频混音器 | 一个拥有它们的引擎。见下文。 |
不是注意事项 — 是缺席。下面每一项都是你必须自带或 自建的东西。
随源码发布的两个应用，一个是应用演示，一个是渲染参考。 两者都没有回答「用它做的游戏长什么样」 — 那是「看起来 不错」之后的第一个问题。它是被要求最多却不存在的东西， 这一点是已知的，而且再多的渲染器细节都替代不了它。实际 有什么，参见示例。
垃圾收集器是真实存在的，假装它不存在是愚蠢的。引擎的回答是
架构性的：对象池、环形缓冲、ArrayPool 复用、
帧级节流和零拷贝纹理路径，而且代码库小到一次分配无处藏身。
论点是：成熟的引擎在间接层和抽象层上损失掉的，比 GC 的
代价更多。
上面那段是工程描述，不是证据。帧时间、每帧 Gen0 分配和 GC 停顿分布能一锤定音，而这些还没有发布。在它们发布之前， 请把它当作对代码如何写的描述，而不是对运行多快的 主张。