焦散是光从表面（在我们的例子中是空气/水界面）折射和反射时出现的光斑。由于在水波上发生的反射和折射，水充当了动态放大镜，于是就产生了这些光斑。在这篇文章中，我们重点关注光折射引起的焦散，主要是水下发生的情况。为了能够获得稳定的高帧率（60fps），我们需要在显卡（GPU）上计算它们，因此我们将完全使用 GLSL 编写的着色器来进行计算。计算水面的折射光线（这在 GLSL 中很简单，有内置函数使用相交算法计算这些光线照射到环境的位置通过检查光线会聚的位置来计算焦散强度。

Raymarching 是一种在 Shadertoy 等网站中流行的 3D 渲染技术，它令人惊奇的能力是没有任何 3D 几何图形，构成场景的所有对象都是使用数学函数实时生成的。接下来我们研究下光线行进算法如何从头开始工作，并使用着色器创建我们自己的光线行进器。

GPU 硬件深度缓冲区通常不会存储物体位于相机前面的距离的线性表示，这与人们第一次遇到这种情况时的预期相反。相反，深度缓冲区存储与世界空间深度的倒数成比例的值，下面解释一下原因。在本文中，我们使用d表示存储在深度缓冲区中的值（在 [0, 1] 区间），使用z表示世界空间深度，即沿相机中心的距离，以世界单位（例如米）表示。一般来说，它们之间的关系是这样的形式从表面上看，我们可以将d视为的z的任何函数。那么为什么要做出这样的特殊选择呢？主要有两个原因。首先，1/z 很适合透视投影的框架。

更多精彩内容尽在。

在处理计算机生成的图像时，锯齿是最令人头痛的问题之一。锯齿以锯齿状线（几何锯齿）或亮点（镜面/着色锯齿）的形式出现，并且随着移动而变得更严重。由于屏幕（由像素组成）的离散性质以及每个像素只能是一种颜色，因此存在锯齿。每个像素实际上是场景一部分上的一个小窗口，并且应该能够显示从该窗口可见的所有颜色以准确描述场景，但由于它只能是一种颜色，因此我们必须决定使用哪种颜色显示。有很多算法可以处理这个问题，时间抗锯齿（TAA，Temporal Anti-Aliasing）就是其中之一。

归根到底，是因为 view space 的 z 值是按负反比例函数被分布到 NDC 的 z 坐标中，导致非常小的一部分 zv 值被映射到大部分的 zNDC 中（在 f=100,n=0.1 中，0.1~0.2 的 zv 就瓜分了一半的 zNDC），导致在大场景中产生所谓的 z-fighting 现象。当然，这在数学上没有什么问题，但在计算机中，浮点数是由精度限制的。我们知道，fragment 的深度值是线性插值的，而 varying 变量的插值是透视矫正的线性插值，会考虑 clip space 的 w 值。

要使用Ray Marching渲染 3D 场景，我们需要为每个像素发射一条光线。通过选择屏幕上的一个点（一个像素），并从视点绘制一条射线，我们可以确定它是否击中一个对象，并决定应该在该像素上绘制什么。使用着色器，我们可以并行处理所有像素以完成整个图像。下面的例子演示了这个想法。光线的起始位置和方向由视点（眼睛）和当前像素（crd）的位置确定。函数是此次演示的主要函数。我们沿光线射线移动一个点并使用 SDF（有符号距离函数）检查它是否足够接近表面。如果距离低于阈值，该函数将返回距离，否则返回 -1.0。

该方法是通过跟踪穿过图像平面中每个像素的光路来生成图像。在现实世界中，光从光源出发，然后到达我们的眼睛。然而，我们在光线追踪中以相反的方式做到这一点。

光能传递是一种模拟从光源开始的光漫反射传播的方法。因此，它对于静态场景是可预先计算的。比如一面墙原来是白色，由于房间里物体的原因，使得墙面反射物体的那一部分变成物体的原色，这种现象叫做Color bleeding。相反，我们可以利用像“Gauss-Seidel”方法这样的近似。Form factor（Fij）是“离开表面 j 并到达表面 i 的光能的分数”。计算准确的Form factor很困难，我们可以在这里采用相同的近似值。我们考虑从半球上的区域投影到地面上的某个区域。只考虑从物体表面到眼睛的直射光。

缓冲区是保存某些数据的临时存储空间。为什么我们需要缓冲区？原因很简单，当数据量很大时，因为计算机无法同时处理整个数据，因此在处理当前数据集时需要额外的空间来存储其余数据。在计算机图形学中，缓冲区有多种定义方式。分辨率：宽度(n) x 高度(m)深度（或精度）：k位数/像素例如，如果我们想要每个像素使用 RGB 通道，则一个通道需要 8 位，总共 24 位（3 x 8 位）。

本系列根据国外一个图形小哥的讲解为本，整合互联网的一些资料，结合自己的一些理解。

Forward+是在屏幕空间中划分Tile进行光源过滤来降低消耗的，这个划分是在XY 2D平面进行的，而Clustered Forward Rendering则是在这个基础上更进一步，在Depth方向上也同样进行一次划分，进一步缩小光照的影响范围，降低光照计算的浪费。将渲染分为两个阶段，第一阶段处理光照计算需要的数据，并将他们储存到GBuffer中，这些数据包括片元位置、漫反射贴图，法线贴图，镜面反射强度图等。最常见的渲染，所谓的前向渲染，就是将物件串成一个队列，一个接一个的进行渲染。

在百度百科上的解释比较难以理解，可以看下面的例子：可以看到两个红色顶点之间的连线并不满足“每条边仅与一个或两个面相关”，是与三个面相关，那么这个就是个非流形几何。二维流形应满足与顶点相接的面形成封闭或开放的扇形：但是下面的网格与另一个三角形相关联，没有共享边，所以它不是二维流形。

本系列根据国外一个图形小哥的讲解为本，整合互联网的一些资料，结合自己的一些理解。

尽管它们通常会扭曲面积（这就是为什么这种类型的投影在极地区域之外的映射中不常见的原因），但保留形状对于我们在多边形上执行的几何操作至关重要。从性能的角度来看，在创建几何图形时，分割多边形可能是一项昂贵的操作，因为该算法对每个多边形和每个分割平面进行操作。但是，一旦进行三角剖分，任何分割的多边形都会稍后在管道中重新组合，作为几何批处理步骤的一部分，以确保与以前相同的渲染性能。在Cesium的早期版本和一些引擎中，我们绘制这种跨度比较大的多边形，经常会看到一些奇怪的冲突问题，如下图所示。一种简单的解决方案是。

首先，在着色器中定义一个常量。稍后可以从 JavaScript 端覆盖该常量。这次我们在片段着色器中定义它。@fragment} else {通过在常量名称之前添加override，该常量就成为可以从 JavaScript 端覆盖的常量。是否指定默认值并不重要，但如果不指定，则必须始终从 JavaScript 端覆盖它。如果不覆盖，将使用着色器端定义的默认值。

此时用作参数的描述符是一个名为 GPURenderBundleDescriptor 的类型， 注意创建RenderPassEncoder时与GPURenderPassDescriptor不同。由于注册的绘图命令在内部被转换为GPU可以理解的命令格式， 比绘制时每次都用RenderPassEncoder进行转换效率更高。命令可以重复使用，这减少了为每个绘制调用注册命令的成本。创建 RenderBundleEncoder 后，像注册 RenderPassEncoder 一样注册绘图命令。

访问，代码在。

我们先说一下前向渲染（forward rendering），它是对场景中所有物体对象进行渲染并执行光照计算。但是光照计算其实是一项非常耗性能的操作，在前向渲染中，我们会做很多次像素着色器的调用，但是其中大部分是不必要的。比如场景中有四个物体，互相之间存在叠压关系，按照前向渲染的流程，先渲染了一个物体之后，它的一部分被后一个渲染的物体挡住了，那么被挡住的这部分就是做了无效的计算，这就会很浪费资源和计算能力。如果场景中有大量的灯光，那么像素数*灯光数这种渲染逻辑将是非常糟糕的。

齐次坐标有一个额外的维度W，它可以缩放X，Y和Z的值。用于平移和透视投影变换的矩阵只能应用于齐次坐标，这就是为什么它们在3D计算机图形中如此常见。当W=1时，X、Y和Z值被认为是“正确的”。任何齐次坐标都可以通过四维数除以W值来转换为W=1，除非W=0。当W=0时，坐标表示无穷远处的点(一个无限长的矢量)，这通常用来表示方向光的方向。