a). Introduction

Real-time Ray-Tracing vs. Ray-Tracing:

• Real-time Ray-Tracing == 1/few sample per pixel(SPP)

• Key technology: Denoising(降噪)

  

一个光路样本（1 SPP path tracing）：

• 第一步是Rasterization，而不是Ray的原因： 从摄影机发出经过各个像素的光线，即等同于进行一次光栅化，找到Primary hitpoint

  • 第一步如做光线求交，则为光线投射（Ray Casting）。而光线投射和光栅化没有本质区别（都是渲染一点的DI，只不过相当于深度测试被光线求交替代了）

    

    ^{Ray Casting}. 注意和光线追踪的区别，Ray Casting基本只求交一次，而不迭代追踪 ↩

• 传统的降噪方式不是效果不好，就是太慢或不靠谱

b). Temporal denoising(时域降噪)

Key idea:

• 复用前面已经降噪过的一帧；
• 使用motion vector来找到先前的位置；
• 本质上是提高采样率；

b.1). G-Buffer

b.2). Back Projection

• Key idea：不同帧之间相同的点，意味着有着相同的世界位置（如不移动）或模型空间位置；

How：

• 如果世界坐标 $s$ 存在于G-Buffer中，即可直接使用；
• 否则，$s = M^{-1}V^{-1}P^{-1}E^{-1}x$ （$E$ 为视口变换，即NDF到Viewport/Screen）
• 运动（Motion）情况已知，$s’ = T^{-1} s$，$s’$ 为运动前的位置，$T$ 为运动的矩阵
• 在 $i-1$ 帧，$s$ 对应的屏幕空间位置为 $x’=P’V’M’s’$

Q1：在金属或高光工作流中，对于非导体材质（电介质）默认其零度菲涅尔值$R_0$ 为4%，那么按PBR来，他怎么会有颜色呢；还是说非导体的albedo就是$R_0$ ? 按作业中来好像albedo就是 $R_0$ ，后续还得深挖一下；

Q2：Jacobian 项，方向导数需要去了解更多

a). Introduction

• 尽管实时渲染中的PBR，不一定完全基于物理。如Disney principled BRDFs (artist friendly but still not PBR)

b). Microfacet BRDF

• 菲涅尔项；
• Shadowing-masking term
  • 考虑微表面之间的遮挡和阴影；
  • 当光线几乎平行与表面入射时(Grazing angle)，微表面之间遮挡变多
• Disterbution of normals(法线分布)

• 引擎为了提高性能，并且artist friendly，用漫反射项补偿微表面BRDF（打破能量守恒，如想在RTR中实现较为准确的能量补充，应使用Kulla-Conty Approximation）。使得其方便控制，如对于非金属4%的 $F_0$ 也可呈现颜色。并且把BRDF分母的 $\pi$ ,写为4。
  • 因此，引擎中PBR的Shading常有以下几项，并通过系数控制其不过与打破能量守恒：
    1. 直接光照漫反射；
    2. 直接光照镜面反射；
    3. 间接光照漫反射；
    4. 间接光照镜面反射；
       • 这样做的结果是容易打破能量守恒，但是artist friendly，而且可表现更多外观。
• 更多请看Games202 Real-time Physically-based Materials，或以下Reference
• Ref:
  1. LearnOpenGL CN
  2. 201403-GDC_UnityPhysicallyBasedShading
  3. 基于物理的渲染（PBR）白皮书
  4. 基于物理的渲染—更精确的微表面分布函数GGX
  5. 如何在Unity中造一个PBR Shader轮子
  6. Image Based Lighting with Multiple Scattering

a). Unity中的PBR（Disney‘s Principled BRDF）

Unity中Standard Shader基本采用Disney’s Principled BRDF，但有些许不同。Disney’s Principled BRDF可具体看其他文章，如毛星云大佬的PBR白皮书，以下就写一些实现上的不同处和细节。

这两篇已经写得挺好的了，后续再补充。

用Unity实现景深效果

图形学基础|景深效果（Depth of Field/DOF）

HW

Step1: 计算CoC(弥散圆)

Step2: Bokeh Filter

Step3: Tent Filter

Step4: Composition

a). Bloom算法介绍

模拟光辉效果的算法
简单思路：提取较亮的部分进行模糊，然后与原图叠加后输出
HDR：使用HDR可以使提取到亮度大于1的区域
高斯模糊：使用高斯函数得到的高斯核去卷积图像
二维高斯核：将运算的复杂度从 N x N x W x H 减少到了 2 x N x W x H (对称性使N可减少到N/2+1)

b). Bloom算法实现（Unity）

C#部分

调用OnRenderImage函数获取纹理和传输参数给Shader：

Shader部分

使用4个Pass计算Bloom效果：

第一个Pass提取较亮区域
第二个、第三个Pass分别在竖直和水平方向上计算高斯模糊
最后一个Pass将计算的结果与原图像进行混合

c). Bloom算法应用

配合自发光贴图使用
配合特效（如烟花）
GodRay（基于径向的后处理）
使用HDR时，配合Tonemapping（配合色调映射的bloom效果更加柔和）

图形 4.3 实时阴影介绍

更深的可看笔记Games202 Real-time Shadow

a). 基于图片实时阴影技术

a.1). Shadow Map

• 关键思想：一个点在相机视角中可见，但在光源视角中不可见，那该点就处于阴影中。

• 做法： 在光源视角下渲染深度图。对于着色点$A$，将其转换到光源视角（其他空间也行，只要两者在同一坐标空间）后，与Shadow Map中对应点进行深度比较，判断一点是否在阴影中；

  

A 2-Pass Algorithm

1. Light pass: Generate the SM(Shadow Map)
2. Camera pass: uses the SM

Pass 1: Render from Light

• 输出一张光源视角的深度图（Depth Buffer）

Pass 2: Render from Eye(Camera)

• 将光源视角对应的深度转换到View Space, 与Camera视角的深度进行深度比较；

  • 如$Depth_{cam} > Depth_{light}$ ，那说明该点在阴影中（相机可见，光源不可见）
  • 如$Depth_{cam} < Depth_{light}$ ，那说明该点在不在阴影中（相机可见，光源可见）

a). AO(Ambient Occlusion)

环境光遮蔽，全称Ambient Occlusion，是计算机图形学中的一种着色和渲染技术,模拟光线达到物体的能力的粗略的全局方法，描述光线到达物体表面的能力。

b). SSAO(Screen Space Ambient Occlusion)

屏幕空间环境光遮蔽，全称Screen Space Ambient Occlusion，一种用于计算机图形中实时实现近似环境光遮蔽效果的渲染技术。通过获取像素的深度缓冲、法线缓冲以及像素坐标来计算实现，来近似的表现物体在间接光下产生的阴影。

b.1). SSAO原理

1. 获取深度、法线（View Space）缓冲；

   • Normal Buffer：

     

2. 重构像素相机空间中的坐标；

   • 通过深度缓冲的depth值重构（近似）该视角下的三维场景；

     

     • 为什么是近似：Depth Buffer中深度值为0~1，并不能反应无穷远（天空等）。常用的办法是把1映射到View Space的远平面。

3. 法向半球随机采样，计算掩蔽因子，进而得到AO强度（For循环）；

   

   • 每一次for循环都会在法线半球中获取一个随机向量，根据这个向量我们会求出它对应的深度值，然后跟深度缓冲中对应采样像素位置的深度值做比较，如果大于（灰色点），则认为有遮蔽，算进加权中，最后我们合成AO，然后再加上一些后期处理优化效果。

a). 名词解释

System on Chip(Soc)

• Soc是把CPU、GPU、内存、通信基带、GPS模块等整合在一起的芯片的称呼。常见有A系Soc（苹果），骁龙Soc（高通），麒麟Soc（华为），联发科Soc，猎户座Soc（三星），去年苹果推出的M系Soc，暂用于Mac，但这说明手机、笔记本和PC的通用芯片已经出现了

物理内存

• 也就是我们常说的手机内存，也叫System Memory。Soc中CPU和GPU共用一块片内LPDDR物理内存。此外CPU和GPU还分别有自己的告诉SRAM的Cache缓存，也叫On-chip Memory。读取System Memory的时间消耗大概是On-chip Memory的几倍到几十倍

On-Chip Buffer

在TB(D)R架构下会存储Tile的颜色、深度和模板缓冲，读写修改都非常快。如果Load/Store指令中缓冲需要被Preserve，将会被写入一份到System Memory中。

Stall

当GPU两次计算结果之间有依赖关系而必须串行时，等待的过程便是Stall

FillRate

像素填充率 = ROP运行的时钟频率 x ROP的个数 x 每个时钟ROP可以处理的像素个数

TBR（Tile-Based (Deferred) Rendering）

TBR（Tile-Based (Deferred) Rendering）是目前主流的移动GPU渲染架构，对应一般PC上的GPU渲染架构则是IMR（Immediate Mode Rendering ）。

• TBR流水线：顶点着色器 - Defer - 光栅化 - 片元着色器
• TBDR流水线：顶点着色器 - Defer - 光栅化 - Defer - 片元着色器

Deffer

延迟，从渲染数据的角度来看，就是 ”阻塞+批处理“ GPU ”一帧“ 的多个数据，然后一起处理

b). 立即渲染（IMR，Immediate Mode Rendering ）

• IMR是PC上GPU采用的架构

  

  

  

c). 基于块元渲染的TB(D)R

TB(D)R宏观上总共分为两个阶段：

1. 分图元： 第一阶段执行所有几何相关的处理，并生成Primitive List（图元列表），并且确定每个Tile上面有哪些Primitive
2. 第二阶段逐Tile执行 光栅化后 写入Tile Buffer（片上内存），并在完成后将 Frame BUffer 从 Tile Buffer 写回到 System Memory中；

a). 纹理压缩简介

• 纹理压缩是为了解决内存、带宽问题，专为在计算机图形渲染系统中存储纹理而使用的图像压缩技术；

a.1). 图片压缩 vs. 纹理压缩（为什么要纹理压缩）

• 图片格式：JPG、PNG、GIF、BMP等；
• 纹理压缩格式： ETC、DXT、ASTC等

图片压缩格式大部分都是整体依赖，即不支持像素随机访问（基于整张图片进行压缩，无法直接实现单个像素的解析），且图片压缩格式无法被GPU识别，还需要经CPU解压缩成非压缩纹理格式才能被识别。因此采用基于块压缩的纹理压缩，能够更快读取像素所属字节进行解压缩以支持随机访问。

• 纹理管线：

  

b). 常见纹理压缩格式

a). 渲染路径

• 决定光照的实现方式。简言之，就是当前渲染目标使用光照的流程。

b). 渲染方式

• 延迟渲染
• 前向渲染

可以看到前向渲染中，中间蓝色的灯并没被渲染。（场景8盏灯，Project Setting中Pixel Light Count设为7）

b.1). 前向/正向渲染-Forward Rendering

• 简介：每个Object对每个光照都计算；

b.1.1). 流程

• 简单来说就是不管光源的影响大不大，计算的时候都会把所有光源计算进去，这样就会造成一个很大的浪费

b.1.2). 规则和注意事项

• 发生在顶点处理阶段，会计算所有顶点的光照。全平台支持

• • 规则1：最亮的几个光源会被实现为像素光照
  • 规则2：然后就是，最多四个光源会被实现为顶点光照
  • 规则3：剩下的光源会实现为效率较高的球面调谐光照（Spherical Hamanic），这是一种模拟光照

• 补充说明

• • 最亮的那盏光一定是像素光照
  • Light的Render Mode是important的光一定是像素光照
  • 如果前面的两条加起来的像素光照小于Quality Setting里的Pixel Light Count（最大像素光照数量），那么从剩下的光源中找出最亮的那几盏光源，实现为像素光照。
  • 最后剩下的光源，按照规则2或3。
  • 在base pass里执行一盏像素光、所有的顶点光和球面调谐光照，并且进行阴影计算。
  • 其余的像素光每盏一个Additional Pass，并且这些pass里没有阴影计算。
  • 场景中看到的阴影，全是base pass里计算出最亮那盏像素光的阴影，其他像素光是不计算阴影的。

• 最多的光源数是可以更改的

  • 以Unity中的为例，在project setting中

  

b.2). 延迟渲染（Deferred Rendering）

b.2.1). 简介

主要解决大量光照渲染的方案。

可以将延迟渲染(Deferred Rendering)理解为先将所有物体都先绘制到屏幕空间的缓冲（即G-buffer，Geometric Buffer，几何缓冲区）中，再逐光源对该缓冲进行着色的过程，从而避免了因计算被深度测试丢弃的片元的着色而产生的不必要的开销。也就是说延迟渲染基本思想是，先执行深度测试（应该也包括其他测试），再进行着色计算，将本来在物空间（三维空间）进行光照计算放到了像空间（二维空间）进行处理。

对应于正向渲染O(m*n)的 复杂度，经典的延迟渲染复杂度为O(n+m)。