高真实感复杂光照环境场景模拟——软件系统设计方案

1. 软件系统设计方案

1.1 软件结构特点

游戏里的 "MVC" 架构

游戏项目里的也有类似 MVC 的架构。如下图所示：

把游戏的架构分成三层：

- Game Application Layer

    - Devices: Input, Files, RAM, Time
    - OS: Language, DLL, Threads, Network
    - Game Life: Core Libs, Main Loop, Init & Shutdown

- Game Logic

    - Game State & Data Structure
    - Physics
    - Events
    - Process Manager Common Interpreter

- Game View(s)

    - Process Manager
    - Options
    - only for Human
        - Display: 3D Scene, UI, Video
        - Audio: SFX, Music, Speech
        - Input Interpreter
    - only for AI Agent
        - Stimulaus Interpreter
        - Decision System

其中游戏逻辑的输出可能是 AI ，也可能是真实的玩家。所以要对应不同的视图。

而本项目依赖的项目是 Unreal Engine，一个巨大的游戏引擎。这个工程实际关注在渲染模块。渲染模块一个
重要的设计考量是抽象各个平台的驱动接口。比如 D3D, OpenGL, Vulkan 等。这就意味着，设计必须要能够
根据平台来切换渲染接口。这还是有 “切换视图” 的概念应用。

依赖视图

依赖视图展现了软件模块之间的依赖关系。比如一个软件模块A调用了另一个软件模块B，那么我们说软件模块A直
接依赖软件模块B。如果一个软件模块依赖另一个软件模块产生的数据，那么这两个软件模块也具有一定的依赖关
系。依赖视图在项目计划中有比较典型的应用。比如它能帮助我们找到没有依赖关系的软件模块或子系统，以便独
立开发和测试，同时进一步根据依赖关系确定开发和测试软件模块的先后次序。依赖视图在项目的变更和维护中也
很有价值。比如它能有效帮助我们理清一个软件模块的变更对其他软件模块带来影响范围。

Renderer 依赖 Engine 和 RenderCore 模块。
Engine 只依赖于 RenderCore。
RenderCore 不依赖他俩。

本项目要拓展实现的模块在 Renderer 里。

泛化视图

泛化视图展现了软件模块之间的一般化或具体化的关系，典型的例子就是面向对象分析和设计方法中类之间的继承
关系。值得注意的是，采用对象组合替代继承关系，并不会改变类之间的泛化特征。因此泛化是指软件模块之间的一
般化或具体化的关系，不能局限于继承概念的应用。
泛化视图有助于描述软件的抽象层次，从而便于软件的扩展和维护。比如通过对象组合或继承很容易形成新的软件
模块与原有的软件架构兼容。

Unreal 中的渲染器类都继承自 FSceneRenderer。分为移动渲染器和延迟渲染器。本次要实现的代码在移动
渲染器中，但要参考到延迟渲染器的实现。

实现视图

实现视图是描述软件架构与源文件之间的映射关系。比如软件架构的静态结构以包图或设计类图的方式来描述，
但是这些包和类都是在哪些目录的哪些源文件中具体实现的呢？一般我们通过目录和源文件的命名来对应软件架构
中的包、类等静态结构单元，这样典型的实现视图就可以由软件项目的源文件目录树来呈现。
实现视图有助于码农在海量源代码文件中找到具体的某个软件单元的实现。实现视图与软件架构的静态结构之间映
射关系越是对应的一致性高，越有利于软件的维护，因此实现视图是一种非常关键的架构视图。

右边的目录结构即实现视图。

1.2 接口API

Unreal 引擎的代码非常庞大。我关注的接口在 Engine/Source/Runtime/Renderer/Private
目录下。其中包含了渲染器的 API。

    SceneRendering.h (FSceneRenderer, FMobileSceneRender)
    SceneRendering.cpp

    MobileShadingRenderer.cpp

    DeferredShadingRenderer.h (DeferredShadingSceneRenderer)
    DeferredShadingRenderer.cpp

移动渲染器 MobileShadingRenderer 和延迟渲染器 DeferredShadingRenderer 都
公有继承自 FSceneRenderer

class DeferredShadingRenderer : public FSceneRenderer
class MobileShadingRenderer : public FSceneRenderer

父类 FSceneRenderer 里有一个纯虚函数 Render 即子类必须实现的渲染入口

virtual void Render(FRHICommandListImmediate& RHICmdList) = 0;

2. 核心数据结构设计

延迟渲染涉及到核心数据即 G-Buffer 里存的数据，这根据实现的要求所有不同，不过至少会包括：

• 法向量
• 各种光照系数：漫反射、高光等
• 位置向量

还有其他计算的时候涉及的：

• 光源的信息
  • 光源类型：
    • 点光源：光向各个方向发散，根据距离衰减。影响范围是一个球体。
    • 聚光源：光向某个方向发散，根据与此方向的角度衰减，影响范围是一个锥体。
    • 平行光：光向各个方向发散，且只定义光源的方向，不定义光源的位置（无穷远的点光源）。
  • 光的颜色
  • 衰减系数
  • ...

3. 软件系统运行环境和技术选型说明

3.1 运行环境

项目开始时 Unreal Engine 的版本是 4.25，其运行的环境要求是：

推荐硬件

操作系统 Windows 10 64位

处理器 Intel四核处理器或AMD，2.5 GHz或更快

存储器 8 GB RAM

显卡/DirectX版本 DirectX 11或12 兼容显卡

用引擎开发

'运行引擎' 的所有要求项（自动安装）

Visual Studio版本

Visual Studio 2017 v15.6或以上（推荐）

Visual Studio 2019

性能说明

本列表列出了Epic采用的常用配置，使用虚幻引擎4的游戏开发者可以此为参考：

64位Windows 10系统

64 GB RAM

256 GB SSD（系统盘）

2 TB SSD（数据盘）

NVIDIA GeForce GTX 970

Xoreax Incredibuild（开发工具包）

Xeon六核E5-2643 @ 3.4GHz

3.2 第三方库

ADO
AMD/AMD_AGS
ANGLE
Android
...
DotNetZip
...
rpclib
xxhash
zlib

详情参见：

https://github.com/EpicGames/UnrealEngine/tree/release/Engine/Source/ThirdParty

4. 系统概念原型的核心工作机制

上次作业的分析中，我说项目的概念原型其实就是：

我们用图形API编写的程序，接受由应用程序传递的渲染数据，向驱动提交渲染命令。
所谓延迟渲染与传统渲染的区别，从这个概念原型的层次来看，就是——得到一次渲染结果，
要经过多遍渲染过程。

这次加上了实际应用 Unreal Engine API 后，系统概念原型的核心工作机制可以更具体地描述，
延迟渲染的工作流程：

• 步骤 1：渲染所有的场景几何信息到 g-buffer。一般是把每个像素对应的材质、表面信息渲染到 render target textures 里去。
• 步骤 2：对光源所影响到的几何范围内覆盖的像素，进行光照计算，期间从 g-buffer 里采样计算所需的信息。

当然，这些流程都是写在 Unreal Engine 具体的渲染器类里的。

参考引用

[1] Software Engineering: Theory and Practice (Fourth Edition),Shari Lawrence Pfleeger,Joanne M. Atlee
[2] http://c.biancheng.net/design_pattern/
[3] https://gitee.com/mengning997/se/blob/master/ppt/软件科学基础概论.pptx