为什么选择季节引擎

一个带现代特性集的 C# 渲染器，一套 API 横跨六个平台，源码树小到 你能读到你正在调试的那部分。MIT 许可，没有编辑器，没有资产 管线，没有运行时费用。

它存在，是因为一个特定的选项在别处不存在：一个维护中的、纯 C#、 无编辑器的引擎，带当代渲染器。那条线之下是绑定 — 很优秀的绑定 — 你拿到一个设备和一张命令列表，剩下的四万行 自己写。那条线之上是带编辑器的引擎，一个 3D 窗口要花掉你一种 项目格式、一条导入管线和一次大安装。季节引擎是中间的那一层： 渲染器完成了，应用外壳完成了，代码留给你读。

一套 API，四种后端，六个平台

你针对 Season.Controls 和 Season.Rendering 编写代码。后端由目标框架 决定，而不是由你的代码决定。

窗口、输入、存储和字体同样如此 — 各自有一个接口和 Season/Platforms 下的逐平台实现。你的 应用项目完全不引用任何平台命名空间。这一边界如何被 强制、目前在哪里泄漏，参见 跨平台隔离。

渲染器是现代，而不是极简

「小引擎」通常意味着前向渲染、一张阴影贴图和一个 Lambert 项。 本引擎交付的，是那些否则你要花一年去做的技术。

其中每一项都是一个你可以通过公开的 RenderQuality 和 FrameSchedule API 检查、禁用或替换的 compute 或光栅通道。功能总览列出了 已发布、部分和缺失的内容，全程使用同样的徽章。

许多对象，声明而非绘制

没有 Draw 调用可写。你声明一个控件， 引擎负责批处理、剔除和排序。一个 InstancedModel 就是一个持有一列变换的 控件，所以一片动画单位的田野，就是一个你往里添加的列表。

var crowd = new InstancedModel { ModelName = "Assets/robot.glb" };

for (int i = 0; i < count; i++)
    crowd.Instances.Add(new MeshInstanceTransform
    {
        PosX = x, PosY = 0f, PosZ = z,
        AnimationClip = walk,   // clip index
        AnimationTimeOffset = Random.Shared.NextSingle() * 2f
    });

AddControl(crowd);

这里值得做的对比，是与基于编辑器的引擎中的替代方案。Unity 当然能达到高实体数量 — 通过 DOTS，一种有着自己的内存 模型、你多半要围绕它重构项目的第二种范式。本引擎用普通 C# 就给你那份中有用的一份，无需采纳第二种范式。

每个领域一个实现

大多数引擎在积聚选项。本引擎拒绝选项，而拒绝本身 就是设计。

好处是：有一条代码路径要理解、有一条要优化、有一条可能 出错。代价是：如果你的资产是 FBX，你就转换它们；如果你的 目标设备没有 Vulkan，就没有可降级的回退。两者都是真实的， 两者都在与其他引擎的对比里。

场景是一个 C# 类

没有场景文件，没有预制体，没有 .meta 附属文件， 也没有 GUID 注册表。一个面板构造它的控件，而一个控件就是 一个带属性的对象。

internal class Island : Panel
{
    internal Island()
    {
        AddControl(new Model
        {
            Name = "Assets/island.glb",
            PosX = 0f, PosY = 0f, PosZ = 0f,
            Width = 40f
        });
    }
}

这个主张比听起来小，好处比听起来大。它意味着你的场景在拉取 请求中做 diff。它意味着一次合并冲突是 C# 里的合并冲突， 而不是二进制资产里的。它意味着你在任何其他 C# 代码里会写的 同一个循环、条件或辅助方法在这里都管用，因为没有另一种 创作语言要跨越。

小到可以读完

引擎是 232 个 C# 文件，大约 119,000 行，MIT 许可。着色器是 拥有它们的特效类里的内嵌字符串，所以没有着色器构建步骤、 你的构建里没有离线编译器，也无需在一个 .hlsl 文件与调度它的代码之间保持同步。

那个规模才是真正的特性。当环境光遮蔽看起来不对时，你打开 Season/Rendering/Effects/Gtao.cs，读内核， 然后改掉它。你不必提交 issue 然后等发布。类带有很长的 解释性注释 — 魔法数字背后的推理就在数字旁边 — 这也是 本文档大部分内容的来源。

依赖少而刻意： Silk.NET 用于 D3D12 和 Vulkan 绑定，SharpGLTF 用于 glTF 解析，GtkSharp 用于 Linux 窗口，还有一个 MSDF 字体图集 包。没有插件市场可被绑定，也没有遥测需要关闭。

在有趣的层可扩展

内置特效使用的是你也会用的同一个公开 API。TAA、泛光、GTAO 和 DDGI 都是通过 FrameSchedule.RegisterCompute 注册的 ComputeEffect 子类。没有特权内部 路径，所以你写的特效与已发布的那些拥有完全相同的 能力 — 包括读取场景颜色、深度和速度，以及发布一个供帧的 其余部分消费的具名纹理。

实际上，这也让调试很便宜：每张中间纹理都有名字，而一个 Sprite2D 按名字绘制纹理。参见 compute 特效。

以及本地 AI，因为它是同类问题

在桌面应用里内置一个 ONNX 或 GGML 模型，会遇到与内置 渲染器同一类问题：版本漂移、原生依赖，以及一套难以 打包的 CUDA 栈。AI 层的存在，是为了把它变成一个已解决的 构建配置而不是一个研究项目，并且遵循与渲染器相同的 规则 — 如果硬件做不到，特性体面地拒绝而不是崩溃。

本地 AI 层解释了今天有什么可用，并且对 生活在本仓库之外的部分保持诚实。

版本 0.2.0，以及这意味着什么

引擎在 1.0 之前，版本号不是谦虚。API 在版本之间变动， 一些特性是 Windows 优先，而且有几个平台目标的测试比别的 更充分。本站文档明确标注状态，而不是把意图描述成 能力。

如果这里的某页没有携带其中之一，那是因为它上面的每样 东西都已发布。

从哪里开始