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