从零手搓简化版Lumen：六个月实时全局光照学习路径

如果你看过 UE5 在 Demo 里展示 Lumen 的洞穴场景，应该会对那种几乎无需烘焙、光照实时变化的画面印象深刻。想从零手搓一个简化版 Lumen，听起来像是一个工程量巨大的目标，但它并不是不可拆解的。这篇文章把 6 个月完成 Lumen 第一帧画面的学习路径拆成六个阶段，覆盖 OpenGL / Direct3D / Vulkan / Metal 四条 API 路线下的选型、环境配置、核心概念和关键代码示例。无论你是刚学完图形学基础的学生，还是想深入实时渲染的工程师，都可以把这份路线当作一份可执行的学习地图。

1. 为什么要手搓 Lumen：从“用引擎”到“理解引擎”

1.1 Lumen 到底解决了什么问题

Lumen 是 UE5 中的一套动态全局光照和反射系统。传统光照方案通常依赖烘焙：把静态场景的光照信息预先计算到 Lightmap 里，运行时直接采样。烘焙方案的问题在于，场景中任何物体的移动、灯光颜色的变化、时间系统的切换，都需要重新烘焙，否则光照结果就和场景不匹配。

Lumen 的核心思路是把“全局光照”从预计算变成实时计算。它不依赖硬件光追也能做到不错的动态全局光照效果，即使开启硬件光追，也只是作为某些阶段的加速手段。Lumen 大致由下面几个关键部分组成：

• Screen Space Tracing（屏幕空间光线追踪）：从当前帧画面中寻找光照遮挡和反射信息。
• Mesh Distance Fields（网格距离场）：用 SDF（有符号距离场）表示场景几何，解决屏幕外光照信息缺失的问题。
• Surface Cache（表面缓存）：把场景表面按层级缓存为低分辨率光照探针，方便快速查询间接光。
• Radiance Cache（辐射缓存）：对光照结果做时间和空间上的缓存与插值。

所以，手搓 Lumen 不是要“复刻 UE5 源码”，而是把上述每一项背后的图形学原理用自己能控制的代码实现一遍。

1.2 手搓 Lumen 的收益与边界

自己做一版简化 Lumen，最大的收益不是得到一个可以商业化的渲染器，而是建立完整的实时渲染知识体系。你会被迫搞明白这些平时被引擎隐藏起来的细节：

• 延迟渲染和多张 GBuffer 到底存了什么。
• SDF 体素化和 Sphere Tracing 的加速原理。
• 射线从像素出发，如何从屏幕空间过渡到场景空间。
• 为什么需要 Surface Cache，它和传统 Lightmap 的区别是什么。
• 帧间复用、时空降噪在全局光照里是如何起作用的。

这件事也有明显边界。6 个月完成“第一帧画面”是一个合理目标，但不要期待 6 个月能写出 UE5 级别的工业级全局光照。合理的定义是：在你自己搭的渲染器里，能看到间接光在物体之间反弹、反射大致轮廓正确、画面有全局光照感。

1.3 四套图形 API 该怎么选

OpenGL、Direct3D 12、Vulkan、Metal 都是图形 API，但学习时机和适用场景不同。

• OpenGL：上手最快，教程最多，适合用来理解渲染管线流程。但 OpenGL 在驱动层面的抽象比较老旧，调试大型现代渲染器时约束较多。
• Direct3D 12：Windows 平台独占，接近底层，适合在 Windows 上做性能优化和 GPU 调试。要求你对资源屏障、命令列表、描述符堆有清晰理解。
• Vulkan：跨平台，Windows、Linux、Android、部分 macOS 场景都能用，现代图形 API 的代表。学习曲线陡，但具备通用性。
• Metal：苹果生态专用 API，如果你在 macOS / iOS 上开发，Metal 是唯一合理选择。很多渲染思路和 Vulkan / D3D12 类似，但 API 风格更简洁。

建议路径是：如果完全没接触过图形 API，先用 OpenGL 或直接选择 Vulkan 作为主攻；如果决定走工业级渲染方向，Vulkan 或 Direct3D 12 是更值得深入的选择。下面所有代码示例围绕 OpenGL 和 Vulkan 展开，因为这两套 API 的资料最丰富，示例也最容易在 Windows / Linux 环境复现。

2. 6 个月学习路线：分阶段推进到第一帧

“从零手搓 Lumen 第一帧”最大的敌人是目标太大，无法拆解。下面这个路线把 6 个月拆成六个阶段，每个阶段都有明确的产出物。这个拆法参考了东汉书院在图形渲染方向的课程推进方式，整体思路是“先跑通管线，再深入算法，最后合并成第一帧”。

阶段	时间	核心目标	阶段产出物
阶段一	第 1 个月	图形 API 基础和渲染管线	能画出一个带深度测试的 3D 三角形/立方体
阶段二	第 2 个月	延迟渲染与 GBuffer	4 张 GBuffer 纹理，能正确输出到屏幕
阶段三	第 3 个月	SDF 距离场与空间加速结构	对场景生成简单 SDF，能完成 Sphere Tracing
阶段四	第 4 个月	屏幕空间光线追踪	从像素发射光线，得到屏幕空间间接光
阶段五	第 5 个月	Surface Cache 与 Radiance Cache	低分辨率缓存 + 插值，间接光能跨帧稳定
阶段六	第 6 个月	整合与调优	稳定输出一帧含间接光的 Lumen 风格画面

2.1 阶段一：图形 API 基础（第 1 月）

第一周先不碰复杂光照，循环执行“创建窗口 -> 初始化图形上下文 -> 创建着色器 -> 绘制三角形”。不管选 OpenGL 还是 Vulkan，都要理解交换链（Swap Chain）、渲染管线（Pipeline）、顶点缓冲、Uniform 传递这四件事。

这一阶段的产物不是“会画三角形”，而是形成对图形 API 资源管理的肌肉记忆。比如 Vulkan 中 Queue Family、Swap Chain Image、Semaphore 之间的关系，如果一开始不弄清楚，后面每加一个新功能都会变成灾难。

// 以 OpenGL + GLFW 为例的初始化骨架 // 文件路径：src/main.cpp #include <glad/glad.h> #include <GLFW/glfw3.h> #include <cstdio> int main() { glfwInit(); glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); GLFWwindow* window = glfwCreateWindow(1280, 720, "LumenLearn", nullptr, nullptr); if (!window) { printf("Failed to create window\n"); glfwTerminate(); return -1; } glfwMakeContextCurrent(window); gladLoadGLLoader((GLADloadproc)glfwGetProcAddress); while (!glfwWindowShouldClose(window)) { glClearColor(0.1f, 0.1f, 0.15f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glfwSwapBuffers(window); glfwPollEvents(); } glfwTerminate(); return 0; }

2.2 阶段二：延迟渲染与 GBuffer（第 2 月）

Lumen 这种现代全局光照方案几乎都是基于延迟渲染或簇式前向渲染。手搓的时候建议直接做延迟渲染，因为它把几何信息拆成多张贴图，后续做屏幕空间追踪时会非常方便。

这一阶段需要输出至少四张 GBuffer：

• 反照率贴图（Albedo）。
• 世界空间法线贴图（Normal）。
• 金属度 / 粗糙度贴图（Metallic / Roughness）。
• 深度贴图（Depth）。

不要急着在这个阶段实现复杂 PBR，只要能把信息存到纹理里，再通过全屏 Pass 原样采样回屏幕，就算达成目标。延迟渲染的关键是使用glFramebufferTexture2D或 Vulkan 的 Render Pass Attachment 把不同数据写到多个颜色附着上。

2.3 阶段三：SDF 距离场与空间加速结构（第 3 月）

SDF 是 Lumen 用来弥补屏幕空间不足的关键技术。屏幕空间光线追踪只能看到屏幕上已经绘制的内容，当你需要计算屏幕外或背面的光照信息时，就必须有一个“场景几何的紧凑表达”，这就是 SDF 的主要用途。

第三个月不需要做成 UE 那种自动体素化任意网格的规模，可以先从简单数学体开始，比如球体、盒子、圆柱的组合。用 Sphere Tracing 算法渲染，理解“光线每次前进的距离由当前位置到场景最近表面的距离决定”这一核心思想。

// SDF 示例着色器片段，理解 Sphere Tracing 的核心 float sdSphere(vec3 p, float r) { return length(p) - r; } float mapScene(vec3 p) { // 在原点上方放置一个半径为 1.0 的球体 return sdSphere(p - vec3(0.0, 1.0, 0.0), 1.0); } float traceSDF(vec3 origin, vec3 direction) { float t = 0.0; for (int i = 0; i < 128; i++) { vec3 p = origin + direction * t; float dist = mapScene(p); if (dist < 0.001) break; t += dist; if (t > 10.0) break; } return t; }

2.4 阶段四：屏幕空间光线追踪（第 4 月）

拿到 GBuffer 后，就可以从每个像素出发，沿反射方向或间接光方向在屏幕空间找相交点。屏幕空间光线追踪的核心过程是：

1. 把像素位置还原到世界空间。
2. 确定追踪方向。
3. 在世界空间逐步前进，并把每一步的位置重新投影回 NDC 和 UV。
4. 比较当前位置的深度和深度贴图上的深度，判断是否相交。

这部分的难点在于步长控制。步长太大容易穿过薄片物体，步长太小性能暴跌。可以先用固定步长跑通，后续再引入 HZB（层次 Z 缓冲）加速。

2.5 阶段五：Surface Cache 与 Radiance Cache（第 5 月）

屏幕空间追踪能给出直接可见区域的间接光，但屏幕外信息需要额外的缓存。Surface Cache 的思路是把场景表面离散成层次化的像素块，把直接光照结果烘焙/缓存到这些小块上，然后在光线追踪时快速查询。Radiance Cache 则用于对亮度辐射做空间插值，避免每个像素都追踪大量光线，从而大幅降低噪声。

这个阶段最容易出现的结果是“画面糊”。因为缓存分辨率不够、插值权重不对、更新频率太低都是常见问题。建议先用最简单的 Uniform 网格缓存，确保光照能量分布合理，再考虑层级化稀疏缓存。

2.6 阶段六：整合输出 Lumen 风格第一帧（第 6 月）

最后一个月把前面所有模块串起来。得到第一帧的判定标准是：

• 画面中有至少一个动态光源。
• 光线在漫反射表面之间产生可感知的反弹。
• 屏幕边缘或屏幕外区域仍有间接光出现，证明 SDF 回退生效。
• 画面虽然可能有噪声或模糊，但整体亮度关系正确。

先跑通，再谈质量。很多项目在这个阶段会因为“画面不美观”而不断纠结，但更重要的指标是渲染流程是否完整。

3. 学习工程环境准备

3.1 工具链

推荐使用 C++17 / C++20，配合 CMake 管理工程。图形 API 初始化部分用 GLFW 做窗口和输入管理，数学库使用 GLM，图像加载使用 stb_image。如果走 Vulkan，还需要准备 Vulkan SDK，包含验证层和调试工具。

调试工具方面，推荐三个：

• RenderDoc：免费开源的图形调试器，可以逐帧查看 Draw Call、纹理、着色器输入输出，是排查渲染问题的第一神器。
• Nsight Graphics：NVIDIA 提供的深度优化工具，适合分析 GPU 瓶颈。
• Vulkan Configurator / vulkaninfo：检查 Vulkan 设备、实例、层和扩展是否正常。

3.2 解决 WSL Ubuntu GPU 识别但 OpenGL CPU 软渲染

这是热词里提到的高频问题：在 WSL 2 的 Ubuntu 里，glxinfo能识别到 NVIDIA GPU，但实际渲染器字符串显示为llvmpipe。这意味着 OpenGL 请求没有被硬件加速，而是被 Mesa 的软件渲染路径接管了。

首先要确认系统里安装了 WSL 专用的 GPU 驱动。Windows 侧应该安装支持 WSL 的 NVIDIA 驱动，Ubuntu 侧通常会通过/usr/lib/wsl/lib暴露相关库。

# 在 WSL Ubuntu 中检查 OpenGL 渲染器 glxinfo | grep "OpenGL renderer" # 如果显示 llvmpipe，继续检查是否有 vk 支持 vulkaninfo --summary # 查看 WSL 自带的驱动库 ls /usr/lib/wsl/lib/

常见处理方式：

• 确认 Windows 驱动版本已更新，且支持 WSL 的 CUDA / 图形转发。
• 在 Ubuntu 安装mesa-utils、libgl1-mesa-dri，但更关键的是确保 Mesa 能加载 WSL GPU 的 vendor 库。
• 如果 OpenGL 始终软渲染，可以暂时把主渲染 API 切换到 Vulkan。WSL 2 对 Vulkan 的支持通常比 OpenGL 更完整，而且能在 Vulkan 上完成 Lumen 的全部实验。
• 在 WSL 下运行时，不要设置LIBGL_ALWAYS_SOFTWARE=1，这是强制软件渲染的标志。

从学习渲染器的角度看，与其花大量时间修 WSL 的 OpenGL 转发问题，不如直接使用 Vulkan 作为主 API，再配合 RenderDoc 在 Windows 侧截帧。

3.3 初始化最小工程

一个适合学习 Lumen 的最小工程结构如下：

LumenLearn/ ├── CMakeLists.txt ├── shaders/ │ ├── gbuffer.vert │ ├── gbuffer.frag │ ├── sstrace.comp │ └── final.frag └── src/ ├── main.cpp ├── Core/ │ ├── Application.cpp │ ├── Window.cpp │ └── Shader.cpp └── Renderer/ ├── GBuffer.cpp ├── SDFScene.cpp └── ScreenSpaceTrace.cpp

CMake 配置可以参照下面这个骨架：

cmake_minimum_required(VERSION 3.20) project(LumenLearn LANGUAGES CXX) set(CMAKE_CXX_STANDARD 20) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 根据你的实际环境使用 find_package 或 FetchContent find_package(glfw3 REQUIRED) find_package(Vulkan REQUIRED) find_package(glm REQUIRED) add_executable(LumenLearn src/main.cpp src/Core/Window.cpp src/Core/Shader.cpp src/Renderer/GBuffer.cpp ) target_link_libraries(LumenLearn PRIVATE glfw Vulkan::Vulkan glm ) target_compile_definitions(LumenLearn PRIVATE GLM_FORCE_DEPTH_ZERO_TO_ONE)

4. 手搓 Lumen 之前必须掌握的核心概念

4.1 G-Buffer 延迟渲染

延迟渲染把所有物体先“画进”多张 GBuffer 纹理，再在屏幕空间统一做光照计算。好处是把场景几何与光照解耦，光源数量增多时，光照 Pass 的代价不会线性增长。

Lumen 的屏幕空间追踪直接依赖 GBuffer 里的世界坐标、法线、深度信息。所以手搓 Lumen 第一步必须是稳定、正确的 GBuffer。这里“正确”的判定标准是：在屏幕上采样 GBuffer 贴图，看到的法线方向、深度远近和场景是匹配的。

4.2 SDF 有符号距离场追踪

有符号距离场是把空间位置映射到“到最近物体表面的距离”的场。正值表示在物体外部，负值表示在内部。SDF 的好处是让光线追踪有了“自适应步长”：离表面远，走大步；离表面近，走小步。

Lumen 使用 Mesh Distance Fields 而不是传统三角形网格做追踪，因为 SDF 可以高效判断射线与大量静态几何的相交情况。手搓时可以先从sdSphere、sdBox、sdCapsule这些基础 SDF 开始，再尝试组合多个 SDF，最后研究把三角网格体素化成 SDF 的方法。

4.3 屏幕空间全局光照

屏幕空间全局光照从当前像素出发，在已经被渲染出来的画面里寻找光照贡献来源。它最大的特点是“看得到才有光”，没有出现在屏幕上的几何不会参与计算。

因此，它天然适合做近距离软阴影、接触阴影和屏幕内反射，但不适合处理屏幕外的间接光照。这也是为什么 Lumen 需要 SDF 和 Surface Cache：它们负责“填补屏幕空间之外的信息”。

4.4 表面缓存 Surface Cache

Surface Cache 把场景表面划分成很多小区域，每个区域保存一个低精度的光照状态。Lumen 会先对这些表面做一次粗略的直接光计算，把结果写入 cache，之后的光线追踪直接查询这些 cache 数据，而不是每次都做完整光照。

手搓时，可以先实现一个简化版：把场景里的几何体按照 UV 或世界空间网格贴上低分辨率“光照纹理”，然后每帧更新一次。像素最终着色时，命中缓存就采样缓存颜色，这样可以明显减少光线追踪的噪声和计算量。

4.5 Radiance Cache 辐射缓存

Radiance Cache 比 Surface Cache 更抽象，它在场景空间中放置若干 Cache Point，每个点保存周围入射光辐射的近似。新的着色点查询附近 Cache Point 做插值，而不是自己重新追踪大量光线。

理解 Radiance Cache 有助于理解 Lumen 在下探到复杂场景时如何保持性能。实际实现时，可以先不做完整的 Radiance Cache，用一个简单的“上一帧结果 + 时域混合”来模拟缓存效果，再逐步升级。

5. 实战：输出你的第一帧间接光

下面用 OpenGL + GLSL 为例，展示一个最小的“GBuffer + 屏幕空间追踪 + SDF 回退”流程。Vulkan 版本思路一样，只是 API 层代码更长。

5.1 项目结构

这个实战项目不需要 6 个月课程的完整工程，只需要验证屏幕空间追踪和 SDF 回退的效果。

LumenMini/ ├── CMakeLists.txt ├── shaders/ │ ├── gbuffer.vert │ ├── gbuffer.frag │ └── sstrace.frag └── src/ ├── main.cpp └── GBuffer.cpp

5.2 生成 GBuffer

第一帧必须包含场景几何信息。下面的片段着色器把法线和反照率写进两个颜色附着。

// 文件路径：shaders/gbuffer.frag #version 460 core layout(location = 0) out vec4 outAlbedo; layout(location = 1) out vec4 outNormal; layout(location = 2) out vec4 outMetallicRoughness; in vec3 vNormal; in vec2 vUV; uniform vec3 uAlbedo = vec3(0.8, 0.2, 0.2); void main() { vec3 normal = normalize(vNormal) * 0.5 + 0.5; outAlbedo = vec4(uAlbedo, 1.0); outNormal = vec4(normal, 1.0); outMetallicRoughness = vec4(0.0, 0.7, 0.0, 1.0); // metallic = 0, roughness = 0.7 }

顶点着色器需要把模型空间坐标变换到世界空间，同时输出法线：

// 文件路径：shaders/gbuffer.vert #version 460 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; layout(location = 2) in vec2 aUV; uniform mat4 uModel; uniform mat4 uViewProj; out vec3 vNormal; out vec2 vUV; void main() { gl_Position = uViewProj * uModel * vec4(aPos, 1.0); vNormal = mat3(uModel) * aNormal; vUV = aUV; }

5.3 矩阵传递与 glUniformMatrix4fv

很多初学者在设置 Uniform 矩阵时遇到“矩阵没有生效”的问题。核心原因通常有两个：一是没有在设置前glUseProgram，二是 GLM 默认列主序，与 OpenGL 期望一致，如果错误地传入GL_TRUE做转置，矩阵就会错乱。

// 文件路径：src/main.cpp（核心片段） GLuint shader = loadShader("shaders/gbuffer.vert", "shaders/gbuffer.frag"); glUseProgram(shader); glm::mat4 model = glm::mat4(1.0f); glm::mat4 view = camera.getViewMatrix(); glm::mat4 proj = camera.getProjMatrix(); glm::mat4 viewProj = proj * view; GLint locModel = glGetUniformLocation(shader, "uModel"); GLint locViewProj = glGetUniformLocation(shader, "uViewProj"); glUniformMatrix4fv(locModel, 1, GL_FALSE, glm::value_ptr(model)); glUniformMatrix4fv(locViewProj, 1, GL_FALSE, glm::value_ptr(viewProj));

可以看到GL_FALSE表示不转置，因为 GLM 已经用列主序把矩阵放进内存了。在 Vulkan 里，因为 NDC 深度范围不同，还需要额外设置GLM_FORCE_DEPTH_ZERO_TO_ONE，更值得留意。

5.4 屏幕空间追踪着色器

屏幕空间追踪的核心工作：从当前像素沿某个方向步进，每一步把世界坐标重新投影回屏幕，然后用深度比较判断是否命中。

// 文件路径：shaders/sstrace.frag #version 460 core uniform sampler2D uDepth; uniform mat4 uViewProj; uniform vec2 uScreenSize; in vec2 vUV; out vec4 fragColor; vec3 reconstructWorldPos(float depth, vec2 uv) { vec4 ndc = vec4(uv * 2.0 - 1.0, depth * 2.0 - 1.0, 1.0); vec4 world = inverse(uViewProj) * ndc; return world.xyz / world.w; } void main() { float depth = texture(uDepth, vUV).r; vec3 worldPos = reconstructWorldPos(depth, vUV); vec3 normal = texture(uNormal, vUV).xyz * 2.0 - 1.0; vec3 dir = normalize(reflect(normalize(worldPos - uCameraPos), normal)); vec3 hitPos = vec3(0.0); bool hit = false; float t = 0.1; for (int i = 0; i < 64; i++) { vec3 samplePos = worldPos + dir * t; vec4 clip = uViewProj * vec4(samplePos, 1.0); vec3 ndc = clip.xyz / clip.w; vec2 uv = ndc.xy * 0.5 + 0.5; if (uv.x < 0.0 || uv.x > 1.0 || uv.y < 0.0 || uv.y > 1.0 || ndc.z > 1.0) break; float sceneDepth = texture(uDepth, uv).r; float sampleDepth = ndc.z * 0.5 + 0.5; if (sampleDepth < sceneDepth + 0.01 && sampleDepth > sceneDepth - 0.01) { hit = true; hitPos = samplePos; break; } t += 0.05; } if (hit) { vec3 hitNormal = texture(uNormal, uv).xyz * 2.0 - 1.0; float nl = max(dot(hitNormal, normalize(uLightPos - hitPos)), 0.0); fragColor = vec4(texture(uAlbedo, uv).rgb * nl, 1.0); } else { // 没有命中屏幕空间，让 SDF 回退处理 fragColor = vec4(0.0); } }

这段代码省略了法线纹理声明和相机位置 Uniform，你需要在工程里补充uNormal、uAlbedo、uCameraPos、uLightPos。它展示的是屏幕空间追踪的典型结构，适合作为第一版参考。

5.5 结合 SDF 回退：解决屏幕外光照信息缺失

当屏幕空间追踪没有命中时，需要回退到 SDF 追踪。下面用一个球体 SDF 场景作为简化示例。

// 文件路径：shaders/sdf_fallback.frag（核心片段） uniform vec3 uCameraPos; float sdSphere(vec3 p, float r) { return length(p) - r; } vec3 sdfScene(vec3 p) { float d1 = sdSphere(p - vec3(0.0, 0.0, 0.0), 2.0); if (d1 < 0.001) { return vec3(d1, 1.0, 0.0); // 返回距离和材质 id } return vec3(10.0, 0.0, 0.0); } vec3 sdfIndirectLight(vec3 origin, vec3 direction) { float t = 0.0; for (int i = 0; i < 128; i++) { vec3 p = origin + direction * t; vec3 res = sdfScene(p); float d = res.x; if (d < 0.001) { // 假设灯光在右上方向，做简易 NdotL float nl = max(dot(normalize(vec3(1.0, 1.0, 0.5)), -direction), 0.0); return vec3(0.8, 0.5, 0.3) * nl * 0.5; } t += d; if (t > 20.0) break; } return vec3(0.0); }

这个 SDF 回退能保证屏幕外的几何也能通过距离场近似查询到间接光。虽然和 UE5 的 Mesh Distance Field 相比还非常原始，但已经具备了“屏幕空间追踪失败后仍能获得场景信息”的能力。

5.6 运行与验证

编译运行后，观察画面中是否出现以下现象：

• 靠近墙壁的物体表面能看到带颜色的反光。
• 物体背光面不再完全是黑色，而是有微弱的反弹光。
• 相机旋转时，间接光会随场景动态变化，而不是固定不变。
• 屏幕边缘或屏幕外没有直接光照的地方，SDF 回退产生了微弱的光照。

如果这些现象出现，说明第一帧“Lumen 风格间接光”已经跑通了。

6. 高频问题排查清单

问题现象	常见原因	解决思路
WSL Ubuntu 里 GPU 被识别但 OpenGL 仍用 llvmpipe 软渲染	Mesa 驱动没走 WSL GPU 转发	更新 Windows 驱动，检查 /usr/lib/wsl/lib，必要时改用 Vulkan
glUniformMatrix4fv 设置后矩阵没生效	未绑定 Program / 传了 GL_TRUE 转置	先 glUseProgram，GLM 矩阵使用 GL_FALSE
屏幕空间追踪远处没有命中	步长太小导致 ray 走不出屏幕 / 深度比较逻辑错误	增大步长或做自适应步长，确认深度范围是 [0,1]
Vulkan 验证层报错	未开启物理设备扩展 / 描述符集布局不匹配	按报错逐条检查，禁用未使用扩展
SDF 回退导致画面全是噪点	采样距离场次数太少 / 没有做时域累积	增加迭代次数，做帧间混合
Surface Cache 画面模糊	缓存分辨率过低	提高缓存分辨率或改为层级化缓存
OpenGL 线段宽度大于 1 不生效	驱动支持的线宽范围有限	改用三角带或几何着色器绘制 Debug 线
屏幕空间追踪在物体背面失效	屏幕空间没有背面几何信息	用 SDF 或 Surface Cache 做回退

6.1 WSL 环境下 OpenGL 软渲染

这个问题在热词搜索里频率很高。如果你的glxinfo显示llvmpipe，先尝试：

export LIBGL_ALWAYS_INDIRECT=0 glxinfo | grep "OpenGL renderer"

如果仍然是llvmpipe，大概率是 WSLg 没有正确加载 GPU 驱动。可以尝试在 Windows 侧更新 GPU 驱动并重启 WSL。但更稳妥的方案是直接切换 Vulkan，因为学习 Lumen 不需要绑定某个具体 API，Vulkan 在 WSL 下的兼容性通常更好。

6.2 glUniformMatrix4fv 的常见误区

很多人在工程里写了大量glUniformMatrix4fv，但帧画出来完全不对。最常见原因是把矩阵转置参数写成了GL_TRUE。GLM 默认生成的矩阵是列主序，OpenGL 期望的也是列主序，所以一定要传GL_FALSE。另外，Uniform 的位置查找最好在 Program 链接后立即完成，不要每帧重复查找。

6.3 屏幕空间追踪的深度比较

深度范围不统一是最隐蔽的问题。OpenGL 默认 NDC 深度范围是[-1, 1]，纹理里的深度值通常被映射到[0, 1]。在写reconstructWorldPos和深度比较时，必须明确每一步使用的深度是线性还是非线性、范围是[0, 1]还是[-1, 1]。建议统一使用GLM_FORCE_DEPTH_ZERO_TO_ONE并把整个工程都按这个约定写，可以避免大量隐蔽 bug。

7. 工程实践与性能优化建议

7.1 调试与截帧

从零手搓渲染器时，最好的习惯是一行代码只做一件事，然后养成“改一点、跑一次、用 RenderDoc 看一次”的习惯。RenderDoc 可以看到当前帧的每个 Pass、每张纹理、每个 Draw Call 的输入输出，能非常直观地定位“是 GBuffer 写错了还是屏幕空间追踪方向算错了”。

建议在工程里内置一个简单的调试热键，按1显示反照率、2显示法线、3显示深度、4显示间接光，这样不用每次都在 RenderDoc 和代码之间反复切换。

7.2 性能分析

第一帧跑通后，重点关注三个指标：

• 帧时间中 G-Buffer 和屏幕空间追踪各占多少。
• 屏幕空间追踪的收敛率，即命中屏幕像素的比例。
• SDF 追踪的平均迭代次数。

如果帧时间大部分消耗在屏幕空间追踪上，可以考虑降低追踪步数，或者只在粗糙度较高的表面做追踪。如果 SDF 回退代价过高，可以减少 SDF 追踪的分辨率，或对远距离 SDF 做降采样。

7.3 从第一帧到更完整版本

拿到第一帧画面后，后面的迭代方向可以是：

• 实现 HZB 加速屏幕空间追踪，让追踪步长根据深度自适应。
• 实现简单的网格 SDF 体素化，替换手动组合的 SDF 球体场景。
• 增加时空降噪，让间接光在帧间稳定。
• 把整个流程迁移到 Vulkan，用VK_KHR_ray_tracing或纯计算着色器实现同等效果。
• 加入大量光源测试，确保渲染器在动态场景下不闪烁。

这些方向每一条都可以单独深入。6 个月的目标在“第一帧”这里是一个很好的节点：之后的路线会越来越宽，而你已经具备了继续往下走的完整地图。

如果你准备开始动手，建议今天就把第一阶段的窗口程序跑起来，不要等所有资料备齐再开始。图形渲染这种东西，资料永远看不完，能推动你前进的是每个周末都有一幅新的画面出现在屏幕上。