Bloom
需要预先学习：
1. Bloom 原理
Bloom（辉光）是 HDR 渲染的经典后处理效果：场景中的亮部向周围"渗光"，形成柔和的光晕。看夜空中的路灯、显示器上的高光，人眼与镜头都会看到这种光晕——光线在眼球晶状体/镜头内部散射，把亮部的能量摊到了周围。
实现的思路很直接，三步：
- 提取亮部：从 HDR 画面中取出超过亮度阈值的部分；
- 模糊：把亮部图模糊成光晕；
- 合成：模糊结果叠加回原图。
1.1 为什么必须用 HDR
亮度阈值要区分"亮"与"不亮"，只能在 HDR 空间做。LDR 画面里所有像素都被截断在 1.0，无法区分"亮度 1.0 的灰"和"亮度 100 的太阳"——两者提取出来一模一样。HDR 帧缓冲（色调映射）保留了超过 1.0 的亮度信息，阈值才有意义。
2. 实现步骤
2.1 1. 渲染 HDR 场景
场景渲染进浮点帧缓冲（色调映射 中的 hdrFBO），光源亮度可以超过 1.0，例如点光源给 vec3(10.0) 的强度。这是整个 Bloom 流程的输入。
2.2 2. 提取亮部（Bright Pass）
片段着色器采样 HDR 纹理，亮度超过阈值的部分原样输出，其余输出黑色：
// 亮部提取 shader
#version 330 core
out vec4 FragColor;
in vec2 TexCoords;
uniform sampler2D hdrBuffer;
uniform float threshold; // 亮度阈值，通常 1.0 附近
// 亮度：按人眼感知加权的亮度公式（Rec. 709 系数）
float luminance(vec3 color)
{
return dot(color, vec3(0.2126, 0.7152, 0.0722));
}
void main()
{
vec3 color = texture(hdrBuffer, TexCoords).rgb;
float brightness = luminance(color);
// 超过阈值的部分保留，且随亮度平滑过渡（乘系数避免硬切边）
float contribution = max(brightness - threshold, 0.0) / max(brightness, 0.0001);
FragColor = vec4(color * contribution, 1.0);
}2.3 3. 高斯模糊（Ping-Pong 帧缓冲）
对亮部图做高斯模糊（Gaussian blur）。二维高斯核可以拆成两个一维高斯核：先横向模糊一遍，再纵向模糊一遍，效果等价但采样数从 降到 。两遍之间用两个帧缓冲来回切换（ping-pong）：
// 一维高斯模糊 shader（横向/纵向由采样偏移方向控制）
#version 330 core
out vec4 FragColor;
in vec2 TexCoords;
uniform sampler2D image;
uniform bool horizontal; // true 横向模糊，false 纵向
// 9 tap 高斯权重（sigma 较大时数值）
const float weight[5] = float[](
0.227027, 0.1945946, 0.1216216, 0.054054, 0.016216
);
void main()
{
vec2 texelSize = 1.0 / textureSize(image, 0);
vec2 offset = horizontal ? vec2(texelSize.x, 0.0)
: vec2(0.0, texelSize.y);
vec3 result = texture(image, TexCoords).rgb * weight[0];
for (int i = 1; i < 5; ++i)
{
result += texture(image, TexCoords + offset * i).rgb * weight[i];
result += texture(image, TexCoords - offset * i).rgb * weight[i];
}
FragColor = vec4(result, 1.0);
}// ping-pong：在两个帧缓冲之间交替模糊
bool horizontal = true, firstIteration = true;
for (unsigned int i = 0; i < 10; ++i) // 迭代次数越多光晕越扩散
{
glBindFramebuffer(GL_FRAMEBUFFER, pingpongFBO[horizontal]);
glUniform1i(glGetUniformLocation(blurShader, "horizontal"), horizontal);
// 第一次采样亮部图，之后采样上一次模糊的结果
glBindTexture(GL_TEXTURE_2D, firstIteration ? brightTexture
: pingpongTexture[!horizontal]);
renderQuad();
horizontal = !horizontal;
firstIteration = false;
}2.4 4. 合成
最后把模糊后的亮部叠加回 HDR 原图，再做色调映射（色调映射）：
// 合成 shader：原图 + Bloom 光晕
#version 330 core
out vec4 FragColor;
in vec2 TexCoords;
uniform sampler2D scene; // HDR 原图
uniform sampler2D bloomBlur; // 模糊后的亮部
uniform float bloomStrength; // 光晕强度
void main()
{
vec3 color = texture(scene, TexCoords).rgb;
vec3 bloom = texture(bloomBlur, TexCoords).rgb;
color += bloom * bloomStrength; // 线性空间直接相加
FragColor = vec4(color, 1.0);
}注：合成必须在线性空间做加法（伽马校正），所以流程是"合成 → 色调映射 → 伽马编码"。如果先色调映射再叠加，HDR 信息已经丢失，光晕会失真。
3. 优化
3.1 降采样模糊
高斯模糊的分辨率越高越贵。Bloom 光晕是低频信息（大面积的柔和渐变），完全可以在低分辨率下计算：先把亮部图降到 1/2 或 1/4 分辨率再模糊，光晕更"散"且开销大减，最后升采样回原分辨率合成。降采样本身也相当于一次模糊，迭代次数可以相应减少。
3.2 mipmap 金字塔模糊
UE 的做法：把亮部图逐级降采样生成 mipmap 链，再从低 mip 逐级升采样叠加回上一级。一次生成 mipmap + 一次升采样循环，就得到平滑的大范围光晕，每级只需一次全屏绘制，比多次 ping-pong 更省。
3.3 自适应阈值
固定阈值的问题：画面整体偏暗时亮部提不出来，偏亮时又全屏光晕。自适应 Bloom 根据画面平均亮度动态调整阈值（平均亮度来自 HDR 纹理的 mipmap 顶层，见 色调映射 的曝光控制），让效果在不同场景下稳定。
| 优化 | 原理 | 收益 |
|---|---|---|
| 降采样模糊 | 低频信息低分辨率算 | 模糊开销降到 1/4 以下 |
| mipmap 金字塔 | 降采样即模糊，升采样合并 | 少一半绘制次数 |
| 自适应阈值 | 阈值跟随平均亮度 | 效果稳定，不依赖场景调参 |
| 分离核 | 二维高斯拆两个一维 | 采样数从 降到 |
Bloom 是 色调映射 流水线的自然延伸：HDR 提供了超过 1.0 的亮度信息，Bloom 把它提取出来变成光晕，色调映射再把压缩后的画面交给 伽马校正 输出。三者合起来就是现代渲染器"从物理亮度到屏幕像素"的完整链路。
相关推荐
2026-08-29
CSM级联阴影
需要预先学习： 阴影 ShadowMap与PCF、PCSS CSM 级联阴影 ShadowMap与PCF、PCSS 中实现了单张阴影贴图：一张正交投影的深度图罩住整个场景。它有一个根本性的问题——分辨率分配与视觉需求不匹配。CSM（Cascaded Shadow Maps，级联阴影贴图）把视锥按深度切成多段，每段单独渲染一张阴影贴图，让近处获得高分辨率、远处用低分辨率，是实时渲染中大范围场景阴影的标准方案。 分辨率困境 透视投影下，屏幕空间里"近大远小"：近处的物体占满屏幕的大片像素，远处的物体挤在屏幕的一角。而阴影贴图是均匀的——正交投影把整个场景等分进固定数量的纹素。于是： 近处：屏幕上一大片像素对应的场景区域，在阴影贴图里只占几个纹素，阴影边缘糊成一片块状锯齿； 远处：阴影贴图的大半纹素被远方的场景占用，但它们在屏幕上只占几行像素，分辨率被浪费。 提高贴图分辨率只能缓解，不能解决：要让近处阴影清晰，需要的分辨率高到远处完全用不完；照顾远处，近处又回到锯齿。正确思路是按需分配——把阴影贴图拆成多张，近处的贴图只覆盖视锥近...
2026-09-08
法线贴图与TBN矩阵
需要预先学习： 纹理 纹理映射 Phong模型与Blinn-Phong模型 凹凸感的来源 Phong模型与Blinn-Phong模型 的光照计算只依赖一个输入描述表面形状：法线（normal）。一个表面看起来是平的还是坑坑洼洼的，本质上取决于法线在表面上如何变化——砖墙缝隙处法线突然翻转，凹陷处法线朝向内倾，人眼把这些明暗变化解读为"凹凸"。 要让一面砖墙真的有凹凸，最直接的办法是建出缝隙的几何：每个砖块、每条沟壑都用三角形描述。代价是三角形数量爆炸——一面墙几十万三角形，剔除总结 与 前向渲染与延迟渲染 里讨论的所有开销跟着翻倍。而仔细想想，这些三角形只是提供了"法线在像素间变化"这一件事。 法线贴图（normal mapping）的思路：几何保持平滑（低多边形），把逐像素的法线存进一张纹理，着色时采样它代替插值法线。凹凸感来自法线变化，而不是几何变化——一张图就能骗过光照计算。 方案 三角形数量 细节层级 代价 几何建模凹凸 极多 顶点级 顶点处理、带宽、内存 顶点...
2026-08-29
前向渲染与延迟渲染
需要预先学习： Phong模型与Blinn-Phong模型 全局光照与局部光照 帧缓冲 PBR 前向渲染（Forward Rendering） 前向渲染（forward rendering）是 着色与渲染管线 描述的标准流程：对每个物体，用一套顶点着色器 + 片元着色器完成变换与光照，结果直接写入颜色缓冲。 基本流程 前向渲染中，光照发生在片元着色器里：片元拿到位置、法线、材质后，遍历场景中的每一个光源，逐个累加光照贡献： // 伪代码：前向渲染的片元着色器 vec3 lighting = vec3(0.0); for (int i = 0; i < lightCount; i++) // 遍历所有光源 { lighting += calcLighting(fragPos, normal, albedo, lights[i]); } FragColor = vec4(lighting, 1.0); 思路直接：每个片元、每个光源算一遍。于是总光照成本大致是： O(物体数×光源数×...
2026-07-30
着色器
需要预先学习： 着色与渲染管线 缓冲对象与顶点 GLSL 语言与着色器 着色器（shader）是运行在 GPU 上的小程序，它接管渲染管线中某些阶段的处理工作。在前一篇笔记中，你把顶点数据放进了 VBO，但 GPU 还不知道怎么处理这些数据——着色器就是告诉 GPU “该做什么” 的程序。 OpenGL 的着色器使用 GLSL（OpenGL Shading Language）编写，它是一种类 C 语言的着色器语言。一个着色器程序的入口点是 main 函数，和 C++ 一样。 数据传递 着色器之间通过特定的变量关键字来传递数据： in：从上一个阶段接收数据 out：向下一个阶段发送数据 uniform：从 CPU 端传入的全局变量，对所有顶点或片元都相同 数据类型 GLSL 有 C 语言风格的类型系统，并提供了面向图形的内置类型： 类别 类型 基础类型 int、float、bool、double 向量 vec2、vec3、vec4（float 向量）、ivec2~ivec4（int 向量）、bvec2~bvec4（bool 向量） ...
2026-08-29
ShadowMap与PCF、PCSS
需要预先学习： 阴影 ShadowMap 阴影 中讲过 ShadowMapping 的原理：把深度测试搬到光源位置再做一遍，用"光源视角记深度 + 摄像机视角比深度"的两遍框架判断片元是否被遮挡。这篇笔记把它落地成 OpenGL 代码，并在这个基础上实现 PCF 与 PCSS。 基本原理回顾 ShadowMapping 分两遍渲染： Pass 1：从光源渲染场景，只记深度。 平行光配正交投影，把场景画进一张深度贴图（depth map）——只写深度缓冲，不写颜色。深度贴图记录了从光源看过去每个方向上最近的表面距离。 Pass 2：从摄像机正常渲染场景。 着色时把片元变换到光源的观察空间，投影得到它对应的贴图坐标与深度，与贴图中记录的最近深度比较：片元更远，说明它前面有别的表面挡光，在阴影中。 // 伪代码：Pass 2 中的阴影判断 float d_frag = to_light_view(fragment.pos).z; // 片元在光源视角下的深度 float d_map = shadow_map.sample(uv); ...
2026-08-31
GLSL 语法
需要预先了解： 着色器 程序结构 在着色器中你已经见过一段完整的 GLSL 代码。这篇笔记把它的语法规则系统梳理一遍。一个 GLSL 程序由版本声明、全局声明（变量、结构体、函数）和入口函数 main 组成： #version 330 core layout (location = 0) in vec3 aPos; // 全局变量声明 out vec4 FragColor; // 输出变量 void main() // 入口函数 { gl_Position = vec4(aPos, 1.0); } 几个语法层面的硬性规则： #version 声明必须出现在文件第一行（前面只允许空白和注释），且要先于任何其他声明 入口函数是 main，返回 void，不接受参数 每条语句以分号结尾，注释风格与 C 相同（// 与 /* */） 注：#version 330 core 中的 core 表示核心模式（core profile）。...
