2026 年 7 月更新发布
如果说 6 月是在打牢地基,那么 7 月就是精细打磨每个房间。
在短短 30 天内,我们密集交付了 19 个发布版本(其中包括 2 次大版本升级),而第 20 个版本 v3.4.0 也紧接着在 8 月初顺理成章地落地。Turian Studio 正式完成了从“可用编辑器”到“让人乐在其中的生产力工具”的蜕变。
然而,7 月的故事绝不仅是一份长长的功能清单,它源于一个场景的考验。
月中时,我们用 Turian 加载了著名的 Amazon Lumberyard Bistro 测试场景 —— 包含 280 万个三角形、1,591 个子网格(submesh)、132 种材质、633 张压缩纹理,源美术资源高达 1.4 GB。结果 Turian 仅渲染了 32 个表面就直接宣告罢工。随后发生的一切 —— 格式重构、视锥剔除、阴影改版、性能分析基建,甚至包括一次大版本升级 —— 归根结底都是为了让这个庞大的场景能够顺畅加载、稳定渲染,并允许摄像机自由穿梭。
- 令人身心愉悦的 Studio 体验
- 告别素颜:游戏内 GUI 系统
- 走向成熟的渲染器
- Bistro 场景攻坚战
- 格式导入:不止于 glTF
- 跨平台支持:Windows 正式到来
- 丝滑平稳的大版本迭代
- 筑牢底层根基
- 展望未来

令人身心愉悦的 Studio 体验
6 月的编辑器是功能性的;7 月的则是舒适的。
可停靠面板
Ticket #90
这是 Studio 工作流迎来的最大突破:面板不再被固定死。现在你可以将 Hierarchy(层级)、Scene View(场景)、Game View(游戏视图)、Inspector(检查器)、Asset Browser(资源浏览器)、Profiler(性能分析器)以及 Log(日志)等所有面板进行自由拖拽、停靠、取消停靠、拆分与重新组合,定制出最符合当前项目需求的布局。
布局会在不同会话间自动保存,一次配置,全局生效。若想恢复如初,“Reset Layout”(重置布局)只需一键即可还原默认。内置的多种预设(默认、四分割、2x3、高屏、宽屏)为不同工作场景(如编辑场景、调试 UI 或分析性能)提供了快捷起点。
在底层架构上,全新的 Panel API 允许插件和扩展包注册自定义面板。编辑器的界面组合逻辑不再是写死的硬编码,未来任何新工具或可视化面板都可以作为一等公民停靠在窗口中。
欢迎面板
过去在未指定项目的情况下启动 Studio,界面只会呈现空荡荡的 Hierarchy 和一片空白的视口。现在,全新的 Welcome(欢迎)面板将迎面呈上:包含路径的最近项目列表、醒目的“新建项目”与“打开项目”按钮、当前引擎版本,以及直达官方文档、博客、更新日志、Discord、Matrix 和 Issue 追踪器的快捷链接。
它的交互与其他停靠面板完全一致 —— 可停靠、可关闭;但在未加载任何项目时作为默认主界面存在,一旦打开具体项目便会自动让出空间。
顶部栏的项目下拉菜单也同步升级。每个最近项目新增了“在新窗口中打开”选项,方便同时对比两个项目。此外,在离开存在未保存修改的项目时,编辑器会优先弹出提示。这项变更检测(dirty-check)采用了统一的内部 API,而非临时拼凑在窗口关闭事件上的特例逻辑。因此,无论是退出应用、切换项目还是开启新窗口,凡是涉及潜在工作丢失的操作都会触发相同的安全防护。

主题系统
Dark、Light、Dark High Contrast、Darcula 以及 Catppuccin —— 5 款内置主题开箱即用,可在 View 菜单中实时预览。将鼠标悬停在主题名称上即可即时查看效果,点击即可确认生效并保存。
底层的 .uitheme 资源类型使主题成为了可自由编辑的一等资源。你可以通过复制现有的主题,自由调整颜色、圆角半径以及面板边框宽度 —— 所有属性均支持在 Inspector 中实时预览并编辑。
主题支持导出与导入为独立文件,便于团队间共享统一的设计规范。同样的基础设施还掌管着字体大小、UI 缩放比例以及自定义系统字体覆盖 —— 既可在 View 菜单中进行单次临时调整,也可在 Settings 中永久设定。
拖动下方滑块,直观对比相同编辑器布局下的 Dark 与 Light 主题效果:

Output / Log 日志面板
Ticket #23
几乎所有引擎都会向 stdout 输出日志,但专业编辑器能帮你快速厘清关键信息。
全新的 Log 面板将引擎与编辑器的全部日志汇总至可停靠的控制台中,支持按日志级别(Debug、Info、Warning、Error)过滤、分类下拉筛选以及全文搜索。连续重复的相同日志会自动折叠为单条记录并附带计数器 —— 这在调试高频循环逻辑时尤为实用。错误堆栈追踪会自动解符号化并支持展开,附带可点击跳转的 文件:行号 源码链接。
现在你可以放心地将日志面板停靠在界面底部,无需担心阻挡视线,在发生异常时轻松化繁为简、精准排查。

统一设置编辑器
Ticket #88
过往 Studio 的配置分散在各处 —— JSON 文件、单个面板菜单、未在文档中说明的默认值。7 月更新带来了规范的 Settings 编辑器:它以独立标签页形式开启,拥有支持搜索的侧边栏、清晰分类的设置项(General、Editor Camera、Asset Browser、UI、Performance、Shortcuts),并支持带有未保存标记(dirty)的实时变更追踪。
设置编辑器复用了 Inspector 的反射与属性控件基础设施,因此每个配置字段都能享受到与资源属性完全相同的类型专属编辑器、合法性校验以及变更追踪。

资源浏览器与资源预览
Tickets #79, #80, #83, #81, #68, #85, #72, #84, #19, #25
本月资源浏览器迎来了三种导航视图 —— Grid(缩略图网格)、Grid+Tree(带文件夹树的网格)以及 Tree Only(完整目录树),可通过工具栏图标一键切换。面包屑导航(Breadcrumb)支持直接点击跳转上级目录,“Create”创建菜单也由过去的扁平列表重构为层级分明的分类子菜单。
网格单元格采用了固定宽度设计。即便一个文件夹内包含 600 张纹理,也会排列为整齐划一的棋盘网格,不再被长文件名撑得参差不齐。过长文件名在悬停时会显示完整名称,支持隐藏文件扩展名,且单元格大小随缩放级别动态调整。由单个导入模型解包(cook)生成的子资源(网格、材质、预制体等),可通过父瓦片上的 + 徽章展开折叠。
与此同时,资源预览缩略图功能同步上线:选中任意资源即可在 Inspector 中查看视觉预览,全面支持纹理、模型与材质。预览系统同样基于插件架构设计,开发者可轻松为自定义资源类型拓展专有预览渲染器。

快捷键绑定与命令注册表
Ticket #14
键盘快捷键系统升级为一等架构。中央命令注册表将编辑器的各项操作(Undo、Redo、Save、Play/Stop、Build Game、Next Tab 等)映射至默认按键。用户可以在 Settings 的专有编辑器中重新绑定任意快捷键、添加备选快捷键或完全解绑,并支持自动冲突检测 —— 一旦两个命令撞键,编辑器会立即高亮预警。
当前生效的快捷键会直接展示在对应菜单项旁边,无需死记硬背即可轻松掌握。

场景视图方位罗盘
Ticket #126
场景视图右上角新增了三维罗盘控件 —— 即 Blender、Unity 和 Unreal 中大家熟悉的轴向操纵器。它实时同步摄像机在世界空间下的旋转朝向,即便是对复杂场景进行了长达 10 分钟的旋转观测,也能随时明确坐标方位。
它绝非单纯的示意图。点击带标签的轴向平面,摄像机会在保持当前焦点居中的同时,瞬间平滑对齐至该轴向视线。正面图、侧视图、顶视图的切换只需轻轻一点,无需手动小心翼翼地拖拽。投影模式切换(透视 / 正交)紧随其下,一键切替。

后台任务与 FPS 信号灯
导入像 Bistro 这样的大型场景会瞬间派生上千个独立的子任务。过去的任务栏会将它们一股脑全部铺开,技术上虽然严谨,但实际体验极差。
重构后的后台任务系统将包含子任务的父任务智能收拢为单条聚合进度条 —— 展示总体完成度、已用时间以及 Cancel 按钮 —— 而各个独立子任务仍保留在内部追踪,支持随时展开与单独取消。

此外,状态栏新增了红黄绿信号灯指示的常驻 FPS 帧率计数器:60 FPS 以上显示绿色,30 FPS 以上为黄色,低于 30 FPS 为红色(阈值均可在 Settings 中自定义)。关键在于,该计数器采样的是真实帧呈现(frame present)频率而非 UI 重绘频率,因此即便编辑器在无操作时处于休眠状态,FPS 也会如实汇报,绝不会在鼠标停止移动的瞬间卡死不动。
多语言本地化
Studio 现在能够原生使用你的语言。全新的本地化系统开箱即用支持英语与巴西葡萄牙语,其框架架构具备极强的可拓展性。
这套 i18n 系统远不止文本替换那么简单:它完整支持复数规则(遵循 CLDR 规范)、消息格式插值、基于上下文的翻译消歧以及按语言环境动态切换字体 —— 这对于中日韩(CJK)、阿拉伯语或天城文等字符集的渲染至关重要。内置工具可自动从源码中提取可翻译字符串并编译为二进制字符串表,因此添加新语言仅需导入数据,无需修改任何引擎代码。
语言切换瞬时生效 —— 在 Settings 中切替语言后,整个 UI 无需重启 Studio 即可实时刷新。

告别素颜:游戏内 GUI 系统
一个连菜单都无法渲染的引擎是无法发布完整游戏的。7 月初,12 项关联 Task 集中攻坚落地,一举补齐了这一短板。
Turian 游戏现在拥有了基于 UIDoc 资源的完整游戏内 GUI 系统 —— 这是一种在 Studio 中可视化创作、在运行时动态实例化的声明式 UI 文档。九宫格(Ninepatch)面板可以在拉伸图像的同时保持边角不失真,Label 掌控文本排版,交互按钮则能将类型化事件直接派发至游戏代码中。正因为 UIDoc 属于独立资源,标题画面的调整成为了美术与设计师随改随刷的流程,再无须程序员重新编译代码。
UI 编辑器提供了一套自带节点树与样式检查器(涵盖 expand、gravity、margin、tint、corner radius、font、font size 等属性)的 WYSIWYG(所见即所得)画布。设计基于参考分辨率并支持黑边自适应缩放(letterbox scaling),确保同一套 UI 在不同宽高比的屏幕上均能完美呈现。

月中,系统进一步引入了 GameEvent 通道资源:提供了一种数据驱动的解耦方式来连接游戏逻辑(如开门、触发对话、播放音效),无需在组件间硬编码引用。UIDoc 中的按钮触发通道,订阅该通道的逻辑自动响应。Inspector 界面支持以可视化的形式绑定这些关联,体验贴合 UnityEvent。
截图验证功能也同步落地,使得游戏内 UI 布局的自动化视觉回归测试成为可能 —— 引擎可以在 Headless(无头)模式下渲染 UI 帧并与标准参考图进行像素级对比。
走向成熟的渲染器
7 月的更新让 Turian 的渲染水准完成了从“仅能成像”到“惊艳出彩”的质变。
基于图像的照明 (IBL) 与天空盒
询问任何一位 3D 美术,答案都是一致的:光影决定场景的生死。此前 Turian 仅支持解析光(方向光、点光源、聚光灯),这使得户外场景看起来生硬而平淡。
基于图像的照明(Image-Based Lighting,简称 IBL)打破了这一困局。只需导入一张 HDR 环境贴图(.hdr Radiance 格式),它就能同时充当背景天空盒与场景的主环境光源。引擎将环境光投影至 2 阶球谐函数(Spherical Harmonics)中以计算漫反射辐射度,并对预过滤的镜面反射环境贴图进行采样 —— 两者与解析光一同送入 PBR 着色器中计算。
镜面反射项在月中迎来了二次重构。最初版本复用了等距柱状纹理自身的 Mip 链作为替代,导致极点区域过度模糊、掠射角下的反射波瓣形状失真。随后该实现被替换为真正的 Render-to-Cubemap 转换,以及基于 GGX 重要性采样的逐 Mip 级别预过滤 —— 即标准的 Split-Sum(拆分求和)方法。如今低粗糙度表面反射锐利,中粗糙度下波瓣形状准确,且彻底根除了极点伪影。面向场景的 EnvironmentComponent API 无需任何改动,底层的采样质感实现了全面跃升。
最终效果:在真实 HDRI 照耀下,户外场景无需任何手动打光即可呈现出极高的信实度。单张环境贴图便提供了过去需要数十盏精心摆放的光源才能模拟出的环境、方向与反射光影细节。
拖动滑块,对比相同场景在仅使用解析光源(之前)与开启基于图像的照明(之后)的效果:

色彩管理:sRGB 与 ACES 色调映射
Ticket #27
过去的 PBR 光照计算运行在伽马空间中 —— 反照率纹理缺少 sRGB 到线性的转换,且输出阶段缺失色调映射(Tonemapping)。7 月更新将这两大痛点一举解决。
颜色纹理(反照率、自发光)现在按 sRGB 采样并在光照计算前自动转换至线性空间;法线贴图、金属粗糙度及 AO 贴图则保持应有的线性空间。整个光照管线在线性空间中高精度运行,最终输出在伽马校正前会经过 ACES 胶片色调映射(ACES Filmic Tonemapping)—— 这是实现电影级色彩还原的行业标准。
这带来了符合真实物理规律的光影表现:金属重现真实质感,暗部保留丰富细节,高光自然过渡而非死白一片。
HDR 后处理管线
Ticket #136
正确的光照赋予画面真实感,而后处理则赋予画面摄影质感。
Turian 现已搭载了光照通道之后运行的可组合 HDR 后处理栈:Bloom(泛光)(支持自定义阈值、强度与模糊半径,高光表面会像真实镜头那样发散光芒)、Color Grading(色彩分级)(采用 ASC CDL 规范的 Lift/Gamma/Gain 调色)以及 Vignette(暗角)(强度、半径、平滑度)。
其精妙之处在于控制模式。效果并非全局硬性绑定,而是寄宿于 PostProcessVolumeComponent(后处理体积组件)之上。体积既可以是全局的(以全权重作用于整个场景),也可以是局部的(绑定至节点周围的包围盒或球体)。重叠的体积会根据优先级与距离权重平滑混合,且每个效果分类均有独立开关 —— 例如局部体积可以在修改色彩分级的同时保持全局 Bloom 不受干扰。
这意味着场景氛围可以随着玩家的移动自然转变:遮阳棚下温暖且带有微弱 Bloom,走入巷弄则转为冷调低饱和 —— 无需编写任何脚本。所有参数均可在 Inspector 中实时调节并获得即时反馈。
拖动对比 Bistro 露台在后处理体积禁用(之前)与启用(之后)的效果 —— 观察灯具发光、边缘消退:

混合模式、剔除与 Alpha 遮罩
Ticket #26
材质现已全面支持 Alpha Blend 与 Additive(加算)混合模式、可配置的面剔除(Front、Back、None)以及 Alpha Mask(Cutout)透明剪裁渲染。透明物体、粒子特效、植被叶片与玻璃材质从此无需任何变通黑科技即可原生创作。
Bistro 场景攻坚战
Epic #132
每一个成熟的引擎,都需要一个能把它逼至极限的硬核场景。
Amazon Lumberyard Bistro 是图形学界的经典压力测试场景:仅室外街角就包含 280 万个三角形、1,591 个子网格、132 种材质以及总计 1.4 GB 的 633 张 DDS 纹理。这是工业级生产管线才会产出的重型资源,它将 Turian 此前暗中蒙混过关的所有瓶颈暴露无遗。
首战撞墙
第一次导入虽然提示“成功”,但场景在 1,591 个表面中仅渲染出了区区 32 个表面。
原因不在于导入器,而是渲染器内部硬编码的 MAX_SUBMESH_MATERIALS = 32 上限。提升这一上限意味着必须重构材质绑定逻辑,从而引发了场景格式的破坏性变更 —— 这正是 v3.0.0 大版本升级的由来(详见下文)。材质绑定由过去的“按子网格索引”改为了“按材质槽位(Material Slot)”。如此一来,拥有 1,591 个子网格但共享 132 种材质的模型只需占用 132 个槽位而非 1,591 个。槽位上限提升至 160,GPU 端的子网格限制被彻底取消。
瞬间,整条街道完全呈现。然而,帧率掉到了完全无法游玩的程度。

瘦身减负
Ticket #141
在优化绘制路径(draw calls)前,数据本身必须瘦身。FBX 烘焙(cook)阶段加入了顶点焊接(Vertex Welding)通道,自动共享并索引相同顶点,将高达 272 MB 的顶点缓冲区大幅裁剪,同步缩短了导入耗时。更少的 VRAM 占用、更好的 GPU 缓存命中率、更快的迭代速度。
三代剔除架构演进
Ticket #143
视锥剔除(Frustum Culling)历经了三代架构演进,每一代都基于对上一代的实测性能分析。
第一代(CPU 逐对象剔除):在 CPU 端跳过视野视锥外的整体网格。但 Bistro 场景本质上被合并为了一个巨大的网格,因此该优化完全无效。
第二代(CPU 逐子网格剔除):每帧在 CPU 端遍历检测全部 1,591 个子网格包围盒。表现有所提升,但每帧巨大的 CPU 遍历计算本身成为了新的性能瓶颈。
第三代(现行・GPU 驱动剔除 (GPU-Driven Culling)):Compute Shader(计算着色器)在 GPU 端并发检测每个子网格包围盒是否在视锥内,并将间接绘制命令直接写入 GPU 缓冲区;渲染通道随后按材质分组发出 DrawIndirect 指令。CPU 彻底摆脱了子网格遍历负担。子网格按材质预先排序,管道与绑定切换开销降至最低。
相关改动还将场景光源移入 GPU 存储缓冲区(Storage Buffer),使单场景光源上限从 8 盏猛增至 256 盏。
拒绝盲猜,用数据说话
在三次重构剔除架构后,帧率依然不够理想 —— 坦白来说,当时没有任何人真正清楚时间究竟消耗在了哪里。遮挡剔除、Hi-Z、Meshlet、LOD 似乎 headquarters 都是合理的下一步,但盲目挑选任何一项都无异于第四次凭空猜测。
因此在 7 月,我们没有贸然开展第四次优化,而是先补齐了诊断工具:在每个渲染通道(Shadow、Cull Compute、Main、Transparent)周围加入了可选的 GPU Timestamp Query(时间戳查询),并在 Studio 的 Profiler 面板中按通道精细化展示,同时扩充了 CPU 区域覆盖。Profiler 中的 gpu_time_ms 终于从过去的 CPU 估算值演进为了真正的 GPU 硬件耗时。
性能测量的回报立竿见影。我们发现了一个惊人的隐藏问题:每次打开已导入的项目时,引擎在启动阶段竟会对 1.7 GB 的纹理源文件进行全文哈希计算,只为了确认文件未发生改变!通过引入基于文件修改时间(mtime)与文件大小的快速校验路径,这一原本沉重的启动瓶颈瞬间缩短为毫秒级的 stat 校验。
逐通道 GPU 计时设为可选开关是有原因的:每通道读取时间戳会强制 GPU/CPU 同步,在非排查瓶颈期其开销超过了信息本身的价值。Profiler 面板将其收纳为复选框,与 V-Sync 和帧率上限控制并列,并在进入 Play 模式时自动记录。

大幅降低渲染开销
性能数据的指引带来了扎实而高效的优化方案:解析后的材质被全面缓存而非每次 DrawCall 都重复解析;阴影通道获得了逐级联的 Frustum Culling(避免将整个场景机械渲染 4 次);场景通道在设备支持时开启 4x 多采样抗锯齿(MSAA)—— 以超采样(SSAA)极小的开销换来了锐利平滑的边缘。
视觉沉淀与质感还原
Ticket #157
当场景终于能够流畅交互后,与 ORCA 参考渲染图 相比最后的差距在于感知层面 —— 归根结底是遮挡关系。传统的 IBL 环境光将天空光视为来自无限远,导致每个缝隙、遮阳棚下的每个隐蔽表面都接收到了满额的半球天空光。而参考图的厚重感,正是由“接触变暗(Contact Darkening)”所奠定的。
两项关键技术填补了这一视觉鸿沟:
级联阴影贴图 (Cascaded Shadow Maps):平行光阴影划分为共享同一阴影图集的 4 个级联,采用对数/均匀混合切分方案,每个级联拥有独立的 Bias 与 GPU 剔除分发。近处级联紧凑精细,呈现场景近处清晰的接触阴影;远处级联延伸至街道尽头。
屏幕空间环境光遮蔽 (SSAO):新增的深度与法线预处理通道为 SSAO 通道(附带模糊)提供数据,在几何体自遮挡处压暗环境/IBL 光照。墙角、门框、桌椅下方终于展现出紧贴地面的沉降感,而非漂浮在空中。
值得澄清的是:Bistro 场景原本被设计为夜景(主要由路灯与室内灯光照亮),而 ORCA 参考图则是明亮的白天户外。由于 SSAO 仅调制环境光项,它在夜景中的视觉贡献虽真实存在,但相比白天场景会更为收敛。间接光反弹(Bounce lighting)与局部反射已在 #157 中跟进研发。

格式导入:不止于 glTF
FBX 格式原生导入
尽管 glTF 已成为现代行业标准,但 FBX 依然是绝大多数数字内容创作(DCC)工具(如 Maya、3ds Max)及商业美术资源库的原生语言。
Turian 现已支持原生导入 FBX 文件(同时涵盖二进制与 ASCII 格式)。网格、材质(高精度映射至引擎的 PBR 金属粗糙度模型)、内嵌及外部纹理、完整节点层级均会被自动提取并转译为引擎原生资源。FBX 的场景树被完整保留为包含所有子资源的预制体(Prefab),可直接拖入场景中使用。
glTF 场景层级导入
Ticket #8
此前 glTF 导入器仅提取网格与材质,却丢弃了场景层级。7 月更新补齐了这一遗憾:导入的 glTF 与 GLB 文件现在会将节点层级完整保留为预制体,精准复原父子节点结构。拥有数十个命名部件的复杂模型不再以散乱网格的形式呈现,而是以条理清晰的预制体树导入。
DDS 纹理导入
Ticket #134
DirectDraw Surface (DDS) 文件 —— 广泛应用于 GPU 预压缩纹理的标准格式 —— 现已支持直接导入。全面覆盖从 BC1 至 BC7 的块压缩格式,并正确处理 sRGB 标识与法线贴图的 Y 轴翻转(Y-flip)。带有预压缩 DDS 纹理的资源包无需任何二次转换即可即插即用。
Git 友好型元数据架构
此前每个资源伴生的已提交 .meta 文件存在一个隐蔽的痛点:它将 GUID、资源类型、导入设置等“应当纳入 Git 版本控制的持久化创作数据”,与源哈希、文件大小、mtime(修改时间)、导入器版本等“纯粹的临时缓存数据”混杂在一起。
由于 Git 不会保留文件的 mtime,因此每次全新 git clone 后的首次导入,都会触发全盘 .meta 的重新写入 —— 仅仅是因为检出仓库就导致了大量已跟踪文件的伪变更。更糟糕的是,任何引发误写入的 bug 都会污染整个团队的 git status。
本次重构将所有缓存字段迁入了已列入 .gitignore 的 .cache/ 目录中,并以 GUID 进行索引。现在克隆并打开项目不会产生任何 .meta 变更,升级导入器版本也不会影响任何被 Git 跟踪的文件。
同期还修复了一个影响隐蔽但危害极大的小 bug:此前在 Inspector 中勾选/取消场景对象的“Active”复选框时,不会将场景标记为未保存(dirty),导致改动可能会静默丢失。
跨平台支持:Windows 正式到来
Turian Studio 现已支持在 Windows 平台上原生构建与运行,并引入了 Direct3D 12 (D3D12) 作为 Vulkan 之外的备用 GPU 后端。这是本月工程量最大的基础设施项目:涵盖修复 SDK 检测逻辑、清理特定平台的链接与文件路径假设、实现跨平台动态库加载器(Zig 0.16 的 std.DynLib 缺乏 Windows 支持),以及验证窗口创建与输入响应。CI(持续集成)现已全面覆盖 Windows 版 Studio 的编译校验,Windows 官方发布包同步包含 CLI 与 GUI 编辑器。
8 月初进一步开展了运行时加固:全面覆盖了首帧渲染无法验证的深层逻辑 —— 包括 Play 模式的编译与加载周期(通过 zig 子进程构建 libturian_play.dll 并动态加载),以及排查消除了脚本反射与代码生成中硬编码的 POSIX 路径假设。
跨平台支持绝非仅仅在不同 OS 上成功运行,更意味着引擎能够精准匹配各平台的首选图形 API:Linux 与 Windows 优先 Vulkan,Windows 备选 D3D12,并为未来在 macOS 上接入 Metal 奠定了架构基石。
丝滑平稳的大版本迭代
7 月我们交付了两次主版本升级 —— v2.0.0 与 v3.0.0 —— 两者均由实质性的破坏性变更所驱动,但用户侧的迁移过程均在几分钟内轻松完成。
v2.0.0:逐子网格材质系统
最初的 glTF/GLB 导入器仅烘焙第一个网格的第一个图元。v2.0.0 通过引入完善的逐子网格材质系统修复了这一问题:TMSH 网格格式增加了子网格表,MeshRendererComponent 将单一的 material 字段升级为 materials 数组,场景文件同步更新。完整背景请参阅 v2.0.0 发布公告。
v3.0.0:按材质槽位绑定
Ticket #140
v2 采用子网格索引绑定材质,而 v3.0.0 改为**按材质槽位(Material Slot)**绑定 —— 这使得拥有数千个子网格但共享少量材质的模型能够仅占用极少数槽位。材质上限从 32 提升至 160,GPU 端子网格限制彻底解禁。
迁移非常直观:运行 turian-cli migrate <project> 重写场景文件,并将代码中访问渲染器材质的索引从子网格编号更新为材质槽位编号即可。完整步骤请查看 v3.0.0 迁移指南。
一套让后续升级变得简单乏味的迁移框架
Ticket #137
在一个月内经历两次破坏性变更后,一个规律清晰显现:project.json 中记录的 turian_version 过去从未被校验过,且每次迁移逻辑都是临时拼凑的,缺乏统一规范的存放机制。
7 月更新建立了一套规范的版本校验与迁移框架。引擎在打开项目时会自动比对项目记录版本与引擎当前版本 —— 大版本不匹配强制提示,小版本差异可通过 Settings 开关控制。迁移逻辑以“一版本一文件”的形式置于手工维护的注册表中,每条迁移均带有幂等性提示元数据。v2 的 material_guid → material_guids 修复逻辑已被收录为该框架的首条官方迁移项。
CLI 运行器率先上线:turian-cli migrate <project> [--yes|--no] [--dry-run],完全适配 CI 无人值守环境,并提供 --dry-run 模式在改动文件前列出所有待执行迁移与手动步骤。Studio 启动时的可视化迁移对话框将在下一阶段推出。完整设计原则记录于 ADR-0012。
筑牢底层根基
并非每一项更改都是头条功能。有些是未来功能所依赖的隐形基础设施。
插件与包系统
Turian 现已搭载了包含清单、模块与运行时注册机制的插件与包系统。插件可以注册自定义菜单、停靠面板以及 Inspector 中的属性绘制器。包清单声明依赖与能力,引擎会在运行时自动从项目目录中检索并加载。这是构建未来生态系统的奠基石 —— 社区插件、美术资源包与引擎扩展均可在不触碰引擎源码的前提下无缝安装。
精简 Studio 架构 (A Thinner Studio)
Ticket #152
Studio 此前堆积了一个庞大的 services/ 目录,充斥着与 UI 毫无关系的模块(项目操作、会话状态、撤销历史、剪贴板、导入任务等)。这些逻辑已被整体抽离至 editor/ 模块,并按功能重构分组(project/、session/、assets/、build/、tasks/、shortcuts/、i18n/)。
这一重构带来了清晰的解耦边界:editor/ 完全脱离 GUI,可独立进行无界面单元测试;而 studio/ 则退居为覆盖其上的 UI 外壳。正因如此,CLI、CI 检查、MCP 服务器等 Headless 工具才能直接复用编辑器核心逻辑,无需重复造轮子(详见 ADR-0015)。
架构决策记录 (ADR)
本月诸多重大技术选定背后的沉淀思考已书面化归档:15 份 ADR 完整覆盖了包系统、依赖注入、操纵器、Play 模式、光影渲染、GPU 剔除、版本控制以及 Editor/Studio 解耦边界。
字体升级为一等资源
Ticket #109
字体文件现已纳入与模型、纹理相同的导入管线进行统一管理。字体资源支持按语言环境覆盖(对中日韩 CJK 字符渲染至关重要),并与本地化系统深度集成,实现自动切替。
构建输出、项目图标与 CI 优化
构建管线输出目录改为了可配置的 .public 文件夹,项目可设置在构建后的可执行文件窗口与任务栏中展示的自定义图标。Studio 本身也补齐了 favicon 与“关于”对话框。在 CI 方面,发布管线逻辑由 YAML 移入 Zig 编写的发布工具子命令中 —— 本地与 CI 共享同一套逻辑 —— 整个发布流水线精简缩减为两个阶段。
开源许可变更至 MPL 2.0
Turian 的开源许可证由 GPLv3 变更为了 Mozilla Public License 2.0 (MPL 2.0) —— 这是一种文件级别的 Copyleft 许可而非项目级。这意味着开发者可以基于 Turian 引擎开发并商业发布闭源的专有游戏,而针对 Turian 引擎本身的修改与改进则继续保持开源共享。这一变革直接源于社区的真实反馈,详细缘由见从 GPLv3 迁移至 MPL 2.0。
展望未来
7 月的努力将 Turian 从一个初具雏形的试作项目,打造为了一个令人身心愉悦的成熟开发环境。如今的 Studio 散发着专业生产力工具的质感 —— 可停靠面板、自定义主题、快捷键注册表、强大的 Log 面板、多语言本地化。渲染器能够输出经得起考验的画面,格式导入覆盖了两大核心标准,曾经仅能勉强渲染 32 个表面的编辑器,如今能够流畅吞吐整条重型街景。
Bistro 场景的攻坚尚未终结 —— 间接光反弹、局部反射与遮挡剔除依然在路上 —— 但它已经功不可没。每一个性能指标的飞跃,都源于面对真实复杂场景拒绝妥协的攻坚,这比任何合成基准测试都是更好的老师。
8 月的征程将在此接续:更深层次的渲染优化、动画系统、音频引擎,以及 Studio 侧的自动迁移对话框。Roadmap 路线图记录着接下来的方向。
欢迎下载最新发布版本,查阅官方文档,并加入我们的 Discord 或 Matrix 社区交流探讨。
编辑器里见!
#release#editor#engine#studio