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