update thesis drafts under 毕设

docs/plan/毕设/初稿/第一章.md

@@ -20,7 +20,7 @@
 
 渲染引擎主体部分围绕运行时系统与编辑器工作流展开。在运行时层面，项目已经建立起平台层、图形接口抽象层、资源系统、场景与组件系统、渲染主链、模型与材质系统、多光源与简单阴影、C# 脚本运行时等核心模块，能够支持基础场景的组织、加载与实时渲染。在编辑器层面，项目已经形成 Scene 视口、Game 视口、Hierarchy、Inspector、Project、Console 等主要界面，并提供对象拾取、轮廓高亮、网格显示、变换 Gizmo 以及脚本构建与重载等辅助能力，具备较完整的开发与调试闭环。
 
-体积渲染扩展部分建立在现有引擎主体之上，重点研究参与介质渲染的基本理论以及 NanoVDB 稀疏体数据在 DirectX 12 环境下的工程实现方式。其核心内容包括体积渲染基本物理量分析、体绘制方程的简化理解、光线步进流程、稀疏体数据加载与 GPU 上传、Shader 侧体数据访问、空域跳过优化和体积阴影等。当前该部分已经完成独立原型验证，正在向现有渲染引擎主线做进一步整合。
+体积渲染扩展部分建立在现有引擎主体之上，重点研究参与介质渲染的基本理论以及 NanoVDB 稀疏体数据在 DirectX 12 环境下的工程实现方式。其核心内容包括体积渲染基本物理量分析、体绘制方程的简化理解、光线步进流程、稀疏体数据加载与 GPU 上传、Shader 侧体数据访问、空域跳过优化和体积阴影等。
 
 ## 1.4 本文的主要工作
 
@@ -30,7 +30,7 @@
 2. 实现了渲染引擎运行时主体能力，完成了缓冲、纹理、资源视图、管线状态、交换链等核心图形对象封装，并在此基础上建立了渲染请求规划、场景提取和相机执行等主链流程。
 3. 实现了资源导入与管理、场景与组件组织、OBJ 模型渲染、材质系统、多光源和简单阴影等基础渲染能力，使引擎具备了较完整的场景渲染闭环。
 4. 实现了基于 Mono 的 C# 脚本系统以及编辑器工作界面，支持脚本程序集构建、脚本运行时装载、Scene/Game 视口显示、Hierarchy 与 Inspector 联动、Project 资源浏览和 Console 调试输出等功能。
-5. 完成了基于 NanoVDB 的体积渲染原型设计与实现，已经实现 `.nvdb` 数据加载、GPU Buffer 上传、HLSL 侧 PNanoVDB 访问、光线步进、HDDA 跳空和体积阴影等流程。
+5. 完成了基于 NanoVDB 的体积渲染管线，实现 `.nvdb` 数据加载、GPU Buffer 上传、HLSL 侧 PNanoVDB 访问、光线步进、HDDA 跳空和体积阴影等流程。
 
 ## 1.5 论文结构安排
 

docs/plan/毕设/初稿/第三章.md

@@ -1,6 +1,6 @@
 # 第三章 体积渲染理论基础
 
-第二章已经从渲染引擎角度说明了运行时系统、资源系统、场景组织和编辑器工作流等基础内容。本章进一步转入体积渲染本身的理论部分，重点讨论参与介质、光在介质中的衰减与散射、体绘制方程、光线步进以及稀疏体数据与空域跳过等关键概念。本章的目的不是对体积光传输进行过度抽象的数学展开，而是为后续基于 NanoVDB 的体积渲染模块设计与实现提供足够明确的理论基础。
+第二章已经从渲染引擎角度说明了运行时系统、资源系统、场景组织和编辑器工作流等基础内容。本章进一步转入体积渲染本身的理论部分，重点讨论参与介质、光在介质中的衰减与散射、体绘制方程、光线步进以及稀疏体数据与空域跳过等关键概念，为后续基于 NanoVDB 的体积渲染管线设计与实现提供充足的理论基础。
 
 ## 3.1 参与介质与体积渲染基本概念
 

docs/plan/毕设/初稿/第二章.md

@@ -4,7 +4,7 @@
 
 ## 2.1 渲染引擎的发展历程
 
-### 2.1.1 从单一绘制程序到引擎平台
+### 2.1.1 从单一程序到引擎平台
 
 早期实时图形程序往往围绕单一渲染目标构建，重点在于完成特定场景的绘制与显示，系统结构相对集中，资源组织和工具支持能力较弱。随着实时图形程序应用复杂度的不断提高，图形程序需要面对的不再只是几何绘制本身，还包括模型与纹理导入、资源管理、场景组织、材质参数管理、光照与阴影、脚本行为控制以及可视化编辑等问题。在这一过程中，渲染系统逐步从面向单次绘制任务的程序形态，演变为面向完整开发流程的引擎平台形态。
 
@@ -14,57 +14,46 @@
 
 图形硬件和图形 API 的演进推动了渲染引擎能力的持续升级。固定功能管线阶段，开发者控制的绘制流程较为有限，系统设计更偏向对既有图形功能的调用与组合。进入可编程管线阶段后，随着顶点处理、像素处理、屏幕后处理以及更复杂的光照模型逐步进入实时图形系统，材质系统、着色器管理和渲染流程组织的重要性也显著提高。也正因如此，渲染引擎开始形成更加清晰的资源层、场景层、渲染层和脚本层等架构分层。
 
-### 2.1.3 从运行时绘制到完整工作流
-
-现代渲染引擎的发展已经不再局限于运行时画面生成，而是越来越强调资源导入、场景搭建、参数调整、脚本扩展和结果验证之间的闭环关系。编辑器、资源数据库、脚本运行时和测试体系逐渐成为引擎的重要组成部分。现代渲染引擎的核心价值，已经扩展到内容组织、资源管理、工具协同和持续扩展能力等多个方面。
 
 ## 2.2 当前主流渲染引擎的特点
 
 ### 2.2.1 Unity 
 
-Unity 在实时图形与交互式应用开发中具有广泛影响力，其突出特点在于组件化对象模型、成熟的编辑器工作流以及围绕资源导入、场景管理和脚本开发建立起来的完整开发环境。Unity 以 C# 脚本为主要行为扩展方式，在对象组织、资源引用和编辑器操作方面形成了较强的一致性。近年来其渲染体系也逐步向可配置、可扩展方向发展，说明现代渲染引擎不仅关注基础绘制能力，也重视渲染管线的工程组织方式。
+Unity 在实时图形与交互式应用开发中具有广泛影响力，其突出特点在于组件化的对象模型、成熟的编辑器工作流以及围绕资源导入、场景管理和脚本开发建立起来的完整开发环境。Unity 以 C# 脚本为主要逻辑扩展方式，在对象组织、资源引用和编辑器操作方面形成了较强的一致性。近年来随着 SRP（Single Responsibility Principle）可编程管线的出现，Unity 渲染体系也逐步向可配置、可扩展的方向发展，让渲染管线的工程组织方式更加灵活自由。
+
+【插图:插一个Unity引擎图片即可】
 
 ### 2.2.2 Unreal Engine 
 
-Unreal Engine 在高质量实时渲染、复杂场景表现和大型工程工具链方面具有代表性。其整体体系强调底层 C++ 能力、高规格实时渲染效果以及可视化工具协同工作。相较于更偏轻量化的开发环境，Unreal Engine 在渲染模块、编辑器体系、资源管理和运行时工具链方面更强调系统完整性，对高复杂度实时图形项目具有较强支撑能力。其发展方向说明，高级渲染效果通常不是孤立功能，而是建立在资源、场景、工具链和渲染主链共同配合的基础之上。
+Unreal Engine 在高质量实时渲染、复杂场景表现和大型工程工具链方面极具代表性。其强调底层 C++ 能力、高规格实时渲染效果以及可视化工具协同工作。相较于更偏轻量化的开发环境，Unreal Engine 在渲染模块、编辑器体系、资源管理和运行时工具链方面更强调系统完整性，对高复杂度实时图形项目具有较强支撑能力。其发展方向说明，高级渲染效果通常不是孤立功能，而是建立在资源、场景、工具链和渲染主链共同配合的基础之上。
+
+【插图:插一个Unreal Engine引擎图片即可】
 
 ### 2.2.3 Godot 等开源引擎
 
 除商业化程度较高的主流引擎外，Godot 等开源引擎也在实时图形开发中占有重要位置。此类引擎通常更加重视开放性、可阅读性和模块化扩展能力，在场景组织、脚本系统和编辑器集成方面同样形成了较完整的工作流。虽然不同引擎在功能规模、定位和实现路线方面存在差异，但从系统构成角度看，资源、场景、渲染、脚本和编辑器的协同已经成为现代渲染引擎的普遍特征。
 
-### 2.2.4 主流引擎能力的共性
+【插图:插一个Godot引擎图片即可】
 
-综合来看，当前主流渲染引擎虽然在底层实现方式、目标平台和工具链风格上各有差异，但在整体结构上呈现出较为一致的趋势。首先，都以资源系统、场景组织和渲染主链作为运行时主体；其次，都通过脚本系统和编辑器工作流提高内容生产与调试效率；再次，都为高级渲染特性预留了较明确的扩展位置。因此，从工程角度理解渲染引擎，重点不应只放在某一个局部渲染效果上，而应放在“完整系统如何支持内容、渲染与工具协同”这一问题上。
+## 2.3 体积渲染在现代引擎中的现状
 
-## 2.3 主流引擎中体积特效的支持现状
-
-### 2.3.1 体积特效在实时图形中的应用
-
-云、雾、烟、火焰和体积光等效果已经成为现代实时图形表现中的重要组成部分。这类效果能够显著增强场景空间层次、光照氛围和视觉真实感，在游戏、数字场景展示和交互式图形应用中都有广泛需求。与传统表面渲染相比，体积特效处理的是空间中的参与介质，因此其实现通常涉及更复杂的采样、累积和光照近似问题。
-
-### 2.3.2 主流引擎中体积特效的工程特点
-
-从主流引擎的实际做法看，体积特效很少被组织为与引擎主体完全割裂的独立模块，而是通常与现有的资源系统、光照系统、材质系统、场景组织方式以及编辑器调试能力紧密结合。体积雾需要与相机和光照信息协同，体积云需要依赖体数据或程序化参数组织，体积光照则需要与阴影和后处理结果协调。这表明体积渲染在工程实现中本质上属于高级渲染扩展能力，而不是可以脱离引擎主体单独讨论的局部算法。
-
-### 2.3.3 实时体积渲染面临的主要问题
+云、雾、烟、火焰等效果已经成为现代实时渲染中的重要组成部分。这类效果能够显著增强场景空间层次、光照氛围和视觉真实感，在游戏、数字场景展示和交互式图形应用中都有广泛需求。与传统表面渲染相比，体积特效处理的是空间中的参与介质，因此其实现通常涉及更复杂的采样、累积和光照近似问题。
 
 尽管体积特效在现代引擎中已经较为常见，但实时体积渲染仍然面临明显挑战。一方面，参与介质中的吸收、散射和透射率累积会带来较高的计算开销；另一方面，体数据存储、采样精度、跳空优化和光照近似又直接影响效果质量与实时性能之间的平衡。因此，体积渲染既具有较强的理论性，也具有明显的工程实现难度。这也是本课题将其作为渲染引擎高级扩展重点展开的主要原因。
 
 ## 2.4 本课题渲染引擎的总体介绍
 
-### 2.4.1 项目定位与整体组成
+本文项目采用模块化 C++ 结构，`engine/` 为引擎核心模块，`editor/` 为桌面编辑器，`managed/` 为脚本程序集，`project/` 为示例工程与项目资源，`tests/` 为模块测试。项目已经建立起 `RHI -> Rendering -> Editor Viewport -> AssetDatabase/Library -> Mono Scripting` 的基本闭环，已经具备较明确的引擎形态。
 
-结合当前代码与工程组织方式，本文项目已经不再是围绕若干独立 sample 展开的图形实验集合，而是已经形成主体清晰的渲染引擎工作区。项目采用模块化 C++ 结构，`engine/` 负责引擎核心模块，`editor/` 负责桌面编辑器，`managed/` 负责脚本程序集，`project/` 负责示例工程与项目资源，`tests/` 负责主线模块测试。从当前主线结构看，项目已经建立起 `RHI -> Rendering -> Editor Viewport -> AssetDatabase/Library -> Mono Scripting` 的基本闭环，这说明系统已经具备较明确的引擎形态。
+从当前实现情况看，本课题的渲染引擎主体已经覆盖多个关键部分。在图形接口层，系统已维护 `D3D12`、`OpenGL` 和 `Vulkan` 三种后端；在渲染层，已经形成以 `SceneRenderer`、`CameraRenderer` 和 `RenderPipeline` 为核心的主链结构；在资源层，已经建立 `Assets + .meta + Library` 风格的 `AssetDatabase`、artifact 缓存与运行时资源装载链路；在场景与组件层，已经形成 `Scene - GameObject - Component` 的组织方式；在渲染能力方面，已经支持 OBJ 模型渲染、材质系统、多光源、简单阴影以及编辑器视口离屏显示；在脚本与工具链方面，已经具备基于 Mono 的 C# 脚本系统，以及 `Scene`、`Game`、`Hierarchy`、`Inspector`、`Project`、`Console` 等编辑器工作界面，并支持对象拾取、轮廓高亮、网格和 Gizmo 等辅助能力。
 
-### 2.4.2 当前已实现的核心能力
+【插图:插一个渲染引擎图片即可】
 
-从当前实现情况看，本文项目的渲染引擎主体已经覆盖多个关键部分。在图形接口层，系统已维护 `D3D12`、`OpenGL` 和 `Vulkan` 三种后端；在渲染层，已经形成以 `SceneRenderer`、`CameraRenderer` 和 `RenderPipeline` 为核心的主链结构；在资源层，已经建立 `Assets + .meta + Library` 风格的 `AssetDatabase`、artifact 缓存与运行时资源装载链路；在场景与组件层，已经形成 `Scene - GameObject - Component` 的组织方式；在渲染能力方面，已经支持 OBJ 模型渲染、材质系统、多光源、简单阴影以及编辑器视口离屏显示；在脚本与工具链方面，已经具备基于 Mono 的 C# 脚本系统，以及 `Scene`、`Game`、`Hierarchy`、`Inspector`、`Project`、`Console` 等编辑器工作界面，并支持对象拾取、轮廓高亮、网格和 Gizmo 等辅助能力。
+基于上述主体能力，本课题的渲染引擎实现了基于 NanoVDB 的完整体积渲染管线。包含 NanoVDB 数据读取、GPU 上传、体数据访问、光线步进、空域跳过和体积阴影等环节。
 
-### 2.4.3 当前阶段与后续扩展重点
-
-基于上述主体能力，当前项目的后续重点已经集中到体积渲染扩展上。仓库中的体积渲染原型已经围绕 NanoVDB 数据读取、GPU 上传、体数据访问、光线步进、空域跳过和体积阴影等环节开展实现与验证，并正在向现有引擎主线进一步集成。也就是说，本文后续章节所讨论的体积渲染，并不是脱离现有项目背景的单独算法实现，而是建立在当前渲染引擎主体基础之上的高级扩展能力。
+【插图:插一个体积渲染图片即可】
 
 ## 2.5 本章小结
 
-本章从渲染引擎的发展脉络出发，说明了实时渲染引擎如何从单一绘制程序演进为集资源、场景、渲染、脚本和编辑器于一体的综合平台；随后对 Unity、Unreal Engine 和 Godot 等主流引擎的典型特点进行了概括，并分析了现代游戏引擎在体积特效支持方面的共同趋势；在此基础上，又结合当前项目的真实实现情况，对本文所涉及的渲染引擎主体能力和当前阶段重点进行了总体介绍。
+本章从渲染引擎的发展脉络出发，说明了实时渲染引擎如何从单一绘制程序演进为集资源、场景、渲染、脚本和编辑器于一体的综合平台；随后对 Unity、Unreal Engine 和 Godot 等主流引擎的典型特点进行了概括，并分析了现代游戏引擎在体积特效支持方面的共同趋势；在此基础上，又结合当前项目的实现情况，对本文的渲染引擎的功能特点进行了总体介绍。
 

docs/plan/毕设/初稿/第六章.md

@@ -1,26 +1,12 @@
 # 第六章 编辑器与引擎工作流设计与实现
 
-上一章已经围绕渲染引擎运行时的核心模块展开分析，说明了底层图形抽象、资源管理、场景组织、渲染主链以及脚本系统的实现方式。在此基础上，本章进一步转向引擎的可视化工作界面与工程工作流部分，重点说明当前项目中的编辑器如何围绕场景编辑、资源浏览、参数调整、运行验证和脚本支撑等需求组织起来。对于本课题而言，编辑器是连接资源系统、场景系统、渲染系统和脚本系统的直接工作入口，也是展示整个系统工程完成度的重要部分。
+上一章已经围绕渲染引擎运行时的核心模块展开分析，说明了底层图形抽象、资源管理、场景组织、渲染主链以及脚本系统的实现方式。在此基础上，本章进一步转向引擎的可视化界面与工作流部分，重点说明当前项目中的编辑器如何围绕场景编辑、资源浏览、参数调整、脚本运行和调试输出等功能组织起来。对于本课题而言，编辑器是连接资源系统、场景系统、渲染系统和脚本系统的直接入口，也是展示整个系统功能的重要部分。
 
 ## 6.1 编辑器在引擎中的定位
 
-### 6.1.1 编辑器作为引擎工作界面
+当前项目中的编辑器由 `Application`、`EditorLayer`、`EditorWorkspace` 以及各类面板共同构成，其初始化过程直接建立在现有引擎能力之上。编辑器启动后，会依次完成窗口渲染器初始化、项目根目录设置、`ResourceManager` 与脚本运行时初始化、ImGui 后端桥接以及视口离屏渲染资源接管，随后进入逐帧更新与绘制阶段。从系统定位看，编辑器并不是独立于引擎主体之外的附加程序，而是直接复用资源系统、渲染链路、场景数据和脚本运行时能力的可视化工作界面。它承担的核心任务包括场景编辑、资源管理、渲染结果验证以及脚本与调试支撑，并通过 `Scene`、`Game`、`Hierarchy`、`Inspector`、`Project` 和 `Console` 等主要界面组织这些工作。
 
-当前项目中的编辑器由 `Application`、`EditorLayer`、`EditorWorkspace` 以及各类面板共同构成，其初始化过程直接建立在现有引擎能力之上。编辑器启动时，系统首先完成窗口渲染器初始化，随后初始化 `ResourceManager` 并设置项目根目录，在此基础上创建 `EditorContext`、初始化脚本运行时、建立 ImGui 后端桥接，并由 `ViewportHostService` 接管编辑器视口所需的离屏渲染资源。完成这些准备后，`EditorLayer` 被挂接到应用层级系统中，编辑器界面才开始进入逐帧更新与绘制阶段。
-
-从这一结构可以看出，编辑器直接复用引擎已有的资源系统、渲染链路、场景数据和脚本运行时能力。编辑器中的界面显示、视口输出和运行模式切换都以统一的上下文对象为中心展开，这使得编辑器天然具备“所见即当前引擎状态”的特点，也保证了论文中对编辑器功能的讨论能够真实反映项目的工程实现情况。
-
-### 6.1.2 编辑器承担的核心任务
-
-结合当前代码结构，编辑器主要承担以下几类任务。其一是场景编辑任务，包括场景层级浏览、对象选择、重命名、父子层级调整以及组件参数检查。其二是资源管理任务，包括 `Assets` 目录浏览、文件夹导航、资源创建、重命名、删除、移动以及导入状态反馈。其三是渲染验证任务，即通过 `Scene` 与 `Game` 两类视口把引擎渲染结果以不同用途展示出来，其中前者面向编辑过程，后者面向运行结果。其四是脚本与调试支撑任务，包括脚本程序集重建、脚本运行时重载、日志查看、错误定位以及运行模式控制。
-
-为了支撑这些任务，编辑器内部通过 `EditorContext` 对事件总线、选择管理器、场景管理器、项目管理器、撤销管理器和视口宿主服务进行统一组织。这样一来，不同面板虽然在界面上彼此独立，但在数据层和事件层是相互联通的。例如层级面板中的对象选择会同步到 Inspector 面板，Project 面板中的资源选择会切换 Inspector 的检查对象，Game 视口中的输入帧又会通过事件总线进入运行时输入系统。这种组织方式使编辑器能够围绕统一编辑上下文协同工作，形成结构完整的界面系统。
-
-### 6.1.3 编辑器与运行时的协同关系
-
-`EditorWorkspace` 是编辑器运行阶段的核心组织者。在工作区附加阶段，系统会依次注册 `MenuBar`、`HierarchyPanel`、`SceneViewPanel`、`GameViewPanel`、`InspectorPanel`、`ConsolePanel` 和 `ProjectPanel` 等主要面板，同时创建 `DockLayoutController`，加载启动场景，并挂接 `PlaySessionController`。在逐帧更新阶段，工作区负责驱动异步资源加载更新、运行模式更新以及各面板自身的刷新；在界面绘制阶段，再由菜单栏、停靠布局和各面板共同完成整套编辑器界面的输出。
-
-其中较为关键的一点，是编辑器不仅负责“编辑”，还负责把编辑状态与运行状态组织成闭环。`PlaySessionController` 在进入播放模式前会保存当前编辑态场景快照，停止播放时再恢复快照，从而把运行时验证和编辑态维护分离开来。这样既能保证 `Game` 视口中脚本逻辑、输入和运行时场景更新能够被真实执行，又能在停止运行后回到稳定的编辑状态。这一协同机制使编辑器成为引擎工作流的核心组成部分。
+编辑器与运行时之间的关系并不是简单的界面展示关系，而是围绕统一上下文形成了完整闭环。`EditorContext` 负责组织事件总线、选择管理器、场景管理器、项目管理器、撤销管理器和视口宿主服务，使不同面板之间的数据与事件能够保持联动；`EditorWorkspace` 负责在运行阶段组织菜单栏、停靠布局和各类面板的更新与绘制；`PlaySessionController` 则负责连接编辑态与运行态，在进入播放模式前保存场景快照、停止播放后恢复快照。这样一来，编辑器既能够把 `Game` 视口中的脚本逻辑和运行时场景更新真实执行出来，又能够在退出运行后回到稳定的编辑状态，因此它构成了当前渲染引擎工作流中的核心组织层。
 
 ## 6.2 编辑器界面总体布局设计
 
@@ -28,6 +14,8 @@
 
 从当前实现来看，编辑器界面主要由顶部菜单栏与运行控制区、左侧层级面板、中部双视口区域、右侧属性检查面板以及底部控制台和项目资源面板构成。各部分职责划分明确：`MenuBar` 负责主菜单与运行模式控制，`HierarchyPanel` 用于展示当前场景对象树，`SceneViewPanel` 和 `GameViewPanel` 分别承担编辑视图与运行视图显示任务，`InspectorPanel` 负责组件和资源属性编辑，`ProjectPanel` 负责项目目录与资源浏览，`ConsolePanel` 则承担日志查看与调试辅助功能。
 
+【插图: 编辑器界面整体截图】
+
 这种布局与当前项目已经具备的功能模块一一对应。由于本项目已经具备场景系统、组件系统、材质系统、脚本系统和基础运行模式切换能力，因此编辑器界面也自然围绕这些能力组织。用户在编辑器中完成的操作路径，基本可以概括为“在 `Project` 中选择资源，在 `Hierarchy` 中定位对象，在 `Inspector` 中调整参数，在 `Scene` 中观察编辑结果，在 `Game` 中验证运行结果，并通过 `Console` 反馈调试信息”。
 
 ### 6.2.2 停靠布局与空间组织方式
@@ -36,8 +24,6 @@
 
 在界面上方，`MenuBar` 除了主菜单外，还单独绘制了运行工具条。该工具条提供播放、暂停和单步执行三个核心按钮，并直接与当前运行模式状态联动。这样一来，场景编辑、运行控制和视口验证被组织在同一工作界面中，用户无需在不同程序之间切换即可完成从编辑到验证的全过程。
 
-此处建议插入图 6-1“编辑器整体界面截图”，重点展示顶部菜单与运行控制区、左侧 `Hierarchy`、中部 `Scene/Game` 双视口、右侧 `Inspector`、底部 `Console/Project` 的整体布局关系。
-
 ### 6.2.3 面板之间的联动关系
 
 编辑器界面的价值不仅在于布局清晰，更在于各面板之间形成了稳定的数据联动。`HierarchyPanel` 中的选择结果会同步到选择管理器，随后 `InspectorPanel` 根据当前选中对象展示组件信息；`ProjectPanel` 中选中的材质资源则会切换 Inspector 的检查对象类型，使其进入材质资源编辑模式；`SceneViewPanel` 中通过拾取选中的对象同样会反馈到层级面板和 Inspector；而 `ConsolePanel` 中的日志信息又能够反向服务于当前脚本和运行调试。
@@ -114,10 +100,10 @@
 
 在调试支撑方面，`ConsolePanel` 提供了日志级别筛选、折叠显示、搜索、清空、错误暂停、详情查看和源位置打开等功能。控制台不仅能够查看普通日志，还能够在播放模式中配合错误暂停机制辅助脚本调试。这样一来，脚本编译、运行验证和错误定位便能够在同一个编辑器环境中完成。
 
-此处建议插入图 6-4“Project、Inspector 与 Console 联动截图”，用于展示资源浏览、属性编辑与日志调试在同一工作流中的组织方式。
+
 
 ## 6.6 本章小结
 
-本章围绕当前项目中的编辑器与工作流实现进行了分析。可以看到，编辑器是建立在渲染引擎运行时、资源系统、场景系统和脚本系统之上的统一工作界面。在结构上，系统通过 `Application`、`EditorContext`、`EditorWorkspace` 和各类面板完成了编辑器的整体组织；在界面上，形成了菜单栏、双视口、层级面板、属性面板、项目资源面板和控制台共同构成的工作布局；在功能上，又通过对象拾取、Gizmo 交互、离屏视口、播放控制、资源导入反馈、脚本重载和日志调试等能力，把编辑、验证与调试串联成完整流程。
+本章围绕当前项目中的编辑器与工作流实现进行了分析。可以看到，编辑器是建立在渲染引擎运行时、资源系统、场景系统和脚本系统之上的统一工作界面。在结构上，系统通过各类面板完成了编辑器的整体组织；在界面上，形成了菜单栏、双视口、层级面板、属性面板、项目资源面板和控制台共同构成的工作布局；在功能上，又通过对象拾取、Gizmo 交互、离屏视口、播放控制、资源导入反馈、脚本重载和日志调试等能力，把编辑、验证与调试串联成完整流程。
 
 对于本课题后续的体积渲染扩展而言，编辑器部分的意义在于提供了稳定的验证和展示平台。无论后续体积渲染模块以何种方式接入现有渲染主链，都可以借助当前编辑器的视口、资源工作流和调试能力完成参数调整、效果观察和结果记录。因此，编辑器与工作流部分不仅体现了当前渲染引擎的工程完整性，也为后续高级渲染模块的并入提供了必要支撑。

docs/plan/毕设/初稿/第四章.md

@@ -1,74 +1,64 @@
 # 第四章 渲染引擎总体架构设计
 
-前两章已经分别给出了渲染引擎相关技术基础和体积渲染理论基础。在此基础上，本章从系统设计层面对当前项目中的渲染引擎进行说明，重点讨论引擎设计目标、总体分层方式、核心模块职责边界、模块之间的协同关系，以及体积渲染扩展在整体架构中的位置。本章的任务是把整个系统的组织方式讲清楚，为后续第5章、第6章和第7章的具体实现分析建立统一框架。
+前两章已经分别给出了渲染引擎概述和体积渲染理论基础。在此基础上，本章从系统设计层面对当前项目中的渲染引擎进行说明，重点讨论引擎设计目标、总体分层方式、核心模块职责边界、模块之间的协同关系，以及体积渲染管线在整体架构中的位置。本章的任务是把整个系统的组织方式讲清楚，为后续第5章、第6章和第7章的具体实现分析建立统一框架。
 
 ## 4.1 引擎设计目标
 
-### 4.1.1 形成完整的渲染引擎工作框架
-
-本项目的架构设计以渲染引擎为主体展开，目标是在统一框架下组织图形接口、资源管理、场景组织、渲染执行、脚本扩展和编辑器工作流等能力。这样的架构安排使系统能够围绕同一套运行时基础持续扩展，并将图形绘制、资源处理和工具能力组织在同一体系中。对工程设计类课题而言，完整框架本身就是系统价值的重要组成部分。
-
-### 4.1.2 建立稳定的基础场景渲染闭环
-
-渲染引擎的总体架构首先需要保证基础场景渲染闭环成立，即资源能够进入运行时，场景能够组织对象，相机与光照能够驱动渲染流程，最终结果能够稳定输出到窗口或视口。只有这一闭环清晰成立，模型渲染、材质绑定、多光源、阴影以及后续更高层渲染特性才有统一的承载基础。因此，基础场景渲染闭环是架构设计中的首要目标之一。
-
-### 4.1.3 兼顾运行时能力与编辑器工作流
-
-当前项目不仅包含运行时系统，也包含围绕资源浏览、场景编辑、参数调整和结果验证构建的编辑器工作流。因此，在总体架构设计中，需要同时考虑运行时执行链路和工具侧使用链路，使资源、场景、脚本和渲染结果能够在同一体系中流转。这样的结构有助于保持项目内部数据的一致性，也有助于后续论文从工程整体角度展开分析。
-
-### 4.1.4 为高级渲染特性扩展预留架构空间
+本项目的架构设计以渲染引擎为主体展开，目标是在统一框架下组织图形接口、资源管理、场景组织、渲染执行、脚本扩展和编辑器工作流等能力。这样的架构安排使系统能够围绕同一套运行时基础持续扩展，并将图形绘制、资源处理和工具能力组织在同一体系中。当前项目不仅包含运行时系统，也包含围绕资源浏览、场景编辑、参数调整和结果验证构建的编辑器工作流。
 
 渲染引擎的架构设计不仅服务于当前已完成的基础能力，也需要为后续扩展保留空间。体积渲染作为当前项目中最重要的高级渲染扩展，需要依附既有资源系统、渲染主链和编辑器验证能力接入系统。因此，在总体架构层面，需要预留新资源类型、新渲染阶段和新调试入口能够自然接入的位置，使扩展能够沿既有资源、渲染和验证链路进入系统。
 
-## 4.2 引擎总体分层架构
+## 4.2 引擎总体分层
 
 结合当前项目的代码结构和功能组织方式，本文将渲染引擎总体概括为平台层、图形接口抽象层、资源与场景层、渲染组织层以及脚本与编辑器层五个主要层级。在此之外，系统中还存在内存、线程、调试、音频和 UI 等支撑模块，但从论文主体展开角度看，上述五层构成了最核心的结构主线。
 
-### 4.2.1 平台层
+【插图:渲染引擎总体分层架构】
 
-平台层位于整个系统的底部，负责窗口、消息循环、输入接入、时间管理和文件系统访问等基础运行环境。它决定了主循环如何驱动系统更新，也决定了渲染结果最终如何呈现到屏幕上。平台层本身不直接组织场景和资源，但它为上层所有模块提供统一的执行起点。
+### 平台层
 
-### 4.2.2 图形接口抽象层
+平台层位于整个系统的底部，负责窗口、消息循环、输入处理、时间管理和文件系统访问等基础运行环境。它决定了主循环如何驱动系统运行，也决定了渲染结果最终如何呈现到设备屏幕上。平台层本身不直接组织场景和资源，但它为上层所有模块提供统一的执行环境。
 
-图形接口抽象层建立在平台层之上，用于统一封装不同图形后端的资源模型和命令执行方式。其核心作用是把设备、缓冲、纹理、资源视图、命令列表、交换链和管线状态等底层对象收敛为稳定接口，使上层系统能够围绕统一的图形资源和执行语义展开设计。对于渲染引擎而言，这一层是保持后续模块结构清晰的重要基础。
+### 图形接口抽象层  
 
-### 4.2.3 资源与场景层
+图形接口抽象层建立在平台层之上，用于统一封装不同图形后端的资源模型和命令执行方式。其核心作用是把设备、缓冲、纹理、资源视图、命令列表、交换链和管线状态等底层对象统一抽象，屏蔽不同后端的差异，使上层系统能够围绕统一的图形资源和执行语义展开设计。
+
+### 资源与场景层
 
 资源与场景层负责回答“系统中有哪些内容”以及“这些内容如何进入运行时”两个问题。资源部分承担模型、纹理、材质、着色器和场景文件等工程资源的导入、缓存和装载职责，场景部分则负责对象层级、组件挂接和运行时内容组织。通过这一层，工程目录中的资源可以被转化为可参与渲染和逻辑更新的场景内容。
 
-### 4.2.4 渲染组织层
+### 渲染组织层
 
-渲染组织层位于资源与场景层之上，负责把场景状态整理为可执行的渲染流程。它的职责并不在于保存内容本身，而在于围绕当前相机、光照和输出目标，对可见对象、渲染阶段和表面资源进行统一规划。这样一来，渲染过程就不再是临时的逐对象绘制，而是能够形成结构清晰的主链执行框架。
+渲染组织层位于资源与场景层之上，负责把场景状态整理为可执行的渲染流程。围绕当前相机、光照和输出目标，对可见对象、渲染阶段和表面资源进行统一规划。这样一来，渲染过程就不再是临时的逐对象绘制，而是能够形成结构清晰的主链执行框架。
 
-### 4.2.5 脚本与编辑器层
+### 脚本与编辑器层
 
 脚本与编辑器层更接近开发工作流。脚本系统为运行时对象提供行为扩展入口，编辑器则为场景编辑、资源管理和渲染结果验证提供可视化工作界面。这一层并不脱离引擎主体独立存在，而是建立在已有资源、场景和渲染能力之上，使系统从“能够运行”进一步扩展到“能够组织工作流和验证结果”。
 
-## 4.3 核心模块职责划分
+## 4.3 核心模块划分
 
-从当前项目的功能组织方式看，引擎主体的核心模块可以归纳为 `RHI`、`Resources / AssetDatabase`、`Scene / Components`、`Rendering`、`Scripting` 和 `Editor` 六个部分。它们之间的区别不在于是否都与渲染相关，而在于各自承担的职责边界不同。
+从当前项目的功能组织方式看，引擎主体的核心模块可以归纳为 `RHI`、`Resources / Assets`、`Scene / Components`、`Rendering`、`Scripting` 和 `Editor` 六个部分。
 
-### 4.3.1 `RHI`
+### `RHI`
 
 `RHI` 模块承担底层图形接口抽象职责，负责统一不同图形后端的资源对象和命令执行语义。它解决的是“底层如何与 GPU 交互”的问题，是整个渲染引擎的图形基础设施。
 
-### 4.3.2 `Resources / AssetDatabase`
+### `Resources / Assets`  
 
 资源模块负责源资源记录、导入产物生成、缓存管理和运行时资源定位。它解决的是“工程资源如何稳定进入引擎”的问题，是内容进入运行时之前的组织基础。
 
-### 4.3.3 `Scene / Components`
+### `Scene / Components`
 
 场景与组件模块负责运行时对象的层级组织与能力挂接。它解决的是“运行时内容如何表达”的问题，为渲染系统、脚本系统和编辑器提供统一的对象模型。
 
-### 4.3.4 `Rendering`
+### `Rendering`
 
 渲染模块负责把场景状态转换为阶段化的渲染执行过程。它解决的是“图像如何被生成”的问题，是场景内容通向最终画面的核心组织层。
 
-### 4.3.5 `Scripting`
+### `Scripting`
 
 脚本模块负责托管逻辑与原生运行时之间的桥接。它解决的是“对象行为如何扩展”的问题，使运行时系统具备更灵活的逻辑组织能力。
 
-### 4.3.6 `Editor`
+### `Editor`
 
 编辑器模块负责围绕场景、资源、脚本和渲染结果建立可视化工作界面。它解决的是“系统如何被编辑、观察和验证”的问题，是当前项目工程完整性的重要体现。