背景

前段时间面试被问过几次 PBR 的问题，遂写个博客梳理下，下次面试就不用再找资料了（不是x。也是对基础光照计算的一个梳理吧。

在传统的光照模型中，光会被分为环境光、漫反射和镜面反射三个部分。环境光是在没有明确光照但并非伸手不见五指的环境下，物体接收到的微弱光照的总和。漫反射是粗糙表面无规则向各个方向反射的光，而镜面反射是光滑表面向入射光沿法线对称方向反射的光。每个部分会进行单独的计算，并最终累加获得最终的光照结果。

PBR

基于物理的渲染算法（Physically Based Rendering），是当前光栅化渲染架构下广泛使用的基础渲染算法，足够支持基本材质的渲染需求。常用商业引擎如 unreal 和 unity 的默认渲染效果都是 PBR 渲染或基于此的扩展。当然不同的引擎、不同的硬件情况、不同的效果需要，PBR 的具体实现算法会有一些不同，但核心算法是相通的。这里的 PBR 使用的是 Learn OpenGL 和 Unreal Engine 中的算法和实现。

关于

本来计划写一篇博客梳理整个渲染流程，但写着写着就发现一篇博客根本没法囊括我所有想要梳理的东西，所以就只能分成很多篇来写啦。这篇主要是准备写一下相关的硬件设施，即 CPU、GPU 和显示屏在这整个渲染流程中所起的作用，他们之间的通信方式，以及他们分别对渲染流程的影响。

CPU

CPU 主要负责一些数据的预处理。这些处理可以由开发者全权掌握。首先，CPU 会从文件或代码中获得需要渲染的内容，如模型的顶点位置信息、贴图坐标、法向量等信息。根据用户/程序员的输入小方块相对世界坐标的位置，相机的各项信息，纹理的图片文件，以及其他任何相关信息。在软件的运行过程中，CPU 会逐步将对应的数据存入 buffer（显存）中，并指定其 ID，以方便 GPU 读取。

背景

在图形学和计算机视觉的学习中，总是会看到大名鼎鼎傅里叶变换，但学了以后仿佛又没再用过了，搞不明白也仿佛完全不影响后续的学习，因此学了几次我都完全没明白。在最近又双叒叕学到这个名词以后，我终于决心把它一次性折腾个明白，顺便写一篇博客给以后的自己复习。当然傅里叶变换背后有一整套数学逻辑，且涉及傅里叶变换的其实都属于数字图像处理这一范畴，而这其中的复杂内容可以单独成课的。因此我这里只大略的涉及了它在图形图像方面应用的一些理论和逻辑（本来想深入研究，但是实在看不懂 QAQ 数学不是这点篇幅可以深入的）。考虑到数字信号本身就是基于数学人工生成的信号，在数学上的本质就是函数表达式，且本文的重点还是倾向于图形学，因此后文中信号、函数等名词使用可能非常混乱 = _ =。

背景

水体效果简直是新人 TA 练手的绝佳项目，简单有简单的写法，难有难的写法，网上教程还又多又杂，上手也很方便。而我也恰巧需要一个城市内河流的水效果，所以就准备写一写练手啦。不过后来由于一直对效果不太满意，且 5.0 迁 5.3 的时候出现了很多奇怪的 bug，所以就半途而废了= =。最后项目中计划还是使用 UE 自带的水体效果，不过总之这次尝试还是对让我对水的实现多了很多了解。

水的效果总体而言分为水面、水下和中间分隔的部分。水面部分主要是水体波纹，光线折射和反射，物体周围的涟漪以及水面的泡沫。水下部分一般是对包含了深度雾，焦散等。中间分隔的部分则包含了屏幕分隔以及水线效果。效果见 B 站。

背景

最近要做爆破仿真，所以开始带薪学习 Chaos 破碎系统（欸嘿）。总体而言感觉目前 Chaos 还是一个不怎么完善的系统，很多功能都很难以使用，尤其是如果想在运行状态下对一些参数进行动态修改。感觉每次尝试都心惊肉跳，生怕它出现什么理论上不该出现的现象。

我们的需求是希望爆破体可以动态添加，完成一次爆破以后，在不重置整个场景的基础上重置这个破碎体，需要的时候可以进行再次爆破。但在 5.0 中并没有破碎体重置的函数，也没找到各种动态设置的能力，因此也只能看看源码中是否有相关解法了。不过总体而已跌跌撞撞还是大概搞明白了一些东西，也是我第一次必须从 UE 源码中找问题的答案。这个解法未必是最合适甚至未必是完全正确的，只是目前测试下来可以使用的一种解法。总之就是如果后续有碰到这种需求，也可以给做个参考叭。

关于怎么创建破碎体、怎么爆破等等，网上已经有非常非常非常多的教程了，所以这里不再赘述。总之就是基于 Static Mesh 创建 GeometryCollision，将 GeometryCollision 放置在场景中，再使用 master field 爆破。当所有东西都预制在场景里时，整个流程十分顺滑，但当我们希望所有东西都动态添加时，就不是那么回事了。

背景

这段时间大量接触了unreal 5 的后处理相关内容，踩了不少奇奇怪怪的坑，且 unreal 的文档也非常混乱，很多地方不测试根本没法知道实现效果是怎么样的，因此就开贴记录留念一下。由于项目相关的原因，我们不能在大世界手动添加后处理volume，只能使用蓝图的后处理组件进行相关开发，因此此处主要讨论后处理组件相关内容。同时我也并不负责美术工作，因此那些具体效果的实现、相关参数和材质也并不包含在这里。我们当前使用的 UE 版本是 5.0.3，因此本文仅依据后处理在 5.0.3 中的表现。

关于后处理

后处理，其实可以称为渲染后处理，是在 3D 场景已经渲染完成以后再对成果进行处理，从而实现一些场景整体的效果。在较为底层的 OpenGL 实现中，后处理可以通过将渲染结果存为 2D 贴图存入 frame buffer，再使用各种图像处理算法在 shader （着色器）中对该贴图进行处理。在 unreal 中，后处理可以通过后处理体积（volume）或在蓝图中添加后处理组件实现。它们是 unreal 提供的用于实现后处理的特殊类型的组件，包含了很多常用的后处理相关的参数，并且可以添加后处理材质。

关于计划

在都柏林读书也一年了，寻思趁着留学生活的尾巴，在爱尔兰好好走一走。因为身在都柏林，东海岸的地方大多在平时周末的时候跑过了，所以这次旅行的主要就在西海岸溜达。迫于没有驾照，所有的公交不可达的景点都被排除在了计划之外。不过住宿和饮食总体来讲不算节约，且时间安排也以舒服为主。同时，本人虽然毫无户外经验，但又菜又爱玩，且随身携带户外经验丰富的大佬一只，也有准备户外防雨外套和防滑鞋，因此行程中有参杂大量非景点打卡的徒步活动。十月的爱尔兰刚刚进入旅游淡季，但天气又还没进入多雨的冬天，因此总体还是比较适合到处溜达的。这篇游记谨用于记录这次旅游中那些值得记忆的零零碎碎。

背景

矩阵与向量

在图形学中，我们使用矩阵来进行一系列坐标处理，包括物体的平移、旋转、缩放，以及物体从三维空间到二维平面的转化。这些处理的数学基础是矩阵和向量的乘法。这里可以把 $n$ 维的列向量看作 $n$ 行一列的矩阵，使用矩阵乘法的逻辑和同样是 $n$ 行的矩阵相乘。这样可以得到一个新的 $n$ 行一列矩阵，即一个新的 $n$ 维的列向量（如公式 1.1 所示）。由此我们可以使用矩阵将一个向量转变成另一个向量。在坐标变换处理中，我们可以将点的坐标表示为列向量，并用矩阵进行坐标变换。这里我们使用右手坐标系，即 x 向左，y 向上，z 向外。

$$\begin{bmatrix} a_1 & a_2 & a_3 & a_4 \\ b_1 & b_2 & b_3 & b_4 \\ c_1 & c_2 & c_3 & c_4 \\ d_1 & d_2 & d_3 & d_4 \end{bmatrix} * \begin{bmatrix} x \\ y \\ z \\ w \end{bmatrix} = \begin{bmatrix} x' = a_1*x + a_2 * y + a_3 * z + a_4 * w \\ y' = b_1*x + b_2 * y + b_3 * z + b_4 * w \\ z' = c_1*x + c_2 * y + c_3 * z + c_4 * w \\ w' = d_1*x + d_2 * y + d_3 * z + d_4 * w \end{bmatrix} \tag{1.1}$$

时隔两年重新把小博客捡起来了。补完了咕咕了两年的软件架构，并且准备开一些新坑。

感觉自己这几年真的变化很大。当初小博客刚刚建立时，敲命令行都有点怂，总觉得没有图形界面就不安全。而现在已经习惯于使用各种命令进行简单的调试和处理，甚至觉得图形化界面好麻烦。以前特别讨厌写报告，总是很难把自己的想法很合适的表达出来，每次写报告都耗时又痛苦。但经历了某校啥作业都得写个报告的残忍培训，现在已经可以熟练的把想法转换成文字了。不过以前讨厌调配置文件现在还是讨厌（笑。

设计风格和设计模式

设计风格和设计模式这两个概念对于初学者（本菜鸡）而言还是比较容易混淆的，尤其是中文里两个词语并没有很明确的体现出他们的区别。这两者的共同点在于，它们都是为软件的设计提供一种可以复用的模板，且在同一项目中可以搭配使用不同的风格/模式。而这两者的区别在于，设计风格是较为宏观的架构设计，而设计模式则更偏向于代码设计。

• 设计风格（style）：较为宏观的设计，一般对应软件架构层面，一般会有对应架构图。
• 设计模式（pattern）：如 23 种设计模式，一般对应代码层面，一般会有对应样例代码。