dtysky|一个行者的轨迹

【WebGPU实时光追美少女】踩坑与调试心得

dtysky — Tuesday, 05 Oct 2021 19:30:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

在前面的七篇文章中，我从概论开始，论述了简单WebGPU渲染引擎的实现，并实现了一个支持BVH加速结构和BRDF光照模型的实时路径追踪渲染器。但由于WebGPU的API的实验性，目前相关标准仍然可能不断变更，而由于配套于WebGPU的调试工具还不存在，所以在不重编Chromium的情况下只能想一些朴素的方法来调试，这里就记录了一些调试心得。

教程基础部分到此完结，BSDF和BVH优化部分等有生之年吧。又在焦虑中做到了一次无偿的知识分享，算是以此再次纪念“互联网之子”亚伦·斯沃茨。

关于API变更

目前WebGPU的API标准仍然可能变更，所以发现之前跑得好好的代码忽然就挂了也是正常的，当遇到这种问题后，我们一般需要去以下几个地方寻找解决方案：

Chromium WebGPU部分的Issue： https://bugs.chromium.org/p/dawn/issues/list

WebGPU最新标准：https://www.w3.org/TR/webgpu

着色语言WGSL最新标准： https://www.w3.org/TR/WGSL

同时有时候报错会不清晰，这时候可以直接看Chromium的WebGPU模块源码来分析：

Dawn： https://dawn.googlesource.com/dawn/+/HEAD/src/dawn_native

如何调试CS

对于有经验的开发者来说，相对而言渲染的部分比较好调试，实在不行可以使用朴素的Color Picker大法，毕竟有了数据什么都好说，并且对于路径追踪来讲渲染部分并不复杂，不需要怎么调试。

但Compute Shader部分就不同了，在路径追踪实现中我大量使用了CS，每个部分都并不简单，而且环环相扣，出了问题十分难以排查，下面每一部我都遇到过问题：

射线生成。
BVH求交。
三角形求交。
重心坐标插值。
重要性采样。
BRDF着色计算。

比如在一开始，我遇到过这种情况：

当然对路径追踪十分熟悉的朋友，应该一眼就能看出这可能是射线生成的问题，但当时刚开始学习并没想到这个，况且就算想到了也需要有方法来确认和调试，为了调试，我使用SSBO构建了一条用来调试CS的流程。

SSBO

SSBO即Shader Storage Buffer Object，在前面的主流程中也使用过，用于存储合并过的场景数据。这种数据可以被CPU和GPU共享，不但可以用于从CPU向GPU传输数据，也可以将数据从GPU到CPU读回来。虽然这两个过程都比较慢，但对于调试而言已经足够。

在构建流程之前，需要先明确调试的步骤：

路径追踪过程始于屏幕空间的像素，所以以像素为入口调试。
构建一个屏幕大小的SSBO来存储CS计算过程中的信息，SSBO中的数据结构可以按情况定制。
可以用一个简单的策略，读回需要的GPU数据，在CPU端复刻算法进行的调试。

梳理清楚流程后，我编写了DebugInfo类以及各个Debug方法，比如debugRay、debugRayShadow，它们都在demo/debugCS.ts中。

DebugInfo

DebugInfo提供了给RayTracingManager中用于路径追踪的计算单元rtUnit注入调试信息的能力，这个调试信息通过一个SSBO作为Uniform传入，骑在Shader中的定义为：

struct DebugRay {
  preOrigin: vec4<f32>;
  preDir: vec4<f32>;
  origin: vec4<f32>;
  dir: vec4<f32>;
  nextOrigin: vec4<f32>;
  nextDir: vec4<f32>;
  normal: vec4<f32>;
};

[[block]] struct DebugInfo {
  rays: array<DebugRay>;
};`

其对应的Interface和具体构造为：

interface IDebugPixel {
  preOrigin: Float32Array;
  preDir: Float32Array;
  origin: Float32Array;
  dir: Float32Array;
  nextOrigin: Float32Array;
  nextDir: Float32Array;
  normal: Float32Array;
}

export class DebugInfo {
  protected _cpu: Float32Array;
  protected _gpu: GPUBuffer;
  protected _view: GPUBuffer;
  protected _size: number;
  protected _rtManager: H.RayTracingManager

  // 构造SSBO并作为Uniform注入给计算单元
  public setup(rtManager: H.RayTracingManager) {
    const {renderEnv} = H;
    const size = this._size = 4 * 7;

    this._cpu = new Float32Array(size * renderEnv.width * renderEnv.height);
    this._gpu = H.createGPUBuffer(this._cpu, GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_SRC);
    this._view = H.createGPUBufferBySize(size * renderEnv.width * renderEnv.height * 4, GPUBufferUsage.MAP_READ | GPUBufferUsage.COPY_DST);

    this._rtManager = rtManager;
    this._rtManager.rtUnit.setUniform('u_debugInfo', this._cpu, this._gpu)
  }

  // 拷贝SSBO，具体原因详见下面
  public run(scene: H.Scene) {
    scene.copyBuffer(this._gpu, this._view, this._cpu.byteLength);
  }

  // 从GPU读回数据，并指定需要解析的区域
  public async showDebugInfo(
    point1: [number, number],
    len: [number, number],
    step: [number, number]
  ): Promise<{
    rays: IDebugPixel[],
    mesh: H.Mesh
  }> {
    await this._view.mapAsync(GPUMapMode.READ);
    const data = new Float32Array(this._view.getMappedRange());
    const rays = this._decodeDebugInfo(data, point1, len, step);
  }

// 将读回的数据进行解析，变成可理解的结构
  protected _decodeDebugInfo(
    view: Float32Array,
    point1: [number, number],
    len: [number, number],
    step: [number, number]
  ) {
    const res: IDebugPixel[] = [];
    const logs = [];

    for (let y = point1[1]; y < point1[1] + len[1] * step[1]; y += step[1]) {
      for (let x = point1[0]; x <  point1[0] + len[0] * step[0]; x += step[0]) {
        const index = y * H.renderEnv.width + x;
        const offset = index * this._size;
        res.push({
          preOrigin: view.slice(offset, offset + 4),
          preDir: view.slice(offset + 4, offset + 8),
          origin: view.slice(offset + 8, offset + 12),
          dir: view.slice(offset + 12, offset + 16),
          nextOrigin: view.slice(offset + 16, offset + 20),
          nextDir: view.slice(offset + 20, offset + 24),
          normal: view.slice(offset + 24, offset + 28)
        } as IDebugPixel);
      }
    }

    return res;
  }
}

在这段代码中，需要注意的是我创建了两个GPUBuffer，一个设置给了uniform，另一个则用于读取，而期间做了一次拷贝scene.copyBuffer，这个拷贝的实现为：

this._command.copyBufferToBuffer(src, 0, dst, 0, size);

这是由于在WebGPU标准中，对GPUBuffer的使用有所限制，STORAGE不能和MAP_READ共存，也就是说一个Buffer不能又可以被CPU读又可以被GPU读，所以必须要先将其拷贝到另一个GPUBuffer中，再进行读取。

在GPU中填充数据

在流程组织完毕后，便可以在GPU中对SSBO进行填充，这个可以根据不同场景有不同的设置，比如这里是：

var hited: f32 = 0.;
if (hit.hit) {
  hited = 1.;
}
ray = startRay;
hit = gBInfo;
light = calcLight(ray, hit, baseUV, 0, false, false, debugIndex);
u_debugInfo.rays[debugIndex].origin = vec4<f32>(ray.origin, hit.sign);
u_debugInfo.rays[debugIndex].dir = vec4<f32>(ray.dir, f32(hit.matType));
ray = light.next;
hit = hitTest(ray);
light = calcLight(ray, hit, baseUV, 1, false, false, debugIndex);
u_debugInfo.rays[debugIndex].nextOrigin = vec4<f32>(ray.origin, hit.sign);
u_debugInfo.rays[debugIndex].nextDir = vec4<f32>(ray.dir, f32(hit.matType));
u_debugInfo.rays[debugIndex].normal = vec4<f32>(hit.normal, hit.glass);

我将初始射线的参数和在CS中求得的下一条射线参数记录了下来，以待调试。

在CPU调试指定数据

有了GPU的数据，就可以通过上面的showDebugInfo函数，来通过指定的像素位置和步长，来decode一定窗口大小的数据，只要有一个时机来触发即可：

H.renderEnv.canvas.addEventListener('mouseup', async (e) => {
  const {clientX, clientY} = e;
  const {rays, mesh} = await this._rtDebugInfo.showDebugInfo([clientX, clientY], [10, 10], [4, 2]);
  console.log(rays);
  rays.forEach(ray => debugRay(ray, this._rtManager.bvh, this._rtManager.gBufferMesh.geometry.getValues('position').cpu as Float32Array));
});

这段代码将调试过程和鼠标点击事件关联了起来，注意到最后一句我对每个像素的数据都执行了debugRay操作，这其实就是在CPU内实现了和GPU一样的算法，比如光源采样、BVH求交和三角形求交等等。由于是JS代码，所以很容易进行调试，并且也可以和GPU中存下的结果直接进行对比，虽然也很麻烦，但至少有一个调试的方法了，比如debugRay：

export function debugRay(rayInfo: {origin: Float32Array, dir: Float32Array}, bvh: H.BVH, positions: Float32Array) {
  const ray: Ray = {
    origin: rayInfo.origin,
    dir: rayInfo.dir,
    invDir: new Float32Array(3)
  };
  H.math.vec3.div(ray.invDir, new Float32Array([1, 1, 1]), ray.dir);

  console.log('ray info', rayInfo);
  console.log('ray', ray);

  const fragInfo = hitTest(bvh, ray, positions);
  console.log(fragInfo);
}

这里可以看到此调试方法将上面decode好的信息中的origin和dir作为参数进行了CPU端的hitTest，hitTest的实现对于此章节无关紧要，不再赘述。

合理借助外部工具

在实际的调试过程中，往往即便我们有了数据和调试函数，但像是BVH求交、三角形求交这种过程的计算比较复杂，数值上又很难分析出结果，这时候就需要外部工具的帮助了。设想如果有个工具能够将三角形、射线这些都直观得在三维空间内简洁地绘制出来，调试难度会大幅降低。

而这个工具确实存在，而且是免费在线的——Wolfram Cloud，可以认为是Mathematica的在线版，功能其实已经够用了。

对于本项目，用它调试最核心的就是生成各种绘制指令，我在CPU端的调试代码中插入了各种生成绘制指令的代码，比如：

// 绘制点
plotS.push(`Graphics3D[{Red, PointSize[0.1], Point[{${rsiPoints[1].join(',')}}]}]`);

// 绘制射线
plotS.push(`ParametricPlot3D[{${ray.dir[0]}t + ${ray.origin[0]}, ${ray.dir[1]}t + ${ray.origin[1]}, ${ray.dir[2]}t + ${ray.origin[2]}}, {t, 0, ${maxT}}]`);

// 绘制三角形
plotS.push(`Graphics3D[Triangle[{{${p0.join(',')}}, {${p1.join(',')}}, {${p2.join(',')}}}]]`);

// 绘制长方体
plotS.push(`Graphics3D[Cuboid[{${node.max.join(',')}}, {${node.min.join(',')}}]]`);

有了这些指令，最后我们就可以画出类似下面的图形：

结语

当然除了调试BVH求交这种问题，像是光照计算等等也都可以通过这种方式输出数据来观察和调试，在开发过程中我也是这么做的。

一开始计划的时候本篇应该还是有挺多内容，但现在回想起来很多踩的坑已经在前面的文章都论述过了，比如16字节对齐、GPUBuffer的Usage、射线原点偏移等等。

那么就到此为止吧，祝大家国庆快乐。

【WebGPU实时光追美少女】降噪与色调映射

dtysky — Monday, 04 Oct 2021 18:00:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

在上一篇文章BRDF与蒙特卡洛积分的最后，我们最终得到了一个充满了噪点的输出，接下来要考虑的就是如何降噪（Denoise），这个分为时间和空间两部分。并且由于整个光照计算都是在高动态范围（HDR）计算的，最后还要做一次色调映射（Tone Mapping）来将其转换到有限的低动态范围（LDR），便于显示器显示。

降噪

实时路径追踪的噪声来自于样本数量不足下的信息量不足，所以有两个方面可以来优化：

提高样本量。
尽可能使用有效的样本。

时间滤波（Temporal Filter）就是用来解决这两个问题的。而由于样本的增加总是需要累计时间，所以会有一个启动时间，所以为了尽可能加快速度达到一个相对可看的程度，我们在空间上也会做一些滤波，或者说是图像处理，这就是空间滤波（Spatial Filter）。

目前工程上的滤波方案往往是混合滤波，即结合时间空间二者，目前最常见的就是SVGF以及其变种，但由于本项目只涉及到静态场景，并未实现Motion Vector这种动态场景的技术，所以只是借鉴其中的一部分。

这里就直接用SVGF的一个流程图来论述整个流程：

首先求得当前帧的1SPP原始图像。
和上一次的结果作时间滤波。
将时间滤波的结果用于空间滤波。
空间滤波的输出反馈到下一帧，同时作为色调映射的来源，做最终输出。

时间滤波

时间滤波顾名思义，是通过不同帧之间的信息来做滤波。路径追踪的时间滤波比较简单：

$$C_{out} = \alpha C_{i-1} + (1 - \alpha)C_{i}$$

这个公式本质上是个简单的混合，将上一帧颜色和这一帧颜色通过权重$\alpha$混合起来。这个权重的值是动态变更的，我这里取：

$$\alpha = \frac{frameCount - 1}{frameCount}$$

这么做也是有原理可循的，回顾一下上一篇文章所说蒙特卡洛积分的采样相加求平均，我们需要相对保证每帧的结果被均匀平均：

$$\frac {C_{n}} n + \frac {n-1}n(\frac {C_{n-1}} {n-1} + \frac {n-2} {n-1}(\frac {C_{n-2}} {n-2} + ...) = \frac 1 n(C_{n} + C_{n - 1} + C_{n - 2} + ...)$$

所以只要在实现的Shader内接受完结传来的这个权重u_preWeight，然后在JS里不断更新权重即可：

[[stage(compute), workgroup_size(16, 16, 1)]]
fn main(
  [[builtin(workgroup_id)]] workGroupID : vec3<u32>,
  [[builtin(local_invocation_id)]] localInvocationID : vec3<u32>
) {
  let size: vec2<i32> = textureDimensions(u_current);
  let groupOffset: vec2<i32> = vec2<i32>(workGroupID.xy) * 16;
  let baseIndex: vec2<i32> = groupOffset + vec2<i32>(localInvocationID.xy);

  let pre: vec4<f32> = textureLoad(u_pre, baseIndex, 0);
  let current: vec4<f32> = textureLoad(u_current, baseIndex, 0);
  let mixed: vec4<f32> = vec4<f32>(mix(current.rgb, pre.rgb, vec3<f32>(material.u_preWeight)), current.a);

  textureStore(u_output, baseIndex, mixed);
}

空间滤波

空间滤波本质上就是图像处理，最简单的空间滤波就是高斯模糊。

高斯模糊

$$exp(-\frac {(x-x_c)^2 + (y-y_c)^2} {2\sigma_d^2})$$

其以某个像素为中心开一个固定大小“窗口”，根据周边像素到中心像素的半径计算权重，然后将窗口中的所有像素颜色加权平均，最终得到一个模糊的效果：

单纯的高斯模糊其实是一个低通滤波器，其本质是在频域将高频噪声过滤，留下低频信号，这种频域的处理就会得到一个如图的看起来很糊的效果，这个糊来源于边界的消失，而边界的消失则是基于以下两个事实：

高频信息并非都是噪声。
低频信息也并非不都是噪声。

所以我们需要又一个更好的策略，来在降噪的同时还能保留有效的高频信息，这就要提到联合双边滤波（Joint Bilateral Filter）。

联合双边滤波

$$exp({-\frac {(x-x_c)^2 + (y-y_c)^2} {2\sigma_d^2}} - {\frac {||color_{x,y} - color_{x_c,y_c}||^2} {2\sigma_c^2}})$$

变换后为：

$$exp({-\frac {(x-x_c)^2 + (y-y_c)^2} {2\sigma_d^2}}) * exp({-\frac {||color_{x,y} - color_{x_c,y_c}||^2} {2\sigma_c^2}})$$

如公式所示，在方才高斯模糊的基础上，我们加了一个和颜色相关的项，来共同决定窗口中某个像素的权重，同时还可以控制二者的方差来决定像素位置和颜色分别决定权重的比例。那么接下来就可以很自然想到——既然如此，是否可以再加上别的项，通过别的信息来共同决定这个权重呢？当然是可以的，这就又要用到Gbuffer了。

已知Gbuffer中提供了世界坐标、法线等等信息，我们可以考虑对于当前图像“边界”到底意味着什么？很自然可以想到就是一些合理可控的突变的点，比如在一个立方体的转折处（法线发生了较大变化），再比如一前一后的两个物体（深度发生了较大变化）。利用这些特性，就可以构造一个比较合理的滤波器：

$$exp({-\frac {(x-x_c)^2 + (y-y_c)^2} {2\sigma_d^2}}) * exp({-\frac {||color_{x,y} - color_{x_c,y_c}||^2} {2\sigma_c^2}}) * exp({-\frac {||normal_{x,y} - normal_{x_c,y_c}||^2} {2\sigma_n^2}}) * exp({-\frac {||z_{x,y} - z_{x_c,y_c}||^2} {2\sigma_n^2}})$$

然后接下来就是调整系数（方差）的工作了，我在CPU中通过方差事先算好了系数，来供Shader中使用：

export function genFilterParams(sigmas: Float32Array): Float32Array {
  const res = new Float32Array(sigmas.length);

  for (let i: number = 0; i < sigmas.length; i += 1) {
    const s = sigmas[i];
    res[i] = -0.5 * s * s;
  }

  return res;
}

到此就可以实现最终的滤波器了，联合双边滤波的结果如下，可见解决了边界被模糊的问题：

Outlier Removal

滤波滤波到此结束，但还有另一个问题，如下图：

图上有一些亮点，这些亮点的亮度明显高于周边。这是由于采样率不足，导致没有足够的样本做平均来达到真正的效果，换言之如果样本足够这些亮点是可以被平均掉的。但对于实时应用，我们等不起这个过程，所以必须用方法将它们“抹除”掉。这确实会造成能量的不守恒，但却是一个必要的权衡。

这个过程称为Outlier Removal，采用的是统计的方法：

在滤波操作之前进行。
计算所有点亮度的均值和标准差。
根据均值和方差算出上界，如果某像素亮度大于上界，则判定为Outlier。
针对Outlier，将其拉到上界范围内。

代码实现

至此，所有的要素都已集齐，就可以进行代码实现了（当然写的有点糙，凑合看吧）：

fn calcWeightNumber(factor: f32, a: f32, b: f32) -> f32 {
  return exp(factor * (a - b) * (a - b));
}

fn calcWeightVec2(factor: f32, a: vec2<i32>, b: vec2<i32>) -> f32 {
  let diff: vec2<f32> = vec2<f32>(a - b);
  return exp(factor * dot(diff, diff));
}

fn calcWeightVec3(factor: f32, a: vec3<f32>, b: vec3<f32>) -> f32 {
  let diff: vec3<f32> = a - b;
  return exp(factor * dot(diff, diff));
}

fn calcLum(color: vec3<f32>) -> f32 {
  return dot(color, vec3<f32>(0.2125, 0.7154, 0.0721));
}

fn blur(center: vec2<i32>, size: vec2<i32>) -> vec4<f32> {
  let radius: i32 = WINDOW_SIZE / 2;
  let sigmaD: f32 = material.u_filterFactors.x;
  let sigmaC: f32 = material.u_filterFactors.y;
  let sigmaZ: f32 = material.u_filterFactors.z;
  let sigmaN: f32 = material.u_filterFactors.w;
  var centerColor: vec4<f32> = textureLoad(u_preFilter, center, 0);
  let alpha: f32 = centerColor.a;
  let centerPosition = textureLoad(u_gbPositionMetalOrSpec, center, 0).xyz;
  let centerNormal = textureLoad(u_gbNormalGlass, center, 0).xyz;
  var colors: array<array<vec3<f32>, ${WINDOW_SIZE}>, ${WINDOW_SIZE}>;
  var lums: array<array<f32, ${WINDOW_SIZE}>, ${WINDOW_SIZE}>;

  var minUV: vec2<i32> = max(center - vec2<i32>(radius, radius), vec2<i32>(0));
  var maxUV: vec2<i32> = min(center + vec2<i32>(radius, radius), size);
  var localUV: vec2<i32> = vec2<i32>(0, 0);
  var sumLum: f32 = 0.;
  var count: f32 = 0.;

  // 计算每个像素的颜色亮度存起来
  for (var r: i32 = minUV.x; r <= maxUV.x; r = r + 1) {
    localUV.y = 0;
    for (var c: i32 = minUV.y; c <= maxUV.y; c = c + 1) {
      let iuv: vec2<i32> = vec2<i32>(r, c);
      let color: vec3<f32> = textureLoad(u_preFilter, iuv, 0).rgb;
      let lum: f32 = calcLum(color);
      colors[localUV.x][localUV.y] = color;
      lums[localUV.x][localUV.y] = lum;

      sumLum = sumLum + lum;
      count = count + 1.;
      localUV.y = localUV.y + 1;
    }
    localUV.x = localUV.x + 1;
  }

  // 计算亮度均值
  let meanLum: f32 = sumLum / count;

  // 计算亮度方差
  var std: f32 = 0.;
  for (var r: i32 = 0; r < localUV.x; r = r + 1) {
    for (var c: i32 = 0; c < localUV.y; c = c + 1) {
      let lum: f32 = lums[r][c];
      std = std + (lum - meanLum) * (lum - meanLum);
    }
  }
  std = sqrt(std / (count - 1.));

  // 确定亮度最大边界
  let largestLum: f32 = max(meanLum + std * 2., 1.);

  var lum: f32 = calcLum(centerColor.rgb);
  if (lum > largestLum) {
    centerColor = centerColor * largestLum / lum;
  }

  localUV = vec2<i32>(0, 0);
  var weightsSum: f32 = 0.;
  var res: vec3<f32> = vec3<f32>(0., 0., 0.);

  for (var r: i32 = minUV.x; r <= maxUV.x; r = r + 1) {
    localUV.y = 0;
    for (var c: i32 = minUV.y; c <= maxUV.y; c = c + 1) {
      var color: vec3<f32> = colors[localUV.x][localUV.y];
      lum = lums[localUV.x][localUV.y];

      if (lum > largestLum) {
        // 当前像素亮度大于最大边界，将其拉回来
        color = color * largestLum / lum;
      }

      let iuv: vec2<i32> = vec2<i32>(r, c);
      let position: vec4<f32> = textureLoad(u_gbPositionMetalOrSpec, iuv, 0);
      let normal: vec4<f32> = textureLoad(u_gbNormalGlass, iuv, 0);
      // 联合双边滤波
      let weight: f32 = calcWeightVec2(sigmaD, iuv, center)
        * calcWeightVec3(sigmaC, color.rgb, centerColor.rgb)
        * calcWeightVec3(sigmaN, normal.xyz, centerNormal.xyz)
        * calcWeightNumber(sigmaZ, position.z, centerPosition.z);
      weightsSum = weightsSum + weight;
      res = res + weight * color;

      localUV.y = localUV.y + 1;
    }
    localUV.x = localUV.x + 1;
  }

  res = res / weightsSum;

  return vec4<f32>(res, alpha);
}

色调映射

在完成了滤波后，如果不加任何处理，我们会得到这样的一个结果：

可见其有明显的过曝，所以就需要色调映射。评估一个色调映射质量最重要的维度是对比度的保留，历史上出现过很多种策略，像是Reinhard曲线、指数曲线等，但都不足够好，会有灰蒙蒙的感觉。直到后期，人们最终找到了高次曲线拟合的方法，最终实现了目前最通用的拟合策略，其计算高效，实现简单：

let A: f32 = 2.51;
let B: f32 = 0.03;
let C: f32 = 2.43;
let D: f32 = 0.59;
let E: f32 = 0.14;  

fn acesToneMapping(color: vec3<f32>) -> vec3<f32> {
  return (color * (A * color + B)) / (color * (C * color + D) + E); 
}

色调映射后的最终的结果如下：

结语

本篇文章所言都是针对静态场景的，在这种实现下，物体和相机都不能移动，这在实际的应用中显然是不够的。一般在真正可用的实现中，我们必须引入Motion Vector，来计算当前一个像素上一帧所对应的像素，然后分别存储权重，最终达到动态场景的滤波。但这也会引入更多其他的问题，由于篇幅和时间确实没空完成了。

当然如果只是玩票，理论上加上Motion Vector，对SVGF之类的进行实现也并非难事，这篇文章的很多知识是可以用到的，有兴趣的读者可以自行实现，或者等有生之年我进行优化（逃

【WebGPU实时光追美少女】BRDF与蒙特卡洛积分

dtysky — Friday, 01 Oct 2021 21:00:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

在上一篇文章BVH与射线场景求交插值中，我论述了如何对场景进行划分、如何求得射线和场景中三角形的交点、如何判断射线和某点之间是否有遮挡、射线是否与光源相交，以及如何得到插值后的顶点和材质属性。有了这些数据，便可以进行最终的光照计算，这里会涉及到BRDF模型、直接光照、间接光照、蒙特卡洛积分、重要性采样、随机数生成等等的概念和实现。

长假第一天从学习开始，大家卷起来！

BRDF

BRDF，即双向反射分布函数，是一种针对物体表面的光照反射模型，其综合了漫反射和镜面反射两部分，给出了一种比较物理真实的算法。

从渲染方程说起

在一般的渲染中，光照本质上是一个针对“入射光线”（一般由方向、亮度、颜色等描述）击中“表面”（一般由法线、各种材质参数描述）后，求得表面最终颜色的计算。为了统一描述这个过程，在1986年，渲染方程被提出：

$$L_0(p,w_0) = L_e(p,w_0) + \int_{\xi^{2}}f_{r}(p,w_{i},w_{o})L_{i}cos{\theta}dw_{i}$$

渲染方程描述了一个基于辐射度量学和能量守恒定律的光照模型。其中p是计算光照的点，wo是出射方向，Le部分可认为是自发光，后面部分是一个半球积分，其描述了此点入射半球内的光照累加和，其中wi是入射方向，fr是散射函数，Li是入射辐亮度（单位立体角单位面积的功率），cos是法线和入射光线的夹角。

至于为何要用辐亮度，可以参考闫老师的Games101。

可见，除了自发光这个比较简单的参数，其他计算都和“入射方向”、“光照点的材质属性”和“出射方向”有关。而其中最重要的就是fr，即散射函数。那么散射函数到底是什么呢？它描述的实际上是出射辐亮度和入射辐亮度微分的比例，也可以认为是一条光线从特定方向入射、出射时发生的能量吸收后剩余的能量。

不同的光照模型实际上就是在定义fr这个散射函数，尤其是对于PBR（基于物理的渲染），就是在寻找模型来尽量逼近物理真实。

BRDF模型

BRDF就是一种散射函数，其不考虑透射现象，只考虑非透明物体的表面反射和回弹，所以是双向反射分布函数。我们这里使用的BRDF模型定义为：

$$f_{r}(p,w_{i},w_{o}) = k_{d}\frac{c}{\pi} + k_{s}\frac{DFG}{4cos\theta_{i}cos\theta_{o}}$$

可见BRDF模型分为两部分，第一部分为漫反射，第二部分为高光反射，这两部分各自有一个系数，这个系数由菲涅尔系数决定。这两部分基于微表面模型，它将每一个着色点理解为很多朝向不同的微小表面的集合：

在这个模型下，每条光线入射某个着色点后，都将以一定的概率反射到不同的方向，并有不同程度的能量损耗。

菲涅尔方程

菲涅尔方程描述了这样的而一种现象——当光从一个介质入射到另一个不同折射率的介质的表面时，一部分会被反射、另一部分会被折射:

被菲涅尔反射的这部分就是高光反射，而另外么有被折射也没有被吸收的部分就是漫反射。菲涅尔系数的计算一般和材质属性相关，这个后面会说。

注意对于金属是没有漫反射的，因为这部分能量会被完全吸收掉，这在后面实际的计算中也会体现。

漫反射

漫反射部分从表现上来看，就是一条光线入射到着色点后，没有被镜面反射的部分在物体内部或微表面多次弹射，没有被吸收的部分会随机得反射到整个法线半球中，其出射只和入射方向与法线相关，和观察方向无关：

在我们使用的这个模型中，对其抽象比较简单，认为这个随机是均匀的，所以可以看到是一个定值c/pi，c是反照率，主要由baseColor和不同工作流的系数控制，除以pi是因为fr是将辐照度转换到辐亮度的比例，需要换算。

高光反射

和漫反射不同，BRDF的高光反射部分相对复杂。高光部分本身其实挺简单的，就是根据入射光线、法线、视线计算一个反射比例，从而确定出射光线的方向和强度。但由于微表面模型的存在，着色点并非是一个简单的镜面，我们需要能够模拟着色点表面粗糙的状况，这也就是这部分在BRDF的公式中比较复杂的原因。

如公式所示，高光反射主要分为三个部分：菲涅尔项F、法线分布D和几何遮蔽G。其中菲涅尔项在上面已经论述过；法线分布本质上描述了模型中各个微表面的分布状况，有不同实现；几何遮蔽则是为了描述微表面的反射光线可能被其他微表面遮挡的现象，也有不同的实现。但由于这里只是先说原理，详细的实现会放在后面讲：

现在我们有了一个理论上的光照模型，可以在光线的入射和出射方向都确定的情况下计算出入射和出射之间的比例，但对于路径追踪而言，还有以下问题要解决：

对于这样一个很难给出解析解的积分，如何求解。
对于实时渲染，几乎不可能一帧完成积分，如何处理。
如何通过已知的出射光线和材质属性，求取入射光线。

这些问题，都可以通过蒙特积分解决。

蒙特卡洛积分

蒙特卡洛积分是一种统计方法，用于求解一个难以求出解析解的积分的数值解。其基本思路是采样和平均：

如图，f(x)为要求解的积分，我们可以在其定义域上采样，如此便可以产生许多矩形样条，用这些样条去采样然后相加求平均，便可以证明其数学期望与希望得到的积分一致，这也证明通过蒙特卡洛积分得到的结果是无偏的。当然，这个无偏不代表有效性，所以我们必须要保证大量的样本才能使得结果最终收敛于真值。

采样与概率密度

在实际的实现中，我们往往希望尽量减少采样的次数，以最快的速度达到收敛。好在蒙特卡洛积分允许我们进行非均匀采样，即提供一个分布来取代均匀采样，如此一来只要保证无偏，就可以就可能提高有效性，来达到最快的收敛速度：

$$F_{n} = \frac{1}{N}\sum_{i=1}^{N}\frac{f(X_{i})}{p(X_{i})}$$

如公式，其中p(x)是需要提供分布的概率密度函数（PDF）。所以对于我们而言最重要的如何选择这个用于采样的概率分布，这就要提到重要性采样：

如图，重要性采样指的是对于被积函数，我们选取的采样分布能够满足随着被积函数而变化——被积函数值越大的地方，采样点选取概率越高。同时有了PDF之后，我们还需要一个方法来采样，然而不幸的是，目前计算机只能实现对均匀分布的采样，所以就需要有一个策略来通过均匀分布的输入来通过指定的PDF，来求取最终的采样值。

对于路径追踪的应用，已经有比较成熟的重要性采样的分布了，同时通过均匀分布求取采样点的方法也很成熟，下个章节就会说到。

随机数

在实际讨论重要性采样之前，我想先说说随机数，或者说是如何生成均匀分布的随机数，毕竟这是接下来所有采样的数据源头。对于路径追踪的应用而言，我们希望这个随机数尽可能均匀和无偏，所以这里选择的是一个四维Blue Noise（天蓝噪声）：

如图，蓝噪声分布均匀且频率较高。理论上来讲，要对蓝噪声进行采样，最好使用分层等策略，但这里我图简单，就直接每帧用Math.random()传进来四个随机数，然后加一下算了...

fn getRandom(uv: vec2<f32>, i: i32) -> vec4<f32> {
  let noise: vec4<f32> = textureSampleLevel(u_noise, u_sampler, uv, 0.);

  return fract(material.u_randoms[i] + noise);
}

重要性采样

上一章节提到了重要性采样可以提高蒙特卡洛几分的采样有效性，来加快收敛速度，而重要性采样的核心有二：

找到合适的分布，求取PDF。
寻找通过均匀分布转换为该分布的方法。

在路径追踪中，我们一般需要对以下几种状况分别进行采样。接下来就从以上两点，论述这几种状况。

采样部分的代码都在buildin/shaders/sample.chuck.wgsl内。

漫反射半球采样

漫反射需要的是在半球空间内均匀采样，这里采用的是Cosine-Weighted Hemisphere Sampling，即先进行均匀的圆盘采样，然后转换到半球空间：

// 圆盘采样
fn sampleCircle(pi: vec2<f32>) -> vec2<f32> {
  let p: vec2<f32> = 2.0 * pi - 1.0;
  let greater: bool = abs(p.x) > abs(p.y);
  var r: f32;
  var theta: f32;

  if (greater) {
    r = p.x;
    theta = 0.25 * PI * p.y / p.x;
  } else {
    r = p.y;
    theta = PI * (0.5 - 0.25 * p.x / p.y);
  }

  return r * vec2<f32>(cos(theta), sin(theta));
}

// 半球采样
fn cosineSampleHemisphere(p: vec2<f32>) -> vec3<f32> {
  let h: vec2<f32> = sampleCircle(p);
  let z: f32 = sqrt(max(0.0, 1.0 - h.x * h.x - h.y * h.y));

  return vec3<f32>(h, z);
}

// 最终生成漫反射部分的入射光向量
fn calcDiffuseLightDir(basis: mat3x3<f32>, sign: f32, random: vec2<f32>) -> vec3<f32> {
  return basis * sign * cosineSampleHemisphere(random);
}

输入的random是一个均匀分布的随机向量，由前面章节论述的随机数提供，sign是后续要提到的一个法线的符号，而basis，顾名思义是通过法线生成的一个变换矩阵，用于cosineSampleHemisphere生成的本地单位空间的向量，转换到世界空间的法线半球内，这里使用的是pixar采用的一种算法：

fn orthonormalBasis(normal: vec3<f32>) -> mat3x3<f32> {
  var zsign: f32 = 1.;
  if (normal.z < 0.) {
    zsign = -1.;
  }
  let a: f32 = -1.0 / (zsign + normal.z);
  let b: f32 = normal.x * normal.y * a;
  let s: vec3<f32> = vec3<f32>(1.0 + zsign * normal.x * normal.x * a, zsign * b, -zsign * normal.x);
  let t: vec3<f32> = vec3<f32>(b, zsign + normal.y * normal.y * a, -normal.y);

  return mat3x3<f32>(s, t, normal);
}

这种分布的PDF为：

$$\frac{cos\theta}{\pi}$$

其中角度为法线和入射光线的夹角。

高光GGX采样

高光反射比较复杂，业界提出过的模型也比较多，这里最终采用的是目前工业界比较通用的GGX分布：

fn calcSpecularLightDir(basis: mat3x3<f32>, ray: Ray, hit: HitPoint, random: vec2<f32>) -> vec3<f32> {
  let phi: f32 = PI * 2. * random.x;
  let alpha: f32 = hit.pbrData.alphaRoughness;
  let cosTheta: f32 = sqrt((1.0 - random.y) / (1.0 + (alpha * alpha - 1.0) * random.y));
  let sinTheta: f32 = sqrt(1.0 - cosTheta * cosTheta);
  let halfVector: vec3<f32> = basis * hit.sign * vec3<f32>(sinTheta * cos(phi), sinTheta * sin(phi), cosTheta);

  return reflect(ray.dir, halfVector);
}

由于是高光反射，所以分布和法线相关很合理。而这种分布的PDF为：

$$\frac{D \vec N \cdot \vec H}{4\vec L \cdot \vec H}$$

其中D是法线分布函数，N是法线，L是入射光线，H是半程向量。

直接光和间接光

在工程实现中，我们并非在路径追踪的每次迭代中直接求出入射光线，然后反向追踪，看其和物体还是光源相交。虽然在样本足够多的情况下得到的结果仍然是无偏的，但出于尽可能加快收敛速度的考量，我们需要思考如下事实：

对于某一着色点，光源往往是光的主要来源，提供了最多的能量，而从其他物体反射而来的能量则相对较少。

这里有两种解法，第一种是找到一个合适的分布，来使得采样采到光源的概率增加，但显然由于场景的动态性，这种分布十分难以找到。所以我们往往使用第二种方法——对渲染方程中的Li进行拆分，对光源单独采样：

$$\int_{\xi^{2}}f_{r}(p,w_{i},w_{o})L_{e}cos{\theta}dw_{i} + \int_{\xi^{2}}f_{r}(p,w_{i},w_{o})L_{s}cos{\theta}dw_{i}$$

如公式，我们将渲染方程的积分部分拆成了两个部分，第一个部分为直接光照，表示对光源的直接采样；第二个部分为间接光照，表示对其他部分的采样。间接光照的采样其实就是上面说的两种，而直接光照的采样，就是对面光源的采样。

面光源采样

本项目中我一共使用了disc和rect两种面光源，它们的采样和PDF本身都相对简单：

var samplePoint2D: vec2<f32>;
// 求出光源平面世界空间的法线
let normal: vec3<f32> = normalize((areaLight.worldTransform * vec4<f32>(0., 0., -1., 0.)).xyz);
var area: f32;
if (areaLight.areaMode == LIGHT_AREA_DISC) {
  // `disc`光源，进行圆盘采样并求得面积
  samplePoint2D = sampleCircle(random) * areaLight.areaSize.x;
  area = 2. * PI * areaLight.areaSize.x;
} else {
  // `rect`光源，可以非常简单得通过均匀分布变换采样而来，并求得面积
  samplePoint2D = (random) * areaLight.areaSize;
  area = samplePoint2D.x * samplePoint2D.y;
  samplePoint2D = samplePoint2D * 2. - areaLight.areaSize;
}

// 将采样点变换到世界空间，并求出光线向量
let samplePoint: vec4<f32> = areaLight.worldTransform * vec4<f32>(samplePoint2D.x, samplePoint2D.y, 0., 1.);
var sampleDir: vec3<f32> = samplePoint.xyz - hit.position;

// 算出光源平面和光线方向的夹角余弦
let cosine: f32 = dot(normal, sampleDir);
if (cosine > 0.) {
  // 证明光线是从光源背面而来，没有光照
  return vec3<f32>(0.);
}

// 通过投影面积和长度，求得最后的PDF
let maxT: f32 = length(sampleDir);
let pdf: f32 = maxT * maxT / (area * -cosine);
let directLight: vec3<f32> = areaLight.color.rgb / pdf;

可见在整个运算过程中，采样是比较简单的，最后PDF的求取中我们依靠了距离和投影面积，因为计算中有一个从本地空间投影到法线半球空间的过程。

环境光采样

理论上我们也需要支持环境光，环境光一半来自于一个环境贴图，或者说一般是是天空盒。对于环境贴图的采样，同样存在尽可能采样光源部分的问题，但这里我没做，有兴趣的同学可以自己查阅资料。对于环境贴图，我的做法就是很无脑得直接采样纹理颜色。

工程实现

原理到这就论述得差不多了，接下来是实际的工程实现。首先我们要给整个着色过程定义个框架。

光照部分的代码都在buildin/shaders/lighting.chuck.wgsl内。

框架

着色的过程从前面文章提到的GBuffer开始，GBuffer中存储了可以认为是第一次射线检测到的着色点的世界坐标，通过它可以很简单得重建出第一条射线：

let gBInfo: HitPoint = getGBInfo(baseIndex);

if (gBInfo.isLight) {
  textureStore(u_output, baseIndex, vec4<f32>(gBInfo.baseColor, 1.));
  return;
}

if (!gBInfo.hit) {
  // 处理没有被光栅化的像素，即等价为第一条射线没有相交的三角形
  // 直接采样环境贴图返回
  let t: vec4<f32> = global.u_skyVP * vec4<f32>(baseUV.x * 2. - 1., 1. - baseUV.y * 2., 1., 1.);
  let cubeUV: vec3<f32> = normalize(t.xyz / t.w);
  let bgColor: vec4<f32> = textureSampleLevel(u_envTexture, u_sampler, cubeUV, 0.);
  // rgbd
  textureStore(u_output, baseIndex, vec4<f32>(bgColor.rgb / bgColor.a * global.u_envColor.rgb, 1.));
  return;
}

let worldRay: Ray = genWorldRayByGBuffer(baseUV, gBInfo);

这是第一条出射光线，通过这个光线便可以进入实际的着色流程，然后不断反射、直接光照和间接光照，最后终止。这个过程中有两点需要注意：

终止条件

路颈追踪是理论上可以是一个无穷的过程，直到射线和场景不相交为止，但我们显然不能让其一直进行。在实际的测试中，一般每条光线进行七八次bounce（弹射）后就可以认为已经到极限了，每次bounce都是一次间接光照。对于实时而言，在不考虑透射的情况下，我们往往只会进行一次bounce，这意味着在最终效果中我们只会体现出一次的间接光照，从能量守恒的角度这自然是有瑕疵的，但效果也比传统得好得多。

由此来看，场景越亮、层次越丰富就代表越真实、效果越好。

当然如果不考虑这么苛刻的实时性，一般还有像是俄罗斯轮盘赌这样的策略来达成终止条件，也就是通过随机性来判定是否终止。

射线原点

在每次bounce过程中，我们都会生成一个由特定原点发出、到特定方向的射线。但由于浮点数运算精度等问题，如果只是刚好以着色点重心插值后的世界坐标为起点，可能会产生锯齿、乱纹等现象，这一般是由于不该自相交的时候自相交（比如普通反射）或该自相交的时候不自相交（比如阴影射线）。所以需要人为给射线原点加上一个偏移：

hit.position + light.next.dir * RAY_DIR_OFFSET + RAY_NORMAL_OFFSET * hit.normal

可见其实就是在法线方向、以及射线方向加了个微小的偏移。

光照累计

路径追踪是迭代累加的，在每次bounce的过程中，我们总是计算当前着色点的直接光照，然后计算间接光照的系数fr，而间接光照的能量部分则来自于下一次bounce，这就可以很清晰得得出一个计算步骤：

fn traceLight(startRay: Ray, gBInfo: HitPoint, baseUV: vec2<f32>, debugIndex: i32) -> vec3<f32> {
  var light: Light = calcLight(startRay, gBInfo, baseUV, 0, false, false, debugIndex);
  var lightColor: vec3<f32> = light.color;
  var throughEng: vec3<f32> = light.throughEng;
  var hit: HitPoint;
  var ray: Ray = light.next;
  var lightHited: vec4<f32>;
  var bounce: i32 = 0;

  loop {
    let preIsGlass = hit.isGlass;
    lightHited = hitTestLights(ray);
    hit = hitTest(ray);
    let isHitLight: bool = lightHited.a <= hit.hited;
    let isOut: bool = !hit.hit || isHitLight;

    if (isHitLight) {
      light.color = lightHited.rgb;
    } else {
      light = calcLight(ray, hit, baseUV, bounce, isLast, isOut);
      ray = light.next;
    }

    lightColor = lightColor + light.color * throughEng;
    throughEng = throughEng * light.throughEng;
    bounce = bounce + 1;

    if (max(throughEng.x, max(throughEng.y, throughEng.z)) < 0.01 || isOut) {
      break;
    }
  }

  return lightColor;
}

其中最值得关注的是lightColor和throughEng，第一个是当前直接光照的结果，第二个是出射（未被吸收）的能量比例。可见这里认为如果检测到了和光源相交，则直接累计，否则而进入光照计算阶段，计算完成后将当前的直接光照结果和累计至今的能量损耗计算，得到应当计入的能量。而光照的计算部分框架实现为：

fn calcLight(ray: Ray, hit: HitPoint, baseUV: vec2<f32>, bounce: i32, isLast: bool, isOut: bool) -> Light {
  var light: Light;
  // 计算随机数
  let random = getRandom(baseUV, bounce);

  if (isOut) {
    // 如果射线和场景无相交，则进行环境光照
    light.color = calcOutColor(ray, hit);
    return light;
  }

  // 直接光照
  light.color = calcDirectColor(ray, hit, random.zw);

  if (isLast) {
    // 最后一次测试，不再进行间接光照计算
    return light;
  }

  // 间接光照过程
  let probDiffuse: f32 = getDiffuseProb(hit);
  let isDiffuse: bool = random.z < probDiffuse;
  let nextDir: vec3<f32> = calcBrdfDir(ray, hit, isDiffuse, random.xy);

  if (isDiffuse) {
    light.throughEng = calcDiffuseFactor(ray, hit, nextDir.xyz, probDiffuse);
  } else {
    light.throughEng = calcSpecularFactor(ray, hit, nextDir.xyz, probDiffuse);
  }

  light.next = genRay(hit.position + light.next.dir * RAY_DIR_OFFSET + RAY_NORMAL_OFFSET * hit.normal, nextDir.xyz);
  return light;
}

可见光照计算切实被分为了直接光照、间接光照、环境光照（没有做特别处理，直接采样贴图）三部分。有了基本的框架，就可以进行真正的光照计算了。

直接光照

当射线和表面上的着色点相交后，首先要进行的是直接光照计算。这里分两步，第一步需要对光源进行采样，第二部则是用这个采样的结果进行计算。采样的部分在上面已经论述过（得到了入射光的方向和辐射度），接下来就是利用采样的结果进行fr的计算：

fn calcDirectColor(ray: Ray, hit: HitPoint, random: vec2<f32>) -> vec3<f32> {
  // 同上面光源采样部分的代码，求得了入射光方向`sampleLight`、距离`maxT`和辐射度`directLight`等

  let shadowInfo: FragmentInfo = hitTestShadow(sampleLight, maxT);

  if (shadowInfo.hit) {
    return vec3<f32>(0.);
  }

  let brdf = calcBrdfDirectOrSpecular(hit.pbrData, hit.normal, -ray.dir, sampleDir, true, 0.);

  return directLight * brdf;
}

可见这里主要有两步计算，第一步是进行阴影射线相交测试，这个在前面的文章《BVH与射线场景求交插值》中论述过，是为了判断光源和着色点之间是否有物体遮挡，如果有遮挡则证明在阴影范围内，直接返回。否则就进入下一步——计算fr，即代码中的brdf。

直接光照的fr使用BRDF的高光反射模型。

间接光照

由于高光反射也被间接光照使用，所以在合理先论述间接光照。间接光照由漫反射和高光反射两部分构成，有了着色点和出射光线的信息后，可以按照上面章节论述的采样方式分别求得漫反射和高光反射的入射光线，但这里要注意一点，那就是比例。在框架一节的代码中，有这么一句话：

let probDiffuse: f32 = getDiffuseProb(hit);

这求取的是漫反射的比例，还记得一开始的BRDF方程中的kd和ks吗?其实就是它。在工程实现中，为了效率，我们往往不会在同一次bounce计算漫反射和高光反射将它们加权相加，而是将这个比例作为概率，来作为当次要进行漫反射还是高光反射的判据，而它的实现为：

fn getDiffuseProb(hit: HitPoint) -> f32 {
  let lumDiffuse: f32 = max(.01, dot(hit.pbrData.diffuseColor, vec3<f32>(0.2125, 0.7154, 0.0721)));
  let lumSpecular: f32 = max(.01, dot(hit.pbrData.specularColor, vec3<f32>(0.2125, 0.7154, 0.0721)));

  return lumDiffuse / (lumDiffuse + lumSpecular);
}

计算中分别求得了着色点的名为diffuseColor和specularColor的变量的亮度，然后算出了漫反射的权重。那么这两个变量又是如何求得的呢？这就涉及到PBR材质的处理了。

材质预处理

在前面的文章，我们了解了使用的材质模型，其中有金属和高光两种工作流，有不同的系数和贴图，现在我们需要将其处理为BRDF需要的参数：

fn pbrPrepareData(
  isSpecGloss: bool,
  baseColor: vec3<f32>,
  metal: f32, rough: f32,
  spec: vec3<f32>, gloss: f32
) -> PBRData {
  var pbr: PBRData;

  var specularColor: vec3<f32>;
  var roughness: f32;

  if (!isSpecGloss) {
    // 金属工作流
    roughness = clamp(rough, 0.04, 1.0);
    let metallic: f32 = clamp(metal, 0.0, 1.0);
    let f0: vec3<f32> = vec3<f32>(0.04, 0.04, 0.04);

    specularColor = mix(f0, baseColor, vec3<f32>(metallic));
    pbr.diffuseColor = (1.0 - metallic) * (baseColor * (vec3<f32>(1.0, 1.0, 1.0) - f0));
  }
  else {
  // 高光工作流
    roughness = 1.0 - gloss;
    specularColor = spec;
    pbr.diffuseColor = baseColor * (1.0 - max(max(specularColor.r, specularColor.g), specularColor.b));
  }

  pbr.baseColor = baseColor;
  pbr.specularColor = specularColor;
  pbr.roughness = roughness;

  let reflectance: f32 = max(max(specularColor.r, specularColor.g), specularColor.b);
  pbr.reflectance90 = vec3<f32>(clamp(reflectance * 25.0, 0.0, 1.0));
  pbr.reflectance0 = specularColor.rgb;
  pbr.alphaRoughness = roughness * roughness;

  return pbr;
}

这个方法完成了材质数据的预处理，其主要通过两种工作流，统一计算出了粗糙度、漫反射颜色、高光反射颜色、菲涅尔系数等等。这里可以看到比如金属工作流和高光工作流的差异，主要在于高光工作流可以自己控制f0，而金属工作流可以由金属度来控制漫反射比例（完全金属没有漫反射）。

高光反射

有了材质数据，可以先来求高光反射。我实现了一个方法，用于求解高光反射，针对直接光照和间接光照的高光部分做了区分，但大部分计算都是一致的，区分主要在PDF部分。

fn calcBrdfDirectOrSpecular(
  pbr: PBRData, normal: vec3<f32>,
  viewDir: vec3<f32>, lightDir: vec3<f32>,
  isDirect: bool, probDiffuse: f32
)-> vec3<f32> {
  let H: vec3<f32> = normalize(lightDir + viewDir);
  let NdotV: f32 = clamp(abs(dot(normal, viewDir)), 0.001, 1.0);
  let NdotL: f32 = clamp(abs(dot(normal, lightDir)), 0.001, 1.0);
  let NdotH: f32 = clamp(abs(dot(normal, H)), 0.0, 1.0);
  let LdotH: f32 = clamp(abs(dot(lightDir, H)), 0.0, 1.0);
  let VdotH: f32 = clamp(dot(viewDir, H), 0.0, 1.0);
  // Calculate the shading terms for the microfacet specular shading model
  let F: vec3<f32> = pbrSpecularReflection(pbr.reflectance0, pbr.reflectance90, VdotH);
  let G: f32 = pbrGeometricOcclusion(NdotL, NdotV, pbr.alphaRoughness);
  let D: f32 = pbrMicrofacetDistribution(pbr.alphaRoughness, NdotH);

  let specular: vec3<f32> = F * G * D / (4.0 * NdotL * NdotV);

  if (isDirect) {
    let diffuse: vec3<f32> = NdotL * INV_PI * pbr.diffuseColor;
    return specular + diffuse;
  }

  let specularPdf: f32 = D * NdotH / (4.0 * LdotH);
  return NdotL * specular / (mix(specularPdf, 0., probDiffuse));
}

在求解的实现中，先不看PDF部分，主要计算的是specular，而其最主要的是菲涅尔项F、法线分布项D和几何遮蔽项G的实现。

F

菲涅尔项的求解实现为：

fn pbrSpecularReflection(reflectance0: vec3<f32>, reflectance90: vec3<f32>, VdotH: f32)-> vec3<f32> {
  return reflectance0 + (reflectance90 - reflectance0) * pow(clamp(1.0 - VdotH, 0.0, 1.0), 5.0);
}

这里采用的是Schilick近似方法。

D

法线分布我们采用的常见的GGX分布：

fn pbrMicrofacetDistribution(alphaRoughness: f32, NdotH: f32)-> f32 {
  let roughnessSq: f32 = alphaRoughness * alphaRoughness;
  let f: f32 = NdotH * NdotH * (roughnessSq - NdotH) + 1.0;
  return roughnessSq * INV_PI / (f * f);
}

G

几何遮蔽则使用Smith GGX近似：

fn pbrGeometricOcclusion(NdotL: f32, NdotV: f32, alphaRoughness: f32)-> f32 {
  let r: f32 = alphaRoughness * alphaRoughness;

  let attenuationL: f32 = 2.0 * NdotL / (NdotL + sqrt(r + (1.0 - r) * (NdotL * NdotL)));
  let attenuationV: f32 = 2.0 * NdotV / (NdotV + sqrt(r + (1.0 - r) * (NdotV * NdotV)));
  return attenuationL * attenuationV;
}

PDF

如果是直接光照，那么直接返回这个高光specular的值即可（因为直接光照的PDF已经在前面的计算除过了），但是对于间接光照，还是需要考虑PDF，以及漫反射的概率。前面提到过我们对高光使用的是GGX分布，其PDF公式翻译为代码为：

let specularPdf: f32 = D * NdotH / (4.0 * LdotH);

而在考虑漫反射概率后，其最终值为：

specular * NdotL / (mix(specularPdf, 0., probDiffuse));

漫反射

相对于高光，漫反射比较简单，其值根据原理所得即为hit.pbrData.diffuseColor * INV_PI，而PDF则为：

let diffusePdf: f32 = NdotL * INV_PI;

考虑到概率，最后的值为：

hit.pbrData.diffuseColor * INV_PI * NdotL / diffusePdf / probDiffuse;

化简后为：

hit.pbrData.diffuseColor / probDiffuse;

结果

至此，整个着色过程完成，由于是1SPP，并且只有一次bounce，在单帧着色后会得到一张充满噪点的结果：

那么接下来就自然要想到如何降噪了，下一文章将会提到。

【WebGPU实时光追美少女】BVH与射线场景求交插值

dtysky — Sunday, 26 Sep 2021 00:10:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

在上一篇文章管线组织与GBuffer中，我提到了路径追踪的第一步是射线和场景的求交，进一步引出了BVH的概念。在这一章，我将会论述如何利用BVH对场景中的所有三角形进行高效得分割和求交，并且给出得出交点后属性插值的方法。

不知道为何最近有点抑郁，所以更新效率低了一些...

求交部分的代码都在buildin/shaders/ray-tracing/hitTest.chunk.wgsl内。

射线和场景求交

首先要讨论的是射线和场景的求交，或者用在物理引擎中的叫法碰撞测试hitTest。我们并不需要先论述BVH这样的加速结构，因为无论哪种加速结构，到最后总是要进行射线和三角形的求交和插值。

射线和三角形描述

为了求交计算，需要先对射线和三角形进行描述。首先是射线，描述一条射线有很多种方式，这里使用最便于GPU计算的结构：

struct Ray {
  origin: vec3<f32>;
  dir: vec3<f32>;
  invDir: vec3<f32>;
};

通过一个原点origin和方向dir来使用方程p = origin + t * dir描述射线，invDir是方向向量的倒数，便于后续使用。有了射线的结构后，考虑如何生成射线，但这一部分我将放在下一章来讲。

接下来是三角形，在前面的文章我论述过如何将整个场景的数据进行合并，其中就包括了顶点数据indexData的合并。一个三角形由三个顶点描述，所以只需要知道三角形三个顶点的索引即可。这里先不讨论BVH，所以就认为我们是在顺序、每三个顶点遍历整个indexData即可。得到顶点索引后，便可以直接从storage buffer中获得对应的顶点属性，比如u_positions.value[index0]。

求交

有了射线和三角形的信息，便可以进行求交计算。射线和三角形的求交思路不止一种，一个最简单和直观的思路为：

先求射线和三角形所在平面的交点。
再判断交点是否在三角形内部。

但由于需要首先确定三角形所在平面，这么做实际运算效率其实不高，实际上我们可以直接通过方程来描述三角形，和射线方程联立整理，来简化计算：

空间射线方程：P = O + t * D
空间三角形方程：P = u * E1 + v * E2，其中E1 = V1 - V0和E2 = V2 - V0是两条边的向量，u、v是权重，V1、V2和V3是三个顶点。

联立后得到方程：O + t * D = u * E1 + v * E2，这是一个三元方程组，自然可以化简写成矩阵形式：

[-D, E1, E2] * [t, u, v] = T，其中T = O - V0，[-D, E1, E2]是3x3列主序矩阵，[t, u, v]是转置（赖得打公式了...

而经过克莱姆法则和混合积公式推导，记det = D x E2 · E1最后可写为：

t = (T x E1 * E2) / det
u = (D x E2 * T) / det
v = (T x E1 * E2) / det

如此一来，便可以求出这三个系数，并在求取的过程中顺便将不满足条件的情况判断出来：

// 判断是否相交，如果相交，返回所有的顶点属性
fn triangleHitTest(ray: Ray, leaf: BVHLeaf) -> FragmentInfo {
  var info: FragmentInfo;
  let indexes: vec3<u32> = leaf.indexes;
  // 索引出三个顶点
  info.p0 = u_positions.value[indexes[0]];
  info.p1 = u_positions.value[indexes[1]];
  info.p2 = u_positions.value[indexes[2]];

  let e1: vec3<f32> = info.p1 - info.p0;
  let e2: vec3<f32> = info.p2 - info.p0;
  let p: vec3<f32> = cross(ray.dir, e2);
  var det: f32 = dot(e1, p);
  var t: vec3<f32> = ray.origin - info.p0;

  // 保证`det`为正
  if (det < 0.) {
    t = -t;
    det = -det;
  }

  // `det`为0，三向量共面，算作不相交
  if (det < 0.0001) {
    return info;
  }

  let u: f32 = dot(t, p);

  // `u / det`必须在(0,1)
  if (u < 0. || u > det) {
    return info;
  }

  let q: vec3<f32> = cross(t, e1);
  let v: f32 = dot(ray.dir, q);

  // `v / det`和`(1 - v - u) / det`必须在(0,1)
  if (v < 0. || v + u - det > 0.) {
    return info;
  }

  let lt: f32 = dot(e2, q);

  // lt即为射线方程的`t`，由于是射线，其必须大于0
  if (lt < 0.) {
    return info;
  }

  let invDet: f32 = 1. / det;
  info.weights = vec3<f32>(0., u, v) * invDet;
  info.weights.x = 1. - info.weights.y - info.weights.z;

  info.hit = true;
  info.t = lt * invDet;
  info.hitPoint = ray.origin + ray.dir * info.t;
  info.uv0 = u_uvs.value[indexes.x];
  info.uv1 = u_uvs.value[indexes.y];
  info.uv2 = u_uvs.value[indexes.z];
  info.n0 = u_normals.value[indexes.x];
  info.n1 = u_normals.value[indexes.y];
  info.n2 = u_normals.value[indexes.z];
  info.meshIndex = u_meshMatIndexes.value[indexes.x].x;
  info.matIndex = u_meshMatIndexes.value[indexes.x].y;
  let metallicRoughnessFactorNormalScaleMaterialType: vec4<f32> = material.u_metallicRoughnessFactorNormalScaleMaterialTypes[info.matIndex];
  info.matType = u32(metallicRoughnessFactorNormalScaleMaterialType[3]);
}

如果这些测试都通过，则射线和三角形相交，而我们也顺便得到了u、v、det，通过它们，也就顺便获得了重心坐标。于此同时，我还将属于这个三角形的三个顶点属性都存了下来，以供下一个阶段做插值。

重心坐标插值

重心坐标插值这个概念在传统光栅化渲染器的栅格化一步也会提到，即当某个像素被一个平面三角形覆盖时，需要通过三角形的三个顶点属性算出当前像素实际的顶点属性。而对于路径追踪渲染器，由于同样是用三角形描述场景，所以也需要这么一个插值的过程，来计算出交点实际的顶点属性值。

所谓重心坐标，就是上面的info.weights。对于一个三角形内的点，它们都在(0,1)之间，记录了三角形的每个顶点到交点的距离的比例，从这个角度而言，它们实际上也是这个交点相对于三角形三个顶点的权重。

// 通过相交点的参数，求取最终插值后的结果并返回
fn fillHitPoint(frag: FragmentInfo, ray: Ray) -> HitPoint {
  var info: HitPoint;

  info.hit = true;
  info.hited = frag.t;
  info.meshIndex = frag.meshIndex;
  info.matIndex = frag.matIndex;
  let metallicRoughnessFactorNormalScaleMaterialType: vec4<f32> = material.u_metallicRoughnessFactorNormalScaleMaterialTypes[frag.matIndex];
  info.position = frag.p0 * frag.weights[0] + frag.p1 * frag.weights[1] + frag.p2 * frag.weights[2];
  let uv: vec2<f32> = frag.uv0 * frag.weights[0] + frag.uv1 * frag.weights[1] + frag.uv2 * frag.weights[2];
  let textureIds: vec4<i32> = material.u_matId2TexturesId[frag.matIndex];  
  let faceNormal: vec3<f32> = getFaceNormal(frag);
  info.sign = sign(dot(faceNormal, -ray.dir));
  info.normal = info.sign * getNormal(frag, uv, textureIds[1], metallicRoughnessFactorNormalScaleMaterialType[2]);
  let baseColor: vec4<f32> = getBaseColor(material.u_baseColorFactors[frag.matIndex], textureIds[0], uv);
  info.baseColor = baseColor.rgb;
  info.glass = baseColor.a;
  info.matType = frag.matType;
  info.isSpecGloss = isMatSpecGloss(frag.matType);
  info.isGlass = isMatGlass(frag.matType);

  if (info.isSpecGloss) {
    let specularGlossinessFactors: vec4<f32> = material.u_specularGlossinessFactors[frag.matIndex];
    info.spec = getSpecular(specularGlossinessFactors.xyz, textureIds[2], uv).rgb;
    info.gloss = getGlossiness(specularGlossinessFactors[3], textureIds[2], uv);
  } else {
    info.metal = getMetallic(metallicRoughnessFactorNormalScaleMaterialType[0], textureIds[2], uv);
    info.rough = getRoughness(metallicRoughnessFactorNormalScaleMaterialType[1], textureIds[2], uv);
  }

  info.pbrData = pbrPrepareData(info.isSpecGloss, info.baseColor, info.metal, info.rough, info.spec, info.gloss);

  return info;
}

以上是插值、求得最后结果的逻辑，可以见到像是position、uv之类的顶点属性都使用了重心坐标进行插值，而后也是用插值后的结果来采样贴图、计算材质属性的。

加速结构

如果不考虑性能，理论上上面的算法已经足够满足需求，我们只需要在每次发射射线的时候用该射线和场景内所有三角形求交，得到所有相交的点，然后找到其中离射线原点最近的即可。然而这是不现实的，在当前的这个时代，一个场景有上万上十万个三角形都挺正常，在实时的情况下即便是1SPP开销都是巨大的，所以这就需要我们有办法来加速整个求交的过程，也就引出了接下来要论述的——加速结构。

常见加速结构

加速结构的本质在于场景划分，通过合适的算法划分场景，来达到索引优化，最终减少真正的计算。场景划分不仅仅用于路径追踪，实际上在传统的实时渲染中也有很大的作用，比如ForwardAdd中的多光源实现等等。

如图，常见的加速结构有八叉树、KD树、BSP树等等。但他们都属于空间划分，而空间划分对于我们的场景有很大的劣势：

物体可能存在与多个划分区域，划分不彻底。
为了建立正确的划分，需要求取区域和三角形的相交。

所以在实时光追的引擎中，大家一般都使用BVH，即层次包围盒：

如图，这种结构不针对空间，而是根据物体的层次来对场景做划分。这样可以保证每个三角形都存在于唯一的划分区域内，同时整棵树比较平衡、最大深度低，而且构建十分简单。但当然世上没有免费的优化，其代价为：

由于不是空间划分，所以包围盒之间可能重叠，必须完全遍历整棵树才能得到最终结果，某些情况下相对求交效率可能低一些。
虽然构建效率高，但结构变了需要完全重建。不过这一部分已经被现代算法优化得很好了，有GPU算法（但本文不会提及）。

不过相对来讲，BVH仍然是当下最适合实时路径追踪的加速结构。

构造BVH

构造BVH可以在CPU进行，也可以在GPU进行（使用莫顿码），但由于个人精力有限，所以这里只实现了传统CPU的版本。

CPU部分构造BVH的代码全部在extension/BVH.ts内。

这里我不会讲所有的构建的代码都事无巨细列出来，只会说一些思路，具体的可以参考实际代码。

简单来讲，为了构建一个BVH，我们至少需要三步：

通过当前合并好的三角形，求取每个三角形的包围盒（世界空间）。
通过这些包围盒，构建二叉树，树的叶子节点为实际的三角形信息，其他为包围盒信息。
将树状结构打平为紧密的数组来存储。

所以我也讲这三步实现为了三个方法。

求取包围盒

首先需要一个数据结构来描述包围盒，其声明为：

export class Bounds {
  // 最大边界
  public max: Float32Array;
  // 最小边界
  public min: Float32Array;
  // 中点
  get center(): Float32Array;
  // 尺寸
  get size(): number;
  // 长度最大的轴
  get maxExtends(): EAxis;
  // 包围盒的表面积
  get surfaceArea(): number ;

  // 生成一个空的包围盒
  public initEmpty(): Bounds;
  // 从顶点生成一个包围盒
  public fromVertexes(v1: Float32Array, v2: Float32Array, v3: Float32Array): Bounds;
  // 扩张一个包围盒
  public update(v: Float32Array): Bounds;
  // 合并另一个包围盒，求并
  public mergeBounds(bounds: Bounds): Bounds;
  // 一个点是否在包围盒内
  public pointIn(p: Float32Array): boolean;
  // 获取一个点与包围盒某个轴最小值的偏移比例，一般0~1
  public getOffset(axis: EAxis, v: Float32Array): number;
}

这个类也是接下来所有操作的基础。有了它，便可以很简单地求得所有三角形的包围盒了：

protected _setupBoundsInfo = (worldPositions: Float32Array, indexes: Uint32Array) => {
  this._boundsInfos = [];

  for (let i = 0; i < indexes.length; i += 3) {
    const idxes = indexes.slice(i, i + 3);

    // 从`worldPositions`中解出每个顶点需要的数据
    copyTypedArray(3, tmpV1, 0, worldPositions, idxes[0] * 4);
    copyTypedArray(3, tmpV2, 0, worldPositions, idxes[1] * 4);
    copyTypedArray(3, tmpV3, 0, worldPositions, idxes[2] * 4);

    // 构建包围盒
    const bounds = new Bounds().fromVertexes(tmpV1, tmpV2, tmpV3);
    // 用于构建树的信息，包括包围盒本身，以及对应的三角形顶点索引
    this._boundsInfos.push({indexes: idxes, bounds});
  }
}

构建二叉树

有了包围盒后，便可以利用它们构建二叉树，构建BVH树的基本原理非常简单，首先我们要定义两个数据结构：结点BVHNode和叶子BVHLeaf：

export interface IBVHNode {
  // 沿哪个轴划分
  axis: EAxis;
  // 所有子节点合并的包围盒
  bounds: Bounds;
  // 左右子节点
  child0: IBVHNode | IBVHLeaf;
  child1: IBVHNode | IBVHLeaf;
  // 结点在树中的深度（层数）
  depth: number;
}

// 用于存储数个按策略不可划分的三角形
export interface IBVHLeaf {
  // 包含三角形的起始索引
  infoStart: number;
  // 包含三角形的结束索引
  infoEnd: number;
  // 所有子节点的包围盒
  bounds: Bounds;
}

最基础的BVH的构建本质上是一个递归，自顶而下不断二分，直到无法继续分割。同时在这个过程中将所有子节点的包围盒合并到父节点，最终无法分割的节点记为叶子节点BVHLeaf:

protected _buildRecursive(start: number, end: number, depth: number): IBVHNode | IBVHLeaf {
  const {_boundsInfos} = this;
  const bounds = new Bounds().initEmpty();
  // 合并所有子节点的包围盒
  for (let i = start; i < end; i += 1) {
    bounds.mergeBounds(_boundsInfos[i].bounds);
  }

  const nPrimitives = end - start;
  if (nPrimitives <= this._maxPrimitivesPerLeaf) {
    // 如果当前三角形数量不可再分割，直接返回叶子节点
    return { infoStart: start, infoEnd: end, bounds };
  } else {
    // 否则，通过一定规则算出新的分割点`mid`，进行下一轮递归
    // 这里还可能执行一些图元顺序的调整，来达到最有分割，分割有不同的策略

    // 递归计算左右子节点
    const child0 = this._buildRecursive(start, mid, depth + 1);
    const child1 = this._buildRecursive(mid, end, depth + 1);

    // 返回新的`BVHNode`
    return {
      bounds: new Bounds().initEmpty().mergeBounds(child0.bounds).mergeBounds(child1.bounds),
      axis: dim, child0, child1, depth
    };
  }
}

可见原理确实很简单，实际上对于这种传统的BVH构建算法，最精髓的在于注释中写道的分割策略。考察一个BVH的构建是否优秀，一般需要评估两点：

在相同的图元数量下，BVH的层数是否最低。
每一层两个子节点中的包围盒重叠程度是否足够低。

围绕这两点有各种不同的算法来权衡，在本项目的实现中，使用的是SAH - Surface Area Heuristic，即表面积启发式算法。这是一种从概率角度的优化，从理论上来讲，一条射线和场景求交的代价，主要由和图元即三角形的代价来决定，一次求交中计算的图元数量越多，也就意味着效率越低。而和图元求交的概率，又可以用包含图元的包围盒的重叠程度来表征，进一步可以用包围盒的表面积来表征，最大程度减少包围盒的表面积，就是SAH的目的，所以它实际上是解决了上面的第二个问题。

如图，实现上来讲，我们可以先求得所有包围盒中心所构成的最大包围盒，以此包围盒最长的轴作为用于切分的轴。如果包围盒已然不可划分（min=max），则直接返回，接着如果目前图元数量小于一定级别，则使用简单的包围盒中心位置做快速选择nth_element划分；再否则就进行正常的SAH，这里使用了一种基于均分的buckets（桶）的算法）——将图元按照中心位置划分到不同的桶内，再从低到高不断合并这些桶来求得划分代价，接着得出最低的划分代价，最终按照这个最低代价的桶为中点进行划分。实现详见代码。

打平为数组

有了BVH树还不够，因为最后一步要送到CS内进行最后的求交，所以必须要将其组装成一个storage buffer，这就要求我们设计一种紧凑的数据结构，来将整棵树存储到一个ArrayBuffer中。而我设计的结构如下:

对于Node，使用uint32 x 1来存储子节点的类型（最低位，0为Node，1为Leaf）和偏移，float x 3存储子节点的包围盒，共两个子节点，消耗8个float的长度。
对于Leaf，使用uint32 x 1来存储接下来有几个三角形属于同一个节点，uint32 x 3存储当前三角形的三个顶点索引。

有了结构，整个Buffer的构建也就比较简单，同样是递归构建：

protected _traverseNode = (
  node: IBVHNode | IBVHLeaf,
  info: {maxDepth: number, nodes: number[], leaves: number[]},
  depth: number = 1,
  parentOffset: number = -1,
  childIndex: number = 0
) => {
  info.maxDepth = Math.max(depth, info.maxDepth);
  const {nodes, leaves} = info;
  const {_boundsInfos, _bvhNodes, _bvhLeaves} = this;

  if (isBVHLeaf(node)) {
    _bvhLeaves.push(node);
    if (parentOffset >= 0) {
      nodes[parentOffset * 8 + childIndex] = (1 << 31) | (leaves.length / 4);
    }

    const count = node.infoEnd - node.infoStart;
    for (let i = node.infoStart; i < node.infoEnd; i += 1) {
      const idxes = _boundsInfos[i].indexes;

      leaves.push(count, idxes[0], idxes[1], idxes[2]);
    }
  } else {
    _bvhNodes.push(node);
    const bounds = node.bounds;
    const nodeOffset = nodes.length / 8;

    if (parentOffset >= 0) {
      nodes[parentOffset * 8 + childIndex] = nodeOffset * 2;
    }

    nodes.push(
      0, bounds.min[0], bounds.min[1], bounds.min[2],
      0, bounds.max[0], bounds.max[1], bounds.max[2]
    );

    this._traverseNode(node.child0, info, depth + 1, nodeOffset, 0);
    this._traverseNode(node.child1, info, depth + 1, nodeOffset, 4);
  }
}

注意这里我们构建好的Buffer正好是16字节对齐的。

BVH求交

构建了BVH后，使用u_bvh作为storage buffer传给CS来进行求交。BVH的求交远离比较简单巧妙，由于BVH本质上是一种AABB，同时和射线也并不需要得到真正的交点，只需要得到是否相交的结果。所以可以将其视为三对互相平行的平板，如图：

可以将射线投影到三个平面，最终需要满足最大的xmin - origin小于最小的xmax - origin，这个原理也好理解，如果将前者理解为光线进入盒子的时间，后者理解为光线离开盒子的时间，那么我们最终要保证进入时间小于离开时间：

fn boxHitTest(ray: Ray, max: vec3<f32>, min: vec3<f32>) -> f32 {
  let t1: vec3<f32> = (min - ray.origin) * ray.invDir;
  let t2: vec3<f32> = (max - ray.origin) * ray.invDir;
  let tvmin: vec3<f32> = min(t1, t2);
  let tvmax: vec3<f32> = max(t1, t2);
  let tmin: f32 = max(tvmin.x, max(tvmin.y, tvmin.z));
  let tmax: f32 = min(tvmax.x, min(tvmax.y, tvmax.z));

  if (tmax - tmin < 0.) {
    return -1.;
  }

  if (tmin > 0.) {
    return tmin;
  }

  return tmax;
}

以上方法返回的结果如果大于0，则表示射线和BVH相交，可见比起三角形求交，是十分高效的。而其中的max和min则是通过对数据的decode得来的：

struct Child {
  isLeaf: bool;
  offset: u32;
};

fn decodeChild(index: u32) -> Child {
  return Child((index >> 31u) != 0u, (index << 1u) >> 1u);
}

fn getBVHNodeInfo(offset: u32) -> BVHNode {
  var node: BVHNode;
  let data0: vec4<f32> = u_bvh.value[offset];
  let data1: vec4<f32> = u_bvh.value[offset + 1u];
  node.child0Index = bitcast<u32>(data0[0]);
  node.child1Index = bitcast<u32>(data1[0]);
  node.min = data0.yzw;
  node.max = data1.yzw;

  return node;
}

fn getBVHLeafInfo(offset: u32) -> BVHLeaf {
  var leaf: BVHLeaf;
  let data1: vec4<f32> = u_bvh.value[offset];
  leaf.primitives = bitcast<u32>(data1.x);
  leaf.indexes.x = bitcast<u32>(data1.y);
  leaf.indexes.y = bitcast<u32>(data1.z);
  leaf.indexes.z = bitcast<u32>(data1.w);

  return leaf;
}

综合实现

有了BVH、BVH求交算法、三角形求交算法、插值算法，便可以组装出最终的求交方案。但在这之前，我们需要先明确求交的分类：

普通射线求交：最普通的求交，用于间接光照，需要找到离射线原点最近的三角形。
阴影射线求交：阴影射线，用于直接光照，详细在后面文章会讲到，只需要判断射线和一定范围内的三角形有相交。
光源求交：和光源求交，是和三角形不同的另一种算法，在这里顺便也讲了。

一般来讲，普通求交要和光源求交联合起来，因为如果射线最先相交的是光源，还进行正常的表面计算会出现问题，阴影射线求交理论同理（若只有一个光源可以忽略）。

普通射线

由于要寻找的是离射线原点最近的交点，所以一定是遍历完整棵树才能停下，这可以用一次dfs实现，途中还可以直接剪枝。dfs最简单的是使用递归，但显然我们不能再wgsl里使用递归，所以只能自己维护一个递归栈，用迭代来实现了：

fn hitTest(ray: Ray) -> HitPoint {
  var hit: HitPoint;
  var fragInfo: FragmentInfo;
  // 初始化为最大长度
  fragInfo.t = MAX_RAY_LENGTH;
  var node: BVHNode;
  // 构建BVH深度大小的结点栈，栈中数据为结点索引
  var nodeStack: array<u32, ${BVH_DEPTH}>;
  nodeStack[0] = 0u;
  var stackDepth: i32 = 0;

  loop {
    // 当前深度小于10，栈中已无结点，结束
     if (stackDepth < 0) {
       break;
     }

    let child = decodeChild(nodeStack[stackDepth]);
    stackDepth = stackDepth - 1;

    if (child.isLeaf) {
      // 进行叶子的求交，内部本质上是进行了三角形求交，最终返回求交的信息
      let info: FragmentInfo = leafHitTest(ray, child.offset, false);

      if (info.hit && info.t < fragInfo.t) {
        // 如果交点比当前交点近，则使用替换
        fragInfo = info;
      }

      continue;
    }

    node = getBVHNodeInfo(child.offset);
    // 进行结点的求交
    let hited: f32 = boxHitTest(ray, node.max, node.min);

    if (hited < 0.) {
      continue;
    }

    // 相交，两个子节点入栈，进入下一次迭代
    stackDepth = stackDepth + 1;
    nodeStack[stackDepth] = node.child0Index;
    stackDepth = stackDepth + 1;
    nodeStack[stackDepth] = node.child1Index;
  }

  if (fragInfo.hit) {
    // 如果有交点，进行重心坐标插值，同时生成材质属性
    hit = fillHitPoint(fragInfo, ray);
  }

  return hit;
}

阴影射线

阴影射线求交和普通求交大差不差，唯一的区别在于需要给定一个初始的最大值maxT，即射线原点到光源之上采样点之间的距离，并且判断有相交后即可结束求交，立即返回：

fn hitTestShadow(ray: Ray, maxT: f32) -> FragmentInfo {
  var fragInfo: FragmentInfo;
  var node: BVHNode;
  var nodeStack: array<u32, ${BVH_DEPTH}>;
  nodeStack[0] = 0u;
  var stackDepth: i32 = 0;

  loop {
     if (stackDepth < 0) {
       break;
     }

    let child = decodeChild(nodeStack[stackDepth]);
    stackDepth = stackDepth - 1;

    if (child.isLeaf) {
      let info: FragmentInfo = leafHitTest(ray, child.offset, true);

      if (info.hit && info.t < maxT && info.t > EPS) {
        // 判断在射线原点和光源采样点之间有遮挡，返回
        return info;
      }

      continue;
    }

    node = getBVHNodeInfo(child.offset);
    let hited: f32 = boxHitTest(ray, node.max, node.min);

    if (hited < 0.) {
      continue;
    }

    stackDepth = stackDepth + 1;
    nodeStack[stackDepth] = node.child0Index;
    stackDepth = stackDepth + 1;
    nodeStack[stackDepth] = node.child1Index;
  }

  return fragInfo;
}

光源

最后就是和光源的求交了，早在前面的文章WebGPU基础与简单渲染器中，我们就提到了本引擎是如何描述光源，尤其是面光源的：

struct LightInfo {
  lightType: u32;
  areaMode: u32;
  areaSize: vec2<f32>;
  color: vec4<f32>;
  worldTransform: mat4x4<f32>;
  worldTransformInverse: mat4x4<f32>;
};

而对于面光源（无论是什么形状），一个通用的做法是先求取射线和平面的交点，然后判断交点是否在光源内，这个也就是本文一开始提到的、低效的三维平面求交。但这里好在引擎已经提供了光源的worldTransformInverse，所以理论上我们可以认为面光源总是在自己的本地空间（XZ平面），此时只要反向将射线变换到光源的本地空间，问题就变得简单了很多：

求取射线与平面的交点被简化了，最终得到的是一个XZ平面的点。
判定交点和光源的关系被简化到了二维空间。

目前引擎支持disc和rect两种面光源，在平面上可以非常简单得判定包含关系：

fn hitTestXZPlane(ray: Ray, inverseMat: mat4x4<f32>) -> vec3<f32> {
  // 射线方向变换到光源本地空间
  let invDir: vec3<f32> = normalize((inverseMat * vec4<f32>(ray.dir, 0.)).xyz);
  // 光源本地空间法线的反向基向量
  let normal: vec3<f32> = vec3<f32>(0., 0., 1.);
  let dot: f32 = dot(invDir, normal);

  if (abs(dot) < EPS) {
    // 射线平行或背向光源
    return vec3<f32>(MAX_RAY_LENGTH, MAX_RAY_LENGTH, MAX_RAY_LENGTH);
  }

  // 射线原点变换到光源本地空间
  let invOrigin: vec3<f32> = (inverseMat * vec4<f32>(ray.origin, 1.)).xyz;
  // 求取相交段的射线步长
  let t: f32 = dot(-invOrigin, normal) / dot;

  if (t < EPS) {
    return vec3<f32>(MAX_RAY_LENGTH, MAX_RAY_LENGTH, MAX_RAY_LENGTH);
  }

  return vec3<f32>(invOrigin.xy + t * invDir.xy, t);
}

fn hitTestLights(ray: Ray) -> vec4<f32> {
  let areaLight: LightInfo = global.u_lightInfos[0];
  // xyz存光的颜色，w存射线相交段的`t`
  var res: vec4<f32> = vec4<f32>(areaLight.color.rgb, MAX_RAY_LENGTH);
  // 目前只支持一个光源
  if (areaLight.lightType != LIGHT_TYPE_AREA) {
    return res;
  }

  // 求得XZ平面上的交点，以及相交段射线的`t`
  let xyt: vec3<f32> = hitTestXZPlane(ray, areaLight.worldTransformInverse);

  var hit: bool = false;
  if (areaLight.areaMode == LIGHT_AREA_DISC) {
    // 判定是否在圆盘内
    hit = length(xyt.xy) < areaLight.areaSize.x;
  } else {
    // 判定是否在矩形内
    hit = all(abs(xyt.xy) < areaLight.areaSize / 2.);
  }

  if (hit) {
    res.a = xyt.z;
  }

  return res;
}

展示

以上就是本文的所有内容，但在最后，为了调试，我还做了一个功能来将将整个BVH的包围盒画出来，其实原理也很简单：

通过包围盒信息，生成line类型的图元数据（主要是索引数据是一个图元两个点，而非三角形的三个点）。
组装Mesh绘制。

由于太过简单这里就不详细讲了，直接看看最后的结果吧：

【WebGPU实时光追美少女】管线组织与GBuffer

dtysky — Friday, 17 Sep 2021 02:00:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

上一篇文章场景数据组织与合并，我们讨论了要使用的材质、以及如何组织好场景数据，并对场景数据进行了合并。现在我们可以认为有了一个很大的Geometry，其中存储着整个场景所有的图元信息，还有合并好的Uniform、Texture，以便在渲染过程中查找到物体上某一点对应的材质数据。那么下一步，就是如何利用这些数据进行渲染了。

路径追踪管线

路径追踪管线和传统的光栅化管线是完全不同的，目前一般有两种方案来实现。在设计整个管线之前，我们要先回顾并深入一下路径追踪的原理。

追踪过程

还是这张图，但这次我们要更深入一些。首先从左侧的相机看起，路径追踪起始于相机发出的若干世界空间的射线，这些射线进入场景后：

首先进行相交测试，从结果上来看，我们需要的是第一个和射线相交的三角面，换言之是离相机最近的相交三角面。
获取相交点的材质数据，进行着色。
生成下一条/多条射线。
对每一条射线进行相交测试、着色。
循环过程直到满足结束条件，累计结果。

通过对这几步的抽象，我们已经可以给出一个不同于传统光栅化流程的全新管线实现，事实上这就是新一代图形API提供的光线追踪管线（XXX Ray tracing pipeline）的实现，比如M$的DXR。不同于光栅化的VS -> Rasterization -> FS管线，这个管线被抽象为下图的形式：

在RTX硬件的支持下，这个管线的性能是非常不错的，也可以和光栅化管线同时存在、相互协作。但显然现在WebGPU目前是不支持的，所以我们只能寻求另一种方案——CS + GBuffer的混合方案。

CS和GBuffer混合方案

说是CS（计算着色器）和GBuffer（几何缓冲对象）的混合方案，实际上只有CS也可以。让我们考虑一下，CS使用通用逻辑单元进行计算，理论上可以完成任何渲染需要的计算，甚至是光栅化也可以，只不过在大部分情况下比较慢（但事实上已经有这样的应用了）。我们现在已经有了整个场景需要用于渲染的的所有数据，那么将它们直接传给CS，理论上当然可以完成路径追踪的计算，只不过比起专用硬件慢了一些而已。

既然如此，我们又为何需要GBuffer呢？这不是画蛇添足？其实很简单——为了性能，虽然CS比起硬件专用加速方案慢，但能快一点总归是好的，而且这在原理上也是行得通的。

让我们再回忆下光栅化的过程，光栅化最重要的分为两步——投影和栅格化，投影是将3D空间的三角面变换到近裁剪平面的三角形，栅格化则是将近裁剪平面的矢量三角形变换为一个个像素（片元）；再对比下路径追踪流程——根据相机投影模式，从近裁剪平面的像素发射一条条射线，找到射线相交的最近三角面上的点。

相信读者已经可以觉察到了——从结果上来讲，光栅化，实际上就是路径追踪的第一步，也就是求取某个像素发出的射线和场景中三角面的第一个交点。而光栅化由于硬件的高度优化，速度是非常快的。而除了速度优势，GBuffer在后面要提到的降噪方面也有用处。

所以总结来看，到此我们的渲染管线至少有两步——

通过光栅化流程渲染GBuffer。
通过CS进行后续的路径追踪流程。

BVH

在上面的绘制流程我们提到了第一步是求得射线和场景中最近的三角面的交点，但并没有提到怎么做。最简单的方法当然是遍历整个场景所有三角面，但考虑到射线数量以及三角面的数量，这显然是不现实的，所以需要一个结构来进行加速，加速结构的分类会在后面讲到，这里只给结论——我最后使用了BVH，这也是业界一般的做法。

由于在相交测试就会使用到BVH，所以它的构建应当先于整个CS流程。但概论中已经说了，本项目目前只针对静态场景，不涉及到Mesh的增减，所以BVH只需要在资源加载、场景组织完成后做一次即可。

降噪和色调映射

最后还需要的流程就是降噪和色调映射了。由于我们要做的是实时路径追踪，并且由于原理（涉及到积分），每次弹射出复数射线进行积分显然是不现实的，所以只能时间换空间——利用随机采样的原理，每帧渲染出一个带有大量噪点的结果，最后进行时域滤波，再辅以空间滤波，得到相对可以接受的最终结果。这整个滤波过程就是降噪。

同时路径追踪渲染出的结果最终基本都是高动态范围（HDR）的，为了让显示器能够正确显示，我们最后还要进行一个通用操作色调映射（Tone mapping），将图像亮度压缩到LDR范围，并尽可能保证细节。

下图表现出了降噪前和降噪+色调映射后的结果对比：

总结

至此，可以总结出整个路径追踪管线的组成：

构建BVH。
通过光栅化流程渲染GBuffer。
通过CS进行后续的路径追踪流程。
降噪。
色调映射。

GBuffer渲染

讲完了管线的组成，就让我们以GBuffer为开端，顺便实战一下之前文章论述的这个WebGPU渲染器吧。

构建Mesh

GBuffer的渲染走的是正常的光栅化流程，所以需要构建一个Mesh，这个Mesh需要的Geometry和Material可以直接使用上一篇文章合并过的场景数据：

protected _buildGBufferMesh = () => {
  const { _attributesInfo, _indexInfo, _commonUniforms } = this;

  const geometry = new Geometry(
    Object.keys(_attributesInfo).map((name, index) => {
      const { value, length, format } = (_attributesInfo[name] as any) as IBVHAttributeValue;

      return {
        layout: {
          arrayStride: length * 4,
          attributes: [{
            name, offset: 0, format, shaderLocation: index
          }]
        },
        data: value,
        usage: GPUBufferUsage.STORAGE
      }
    }),
    _indexInfo.value,
    _indexInfo.value.length
  );

  const material = new Material(buildinEffects.rRTGBuffer, {
    u_matId2TexturesId: _commonUniforms.matId2TexturesId,
    u_baseColorFactors: _commonUniforms.baseColorFactors,
    u_metallicRoughnessFactorNormalScaleMaterialTypes: _commonUniforms.metallicRoughnessFactorNormalScaleMaterialTypes,
    u_specularGlossinessFactors: _commonUniforms.specularGlossinessFactors,
    u_baseColorTextures: _commonUniforms.baseColorTextures,
    u_normalTextures: _commonUniforms.normalTextures,
    u_metalRoughOrSpecGlossTextures: _commonUniforms.metalRoughOrSpecGlossTextures
  });

  this._gBufferMesh = new Mesh(geometry, material);
}

可见这里构建的Geometry没有使用交错形式，而是使用了多个Buffer，每个Buffer对应一个Attribute。而Material的UniformBlock直接使用了场景合并过的各个Uniform和Texture，同时使用了buildinEffects.rRTGBuffer这个Effect。

Effect

buildinEffects是引擎内置的一些Effect，rRTGBuffer如其名是用于渲染GBuffer的，前缀的r表明是用于Render的。对于一个Effect，最重要的就是它的Shader。

首先是顶点着色器：

struct VertexOutput {
  [[builtin(position)]] position: vec4<f32>;
  [[location(0)]] wPosition: vec4<f32>;
  [[location(1)]] texcoord_0: vec2<f32>;
  [[location(2)]] normal: vec3<f32>;
  [[location(3)]] meshMatIndex: vec2<u32>;
};

[[stage(vertex)]]
fn main(attrs: Attrs) -> VertexOutput {
  var output: VertexOutput;

  let wPosition: vec4<f32> = vec4<f32>(attrs.position, 1.);

  output.position = global.u_vp * wPosition;
  output.wPosition = wPosition;
  output.texcoord_0 = attrs.texcoord_0;
  output.normal = attrs.normal;
  output.meshMatIndex.x = attrs.meshMatIndex.x;
  output.meshMatIndex.y = attrs.meshMatIndex.y;

  return output;
}

可见比较简单，由于直接使用了合并过的顶点数据，所以不需要Model -> World变换，输出给光栅器重点处理的position只需要乘以VP矩阵即可，剩下要用于插值的数据有世界坐标、UV和法线这三个f32向量，以及meshMatIndex这个存储顶点材质索引的u32向量。

之后是片段着色器：

struct VertexOutput {
  [[builtin(position)]] position: vec4<f32>;
  [[location(0)]] wPosition: vec4<f32>;
  [[location(1)]] texcoord_0: vec2<f32>;
  [[location(2)]] normal: vec3<f32>;
  [[location(3)]] meshMatIndex: vec2<u32>;
};

struct FragmentOutput {
  [[location(0)]] positionMetalOrSpec: vec4<f32>;
  [[location(1)]] baseColorRoughOrGloss: vec4<f32>;
  [[location(2)]] normalGlass: vec4<f32>;
  [[location(3)]] meshIndexMatIndexMatType: vec4<u32>;
};

fn getRoughness(factor: f32, textureId: i32, uv: vec2<f32>) -> f32 {
  if (textureId == -1) {
    return factor;
  }

  return factor * textureSampleLevel(u_metalRoughOrSpecGlossTextures, u_sampler, uv, textureId, 0.).g;
}

fn getMetallic(factor: f32, textureId: i32, uv: vec2<f32>) -> f32 {
  if (textureId == -1) {
    return factor;
  }

  return factor * textureSampleLevel(u_metalRoughOrSpecGlossTextures, u_sampler, uv, textureId, 0.).b;
}

fn getSpecular(factor: vec3<f32>, textureId: i32, uv: vec2<f32>) -> vec3<f32> {
  if (textureId == -1) {
    return factor;
  }

  return factor * textureSampleLevel(u_metalRoughOrSpecGlossTextures, u_sampler, uv, textureId, 0.).rgb;
}

fn getGlossiness(factor: f32, textureId: i32, uv: vec2<f32>) -> f32 {
  if (textureId == -1) {
    return factor;
  }

  return factor * textureSampleLevel(u_metalRoughOrSpecGlossTextures, u_sampler, uv, textureId, 0.).a;
}

fn getBaseColor(factor: vec4<f32>, textureId: i32, uv: vec2<f32>) -> vec4<f32> {
  if (textureId == -1) {
    return factor;
  }

  return factor * textureSampleLevel(u_baseColorTextures, u_sampler, uv, textureId, 0.);
}

fn getFaceNormal(position: vec3<f32>) -> vec3<f32> {
  return normalize(cross(dpdy(position), dpdx(position)));
}

fn getNormal(
  vNormal: vec3<f32>, position: vec3<f32>, faceNormal: vec3<f32>,
  textureId: i32, uv: vec2<f32>, normalScale: f32
) -> vec3<f32> {
  var normal: vec3<f32> = normalize(vNormal);
  normal = normal * sign(dot(normal, faceNormal));

  if (textureId == -1) {
    return normal;
  }

  // http://www.thetenthplanet.de/archives/1180
  let dp1: vec3<f32> = dpdx(position);
  let dp2: vec3<f32> = dpdy(position);
  let duv1: vec2<f32> = dpdx(uv);
  let duv2: vec2<f32> = dpdy(uv);
  let dp2perp: vec3<f32> = cross(dp2, normal);
  let dp1perp: vec3<f32> = cross(normal, dp1);
  var dpdu: vec3<f32> = dp2perp * duv1.x + dp1perp * duv2.x;
  var dpdv: vec3<f32> = dp2perp * duv1.y + dp1perp * duv2.y;
  let invmax: f32 = inverseSqrt(max(dot(dpdu, dpdu), dot(dpdv, dpdv)));
  dpdu = dpdu * invmax;
  dpdv = dpdv * invmax;
  let tbn: mat3x3<f32> = mat3x3<f32>(dpdu, dpdv, normal);
  var tNormal: vec3<f32> = 2. * textureSample(u_normalTextures, u_sampler, uv, textureId).xyz - 1.;
  tNormal = tNormal * vec3<f32>(normalScale, normalScale, 1.);

  return normalize(tbn * tNormal);
}


[[stage(fragment)]]
fn main(vo: VertexOutput) -> FragmentOutput {
  var fo: FragmentOutput;

  let meshId: u32 = vo.meshMatIndex[0];
  let matId: u32 = vo.meshMatIndex[1];
  let metallicRoughnessFactorNormalScaleMaterialType: vec4<f32> = material.u_metallicRoughnessFactorNormalScaleMaterialTypes[matId];
  let specularGlossinessFactor: vec4<f32> = material.u_specularGlossinessFactors[matId];
  let textureIds: vec4<i32> = material.u_matId2TexturesId[matId];
  let matType = u32(metallicRoughnessFactorNormalScaleMaterialType[3]);
  let isSpecGloss: bool = isMatSpecGloss(matType);

  fo.positionMetalOrSpec = vec4<f32>(vo.wPosition.xyz, 0.);

  let baseColor: vec4<f32> = getBaseColor(material.u_baseColorFactors[matId], textureIds[0], vo.texcoord_0);
  fo.baseColorRoughOrGloss = vec4<f32>(baseColor.rgb, 0.);

  if (isSpecGloss) {
    fo.positionMetalOrSpec.w = getSpecular(specularGlossinessFactor.xyz, textureIds[2], vo.texcoord_0).r;
    fo.baseColorRoughOrGloss.w = getGlossiness(specularGlossinessFactor[3], textureIds[2], vo.texcoord_0);
  } else {
    fo.positionMetalOrSpec.w = getMetallic(metallicRoughnessFactorNormalScaleMaterialType[0], textureIds[2], vo.texcoord_0);
    fo.baseColorRoughOrGloss.w = getRoughness(metallicRoughnessFactorNormalScaleMaterialType[1], textureIds[2], vo.texcoord_0);
  }

  let faceNormal: vec3<f32> = getFaceNormal(vo.wPosition.xyz);
  fo.normalGlass = vec4<f32>(
    getNormal(vo.normal, vo.wPosition.xyz, faceNormal, textureIds[1], vo.texcoord_0, metallicRoughnessFactorNormalScaleMaterialType[2]),
    baseColor.a
  );

  fo.meshIndexMatIndexMatType = vec4<u32>(meshId, matId, matType, 2u);

  return fo;
}

可见这个比较顶点处理就复杂多了，但其实也不难理解。从宏观角度来看，片元处理的目的就是将需要的数据写入到输出的目标纹理中，这里我们可以回忆一下在只文章WebGPU基础与简单渲染器中讲过的RenderTexture，那时候提到了它支持多渲染目标MRT，其实就是主要用在了GBuffer中。要使用MRT，我们首先需要在CPU创建一个RenderTexture（下一节会讲），然后在FS中按照顺序定义好FragmentOutput作为它的输出，即可完成CPU和GPU两端的映射。

在实际的Shader编程中，我们可以认为FS可以输出到不同的纹理，本FS就输出到了以下几个纹理中：

positionMetalOrSpec：存储世界空间的坐标，以及金属工作流下的metallic或者高光工作流下的specular，注意specular本来有三个通道，但这里只保留一个，这是出于节省空间，而且实际场合中其实一个通道也不是不行（逃。
baseColorRoughOrGloss：存储baseColor，以及金属工作流下的roughness或者高光工作流下的glossiness。
normalGlass：存储世界空间的顶点法线normal，以及透射材质的折射率的倒数glass，之所以存倒数，是因为实际应用中折射率基本都大于1，而调整的时候0~1比较好调。
meshIndexMatIndexMatType：存储顶点索引、材质索引、材质类型，注意这是一个u8向量，意味着整个场景支持的Mesh和材质数量最多256。

而其中的大部分计算其实都是索引，比如通过vo.meshMatIndex[1]拿到这个片元对应的材质id，然后通过material.u_matId2TexturesId[matId]获取到几种纹理的id数组，再通过textureIds[0]获取到对应baseColor纹理的id，最后用这个id和uv去用textureSampleLevel(u_baseColorTextures, u_sampler, uv, textureId, 0.)采样数组纹理，获得最终的baseColor值。

在这些最终输出到纹理的数据的计算中，有几个需要特别说明：

法线计算

和其他数据不同，这里法线的计算比较复杂，因为法线本身就有其复杂性，每个着色的片元都有自己的顶点法线、面法线和可能的法线贴图采样值：

顶点法线：顶点数据中的法线插值而来，如果没有法线贴图，就是最终的法线矢量的值。
面法线：顶点所在三角面的法线，一般用于和顶点法线计算求取法线矢量最终的方向。
法线贴图：由于物体的表面会有复杂的凹凸不平，全部用几何信息描述开销过高，而使用贴图来存储法线信息能有效降低开销，一般会构建一个切线空间，将实际的顶点法线换算到其中，在渲染时还原。为何要使用切线空间读者可以自行查找，不再赘述。

面法线的一般计算方法是利用三角面两个边向量的叉乘，在片元着色器中无法直接获取边向量的信息，但有Derivative functions，可以用于近似计算，具体实现为上面的getFaceNormal函数，这里我们计算了世界空间坐标对屏幕空间坐标的导数，最终近似求得世界空间的面法线。

而对于最终法线的求取，如果没有使用法线贴图，那么直接用已有的世界空间顶点法线和面法线点乘求得方向，返回即可。但如果有法线贴图，就需要涉及到切线空间的反变换了，如果使用传统的算法，还需要提供预计算的顶点切线数据Tangent，最终利用顶点法线、切线构造TBN矩阵，但由于懒得生成，这里就使用了这篇文章介绍的方法，其本质上是还原了切线的预计算过程。当然这也是近似，毕竟无法拿到真正的三角面的三个顶点数据。

meshIndexMatIndexMatType的alpha通道

读者可能刚才已经疑惑了为什么这个纹理的alpha通道要给个2，这其实是处于后续运算的考虑。在实际的渲染中，并非每个像素都会被三角面覆盖，所以一些像素是没有值的，对应于路径追踪流程，就是这个像素射出的射线和场景物体没有任何交点。至于为何是2而不是1，因为alpha会被相机clear为1，设计而已。

渲染和展示

现在我们有了GBuffer需要的Mesh，接下来只需要创建用于MRT的RenderTexture，并将它们关联起来：

this._gBufferRT = new H.RenderTexture({
  width: renderEnv.width,
  height: renderEnv.height,
  colors: [
    {name: 'positionMetalOrSpec', format: 'rgba16float'},
    {name: 'baseColorRoughOrGloss', format: 'rgba16float'},
    {name: 'normalGlass', format: 'rgba16float'},
    {name: 'meshIndexMatIndexMatType', format: 'rgba8uint'}
  ],
  depthStencil: {needStencil: false}
});

const {material} = this._gBufferDebugMesh = new H.ImageMesh(new H.Material(H.buildinEffects.iRTGShow));
material.setUniform('u_gbPositionMetalOrSpec', this._gBufferRT, 'positionMetalOrSpec');
material.setUniform('u_gbBaseColorRoughOrGloss', this._gBufferRT, 'baseColorRoughOrGloss');
material.setUniform('u_gbNormalGlass', this._gBufferRT, 'normalGlass');
material.setUniform('u_gbMeshIndexMatIndexMatType', this._gBufferRT, 'meshIndexMatIndexMatType');

然后渲染就OK：

this._scene.setRenderTarget(this._gBufferRT);
this._scene.renderCamera(this._camera, [this._rtManager.gBufferMesh]);

最后我用一个ImageMesh将最终的结果显示了出来，如图：

【WebGPU实时光追美少女】场景数据组织与合并

dtysky — Wednesday, 15 Sep 2021 00:00:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

本文将在上一篇文章WebGPU基础与简单渲染器的基础上，论述针对路径追踪，应当如何组织场景数据，这涉及到PBR材质定义、glTF资源的导出和加载、场景的构建、以及最重要的场景合并等内容。

PBR材质

这篇文章以PBR材质开始，为什么要以材质开始？因为如上一篇文章所言，材质（以及效果）决定了物体的渲染方式，也可以从某种程度上认为是决定了使用光照模型（或者说是光照模型决定了材质和效果），这个对整个场景数据和渲染流程的组织有决定性的影响。为了搞清楚为何要如此组织数据和渲染流程，我们必须要先了解使用到的材质。

PBR即“基于物理的渲染”是工业界的说法，其可以认为是基于相对物理正确的BRDF、BSDF等模型，根据不同的场合，抽象了一些参数供美术人员调节，并加上一些技术（比如用于实时渲染的预计算IBL、SH技术等等）来达到相对物理真实的效果。不过这里我们不讨论背后实现的理论细节，这些细节将在后续的章节详细论述，本文只需要了解这些参数和工作流即可。

事实上，在光栅化渲染流程如果单纯使用PBR材质进行直接光照，而不使用IBL/SH进行间接光照，相对于传统的光照模型，并不能带来多大的提升，所以Baking是十分重要的。

根源上来讲，PBR材质只是一个统称，其有很多变种，这些变种一般被称为工作流（Workflow）。同时这些变种也有不同的定义和实现，比如著名的迪士尼的Disney Principled BRDF。而本引擎的定义则基于后续要提到的glTF资源中的标准定义，支持了两种最常见的工作流——金属（MetallicRoughness）和高光（SpecularGlossiness）工作流。

Metallic Roughness

金属工作流，是指主要通过金属度和粗糙度来控制渲染效果，这实际上模拟的是自然界的导体，也有一些其他参数来共同决定最终效果：

Metallic：金属度，由单通道贴图metallicMap和系数metallicFactor相乘得到。
Roughness：粗糙度，由单通道贴图roughnessMap和系数roughnessFactor相乘得到。
BaseColor：反照率，有的引擎也称为Albedo，由RGBA贴图baseColorMap和颜色系数baseColorFactor相乘得到。
Occlusion：环境光遮蔽，由单通道贴图occlusionMap和系数occlusionFactor相乘得到。
Normal：法线贴图，一般是切线空间的法线贴图normalMap和系数normalScale计算得到。
Emission：自发光，由RGBA贴图emissiveMap和颜色系数emissiveFactor相乘得到。

在实际使用中，metallicMap、roughnessMap和occlusionMap一般会合并成一张RGB贴图。

Specular Glossiness

除了金属度和粗糙度，高光工作流的大部分参数和金属工作流都是通用的，但高光和光泽度是独有的，也是控制渲染的最主要因素：

Specular：高光，由RGB贴图specularMap和颜色系数specularFactor相乘得到。
Glossiness：光泽度，由单通道贴图glossinessMap和系数glossinessFactor相乘得到。

这里要注意除了BaseColor和Emissive一般是SRGB空间的，其他都是线性空间的，并且在实际计算时都是转到线性空间计算的，这也是物理正确的要求。

glTF资源

有了材质的定义，接下来的问题就是如何将它们应用到物体上了，这又引出了更多的问题——我们该如何组织整个场景？又如何去存储它们、如何去生成它们？答案很简单——使用glTF格式。

glTF是KhronosGroup近年来提出的一种标准模型格式，从某种意义上你可以认为它是3D场景序列化的一种标准解决方案。其方案非常简单明确，基本由一个存储节点、曲面、材质、纹理、动画等等索引信息的json格式的.gltf文件，同时还提供了一个二进制.bin文件用于存储实际的顶点、动画信息等，而这个二进制文件中的数据和GL所需格式基本一致，这大幅降低加载延迟、提升了首屏速度。更多详细的信息可以看这里——Sein.js glTF和实例化。

读者可能会疑惑为何这里会提及另一个引擎，因为这个引擎是我还在支付宝供职时研发的（当然已开源），同时还为其开发了配套的Unity扩展——SeinjsUnityToolkit，而本引擎也可以直接使用这个工具导出的资源，也算是物尽其用吧，但相比于工具支持的所有特性，本引擎只用到了需要的部分：

贴图。
2D和Cube纹理。
PBR材质，主要是glTF官方内置的金属工作流，以及通过KHR_materials_pbrSpecularGlossiness扩展实现的高光工作流。
图元和Mesh，直接对应引擎中的Geometry和Mesh。
相机，支持正交和透视。
灯光，在路径追踪中主要用到了rect和disc两种面光源。
结点，用于构建节点树。

整个加载器的代码的实现在resource/GlTFLoader内，实际使用中，只需要调用load方法，之后将返回的结果中的根节点rootNode添加给场景的根节点即可：

const model = this._model = await H.resource.load({type: 'gltf', name: 'scene.gltf', src: MODEL_SRC});
if (model.cameras.length) {
  this._camera = model.cameras[0];
}
_scene.rootNode.addChild(model.rootNode);

场景合并

加载完资源并将其添加到场景后，我们有了一整颗节点树，节点树上也有了不同的Mesh、Light、Camera，而Mesh则拥有Geometry和Material，Material全部是PBR材质，并使用UniformBlock将需要的参数管理了起来。如果是传统的光栅化流程，我们可以直接开始渲染——Camera剔除出需要的Mesh，将lightInfo、VP矩阵等写入全局UB，之后分别绘制每个Mesh.....但对于路径追踪流程，却不能这么做，原因很简单——信息不足。

上面这张图生动地描述了两个流程的差异（当然第二个实际上是光线追踪流程，不过用于描述差距还是足够了，把射线反过来就OK）。

光栅化流程实际上是将场景中的每个三角面投影到近裁剪面上，然后通过算法将矢量的三角形栅格化为像素（片元），之后经过重心坐标插值、像素着色、各种测试、混合等等决定屏幕空间某些像素最后的颜色值，这实际上是反直觉的，并且只能计算直接光照。

而路径追踪则不同，其出发点并非三角形，而是屏幕空间的像素，我们通过相机坐标->像素对应世界空间坐标生成一条世界空间的射线，然后让其和场景中所有三角面求交，找到最近的相交点后再通过反射/折射计算光路，最终可以通过N次弹射，最终收集完整个场景对此像素的贡献。除了部分场景（比如焦散），单向的路径追踪可以比较准确地计算出全局光照的结果。

那么这些和场景合并又有什么关系呢？当然有——路径追踪需要在每个射线求交的过程中拥有整个场景所有三角面的信息，除此之外，由于交点可能存在于任意三角面上，所以也需要能够即时获取到三角面对应的材质信息。

有经验的读者可能已经联想到了，这个特征其实和工业界讨论许久的GPU Driven有些相似。

GPU Driven Rendering Pipeline

GPU Driven Rendering指的是一类渲染技术，其根本目的是为了充分利用GPU的计算能力，使用Bindless Resource、Virtual Texture、Indirect Draw等等技术，尽可能减少渲染过程中CPU和GPU之间数据传输、调用的cost，还可以充分控制利用cache，来提升性能。这里最主要的就是上一篇文章前面提到过剔除、资源绑定、绘制等等。此技术的细节比较复杂，需要很多工程上的工作，有兴趣的读者可以自行搜索。对于本文我们只需要关心它和路径追踪相关的内容，也就是——资源绑定部分。

资源绑定在WebGPU中，实质上就是上篇文章提到pass.setIndexBuffer、pass.setVertexBuffer、pass.setBindingGroup等等方法，CPU通过这些方法告诉GPU我们接下来的绘制指令将会使用哪些顶点数据、Uniform数据......之后进行渲染。但因为硬件结构和软件设计，资源绑定操作是有开销的，一部分是指令本身、另一部分就是GPU中的计算单元获取这些资源对应Buffer的机制，那么如何尽量减少这些操作便是一个可以考虑的问题。

这里我们可以回忆一下Instanced Drawing，即GPU实例化的机制，这个机制它提供一个一次性绘制一批相同图元、相同渲染状态，但可以有不同位置、颜色等等的Mesh的方法。无论是使用InstanceBuffer，还是使用instanceId + const buffer/texture array的机制，本质上都是将这些Mesh中不同的Uniform（比如worldMatrix、color）转换成可以按照实例索引的数据，然后按照实例的维度去索引。这实际上是以在CPU对这些数据打包为代价，降低了实际渲染时绑定和绘制指令的大幅降低（当然，绑定这个操作很久之前就已经可以通过VAO来降低，在新的技术里也有Bindless Resource来降低）。

那么在这个基础上进一步考虑，我们是否可以将图元、某些渲染状态、大量Uniform都不一致的Mesh一批渲染完成呢？当然可以——这就是合批（Batch）技术。在目前常见的光栅化渲染管线（比如ForwardBase）中，合批一般指将相同渲染状态、只有少数Uniform不同的Mesh进行合并的技术，一般在简单的图元、UI上比较常用，其原理是Mesh的某些顶点数据和对应的uniform预先在CPU处理好（比如position和worldMatrix相乘得到worldPos），并将这些Mesh图元数据合并，被合批的uniform统一，便可以实现一次DrawCall绘制大量Mesh。

GPU实例化和合批在目前的游戏中都有大量应用，而GPU Driven的资源部分可以认为是基于它们和一些新技术，做得更加彻底、做了更多优化、也更为复杂。本项目用于路径追踪的部分实际上也可以认为结合了这两者，但毕竟和光栅化流程面对的问题不完全相同，所以做法也不完全一致。

顶点合并

整个路径追踪场景数据管理相关的代码都在extension/RayTracingManager中。

首先要做的就是顶点数据vertexData的合并，这个流程和传统的合批流程基本一致，将位置position和法线normal转换到世界空间，其他的直接拼接即可。如果只是为了合并，其实也可以不转换，然后在下面的流程将worldMatrix合并，通过索引后续计算也行，但由于构建BVH必须要使用世界空间的坐标，这里也就必须要合并，至于法线也只是顺带算了。在合并顶点数据的过程中，还需要同时构建索引数据indexData：

protected _buildAttributeBuffers = (meshes: Mesh[]) => {
  const {_materials} = this;

  let indexCount: number = 0;
  let vertexCount: number = 0;
  meshes.forEach(mesh => {
    vertexCount += mesh.geometry.vertexCount;
    indexCount += mesh.geometry.count;
  });

  const {value: indexes} = this._indexInfo = {
    value: new Uint32Array(indexCount)
  };

  const {position, texcoord_0, normal, meshMatIndex} = this._attributesInfo = {
    position: {
      // alignment of vec3 is 16bytes!
      value: new Float32Array(vertexCount * 4),
      length: 4,
      format: 'float32x3'
    },
    texcoord_0: {
      value: new Float32Array(vertexCount * 2),
      length: 2,
      format: 'float32x2'
    },
    normal: {
      // alignment of vec3 is 16bytes!
      value: new Float32Array(vertexCount * 4),
      length: 4,
      format: 'float32x3'
    },
    meshMatIndex: {
      value: new Uint32Array(vertexCount * 2),
      length: 2,
      format: 'uint32x2'
    }
  };

  let attrOffset: number = 0;
  let indexOffset: number = 0;

  for (let meshIndex = 0; meshIndex < meshes.length; meshIndex += 1) {
    const mesh = meshes[meshIndex];
    const {worldMat} = mesh;
    const quat = mat4.getRotation(new Float32Array(4), worldMat) as Float32Array;
    const {geometry, material} = mesh;
    const {indexData, vertexInfo, vertexCount, count} = geometry;

    if (material.effect.name !== 'rPBR') {
      throw new Error('Only support Effect rPBR!');
    }

    let materialIndex = _materials.indexOf(material);
    if (materialIndex < 0) {
      _materials.push(material);
      materialIndex = _materials.length - 1;
    }

    indexData.forEach((value: number, index: number) => {
      indexes[index + indexOffset] = value + attrOffset;
    });

    if (!vertexInfo.normal) {
      geometry.calculateNormals();
    }

    for (let index = 0; index < vertexCount; index += 1) {
      this._copyAttribute(vertexInfo.position, position, attrOffset, index, worldMat);
      this._copyAttribute(vertexInfo.texcoord_0, texcoord_0, attrOffset, index);
      this._copyAttribute(vertexInfo.normal, normal, attrOffset, index, quat, true);

      meshMatIndex.value.set([meshIndex, materialIndex], (attrOffset + index) * meshMatIndex.length);
    }

    indexOffset += count;
    attrOffset += vertexCount;
  }
}

有读者应该注意到了打包的除了传统的那些顶点数据，还有meshMatIndex，这其实是记录了当前顶点属于哪个Mesh（meshIndex），拥有哪个材质（matIndex）。这是因为光有点点数据并不足以支撑整个渲染流程，所以需要通过某个顶点获取到对应的材质。于是我借鉴上面说到的GPU实例化思想——通过材质ID来索引，这也就引出了“材质合并”。

材质合并

所谓材质合并，其实是将材质中的UniformBlock进行合并（Mesh级别的UB目前只有worldMatrix，已经在上一步合过了），来准备给每个顶点的matIndex索引出渲染需要的参数。前面提到过我们使用的都是PBR材质，所以合并的也就是这些参数：

protected _buildCommonUniforms = (materials: Material[]) => {
  const matId2TexturesId = new Int32Array(materials.length * 4).fill(-1);
  const baseColorFactors = new Float32Array(materials.length * 4).fill(1);
  const metallicRoughnessFactorNormalScaleMaterialTypes = new Float32Array(materials.length * 4).fill(1);
  const specularGlossinessFactors = new Float32Array(materials.length * 4).fill(1);
  const baseColorTextures: Texture[] = [];
  const normalTextures: Texture[] = [];
  const metalRoughOrSpecGlossTextures: Texture[] = [];

  materials.forEach((mat, index) => {
    const useGlass = mat.marcos['USE_GLASS'];
    const useSpecGloss = mat.marcos['USE_SPEC_GLOSS'];
    const baseColorFactor = mat.getUniform('u_baseColorFactor') as Float32Array;
    const metallicFactor = mat.getUniform('u_metallicFactor') as Float32Array;
    const roughnessFactor = mat.getUniform('u_roughnessFactor') as Float32Array;
    const specularFactor = mat.getUniform('u_specularFactor') as Float32Array;
    const glossinessFactor = mat.getUniform('u_glossinessFactor') as Float32Array;
    const normalScale = mat.getUniform('u_normalTextureScale') as Float32Array;
    const baseColorTexture = mat.getUniform('u_baseColorTexture') as Texture;
    const normalTexture = mat.getUniform('u_normalTexture') as Texture;
    const metallicRoughnessTexture = mat.getUniform('u_metallicRoughnessTexture') as Texture;
    const specularGlossinessTexture = mat.getUniform('u_specularGlossinessTexture') as Texture;

    const mid = index * 4;
    baseColorTexture !== buildinTextures.empty && this._setTextures(mid, baseColorTextures, baseColorTexture, matId2TexturesId);
    normalTexture !== buildinTextures.empty && this._setTextures(mid + 1, normalTextures, normalTexture, matId2TexturesId);
    baseColorFactor && baseColorFactors.set(baseColorFactor, index * 4);
    normalScale !== undefined && metallicRoughnessFactorNormalScaleMaterialTypes.set(normalScale.slice(0, 1), index * 4 + 2);

    if (useSpecGloss) {
      specularFactor !== undefined && specularGlossinessFactors.set(specularFactor.slice(0, 3), index * 4);
      glossinessFactor !== undefined && specularGlossinessFactors.set(glossinessFactor.slice(0, 1), index * 4 + 3);
      specularGlossinessTexture !== buildinTextures.empty && this._setTextures(mid + 2, metalRoughOrSpecGlossTextures, specularGlossinessTexture, matId2TexturesId);
      metallicRoughnessFactorNormalScaleMaterialTypes.set([useGlass ? EPBRMaterialType.GLASS_SPEC_GLOSS : EPBRMaterialType.SPEC_GLOSS], index * 4 + 3);
    } else {
      metallicFactor !== undefined && metallicRoughnessFactorNormalScaleMaterialTypes.set(metallicFactor.slice(0, 1), index * 4);
      roughnessFactor !== undefined && metallicRoughnessFactorNormalScaleMaterialTypes.set(roughnessFactor.slice(0, 1), index * 4 + 1);
      metallicRoughnessTexture !== buildinTextures.empty && this._setTextures(mid + 2, metalRoughOrSpecGlossTextures, metallicRoughnessTexture, matId2TexturesId);
      metallicRoughnessFactorNormalScaleMaterialTypes.set([useGlass ? EPBRMaterialType.GLASS_METAL_ROUGH : EPBRMaterialType.METAL_ROUGH], index * 4 + 3);
    }
  });

  this._commonUniforms = {
    matId2TexturesId,
    baseColorFactors,
    metallicRoughnessFactorNormalScaleMaterialTypes,
    specularGlossinessFactors,
    baseColorTextures: this._generateTextureArray(baseColorTextures),
    normalTextures: this._generateTextureArray(normalTextures),
    metalRoughOrSpecGlossTextures: this._generateTextureArray(metalRoughOrSpecGlossTextures)
  };
}

可以看到合并的逻辑也比较简单，唯一注意的是合并的规则——都是尽量凑齐16字节对齐的。同时除了材质本身固有的基本参数，还有materialType和matId2TexturesId。materialType用于表示材质的类型，分为不透明金属、透明金属、不透明高光、透明高光，不同材质对应的光照计算流程不同。

matId2TexturesId记录的是该材质到纹理id的索引。通过顶点找到材质需要索引，那么通过材质找到需要用到的纹理也需要索引，这是由于不同材质可能复用同一张纹理资源，所以需要同样对纹理进行合并。

纹理合并

纹理合并即将不同的纹理合并成一个可以索引的集合，其并没有看起来那么简单。目前工业界比较成熟和推荐的方案是使用Bindless Texture，但WebGPU并不支持，另外妥协的方案有两个：

大纹理：创建一张很大的纹理，通过UV映射将需要的纹理分配在大纹理的一个个子区域，存下offset和size来进行采样。
ArrayTexture：创建数组纹理，直接在shader中通过索引采样。

二者各有各的缺点，大纹理的缺点主要是容量有限，对于很多最大支持2048 x 2048的平台很容易超，并且即便是支持不同大小的纹理，也容易产生空间的浪费，当然最主要的还是容量问题。ArrayTexture主要就是要求纹理尺寸必须一致了，但胜在使用方便不太需要担心容量超过。本项目使用的是ArrayTexture：

protected _generateTextureArray(textures: Texture[]): Texture {
  let width: number = 0;
  let height: number = 0;

  textures.forEach(tex => {
    width = Math.max(width, tex.width);
    height = Math.max(height, tex.height);
  });

  const images = textures.map(tex => {
    if (tex.width === width && tex.height === height) {
      return tex.source as TTextureSource;
    }

    if (!(tex.source instanceof ImageBitmap)) {
      throw new Error('Can only resize image bitmap!');
    }

    if (!RayTracingManager.RESIZE_CANVAS) {
      RayTracingManager.RESIZE_CANVAS = document.createElement('canvas');
      RayTracingManager.RESIZE_CANVAS.width = 2048;
      RayTracingManager.RESIZE_CANVAS.height = 2048;
      RayTracingManager.RESIZE_CTX = RayTracingManager.RESIZE_CANVAS.getContext('2d');
    }

    const ctx = RayTracingManager.RESIZE_CTX;
    ctx.drawImage(tex.source as ImageBitmap, 0, 0, width, height);

    return ctx.getImageData(0, 0, width, height).data.buffer;
  })

  return new Texture(
    width, height,
    images,
    textures[0].format
  );
}

至此，整个场景合并部分完成。

【WebGPU实时光追美少女】WebGPU基础与简单渲染器

dtysky — Monday, 13 Sep 2021 01:00:00 -00:00

本系列文章设计的所有代码均已开源，Github仓库在这里：dtysky/webgpu-renderer。

WebGPU作为Web平台的下一代图形API标准（当然不仅仅是图形），提供了类似于DX12、Metal、Vulkan对GPU深入控制的能力，在经过了数个版本的迭代后，其在当下时点（2021年9月）终于基本稳定，可见WebGPU标准，其使用的着色器语言wgsl也基本稳定，详见WebGPU Shading Language。

WTF，就在我写这篇文章这一周（2021年9月第二周）标准又有更新，写完发现原来的代码跑不起来了......待我修一修。

在本文中，笔者将论述如何用WebGPU来实现一个简单的渲染器，并且目前只支持静态物体渲染，没有动画物理等等组件，这个渲染器的架构脱胎于笔者过去研究和实现过的几个渲染引擎，以求尽量简单，而非大而全，所以实现中可能有粗糙之处，但作为如何使用WebGPU的例子而言是绝对足够的。

概述

在设计一个渲染引擎，或者说渲染器的时候，我们最关心的问题毫无疑问是“渲染”，无论如何设计，首要考虑的都是“渲染是如何被驱动的”。一般来讲，目前通用的渲染驱动方案大致都是：

一帧开始 -> 组织提取渲染数据 -> 提交数据更改到GPU -> 设置渲染目标并清屏 -> 提交绘制指令 -> 一帧结束

对应于比较详细的工程概念，帧的调度可以视作是Web中的requestAnimationFrame，以每秒30、60或者120帧驱动；组织提取渲染数据可以分为两部分，一部分是渲染所需资源的管理，另一部分是“剔除”，即通过某种手段在整个场景中筛选出真正需要渲染的物体；而提交必要数据到GPU，则是指渲染过程中可能有一些数据会被更新，比如模型数据、Uniform等等，这时候就需要把这些数据更新上传到GPU；然后是设置渲染目标为画布或者主屏，并进行颜色、深度和模板缓冲区的清除；最后就是提交绘制指令，即进行实际的绘制。

为了实现以上整个驱动的过程，我们首先需要有一个用于渲染的环境，这个环境用于管理Canvas、Context以及一些全局的变量；其次是需要一些资源，这些资源管理着所有渲染所需要的数据；之后还需要一个场景结构和容器，来将这些渲染数据组装管理起来，方便剔除和绘制，与此同时还需要相机来提供观察场景的视角，需要灯光来让场景更加真实；最终还需要一种数据格式用于存储模型数据，还需要对应的加载器来它转换为我们需要的资源数据。

以下内容需要参考文首提到的项目源代码同步观看。

HObject

在真正开始讲述渲染部分的原理之前，要大概说一下整个工程的基本架构。这里我采用的是一个比较简单的继承式OO，对于工程中的每个类，都拥有统一的基类，并遵循统一的模式。这个基类叫做HObject（至于为何是HObject，那当然是因为青年H的原因咯）：

export default class HObject {
  public static CLASS_NAME: string = 'HObject';
  public isHObject: boolean = true;
  public name: string;
  get id(): number;
  get hash(): string;
}

每个继承自HObject的类都需要提供static CLASS_NAME、isXXXX，并会通过CLASS_NAME自动生成id和hash，还有可选的name方便Debug。

而有了isXXXX这种标示，还可以避免使用instanceof而是使用谓词判断类型，比如：

export default class RenderTexture extends HObject {
  public static IS(value: any): value is RenderTexture {
    return !!value.isRenderTexture;
  }

  public static CLASS_NAME: string = 'RenderTexture';
  public isRenderTexture: boolean = true;
}

便可以通过RenderTexture.IS(obj)来判断是否为obj是否为RenderTexture，无论是运行时还是编译期。

渲染环境

渲染环境在引擎中的实现是core/renderEnv，其实现比较简单，主要是通过Canvas初始化整个WebGPU的Context，同时管理全局Uniform和全局宏，Uniform和宏后面资源的死后会说到，这里先主要关注最重要的init方法实现：

public async init(canvas: HTMLCanvasElement) {
  if (!navigator.gpu) {
    throw new Error('WebGPU is not supported!');
  }

  const adapter = await navigator.gpu.requestAdapter();

  if (!adapter) {
    throw new Error('Require adapter failed!');
  }

  this._device = await adapter.requestDevice();

  if (!this._device) {
    throw new Error('Require device failed!');
  }

  this._canvas = canvas;
  this._ctx = (canvas.getContext('webgpu') as any || canvas.getContext('gpupresent')) as GPUCanvasContext;

  this._ctx.configure({
    device: this._device,
    format: this._swapChainFormat,
  });
}

这里可以看出WebGPU的Context的初始化方式，我们首先要检查navigator上是否有gpu实例，以及gpu.requestAdapter是否能够返回值，然后再看是否能够用adapter.requestDevice分配到设备，这个设备可以认为是图形硬件的一个抽象，其可以把实现和底层硬件隔离，有了这个中间层，便可以做各种兼容和适配。

有了device，还需要一个Context，这可以通过传入的canvas使用getContext('webgpu')获取，获取了Context后，便可以使用ctx.configure来配置SwapChain，注意这里使用到的format一般默认为'bgra8unorm'。

场景和容器

根据一开始的论述，读者可能认为接下来就要讲资源的实现，接着才是场景和容器，但这种论述其实是反直觉的。对于了解一个渲染引擎的设计而言，自顶向下才是最优解，下面我会先从场景的组织讲起，然后是渲染的驱动，再到渲染和计算单元，最后才是各个资源的细节。

Node

虽然是自顶向下，但Node，即节点还是要放在最开始说的。由于本文不是3D渲染的科普贴，就不再去说MVP矩阵这种入门知识了。简单来讲，Node就是描述3D场景中某个物体位置信息的基础，其拥有平移pos、旋转quat、缩放scale三个属性，并拥有父级parent和子级children来进行级联，级联后即为树状结构的节点树，这也就是场景的基础：

节点树将会在每一帧驱动的时候通过深度优先搜索dfs来从根节点遍历每个节点，调用updateMatrix进行自顶向下的世界矩阵worldMat更新。成熟的渲染引擎都会在节点树刷新这一步做很多优化，比如脏检查，但本项目没有考虑这些，每帧全量刷新。

节点是非常重要的单元，其也是相机、灯光、渲染单元的基类。

Scene

有了Node，场景Scene就自然而然构成了。所有的渲染引擎基本都有场景的概念，只不过功能可能不同。而本引擎为了方便，直接把渲染驱动的能力给了它。所以本引擎的Scene主要有两个功能——管理场景，以及管理绘制流程。

对于场景的管理主要在于节点树，节点树管理的实现很简单，场景内部持有了一个rootNode，直接将自己新建的节点作为rootNode的子级即可将其加入场景。但场景管理不限于此，在每帧从rootNode自顶向下刷新整棵节点树的时候，我们还可以收集一些渲染必要的信息，比如当帧可供剔除的渲染单元列表meshes和当帧需要的灯光列表lights：

this._rootNode.updateSubTree(node => {
  if (Mesh.IS(node)) {
    this._meshes.push(node);
  } else if (Light.IS(node)) {
    this._lights.push(node);
  }
});

关于这二者的时候马上就会讲到。

那么现在有了场景，我们如何驱动渲染呢，渲染当然需要一些资源，但也需要流程将它们组织起来。在文章的一开始已经提到过一个渲染流程应该是如何的，那么其实直接将它们翻译成接口给Scene即可：

1.startFrame(deltaTime: number)：

一帧开始，执行节点树刷新、收集信息，并设置全局的Uniform，比如u_lightInfos、u_gameTime等。然后是最重要的：创建GPUCommandEncoder：

this._command = renderEnv.device.createCommandEncoder();

GPUCommandEncoder顾名思义，是WebGPU中用于指令编码的管理器。一般每一帧都会重新创建一个，并在一帧结束时完成它的生命周期。这也是这一代图形API的标准设计，但其实类似思想早就存在于一些成熟的游戏引擎中，比如UE。

2.setRenderTarget(target: RenderTexture | null)：

这个接口用于设置渲染目标，如果是RenderTexture资源，那么接下来执行的所有绘制指令都会会知道这个RT上，如果是null则会会知道主屏的缓冲区。

3.cullCamera(camera: Camera): Mesh[]：

使用某个相机的camera.cull进行剔除，返回一个Mesh列表，并对列表按照z进行排序。

注意，在标准流程中，透明物体和非透明物体需要分类反着排序，透明物体由远及近画，非透明物体由近及远。并且往往还会加上renderQueue来加上一个可控的排序维度。

4.renderCamera(camera: Camera, meshes: Mesh[], clear: boolean = true)：

使用某个相机进行渲染一批Mesh，直接代理到camera.render方法。

5.renderImages(meshes: ImageMesh[], clear: boolean = true)：

渲染一批特殊的渲染单元ImageMesh，专用于处理图像效果。

6.computeUnits(units: ComputeUnit[])：

对一批计算单元进行计算，专用于处理计算着色器。

7.endFrame()：

结束一帧的绘制，主要是将当帧的commandEncoder送入GPUQueue并提交：

renderEnv.device.queue.submit([this._command.finish()]);

如此，this._command便结束了其生命周期，不能再被使用。

Camera

相机是观察整个场景的眼睛，其继承自Node，对渲染的主要贡献有以下几点：

1.剔除：

剔除分为很多种，相机的剔除是物体级别的可见性剔除，其利用相机位置和投影参数构造的视锥体和物体自身求交（出于性能考虑，往往使用包围盒或者包围球）来判定物体是否在可见范围内，并算出相机到物体的距离，来作为后续排序的依据。剔除的实现为camera.cull，但由于其不是教程重点，并且对于目前场景也没什么意义，所以没有实现。不过实现也很简单，读者可以自行查阅相关资料。

2.提供VP矩阵：

相机还需要为渲染过程提供VP矩阵，即视图矩阵ViewMatrix和投影矩阵ProjectionMatrix。前者和相机结点的WorldMatrix相关，后者则和相机的投影模式（透视或者正交）以及参数有关。这些参数将在updateMatrix方法更新了WorldMatrix后计算，计算后会立即设置到全局Uniform中。

当然理论上这种做法在场景中存在多个相机的时候会出问题，实际上应该有个专门的preRender之类的流程来处理，但为了方便这里就这么做吧。

3.天空盒：

除了计算VP矩阵外，在updateMatrix中还会计算一个skyVP，这个是用于天空盒渲染的。天空盒是一种特殊的Mesh，其不会随着相机的移动变换相对位置（只会相对旋转）。本引擎对天空盒的实现很简单，固定使用内置的几何体Geometry，为相机增加了skyboxMat这个材质属性来定制绘制过程，并提供了内置的天空盒材质。

4.渲染：

相机最重要的功能就是进行渲染实际的渲染驱动了，其render(cmd: GPUCommandEncoder, rt: RenderTexture, meshes: Mesh[], clear: boolean)方法就用于此。这个方法的实现并不复杂，直接贴代码：

const [r, g, b, a] = this.clearColor;
const {x, y, w, h} = this.viewport;
const {width, height, colorViews, depthStencilView} = rt;

const renderPassDescriptor: GPURenderPassDescriptor = {
  colorAttachments: colorViews.map(view => ({
    view,
    loadValue: clear ? { r, g, b, a } : 'load' as GPULoadOp,
    storeOp: this.colorOp
  })),
  depthStencilAttachment: depthStencilView && {
    view: depthStencilView,
    depthLoadValue: this.clearDepth,
    stencilLoadValue: this.clearStencil,
    depthStoreOp: this.depthOp,
    stencilStoreOp: this.stencilOp
  }
};

const pass = cmd.beginRenderPass(renderPassDescriptor);
pass.setViewport(x * width, y * height, w * width, h * height, 0, 1);
pass.setBindGroup(0, renderEnv.bindingGroup);

for (const mesh of meshes) {
  mesh.render(pass, rt);
}

if (this.drawSkybox && this._skyboxMesh) {
  this._skyboxMesh.render(pass, rt);
}

pass.endPass();

其中比较重要的是RenderPass的概念，在WebGPU中这可以认为是一次渲染的流程，创建其使用的GPURenderPassDescriptor对象是这个流程要绘制的目标和操作的描述符。可以看到其中主要是设置了颜色和深度/模板缓冲的view，关于这个将会在后面的RenderTexture中详细说到，这里就认为其就是画布即可；而loadValue和storeOp是决定如何清屏的，在这里这些参数都可以交由开发者决定，一般来讲是颜色值和store操作。

在创建了一个RenderPass后，就可以设置viewport和bindGroup，前者和OpenGL中的视口概念等同，后者可以认为就是UniformBlock，这个在后面会详细讲到，这里设置的是第0个UniformBlock，即全局UB。设置好后便是调用每个Mesh的render方法逐个渲染，最终渲染天空盒。渲染完毕后调用pass.endPass来结束这个RenderPass。

事实上关于ImageMesh和ComputeUnit的绘制处理也类似，后面会详细讲到。

Mesh

网格Mesh是用于渲染的基本单元，其构造为new Mesh(geometry, material)。其将存储着图元数据的几何体Geometry和决定了渲染方式的材质Material对应组装起来，加之每个对象各有的UniformBlock，在相机绘制的过程中，被调用进行渲染：

public render(pass: GPURenderPassEncoder, rt: RenderTexture) {
  const {_geometry, _material} = this;

  if (_material.version !== this._matVersion || !this._pipelines[rt.pipelineHash]) {
    this._createPipeline(rt);
    this._matVersion = _material.version;
  }

  this.setUniform('u_world', this._worldMat);
  this._bindingGroup = this._ubTemplate.getBindingGroup(this._uniformBlock, this._bindingGroup);

  _geometry.vertexes.forEach((vertex, index) => {
    pass.setVertexBuffer(index, vertex);
  });
  pass.setIndexBuffer(_geometry.indexes, _geometry.indexFormat);
  pass.setBindGroup(1, _material.bindingGroup);
  pass.setBindGroup(2, this._bindingGroup);
  pass.setPipeline(this._pipelines[rt.pipelineHash]);
  pass.drawIndexed(_geometry.count, 1, 0, 0, 0);
}

渲染的流程并不复杂，先不管下面章节会说到的资源的具体实现，从宏观的角度来看，这里主要的工作是设置顶点缓冲vertexBuffer，设置索引缓冲indexBuffer，分别设置物体（index=1）和材质（index=2）级别的Uniform，最后设置一个叫做pipeline的参数，全部设置完后调用drawIndexed来绘制这一批图元。

当然，这也支持GPU实例化，但不在本引擎的讨论范围内。

ImageMesh

图像渲染单元ImageMesh一般用于图像处理，其构造为new ImageMesh(material)。其内置了绘制一张图像的图元数据，直接用传入的Material进行绘制。所以其绘制流程也相对简单，不需要MVP矩阵，所以并不需要相机，也不需要结点，不需要深度缓冲，其他和camera.render几乎一致。

还要注意的是ImageMesh最终的绘制并不是用drawIndexed方法而是用pass.draw(6, 1, 0, 0)方法，因为其并不需要顶点数据，这个在着色器章节会详细论述。

ComputeUnit

WebGPU相对于WebGL最重大的进化之一就是支持计算着色器，计算单元ComputeUnit就用于支持它。和渲染单元不同，其专门用于使用Compute Shader进行计算，相比于渲染单元，其不需要顶点、渲染状态等等数据，所有数据都将视为用于计算的缓冲，所以其构造为new ComputeUnit(effect, groups, values, marcos)，效果effect以及values、marcos参数也是构造Material的参数，所以ComputeUnit合并了一部分Material的功能。与此同时还加上了groups（类型为{x: number, y?: number, z?: number}），这里先不谈，让我们看看整个一个单元列表的计算是如何实现的：

// 在Scene.ts中
public computeUnits(units: ComputeUnit[]) {
  const pass = this._command.beginComputePass();
  pass.setBindGroup(0, renderEnv.bindingGroup);

  for (const unit of units) {
    unit.compute(pass);
  }

  pass.endPass();
}

// 在ComputeUnit.ts中
public compute(pass: GPUComputePassEncoder) {
  const {_material, _groups} = this;

  if (_material.version !== this._matVersion) {
    this._createPipeline();
    this._matVersion = _material.version;
  }

  pass.setPipeline(this._pipeline);
  pass.setBindGroup(1, _material.bindingGroup);
  pass.dispatch(_groups.x, _groups.y, _groups.z);
}

可以看到，和渲染流程的RenderPass不同，这里创建了一个ComputePass用于这批计算，并且同样需要设置BindingGroup0（可以认为是全局UniformBlock）。之后针对每个计算单元，都设置了pipeline、单元级别的UniformBlock，最后执行dispatch，后面的参数涉及到线程组的概念，和计算着色器也有关，这个后面会讲到。在计算完所有单元后，执行endPass来结束这个流程。

Light

除了相机和渲染单元之外，对于一个最简单的渲染器，灯光也是不可或缺的。本引擎的灯光设计比较简单，全部集中在Light这一个类的实现中。灯光主要属性有类型type、颜色color以及分类型的各种参数，类型一般有：

export enum ELightType {
  INVALID = 0,
  Area,
  Directional,
  Point,
  Spot
}

每种类型的光源都有不同参数，对于本引擎针对的路径追踪而言，比较重要的是面光源的参数：模式（矩形Rect或圆盘Disc）和尺寸宽高或半径。和相机一样，灯光本身也继承自结点，所以在更新矩阵的时候也要计算自己的灯光矩阵LightMatrix，并更新需要送往全局UniformBlock的信息：

public updateMatrix() {
  super.updateMatrix();

  this._ubInfo.set(this._color, 4);
  this._ubInfo.set(this._worldMat, 8);
  this._ubInfo.set(mat4.invert(new Float32Array(16), this._worldMat), 24);
}

在实际渲染中，renderEnv.startFrame中全局UB的u_lightInfos就是从这个ubInfo中获取信息更新的，目前一个物体一次绘制最多支持四个灯光。

资源

有了宏观的渲染管线和容器，就只剩具体的资源来填充它们了。在接下来的章节，我将论述我们熟悉的一些渲染资源抽象如何在WebGPU中实现。

Shader

首先必须要说的是着色器Shader，因为后续的所有资源最终都会在Shader中被应用，并且它们的部分设计和Shader也有着十分紧密的联系。着色器是什么我不再赘述，相信写过OpenGL或WebGL的读者都写过顶点着色器和片段着色器，在WebGPU中它们同样存在，而比起WebGL，WebGPU还实现了计算着色器。

WebGPU使用的着色器语言在一次又一次的变更后，终于定论为WGSL。其语法和glsl与hlsl都有较大差异，以本人的观点看比较像融合了metal和rust的很多部分，这一点也体现在编译阶段——WGSL的类型系统十分严格。

本文并非是一个WGPU或者WGSL的详细教程（否则至少得写一本书），下面就分别以三个/三种着色器的简单示例，来论述一下本文需要用到的一些WGSL的基本知识。

顶点着色器

//model.vert.wgsl
struct VertexOutput {
  [[builtin(position)]] Position: vec4<f32>;
  [[location(0)]] texcoord_0: vec2<f32>;
  [[location(1)]] normal: vec3<f32>;
  [[location(2)]] tangent: vec4<f32>;
  [[location(3)]] color_0: vec3<f32>;
  [[location(4)]] texcoord_1: vec2<f32>;
};

[[stage(vertex)]]
fn main(attrs: Attrs) -> VertexOutput {
  var output: VertexOutput;

  output.Position = global.u_vp * mesh.u_world * vec4<f32>(attrs.position, 1.);

  #if defined(USE_TEXCOORD_0)
    output.texcoord_0 = attrs.texcoord_0;
  #endif

  #if defined(USE_NORMAL)
    output.normal = attrs.normal;
  #endif

  #if defined(USE_TANGENT)
    output.tangent = attrs.tangent;
  #endif

  #if defined(USE_COLOR_0)
    output.color_0 = attrs.color_0;
  #endif

  #if defined(USE_TEXCOORD_1)
    output.texcoord_1 = attrs.texcoord_1;
  #endif

  return output;
}

这是一个典型的顶点着色器，首先从其入口main看起，[[stage(vertex)]]表明这是一个顶点着色器的入口，attrs: Attrs表明其输入是一个类型为Attrs的struct，-> VertexOutput则说明顶点着色器要传输给下一步插值的数据类型为VertexOutput。Attrs在这里没有写，这是因为其相对动态，我将其生成集成到了整个渲染过程的设计中，这个在下面的Geometry章节会讲到。而VertexOutput的定义就在代码顶部，其是一个struct，里面的内容都是形如[[位置]] 名字: 类型的形式，唯一不同的是[[builtin(position)]] Position，因为位置信息是重心坐标插值的重要依据，所以需要特殊指明。

接下来main的函数体中，主要实现了顶点数据的计算和输出，其中包括大家熟悉的MVP变换output.Position = global.u_vp * mesh.u_world * vec4<f32>(attrs.position, 1.);，这里要注意var output: VertexOutput的定义中使用的是var，在WGSL中使用var和let区分变量是动态还是静态，静态变量不可变并且必须初始化，动态的可变。在结尾return output表明返回计算结果到下一个阶段。

注意这里出现了#if defined(USE_TEXCOORD_0)这样的写法，而我们也在前面提到过宏，但实际上WGSL目前并没有实现宏、或者在这里的功能层面为预处理器，详见Issue[wgsl Consider a preprocessor。这里其实是我自己通过正则实现的一个简易预处理器，除此之外我还是用webpack的loader机制实现了一个简单的require方法，来完成shader文件的分隔复用，这里不再赘述。

这里还有必要单独提一下ImageMesh使用的顶点着色器，在上面的章节中提到了其绘制并不依赖于顶点数据，其实是利用WGSL的模块作用域变量（MODULE SCOPE VARIABLE）实现的：

struct VertexOutput {
  [[builtin(position)]] position: vec4<f32>;
  [[location(0)]] uv: vec2<f32>;
};

var<private> pos: array<vec2<f32>, 6> = array<vec2<f32>, 6>(
  vec2<f32>(-1.0, -1.0),
  vec2<f32>(1.0, -1.0),
  vec2<f32>(-1.0, 1.0),
  vec2<f32>(-1.0, 1.0),
  vec2<f32>(1.0, -1.0),
  vec2<f32>(1.0, 1.0)
);
var<private> uv: array<vec2<f32>, 6> = array<vec2<f32>, 6>(
  vec2<f32>(0.0, 1.0),
  vec2<f32>(1.0, 1.0),
  vec2<f32>(0.0, 0.0),
  vec2<f32>(0.0, 0.0),
  vec2<f32>(1.0, 1.0),
  vec2<f32>(1.0, 0.0)
);

[[stage(vertex)]]
fn main([[builtin(vertex_index)]] VertexIndex : u32) -> VertexOutput {
  var output: VertexOutput;

  output.position = vec4<f32>(pos[VertexIndex], 0.0, 1.0);
  output.uv = uv[VertexIndex];

  #if defined(FLIP)
    output.uv.y = 1. - output.uv.y;
  #endif

  return output;
}

这里通过var<private>定义了两个模块作用域的变量数组pos和uv，可以被着色器函数索引内容，而此处函数入参[[builtin(vertex_index)]] VertexIndex : u32是当前正在绘制的顶点索引，用这个索引和两个数组即可完成输出。

模块作用域变量不止有private一个域，还有workgroup等，这里不再赘述。

片段着色器

struct VertexOutput {
  [[builtin(position)]] Position: vec4<f32>;
  [[location(0)]] texcoord_0: vec2<f32>;
  [[location(1)]] normal: vec3<f32>;
  [[location(2)]] tangent: vec4<f32>;
  [[location(3)]] color_0: vec3<f32>;
  [[location(4)]] texcoord_1: vec2<f32>;
};

[[stage(fragment)]]
fn main(vo: VertexOutput) -> [[location(0)]] vec4<f32> {
  return material.u_baseColorFactor * textureSample(u_baseColorTexture, u_sampler, vo.texcoord_0);
}

main函数上方的[[stage(fragment)]]表明这是一个片段着色器。这个着色器很简答也很典型，其将顶点着色器的输出VertexOutput重心插值后的结果作为输入，最终输出一个 [[location(0)]] vec4<f32>的结果，这个结果就是最终这个片元颜色。

有了结构，再看看函数体中做了什么。这里从一个叫material的变量中取出了u_baseColorFactor，并用textureSample方法和UVvo.texcoord_0，对名为u_baseColorTexture的贴图进行了采样，并且还用上了一个叫做u_sampler的变量。纹理采样我们熟悉，但这个materia、u_baseColorTexture、u_sampler又是什么呢？这就要涉及到WGSL的另一点：BindingGroup了。

BindingGroup

这不是本文第一次出现BindingGroup这个词，在前面我们已经提到过无数次，并将其和UniformBlock相提并论，并在绘制流程中调用了pass.setBindGroup方法。那么这东西到底是什么呢？回想一下我们在OpenGL或者WebGL中如何在渲染过程中更新uniform的信息，一般是调用类似gl.uniform4vf这种借口，来将从shader反射信息拿到的location作为key，把值更新上去，如果是纹理则还需要线绑定纹理等等操作。就算是加上了缓存，每帧用于更新uniform的时间也是可观的，所以新一代图形API为了解决这个问题，就给出了BindingGroup或者类似的方案。

BindingGroup本质上可以看做是一个uniform的集合，和其他资源一样，在WebGPU最后创建一个BindingGroup也需要一个描述符：

device.createBindGroup(descriptor: {layout: GPUBindGroupLayout; entries: Iterable<GPUBindGroupEntry>}): GPUBindGroup;

描述符需要一个layout和一个entries，前者给出了结构，后者给出了实际的值。以一个简单的构造为例：

const visibility = GPUShaderStage.VERTEX | GPUShaderStage.FRAGMENT;
const bindingGroup = renderEnv.device.createBindGroup({
  layout: device.createBindGroupLayout({entries: [
    {
      binding: 0, visibility,
      buffer: {type: 'uniform' as GPUBufferBindingType},
    },
    {
      binding: 1, visibility,
      texture: {
        sampleType: 'rgba8unorm',
        viewDimension: '2d'
      },
    },
    {
      binding: 2, visibility,
      sampler: {type: 'filtering'}
    },
    {
      binding: 3,
      visibility: GPUShaderStage.COMPUTE,
      buffer: {type: 'storage'}
    },
  ]}),
  entries: [
    {
      binding: 0,
      resource: {buffer: gpuBuffer}
    },
    {
      binding: 1,
      resource: textureView
    },
    {
      binding: 2,
      resource: sampler
    },
    {
      binding: 3,
      resource: {buffer}
    }
  ]
});

这里构建的BindingGroup涵盖了几种值，分别是Uniform、Texture、Sampler和Storage，可见每种方式的描述定义都不一样，但它们都有共同之处——需要制定binding（可以认为是这个Group下的子地址）和visibility（在哪种着色器可见）。而这里构建的BindingGroup最终会设置到Pass中指定地址给Shader使用，在Shader中我们同样需要定义它们的结构：

[[block]] struct UniformsMaterial {
 [[align(16)]] u_baseColorFactor: vec4<f32>;
};
[[group(2), binding(0)]] var<uniform> material: UniformsMaterial;
[[group(2), binding(1)]] var u_baseColorTextures: texture_2d<f32>;
[[group(2), binding(2)]] var u_sampler: sampler;

struct Debug {
  origin: vec4<f32>;
  dir: vec4<f32>;
};
[[block]] struct DebugInfo {
  rays: array<DebugRay>;
};[[group(2), binding(3)]] var<storage, read_write> u_debugInfo: DebugInfo;

这里将一个BindingGroup分为了几个部分，所有的向量、矩阵等uniform类型的数据被打包在UniformsMaterial这个struct中，texture、sampler和storage类型的数据则需要分离出来，并且都有各自的定义形式，这个就是为何我们上面要通过materia.u_baseColorFactor去取uniform数据，而直接用u_texture来取纹理数据。

还需要注意的是各种前缀，group(2)表明这是绑定的第2个BindingGroup，这和前面说过的全局、单元、材质的UniformBlock是绑定在不同级别的一致。事实上前面也给出过其他两个级别的例子，在顶点着色器中使用到的global.u_vp * mesh.u_world就是在全局0和单元1级别的。而后面的binding(x)则需要和ts中的声明一致。同时还要注意的是uniform类型的struct的align(16)，这是为了强制每一项16字节对齐，同时可能使用的还是stride这样的修饰。

由于BindingGroup的创建和Shader描述耦合十分高，其中还有字节对齐之类的问题，为了方便使用、减少冗余代码，在引擎中我将BindingGroup的构造、Shader对应的struct的定义生成、Uniform管理都深度融合了，将在下面的UBTemplate论述。

计算着色器

计算着色器和前两种都不同，其不属于渲染管线的一部分，利用的是GPU的通用计算能力，所以也没有顶点输入、像素输出之类的要求，下面是一个比较糙的对图像卷积滤波的例子：

let c_radius: i32 = ${RADIUS};
let c_windowSize: i32 = ${WINDOW_SIZE};

[[stage(compute), workgroup_size(c_windowSize, c_windowSize, 1)]]
fn main(
  [[builtin(workgroup_id)]] workGroupID : vec3<u32>,
  [[builtin(local_invocation_id)]] localInvocationID : vec3<u32>
) {
  let size: vec2<i32> = textureDimensions(u_input, 0);
  let windowSize: vec2<i32> = vec2<i32>(c_windowSize, c_windowSize);
  let groupOffset: vec2<i32> = vec2<i32>(workGroupID.xy) * windowSize;
  let baseIndex: vec2<i32> = groupOffset + vec2<i32>(localInvocationID.xy);
  let baseUV: vec2<f32> = vec2<f32>(baseIndex) / vec2<f32>(size);

  var weightsSum: f32 = 0.;
  var res: vec4<f32> = vec4<f32>(0., 0., 0., 1.);
  for (var r: i32 = -c_radius; r <= c_radius; r = r + 1) {
    for (var c: i32 = -c_radius; c <= c_radius; c = c + 1) {
      let iuv: vec2<i32> = baseIndex + vec2<i32>(r, c);

      if (any(iuv < vec2<i32>(0)) || any(iuv >= size)) {
        continue;
      }

      let weightIndex: i32 = (r + c_radius) * c_windowSize + (c + c_radius);
      let weight: f32 = material.u_kernel[weightIndex / 4][weightIndex % 4];
      weightsSum = weightsSum + weight;
      res = res + weight * textureLoad(u_input, iuv, 0);
    }
  }
  res = res / f32(weightsSum);

  textureStore(u_output, baseIndex, res);
}

其main函数的修饰stage(compute)表明这是一个计算着色器，除此之外后面还有workgroup_size(c_windowSize, c_windowSize, 1)，读者应该注意到了这里有三个维度的参数，还记得我们前面在论述ComputeUint时提到的groupSize以及pass.dispatch(x, y, z)的三个参数吗？它们毫无疑问是有关联的，这就是线程组的概念。

这里不再赘述卷积滤波的原理，只需要知道它每次要对一个N X N窗口内的像素做处理，所以这里定义了一个窗口大小windowSize、也就定义了一个二维的（第三个维度为1）、大小为size = windowSize X windowSize的线程组，这表明一个线程组有这么大数量的线程，如果我们要处理纹理数据、同时每个线程处理一个像素，那这么一个线程组可以处理size个数量的像素，那么如果我们要处理一张width x height大小的图片，就应当将groupSize设置(width / windowSize, height / windowSize, 1)。

不同平台上允许的最大线程数量有限制，但一般都应当是16 x 16以上。

除此之外，可以看到计算着色器确实没有顶点像素之类的概念，但它有输入workgroup_id、local_invocation_id，这其实就是线程组的偏移和线程组内线程的偏移，通过它们我们就可以得到真正的线程偏移，也可以作为纹理采样的依据。能够采样纹理，就可以进行计算，最后将计算的结果通过textureStore写回输出纹理即可，输出纹理是一个write类型的storageTexture。

着色器中的${WINDOW_SIZE}这种也属于我自己实现的简陋的宏的一部分。

Geometry

几何体Geometry本质上就是顶点数据和索引数据的集合。在OpenGL中，我们往往会自己组织一个结构来描述顶点数据的存储构造，在WebGPU中，API标准即将这个结构定死了，其为GPUVertexBufferLayout[]。这个结构的描述加上vertexBuffer、indexBuffer即构成了整个渲染单元的几何信息：

constructor(
  protected _vertexes: {
    layout: {
      attributes: (GPUVertexAttribute & {name: string})[],
      arrayStride: number
    },
    data: TTypedArray,
    usage?: number
  }[],
  protected _indexData: Uint16Array | Uint32Array,
  public count: number,
  protected _boundingBox?: IBoundingBox
) {
  this._iBuffer = createGPUBuffer(_indexData, GPUBufferUsage.INDEX);
    this._vBuffers = new Array(_vertexes.length);
    this._vLayouts = new Array(_vertexes.length);
    this._indexFormat = _indexData instanceof Uint16Array ? 'uint16' : 'uint32';
    this._vInfo = {};
    this._marcos = {};
    this._attributesDef = 'struct Attrs {\n';

    _vertexes.forEach(({layout, data, usage}, index) => {
      const vBuffer = createGPUBuffer(data, GPUBufferUsage.VERTEX | (usage | 0));

      layout.attributes.forEach((attr) => {
        this._marcos[`USE_${attr.name.toUpperCase()}`] = true;
        this._attributesDef += `  [[location(${attr.shaderLocation})]] ${attr.name}: ${this._convertFormat(attr.format)};\n`;
        this._vInfo[attr.name.toLowerCase()] = {
          data, index,
          offset: attr.offset / 4, stride: layout.arrayStride / 4, length: this._getLength(attr.format)
        };
      });

      this._vBuffers[index] = vBuffer;
      this._vLayouts[index] = layout;

      this._vertexCount = data.byteLength / layout.arrayStride;
    });

    this._attributesDef += '};\n\n';
}

这是Geometry的构造方法，可以看到其主要是将多个vertexBuffer以及对应的layout、一个indexBuffer、顶点个数count处理，最终生成WebGPU需要的VertexLayout和GPUBuffer，同时还生成了其他必要的数据。VertexLayout这是描述无须赘述，这里主要需要注意GPUBuffer和所谓其他数据的生成。

GPUBuffer

首先是GPUBuffer，其在WebGPU中很常见，除了纹理之外所有在CPU和GPU传输的数据都是GPUBuffer。在历经数次迭代后，我们可以用一段简短的代码来创建它：

export function createGPUBuffer(array: TTypedArray, usage: GPUBufferUsageFlags) {
  const size = array.byteLength + (4 - array.byteLength % 4);
  const buffer = renderEnv.device.createBuffer({
    size,
    usage: usage | GPUBufferUsage.COPY_DST,
    mappedAtCreation: true
  });

  const view = new (array.constructor as {new(buffer: ArrayBuffer): TTypedArray})(buffer.getMappedRange(0, size));
  view.set(array, 0);

  buffer.unmap();

  return buffer;
}

这段代码通过传入的TypedArray创建一个同尺寸（但需要字节对齐）的GPUBuffer，并将其数据的值在初始化的时候拷贝给它。

宏和Shader

在创建Geometry的过程中还会生成别的重要数据：

一张宏的表_marcos，所有用到的顶点属性都会以USE_XXX的形式存在，然后作用在Shader中，比如上面顶点着色器示例那样。
顶点相关的Shader类型定义数据_attributesDef，自动组装出需要的拼接到Shader头部的字符串。

Texture

前面提到了BindingGroup的各种类型，其中有一大类就是纹理Texture，而纹理在引擎实现中又可以分为2D纹理和Cube纹理。

2D纹理

纹理在WebGPU中的创建很简单：

this._gpuTexture = renderEnv.device.createTexture({
  label: this.hash,
  size: {width: this._width, height: this._height, depthOrArrayLayers: this._arrayCount},
  format: _format || 'rgba8unorm',
  usage: GPUTextureUsage.TEXTURE_BINDING | GPUTextureUsage.COPY_DST | GPUTextureUsage.RENDER_ATTACHMENT
});

if (isTextureSourceArray(_src)) {
  _src.forEach((src, index) => this._load(src, index));
  this._gpuTextureView = this._gpuTexture.createView({dimension: '2d-array', arrayLayerCount: this._arrayCount});
} else {
  this._load(_src);
  this._gpuTextureView = this._gpuTexture.createView();
}

首先我们需要用device.createTexture来创建一个纹理，这里需要注意的参数是size中的depthOrArrayLayers，其在类型为2d-array的时候是数组的数量。创建了纹理后用_load方法来加载并上传纹理数据，最终调用createView方法创建view并缓存。而对于_load的实现，则根据来源是Buffer或图像有不同的做法：

_loadImg(img: ImageBitmap, layer: number) {
  renderEnv.device.queue.copyExternalImageToTexture(
    {source: img},
    {texture: this._gpuTexture, origin: this._isArray ? {x: 0, y: 0, z: layer} : undefined},
    {width: this._width, height: this._height, depthOrArrayLayers: 1}
  );
}

_loadBuffer(buffer: ArrayBuffer, layer: number) {
  renderEnv.device.queue.writeTexture(
    {texture: this._gpuTexture, origin: this._isArray ? {x: 0, y: 0, z: layer} : undefined},
    buffer as ArrayBuffer,
    {bytesPerRow: this._width * 4},
    {width: this._width, height: this._height, depthOrArrayLayers: 1}
  );
}

通过图像提供纹理数据，主要使用device.queue.copyExternalImageToTexture方法，但要求传入的是一个ImageBitMap，这个可以使用以下代码生成：

const img = document.createElement('img');
img.src = src;
await img.decode();
const bitmap = await createImageBitmap(img);

而使用Buffer的话，则直接用device.queue.writeTexture即可。

Cube纹理

Cube纹理和2D纹理大差不差，区别在于其初始化的时候depthOrArrayLayers为6，并且需要在初始化的时候提交六张纹理，并且在origin参数中的z为1~6。

RenderTexture

说完Texture，顺便可以直接说说可渲染纹理RenderTexture，顾名思义，这是一种可以用于用于绘制或写入数据的纹理。和通常的RenderTexture的设计一样，为了和MRT（多渲染目标）技术相容，本引擎的RenderTexture也设计为多个colorTexture和一个depthTexture的形式，来看看它的构造参数：

export interface IRenderTextureOptions {
  width: number;
  height: number;
  forCompute?: boolean;
  colors: {
    name?: string,
    format?: GPUTextureFormat
  }[];
  depthStencil?: {
    format?: GPUTextureFormat;
    needStencil?: boolean;
  };
}

具体的实现不贴了，就是根据colors和depthStencil中的参数去创建不同的GPUTexture，然后使用每个color的name建表索引，之后创建view缓存。这里有个特别的参数forCompute（是否用于计算着色器），主要决定了创建GPUTexture时的usage，如果是则需要开启GPUTextureUsage.STORAGE_BINDING。

创建好的RenderTexture可以和Texture直接一样直接用于渲染来源数据，但其最重要的功能是用于绘制，关于如何绘制，已经在前面的Camera章节说过了，将其按照顺序设置到GPURenderPassDescriptor即可。

UBTemplate

UBTemplate，可以认为是前面提了无数次的UniformBlock的模板，当然到这里读者应该察觉到了——这个UniformBlock远不止管理了Uniform，也管理了纹理、采样器、SSBO等等，只不过出于习惯这么称呼。而这也可以认为是整个引擎最复杂的一部分，因为它不仅涉及到了这些数据的创建和更新，还涉及到了Shader相关定义的生成。而在WebGPU和WGSL规范中，尤其是Uniform部分的规范又非常繁琐，比如各种字节对齐（align、stride），在方便使用的前提下，UBTemplate需要自动抹平这些复杂性，对外暴露足够简单的构造和接口，当然这是有代价的——会造成部分的内存浪费。

将UBTemplate所做的全部工作列出来实在会篇幅过长，而且必要性不大，这里就说一些核心的地方，剩下的读者自己去看代码即可。首先让我们看一下它的构造参数：

constructor(
  protected _uniformDesc: IUniformsDescriptor,
  protected _groupId: EUBGroup,
  protected _visibility?: number,
);

export enum EUBGroup {
  Global = 0,
  Material = 1,
  Mesh = 2
}

export type TUniformValue = TUniformTypedArray | Texture | CubeTexture | GPUSamplerDescriptor | RenderTexture;

export interface IUniformsDescriptor {
  uniforms: {
    name: string,
    type: 'number' | 'vec2' | 'vec3' | 'vec4' | 'mat2x2' | 'mat3x3' | 'mat4x4',
    format?: 'f32' | 'u32' | 'i32',
    size?: number,
    customType?: {name: string, code: string, len: number},
    defaultValue: TUniformTypedArray
  }[],
  textures?: {
    name: string,
    format?: GPUTextureSampleType,
    defaultValue: Texture | CubeTexture,
    storageAccess?: GPUStorageTextureAccess,
    storageFormat?: GPUTextureFormat
  }[],
  samplers?: {
    name: string,
    defaultValue: GPUSamplerDescriptor
  }[],
  storages?: {
    name: string,
    type: 'number' | 'vec2' | 'vec3' | 'vec4',
    format?: 'f32' | 'u32' | 'i32',
    customStruct?: {name: string, code: string},
    writable?: boolean,
    defaultValue: TUniformTypedArray,
    gpuValue?: GPUBuffer
  }[]
}

可见主要是_uniformDesc和_groupId，后者很简单，决定UB将用于哪个级别，这决定生成的Shader定义中Uniform部分的是global、mesh还是material。而前者就相对复杂了，其主要是四个部分：

uniforms：Uniform部分，这一部分的数据一般都是细粒度的向量、矩阵等，支持数组，在实际生成最后，会将他们都打包成一个大的Buffer，这个Buffer是严格16字节对齐的，这是什么意思呢？比如一个Vector3数组，将会被生成为[[align(16)]] ${name}: [[stride(16)]] array<vec3<f32>, 4>;。也就是说虽然这个数据只占用4 x 3 x 4个字节的空间即可描述，但这里强制使其占用4 x 4 x 4的空间，在每个vec3元素后都填了一位。在使用setUniform设置值的时候也会自动按照这个对齐规则来设置。
textures：纹理部分，和前面给出的创建BindingGroup时使用基本一致，但注意这里有参数storageAccess和storageFormat，用于生成storageTexture的定义，一般用于给CS提供可写入的RenderTexture。
samplers：采样器部分，和前面给出的创建BindingGroup时使用完全一致。
storages：SSBO部分，这是一种可以在CPU和GPU共享的特殊Buffer，其可以存储相对大量的数据，并可以在GPU的CS中写入和读取、也可以在CPU中写入和读取。在本项目中我一般用于调试CS。

uniforms和storage都提供了customStruct或customType参数来让用户自定义结构，而非默认生成，提供了自由度。

每次创建UBTemplate的时候，实际上都只是生成了BindingGroup中的layout部分和CPU端的默认值等，于此同时还生成了Shader中对应的Uniform相关的定义字符串。而在后续实际渲染中，我们将使用createUniformBlock方法实际创建UB时，返回的是：

export interface IUniformBlock {
  isBufferDirty: boolean;
  isDirty: boolean;
  layout: GPUBindGroupLayout;
  entries: GPUBindGroupEntry[];
  cpuBuffer: Uint32Array;
  gpuBuffer: GPUBuffer;
  values: {
    [name: string]: {
      value: TUniformValue,
      gpuValue: GPUBuffer | GPUSampler | GPUTextureView
    }
  };
}

后续便可以使用setUniform(ub: IUniformBlock, name: string, value: TUniformValue, rtSubNameOrGPUBuffer?: string | GPUBuffer);方法和getUniform(ub: IUniformBlock, name: string)给用到UBTemplate的对象提供修改和获取的支持。还记得前面说到的几个UniformBlock吗？其实就是用UBTemplate生成的，其中renderEnv管理了全局的UniformBlock，Mesh/ImageMesh/ComputeUint管理了单元级别的UniformBlock，而即将说到的Material管理了材质级别的UniformBlock，它们被设置到不同的地址，共同完成渲染。

在最终，也就是后续会提到的创建BindingGroup的那一步，使用的是getBindingGroup方法，在上面说到的几类对象上都有bindingGroup访问器代理到这里：

public getBindingGroup(ub: IUniformBlock, preGroup: GPUBindGroup) {
  if (ub.isBufferDirty) {
    renderEnv.device.queue.writeBuffer(
      ub.gpuBuffer as GPUBuffer,
      0,
      ub.cpuBuffer
    );

    ub.isBufferDirty = false;
  }

  if (ub.isDirty) {
    preGroup = renderEnv.device.createBindGroup({
      layout: ub.layout,
      entries: ub.entries
    });
    ub.isDirty = false;
  }

  return preGroup;
}

可见这里主要做了两件事，第一件事是检查脏位更新Uniform部分的数据，第二则是检查并更新group缓存返回。

Effect

效果Effect可以认为是对Shader、UniformBlock、渲染状态和宏的一个管理器，也可以认为是一个模板，以供后面的Material实例化，其构造参数为：

export interface IRenderStates {
  cullMode?: GPUCullMode;
  primitiveType?: GPUPrimitiveTopology;
  blendColor?: GPUBlendComponent;
  blendAlpha?: GPUBlendComponent;
  depthCompare?: GPUCompareFunction;
}

export interface IEffectOptionsRender {
  vs: string;
  fs: string;
  uniformDesc: IUniformsDescriptor;
  marcos?: {[key: string]: number | boolean};
  renderState?: IRenderStates;
}
export interface IEffectOptionsCompute {
  cs: string;
  uniformDesc: IUniformsDescriptor;
  marcos?: {[key: string]: number | boolean};
}
export type TEffectOptions = IEffectOptionsRender | IEffectOptionsCompute;

除去vs/fs（用于渲染）和cs（用于计算）的区分，通用的部分是：

UBTemplate构造参数uniformDesc：指定这个Effect提供的默认UniformBlock结构来创建UBTemplate。
宏对象marcos：Effect能够支持的宏特性列表，后续生成Shader的时候会使用。
渲染状态renderState：Effect提供的默认渲染状态，这里只定义了几个我用到过的，实际上还有不少。

Effect的功能并不多，其最重要的是对外暴露了createDefaultUniformBlock和getShader两个方法，以供最后的渲染使用。前者将会在Material中用到，后者则会在最后的Pipeline中用到。

Material

材质Material可以看做是实例化后的Effect，其构造如下：

constructor(
  protected _effect: Effect,
  values?: {[name: string]: TUniformValue},
  marcos?: {[key: string]: number | boolean},
  renderStates?: IRenderStates
) {
  super();

  this._uniformBlock = _effect.createDefaultUniformBlock();

  if (values) {
    Object.keys(values).forEach(name => this.setUniform(name, values[name]));
  }

  this._marcos = marcos || {};
  this._renderStates = renderStates || {};
}

可见其实很简单，就是利用拥有的Effect构建了一个材质级别的UniformBlock并设置初始值，然后提供了宏marcos和渲染状态renderState，后续也可以修改和获取这些宏和渲染状态。需要注意的是，Material还提供了version（number）类型，来记录版本，以便于后续Pipeline的更新。

Pipeline

讲了这么多，基本所有的要素都极其了，终于到了整个流程的最后一步——管线Pipeline。Pipeline的创建是分别实现在Mesh、ImageMesh、ComputeUint中的，也就是前面在论述这三者时提到的_createPipeline方法，如果读者还记得，其实这里就利用了上面说到的material.version来判断版本做缓存。这是因为和BindingGroup一样，创建Pipeline的开销并不低。

在Mesh中，创建的实现为：

const {device} = renderEnv;
const {_geometry, _material, _ubTemplate} = this;

this._bindingGroup = this._ubTemplate.getBindingGroup(this._uniformBlock, this._bindingGroup);
const marcos = Object.assign({}, _geometry.marcos, _material.marcos);
const {vs, fs} = _material.effect.getShader(marcos, _geometry.attributesDef, renderEnv.shaderPrefix, _ubTemplate.shaderPrefix);

this._pipelines[rt.pipelineHash] = device.createRenderPipeline({
  layout: device.createPipelineLayout({bindGroupLayouts: [
    renderEnv.uniformLayout,
    _material.effect.uniformLayout,
    _ubTemplate.uniformLayout
  ]}),

  vertex: {
    module: vs,
    entryPoint: "main",
    buffers: _geometry.vertexLayouts
  },

  fragment: {
    module: fs,
    targets: rt.colorFormats.map(format => ({
      format,
      blend: _material.blendColor ? {
        color: _material.blendColor,
        alpha: _material.blendAlpha
      } : undefined
    })),
    entryPoint: "main"
  },

  primitive: {
    topology: _material.primitiveType,
    cullMode: _material.cullMode
  },

  depthStencil: rt.depthStencilFormat && {
    format: rt.depthStencilFormat,
    depthWriteEnabled: true,
    depthCompare: _material.depthCompare
  }
});

可见这里将之前所有部分基本都串起来了，首先合并两个级别的宏，通过他们和Geometry的顶点信息Shader定义、三个级别的UniformBlock的Shader定义来生成最终的vs和fs，然后使用device.createRenderPipeline方法将这一切都组装起来，生成最终的Pipeline。

ImageMesh和上面基本一致，只不过省去了不需要的vertex部分，而ComputeUint由于没有顶点、片元，也没有渲染状态和渲染目标，更为简单：

 protected _createPipeline() {
  const {device} = renderEnv;
  const {_material} = this;

  const marcos = Object.assign({}, _material.marcos);
  const {cs} = _material.effect.getShader(marcos, '', renderEnv.shaderPrefix, '');

  this._pipeline = device.createComputePipeline({
    layout: device.createPipelineLayout({bindGroupLayouts: [
      renderEnv.uniformLayout,
      _material.effect.uniformLayout
    ]}),

    compute: {
      module: cs,
      entryPoint: "main"
    }
  });
}

至此，整个渲染引擎部分就此结束。

glTF和工作流

本来这里想顺便说说资源和工作流部分的，但篇幅已经太长了，就放在下一个章节讲吧。

【WebGPU实时光追美少女】概览介绍

dtysky — Monday, 06 Sep 2021 03:00:00 -00:00

本系列文章将会论述如何用WebGPU来实现一个实时路径追踪渲染器，从一个简单渲染器为开端层层深入，了解经典路径追踪渲染器的各个部分，以及BRDF模型在路径追踪中的实现。

Github仓库在这里：dtysky/webgpu-renderer，Demo在：Demo，注意目前需要最新的Chrome Canary版本才能打开。

这个项目是我三个月前一边学习闫神的GAMES202一边搞的，当时搞了大半的进度后迫于搞给自己庆生的游戏Double;14所以暂时搁置，游戏搞完了肝也废了缓了一阵子又出了一些头疼现实问题，最近都解决了才重新捡起来。

大纲

下面这些是这系列教程的一个大纲，都是通过GAMES101和202相关章节、阅读资料以及自己的理解做出来的，由于个人水平有限，所以难免有错漏之处，欢迎指出。同时迫于毕业时许诺的“三十岁之前一定要出一个商业品质的独立游戏，而现在只有两年时间了”以及做好可能RUN的准备带来的焦虑，所以这系列文章主要目的是基于现有的进度尽快收尾而非达到最优化，所以下面章节有的部分可能并不会完美实现，这些部分我会特别注明。

这个系列的文章预计如下：

概览介绍：本章节，将会对整个项目涉及的知识做一个综述。
WebGPU基础与简单渲染器：通过自己实现的一个简单渲染器来论述WebGPU的能力。
路径追踪-场景数据组织：针对路径追踪，如何组织场景数据，涉及到PBR材质、glTF、场景合并等。
路径追踪-管线组织与GBuffer：针对路径追踪，如何组织渲染管线，同时论述GBuffer的生成。
路径追踪-BVH构建与求交：如何构建BVH，以及如何在CS中求交。
路径追踪-随机采样与BRDF：论述如何在路径追踪中运用蒙特卡洛采样实现直接光照和间接光照，以及运用BRDF光照模型。
路径追踪-降噪与色调映射：如何对充满噪点的图像进行空间和时间的滤波，最后输出如何进行色调映射。
路径追踪-毛玻璃材质与BSDF：如何运用BSDF（BRDF+BTDF）模型实现毛玻璃材质。
踩坑与调试心得：对于WebGPU这样一个实验性的API（至少当时），我是如何进行调试的血泪史（主要是CS部分）。
性能优化：包括BVH并行构建、WebGPU管线优化等。

在这其中，章节7的降噪部分，目前大概率只会涉及到静态场景的简单滤波，而不会有Motion Vector、SVGF之类的进阶实现；章节8的BSDF至今仍未实现，并且不一定会实现，但关于透射整个框架已经搭好，会尽量做完吧；章节10的性能优化大概率不做了，如果梦想推进顺利可能会在未来某一天忽然补完。

（以上其实就是风险声明，烂尾别找我（逃

概览介绍

本项目主要分为两部分，第一是WebGPU部分，第二是路径追踪部分。

WebGPU

实时渲染在工业领域的应用离不开各个图形API，主流的API主要被各个系统厂商和标准委员会（实际上背后也是厂商）所支持，比如过去的OpenGL，OpenGL是一个跨平台的图形API，其迭代了漫长的岁月并在这些岁月中占据了这个领域大部分份额。在十年前，Web作为一个通用的平台也支持了图形接口，其名为WebGL，是OpenGL ES2在Web上的一个实现，在当时为Web带来了3D的可能。

但这也是十年前的事情了，在今天，图形API也遵循了“分久必合、合久必分”的规律，分裂成了DX12、Metal和Vulkan，这些API都更加底层、给开发者提供了更深层的可控性（当然同时也带来了更高的开发难度），相比于OpenGL，可谓是“自动挡”和“手动挡”的区别。而反观Web平台，这十年来却似乎毫无长进，在OpenGL迭代了如此多的版本后仍然停留在ES2的时代，只能打些扩展补丁缝缝补补，这当然很大一部分苹果不支持WebGL2的锅（虽然宣布将支持，但太晚了）。但苹果虽然在支持WebGL2上摸鱼，却也同时推进了更激进的下一代Web图形接口方案——WebGPU。关于WebGPU标准这几年的不断延期、标准的不断变更、API直到近两个月还在改、Shader变了一次又一次的槽就不吐了，总之，作为Web开发者的我们终于也有对标DX、Metal、Vulkan的图形API了，而事实上其API设计确实是借鉴了它们，并且用起来也足够简单。

值得欣慰的是，谷歌宣布Chrome 94的正式版将会正式支持WebGPU。

WebGPU标准目前的状态基本已经稳定，可见WebGPU标准。同时其使用的着色器也已确定，名为wgsl，详见WebGPU Shading Language。

在此项目中，我使用WebGPU实现了一个渲染器，其拥有UniformBlock、Effect、Material、Geometry、Texture、RenderTexture等资源的抽象，也有Scene、Node、Camera、Light的场景管理，还有Mesh、ImageMesh、ComputeUnit这样负责渲染和计算的单元，基本可以说是麻雀虽小五脏俱全。

除此之外，项目也支持由我之前写的seinjs-unity-toolkit导出的PBR材质的glTF文件，来作为内置的路径追踪渲染器的资源。

路径追踪

光线追踪是不同于光栅化的另一种渲染思路，或者说才是最符合直觉的思路。但由于其性能开销较高，所以很少在实时领域使用，基本都用于离线渲染。但在硬件性能日益变强的今天，实时光线追踪已然成为可能。光线追踪有很多种实现方式，最适合做实时的便是路径追踪：

如图，其本质上是从人眼（或者说相机）发射射线，和场景中的物体求交，然后利用“光沿直线传播”的原理反向追踪计算光路，然后再计算直接或间接光照，实际上现在的光栅化流程可以看做是路径追踪中的第一步。路径追踪主要优点是可以实时计算出间接光照，即便是由于性能问题目前往往只能做到一次间接光照计算，但效果也已经很不错了。

但注意，路径追踪并非是万能的，其假设的“光沿直线传播”在遇到透镜时可能会失效。

所以，路径追踪的第一步就是要将整个场景的数据组织起来。我们现在往往将模型视为三角面的集合，并且用“材质”来描写模型的渲染方式。这在光栅化的流程中很自然，但对于路径追踪，由于光线的求交是针对整个场景的，所以必然涉及到整个场景模型的合并，也涉及到如何将我们熟悉的“模型-材质”模式转换成路径追踪适用的模式，这也就涉及到场景的合并，以及合并中材质、贴图等资源的管理。

有了合并过的场景，我们还要有一个方法把整个渲染流程管理起来，路径追踪和传统的光栅化流程不太一样，其前面部分和传统的延迟管线有点类似，但后面却大相径庭，所以如何合理得组织渲染流程也是个问题。

接下来便是光线和三角面如何求交的问题，诚然我们可以直接暴力求交，这对于小场景也不是不可以，但场景稍微大一点便是巨量的性能开销，这就要求我们去寻找更快的求教方法，也就引出一个问题——如何划分场景的层次来加速求交。这里我使用的是现在最常见的BVH，所以这一步就是论述如何构建BVH以及如何在CS中对BVH求交。

取得了光线和物体表面的交点，接下来要解决的便是光照计算。这里做的是真实渲染，走的是PBR流程（这么说可能有点不严谨），而如果要做相对物理正确的渲染，就会涉及到目前大家都在用的BRDF模型。在BRDF的描述中，一个着色点的最终结果是由其法线半球内各个方向的光线的贡献总和，而我们一次只能发射一条射线，并且每次间接光反射也只能反射或透射出一条，这就引出了“蒙特卡洛采样”，也引出了直接光照、间接漫反射、间接高光反射、能量衰减、重要性采样等等。

解决了采样问题，随之而来的是噪声和性能问题，首先是性能问题，诚然我们可以在同一帧发射大量射线来直接收敛出最终结果，但这往往意味着极高的开销，但如果不这样做，就又会导致极大的噪声。而这就引出了非常经典的“时间换空间”思想——将一帧多次拆成一次多帧，然后再来解决降噪。降噪首先要考虑时域的滤波，即“Temporal Filter”，使用一定的权重将当前帧和前一帧加权混合，不断加重上一帧的权重来使得结果最终收敛。以时间滤波为基准，还可以加入空间滤波进行辅助，本项目用到了联合双边滤波。对于静态场景这基本已经足够，但对于动态场景还需要做的更多，比如引入“Motion Vector”之类的，也会面临更多问题。除此之外，由于整个场景是HDR的，还需要进行色调映射防止过曝。

如果只考虑非透明物体，功能方面到此基本可以说结束了，若要考虑毛玻璃这种材质，必须要引入BSDF模型，同时要考虑BTDF和BRDF。除了光照模型之外，透射也会影响到求交的计算，以及终止条件的判定。

然后就是对于WebGPU这么一个比较新的图形API如何调试的问题，尤其是如何调试CS，经过血泪尝试我构建了一套使用Storage Buffer来调试的方法。。。哎。。。

最后是优化部分，其实项目中还是有很多地方可以优化的，首当其冲的就是BVH的构建和求交部分，可以使用莫顿码进行GPU加速。其次WebGPU部分也可以做一些优化，比如Binding Group部分。其他好像。。。想不起来了。。。

总结

我好菜啊感觉还是有很多地方没有理解深刻很容易忘尽力了，但是为了美少女也值得了（虽然发现最后性能好像并搞不定美少女...），但是开坑了就得含泪填完这是我作为码农一面的底线，希望大家多多指正。

记一次向WebAssembly的移植:gl-matrix

dtysky — Sunday, 23 Jun 2019 22:00:00 -00:00

项目地址，欢迎Star（如果你觉得还行）：gl-matrix-wasm。

由于某些工作上的原因，以及个人兴趣，配合之前用Rust+WASM写软件渲染器的踩坑，端午花了三天将gl-matrix移植到了WASM（但因为各种奇奇怪怪的事情一直没时间发文）。此移植包含gl-matrix的所有功能，同时具备完整的单元测试。库本身以Rust + wasm-bindgen + wasm-pack + webpack4的形式开发，使用TS + Karma + Mocha来写单元测试（当然前两年还能扯一扯“优雅”啥的，现在这些都常识了也没啥说的）。在使用方面，我提供了两种使用模式，来应对不同的场合。同时还使用了很多Trick来在不破坏工程性的同时优化性能，某种意义上可以当做Rust来写WASM的工程的模板。

当然，新技术（或许也不算新了）总是看似很美好，坑却也无限大。具体详细的经历我就不说了（也没空），下面就大概说说一些坑，以及个人认为的WASM的优缺点吧。

坑（缺点）

坑其实和WASM本身关系不是特别大，主要是工具本身的坑，而有的缺点则是WASM目前切实的缺点了：

功能限制。如果你以为有了Rust就可以使用Rust所有能力快速开发一个WASM项目就太天真了，如果你的项目完全使用Rust编写或许可以，但一旦要和JS端进行交互，那就只能使用Rust的一个不大的子集（没有生命周期，没有trait等等...），函数无法返回引用（全走裸指针然后unsafe吧www要么就全走移动（其实是拷贝））。
内存管理。没有GC，需要手动内存管理。其实这确实也不是什么坑，但对于大多数被JS惯坏的前端也确实是个问题。而且如果你完全使用wasm-bindgen来托管内存管理（虽然还是要在js端xx.free()释放），那么你对内存的掌握又会下降，这可能会造成一些性能坑（比如在本库中，由于完全托管给Rust创建结构体，比自己在JS端直接操作WebAssembly.Memory实例进行ArrayBuffer的操作要慢的多，当然这个还有#4的问题）。
灵活性。这个其实是Rust的问题，其实仍然不算问题，只是JS这边确实有时候有的场景过于灵活，而Rust的借用规则由比较严格。举个例子，gl-matrix中经常会有vec3.add(a, a, b)这种使用方式，而这个是无法通过Rust的借用规则的，但它编译到WASM后又没办法在编译期检查，咋整呢——它搞了个运行时检查，这不但会使得逻辑无法实现还会使得性能有所下降（除此之外还有空指针检查）。当然这正是Rust可靠的表现，所以我选择把它黑掉（划掉）。
工程灵活性。这个主要是Rust工具链的可定制性问题。目前这套流程可以生成wasm + js + ts头的组合，在够用的情况下很完美。但...如果要做一些魔改（比如修改生成的JS来优化性能或自定义功能），就比较难受了，我这边采用的是超级Hack的方法，详见wasm-opt.js的黑魔法。
互操作开销。Rust本身通过ABI和JS互调用，但这个开销其实还蛮高的，这个可能会在某些状况打消掉WASM本身计算性能的优势。
异步。不错，目前WASM本身编译是强行异步的，这个可能会对代码组织有些坑（主要是库），如果是工程代码使用Webpack和异步模块其实也不是啥问题。
性能。这个其实不是WASM的问题，而是Rust工具链的问题（应该是），导致同样代码编译出来比CPP + EMCC编译出来慢两倍左右，具体见Issue 1585。这个问题我还没查明到底是啥（没空），如果有大佬帮忙再感谢不过。
体积。不错你没看错，同等功能WASM的体积比JS大两倍左右（至少在这个纯粹的库）。

优点

当然WASM本身优点也是有很多的（要不要它干嘛）：

可控。在WASM中，内存对于开发者是完全透明的，它就是一块线性的ArrayBuffer。Rust在其之上帮我们抽象出了堆和栈，帮我们做了一些事情，但其本质还是非常透明的，而精确的内存控制对于游戏这种复杂应用的好处是巨大的。
可预测。在WASM中，性能是可以预测的。你不用担心GC（The world！）或是JIT带来的迷失感。同一个函数执行100次和1000次稳稳差10倍左右。
低开销。GPU和内存开销都比JS更低，这个不用多说。
性能好。根据不同业务属性，性能提升不太一样。但是纯计算性能毋庸置疑是很高的，当然JIT后的JS也不差，这个下面会详细说。
深入融合Webpack工作流。这算是一个工程上可用的进步吧（比以前），Webpack4中WASM已经是一等公民了。
不用再写JS啦！对部分开发者这个可能是最重要的（当然有TS这个属性可能弱了点）。
完整。这个是说Rust这套流程的，它的web_sys和js_sys实现了WebIDL的完整Port，可用性还是很不错的（如果你不在意性能的话）。
还有的请补充......

性能

性能方面前面也说了，WASM的运算性能是可预测的，而JS则由于JIT和GC会比较难以预测。对于本应用，由于JS版本使用了TypedArrayBuffer，以及进行的都是非常容易优化的简单纯数学运算，所以JIT后的JS版本性能可以说达到了JS可达到的上限。但即使在这种状况下，对于大多数的测试WASM版本还是要稳稳压1.5倍左右：

详见[Benchmark(Matrix4, 2015 RMBP, Chrome)]（https://github.com/dtysky/gl-matrix-wasm/blob/master/Benchmark.md。

而对于真实世界，性能测试就没有Benchmark这么简单了，我写了DEMO来进行这个测试（当然对于Web 1000个物体的场景已经很大了）：http://gl-matrix-wasm.dtysky.moe/。

可见其实WASM版本在真实场景中还是有优势的（当然，Safari除外，其WASM现在优化得还不行）。

当然，除了这个库本身我也测试过别的应用，比如CRC32、数字图像处理、DOM操作等等，大致结论就是在无法简单优化的密集计算场景下，WASM有显著优势（比如模型压缩解压缩，加密解密），而在其他场合目前看来就差了点意思，投入产出比较低。

未来

未来来看，我觉得WASM有几点很值得关注：

WASI。WebAssembly System Interface，不用多说，这说明我们以前对WASM本身都有很深的误解，它并不是为Web而生的汇编语言，而是个恰好可以跑在Web上的通用虚拟机。这是个好东西，对未来WASM在更多场景可用而言很重要。
SIMD。simd.js提案被废弃后，SIMD on WebAssembly就成了Web使用SIMD唯一可预计的方式了，而SIMD可以为图形应用带来的好处也不用多说。
多线程。相比于阉割了SharedArrayBuffer的Worker（虽然有Transferable对象），这东西在某些场合很重要。

结论

一个项目是否要选择WASM，还是要从其适用性出发。如果你的项目是对计算要求较高，而且没有频繁的WASM <-> JS互操作，同时能保证内存都是申请在WASM虚拟机中最好，那么你的项目是比较适合使用WASM的。否则至少在目前时点不太建议。

特别要求性能，目前暂时考虑CPP版本，Rust版本在工程化的角度做的很好，而且团队足够重视，应该是未来的主流。

当然WASM本身目前起步也不是很久，它也在不断变好，相信未来它的能力和性能都会更强，也能适用于更多的领域（虽然大多领域应该还是干不过JS，“我为啥要功夫学这玩意，JS两下撸完回家打游戏不好吗？”）。

踩坑或许还不是特别深入，大佬觉得有问题或者建议请指正。

招人

本来想发招人的但目前也比较难，不过你有P7的实例肯定是没问题的，我们是支付宝互动图形团队，致力于在这个前端迷失的时代，在前端老本行的方向走的更远，给用户带来更好的体验。我们有自研Web3D/2D游戏引擎、巨量用户和业务场景，还和小程序团队直接相邻，有想法请直接联系我。

完。

前端视觉交互——全屏泛光

dtysky — Sunday, 09 Sep 2018 22:00:00 -00:00

Code: github.com/dtysky/paradise/tree/master/src/collection/GlobalBloom，github.com/dtysky/paradise/tree/master/src/collection/GlowEmissiveMap

Demo: paradise.dtysky.moe/effect/global-bloom，paradise.dtysky.moe/effect/glow-emissive-map

原理

本次的效果是全局辉光（Bloom），又称泛光。它其实是一种作用于特定区域的外发光效果。

外发光

在游戏中，我们经常可以见到外发光的效果。典型的比如在室内场景的吊灯、电子设备的屏幕、室外夜晚的路灯，还有车灯等。这些场景的共性是它们提供了亮度和气氛的强烈视觉信息。当我们观看屏幕等物体时，它们到达眼睛的光强是有限的，所以我们便通过其周围的辉光/泛光/光晕来辨别它们。在现实中，这些辉光是由于光线在大气或我们眼睛中产生散射而造成的。而利用数字图像处理的方法，我们可以比较简单得模拟这种效果。

RTT和后处理

一个最通用并且效果最佳的实现辉光的方法是后处理，它要求我们并不直接把主场景渲染的结果显示到屏幕上，而是将这个结果保存到一张纹理上，这个过程称为RTT(渲染到纹理)。拿到这个纹理之后，我们再渲染另一个只有一个全屏的Plane的场景，将前面保存的纹理作为贴图传入这个Plane的材质中进行渲染，在这个渲染的过程中我们可以添加一些特殊的效果，本质上，这些效果其实是应用于第一次渲染的主场景的图像的，所以这其实是一种对当前渲染结果的数字图像处理，这也就是后处理的本质。

对于这里要说的全局辉光，下面这张图比较清晰得描述了整个过程：

首先我们将主场景渲染到一张纹理上，而后将其应用到后处理专用场景中Plane的材质中，我们不断地重复RTT和后处理过程，最终得到了一张模糊后的纹理，最终我们将这个纹理和最初主场景的原始渲染纹理进行alpha混合，便可以得到最终的结果。下面让我们细致地分析一下整个过程。

渲染主场景

首先我们将主场景渲染到纹理：

this.rendererTarget0 = new THREE.WebGLRenderTarget(window.innerWidth, window.innerHeight);
this.renderer.render(this.scene, this.camera, this.rendererTarget0, true);

我们将this.rendererTarget0保存下来，作为最后混合的原始图像和阈值化的输入。

阈值化

当将主场景渲染到纹理后，我们要做的第一步就是阈值化。阈值化是图像处理中的一个概念，其本质是是将灰度高于某个值的像素颜色设为1，反之设为0，这是针对灰度图像的阈值化。而在本例中，我们对这个阈值化进行特例化——我们设定一个阈值，将纹理中灰度低于这个阈值的像素设为(0, 0, 0)，而灰度高于此阈值的像素，则保留，如此一来我们便可以得到一张只有“辉光”处色彩信息的纹理。将这张纹理保留下来，进行下一阶段：

这里有两个注意点，其一是阈值的选取，其二是降采样。

阈值的选取决定着辉光像素的筛选，一般有两种方法——全局阈值和局部阈值，全局阈值又有玄学调参、直方图选取等方式，局部阈值要和局部滤波器结合，这些内容在我大学时的论文中有详细分析，详见FPGA/图像处理】点操作—阈值化、FPGA/图像处理】局部滤波器-局部阈值化。

降采样，则是指降低纹理分辨率，降低后处理运算的开销。一般来讲是将要后处理的纹理降低到屏幕大小的四分之一，这样也可以使得模糊运算用更小的窗口模糊更大的范围。当然降采样也会带来走样的问题，这个的解决方法需要具体项目具体考量，这里不再赘述。

下面来看看代码：

this.rendererTarget1 = new THREE.WebGLRenderTarget(window.innerWidth / 2, window.innerHeight / 2);

this.quad.material = this.thresholdMaterial;
this.thresholdMaterial.uniforms.tDiffuse.value = this.rendererTarget0.texture;
this.renderer.render(this.finalScene, this.finalCamera, this.rendererTarget1, true);

uniform float threshold;
uniform sampler2D tDiffuse;

varying vec2 vUv;

void main() {
  vec4 color = texture2D(tDiffuse, vUv);
  float gray = color.r * .299 + color.g * .587 + color.b * .114;
  float th_color = gray > threshold ? 1. : 0.;

  if (gray > threshold) {
    gl_FragColor = color;
  } else {
    gl_FragColor = vec4(0., 0., 0., 1.0);
  }
}

可见，这里我通过阈值threshold来控制哪些像素和辉光像素。

分步模糊

得到了阈值化并降采样后的纹理rendererTarget1后，便可以进行下一步的模糊了。模糊本质上是一种利用卷积计算的局部滤波器，这一点可以参考我之前对均值滤波器的分析：【FPGA/图像处理】局部滤波器-均值滤波器。一般而言，此种模糊使用的都是高斯模糊，但我这里为了代码简单实例，用了一个XJB搞的均值滤波器。

如果看完了上面的文章，读者应该了解到局部滤波器本质上都是在一个窗口中完成的，窗口的大小一般为3x3、5x5等，而处理，则是以当前像素为中心取得的窗口中所有像素做一个卷积运算，当然在此DEMO的做法中是全部相加然后除以一个玄学值N，这相当于乘了一个所有元素都是1/N的卷积。

一般而言，这种操作对于每个像素都要做一个双重循环，毕竟要遍历每一行的每一列嘛，这样一来，如果是一个n x n的窗口，运算的总时间复杂度是O(n^2)（GPU运算先天并行，不考虑纹理大小）。这里我们就可以想到，能不能拆分行和列的两次模糊，来降低时间复杂度呢？当然是可以的，这也就是所谓的分布模糊。

分布模糊的想法很简单，就是以空间换时间，我们先对每个像素进行横向的模糊，渲染到一个纹理，然后再输入这个纹理，对每个像素进行纵向的模糊。这样一来，我们仍然可以得到最后的模糊结果，而时间复杂度却降到了O(n)：

让我们看看代码：

this.rendererTarget2 = new THREE.WebGLRenderTarget(window.innerWidth / 2, window.innerHeight / 2);

this.quad.material = this.localFilterMaterial;
this.localFilterMaterial.uniforms.vDirection.value = false;
this.localFilterMaterial.uniforms.tThreshold.value = this.rendererTarget1.texture;
this.renderer.render(this.finalScene, this.finalCamera, this.rendererTarget2, true);

this.localFilterMaterial.uniforms.vDirection.value = true;
this.localFilterMaterial.uniforms.tThreshold.value = this.rendererTarget2.texture;
this.renderer.render(this.finalScene, this.finalCamera, this.rendererTarget1, true);

#define WINDOW_SIZE 5.
#define DOUBLE_WINDOW_SIZE 10.

uniform float stepSize;
uniform bool vDirection;
uniform sampler2D tThreshold;

varying vec2 vUv;

void main() {
  vec4 blur = texture2D(tThreshold, vUv);

  if (vDirection) {
    for (float i = 1.; i <= WINDOW_SIZE; i += 1.) {
      blur += texture2D(tThreshold, vUv + vec2(0., i * stepSize));
      blur += texture2D(tThreshold, vUv - vec2(0., i * stepSize));
    }
  } else {
    for (float i = 1.; i <= WINDOW_SIZE; i += 1.) {
      blur += texture2D(tThreshold, vUv + vec2(i * stepSize, 0.));
      blur += texture2D(tThreshold, vUv - vec2(i * stepSize, 0.));
    }
  }

  blur.rgb = blur.rgb / DOUBLE_WINDOW_SIZE;

  gl_FragColor = blur;
}

这里我用vDirection控制是横向模糊还是纵向模糊，用stepSize控制窗口中每个像素的uv偏移，用WINDOW_SIZE定义窗口大小。通过这两次运算，便得到了模糊后的高光纹理图像。

辉光和色调映射

有了原始的渲染纹理和模糊后的辉光纹理，我们便可以进行最后的混合了：

this.quad.material = this.bloomMaterial;
this.bloomMaterial.uniforms.tDiffuse.value = this.rendererTarget0.texture;
this.bloomMaterial.uniforms.tBlur.value = this.rendererTarget1.texture;
this.renderer.render(this.finalScene, this.finalCamera);

uniform sampler2D tDiffuse;
uniform sampler2D tBlur;
uniform float toneExp;

varying vec2 vUv;

void main() {
  vec3 diffuseColor = texture2D(tDiffuse, vUv).rgb;
  vec3 blurColor = texture2D(tBlur, vUv).rgb;

  vec3 result = diffuseColor + blurColor;

  result = vec3(1.) - exp(-result * toneExp);

  gl_FragColor = vec4(result, 1.);
}

可见我分别对两个纹理进行了采样，而后将它们简单地混合到了一起，当然我这里没有用alpha混合而是简单的色彩混合，这和我前面模糊时的做法有关。由于是色彩混和，所以相加得到的结果result中的色彩值可能会超过0 ~ 1的色域，也就是说，我们得到的是一个高动态范围的结果。这就需要我们用Tone Mapping（色调映射）方法，来将高动态的渲染结果归一化到有限动态范围中，这也是HDR的原理之一。

色调映射本身是一个大话题，其发展历史和种类都十分繁多，在这里我们使用的是一种简单高效效果又不错的方法，即公式result = vec3(1.) - exp(-result * toneExp);，这个公式利用定义域在-∞ ~ 0的指数函数来进行映射，配合一个参数toneExp来调整曲线。

至此，我们便得到了最终的结果：

非后处理实现

对于少量模型的局部辉光也是可行的，但技术和上面的描述完全不同。它本质上是创建一个Billboard，上面渲染着平滑的“辉光纹理”，而后让这个Billboard跟随着要进行辉光的模型。但这种方法通常还是比较适用于2D物体，对于要时长变换视角的3D物体比较困难，适用面比较窄吧。

更可控

一般的辉光流程按照上一章的全局辉光-后处理+色调映射即可实现，不过那个实现方法有个弊端，就是阈值化这一步，辉光部分的筛选是程序决定的，很大程度上不可控，在现实应用中，我们需要更可控的方法来操纵辉光达到想要的效果。

自发光贴图

决定最终渲染风格的是美术人员，所以我们当然希望美术能决策整个场景，甚至将这种决策细化到单个模型。方法也很简单，和其他很多效果一样，我们可以建立一张纹理，通过采样这个纹理来决定辉光的强度和颜色，借此来取代阈值化的过程。

比如在这个DEMO中，我渲染了一个宇宙战舰（Unity免费模型），为了让战舰的特定部分辉光，我直接用EmissiveMap，即自发光纹理作为辉光的来源，由于战舰整体分为三个部分，我这里只给出一个部分的EmissiveMap作为实例：

整体的渲染流程和标准的全局辉光并无区别，在第一步还是正常地渲染整个场景，只是在筛选辉光像素这一部分，我修改了模型的材质，这个材质只以emissive和emissiveMap为基础色，渲染的结果即为标准流程中阈值化的结果：

// init
this.scene.traverse(node => {
  if (!(node instanceof THREE.Mesh)) {
    return;
  }

  const material = node.material as THREE.MeshStandardMaterial;
  const {emissive, emissiveMap} = material;

  this.originMaterials[node.uuid] = material;
  this.emissiveMaterials[node.uuid] = new THREE.MeshBasicMaterial({color: emissive, map: emissiveMap});
});

// loop
this.scene.traverse(node => {
  if (!(node instanceof THREE.Mesh)) {
    return;
  }

  if (this.originMaterials[node.uuid]) {
    node.material = this.emissiveMaterials[node.uuid];
  }
});
this.renderer.render(this.scene, this.camera, this.rendererTarget1, true);

接下来的流程和标准辉光流程一致。最终渲染效果如下：

前端视觉交互——轮廓边缘照明-菲涅尔反射

dtysky — Saturday, 08 Sep 2018 22:00:00 -00:00

Code: github.com/dtysky/paradise/tree/master/src/collection/RimLightFresnel

Demo: paradise.dtysky.moe/effect/rim-light-fresnel

原理

本次实现的效果是轮廓边缘内发光。顾名思义，其指的是在模型轮廓边缘内部的发光效果，核心是“边缘”和“内部”这两个词，也适合“外发光”（辉光、泛光）最大的区别。由于是在模型内部的发光，所以我们完全可以针对模型自身的材质去实现，不必使用后处理，这一点在性能上有所优势。当然，最重要的还是它本身能达到的效果的适用范围。

现实中的考察

计算机图形学很大一部分都是对现实的仿真，所以我们需要先考量一下这个效果在现实中的表现和原理。在现实中，边缘轮廓外发光最常见的例子就是一个平整而深远的水面，比如湖面。

当我们站在湖边看着湖面时，你会发现在脚下的湖面中的水是透明的，其反射并不强烈，而当望向远处之时，却会发现水并不透明，反射十分强烈，有一种泛光的效果。也就是说，当你的视线和观察的具有此效应的物质表面的夹角越小时，反射约明显。

这个现象也可以从玻璃珠观察到。当看向玻璃珠的中心之时，会发现反射比较弱，视线越靠近珠子两侧则反射越明显。

菲涅尔反射

上面的这种现象在光学中叫做“菲涅尔反射”。其本质上是由光从一种介质传播到另一种介质中的反射和折射造成的。一般来讲，对于金属外的绝大多数介质，光总在法线法线入射时反射比最小，即反光最少，而在和法线垂直的方向入射时，其反射比达到最大（不透射）。

这也就是说，我们可以在计算机中很简单地模拟这种现象，只要有模型上某顶点的法线和当前摄像机的视线，便可以通过很小的计算量计算出光强，从而得到这种轮廓边缘内发光的效果。

法线与视线

对于是一直在关注此系列的同学，对于法线和视线应当不陌生了。法线信息存储在模型的顶点数据中，携带着对某一图元所在平面的垂直向量的方向信息。而视线，则指的是摄像机前向向量（对于THREEJS是forward属性）。

有了法线和视线，结合上面所述的菲涅尔发射原理，我们便可以视线效果，首先在顶点着色器中计算光强：

uniform vec3 view_vector;
uniform float c;
uniform float p;

varying vec2 vUv;
varying float intensity;

void main() {
  vec3 v_normal = normalize(normalMatrix * normal);
    vec3 v_view = normalize(normalMatrix * view_vector);

    intensity = pow(c - dot(v_normal, v_view), p);
  vUv = uv;

  gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
}

片段着色器：

uniform sampler2D diffuse;
uniform vec3 glow_color;

varying float intensity;
varying vec2 vUv;

void main() {
    vec3 glow = glow_color * intensity;

  gl_FragColor = vec4(glow, 1.0) + texture2D(diffuse, vUv);
}

以上shader中，view_vector为视线向量。我们首先将视线和法线和法线变换矩阵normalMatrix求叉积并归一化，得到正确的视线和法线向量。之后再对这二者求点积，这个点积本质上其实就是两个向量夹角的余弦，由于余弦函数的性质，可知实现和法线平行时其值最大，垂直时其值最小。这一点和我们需要的恰恰相反，考虑到只用关心模型朝向视线这一边的渲染，我们只需要考虑夹角在-90 ~ 90deg时的状况，显然得知其值域实际上是0 ~ 1，所以我们只需要简单得换算一下，便可以得到最终的结果：

intensity = 1 - dot(v_normal, v_view);

这便是最朴素的菲涅尔反射的光强计算。在此公式的计算下，当我们将这个材质运用到球体上时，球体上将会叠加一层“光罩”，光的强度在球心处为0，在球的边缘处为1。

更细致的控制

然而仅有朴素的效果是不够的，我们还希望对发光的效果有着更细致的控制，比如反光的范围、方向、光强增强的速度等。相比读者已经注意到了在顶点着色器中那个最终的公式了：

intensity = pow(c - dot(v_normal, v_view), p);

这个公式中有两个参数c和p，它们实际上就是提供效果细致控制的参数。其中c控制的是发光的方向和范围，p控制的是光强增强的速度和光强的极限。你可以在DEMO的调参控制器中调节它们来查看效果。

限制

菲涅尔反射是根据法线和视线的夹角来计算最终照明的光强的，所以对于立方体、棱柱这种平整模型，由于模型的每个面的法线都一致，所以无法达到想要的效果。如果一定要使用这种效果，可以考虑曲面细分平滑或者利用法线贴图来修改顶点法线。

前端视觉交互——顶点动画实现图片过度

dtysky — Saturday, 21 Jul 2018 22:00:00 -00:00

Code: github.com/dtysky/paradise/tree/master/src/collection/ImageFragmentTransition

Demo: paradise.dtysky.moe/effect/image-fragment-transition

原理

这是一个非典型的顶点着色器实现的顶点动画的例子。它构造了一个可被打碎的平面，使得我可以在碎片化的过程中对两张图片做平滑过渡。

使用顶点构成三角片

看到这里，需要读者对OpenGL图形绘制底层有基本的了解。我们知道，OpenGL绘制一个曲面，本质上绘制的是一个个顶点构成的一个个三角面，这一个个三角面组合起来，便形成了整体的曲面。而这些顶点数据都是存储在buffer中的，我们需要一开始生成一个buffer，然后将其作为attributes一次性提交给GPU，之后就可以通过少量uniform变量控制渲染啦。

以ThreeJS为例，为了绘制一个三角形，我们需要进行几个步骤：

构造基于Buffer的几何体并生成顶点数据：

function disposeArray() {
  this.array = null;
}

const geometry = new THREE.BufferGeometry();
const positions = [x0, y0, z0, x1, y1, z1, x2, y2, z2];

geometry.addAttribute('position', new THREE.Float32BufferAttribute(positions, 3).onUpload(disposeArray));

注意这里最后一句，我们将positions中的每三个数据为一组(x, y, z)，将其作为attribute position 提交给GPU，并在提交后回收掉CPU这边的数组，避免内存浪费。提交之后，我们便可以在shader中使用数据了，注意shader中是针对每个顶点做处理，所以拿到的自然是vec3变量：

attribute vec3 position;

编写shader，构造材质：

const material = new THREE.RawShaderMaterial({
    uniforms,
    vertexShader: shaders.vertex,
    fragmentShader: shaders.fragment
  });
material.needsUpdate = true;

在这里，我们传入构造好的uniforms（主要是为了传入纹理和各个矩阵，有时也是为了动画），加之vertexShader和fragmentShader，便可以完成材质的构造。

生成曲面：

const mesh = new THREE.Mesh(geometry, material);

将曲面添加到场景后，启动渲染，便可以看到一个三角片了。

使用三角片构造平面

光有一个三角片当然不够，接下来我们要构造一个平面。这其实也很简单，依样画葫芦重复构造三角片就OK。让我们想想——一个矩形该如何用三角形构造？当然是用两个对称的三角形拼起来啦：

const positions = [l, t, 0, r, t, 0, l, b, 0, l, b, 0, r, b, 0, r, t, 0];

这里我构造了两个拼在一起的三角形，拼在一起就构成了矩形，其中l、r、t、b分别表示矩形的左右上下边界，由于是在xy平面，z都是0。

然而只是这样还是不够，我们需要的是碎片，很多很多碎片，不过这也不难办，只要将一个大矩形分隔成若干个小矩形，再将每个小矩形分割成两个三角片不就好了嘛：

const stepX = .1;
const stepY = .05;
const hStepX = stepX;
const hStepY = stepY;

for (let x = left; x < right; x += stepX) {
  for (let y = top; y < bottom; y += stepY) {
    const xL = x;
    const xR = x + hStepX;
    const yT = y;
    const yB = y + hStepY;

    positions.push(xL, yT, 0);
    positions.push(xL, yB, 0);
    positions.push(xR, yB, 0);
    positions.push(xL, yT, 0);
    positions.push(xR, yT, 0);
    positions.push(xR, yB, 0);
  }
}

其中stepX和stepY分别为小矩形的宽度和高度，通过这段代码，我们便生成了很多个小碎三角片构成的大矩形。

着色

上面说的都是如何生成顶点，但还有很重要的一步没说——如何给三角片着色？有过一定基础的同学应该都知道，在fragment shader中我们一般是通过uv坐标来采样纹理输出颜色，大家有没想过这个uv是从哪来的？不错，这个uv实际上是从vertex shader中的attribute变量传来的，而这个attribute和position一样，都是在CPU中算好（存储在模型顶点数据中）的：

for (let x = left; x < right; x += stepX) {
  for (let y = top; y < bottom; y += stepY) {
    // positions
    ......

    uvs.push((xL + right) / width, (yT + bottom) / height);
    uvs.push((xL + right) / width, (yB + bottom) / height);
    uvs.push((xR + right) / width, (yB + bottom) / height);
    uvs.push((xL + right) / width, (yT + bottom) / height);
    uvs.push((xR + right) / width, (yT + bottom) / height);
    uvs.push((xR + right) / width, (yB + bottom) / height);
  }
}

geometry.addAttribute('uv', new THREE.Float32BufferAttribute(uvs, 2).onUpload(disposeArray));

在这里，我们计算了每个顶点的uv坐标，并一并作为uv这个attribute提交给了GPU，然后便可以在shader中使用：

attribute vec2 uv;

打碎！添加attribute连接顶点

到此为止，我们应该可以渲染出来一张正常的图片了，我知道你们想说什么：费这么大事就为了渲染张图片？不要急，我们接下来只需要一点小技巧，便可以实现一个简单的碎片化效果：

vec3 new_position = position;
new_position.z += position.x;

gl_Position = projectionMatrix * modelViewMatrix * vec4(new_position, 1.0);

通过这几句代码，我们将每个顶点的z坐标位移了其x坐标的距离，理论上，我这么写想达到一个“从左到右，三角片一层一层铺开”的效果。然而事与愿违，如果你去运行这段代码，会发现整个图片还是连续的，只不过发生了在x-z平面的斜切罢了。想一想，会发生这种状况的原因是什么？其实很简单，对于两个相邻的三角片，它们的三个顶点中有两个是重合的，重合的顶点自然会如果不加处理，它们的位置变换将会保持一致，这样一来，所有重合的顶点其实可以视为一个顶点，所以才会导致变换后的图像仍然连续。

为了解决这个问题，我们要给同不同三角片的各个顶点不同的新attribute变量，来表明它们不同于重合点的属性。比如在3D模型中，有法线normal这个属性，它表明顶点的法线方向。在这个例子中，我们可以构造个叫做centre的属性，其表明每个三角片的中心点，然后再让三个顶点都拥有同样的centre属性：

for (let x = left; x < right; x += stepX) {
  for (let y = top; y < bottom; y += stepY) {
    // positions, uvs
    ......

    for (let i = 0; i < 3; i += 1) {
      centres.push(xL + (xR - xL) / 4, (yT + yB) / 2, 0);
    }

    for (let i = 0; i < 3; i += 1) {
      centres.push(xR - (xR - xL) / 4, (yT + yB) / 2, 0);
    }
  }
}

geometry.addAttribute('centre', new THREE.Float32BufferAttribute(centres, 3).onUpload(disposeArray));

之后顶点的变换都以这个中心点的位置为基准，如此一来，便可以区分每个重合但不在同一个三角面的顶点了：

new_position.z += centre.x;

动起来

现在，我们已经可以静态地打碎一张我们为其赋予纹理的图片了，但怎么让这个打碎的过程动起来呢？

这里的方案是引入外部uniform变量progress，这个变量是一个范围是0~1的自增变量，它表明运动的进度。结合这个变量和一些其他的变量，加之自己喜欢的顶点变换逻辑（公式），我们便可以实现很多惊艳的效果，比如此例中，我以图片中心点和顶点的距离为基准，结合progress，使用三角函数来控制x、y坐标，并赋予每个顶点的z坐标一定的差值，最终加上旋转让整个效果更富有动感：

attribute vec3 position;
attribute vec3 centre;
attribute vec2 uv;

uniform mat4 modelViewMatrix;
uniform mat4 projectionMatrix;
uniform float progress;
uniform float top;
uniform float left;
uniform float width;
uniform float height;

varying vec2 vUv;

vec3 rotate_around_z_in_degrees(vec3 vertex, float degree) {
    float alpha = degree * 3.14 / 180.0;
    float sina = sin(alpha);
    float cosa = cos(alpha);
    mat2 m = mat2(cosa, -sina, sina, cosa);
    return vec3(m * vertex.xy, vertex.z).xyz;
}

void main() {
    vUv = uv;
    vec3 new_position = position;
    vec3 center = vec3(left + width * 0.5, top + height * 0.5, 0);
    vec3 dist = center - centre;
    float len = length(dist);
    float factor;

    if (progress < 0.5) {
        factor = progress;
    } else {
        factor = (1. - progress);
    }

    float factor1 = len * factor * 10.;
    new_position.x -= sin(dist.x * factor1);
    new_position.y -= sin(dist.y * factor1);
    new_position.z += factor1;
    new_position = rotate_around_z_in_degrees(new_position, progress * 360.);

    gl_Position = projectionMatrix * modelViewMatrix * vec4(new_position, 1.0);
}

两张图片自然过渡

顶点动画到这里就结束了，对于本效果，最后还需要考虑的一点是如何让两张图片能自然得过渡。其实这一点在上面的vertex shader中就有所体现了——我以0.5为分界点，将整个运动的周期分为了两部分，第一部分平面逐渐被打碎，第二部分碎片逐渐收缩回平面。

而配合vertex shader，适当得编写fragment shader便可以轻松完成两个纹理的自然过渡：

uniform sampler2D image1;
uniform sampler2D image2;
uniform float progress;

varying vec2 vUv;

void main() {
  vec4 t_image;
  vec4 t_image1 = texture2D(image1, vUv);
  vec4 t_image2 = texture2D(image2, vUv);

  t_image = progress * t_image1 + (1. - progress) * t_image2;

  gl_FragColor = t_image;
}

利用progress，将两个纹理按照不同的权重混色起来即可。

前端视觉交互——Shader实现扩散水纹涟漪效果

dtysky — Sunday, 01 Jul 2018 16:00:00 -00:00

Code: github.com/dtysky/paradise/tree/master/src/collection/ShaderWaterRipple

Demo: paradise.dtysky.moe/effect/shader-water-ripple

原理

涟漪，是指现实世界中水面上落入物体时、以物体为圆心向四周不断生成扩散圆形式的涟漪并逐渐衰减的现象。真实世界的涟漪十分复杂，在图形学中，我们只能模拟它来按达到一个近似效果。而为了模拟涟漪，图形学也提供了各种各样的方法，像是各种map（flow map）等，但在这里，为了最简化资源和达到最好的动态效果、并阐明原理，本例由纯Shader绘制。

像是如何绘制一个平面并将贴图铺满这种前置工作我就不在赘述了。在这个效果中，我们首先要考虑的是如何模拟涟漪那一圈一圈的效果，这其实分为两个部分——其一是如何让贴图的像素进行偏移，另外则是如何绘制一个一个的圆，来使得贴图的像素按照这些圆进行偏移。

第一部分的原理在之前的作品《2D Pixel Displacement》中已经说过了，其实就是利用某个值当做当前像素uv坐标的偏移量，再用偏移后的uv去采样纹理即可。而第二部分，则需要用到一些平面解析几何的知识了。

基础

由于Shader中基本无法存储状态，所以只能由当前时刻的uv坐标和外部传入的变量（一般是当前时间time）来通过确定的公式算出，所以我们需要一个方程来描述距离某中心点不同距离的圆的信息：

vec2 tc = vUv.xy;
p = (tc - centre);
p.x = p.x * aspect;
len = length(p);

首先，我们拿到了当前像素的uv坐标tc，它是一个二维向量，对其和外部传入的uniform中心centre求差，得到其和中心的差值向量p，p携带了方向和距离两个信息，len即为其中的距离信息。（注意第三句，这里我用p的x分量乘了外部变量纵横比aspect，这是因为我们需要的是一个标准的圆，而要渲染的平面并非总是正方形，这就会导致uv坐标的比例不同）。

有了每一点相对于中点的距离，那么计算哪些点属于同一个圆也就十分简单了——只要它们的len相同即可。从最简化的层面而言，为了模拟涟漪，我可以用下面的公式：

uv_offset = (p / len) * cos(len * 3.14) * amp;

余弦函数的基本形式是y = cos(x)，它的周期为2π，值域为-1 ~ 1，为了便于理解，这里将len作为自变量并乘以π，将周期标准化为1。如此一来，所有和中心点距离为len的采样点，其偏移向量的模均一致，但方向各不相同，为大小归一化过得方向向量p / len，这便构成了一个由平面法向量定义的圆环。

之后将这个偏移向量加给原始的uv坐标，即可得到真实采样的坐标，计算颜色输出即可：

vec4 t_image = texture2D(image, fract(tc + uv));
gl_FragColor = t_image;

进阶

通过以上基础方法可以绘制得到一个从中心点向外扩散的、静态的涟漪，这个涟漪由若干个圆环构成，圆环的偏移从1 到 -1 再到 1，即包含一个波长。然而真实情况下，我们的一片涟漪显然不止一个波长，换言之，它是由许多个周期的圆环构成的；除此之外，我们还要给涟漪限定半径，让它能被控制在一定的范围内：

float waves_factor = waves * len / radius;
uv_offset = (p / len) * cos((waves * len / radius) * 3.14);

这里我引入了两个变量波数waves和半径radius，这个变换体现在函数曲线上，就是将上面公式中的函数曲线在定义域收缩了waves / radius，控制这二者可以让我们得到理想中的、一定半径下且具有一定数量的波的涟漪。

然而有了这些还是不能让涟漪运动起来，我们还需要一个外部变量引入一个递增的概念，这个一般是时间time，然而二了精确控制涟漪出现和消失的整个过程，这里我引入了进度current_progress和速度speed，进度的范围是0 ~ 1，表明着一个涟漪整个生命周期，速度则表明波形波动的速度：

float waves_factor = waves * len / radius;
uv_offset = (p / len) * cos((waves_factor - current_progress * speed) * 3.14);

通过这两个变量，即可让涟漪从中线点向四周扩散，运动起来。但我们说这样还是不够的，它只能形成一个不断循环由瞬间消失的鬼畜效果，为了使得效果更佳真实，我这里引入一个通带band的变量，其范围是0~1，它定义了一个范围，只有在这个范围内的波才能被看到，否则将被裁剪：

float wave_width = band * radius;
float current_radius = radius * current_progress;
float cut_factor = clamp(wave_width - abs(current_radius - len), 0.0, 1.0);
uv_offset = (p / len) * cos((waves_factor - current_progress * speed) * 3.14) * cut_factor;

这里我将band首先归一到了最大半径的范围内，之后将其和当前采样点与当前波运动到的半径比较，算出一个裁剪系数cut_factor，如果采样点和当前半径的距离在归一化后的通带内，则为1，否则为0。

然而这样会有个问题，若通带一直未一个静态量，那么最后涟漪还是会有在通带宽度的状态下突然消失的感觉。为了解决这个问题，这里再计算一个衰减系数damp_factor，其在一定进度前为1，之后逐渐变为0，将其和通带结合即可得出最后的裁剪系数，其含义是在某个时间段后逐渐压缩通带，直到进度为1时通带也被压缩为0：

float damp_factor = 1.0;
if (current_progress > .5) {
  damp_factor = (1.0 - current_progress) * 2.0;
}
float cut_factor = clamp(wave_width * damp_factor - abs(current_radius - len), 0.0, 1.0);

注意这里我计算了两个值，当前扩散半径current_radius和当前衰减系数damp_factor，这两个变量一个负责约束当前

在最后的最后，我们在配合一个可配置的振幅amp，其用于定义偏移量的峰值，即可得到最终的uv偏移：

uv_offset = (p / len) * cos((waves_factor - current_progress * speed) * 3.14) * amp * cut_factor;

Web方向传感器的正确使用姿势

dtysky — Monday, 25 Jun 2018 10:00:00 -00:00

现在移动设备普遍提供了重力传感器和方向传感器来测量设备方向，HTML5标准也提供了标准的API来进行方向信息的获取，获取方式是通过两个事件，他们分别是“orientationchange”和“deviceorientation”。

规范可以参考DeviceOrientation事件规范。

DEMO + NPM

我封装了一个模块用以方便得使用重力传感器和陀螺仪。

DEMO在：PanoramaImageViewer

NPM包：DeviceOrientationManager

Orientation Change

监听此事件可以获得设备当前的屏幕方向，通过window.orientation获取，正常竖屏为0，按顺时针渲染依次为：0 -> 90 -> 180 -> -90。

Device Orientation

监听此事件可以获取当前的设备的三个偏转角alpha、beta和gamma。

基础

本质上重力传感器和方向传感器都是派生传感器。重力传感器基于加速度传感器；方向传感器主要基于陀螺仪和磁力计，但主要还是基于陀螺仪。

陀螺仪本质上是用于测量角速度的仪器，其原理和我们日常生活中的陀螺基本一致——在陀螺高速旋转时，若没有外加力矩，其总是围绕一个固定转轴稳定转动（转动惯量大），这被称为定轴性，这也是陀螺仪最重要的一个特性，其基于角动量守恒原理。日常中的陀螺其实是一个具有两个自由度的偏轴陀螺仪，而在实际运用中的则是多为三个自由度的定轴陀螺仪，我们只要给不同的轴框不同的力，就可以使得对应的轴框转动，从而测出不同的姿态角：

移动设备上的陀螺仪基本都是MEMS（微机械）陀螺仪。对于HTML5标准，设备方向官方定义的坐标系为：

这其实是一个Z-UP的左手坐标系，而其中三个角度的定义为绕三个轴旋转的欧拉角：

围绕 Z 轴的旋转。当设备的顶部指向正北时 alpha 值为 0°。当设备逆时针旋转时，alpha 值增加。

围绕 X 轴的旋转。当设备的顶部和底部与地球表面等距时 beta 值为 0°。当设备的顶部倾向地球表面时，此值增加。

围绕 Y 轴的旋转。当设备的左右边缘与地球表面等距时 gamma 值为 0°。当设备的右侧倾向地球表面时，此值增加。

实践

从W3C标准来看，alpha的角度应该是 0 ~ 360，beta是 -180 ~ 180，gamma是 -90 ~ 90，并且这个变化应当是平滑的，但真实情况确实如此吗？

以下符号->表示逐渐变化，比如0 -> 180表示从0度逐渐变化到180度，|>表示瞬变，比如360 |> 0表示从360瞬变0。

Note: 这个是三星S9 Chrome实机测试结果，不同设备可能各有差异，比如实机测试和chrome sensors功能模拟的结果中alpha和gamma的变化就有所不同，这个非常坑爹，后面会详细说道。

实际换算

然而一般的实时渲染引擎（尤其是游戏引擎）使用的坐标系与以上坐标系不同，它们中的大多数都是使用Y-UP右手坐标系的，所以以下为基准，即：

屏幕朝向用户，横向为x轴、右侧为正，纵向为y轴、上侧为正，屏幕朝向方向为z轴、朝向屏幕外侧为正。

不仅如此，在需要使用到方向传感器的应用中（VR、AR），我们一般是使用其去控制一个场景中观察世界的相机，相机自身的坐标系的一般初始化为以屏幕正向面对用户时的Y-UP右手坐标系：

此时设备纵向旋转绕X轴（俯仰角pitch），横向旋转绕Y轴（偏航角yaw），剩下一个维度即为Z轴（翻滚角roll）:

这么一对比，不难发现当设备在不同朝向时摄像机的坐标系和方向传感器定义的坐标系其实是有一些差异的，他们存在一些对应关系。在下面，我将用pitch、yaw、roll为三个偏转角，给出它们与alpha、beta、gamma的关系。

window.orientation = 0

渲染场景竖屏，设备顶部朝上。

pitch = beta;
yaw = alpha;
roll = -gamma;

window.orientation = 90

渲染场景横屏，设备顶部朝左。

在0度基础上，将整个物体坐标系绕Z轴旋转-90度。

window.orientation = 180

渲染场景竖屏，设备顶部朝下。

在0度基础上，将整个物体坐标系绕Z轴旋转-180度。

window.orientation = -90

渲染场景横屏，设备顶部朝右。

在0度基础上，将整个物体坐标系绕Z轴旋转90度。

设备差异

原则上来讲，以上的换算非常完美，但这是建立在所有角度都正常，也就是一个循环一个正常的周期（0 -> 360 -> 0）的情况下的。当然，工程实践和理想状况总是有巨大的差异，有差异怎么办？还能怎么办，解决呗......

首先，经过测试后，发现设备普遍差异化为两种，第一种就是一开始的实机测试，而第二种（比如Chrome模拟器）中，alpha的变化是 0 -> -180 |> 180 -> 0，gamma变化是 0 -> 90 -> 0 -> -90 -> 0。这就导致在有的设备下alpha的值很完美，有的设备下gamma的值比较好，这就很尴尬了。

这就导致我要做一些兼容，首先让我们看看我们期望的三个偏转角和设备实机偏转（以Z-UP坐标系为准）的函数图像，以及它们实际的函数图像：

第一种设备：

第二种设备：

是不是发现都有挺大的很大差异？但其实也没什么差异，因为在正常使用中，方向传感器返回的三个欧拉角是互有关联的，比如第一种设备虽然看起来有很大的突变，但其实其突变的画风是这样的：

{alpha: -10, beta: 40, gamma: -90} -> {alpha: 170, beta: 170, gamma: 90}

这两对欧拉角在三维旋转中其实是等价的。

滤波去抖

真实世界中总是会有抖动的，所以我们需要一定的滤波算法来去抖。当然，不仅是alpha，其他两个角度也可以用同样的算法使得更加平滑，在这里我们一般使用LPF（低通滤波器，这里其实是一个拥有一定大小窗口的FIR实现的，学过信号处理的同学是不是很熟悉www）来滤除，用于滤除高频噪声（突变），其本质是加权平均滤波，会有一定的迟滞，窗口越大迟滞越大，但在一定范围内可以接受，同时注意smoothing参数，其越大表明当前值对结果影响越大。

const result = buffer.reduce(
  (last, current) => smoothing * current + (1 - smoothing) * last,
  removed
);

理想状况下，只需要对原始角度进行单个数字的滤波即可，即窗口中存的是[alpha1, alpha2, alpha3, alpha4, ...]，然而考虑前面的分析，所有角度都可能出现瞬变 360 <-> 0，虽然在角度层面上 360 和 0度是等价的，但对于滤波则不是。在滤波过程中，由于本方案涉及到加权平均值的计算，会导致当前值和实际值有一定的迟滞，所以在360 -> 0 度这种情境下，计算值看起来像是出现了几次的插值，比如 360 -> 280 -> ... -> 0，这会严重影响实际使用。解决方案也不是没有，考虑相隔一个周期（2π）两个角度，它们的sin(angle)和cos(angle)的值完全相等且这两个值可以确定在一个周期的定义域内的唯一角度。所以我们不直接对角度进行滤波，而是先变换为sin和cos进行滤波，最后再通过atan2(y, x)这个值域为-180 ~ 180的函数进行反变换即可。以下是atan2(cos(angle), sin(angle))这个函数的图像（弧度）：

atan2的值域是-180 ~ 180度，正好在一个周期，所以结果就是将alpha和beta归一化到了-180 ~ 180度内，而我们实际使用时一般会用正弦和预先函数处理，所以完全不影响使用。而对于gamma，其值域和原来保持一致。

突变注意

以上滤波可以解决大多数情况下的抖动，但对于《设备差异》一节最后的反转和补角突变，它也无能为力，我们可以设定低一些的获取频率、或者调高当前值得权重来解决这个问题。如果要求再高一些，建议关闭上面的滤波，自己去对四元数进行平滑。

和Camera结合

对于应用最为广泛的方向传感器 + 3D摄像头组合，直接将pitch、yaw、roll运用到就上旋转举矩阵或者四元数上即可：

const zee = new Vector3(0, 0, 1);
const screenTransform = new Quaternion();
const worldTransform = new Quaternion(-Math.sqrt(0.5), 0, 0, Math.sqrt(0.5));

const euler = new Euler();
// order = 'YXZ'
euler.order = order;
euler.set(pitch, yaw, roll, order);

camera.quaternion.setFromEuler(euler);
camera.quaternion.multiply(worldTransform);
camera.quaternion.multiply(screenTransform.setFromAxisAngle(zee, -orientation));

前端视觉交互——Particle3DByThree

dtysky — Sunday, 24 Jun 2018 02:00:00 -00:00

Code: https://github.com/dtysky/paradise/tree/master/src/collection/Particle3DByThree

Demo: http://paradise.dtysky.moe/effect/particle-3d-by-three

原理

这个效果是3D Particle Explorations其中之一的实现。觉得蛮有意思满酷炫就研究实现了一下。

基元

首先，顾名思义，这是一个粒子效果。和大多的粒子效果一样，它都是由一个一个小的“基元”组合而成的，而在本作品中这个基元就是“球体”，也就是说，那一个个粒子本质上是由SphereGeometry加上不同的Material形成的Mesh。对于本例的粒子，主要被设置的显示属性是半径、位置、颜色和透明度。

生长

光有粒子本身是无法实现效果的，我们还需要让它们按照一定的规律动起来。这个动起来包括两部分——其一是粒子自身的约束，其二是粒子间的约束。

首先是粒子自身的约束，这其实就是一个生命周期中，生长和消亡的过程。看到这个效果，我们很自然的可以想到——是不是有一个摄像机在对着粒子群，而粒子是在随着时间向着摄像头运动呢？当然是的，粒子群确实是在进行着“出生 -> 向摄像头运动 -> 消失”的生命循环，但实际上你会发现，仅仅是让粒子改变位置是无法达到这种效果的，我们还必须在粒子的一次生命周期中改变它的大小和透明度，使得变化更加自然：

this.mesh.scale.set(scale, scale, scale);
this.mesh.position.setZ(z);
// 4为设定的边界，可以调整
(this.mesh.material as THREE.Material).opacity = (1 - Math.abs(z) / 4) * this.config.opacity;

但仅仅这样还是不够的，如果所有粒子的行为都一致，那么实际的效果也只是粒子群同时运动到了某一平面，并没有实际效果的那种层次感。所以必须有一种细致操控每一个粒子的方法，来使得它们的生长具有差异化。这个方法也很简单，就是——给每个粒子设置不同的出生时间born和生命life，然后通过这两个参数控制粒子运动的整个周期，这就可以是的粒子群在宏观上拥有一致的运动曲线和终点，而在微观上每一个粒子又都各有自己的特点：

if (!this.initialized) {
  if (this.current < born) {
    this.current += deltaTime;
    return;
  }

  this.initialized = true;
  this.current = 0;
}

if (this.current + deltaTime > life) {
  return;
}

this.current += deltaTime;

这段代码说明了born、life的作用，它们决定了每个粒子开始运动和结束运动的时间。

运动曲线

光有时间无法让粒子运动起来，我们还需要根据时间去算粒子的z和scale，这就需要插值。一个简单的方式是线性插值，即值和时间成正比，但这显然无法达到我们的效果，我们需要的是一个Q弹的运动曲线，让每个粒子的运动有一种平滑自然的效果。

一般而言，为了实现曲线，大家都会选择Tween或者近似品，但为了从全局严格管控每一个粒子的行为，我引入了更底层的d3-ease和d3-interpolate，前者是运动曲线生成库，后者是插值库，二者配合就可以算出粒子起始和终点属性中任意的平滑的值。

现在让我们回到曲线本身，看着实例，想想我们究竟需要怎样的曲线？看起来像是QuadInOut对不对？不错，大概没错，但其实还是有些不同。QuadInOut的曲线是这样的：

但我们需要的曲线是这样的：

                                          -
                                          -
                                        --
                                      --
                                  ---
                                ---   
            -------------------
         ---
      ---
    --  
  --       
 -      
-

事实上，QuadInOut也不过是QuadIn和QuadOut的合成，它把两者各scale了0.5，之后再将二者拼起来，我们当然也可以这样做：

export function customInOut (duration: number, point1: number, point2: number, current: number): number {
  if (current < point1) {
    return d3Ease.easeQuadIn(current / point1) / 2;
  } else if (current < point2) {
    return .5;
  }

  return d3Ease.easeQuadOut((current - point2) / (duration - point2)) / 2 + .5;
}

这里我将曲线分成了三个阶段，第一阶段用QuadIn，第二阶段保持状态，第三阶段用QuadOut，这就是我们需要的曲线。有了曲线，插值就十分简单了，根据阶段选择不同的插值器即可，这里不再赘述：

const percent = customInOut(this.config.life, life * edgeTime1, life * edgeTime2, this.current);

if (percent === .5) {
  return;
}

const index = percent < .5 ? 0 : 1;
const realPercent = percent < .5 ? percent * 2 : percent * 2 - 1;
const {scale, z} = this.interpolates[index](realPercent);

斥力

到了这一步，粒子可以运动起来，也可以有层次感，但是不是觉得还少了些什么？对，还少了散开的效果。从实例中不难发现，粒子间的间距实际上是动态变化，当一个新的粒子插入粒子群时，所有的粒子开始动态调整间隙，一开始逐渐变大，到了一定的间隙之后基本保持不变。

这个现象很自然得可以想到用斥力来描述，废话不多说放代码：

for (let i = 0; i < count; i += 1) {
  const p1 = this.particles[i];
  const p1Pos = p1.mesh.position;

  if (!p1.initialized) {
    continue;
  }

  for (let j = 0; j < count; j += 1) {
    const p2 = this.particles[j];

    if (p1 === p2 || !p2.initialized) {
      continue;
    }

    const p2Pos = p2.mesh.position;
    const dx = p1Pos.x - p2Pos.x;
    const dy = p1Pos.y - p2Pos.y;
    const dist = dx * dx + dy * dy;
    const radii = (p1.size + p2.size) * (p1.size + p2.size) + spacing;

    if (dist < radii) {
      const angle = Math.atan2(dy, dx) + generateRandom(-0.05, 0.05);
      const diff = radii - dist;
      const x = Math.cos(angle) * diff * 0.05;
      const y = Math.sin(angle) * diff * 0.05;
      p1Pos.x += x * dTime;
      p1Pos.y += y * dTime;
      p2Pos.x -= x * dTime;
      p2Pos.y -= y * dTime;
    }
  }
}

这段代码简单明（cu）了（bao），就是遍历每一个粒子，然后去计算其他粒子对该粒子的力的作用，这里要注意两个约束：只有出生了的粒子才会进行计算，只有在两个粒子的间隙小于约束的间隙时才会进行调整，这样可以避免无效和错误的计算。

至此，整个系统就可以完美运行了。

前端视觉交互——PixelDisplacement2D

dtysky — Monday, 18 Jun 2018 20:00:00 -00:00

Code: https://github.com/dtysky/paradise/tree/master/src/collection/PixelDisplacement2D

Demo: paradise.dtysky.moe/effect/pixel-displacement-2d

原理

2D pixel displacement mapping，即2D像素位移映射（其实pixel换成fragment更合适，毕竟像素只是片段的一个子集），可以算作是3D vertex displacement mapping的一个变种。

3D顶点位移映射，比如displacement map中的效果，本质上是用一个球体，加上一张灰度图（下称dMap）作为参考，在每一帧渲染时，通过dMap上的采样结果来决定3D模型上顶点的位移，而这一变换是在顶点着色器中实现的，所以其真正得改变了模型的数据。这个映射后面会专门有个作品来展示，这里不多说。

回到2D像素位移映射，其实就是讲这种位移应用到了光栅化后的片段着色器中。其原理也很简单，让我们回想一下，现实生活我们去到了一个泳池，当水面有波动时，我们透过水面去看里面的东西其实从感官上而言是有偏移的，这个偏移则是相对于我们在空气中看到物体的实际位置，这种现象就是“光的折射”，而我们这个映射就是要模拟这种折射的效果。

那么折射现象应该怎么用片段着色器描述呢？在片段着色器中，我们可以获得从顶点着色器传来的uv坐标，对于纯2D图像，这个就是归一化过的采样坐标，比如(0.5, 0.5)这个坐标就意味着着色器正在处理的点就是图像的中心。一般而言，我们可以通过这个坐标到对应的贴图上去采样：

vec4 t_image = texture2D(image, uv);

这里t_image得到的就是通过uv坐标在image贴图上采样到的rgba像素值。这时候位移映射要做的事情就非常明确了——只要在计算的时候给uv坐标一个偏移，那么我采样到的就是贴图上另一个坐标的像素：

vec4 t_image = texture2D(image, uv + vec2(0.1, 0.2));

通过这句代码，我们将图像所有的像素值都向左偏移了(10%, 20%)。接下来，我们只需要对每一个不同uv坐标的片段做不同的位移就好了，这个位移的来源，其实就是dMap。在处理每个片段的时候，先采样dMap，用它的灰度加上处理作为位移值，之后将这个值应用到image贴图的采样中，就搞定啦：

  vec4 t_map = texture2D(map, vec2(vUv[0], vUv[1]));
  float offset = t_map.g;
  vec2 uv = vec2(vUv.x + offset, vUv.y + offset);

    vec4 t_image = texture2D(image, uv);

当然有这些还是不够的，目前我们只能得到一张静态的位移后的图，下一步我们需要让它动起来并且能控制其位移的程度。为了实现这些，我们需要三个uniform变量u_time, scaleX和scaleY，通过在js中更新这些变量，便可以间接地控制着色器中具体的坐标偏移量，比如下面这段代码就是通过一个不断递增的u_time去达到循环位移dMap的目的：

uniform sampler2D image;
uniform sampler2D map;
uniform float scaleX;
uniform float scaleY;
uniform float u_time;
varying vec2 vUv;

void main() {
  vec4 t_map = texture2D(map, fract(vUv + u_time);

  float offset = t_map.g;

  vec2 uv = vec2(
    vUv.x + offset * scaleX,
    vUv.y + offset * scaleY
  );

    vec4 t_image = texture2D(image, uv);

  gl_FragColor = t_image;
}

如此一来，dMap在渲染过程中不断平移，每个片段本次的uv偏移都是它邻点上一次的偏移，这样就可以有一种自然的波动效果了。

Lottie原理与源码解析

dtysky — Friday, 15 Jun 2018 19:00:00 -00:00

Lottie（Bodymivin）是一个动画库，其和GSAP这类专注动画曲线、插值等js动画库不同，它本质上是一套跨平台的平面动画解决方案。其提供了一套完整得从AE到各个终端的工具流，通过AE的插件将设计师做的动画导出成一套定义好的json文件，之后再通过渲染器进行渲染，它提供了“SVG”、“Canvas”和“HTML”三种渲染模式，最常用的是第一种和第二种。

特性

Lottie提供了如下特性，并给出了AE的功能支持度与限制：

http://airbnb.io/lottie/supported-features.html

每个渲染器均有各自的实现，其复杂度也各有不同，但毫无例外的是图形越多、参与运算的属性越多、帧率越高，其对性能的消耗也就越高，这些要看实际的状况。

lottie-web优势

以上列表可以看出在web上使用lottie的巨大优势：支持特性最多，可以做出最丰富的效果。而且得意于Web的特性，lottie-web较为灵活，迭代快，修改和添加功能也较为容易。

目前问题

没有发现官方或第三方对sprites map（如果有请务必告诉我！），而lottie动画的每个图片又相对较小，这个对于图片资源较多的情况下会有碎片化问题，对于移动端web在线资源是比较难接受的。所以需要想个办法让它支持，要么加一个前置Loader，要么进行修改源码，前者好处是不动源码，作为插件比较灵活，但有可能的性能问题，后者需要改动的可能较多（有可能要修改AE插件）但可能性能好一点，这个可以随着使用逐步研究起来。

代码分析

从lottie-web的Git源Clone代码，其中player/js目录下的即为播放器代码，其中module.js即为入口，让我们从这个文件开始分析，以一个文件被加载到播放以及各种其他操作为例，看看lottie到底做了什么工作：

Lottie模块

module.js中是标准的各种模式下模块的导出流程，其中模块在factory函数中被初始化并导出，在这个函数中，它定义了一个lottiejs，这个就是实际挂载模块的对象。

lottiejs.play = animationManager.play;
lottiejs.pause = animationManager.pause;
lottiejs.setLocationHref = setLocationHref;
lottiejs.togglePause = animationManager.togglePause;
lottiejs.setSpeed = animationManager.setSpeed;
lottiejs.setDirection = animationManager.setDirection;
......

静态方法

静态方法是指直接挂载在lottiejs上的方法，我们可以在导入lottie后直接调用，比如最基础的loadAnimation方法，其用法是：

import Lottie from 'lottie-web';

Lottie.loadAnimation({......});

lottie提供了很多这样的静态方法，比如setSpeed、inBrowser、installPlugin等，这些方法一般有两个作用：其一是设置所有动画对象的对应的属性值，比如我通过Lottie.setSpeed(.5)修改了速度，那么所有对象的速度就被修改为了的这个全局的速度；其二，静态方法还可以在没有拿到实际动画对象的时候对其进行控制，比如Lottie.play('animation1')就可以播放注册过的命名为'animation1'的对象，其等价于lottieAnimation1.play()。

初始化动画

lottie可以通过loadAnimation或registerAnimation来初始化动画。后者需要预先插入一个Tag，这个Tag上有一个data-animation-path属性，其的值需要指向你的动画的json文件，这个一般在你有许多lottie动画，预先对动画进行了布局时很有用，但一般我们使用的是第一种做法：通过一个对象来初始化一个动画对象。

可以在源码中看到，loadAnimation或registerAnimation这两个方法，以及其他大部分静态方法实际上都被委托到了一个叫animationManager的对象中同名的方法实现，那么这个对象在哪呢？在animation/AnimationManager中。

可见，这个对象可以说是实际上的模块顶层，大多重要方法都在其中。让我们找到上述两个初始化方法，看看它们都干了啥。首先是registerAnimation。

registerAnimation

function registerAnimation(element, animationData){
    if(!element){
        return null;
    }
    var i=0;
    while(i<len){
        if(registeredAnimations[i].elem == element && registeredAnimations[i].elem !== null ){
            return registeredAnimations[i].animation;
        }
        i+=1;
    }
    var animItem = new AnimationItem();
    setupAnimation(animItem, element);
    animItem.setData(element, animationData);
    return animItem;
}

首先这个对象的闭包中定义了几个全局的变量len、registeredAnimations等，用于判断和缓存已注册的动画元素。在调用这个方法时需要传入DOM对象element和动画数据animationData，先判断缓存中有没有对应对象，有的话直接返回，否则new一个AnimationItem类为animItem对象，AnimationItem这个类是动画容器的基类，之后会详细说到。新建对象后，lottie又将其和通过参数传入的DOM元素作为参数传入setupAnimation方法，这个方法中会进行一些自定义事件的绑定。在之后新建的animItem将会调用setData方法将animationData传入为对象设置动画数据，最后将对象返回：

setData

AnimationItem.prototype.setData = function (wrapper, animationData) {
    var params = {
        wrapper: wrapper,
        animationData: animationData ? (typeof animationData  === "object") ? animationData : JSON.parse(animationData) : null
    };
    var wrapperAttributes = wrapper.attributes;

    params.path = wrapperAttributes.getNamedItem('data-animation-path') ? wrapperAttributes.getNamedItem('data-animation-path').value : wrapperAttributes.getNamedItem('data-bm-path') ? wrapperAttributes.getNamedItem('data-bm-path').value :  wrapperAttributes.getNamedItem('bm-path') ? wrapperAttributes.getNamedItem('bm-path').value : '';

   ......
    this.setParams(params);
};

这个方法其实就是初始化animItem的参数params（通过this.setParams），参数中除了wrapper和animationData外还有path、autoplay这些参数，都是从wrapper、也就是传给registerAnimation的那个DOM元素的属性中获取的。让我们看看setParams干了啥：

setParams

AnimationItem.prototype.setParams = function(params) {
    ......
    var animType = params.animType ? params.animType : params.renderer ? params.renderer : 'svg';
    switch(animType){
        case 'canvas':
            this.renderer = new CanvasRenderer(this, params.rendererSettings);
            break;
        case 'svg':
            this.renderer = new SVGRenderer(this, params.rendererSettings);
            break;
        default:
            this.renderer = new HybridRenderer(this, params.rendererSettings);
            break;
    }
    ......
    if(params.animationData){
        this.configAnimation(params.animationData);
    }else if(params.path){
        if(params.path.substr(-4) != 'json'){
            if (params.path.substr(-1, 1) != '/') {
                params.path += '/';
            }
            params.path += 'data.json';
        }

        if(params.path.lastIndexOf('\\') != -1){
            this.path = params.path.substr(0,params.path.lastIndexOf('\\')+1);
        }else{
            this.path = params.path.substr(0,params.path.lastIndexOf('/')+1);
        }
        this.fileName = params.path.substr(params.path.lastIndexOf('/')+1);
        this.fileName = this.fileName.substr(0,this.fileName.lastIndexOf('.json'));

        assetLoader.load(params.path, this.configAnimation.bind(this));
    }
};

不太重要的地方就略去了，此方法中最重要的其实就两点——一是确定渲染方式并创建响应的渲染器，而是通过是否有animationData参数来确定数据来源并初始化数据，如果有则直接用这个数据，如果没有则去寻找path参数，之后调用assetLoader.load来初始化数据，最终数据都会被传给configAnimation方法。

Note: 这里要注意如果路径后缀不是json将会自动加上data.json！

configAnimation

AnimationItem.prototype.configAnimation = function (animData) {
    if(!this.renderer){
        return;
    }
    this.animationData = animData;
    this.totalFrames = Math.floor(this.animationData.op - this.animationData.ip);
    this.renderer.configAnimation(animData);
    if(!animData.assets){
        animData.assets = [];
    }
    this.renderer.searchExtraCompositions(animData.assets);

    this.assets = this.animationData.assets;
    this.frameRate = this.animationData.fr;
    this.firstFrame = Math.round(this.animationData.ip);
    this.frameMult = this.animationData.fr / 1000;
    this.trigger('config_ready');
    this.preloadImages();
    this.loadSegments();
    this.updaFrameModifier();
    this.waitForFontsLoaded();
};

在这个方法中将会初始化更多动画对象的属性，比如totalFrames等，此外最重要的是去加载一些其他资源，比如图像、字体等，也会去加载预先定义的片段segments（默认有一个），片段是lottie提供的一种动画控制手段，可以将多个动画统一在一个动画对象中，其本质上是不断调用loadNextSegments方法，获取片段路径然后不断调用assetsLoader.load方法去加载新的片段。

片段的路径被写死为了${basePath}/${filename}_${segementsPos}.json。

注意在加载片段后includeLayers方法被调用，其中主要涉及到一些静态资源的追加合成，以及利用utils/dataManager.completeData进行的animationData的检查和标准化（在别的阶段也会被调用，比如waitForFontsLoaded），还会调用expressionsPlugin.initExpressions（如果有的话）方法对数据中的表达式进行初始化。

一切都结束后一个data_ready事件将会被触发，至此，registerAnimation方式的动画Load便结束。

loadAnimation

loadAnimation的大部分流程和registerAnimation是一样的，不同的是它直接接受一个包含了初始化参数的animationData对象：

function loadAnimation(params){
    var animItem = new AnimationItem();
    setupAnimation(animItem, null);
    animItem.setParams(params);
    return animItem;
}

把setupAnimation的第二个参数直接置为null，去掉了setData阶段（因为不需要），直接跳到setParams阶段，剩下的都一样。

全局搜索初始化

除了以上两种方式初始化动画对象，还有个方法searchAnimations用于初始化所有dom元素定义的动画。它默认会搜索所有classList中有lottie或bodymovin的dom元素，将它们全部用registerAnimation进行初始化。

动画参数

Lottie通过一系列参数完成对动画对象的初始化，然而可悲的是他们被分散在源码的各个地方也没注释，好在官网还有一些例子加上拼凑我总结了一下定义：

{
  // 要挂载动画的DOM对象，默认为空，新建一个。
  container: HTMLElement;
  // 渲染模式，默认为canvas。
  // 对应DOM属性 data-anim-type | data-bm-type | bm-type | data-anim-renderer
  renderer: 'svg' | 'canvas' | 'html';
  // 循环参数，ture/false以开关量控制，若为数字，则0~max为循环次数，负数为无限循环。默认为true
  // 对应DOM属性 data-anim-loop | data-bm-loop | bm-loop
  loop: boolean | number;
  // 自动播放，默认为true。
  // 对应DOM属性 data-anim-autoplay | data-bm-autoplay | bm-autoplay
  autoplay: boolean;
  // 动画数据，需要符合数据格式（见下），优先级高于path参数，默认为null。
  animationData: AnimationData;
  // 动画json文件路径，如果末尾不是.json则会自动加上/data.json，默认为null。
  // 对应DOM属性 data-animation-path | data-bm-path | bm-path
  path: string;
  // 渲染设置。
  rendererSettings: {
    // 指定canvasContext
    context: canvasContext;
    // 是否先清除canvas画布，canvas模式独占，默认false。
    clearCanvas: boolean;
    // 是否开启渐进式加载，只有在需要的时候才加载dom元素，在有大量动画的时候会提升初始化性能，但动画显示可能有一些延迟，svg模式独占，默认为false。
    progressiveLoad: boolean;
    // 当元素opacity为0时隐藏元素，svg模式独占，默认为true。
    hideOnTransparent: boolean;
    // 容器追加class，默认为''
    className: string;
}

播放控制

Lottie提供了一系列API来控制播放流程，其控制的基准都分为两个层次——时间(time)和帧(frame)。一般而言像是goToAndPlay这种方法除了第一个value参数之外，还谁有一个isFrame参数，其表明前面这个值是time还是frame，一般而言默认都是时间，但我强烈建议用帧来控制，对应AE比较清晰。下面我列举一下常用的方法。

常用的方法

play(): 播放动画。
pause(): 暂停动画。
togglePause(): 切换播放和暂停的状态。
stop(): 停止动画。
goToAndStop(value: number, isFrame: boolean): 跳转到某时间/帧并播放。
goToAndPlay(value: number, isFrame: boolean): 跳转到某时间/帧并停止。
setSegment(init: number, end: number): 设置当前的segment区间。
playSegments(range: [number, number], force: boolean): 设置并播放当前的segment区间，force为true的时候讲立即播放，否则会等当前一循环播放完再切换。如果range[0] > range[1]则会设置方向为反播放。
resetSegments(force: boolean): 重置当前的segment区间，force依然是是否立即生效的标志。
setSpeed(value: number): 设置播放速度，基准为1。
setDirection(value: -1 | 1): 设置播放正反，1为正，-1为反。

play

让我们从animationItem.play方法开始吧，了解一下整个播放流程的细节：

if(this.isPaused === true){
    this.isPaused = false;
    if(this._idle){
        this._idle = false;
        this.trigger('_active');
    }
}

除去前置的各种flag判断，这个方法中最重要的操作就是触发了_active事件，让我们看看这个事件在哪里被监听了：

addPlayingCount -> activate -> first -> resume

_avtive事件只在一处被监听，其为AnimationManager.addPlayingCount，之后再传递到active方法中，之后再first(nowTime)方法中初始化播放时间，设置起点，然后就到了resume方法：

function resume(nowTime) {
    var elapsedTime = nowTime - initTime;
    var i;
    for(i=0;i<len;i+=1){
        registeredAnimations[i].animation.advanceTime(elapsedTime);
    }
    initTime = nowTime;
    if(playingAnimationsNum && !_isFrozen) {
        window.requestAnimationFrame(resume);
    } else {
        _stopped = true;
    }
}

这个方法中首先会计算当前时间和初始化时间的一个diffelapsedTime，之后将elapsedTime依次传入所有动画对象的advanceTime方法中，之后更新初始时间并根据状态看是否要进行下一次循环。可见，这里在首帧后lottie做的事情其实就是不断和上一次RAF的时间算diff，并不断利用这个diff去进行下一步操作。

advanceTime -> setCurrentRawFrameValue -> gotoFrame

advanceTime是animItem的一个方法，其主要工作是根据上一个方法传来的diff以及一些flag进行一些中间控制，比如判断是否播放结束，播放结束是否要Loop，同时在结束的时候触发响应的事件通知开发者。除此之外，其最重要的作用是算出nextValue = this.currentRawFrame + value * this.frameModifier;，即下一帧的帧数，然后传给animItem.setCurrentRawFrameValue方法，这个方法也只是记录下当前rawFrame（原始Frame）的值，然后直接跳到goToFrame方法。

在goToFrame方法中，lottie计算出了事实上的currentFrame，也就是实际用于渲染的frame值，触发进入frame的事件后，就调用动画对象自身的renderFrame方法进行渲染。

事件

以上无数次提到了lottie的事件机制，lottie提供了许多事件用于控制动画的播放和初始化等，以下是暴露出来的一些事件和触发时机：

complete：在播放结束后被触发（一次Loop结束不算）。
loopComplete：在没次Loop结束后触发。
enterFrame：在进入每一帧的时候触发（注意stop的时候也会触发一次）。
segmentStart：当一段segment开始播放的时候触发。
config_ready：当所有的参数配置解析完毕后触发。
data_ready：在所有的segments被加载完毕后触发。注意这个当你直接传入animationData而非path的时候，解析是同步的，所以执行完loadAnimation的时候实际上已经被触发过了，并且这个事件是超前与image这种资源的加载的，所以建议加上if (animation.loaded)的判断或绑定DOMLoaded事件。
data_failed：虽然文档写了但代码里并没有这个事件嗯。
loaded_images：所有图片资源加载完毕的时候会触发，虽然代码里写了 if (!error)然而当你详细去看的时候只会发现err永远为null。
DOMLoaded：当元素被添加到DOM的时候触发，这个是比较可靠的可以替换data_ready的事件。
destroy：当元素被释放的时候触发。

数据结构

接下来要讲最大头的渲染了，不过在这之前，我们需要先了解一下lottie所定义的数据结构，否则看到那些奇怪的ip、op、fr这些字段不知道是啥意思就尴尬了。

其实Lottie官方是给出了详细的定义的，在项目根目录下的docs/json内，随便打开一个animation.json可以看到：

"layers": {
  "title": "Layers",
  "description": "List of Composition Layers",
  "items": {
    "oneOf": [
      {
        "$ref": "#/layers/shape"
      },
      {
        "$ref": "#/layers/solid"
      },
      {
        "$ref": "#/layers/comp"
      },
      {
        "$ref": "#/layers/image"
      },
      {
        "$ref": "#/layers/null"
      },
      {
        "$ref": "#/layers/text"
      }
    ],
    "type": "object"
  },
  "type": "array"
}

key为在实际的json文件中对应的Key，title为标题，description为说明，type为其在程序中的数据类型，items则是其作为array类型的元素，oneOf以及其下的数组表示其元素为以下几种之一，$ref表示这种元素对应的文档地址。

通过这个，我们便可以很方便得查找每个字段的含义，这样也方便与理解渲染。

渲染

承接播放控制一节的最后，渲染从动画对象的renderFrame开始：

AnimationItem.prototype.renderFrame = function () {
    if(this.isLoaded === false){
        return;
    }
    this.renderer.renderFrame(this.currentFrame + this.firstFrame);
};

可见其首先做了下防卫，防止没有加载完成的动画的播放，然后就调用通过参数生成绑定的渲染器this.renderer的renderFrame，将当前帧数传给其进行渲染。

configAnimation -> includeLayers

让我们回顾一下动画初始化时的setParams阶段的configAnimation方法，其中有一句是：

this.renderer.configAnimation(animData);

这一句就是通过相应的renderer去通过动画数据初始化渲染的容器，比如对于svg渲染模式，就是去生成初始DOM节点，对于canvas，就是去生成初始化的画布。

在之后的初始化过程中，animItem.includeLayers方法还会调用到renderer.includeLayers方法，这个方法是在所有renderer继承的baseRenderer中的，它负责将所有动画数据中的图层保存到renderer中备用。

renderFrame

对于每个render，最核心的方法就是renderFrame，它最重要的代码如下：

this.globalData._mdf = false;
var i, len = this.layers.length;
if(!this.completeLayers){
    this.checkLayers(num);
}
for (i = len - 1; i >= 0; i--) {
    if(this.completeLayers || this.elements[i]){
        this.elements[i].prepareFrame(num - this.layers[i].st);
    }
}
if(this.globalData._mdf) {
    for (i = 0; i < len; i += 1) {
        if(this.completeLayers || this.elements[i]){
            this.elements[i].renderFrame();
        }
    }
}

这个渲染流程分为了三个步骤，分别是checkLayers、prepareFrame和renderFrame。

在checkLayers中，实际上做的事情是检查图层是否被建立完毕，如果没有则去使用图层原信息通过renderer.buildItem方法初始化真正的渲染数据，也可以认为是生成对应的虚拟渲染元素树，这些元素的实现都在elements目录下，对于这些元素之后会详细说道。注意对于svg渲染器，这个也会递归地去初始化DOM树，填充图形元素。

在prepareFrame中，实际上是调用每个初始化过的元素的prepareFrame，这个其实就是为渲染做准备，检查元素的一些状态然后决定globalData._mdf或是isInRange这些状态，为之后的渲染做准备。要注意的是每种元素（像是图形、文本等）的准备过程各有不同，而且官方这部分明显过度设计多继承加上没有注释也没有ts导致不太好阅读，所以读的时候要格外注意。

通过上一步得到的globalData._mdf属性，我们便可以判断是否要进行下一步的渲染，如果没有修改就不渲染，节省性能，其实不仅仅是全局的_mdf，每个子节点元素也自己会维护一个，来防止可以避免的渲染发生，这么来看，其实prepareFrame算是类似于React的前置Diff吧。

渲染阶段即调用每个节点元素的renderFrame实现，这个实现同样在每个渲染器也各有不同。细节太过丰富这里就不在细化解析了，只说下每一种的大致架构：

SVGRenderer

SVGRenderer的实际渲染实际上是委托给每个elements/svgElements下的每个元素进行的，其中最基础的是SVGBaselement，其他的几种Element都继承自它和其他的几种通用Element（比如elements/BaseElement）。对于SVGRenderer而言，所有元素本质上都被分成了两种：shape 和text，而这两种元素有各自的渲染方法进行渲染。注意这两种元素的实现也有一些共性，那就是对于动画中的变换以及滤镜等，他们的实现中都有类似这么一句：

extendPrototype([BaseElement,TransformElement,SVGBaseElement,IShapeElement,HierarchyElement,FrameElement,RenderableDOMElement], SVGShapeElement);

前面这一大长串的列表就是指这个元素类继承了多少种特性，这些特性中有来自于通用变换特性的像是TransformElement、RenderableDOMElement（在elements/helpers中），也有SVG的基础类SVGBaseElement，还有像是Shape元素的专用接口IShapeElement。而在实际的动画中，元素就是靠将具体的变化派发到这些基类的方法中去实现的。

比如我在AE做了一个shape的transform动画，那么最终这个动画会被派发给SVGShapeElement渲染逻辑，之后利用TransformElement中的计算逻辑计算每一帧对应的transform矩阵，然后在通过设置给具体的DOM元素上的属性或样式来完成修改。

而对于滤镜（主要是颜色效果），SVGElement则会将其派发给elements/svgElements/SVGEffect进行管理，而SVGEffect又会通过类型创建对应的effects下的对象，从而真正派发给这些对象进行渲染，其本质上其实也是生成色彩矩阵，归一化成矩阵进行管理。

CanvasRenderer

相较于SVGRenderer，CanvasRenderer受限于其能力，所以要简洁许多，当然这也造成了一些效果它不支持，比如滤镜效果（可以看到CanvasEffects.prototype.renderFrame = function(){}）。

CanvasRenderer本质上就是根据动画数据将每一帧的对象不断重绘出来，没有特别好说的。像是tranform变换这些和SVG的归一化处理基本一致。

HTMLRenderer

HTMLRenderer就没什么好说的了，受限于其功能，支持的特性最少，只能做一些很简单的图形或者文字，也不支持滤镜效果。其生成变换的原理倒是和SVG有些类似，毕竟都是DOM嘛。

前端视觉交互——TreesGenerator2D

dtysky — Sunday, 22 Apr 2018 19:00:00 -00:00

利用约束参数随机通过点击生成一颗颗抽象化的树。
这个效果是我在去年（2017）的the best of codepen发现的，觉得是很有意思，非常具有艺术感，于是学了下原理并在这里实现了一下。
code, demo

原理

此效果原理稍微有点复杂，需要分为“树的生成”以及“树的绘制”两部分，下面让我们来一步一步分析：

从一棵树开始

这个效果是可以支持多棵树同时生长的，但其基础还是一颗颗独立的树，所以为了弄清整个的原理，让我们先从一棵树开始。

树的抽象

为了绘制一棵树，我们首先要构建一个合适的对象来描述它。根据在现实世界的观察，不难得知一棵树最重要由三部分构成——“干”、“枝”、“叶”/“花”，所以再要构建的Tree对象中，理应有三个成员来描述它们。但考虑到在在一棵树的快进的生命周期中，其主干和分枝的生长应该是可以并行进行的，所以本质上它们是一个东西，而叶子不同，仍然是独立的，所以在Tree中我们只需要points和leaves两个成员来描述，前一个描述枝干的点集，后一个描述叶子，那么为什么是“点集”而不是别的呢，接下来就让我们分析一下。

树的绘制

有了树的抽象结构之后，要考虑的就是这样一个问题——假设我们已经有了一颗由以上的树，如何来描述其枝干和叶子，使其可以被最方便得绘制？考虑到绘制的媒介是canvas，我们能使用的工具也无非以下几个：

rect
image
arc
ellipse
line

rect和line对于一棵树的绘制而言太生硬，image不予考虑，剩下的也就只有arc和ellipse了。这二者其实没有本质上的区别，arc绘制的是圆弧、ellipse绘制的是椭圆，前者是后者的一个子集。相对而言，arc控制起来更为简单，所以在这里我们选择了arc——等等，有这么简单吗？

让我们仔细想想，arc绘制的是圆弧，设定一定的参数后便可以画出一个圆，而出去本身确实可以用圆来描述的抽象的叶子，枝干如何用圆来描述呢？显然我们不可能去真的绘制一个个很小的点并将其密集拼成像素化的树，这无论是性能还是效果都不会好。那么究竟应该如何去做？

答案其实很简单——拼起来即可。不错，你自己去尝试一下便可知，适当调整几个圆的绘制位置、半径、颜色和透明度，将它们叠在一起，你变可以得到一个类似于真实世界中的树干——它并不那么规整，但却乱得很合适，比如：

js ctx.fillStyle = 'hsla(208, 80%, 91.5%, 1)'; ctx.beginPath(); ctx.arc(400, 560, 16, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.arc(400, 555, 15, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.arc(400, 550, 14, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.arc(400, 545, 13, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.arc(400, 540, 13, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.arc(400, 535, 11, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.arc(400, 530, 12, 0, Math.PI * 2); ctx.fill();

当然，这里的位置、半径、颜色和透明度等约束参数如何确定也是一门技术活，这个后面会讲到。

如此一来，我们便可以通过一个点集来绘制出一棵树，接下来的重点就是如何生成这些点集，换言之，就是“如何让一棵树从某个位置的一个点生长出来”。

生长

树是从一点生长出来的，也就是说，在初始化树的时候我会传给它一个坐标，就像是埋下了一个种子，它以这个种子为基点长出来，并且在合适的地方生长和分叉。这就需要一套算法去计算这种“生长”结果，显然，这是一个和历史状态相关的函数，我们可以将此函数描述为：

points[n] = f(points[n - 1])
tree = points + leaves

其中points即为枝干的点集，那么我们如何来描述一个点呢？其实很简单，如前面所述，树的绘制是以点为基本单位的，所以这个点要能描述一个圆，所以其基本的属性也就是x、y、color、radius、opacity。也就是说，以上这个函数的本质，就是通过前一个点的这些属性，生成下一个点的这些属性。

有了这个思路，接下来就这个函数的实现了，这个实现需要一些数学知识，比如PerlinNoise。不过我们先不管这个，先回顾并理顺一下树生成的主逻辑：

首先确定一个种子的位置，生成种子，也就是第一个点。
然后不断调用函数f，生成下一个点、下下个点......
树的生长是有其极限的，这个极限应该是我们可以定义的。
生长到极限以后长出叶子。

可见，除去函数f，我们首先要定义一个树的生长极限并强制让它在这个时候停止生长。这个实现起来比较简单，只要在初始化的时候记录一个age，之后在点生成将其传入给点，保证每个点的age独立计算，并在生成新点的时候的时候不断检查这个age，看下一步是生成新的点还是叶子，到极限后在去遍历leaves数组绘制叶子，这个后面再说。

现在让我们回到函数f本身，看看它是怎么运作的。

生成函数

生成函数的核心是age、variance这两个点的属性，第一个前面说过了，是树的年龄，而一个则是分歧系数。其中年龄主要用于和PerlinNoise以及之前点的x和y组合计算出dirX和dirY，而variance则负责和degrees组合计算出randX和randY，它们一起组合生成下一个点的x和y：

```js const reduce = 0.01; const n = (noise.at((point.x + point.age) * reduce, (point.y + point.age) * reduce) - 0.5) * 4 * Math.PI; const mag = noise.at((point.y + point.age) * reduce, (point.x + point.age) * reduce); const dirX = Math.cos(n) * mag; const dirY = Math.sin(n) * mag;

const diff = variance * point.opacity; const degrees = point.degrees + (-diff + Math.random() * diff * 2);

const randX = Math.cos(radians(degrees)) * Tree.DRAW_DISTANCE; const randY = Math.sin(radians(degrees)) * Tree.DRAW_DISTANCE;

const x = point.x + dirX + randX; const y = point.y + dirY + randY; ```

我们不去细究PerlinNoise的细节，它本质上就是为了生成微小随机噪声，为树的生长提供一定接近真实的随机性，而variance这个分歧系数则是为了提供一个大幅度改变树生长朝向的能力，也就是为树提供产生分支的能力，其具体是通过修改degrees这个角度来实现的。

进一步研究其细节，会发现在树的整个生命周期中，主干一定会一直生长，而分枝是否会出现则是依据一个随机数是否在某一个范围内，同时随着年龄的增长，点的直径会越来越小，这就是最终生成的一颗一颗树是那个样子的理由。

叶子

当树生长到极限并满足一定的随机数之后，便会生成叶子，其实叶子和枝干的构成基本一致，只不过其受到的约束没有这么强，只要在其依附的分支周边一定范围内、并满足一定范围的大小即可。

这里程序设定了LEAF_DISTANCE和LEAFE_SIZE两个静态变量来约束叶子的范围和大小。

生成了叶子后，绘制也和枝干一样，用同样的方法将其画到对应区域即可。

到整片森林

完成了一棵树的绘制，要考虑的便是一个森林中许多树的并行生长了，所谓并行生长，就是说一颗树的生长不能阻塞其它树的生长，这个分解开来，便是并行计算与并行绘制。

为了维护多棵树，我们需要一个trees数组。这个数组负责在生成一棵树的时候将其入队，并在其绘制完成时将其剔除，不但如此，它还要管理每一棵树的“生长 -> 绘制”流程。这就要求树类Tree本身有一个生命周期的机制，来维护和管理其自身的初始化、更新、绘制和释放。

这个机制做起来并不困难，首先我设置了两个标记属性generated和drawn，分别表示树的生成状态和绘制状态。同时我也设计了两个方法update和draw分别用于更新计算和绘制。这两个生命周期函数在外部RAF触发的绘制循坏下不断执行，同时利用并更新两个标志位，便可以完成一棵树的整体的管理。

而得益于这种机制，树的并行绘制也水到渠成——只需要在每一帧轮询trees里的每一个对象，调用其对应的生命周期即可。当然，这也是绝大多数库包括游戏引擎的流行做法。

前端视觉交互——DigitalClock3D

dtysky — Sunday, 22 Apr 2018 18:00:00 -00:00

一个基于THREE和GSAP(Tween)实现的3D数字时钟。这个也是以前见过的一个效果，觉得很不错就尝试做出来了。
code,demo

原理

数字时钟想必大家基本都实现过，其逻辑模型很简单，就是用JS的API获取时间，然后将时分秒分别拆分计算出来，最后渲染到页面上。而本效果的重点是在于这个渲染。

效果拆解

首先让我们拆开这个时钟，不难发现其主要由六个数字和两对点构成，数字表明时间，由一个类似于魔方的立方体构成，点则用于分隔，由两个反色的cube构成，这个是单纯静态渲染方面的问题。而另一方面，如何让数字和点动起来也是个问题。也就是说，整个效果被规约为了以下几个小问题：

如何在平面渲染一个数字
如何在同一个立方体渲染多个数字
如何渲染点
如何让数字和点动起来

下面就这几点来做一下分析：

在平面上渲染一个数字

渲染一个数字并不困难，有过硬件背景或者做过数电实验的同学，应该都接触过数码管这东西。而在本效果中渲染一个数字和数码管其实没什么区别，本质上都是设置几个格子，通过将格子染上不同的颜色来表现出一个数字。在本例中，采用标准的3x5的格子阵列来表示一个数字，其中前景为黑色的格子，背景为白色的格子，倘若用1代表黑色格子，0代表白色格子，则数字4将有如下表现：

1 0 1
1 0 1
1 1 1
0 0 1
0 0 1

这就是一个数字在平面上的模型，换言之，只要立方体面对用户的这一面的格子颜色分配如上，用户就会看到一个4。

在同一个立方体渲染多个数字

以上的模型可以在平面渲染0-9的任意一个数字，让我们将思想扩展到三维，会发现每个格子都是组成数字的那个3x5x3的立方体中的每一个小cube在x-y平面上的投影。

那么如何让一个立方体能表现出多个数字呢？你的第一想法一定是：“每次更新这些格子，让它的数字变化不就可以了”。这当然是一种思路，但这种思路过于粗暴，无法实现本例中的效果，让我们仔细观察本例中数字的变换方式，它并非瞬变，而是通过不同行绕Y轴的渲染实现的。

这就产生了一个难题：我们需要合理得设置立方体中每一个cube的颜色，来使其可以通过绕Y轴的旋转来达到在x-y平面上投影出不同数字的目的。

这段话看起来拗口，其实说的问题很简单，就是说我们要在一定的约束下，构造一个立方体，这个立方体在Y轴方向上有5行，每一行都是一个有3x3个cube构成的阵列，每一行的旋转是独立的，每次旋转都会选择其一面朝向用户（即投影到 x-y平面），所有行投影的组合就构成了一个数字。这样一来，如何构造这个立方体就成了问题的症结所在，让我们仔细思考一下有哪些约束：

立方体由五行构成，每一行都是3x3的cube阵列
每行通过旋转构造一个x-y平面投影，投影可以组合出任意数字
每行的每个面之间有强关联，边角上的cube是重合的，投影后每一面的边角的那个格子会和相邻面耦合
需要构造每个数字的格子组合固定，总共十种

进行分析后，不难发现这其实可以通过枚举（也没别的办法）得出每一个数字需要的格子组合，然后反推出每一行需要的投影，最后再通过这些投影反推出每一行的cube颜色构成，最后再推算需要渲染一个数字时，每一行需要以那一面出现（即旋转到什么角度）。

根据这个思想，我写了个脚本num_helper.py来计算每一行可能出现的投影的组合，并将反算结果存在了NumbersLUT内，不难发现，这过程中我其实最终将问题规约成了一个对九宫格的染色问题：

0 0 1
0 0 0
1 1 1
（第一行的顶视图，旋转0度对应111，旋转90度对应001，旋转270度对应101）

如此一来，后续便可以通过每一行的转角来控制显示哪一个数字了。

渲染点

点的渲染就十分简单了，其实就是两个一半单位深度的、不同色的立方体拼起来，加个定位，并在每次时间更新的时候旋转180度罢了，不再赘述。

动起来

即便解决了渲染问题，倘若只是在每次时间更新的时候切换一下转角，也太过生硬。为了不那么生硬，我们需要对这种转角的变换做一个动画，这本质上其实就是在一定时间内对这个变换进行插值。这里我引入了通用的解决方案Tween来进行插值，使用起来只要设定好目标角度和duration即可：

js Tween.to(num.rotation, .4, {y: degree});

不过这里有一点需要注意，为了在时间变换时达到一个“前进”的观感，数字的每一行和点每次旋转的方向应该都是顺时针的。对于点而言这很好办，但对于数字就不同了，比如上面我们计算出的第一行，其三个角度是0、90和270，那么如果上一次的角度是270，这一次是90，直接旋转就会变成逆时针。这个解决起来也很简单，分两步实现：

使转角始终保持在0~360度内，在每次变换计算前先判断rotation.y的值，若大于360则减去360
判断当前角度和上一次角度的大小，若大于，则走正常逻辑，若小于，则给当前的角度加上360度

如此便可以保证顺时针的旋转。

编译TypeScript、C++和Rust到WebAssembly

dtysky — Sunday, 31 Dec 2017 18:00:00 -00:00

心得和例子已被整合到工程wasm-usage-guide中。

当下，wasm已被大多浏览器实现，其设计很巧妙，理论上任何可以编译成LLVM字节码的语言都可以被编译到wasm（借助llc和binary），在这个项目中，我对几种编译方式进行了实践并总结出了一些心得：

TypeScript: 现在有一个叫AssemblyScript的项目在做，借助Binaryen，已经可以跑通一些例子了。
C++ without Emscripten：直接用clang的前端编译到LLVM的bc，然后llc编译到汇编文件s，再用Binaryen的工具s2wasm从汇编文件编译到wasm的ast文件wast，最后用wasm-as编译到wasm。
Rust without Emscripten：用rustc通过编译选项编译到LLVM的bc，剩下的和CPP一样。
C++ with Emscripten：用Emscripten的emcc进行编译，附送一个runtime，实现了很多实用的方法，挺有用的，推荐使用。
Rust with Emscripten：rustc的nightly版本现在支持一个targetwasm32-unknown-emscripten，可以借助emscripten直接编译出一个runtime的js和wasm，但似乎emcc自身的arguments传不过去...看着用吧。

有兴趣的话，可以直接clone下来研究，写的都很全了。

如有疏忽请指出。

Bilibili圣诞游戏剖析-用pixi.js实现鬼畜音游

dtysky — Monday, 25 Dec 2017 00:00:00 -00:00

在正式看这篇文章之前，希望大家先去此处体验一下游戏，这样才能更好地理解我的此次分享：

继七夕活动之后，我又负责了圣诞活动Jingel Beats的开发，这次放弃了白鹭引擎，使用了侵入性比较低的pixi.js。下面我就此次活动的一些心得。

不过在了解到有Phaser之后，其实本游戏应该用它来做，比起PIXI这个渲染引擎，它才是一个实际的游戏引擎，自带音频、物理引擎、摄像机、输入归一化、全局画布管理、内置状态管理等等设计也更符合游戏的需求，希望大家可以尝试一下。不过对于一般的轻量级游戏，还是可以直接用PIXI，毕竟Phaser的mini版本也有1.7m了...

前言

在活动开发方面，我一直致力于形式的探索，而由于国内审美环境特别，现在国际主流的设计无法很好使用（这个也和跳过了桌面端而直接到移动端有关），所以需要另辟蹊径。不难想到，交互形式的极致其实就是游戏，而游戏同时也是受众最为广泛的一种形式，加之本人本身就对游戏有着极高的兴趣和爱好，所以这次在这个方向又做了一个尝试。

当然，如果大家谁有有趣的、纯公益或者纯艺术性与新媒体结合的路子，可以找我，视情况我可以提供无偿的技术支持，不仅仅是web前端，硬件我也可以视情况奉陪。

这次的游戏形式是MUG，即音乐节奏类游戏，这类游戏的代表有Project Diva、太鼓达人、DJMAX、OSU等。其形式各有所长，输入方式也千门百类，且每种都有大量fans（当然，真fan无论哪种都很喜欢）。而由于是此游戏主打移动端，并且是运行在浏览器内，所以考虑到输入方式和一些边边角角的问题后，我初步给出了两种形式：

玩法一：太鼓达人式的游戏模式，其核心在于一个和音频同步、不断向一侧移动的元素序列，由于整体是一个长条，所以绘制较为简单，但玩家控制并非直接作用于元素之上，而是利用两个按钮进行输入，所以逻辑有些复杂。在正常模式之后，还会有一个随意点击屏幕可视区域的奖励模式。这种玩家操作都规约到两个按钮的游戏模式比较亲民，而且操作上也不会有和浏览器以及设备本身有过多的冲突，中规中矩，比较保险。
玩法二：有些像PSV上的那一作DJMAX，或者是触控模式的OSU。元素不像太鼓达人在一个长条内，而是多出一个空间的属性，铺满了整个屏幕。随后，我将给每个元素赋予不同的类型，每种类型代表一个手势，当元素出现时，玩家需要去定位元素，之后遵守元素自身的手势去拖动它，完成判定，最终也有个奖励模式，就是模仿地雷社的限界凸骑中的撸动屏幕，带来整个游戏的高潮——这个方案充分挖掘了触屏的优势，可玩性也很高，不过也有其自身的问题。

玩法二的问题在于当玩家投入游玩后，可能会手势越界，唤醒浏览器自身的手势行为，亦或是唤醒设备本身的通知栏等。而MUG本身是一种不能被中断的游戏，所以为了保险，最终还是选择了玩法一——这也是在浏览器中做游戏的限制。不过，忙过这阵子我将尝试实现这种模式（作为个人项目）。

架构

一个MUG，或者说几乎任何一个游戏，都可以被拆解为逻辑和展示这两个部分，而逻辑部分和试图部分的分离也是复杂度得以控制的根源。拿此游戏为例，运行时的状态和判定等，并非是由元素的位置决定，而是由当前的时间决定的，而这个时间也同时控制着元素位置和状态的绘制——这样一种状态视图解耦、状态驱动视图、单向数据流的模型，和现代前端开发的MVC等视图框架没有太大区别。所以接下来，我将从控制层和表示层这两层来描述。

玩法核心

控制层的核心便是围绕玩法的逻辑，本游戏逻辑相对单纯却也不失丰富：

元素的类型，有左按、右按、一起按三种。
在操作维度上，有点击和长按两种。
判定方面，有miss、good和perfect三种。
游戏流程，则有普通模式、奖励模式，还有基于能量的fever机制和失败判定，以及得分、Combo和判定类型的统计。
难度方面，我们提供了easy、normal和hard三种模式。
而在数值设计上，参照魔界战记大额伤害带来的爽快感，这里一个good积分666、perfect积分1000，fever状态翻倍。

以上要素加起来，其实已然不仅仅是一个HTML5小游戏，而可以说是一个完整版音游了。加之后面会说的可以灵活切换的谱面设计，套个壳再多加几首歌都可以上架了（逃。

图层管理

作为一个MUG，玩家的注意力应当是高度集中在玩法本身上的，所以应当给节奏条和控制器很高的优先度，而其它元素则是以客场的身份——它们只是作为背景，并且不宜过度复杂，否则将会干扰视觉（这一点在歌姬计划的某些曲目有所体现），所以经过讨论，加之B站背景的限制，我们选择了今天妈妈不在家这个鬼畜的梗（bgm本身也是鬼畜版的），让玩家的操作来控制22和33的动作，并利用一些小的元素（比如烤箱喷射的食物、fever时候降下的灯）等来烘托氛围。基于以上，图层实际被分割为：

background: 背景图层，用于放置在最底层元素的基础元素，比如屋子的图片、闪烁的灯等。
chars: 人物图层，放置22和33.
magic: 核心元素图层，用于放置节奏条和控制器。
ui: UI图层，记分板、引导页和结果页放在这里。

这些图层自底而上，一层一层构成了整个游戏的视觉部分。

自适应

本游戏和七夕游戏一样，也遇到了强制横屏的问题，但pixi并没有提供官方的强制竖屏和自适应方案。一开始我按照egret的方案去做，但遇到了一些问题，而解决方案我确实也找到了，如有需要，请参照我写的这篇文章：在pixi.js实现设备自适应和强制竖屏。

实现

架构说完了，让我们进入细节来看看具体的实现吧。

谱面设计

将可配置的尽量提出来变成可配置的，是降低工程复杂度的最佳方式之一，无论这个配置看起来和程序主题耦合的多么深——在此游戏中，这个最大的配置就是谱面本身。如果我只是为了一个谱面来单纯写一个游戏，那它只是一段是毫无价值的堆砌式代码，而倘若我将谱面作为一个配置项来服务于程序主体，那我就做了了一个引擎似的东西——它高度复用，以后有新的需求或者需求的修改，只需要修改配置即可。做好架子，将核心逻辑和形式内容分离，当产品或内容想修改的时候将只需要将配置拿来，这是最合理的分工。

好，废话不多说，先来看一看下面的类型定义：

export type TRhythm = {
  level: number,
  bps: number,
  direction: TDirection,
  award: {
    start: number,
    end: number
  },
  // 0 ~ 1
  fever: number,
  duration: number;
  sequence: TRhythmElement[]
};

TRhythm即为谱面的数据结构，它最核心的几个要素是：

bps: 一秒的拍数，用于控制谱面整体的速度。
award: 奖励模式的起始和结束拍数定义。
fever: fever阈值定义，其为一个比例，这个比例代表的是fever所需能量占据游戏可获取的所有能量的比例。
duration: 谱面长度，以拍数记。
sequence：核心，谱面序列，这个定义其实是解析后的元素序列，解析前则是一个字符串，解析过程将会在下一节讲到。

这些属性加起来就定义了一个谱面，若有需求变更，只需要修改这个谱面即可。

谱面解析

有了原始的谱面定义，程序便可以将其解析，转换为运行时实际的谱面。而这个解析的核心，实际上是对sequence这个序列的转换。让我们来看看一段原始的、字符串描述的谱面和转换后的TRhythmElement[]序列是怎样的：

export type TRhythmElement = {
  type: TElement,
  // int, beats from last element
  start: number,
  // 1 is short, others are long-touch element
  beats: TBeats
};

const squence = '010|121|233';
// bps = 1
const convertedSequence = [
  {type: 0, beats: 1, start: 0},
  {type: 1, beats: 2, start: 1},
  {type: 2, beats: 3, start: 3}
];

可以看到，原始的谱面实际上是由一段由|分割的字符串描述的，其定义为${type}${beats}${start}|...，它们正好对应TRhythmElement中的三个属性，分别表示节奏元素的类型、拍数和距离上一个元素结束时的拍数，在本游戏这种类型的MUG中，这三个属性足以描述一个元素。

从标准化的字符串向TRhythmElement[]的转换只是第一步，在拿到了转换后的TRhythm后，对谱面的解析才真正开始。第二步解析的目的是——将拍数描述的谱面转换为时间描述，并同时生成每个元素对应的视觉容器，之后将它们放入顶层容器中。视觉方面的实现下一节再讲，这里先说一下逻辑上的实现，来看看下面的这个新类型：

export type TRhythmPlayElement = {
  type: TElement,
  start: number,
  end: number,
  beats: TBeats,
  element: PIXI.Container
};

这是经过解析后元素的最终形态，和TRhythmElement不同，这里的start和新多出的end的单位都是ms，并且它们的值都不再是相对于上一个元素的偏移，而是绝对时间，这是游戏运行时进行判定操作所必要的。与此同时，这里还多出了一个element属性，它用于保存元素在视图层容器的引用。

元素序列条

谱面被解析后，生成了被各种属性描述的元素，被保存在一个序列中。这个序列除了逻辑，还保存着其视图容器的引用。而这个视图容器其实就是游戏过程中的那一个个圆形或者长条的元素，这些容器的也是伴随着谱面解析同步生成的。下面我就来说说这些容器生成的细节。

节奏元素以及其外部容器分为四个部分，其一是最底层的那个半透明轨道，其二是圆形的判定框，第三是那一个个元素构成的序列条，第四就是元素被命中时判定框环测的闪光和星星。在游戏过程中，元素在轨道上不断从右向左运动，到了判定框后，随着玩家的操作或者自发发起操作来引起游戏判定，判定后元素消失，如果是长按型的元素（长条状），则要保证该元素不会穿过判定框，即产生一个进洞的效果。这三部分中，半透明轨道直接使用了PIXI.Graphics来绘制：

rail.beginFill(config.railColor, config.railAlpha);
rail.drawRect(0, 0, width, config.rhythmRailHeight);
rail.endFill();

而判定框，则是一个PIXI.Sprite，它的宽高是和轨道相关的，比轨道的高略小。这里要注意的是判定框并非真的主导了“判定”操作，“判定”操作实际上是和核心逻辑、也就是每个元素自身存储的start和end决定的，这里的判定框不过是给了玩家一个视觉上的预期，让他们有了操作的依据。

在这四个部分当中，元素序列条最为重要。在游戏过程中，从玩家角度来看，元素似乎是一个一个从屏幕右侧生成的，但实际上，实时生成元素对于性能和复杂度而言都是不太可取的。我这里采用的策略是预生成，也就是说，我先生成了一个名为elements的容器，之后在谱面解析时、对一个一个节奏点的循环中去生成元素element，并按照它们的拍数去计算相对位置，然后将它们放入elements中：

const element = new Element(textures[`elements-${type}`], beats, diam);
const diffBeats = start + preBeats;
center += diffBeats * diam;
element.x = center - radius;
preBeats = beats;

Element是我自己定义的一个类，其通过类型、拍数和直径绘制出一个元素，绘制原理本质上也很简单，如果beats为1，即一拍的元素，则直接当做一个Sprite处理，如果是多拍的元素，则套上一个容器，在内部利用Graphics画好白色的外框背景，然后再把一个Sprite放到背景上即可。绘制好了之后便要调整她的位置，由于只有一个维度的运动，所以只需要调整x的值。我是用了一个center变量来存储每个元素中心的位置，利用中心同步而非边缘有利于降低心智负担，其中radius和diam是元素的半径，这个是可以调整的，preBeats是上一个元素的拍数，start是此元素距离上一个元素结束时的拍数，通过这样不断的循环计算，我们便可以得到一个element的序列，在实际运行时，运动的实际上是外层的容器，而不是元素自身，这样也减少了计算和更新的逻辑。

至此，元素序列条本身的绘制已然完成，但如果仅仅如此，当这个序列条的容器运动时，元素还是会越过判定框，没有符合进洞这个效果的预期。为了实现这一点，我是用了mask这个属性：

elementsContainer.addChild(elementsMask);
elementsContainer.addChild(elements);
elementsContainer.mask = elementsMask;

创建一个更顶层的容器elementsContainer，将elements作为child加入其中，之后对其设置一个mask。容器的位置固定，和轨道的宽高一致，而mask本身是一个Graphics，其形状为一个半圆和一个长方形的拼接，直接将判定框以及其右侧的轨道纳入其中。如此一来，elements这个序列条超出判定框左侧的内容将不会被展示，这样就达到了一个“进洞”的效果。

以上三部分完成后，便可以考虑第四部分的实现。第四部分本质上是一个光罩和其上的星星，光罩没什么特别的，就是一个Sprite，而星星则是一个序列帧动画，这个可以用PIXI.extras.AnimatedSprite实现。这二者的绘制和定位非常简单，唯一的麻烦在于如何让它们配合每一次的判定结果进行显示——即玩家命中后会有发光和星星散出的效果。这里有两种方案备选：其一，在命中时再去设置光罩和星星的visiable属性，并开始播放星星的动画，这种方式要频繁触发播放动作，需要进行变动的地方也较多；其二，将这两部分放入一个容器中，初始化完毕后不变动它们，而是变动容器的visiable属性，这意味着星星始终在闪，只不过由外层的容器控制它是否可见，这里也有一个潜在的问题——加入在切换容器显示状态时，动画只播了一半怎么办？所以这种控制实际上虽然简单，但不精确。我最终选择了第二种方案，虽然有风险，但考虑星星播放速度较快，并且切换也足够迅速，人眼几乎无法觉察，所以这个障眼法可行。

动起来

准备工作做完，便要考虑如何让序列条动起来了。上面讲到过，序列中元素的运动其实就是其外层容器的运动，所以我只需要在游戏过程中不断根据时间修改容器的x即可，而时间，实际上是由一个计时器ticker驱动的：

this.ticker = new PIXI.ticker.Ticker();
this.ticker.add(this.update);
this.ticker.start();

这段代码中，我创建了一个ticker，而后在其中注册了一个回调update，最后启动它，开始计时。之后在计时器的每一次更新时，它都回去调用update，我便在其中更新容器的x：

const preTime = this.currentTime;
const diffTime = this.ticker.elapsedMS;
this.currentTime += diffTime;
const diff = this.pixelsPerMs * diffTime;
elements.x -= diff;

其中this.ticker.elapsedMS为距离上一次回调经过的时间，而this.pixelsPerMs是一个定量，表示容器每毫秒需要移动的像素值，它是在元素序列被初始化完毕时计算的。如此便可以完成容器位置的更新，不过需要注意的是当浏览器被切出时，ticker的计时将会休眠，在这个过程中，虽然其计时没有停止，但将不会触发回调。当再次切回页面时，回调会再次被触发，但此时的this.ticker.elapsedMS将会是一个很大的值，这对于本MUG是无法接受的，所以我这里用了一个相对粗暴的手段——直接弹出提示让玩家重新开始。这也是无奈之举，如果有更好的方案请务必告诉我。

玩家输入

玩家输入指的便是开始说过的那六种操作——左按钮、右按钮、一起按，以及这三个的长按模式。将这六种操作映射到玩家这边的两个按钮、两对事件（分别的touchstart和touchend）上，并不是一件特别简单的事情，会涉及到一个稍显复杂的状态机。

首先我们定义原始输入，原始输入指的通过监听玩家对两个按钮的touchstart和touchend事件得到的输入。在这一步，程序将会对玩家的输入进行预处理，将其处理为左按开始、左按结束、右按开始、右按结束、同时按开始、同时按结束，来为下一步处理做准备。其具体的实现见状态机：

当接收到玩家对某个按钮的输入后，先缓存输入状态，将其保存为一个类的属性中，之后合理利用setTimeout函数，在delta时间(这个时间自行调整，此处为30ms，基本是两个主循环周期)后做一次延迟判断，如果在这段时间内玩家没有另一个按钮的输入、还保持着这个操作的状态，则直接触发其对应按钮的全局事件（这个全局事件是本游戏状态同步机制的基础，下面会细说）。但如果在delta时间内，用户又触发了另一个按钮的操作，则在另一个按钮的事件回调中先获取当前缓存的输入状态，此时可以检测到在短短时间内，玩家前后对两个按钮触发了touchstart或者touchend事件，这在宏观上可以等价为用户同时触发了两个按钮的相同事件，那么此时我就可以将两个事件合并成一个事件，触发全局的同时touchstart或者touchend事件。

这一段可能有点晕，但原理其实很简单。比如，玩家按了左按钮，并且delta内没有其他操作，则触发左按钮的touchstart的全局事件；如果delta内玩家又按了右按钮，则触发一起按的touchstart事件。

合并了玩家的输入后，便可以进入下一步的判定，从而真正实现输入和六种操作的映射，这将会在下一节说到。

背景和前景人物动画

在具体的判定逻辑分析之前，让我们来点轻松的——画面中随着玩家输入而动的22、33是如何实现的呢？其实并不复杂，合理运用序列帧动画AnimatedSprite和补间动画库Tween.js便可。

22和33分别都是一个AnimatedSprite，只需要按照其规范初始化和定位即可，但其中33需要特别注意，细心的玩家应该注意到了她所持烤箱的盖子其实是和她一体化的——这是为了在后续食物喷射出的时候，让食物能处于烤箱和盖子之间。所以33和背景上烤箱的定位其实有一定的耦合关系。

初始化只是第一步，要让22和33能响应玩家的输入做出动作，就要实现一个跟随玩家输入播放/停止动画的逻辑。我实现了act22和act33方法来完成这个逻辑，以22的为例：

public act22(mode: 'start' | 'end') {
  if (mode === 'start') {
    if (this.playing.two) {
      return;
    }
    this.loop.two = true;
    this.two.play();
    this.playing.two = true;
  } else {
    this.loop.two = false;
  }
}

这里的mode参数对应前面合成时间中的touchstart和touchend(以及touchendoutside)，22对应左按钮，33对应右按钮，一起按的操作则两个都对应。可以看到，这里本质上是利用AnimatedSprite的play方法来控制播放的，如果输入只有短按一种，那么每次在touchstart的时候直接调用play方法即可，但输入不止短按，还有长按，而长按时我的设计是让动画不断loop，当touchend的时候取消loop即可。一个显而易见的方法是利用AnimatedSprite自身的loop属性和其stop方法、onComplete回调方法进行控制，然而这种方式在当前版本的PIXI下会出现难以理解的行为（我认为这是一个bug），所以必须用替代方案。我这里是利用一个自己保存的this.loop属性结合AnimatedSprite的onLoop回调方法，来实现一个自定义的loop方案，并使用this.playing方法来防治动画播放过程中用户的意外输入：

this.two.loop = true;
this.two.onLoop = () => {
  if (!this.loop.two) {
    this.two.stop();
    this.playing.two = false;
  }
};

如此一来，便实现了22和33响应用户输入的功能。除此之外，还有一个在fever状态下、33拉烤箱门时同时喷射食物的效果，食物总共有五种，需求是随机选取其中的一个喷射而出，喷射位置也最好有所不同。我的做法是建立一个用于容纳食物的容器，当进入fever状态后，在触发33动画的同时调用一个actFood方法，在这个方法中，我先随机取出五种食物中的一种texture，之后生成其对应的Sprite，，为其指定初始位置和大小，将其添加到食物的容器中。之后用Tween.js生成一个Tween对象，为其添加变换位置（x和y，从预定义目标位置集合中随机选取）和大小（scale）的动画，然后在onComplete回调中将其从容器中移除即可：

const tw = new TWEEN.Tween({x: food.x, y: food.y, scale: food.scale.x})
  .to({x: end.x, y: end.y, scale: food.scale.x * 2}, 500)
  .onUpdate(({x, y, scale}) => {
    food.x = x;
    food.y = y;
    food.scale.x = scale;
    food.scale.y = scale;
  })
  .onComplete(() => {
    this.foods.removeChild(food);
  })
  .start();

操作判定

好，让我们回到用户输入到操作判定的逻辑。在前面，程序已经完成了对用户输入的合并，那么接下来这一步就是对已经合并的输入进一步处理了。在这一步，用户输入将会被转为miss、good或者perfect的判定，而这个判定对于短按和长按元素的逻辑又不相同，我们来一个一个分析：

判定流程

首先理清整个判定的流程，如下图：

元素序列条随着时间的推进不断更新位置，而在更新的同时，玩家或者程序自发（这个后面会说到）触发输入事件，去诱发判定逻辑，在判定结束后视情况更新玩家本次游戏状态，然后将当次判定过的元素从队列中移除......如此如此，进入一次又一次的判定循环。

1. 取出要判定元素

判定的第一步是要得知接下来要判定的是短按还是长按，由于已然判定过的元素会被从队列中移除，所以当下从队列中取出的第一个元素一定是接下来要判定的新元素，而这个新元素中有它自身的所有属性，其中一个就是beats属性——它决定着当前元素的长度，若为1，则按照短按判定，否则按照长按判定。

2. 对操作进行判定

若按照短按判定，那么很简单，首先，程序将比较当前输入事件的操作是否和待判定元素的type一致（比如元素type为0对应左按，那它对应的输入类型就是左按钮的touchstart事件，在本游戏中我设定为MAGIC.FIRE_START），之后在将当前游戏时间（即前文所示的this.currentTime）和元素的start和end属性进行比对，在距离中心±1/4的时间差内时，判定为perfect，在±1/2的时间差内时，判定为good。如果时间差在范围内但类型不对，则判定为miss。

长按判定比起短按要复杂许多。程序维护一个状态actionPre，这个状态用于存储上一个输入，而输入分别为三种操作的start和end。当接收到start输入时，先判定其是否和当前元素的type一致，如果一致则直接将状态存储下来，否则忽略。而当接收到end输入时，首先也判定是否和当前元素的type一致，倘若是则进入下一轮判断，否则忽略。下一轮判断对比的是当前输入的type和actionPre中存储的type是否一致，如果是，则表明它们是同一类型操作的开始和结束，这也正好描述了一个“长按”的过程，如果不是，则说明此次长按失败，判定为miss。

长按的good和perfect是start和end两次输入的结合，在start和end输入判定成功时，程序都会按照短按的逻辑对其进行一次状态的归类，并且当start时，会有一个属性statPre来保存其状态，当end判定为成功后，便会结合statPre和当前的状态综合计算出这次的状态，两次都是perfect则最终判定为perfect，否则为good。

3. 自发的输入

光依靠用户输入并不能构成一个完备的有限状态机，还需要考虑用户不输入这种异常的状况。为此，我加入了一个保留输入类型None，这种类型的输入事件将在满足一定条件时、在ticker触发的update回调中被触发。而这个条件，就是当当前时间大于当前元素的end时。此时可以认为为用户错过了一个节奏元素，那么接下来可以直接跳过所有判定逻辑、直接判定为miss即可。

状态同步

在上面的分析中，不止一次说到了自定义全局事件这个关键词，这其实是本游戏实现状态同步的机制。而状态同步，其实是全局跨组件状态同步，它的目的是解决不同组件间的通信，比如上面说到的“用户控制器中用户的输入事件”和“节奏元素条的判定”问题，在游戏逻辑中实际代码如下：

// main.ts
eventManger.on(EVENTS.HERO_ACTION, ({magic}) => {
  boss.judge(magic);
});

//Hero.ts
......
eventManger.emit(EVENTS.HERO_ACTION, {magic: ......});

对于前端同学，这段代码的含义言简意赅——这其实就是事件机制，在设计模式上被称为发布订阅模型、观察者模式，也可以说是RXJS的理念来源。当然，这种模式和redux等的思想也是一样的，只不过它做的事情更多，而这个比较灵活，当然灵活也会带来碎片化的问题，不过这个问题在本游戏这种规模的工程上，尚可接受。

在游戏过程中，我定义了很多个类似的事件，利用事件的监听和触发维护着全局的状态同步。而为了减轻自己的心智负担，我并没有把事件监听的逻辑去中心化地分散到各个组件，而是将其集中在一个文件中管理，像这样：

eventManger.on(EVENTS.HERO_ACTION, ({magic}) => {
  boss.judge(magic);
  chars.act(magic);
});

eventManger.on(EVENTS.BOSS_ACTION, ({stat, beats}) => {
  scoreboard.judge(stat, beats, boss.feverPower);
});

eventManger.on(EVENTS.CALCULATE, (summary: TSummary) => {
  if (summary.currentCombo >= 0 && !chars.withFood) {
    chars.withFood = true;
  }
});

eventManger.on(EVENTS.GAME_END, () => {
  boss.stop();
  result.show(scoreboard.summary);
});

......

如此一来，整体的流程便十分清晰，一目了然。

计分板

在上一节中，可以看到EVENTS.BOSS_ACTION这个事件的订阅中，有一个scoreboard对象触发了自身的judge方法。这个对象就是计分板，而这个方法就是对一次判定进行结算的逻辑，它接受当前判定状态stat（即perfect、good或miss）和当前判定元素的拍数beats，按照一开始说的规则结算生成summary: TSummary，TSummary的定义如下：

export type TSummary = {
  power: number,
  goals: number,
  maxCombo: number,
  currentCombo: number,
  miss: number,
  good: number,
  perfect: number,
  currentStat: TMagicStat
};

这里面定义了一些结算需要的属性，像是玩家每个命中判定每个状态的统计、最大连击数、总得分等。结算完成后，方法内部将会触发EVENTS.CALCULATE事件，将结果广播到全局。

以上是计分板在逻辑上的工作，而在视图上，它也控制了一些元素的显示，其分为左上角的能量球、右上角的积分和中间的判定状态：

1. 能量球：

如果你细心观察，会发现能量球其实是由背景的玻璃球，一层白色的水、一层蓝色的水和夹在其中的小电视构成的，其中水的高度和summary.power绑定。其中背景和小电视都很简单，直接用Sprite元素做好定位即可，水的实现则相对复杂，因为要实现一个波动的效果。一开始，我准备试试用置换映射来做这件事，不过发现得不偿失，所以最后还是用老路子，首先利用两种颜色的、有水面波动效果的长方形texture初始化两层水的Sprite，之后借用Tween分别对两层水实现了无限循环的、方向相反错位的旋转和位移，比如蓝色那一层的实现：

blue1.to({rotation: -wave, x: blue.x - 12}, time)
  .easing(TWEEN.Easing.Sinusoidal.InOut)
  .chain(blue2);
blue2.to({rotation: wave, x: blue.x + 12}, time)
  .easing(TWEEN.Easing.Sinusoidal.InOut)
  .chain(blue1)
  .start();

这样便有了水面波动的效果。而两层水本身超出背景玻璃球的部分，则和节奏条一样，用一个圆形的mask来解决。在power更新时，只需要在加上一个短暂的动画，去修改两层水的y即可。

2. 积分：

积分比较简单，直接用PIXI.Text展示，在更新时去修改其text属性即可，这里需要注意的是左侧0字符的补齐。

3. 判定状态：

判定状态即当判定结束时，在屏幕中间出现的state + combo的组合，这里唯一值得一提的是combo的绘制用到了BitmapText，一个坑是PIXI支持的BitmapText描述文件是一个xml文件二分fnt，这个xml文件可以用ShoesBox生成。

奖励模式

到这里完成的逻辑已然足以支撑一个正常的游戏流程。然而在正常流程外，还有一个奖励模式，这类似于太鼓的连打。在这种模式下，玩家交互方式不变，还是点击触摸，但输入将从按钮变为全屏幕，并且不再有正常的判定，任何一个点击都会被记为good算入积分，但combo并不会更新，简而言之——就是刷分用的。

奖励模式的启动和结束依托于TRhythm中的award.start和award.end，进入奖励模式时，先会有前置动画提示玩家，然后便进入玩家的操作流程。在这种模式下，正常流程的控制器将被隐藏，取而代之的是扭动的小电视、背景的闪光以及一个盖于其上的、透明的全屏遮罩，玩家此时的输入事件实际上由此遮罩监听，监听到输入后，控制器将会绕过正常的判定流程而直接触发EVENTS.BOSS_ACTION事件，直接完成判定。

音频

除了逻辑和画面，音频对于MUG也至关重要，前面所言的音画同步也主要是画面同步音频而非相反。本游戏中对音频的操作很简单——就是加载一个音乐然后播放和停止而已。我在这里使用的是pixi-sound这个插件，它本质上是利用WebAudio API来操作音频。为了使PIXI支持音频，我们需要在资源加载之前导入这个包：

// main.ts
import 'pixi.js';
import 'pixi-sound';

之后便可以像其他资源一样，用loader.add方法将音频加入队列，进行正常的预加载和使用。

注意，ios设备并不原生支持ogg格式的音频编码，为了保证兼容性（又是SB的兼容性），我在这里使用了mp3这种落后的编码模式。

虽然WebAudio API支持已然很广泛，但为了防止一些兼容问题，我们一开始要调用PIXI.sound.supported来检查当前环境是否支持音频播放，不支持的话就...只有无声游戏了，这也是我为什么使用ticker进行音画同步而不是用音频播放时的onUpdate回调的原因之一（另一个原因是这个回调在不同设备下调用周期差距过大，难以使用）。

当然，你可能会疑惑——如果不利用音频的播放时间来同步进度，那么如何保证真正的音画同步呢？这个问题很好，我也有所考虑，但经过测试和思考，我发现这个一个没有必要烦恼的问题——音频已然预加载完成，出现卡顿的概率微乎其微，如果因为这点小担心而去采用风险更大的音频同步手段（风险已在上面声明），非常得不偿失。再者，如果一定要关注音频同步问题，那其实可以在onUpdate回调中对this.currentTime属性进行修正，但这又会带来潜在的竞争问题，加大了系统复杂度，所以我认为，对于这个游戏而言，现在的处理逻辑已然妥当。

经过以上分析，音频在本游戏中做的事情很简单，就是在开始的时候play一下，结束的时候stop一下，结束。

结算

有开始，有经过，有结束，才构成一个完整的游戏闭环。虽然有些高贵的独立游戏去挑战这个定则，但本游戏毕竟还是一个商业作品，自然也免不了俗——所以，在游戏过后，就进入了结算页面：

结算页绘制

最终结算在游戏结束时，由一个事件触发：

eventManger.on(EVENTS.GAME_END, () => {
  boss.stop();
  result.show(scoreboard.summary);
});

这里我创建了一个Result组件来绘制结算页，在组件被实例化并加入ui容器时，结算页的所有元素会被绘制一遍，它们分为解算部分、分享部分、抽奖部分和STAFF部分。而show方法被调用时，实际上会调用一个私有方法update，这个方法将会更新结算部分的一些元素的值，比如最大连击数、分数等，并重新计算定位来使其保持一个相对合理的位置。在修改完毕后，组件内部将会触发一个复杂的动画去将绘制后的元素显示出来。

不难发现，和前面的组件不同，结算组件的长度超过了屏幕长度，所以需要能够拖动，而和DOM页面不同，这里并没有原生的scrollbar，只能自己去模拟，我写了一个ScrollableContainer去捕获touchmove事件来完成scroll操作，也不复杂。

分享图生成

在一次结算完成后，玩家如果点击分享到其他平台，会发现分享图就是自己当前得分对应的结算部分，这个本质上和BML2017那次一样，是先生成base64的图、上传到后端实现的，不过和那次不同，如何将PIXI内的一个DOC转换为base64的图其实是一个问题。在寻觅许久后，我找到了在当前版本V4.6.1完成这个操作的方法：

this.base64 = this.game.renderer.extract.canvas(this.goalsLayers.container).toDataURL('image/png');

如此一来，结算页的逻辑基本就搞定了。

后话

不得不说现在国内直接跳过桌面端直接到移动端，使得很多有趣的设计效果无法实现，移动端由于性能和标准等各种问题，表现力也很有限，而WebAR/VR尚未Ready也进一步加大了这种尴尬。当然，如果大家谁有有趣的、纯公益或者纯艺术性与新媒体结合的路子，可以找我，视情况我可以提供无偿的技术支持，不仅仅是web前端，硬件我也可以视情况奉陪。

在pixi.js实现设备自适应和强制竖屏

dtysky — Saturday, 02 Dec 2017 10:00:00 -00:00

问题

最近在用pixi.js写一个2D音游，出现了关于适配的三个问题。

其一，由于游戏是竖屏模式，而某APP在IPAD下是强制横屏的，所以需要一个方式去适配。

其二，游戏本身需要保持一定的纵横比，而且在不同分辨率的屏幕下都要保证内容显示正常，即需要一个适当的缩放。

其三，并非游戏内的所有元素都是有绝对位置定位的，有些元素的位置需要根据当前实际的游戏屏幕中的可视范围来确定，比如用户控制按钮必须在屏幕可视区域内置低，计分板必须置顶等，这需要在渲染时动态计算。

分析和实现

对于这三个问题，让我们先分析一下，其本质是什么，以及有哪些方式可以运用。

强制竖屏

竖屏适配的方式有很多种，一种普遍的方法是在PAD的横屏下向两侧添加背景，将游戏画布居中，如下图。这种方式虽然可行，但却不是那么完美。

而另一种方法则是利用对容器的旋转等操作，让游戏画布始终保持一个真正意义上的竖屏，如图所示。这种方法比较完美，能最大化地利用设备的可视区域。

那么这种模式如何实现呢？关注过我之前的文章的朋友，想必知道之前我用egret.js写过一个Galgame，它实现强制竖屏的方式是当设备横屏时，直接利用transform的rotate属性对canvas容器进行变换，而后通过调整left和top属性来重置容器位置。进行调整后，我们获得了一个旋转过的、仍然铺满屏幕的canvas容器，由于只是修改了容器的属性，所以容器内部绘制的场景仍然是相对不变的：

#container {
    transform: rotate(90deg);
    top: ${device-height};
    left: 0;
}

这样做画面确实完成了适配，一切看起来很完美，但进一步操作后你会发现这个在pixi.js中是行不通的——touch事件的位置判定出现了问题，也就是说旋转后，你给DOC(DisplayaObjectContainer)的绑定的事件无法在触碰它时被正确触发。经过查看egret的源代码并进行分析后，我确认是egret在旋转容器后重置了全局的touch事件判定，应该是在transform变换后引擎对触碰位置与画面内DOC的映射出现了问题，所以需要重置，但在pixi中，我并没有找到这个方法（也可能看漏了，有找到的请务必告诉我），所以只能用另一个方法来绕过——既然根级容器无法完成需求，我就利用引擎自身提供的Container方法自己造一个根级容器，由于对这个容器的所有变换都是引擎内部管理的，所以并不会出现touch事件的映射错误，也就完美绕过了之前的问题。具体实现看以下代码：

const root = new PIXI.Container();
game.stage.addChild(root);

const screenRect = container.getBoundingClientRect();
renderer.resize(screenRect.width, screenRect.height);

if (window.orientation === 90 || window.orientation === -90) {
  root.rotation = -Math.PI / 2;
  root.y = newWidth;
} else {
  root.rotation = -Math.PI / 2;
  root.y = screenRect.height;
}

这个本质上，是始终保持canvas容器全屏，然后重置renderer的尺寸让根级的stage容器全屏。之后构建一个root容器作为实际的根级容器，并将其添加到stage中作为唯一的children。之后判断window.orientation属性，这个属性用于判断当前设备的方向，当其为±90时即为横屏，此时只需要将root容器旋转90度，而后将其transform.y进行调整。

缩放

为了强制竖屏，我们已然有了root容器，如此一来，缩放也就变得十分简单了——只需要设置root容器的缩放即可:

当然，如果仅仅是需要缩放，直接对canvas进行缩放，并始终保持renderer的size为游戏画布本身的绝对大小也可以。

const {width, height} = options;
const screenRect = this.container.getBoundingClientRect();
renderer.resize(screenRect.width, screenRect.height);

let offsetWidth = 0;
let offsetHeight = 0;
if (window.orientation === 90 || window.orientation === -90) {
  offsetWidth = screenRect.height;
  offsetHeight = screenRect.width;
} else {
  offsetWidth = screenRect.width;
  offsetHeight = screenRect.height;
}

const newWidth = offsetWidth;
const scale = newWidth / width;
const newHeight = height * scale;

root.scale.x = newWidth / width;
root.scale.y = newHeight / height;

这里直接对root容器进行了缩放，这样一来，之后所有子级元素的定位布局仍然是按照游戏画布的绝对大小来的。也就是说，这一层的修改相对于后面的编程是无感知的，做到了自适应逻辑的无痛植入。我在这里实现的是fixedWidth这种自适应模式，它表现为宽度适应屏幕，高度将会跟随宽度进行缩放。这种模式是最为常见的一种模式，但它往往也会带来一个问题——游戏缩放后的实际画布仍然有可能会超出设备可视区域，这就引出了一个概念——可视范围。

可视范围

解决了游戏画布的自适应，还有可视元素自适应的问题需要解决。如一开始分析，在游戏中有些元素是不能越出可视区域的，所以就需要在编写布局代码时拿到游戏可视区域的定义，以此为基准来动态确定元素的位置。为此，我定义了一个realScreen的公有属性，里面存储着游戏实际的可视范围：

何为越过可视区域？比如在一个16:9的设备上，我使用了以上的强制竖屏和fixedWidth模式。此时倘若我设计了一个作为玩家控制器的元素，其定位为游戏画布置底，那么当设备的可视区域比例小于16:9时，这个控制器的一部分便会越出可视区域，这显然并不是我们预期的，我们需要的，应该是无论设备如何改变，控制器都始终在设备可视区域的底部。

type TScreen = {
  // 可视区域的上边界，对标游戏画布尺寸
  top: number;
  // 可视区域的下边界，对标游戏画布尺寸
  bottom: number;
  // 可视区域的左边界，对标游戏画布尺寸
  left: number;
  // 可视区域的右边界，对标游戏画布尺寸
  right: number;
  // 可视区域的宽度，对标游戏画布尺寸
  width: number;
  // 可视区域的高度，对标游戏画布尺寸
  height: number;
  // 可视区域的宽度，对标设备尺寸
  realWidth: number,
  // 可视区域的高度，对标设备尺寸
  realHeight: number,
  // 设备纵横比
  aspectRatio: number;
};

如此一来，后续元素便可以动态确定它们的位置了。

完整代码

我将以上三种特性集成到了一个resize函数中，并将其放入了一个Game类中，以下便是封装好的Game类，使用时只需要从类的实例中获取realScreen属性便可。

export default class Game extends PIXI.Application {
  private container: HTMLElement;
  private options: PIXI.ApplicationOptions;
  public root: PIXI.Container;
  public realScreen: TScreen;

  constructor(element: string, options?: PIXI.ApplicationOptions) {
    super(options);
    this.options = options;
    this.container = document.getElementById(element);
    this.container.appendChild(this.view);
    ......
    this.root = new PIXI.Container();
    this.addChild(this.root);
  }

  public resize = () => {
    const {width, height} = this.options;
    const screenRect = this.container.getBoundingClientRect();
    this.renderer.resize(screenRect.width, screenRect.height);

    let offsetWidth = 0;
    let offsetHeight = 0;
    if (window.orientation === 90 || window.orientation === -90) {
      offsetWidth = screenRect.height;
      offsetHeight = screenRect.width;
    } else {
      offsetWidth = screenRect.width;
      offsetHeight = screenRect.height;
    }

    const aspectRatio = offsetHeight / offsetWidth;

    // fixWidth, orientation="portrait"
    const newWidth = offsetWidth;
    const scale = newWidth / width;
    const newHeight = height * scale;

    const {root} = this.layers;
    root.scale.x = newWidth / width;
    root.scale.y = newHeight / height;

    if (window.orientation === 90 || window.orientation === -90) {
      root.rotation = -Math.PI / 2;
      root.y = newWidth;
    } else {
      root.rotation = 0;
      root.y = 0;
    }

    this.realScreen = {
      realWidth: offsetWidth,
      realHeight: offsetHeight,
      width,
      height,
      top: 0,
      bottom: offsetHeight / scale,
      left: 0,
      right: width,
      aspectRatio
    };
    this.realScreen.width = this.realScreen.right - this.realScreen.left;
    this.realScreen.height = this.realScreen.bottom - this.realScreen.top;
  }
}

Bilibili《七夕之约 - Double;7》技术剖析

dtysky — Sunday, 27 Aug 2017 00:00:00 -00:00

今年B站七夕活动的GalgameDouble;7由我负责原案、程序和演出三部分，深度使用了白鹭游戏引擎的2D部分并为之写了一个galgame插件egret-galgame，下面就这次活动的各个方面我将输出一篇心得，各位稍安勿躁，待我娓娓道来。

前言

本人的开发之路算是比较崎岖，到现在为止从底层硬件开发到WEB前端都干过一些，而现在基本确定了WEB前端的道路，虽说如此，这条道路却和我梦想的道路并非一致，本质上来讲，我还是想做游戏、尤其是做GAL。但这并不代表我舍弃了这个追求，而是一直在需找契机，看是否有机会争取到资源进行尝试。

众所周知，B站去年七夕就有这样一个尝试，然而那时候我入职尚早，尚在后台开发组中，在公司内也没有资源和话语权，所以并未能参与。而这次的七夕，我终于有机会并果断抓住了机会，和一帮同样很有想法和干劲的同事进行了这次游戏的开发，虽然受制于H5活动本身的性质，此次也有所遗憾，但终归还是做出来了不错的作品，对这些同事表示由衷的感谢。

对于本人而言，负责GAL的原案实在是一件非常具有诱惑力的事情，自己过去也做过很多尝试，加之也有不少GAL的游戏经验，所以对游戏质量自然有一定要求。但和正常游戏不同，这次游戏本质上是一个H5活动页，所以有存在着很多问题。

其中一个问题，就是如何在有限的时长和资源内做出一个比较合格的GAL，而这一点是比较困难的。对于一个H5的活动页面，本次活动预计的十分钟的平均通关时间实际上已是超常规，上面也有所微词，但考虑这其实又是一个游戏，所以最终还是争取到了这个时间。虽然十分钟对于一个正统GAL还是太短，但尚可比较完整得走完一套流程。

第二个问题是游戏风格倾向。作为资深GAL玩家，虽然对废萌也不反感，但自身还是倾向于深刻向的正剧或者电波作，所以一开始基调定的是偏向悲剧中透着淡淡的关怀的、对死宅人文关怀的类型。但和编剧讨论后，最终还是由于这个活动的官方欢乐性质妥协了，这一点确实没有办法，但编剧菊苣很好得使用了之前B站相关的一些梗，无厘头也算是一个比较安全的倾向吧。

第三个则是设备问题。此次平台是移动端，而且是WEB上，加之在APP内主推，所以横屏模式下可用空间有限，最终选择了竖屏模式。竖屏模式和传统GAL的演出是相悖的，因为其不符合一个舞台相对于人眼的空间成像习惯，同时也限制了一个舞台（屏幕）中出现的任务、物体数量，这相对于传统GAL是一个瓶颈，而白鹭也只提供了锁定竖屏而非横屏自适应模式。所以必须有一个方案来在竖屏模式下模拟横屏演出，我做到了这一点，具体细节会在下文中说明。

原案

本游戏主标题是《Double;7》，这一个标题承载着多重的含义，其直接影响到了游戏的主题和形式，也算是对某两个经典系列的致敬。

首先，“Double7”即“双7”也即“77”，即七夕，这意味着这个游戏是一个七夕的游戏。

其次，Word + Number形式的标题是业界眼泪KID的的无限轮回系列每一作的命名方式，其中最著名的而是《Ever17》，然后是首作《Never7》，后面还有《Remeber11》、《12River》等。这一系列的主要特征就是带有轮回概念的科学幻想。这也意味着本作有轮回的要素。

最后，XX;YY形式的标题是KID的精神后继者5PB开发的科学妄想系列每一作的命名方式，比如最著名的《Steins;Gate》，本人最爱的《CHAOS;HEAD》、《Chaos;Child》，以及某RN和社长亲自下笔的《Occultic;Nine》等。这一系列核心是对扭曲真死宅的人文关怀与自我救赎。这一点，是本作最初的核心立意。

本作的核心立意除了源于科学妄想系列外，也源于《四叠半神话大系》这一作品。本质上，我还是想传达一个“走出去尝试看看吧，无论如何，只要去做了，即便是后悔，也比什么都不做强”的观点。无论是轮回前期的尝试还是最后放弃时的反差、以及最后的最后的配对、和另一个玩家的相遇和协作，都是为了这一个主题而服务的。

当然，由于本作特殊的官方活动性质，剧情无法加入偏悲剧和些许恶意的情节，无法参入毒电波，更无法表现阴暗的放弃挣扎和自我的憎恶与反思，只能走无厘头的道路，所以自然就无法有最后反思爆发的高潮。这一点确实有些遗憾，但考虑基本走向和玩法还是保留了，也难为编剧了。

程序架构

技术方面可说的点比较多。此次活动虽然是一个WEB页面，但本质上其实是游戏开发。作为一个游戏，自己从头写一套渲染虽未尝不可，但毕竟是开发周期有限的商业活动，所以我选用了现成H5引擎Egret，这个引擎用下来虽然有一些小问题，但整体还是不错的。不过如果现在让我重选，我应该会选择对工作流侵入性不高的PIXI等框架吧——毕竟对于一个H5应用，Egret做的事情还是太多了，这导致使用第三方库、打包等都难以和现在的标准工作流结合，最后打包合并、版本控制还是我自己写了个小脚本做的，这点确实不怎么合理。

由于本人自身有着比较丰富的GAL开发经验，所以借助于一些优秀的设计（比如Renpy）后，我将自己在此次游戏中使用的核心代码封装成了一个Egret的扩展，其按照规范，被封装在GAL的namespace内，开箱即用，读者可以在此处egret-galgame来获取它。但做一个非常完美的扩展毕竟耗时巨大，本人工作较忙，所以此物有很多地方并不完整，如果要用在自己项目中，请读完下面的经验介绍并按照自己需求对其做出更改即可。

顶层框架

由于游戏的形式是GAL，所以和传统游戏相比，其交互的侧重点和表现形式大为不同。GAL大多都是2D的，其基本表现方式是一个作为场景的背景、一个或多个背景前的人物、一个NVL或是ADV模式的对话框，通过人物的形态、表情、动画和对话框中的文本、还有场景间的过度效果来进行话剧式的演出。所以比起传统的游戏，我更愿意将其视作一个“虚拟的话剧”。针对这样的情境，一个简洁有效的图层分层方案必须被提供，这也就是本扩展中Scene的概念。

这种演出方式也决定了它和一般游戏交互的不同。GAL的主要流程是由一个单一的输入决定的，在本作中，这个输入是“对屏幕的点击”。用户不断触摸屏幕，游戏程序响应这个触摸进行对应的演出。换言之，GAL的操作方式是相对单一的，而建立在这种单一之上的，则是由大量文本堆积出的巨量演出，针对这种简单的输入和复杂的效果，一个大幅简化流程的脚本DSL毫无疑问是必要的。

下面就针对以上两个问题做详细的说明。

图层

图层设计是建立在Egret本身的图层概念上的，其图层排序是按照子级加入到父级容器的顺序来确定的，并且其图层的维护是一个数组，所以并不能简单得设置一个很大的值和很小的值以及中间值来简单排序，只能在得知原图层index的情况下进行交换或是简单的置顶和置底，所以一个最佳的策略其实是在运行过程中尽量不要去更改图层顺序，这也就要求这个扩展的设计要一开始将层次区分明确。我对图层的区分如下图所示：

Scene作为整个扩展的核心，负责维护游戏场景中的所有子元素，这其中包括主要元素main、对话框dialog、纯文本text和选择支branch，main下面又有背景bg和人物chars。其中main层级最低，而其中的bg又是最低的，接下来是chars、text、dialog、branch，这个顺序是按照功能性排列的。这些子元素都以对象的形式存在，而这些对象的类中必有一个addToScene方法，此方法使得这些类可以保存Scene对象的引用并将其自身添加到场景中。

这其中，其他的顺序都比较容易理解，而有一个特殊的点是背景图层bg和人物图层chars并未打平，而是合并放在main下面，这是因为游戏中既有单独移动背景和人物，也有让背景和人物同步移动的需求。

在实际运行中，Scene先初始化，清空当前所有显示的内容，然后通过背景图片以及一个过渡效果创建一个新的场景，之后根据需求对bg进行位置或缩放的动画控制，当需要人物出现时，便将人物对应的对象添加到chars图层中，并在后续控制其位置、缩放、姿势和表情等。如果有对话、分支等需求，则只要再在对应的图层中添加对象即可。

脚本化

场景管理只解决了基本的绘制问题，但并未解决开发效率的问题。在理想的开发策略中，当我想进行演出，比如想切换背景、显示一个人物、或是让某人说一段话的时候，我并不需要去写复杂的类似：

scene.addChild(charABodyA);
scene.addChild(charAFaceA);
charABodyA.x = 0;
charBBodyA.y = 0;
charAFaceA.x = 200;
......
name.text = 'A';
name.x = 300;
name.y = 0;
words.text = '蛤蛤蛤蛤';
words.x = 200;
......

这样的代码。而是想去写出类似这样的简单的脚本：

const charA = new Character('A')
charA.addToScene(scene);
charA.posture('A').face('A').at(0, 0).show();
charA.say('蛤蛤蛤蛤');

这种脚本无疑更加简洁明晰，也更符合人类的思维模式。事实上，很多老牌GAL游戏引擎都是这么做的，比如前面提到的Renpy，其提供的脚本时这样的：

scene bg SE02C at truecenter with move
show Song AB01A at GridXfL(3,0.5)
SongA '偶尔也要释放一下嘛。'

相比我上面的写法，Renpy语法更加简洁，属于标准的DSL（作者自己写了一个解释器来处理这个DSL）。但无论是从开发周期、还是从稳定性、扩展性而言，这样的DSL都显然不适用于我现在的场景，硬上的话也不过是杀鸡焉用牛刀，我需要的实际上是类似于JQuery那样的语言内DSL，即通过链式调用来达到近似DSL的描述能力，但却有可以灵活地插入原生js代码中进行混用，并且开发和维护也较为便捷。

此扩展的DSL核心是一句一句的描述性语句，像是上面第二段代码的第三和第四行那样，我通过面向对象的思想将其设计为了由链式调用构成的语句。比如第三句，就表示人物A将展示A姿势A表情、并显示在(0, 0)的位置，第四局则是这个人物A将会说出蛤蛤蛤蛤这句话，至于具体渲染出的逻辑，则由这个扩展引擎的后端部分来实现。

有了基本的DSL，就需要一个集合来管理它们，完成它们的解析，而这一切则需要一个集合的描述结构和对应的解释器来完成。我选择的结构是最简单的数组，数组中的每一个元素都是一个匿名函数，而解释器的功能就是不断地读取这些匿名函数执行，并通过执行结果来决定下一步的行为。匿名函数集合在实际的编写中如下所示：

const map1 = [
    () => scene.with(600, 'fade').then(() => next()).toMode('NVL').at(370).create('home'),
    () => boy.think('什么...我是主角？'),
    () => boy.think('开什么玩笑，当主人公岂不是会很累...我可没那么多精力。'),
    () => boy.think('蛤？还是让我当，我...'),
    () => branch.open([
      {
        content: '搞什么玩意，我就是不想当怎么着了？',
        callback: () => {
          scene.with().toMode('ADV');
          interpreter.next();
        }
      },
      {
        content: '没办法，看来还是逃不过命运啊~',
        callback: () => {
          scene.with().toMode('ADV');
          interpreter.next();
        }
      }
    ]),
    () => boy.say('...不对，我是和谁在说话？');
];

在以上这段代码中，我将数组map1称为一段剧本，其中的每一元素都是一个匿名函数。解释器读取剧本中的每一句进行执行，而这个执行方法的触发源就是用户的触摸事件，用户触摸一下，解释器便将内部维护的指针加一并读取执行，执行的效用由每个对象的内部实现，比如场景切换、人物显示、说话等。而每一句函数执行的返回值，也决定着用户下一次行为的功能，这也是解释器运行的核心。

解释器

由于是语言内的DSL，所以解释器构造很简单，不同于传统的语法分析需要构造语法树，此扩展的解释器的核心功能只需要维护一个内部列表和一个数组的指针便可实现。为了进行内部剧本的载入，我实现了load: (script: TScript[]) => void方法，其加载一个剧本并准备对齐进行解析；解释器中的指针则由next: () => void和goto: (line: number) => void方法控制，next方法将指针加一，之后执行指针指向的那句脚本，而goto方法则是next方法的一个扩展，可以跳转到并执行指定行。

除了以上基本功能之外，解释器还必须提供现场保护和恢复的功能。比如在一段剧本中，有一个语句是使用load方法加载别的剧本并执行，而新加载的剧本执行完后我们显然希望回到原来的剧本并继续执行下一句，这个状况在分支存在的情况下非常常见。这就要求解释器内部维护的并非一个单纯的剧本，而是一个剧本构成的栈，这和传统底层开发的汇编中保护现场的姿势一致。每当加载一个新的剧本，我就会把当前剧本以及对应指针分别入栈，然后再执行新的剧本，当新剧本执行完毕后我便从栈中出栈一个剧本和对应的指针，并继续执行。

至此，一个满足需求的基本的解释器便已完成，但考虑GAL的特殊演出形式，此扩展必须提供一个类似于快进的功能来使得玩家可以加速语句显示或是动画的表现，使其快速到达结束的状态。比如我在角色说话的过程中再触摸一下屏幕，当前的这句话就会被直接跳过逐字动画而直接显示；除此之外，有时候我们还希望一些效果无法被略过，也即能够有一些方法卡住脚本的执行，在不频繁使用事件的绑定与解绑的情况下，一个统一的解决方案需要被提出，而我的方案，就是依赖于剧本中每一句匿名函数的返回值——

export type TSPScriptResult = {check: () => boolean, exec: () => void};
export type TScript = () => any | TSPScriptResult;

此处类型定义并非BUG，这只是表明匿名函数的返回值可以是任意类型，但其中有一个类型是TSPScriptResult。当返回值的类型是其他时，解释器不做操作，正常响应接下来的所有行为，而如果是TSPScriptResult，则会进入特殊的处理流程：

如果check的执行结果是true，则正常响应接下来的操作。
如果check的执行结果是false，则执行exec。

这个简单的规则可以解决上面提出的几乎所有的问题，当有可以被跳过的动画相关的语句被执行时，可以返回一个TSPScriptResult的结果，其中由check方法告知解释器是否要卡住解释流程，而exec方法则在允许快速跳过的情形下、给出一个快速跳过的方法。比如在一开始的性别选择页面，我就是通过check卡住接下来的操作，直到用户选择完毕才改变其返回结果，重启解释流程。

资源管理

资源管理也是游戏中非常重要的一部分，我在这里基本就用了Egret自身的资源管理模式。核心是用它提供的TextureMeger来进行图像资源的合并，而后利用其RES单例进行资源加载和管理。比如如下这张图和其对应的json文件：

{"file":"dialog.png","frames":{
"altair-s":{"x":542,"y":289,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"altair-t":{"x":542,"y":867,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"boy-s":{"x":1084,"y":0,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"boy-t":{"x":542,"y":867,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"fff-s":{"x":1084,"y":289,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"fff-t":{"x":542,"y":867,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"girl-s":{"x":1084,"y":578,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"girl-t":{"x":542,"y":867,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"npc-s":{"x":542,"y":0,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"npc-t":{"x":542,"y":867,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"nvl":{"x":0,"y":0,"w":540,"h":960,"offX":0,"offY":0,"sourceW":540,"sourceH":960},
"vega-s":{"x":542,"y":578,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287},
"vega-t":{"x":542,"y":867,"w":540,"h":287,"offX":0,"offY":0,"sourceW":540,"sourceH":287}}}

这样能够大幅减少网络请求，提高响应速度。对于大部分资源这样处理都是没有问题的，但对于人物的立绘资源，由于我的特别设计，需要另一套方式而非工具合并，这一点会在下面说明。

资源管理没问题以后，便会出现资源预加载的问题。对于一个游戏，资源量肯定不会少，然而对于一个WEB应用，响应速度又很重要。为了去一个平衡，本游戏的处理方式是——将资源加载分为两个部分。用户在JS加载完毕后首先只预加载标题和基础UI相关的素材，加载完毕后先展示首屏，用户操作后再加载剩下的资源，这样至少能够保证用户能在短时间内看到东西，不至于快速流失。除此之外，我还是用了optimizilla来压缩图片，普遍能压缩60%+，来达到效果和大小的平衡。

细节实现

顶层的大框架设计说完了，下面就来说一部分细节的实现吧。

场景

场景类是Scene，其负责管理场景图层（已在上文说过）和控制背景以及整体的位置、动画等操作，其最基本的方法就是create方法，配合with、at、from、show等方法能达到更丰富的控制。以下是一句基本的脚本：

scene.with(600, 'normal').at(0, 0).from('right').then(() => next()).create('home');

这句话代表我要新建一个场景，这个场景的背景是home，以normal模式、600ms过渡，并且背景的位置是(0, 0)，过渡从右侧开始，并且在场景创建完成后执行作为then参数的回调函数。这几个操作基本能实现场景管理的所有功能，下面来一个一个分析：

with和from方法：with的第一个参数是时间，第二个是模式，决定着下一次创建场景时使用的过渡模式，而from则决定着过渡方向。过渡方法此处暂时有normal、fade和none三种，fade顾名思义是先渐隐第一个场景，再渐显第二个场景；none是直接变换场景，没有任何过渡效果；normal则是一种模仿传统GAL的过渡的效果（就是游戏中选择完大场景后的切换效果），在传统引擎中，这个效果是由一张渐变图加上ImageDissolve函数定义，并在过渡过程中实时生成中间图像的，但考虑WEB的性能问题，我此处选择的方式是利用一个具有羽化毛边黑色图作为mask，先将其移入，然后在场景被盖住的时候变换场景，之后再移出，便可模拟那种传统的效果。
at方法用于定位场景，决定下一次将场景移动到某个坐标(x, y)处。
then接受一个回调函数，这个回调函数将在场景变换结束后调用，这是为了提供一个调度的方法。
create方法是一个终结方法，其不是一个链式调用的节点，功能是利用参数中的标示，去寻找资源中的bg_${mark}图像，作为新场景的背景进行变换，在变化之时，对象还会调用一个clear方法，来清空子图层的所有对象。

如上所言，像是at这种方法其实只是决定下一次场景在create或是另一个方法show后的状态，换言之，这些方法是惰性的，它们只会修改Scene对象的成员变量，这些成员变量真正生效要等到下一次场景的实际变换。除了上面的几个方法，还有两个方法对于场景（特别是此游戏）十分重要：

scene.toMode('ADV').at(100, 100).animate(600, t => t).show();

show方法，此方法会在不进行过渡的情况下对场景进行变换，也就是说，不改变背景，但可以修改场景的位置，这在某些场景下非常有用。
animate方法，此方法参数是一个时间函数和一个时间，它可以为下一次变换指定一个动画，如果其被指定，则下一次show的时候，背景的位置在移动两点之间将会有一段平滑的动画。
scale方法，和at类似，但提供的是缩放功能。
toMode方法则是切换对话模式，这一点在下面会详细说明。

除了以上的功能，我在实现背景初始化时，并非直接使用素材和场景左上角对齐的模式，而是令其中心对齐，这对于人类而言比较合理，但代价就是要去实时算anchor和背景的位置。

人物

人物由Character类生成，其比较复杂。一方面，它决定着人物自身的固有属性，比如对话时的字体、对话框背景等，另一方面它又组织着人物的资源，而人物的资源又和别的资源不太一样。这里我就详细说说这个类的具体实现。

说详细实现，不得不先提一下人物的素材，为了使一个人物能有生动的演出，最基本的方法就是对其立绘的姿态和表情进行变更，结合上面提到的惰性方法结合show方法的模式，我显示一个人物立绘的脚本如下：

vega.posture('普通').face('微笑').at(0, 0).from('right', 400).show();

这里的posture方法定义了立绘姿态，face定义表情，这两者将会在实际显示时先和上一次的状态做一次差分，只有真正有更新的时候才会进行实际的图层重绘。在更新时，对象先拼接出两个资源标识，然后通过这个标识去引擎获取对应的素材，素材分为两部分——一部分是躯体，其标识是${resName}-${posture}.body，一部分是表情，标识是${resName}-${posture}.${face}。

这里就要说起人物资源的详细定义了，根据Egret的资源规范，我将人物的每个姿势以及其表情集合拼合到了一张图内，然后将其资源命名为${resName}-${posture}的模式，之后在这个资源对应的json内写好身体和各个表情的偏移：

{
    "frames": {
        "body": {
            "offY": 0,
            "sourceW": 724,
            "w": 724,
            "x": 0,
            "y": 0,
            "h": 1280,
            "sourceH": 1280,
            "offX": 0
        },
        "生气": {
            "offY": 144,
            "sourceW": 136,
            "w": 136,
            "x": 764,
            "y": 324,
            "h": 95,
            "sourceH": 95,
            "offX": 289
        },
        ......
    },
    "file": "vega.png"
}}

通过这些定义，我便可以轻易得从资源图中获取到身体和表情的图像，并将它们绘制到对应的body和face子图层去。

这些操作实现了基本的姿势和表情切换，但如果直接切换又太过生硬，连若干年前GAL的演出标准都无法达到，为了达到GAL的底线，姿势或者表情变化时的fade效果必须被实现。我实现了一个类Transition，专门用来做这个效果，其可以传入之前和之后的两个图像，直接实现二者的交错fade效果。

当然，除了主要角色，我们还可能有一些次要角色，这些角色并不需要姿势和表情的变化，而仅仅需要一张图作为基本立绘即可，对于这种角色，我在构造函数中设定了参数multiPos和multiFace来做细节控制，若设置为false，则不会去进行姿势和表情的区分，而仅仅是绘制resKey对应的基本图像：

export const boy = new GAL.Character('npc.boy', '少年', 'boy', 0x0078a4, 0x0078a4, cps, false, false);

在姿势和表情之后，at方法用于定义下一次显示的位置，不过和Scene不同，它的两个参数是格点而非像素，这是由于立绘定位比较特殊，设计为格点模式比较方便，而格点的约束则写在types.ts中。from方法定义的是立绘从何处出现，这个和Scene也不同，它实际上决定的是当立绘从无到有是、从某一侧的某个偏移边移动边逐渐显示的效果（这一点在游戏中处处都有体现），我认为这也是一个合格的GAL应该拥有的底线演出。

除了以上方法，Character类同样提供了很多其它方法以供显示的细节控制：

vega.size('large').opacity(.5).face('生气').at(3).with(600, t => t).animate().show();
vega.hide();

size方法的参数可以是large、middle、small等，它本质上用于控制立绘的远近感，具体的效果也是在types.ts中定义的，opaticy用于修改下一次的透明度，with则决定了姿势和表情变换的时间和时间函数，animate决定在角色size和position变换时是否要有动画，hide则是隐藏当前立绘，和show相同，它也会有淡出的效果。

显示问题解决后便是角色的另一个重要行为——对话，角色的对话分为两种，一种是说，一种是想，并且对话形式也分为ADV模式（对话框置底，一句话占据一个对话框，主要用于普通对话）和NVL模式（对话框居中且大，一屏有多段对话，主要用于独白和描述），其脚本如下：

scene.toMode('NVL');
vega.think('我，我为什么会在这里？');
scene.ADV('NVL');
boy.say('因为你是笨蛋啊。')
vega.say('我才不是！');
vega.think('这家伙是谁啊，这么没礼貌......');

脚本写起来非常简洁优雅，而这简洁的背后是大量的工作，这工作依赖于另两个类——ADVDialog和NVLDialog。

对话框

对话框分为ADVDialog和NVLDialog，这两个都继承自基类Dialog，其核心方法有两个：say: (id: string, words: string) => TSPScriptResult和think: (id: string, words: string) => TSPScriptResult，它们分别对应Character类的say和think方法。

在实际的调用链中，首先执行Character对象的say方法，然后再内部通过Scene对象中的say方法将该对象的id和当前说的话words传递给Dialog类的say方法：

vega.say('蛤蛤');
↓
scene.say('vega', '蛤蛤');
↓
dialog.say('vega', '蛤蛤');

最后对话框的绘制和文字的显示实际上由dialog完成，而对话框的样式与当前文本的样式，一方面由types.ts中定义的静态变量决定，比如文本偏移、字体大小，另一方面则在Character对象被构造时、由其构造函数的参数决定，比如cps（每秒显示多少个字符）、文字颜色等，这些变量被存在一个全局单例中，使用时直接从中拉取。

在绘制时，两种对话框的形式截然不同。对于ADVDialog，实际上是先绘制底层的对话框图片，然后在直接绘制姓名，然后在文本区启动文本绘制动画，动画则是利用requestAnimationFrame加上和绘制开始的时间差来实现的，加上一个快速结束动画的方法，便可以实现功能。

对于NVLDialog，显示情况就复杂得多。由于可以容纳多段对话，需要考虑的问题就有很多：首先是名字和文本的排版、包含多行文本如何定位的问题，涉及到这个问题，就必须引入各种变量来保存位置信息；其次是清屏的问题，也就是判断文本将会超出时清空当前对话框，并在下一个对话框中显示新内容，这本质上是一个预判的问题，就是必须在绘制前先判断是否会超出，然后再按需绘制。这两个问题只能通过无尽的小学数学和文本测量来解决，好在并不是特别复杂，最终都获取了比较完美的解决。

选择支

选择支是GAL最基本也是最核心的操作，本质上就是一个一个的按钮，每个按钮都有自己的背景图片和文本还有回调，而文本和容器有可能有不同的样式，但这些样式在大多数状况下又是中规中矩、基本相同的。所以我提供了两种方式——基本模式和用户自定义模式。

在基本模式中，用户可以只给一个文本或背景图、加上一个回调便可定义一个选项，像是这样：

branch.open([
  {
    content: '成神，我不做人啦！',
    callback: () => loadAndNext(god)
  },
  {
    content: '不，我想回归那平凡的生活',
    callback: () => loadAndNext(human)
  }
]);

在这种状况下，选择支所有的属性都会又types.ts中的一个静态变量控制，不过在此处还可以传入一个autoClose参数，用于确定选择完成后是否应当直接关闭选择支，其默认为true，当有特殊需求时可以将其设为false；另外还有一个参数eachTransform，可以为每一个选项指定同样的属性，这些属性将会覆盖默认属性。

而在自定义模式时，每个选择支中的transform属性便会生效，用户可以通过此精确控制每个分支的一个属性，来达到一些特殊的效果：

branch.custom().open([
  {
    content: '我是好人',
    callback: () => loadAndNext(good);
    bg: '1',
    transform: {width: 200, height: 100, x: 120, y: 200, rotation: 30}
  },
  {
    content: '我是坏人',
    callback: () => interpreter.load(bad);
    bg: '2',
    transform: {width: 200, height: 100, x: 240, y: 400}
  }
]);

再配合类似于上面类的animate和from方法，便可以实现丰富的出现动画，不过现在每个选择支的单独动画尚未完成，做起来也不难，不过我觉得没有必要——选择支一起出现，黄油都是这么干的。

音乐

由于此次游戏没有用到音乐，所以只是做了一个基本的BGM播放，按理说BGM和效果音应该是分轨的，效果音也可以多音轨，基本使用方法如下，不再过多介绍：

bgm.play('bgm-home');
bgm.pause();
bgm.resume();

其他

其他一些游戏中的演出，比如标题、轮回画面、银河都是该游戏特例化的对象，业务耦合度过深，基本不可能抽象，对于这些对象，我都是直接在扩展外另写几个类，并按照解释器要求的形式进行方法的编写，使其能够无缝融入剧本，所以这几个类可以看做是这个GAL扩展的扩展。这几个类除了银河之外没什么好说的，难度基本都在玄学调动画而非设计上，银河我会在下面单独说明。

演出

上面的实现细节其实已经说了大部分演出的原理，这里还要单独说的就是这个竖屏的问题。由于游戏是移动端游戏，并且移动端浏览器千奇百怪，顶部的bar很可能无法隐藏，如此情况下纵向可视区域就非常之效了。所以即便是违背传统GAL的模式，我还是选择了竖屏。竖屏的话就有两个问题——一个问题是演出画布过窄，很难做到多人同台；另一个问题则是用户横屏的问题，比如在B站IPAD客户端内就是强制横屏。

适配

对于画布过窄的问题，我是通过演出的一个trick来解决的。读者是否记得，在游戏中经常出现人物和场景同步移动的情景？这就是我的解决方案——既然画布过窄，我就变相扩展画布，将画布扩展到屏幕之外，然后通过移动屏幕中显示的内容来决定现在舞台上的对象。这个操作的核心是在Scene的at方法后加上第三个参数，这个参数是一个bool值，决定下一次移动是否要背景带着人物一起移动，这也就是一开始说的那个main子图层存在的意义，当一起移动时，移动的是main图层，否则移动的是bg图层自身。

而对于强制竖屏的问题，我利用的是Egret自身的方法：缩放模式和旋转模式说明。我将data-orientation设置为portrait来强制竖屏，然后选用fixedWidth这种缩放模式来进行不同分辨率的适配，加之在渲染时我的图层实时计算，基本完美解决了适配问题。

银河

银河也就是最后的CG和一系列操作，前面的CG动画就不说了，调参罢了。值得说明的主要是留言板和仰望星空的实现。

留言板其实就是一条条文字数据，我拿到数据后把这些文字画到画布上而已。但为了在均匀铺满星空的同时又尽量避免那种人工的规则感，我先将星空那张图的画布区域分割成了7x7块，然后再每一块中放置一条留言，每条留言的位置会在这个区块内进行随机，同时随机的还有留言的scale，这样就可以造成一种不规则却又铺满的感觉（虽然还是有点假）。

仰望星空这一个操作显然是用了陀螺仪，在做这一个功能并将其作为查看留言的唯一方式时我就已经预料到了争议，但为了一些情怀的仪式感，我还是这么做了。其基本原理很简单，其实就是在那个仰望星空的按钮出现时，程序就开始不断记录用户当前陀螺仪的三个角度偏移值，当用户按下按钮时，程序判断当前的偏移值是否在合理范围内，如果合理，则以当前位置为起点开始进行观测，横向依赖的是alpha的变换，纵向则依赖于beta。这里有一个坑是不同的系统和浏览器对陀螺仪角度的解释不一样，只能UA判断做适配了= =。

观测时移动的背景实际上是二维图像进行的伪全景模拟，而并非三维的Skybox，这一点我深表遗憾——毕竟为了这样一个功能再将Egret3D引入，还是得不偿失，而且也由于时间原因无暇再改，这一点下一次会有所计划。

另外后端临时和我商量加入了一个留言板实时更新的功能，这是一个新的功能，基于弹幕系统的实时推送，基于WebSocket。其难点在于我每次收到后端通知后，总是要找到用户当前观看区域中、随机的一块，将其中的留言移除再更新，以此保证用户的基本体验。这个功能在此处只是做实验，后续活动会有更大应用。

彩蛋

这次彩蛋比较少，一个是在用户留言不足、或是一定概率下，星空留言的一部分将由我mock的数据填充，这些数据都是一些ACG作品中的人物以及其名言。另一个就是我给我女朋友的专属菜单啦，我们只能互相匹配到对方，并且结尾有一段专门的彩蛋剧情，虐下狗（逃

BML2017主视觉技术剖析

dtysky — Monday, 12 Jun 2017 20:00:00 -00:00

今年BML宣发页面的主视觉由我负责，使用了比较新的技术栈，包含大量动画技巧以及视频运用，下面大概分析一下这些技术和遇到的一些坑。

对IE的处理

将这一点放在文章之首是为了充分表达我个人（应该也是世界上所有有追求的前端工程师）对IE的厌恶，经过一番较为艰难的沟通，我们终于就“在此活动干掉IE全家”达成了共识，所以如果用IE访问此页面，你应该会看到一个配有33娘背景图的页面，其上的文字敦促你去下载现代浏览器，我觉得这和苹果强推HTTPS一样，有一定影响力的公司应当为业界的技术革新产生一些贡献。

为了实现这一点，我用了两个手段，对于IE9以下（包括自身）的IE，可以在HTML加入一段这样的注释

<!--[if IE]>
<div class="ie-must-die">
  <div class="ie-container">
    <h1>
      您正在使用IE
    </h1>
    <p>
      少女H也曾依赖过IE，借此来窥探这个世界。
      <br />
      但IE毕竟已然老去，早已无法适应这个绚丽的时代。
      <br />
      他的职责既已完成，不如就任其安然睡去吧——
      <br />
      毕竟，这个时代是属于现代浏览器的。
    </p>
    <a href="https://browsehappy.com" target="_blank">
      您可以点击此处，下载Chrome后再次打开本页面。
    </a>
  </div>
</div>
<![endif]-->

这段代码在IE中会取消注释并插入到DOM中，如果想判断IE版本，可以在if条件处修改，比如要在IE8以下显示，可以写if lt IE9。

但这种方法毕竟只能支持IE10以下的版本，诚然IE10以上的IE已然友善许多，但还是有很多奇怪的坑（尤其是有很多动画的时候），这时候就需要别的方法来对其进行屏蔽。由于我使用的是React，所以只需要设定一个状态，并更具这个状态决定要渲染的DOM即可：

// config.ts
const isIE = !!window.ActiveXObject || 'ActiveXObject' in window;

// App.tsx -> render
if (config.isIE) {
  return (
    <div className={cx('ie-must-die')}>
      ......
    </div>
  );
}

Preload

结构

IE说完，下面切到正文。BML主视觉属于大型活动页面，视频和图像资源比较多，在对首屏展示有着严格要求的情况下，预加载是必须的。我写了一个ResourceManager单例来管理所有资源，它构造时接受一个数组，数组中的每个对象可用参数配置src、type、是否需要preload以及preload时的权重weight，除此之外，还可以设置一个超时时间timeout来强制一定时间内加载完成（即使资源尚未真正加载完），这是为了确保访问体验的下限。

{name: 'world', src: resSrc.world, type: 'video', preload: isPC, weight: 20},
{name: 'guide-img', src: resSrc.guideImg, type: 'image'},

const resourceManager = new ResourceManager(resources, 8000);

当单例初始化结束后，便可以在任何地方调用它的load方法来进行加载，在期间可以用loadDone这个访问器来确定是否已经加载完成。除此之外，我还定义了一个registerOnProgress方法来注册一个回调，此回调在加载进度变更的时候会被调用，它可以灵活得被用于和React组件结合刷新视图：

resourceManager.registerOnProgress((progress: number) => {this.setState({progress}));
resourceManager.load();

而在使用时，只需要调用getSrc(name)方法即可拿到资源的url。

数据结构

加载队列中的每个资源都有相同的的数据结构，其为：

interface IResourceElement extends IResourceEntry {
  preload?: boolean;
  name: string;
  src: string;
  // image or video
  type: 'image' | 'video';
  weight?: number;
  element?: HTMLImageElement | HTMLVideoElement;
  progress?: number;
}

其中progress即为该资源的加载进度，取0 ~ 1，当不需要预加载时，其恒定为1。

当资源加载进度变更时，通过progress访问器可以获取到资源的实际进度，其基本思路就是遍历所有资源对象，将每一个的progress乘以权重weight相加，最后除以权重和。

图像预加载

图像预加载比较简单，只要创建Image对象，绑上onload事件并设置src，在事件执行时将其对应的progress设为1即可。

// element为一个Image对象
const element = this.resources[name].element;
element.onload = () => {
    this.resources[name].progress = 1;
    if (!this.loaded) {
      this.onProgress(this.progress);
    }
};
element.src = this.resources[name].src;

视频预加载

视频预加载比起图像麻烦的一点在于，我们无法通过向new Video()这样的方法创建一个视频对象然后如图像那样处理，而是必须用document.createElement('video')并用其API，此外，为了兼容，还必须将其插入到DOM中来保证其正常加载，于是代码就变成了这样：

// element为视频对象
this.resources[name].element.addEventListener('canplaythrough', this.handleVideoProgress(name));
this.resources[name].element.muted = 'muted';
this.resources[name].element.preload = 'auto';
this.resources[name].element.src = this.resources[name].src;
this.resources[name].element.style.position = 'fixed';
this.resources[name].element.style.transform = 'scale(-10000)';
this.resources[name].element.style.width = '0';
this.resources[name].element.style.height = '0';
document.body.appendChild(this.resources[name].element);
this.resources[name].element.play();

即，将视频绑事件，插入到DOM中并使其不可见，然后播放它。我这里绑的事件是canplaythrough，这个事件将会在每一次视频可以一段时间时触发，这个机制也影响到了对应回调函数的实现。

视频和图像不同，我们可以拿到其总长和加载期间已经加载了多少：

// 总时长
const duration = this.resources[name].element.duration;
// 已经加载的时长
const buffered = this.resources[name].element.buffered.end(0);

通过这二者便可以算出加载的比例，也就是progress的值：

this.resources[name].progress = buffered / this.resources[name].element.duration;

算完后触发onProgress回调，基本就完成了，别忘了在加载结束时将element从DOM中移除www

Guide-首屏

前置处理做完，接下来便是视图的展示了。

首先是首屏，也就是一进来的那段酷炫的特效，其原理很简单，其实就是背景视频 + SVG + 几个DOM。下面分PC和移动两个平台来阐释其中的重点。

PC

PC的H5视频支持基本完美，需要注意的只有。

而这视频虽然有两段，其实是一个视频，只不过我监听了timeupdate方法，在视频播放进度变更的时候设置不同的状态来确保新视图的渲染，跳过功能也不过是修改video.currentTime而已。这里比较需要注意的是样式问题，因为是将视频作为背景，所以我们需要一个类似于background-size: cover的效果，当知道原始视频宽高比的情况下，样式可以这么写：

.cover-video {
    @media (min-aspect-ratio: 16 / 9) {
        width: 100%;
        height: auto;
    }
    @media (max-aspect-ratio: 16 / 9) {
        width: auto;
        height: 100%;
    }
    position: absolute;
    top: 50%;
    left: 50%;
    transform: translate(-50%,-50%);
}

至于SVG动画，由于一开始还试图考虑兼容IE，这里使用的是Vivus库，不过它也有一些问题，能用原生的SVG动画还是原生吧。

移动端

移动端的背景视频播放绝对是超级大坑，由于移动平台设备奇多，良莠不齐，所以我付出很多努力后，最后还是在指示下将其取消了，但我研究出的这个方法应该还是可以兼容绝大多数现代设备的，所以就将经验写在这里吧。

第一个问题是有些版本的设备不支持背景视频，很多设备即使支持，浏览器也会劫持视频，对于这些设备和浏览器我建议直接放弃治疗，禁掉视频吧。比如5.0以下的安卓啦，移动端的QQ浏览器（不包括QQ和微信的内置浏览器以及HD版本）。

对于iOS设备，10是可以直接支持背景视频的（Safari或者基于原生Webview的），但8和9需要一个插件来支持iphone-inline-video。此外，还需要在video标签上加上playsInline属性。

对于QQ和微信内置浏览器，只需要在video标签上再加上两个属性即可：

video.setAttribute('webkit-playsinline', 'true');
video.setAttribute('x5-video-player-type', 'h5');

下面给出我用的几个平台的判据：

const isQQ = /TBS/.test(navigator.userAgent);
const isIos = /iPad|iPhone|iPod/.test(navigator.userAgent);
const isIpad = /iPad/.test(navigator.userAgent);
const isAndroid = /Android/.test(navigator.userAgent);
const isQQBroswer = !isIpad && /MQQBrowser/.test(navigator.userAgent) && !isQQ
const getAndroidVersion = (ua: string) => {
    const u = ua || navigator.userAgent;
    const match = u.match(/Android\s([0-9\.]*)/);
    return match ? parseFloat(match[1]) : 4;
};

Home-分会场选择

酷炫的特技后是分会场选择页面，此页面结构虽看似简单，但其实是最耗性能的一页，这也怪我当时想的太简单全用DOM动画吧（用canvas可能麻烦点但性能应该会好很多）。

该页面主要由背景的星轨、前面的无限轮播图和其他一些小按钮构成。那些小按钮暂且不论，星轨和轮播图的动画相对复杂，值得单独拿出来说一说。

星轨

星轨分两部分，一个是在完全进入页面后的行星转动动画，一个是在从别的页面切换回来时的逐环扩散效果。

转动

前者比较简单，用无限循环的keyframes实现即可，要注意这里最好让行星自己动，不要带轨道一起，性能会好点。但既然要行星自己动，那么行星自己的transform-origin就要特别注意，其需要注意的样式为：

.star-item {
    transform-origin: @star-size / 2 (@rail-size + @rail-width + @star-size) / 2;
    left: (@rail-size - @star-size) / 2;
    top: -(@star-size + @rail-width) / 2;
}

其中star-size是行星直径，rail-size是轨道直径，rail-width是轨道的border宽度。这个再加上keyframes，整个效果就出来了（当然轨道居中什么的还有些额外样式，很简单，这里不多说）。

@keyframes rotate-stars {
  from {transform: rotate(0deg) translateZ(0);}
  to {transform: rotate(360deg) translateZ(0);}
}
.star-item {
    animation: rotate-stars @step * 4s linear 0s infinite normal;
}

扩散

扩散的效果就比较不友好了，由于我想使用纯CSS实现，所以又不想借助于ReactCssTransitionGroup，所以又只能用keyframes，这里利用了它的一个特性，就是keyframes（所在的class）被新加入到DOM上时，其必定会被触发一遍，这一点在带有这种样式的DOM被新插入页面中时也一样，利用这一点，我们就可以使用keyframes加上不同的插入时点、或者利用其本身的阶段特性，来实现这样的动画效果。我选用的是后者，九个星轨实际上是九个DOM，每一个都拥有自己独立的动画，而它们是同时插入到页面中的，也拥有同样的时间：

.star-rail {
    animation: 1.6s ~'home-star-@{step}' ease-out;
}

然后针对不同的step写动画：

@keyframes home-star-0 {
  0% {opacity: 0;}
  5% {opacity: 1;}
}

......

@keyframes home-star-5 {
  0% {opacity: 0;}
  40% {opacity: 0;}
  60% {opacity: 1;}
}

......

@keyframes home-star-9 {
  0% {opacity: 0;}
  80% {opacity: 0;}
  100% {opacity: 1;}
}

不错，核心就是肝疼的微调，也正因为此，渲染性能消耗变得很高。

轮播

轮播和星轨一样，其实也是分两部分的，入场时是一个额外的DOM，结束后展示的是另外一个DOM，只不过这两个DOM切换时完全重合，所以造成了一种无缝的错觉。

入场

入场和星轨的入场一样，也是利用keyframes分阶段实现的，这个比较简单，基本就是微调样式，对四个场子的bg进行translate和scale、margin的变换，在这里我强行开了translateZ来进行GPU加速，但在一些机器上还是会有些卡和抖动，这个大概是transform变换中的渲染性能消耗和计算出的小数导致。

在入场完成后，js这边控制状态切换到入场后的DOM，实现无缝切换。

入场后

入场后会有一段前景左侧图片和右侧文字的小动画，以及其他一些小按钮的动画，这些都是keyframes实现的。同时，在进行轮播的左右切换之时你会发现前景和背景、前景的图像和文字之间都有明显的视差（即不是同步移动），这个也是通过添加和删除keyframes相关的样式实现的。

而轮播自身，因为是无限循环的轮播，所以每次切换结束总是要将移动侧边缘的DOM删除后插入到另一边，这也导致无法用纯CSS实现，必须上JS，于是这就涉及到了React中的JS动画实现问题。在这里我选用了和ReactMotion相似的原理，自己写了一个Animation组件，用于实现需求的动画。

<Animation
    enable={enableAnimation}
    animation={next.styles}
    duration={duration}
    easing={easing}
    onEnd={this.handleAnimationEnd}
>
    styles => (
        ......
    )
</Animation>

此组件用法如上，enable表示是否允许动画；duration是起始到终止态的时间；easing是缓动函数的类型，这里我们使用了d3-ease和d3-interpolate来实现起始到终止态之间的插值；onEnd是一个回调，其在每次动画结束后触发；最后是这个animation属性，它是整个组件的核心，用于动画的触发，触发方式是要求两次传入的值不同，这个值可以是一个数字、一个数组或是一个对象。触发动画后，组件的children（要求是一个函数）将会每个一段时间（取决于requestAnimationFrame）接收到一个经过插值计算后的值，然后通过这个值进行组件的渲染。

有了这个组件，轮播的动画逻辑就很清晰了：用户每次操作时算出每个场次的下一个位置，扔到一个数组里（这里是next.styles），然后根据每一次的styles进行渲染，并监听onEnd事件，在动画结束后完成DOM的删除和插入即可。

World-地域选择和分享

第三屏是地域选择和分享，其可以划分为两个主要部分——“地区选择器”和“分享图片生成”。

地区选择器

地区选择器说来也简单，其实就是三个关联选择框，其核心是数据来源。这方面我是选择了网上找到的一个地区区号和名字的列表的xml文件，之后自己转成了两个json文件locationListTable.json和locationLookupTable.json：

const locationListTable = {'11': {name: '北京', children: {'1101': {name: '北京', children: null}}}, ......}
const locationLookupTable = {"11":{"id":"11","name":"北京","parent":null},"1101":{"id":"1101","name":"北京","parent":"11"}, ......}

第一个用于生成关联选择器，第二个用于利用id反向查询名字和父级。有了这两个表，地区选择器的实现基本就是搬砖难度了。

分享图是根据用户选择的地区实时生成的，基于canvas。原理是先载入一张背景图，利用drawImage方法将其绘制到canvas中并将canvas引用保存。之后每次用户点击生成时，只需要用特定的字体将地区的名字用fillText方法绘制上去，之后再用toDataUrl方法即可生成预览图。这是第一步。

生成完预览图后我们并不能直接分享，因为几乎所有社交应用的分享接口都是不支持base64接口的，所以这里由后端提供了一个通过base64为参数上传图片的接口。用户确认后再点击一次生成才会真正得生成图像供用户分享。这也大大降低了后端的压力，提升了用户的体验。

其他

你可能会注意到这个分享流程在任意次访问中只会走一遍，但换个浏览器却又要重新输入。这是由于我此处使用了一个变量来保存用户的访问状态，而此变量存到了localStorage内。在使用localStorage的时候，一定要注意用户是否是在隐身模式下，如果是则需要降级（这里的降级方案是直接存到内存，至少保证该次访问正常），下面是判断用户localStorage是否可用的方法：

let storeEnabled = true;
try {
  localStorage.setItem('test', 'test');
} catch (e) {
  storeEnabled = false;
}

Comments-讨论区

最后就是讨论区了，你们一定以为我只是主站评论区换了个皮肤吧www

错，由于要把评论区改造成贴吧，为了可控和与现在ts + react的技术栈相容，我将评论区重写了一遍，并在外面套了一层别的东西做成了这种微博式的体验。得益于ts和less的优秀，这一部分只花了一周基本就搞定www

虽说一周搞定，但其实讨论区的逻辑工作量是最大的，还好我最先开发的是这一块，那时候脑子最清楚（后面都被各种样式、兼容、媒体查询搞的精疲力竭）

这一块没什么特别的心得，大部分都是业务逻辑和后端对接口，要说真有什么建议的话：

先把类型和数据结构定好再写代码，像这样子都写好回来查后来改都好弄，还有类型校验防止SB错误，你们还有什么理由不用TS！

export interface IMember {
  mid: string;
  uname: string;
  sex: string;
  avatar?: string;
  face: string;
  sign: string;
  rank: string;
  level_info: {
    current_level: number
  };
}

结语

基本就这些了，要说遗憾也有，这次本来想上WEBGL的后来觉得不太稳也没上，由于一开始没想太多所以后面发现性能有问题想改成canvas也来不及了。

说到底还是经验不太够，这次成长了很多，下次大型活动我们再见。

现代前端-近年的发展与有趣实践

dtysky — Sunday, 08 Jan 2017 20:00:00 -00:00

这个是我在B站内部技术分享做的PPT，本人水平还很菜所以难免有不少纰漏，但脉络上应该还是没有问题的，抱着一切能开源就开源的心态，我就扔这里了www（跑年轻还是要多折腾啊，要不以后多后悔www

H光-前端.pptx

照骗（逃

【Less】实现可选参数以及各种AutopreFixer

dtysky — Friday, 14 Oct 2016 20:00:00 -00:00

Less和Sass、Scss、Stylus等都是CSS的预处理语言，比起CSS，它们更接近于一门完整的程序语言。变量、引用、函数、Mixin等，使得它们提供更强的逻辑功能来使得样式代码也可以复用、并且便于维护。Less相较其它几种，更加接近于CSS原生的思维模式和写法。本篇就我的使用心得，论述一下如何可选参数函数，以及介绍一些我实现的各种AutopreFixer，比如keyframes的AutopreFixer。

可选参数函数

在less中实现可选参数函数，只需要给参数设定一个不会用到的默认值，然后在内部检查是否为这个值并开分支即可：

.background(@all: undefined, @size: undefined, @pos: undefined, @re: undefined, @clip: undefined, @image: undefined, @color: undefined) {
  .test();
  .test() when not (@size = undefined) {
      background-size: @size;
  }
  .test() when not (@pos = undefined) {
      background-position: @pos;
  }
  .test() when not (@re = undefined) {
      background-repeat: @re;
  }
  .test() when not (@clip = undefined) {
      background-clip: @clip;
  }
  .test() when not (@image = undefined) {
    background-image: @image;
  }
  .test() when not (@color = undefined) {
    background-color: @color;
  }
  .test() when not (@all = undefined) {
      background: @all;
  }
}

如此，我们使用它时便可以达到如下效果：

.test {
    .background(@size: cover, @color: green);
}

转换为：

.test {
    background-size: cover;
    background-color: green;
}

AutoPrefixer

主要用于处理浏览器兼容问题，一般的AutoPrefixer比较简单，主要利用将参数作为属性名的一部分的特性，比如这个：

.autoprefix-some(@name, @t) {
  -webkit-@{name}: @t;
  -moz-@{name}: @t;
  -o-@{name}: @t;
    @{name}: @t;
}

.autoprefix-transition(@t) {
  .autoprefix-some(transition, @t);
}

下面代码：

.test {
    .autoprefix-transition(all .5s esae-out);
}

将被转换为：

.test {
    -webkit-transition: all .5s esae-out;
    -moz-transition: all .5s esae-out;
    -o-transition: all .5s esae-out;
    transition: all .5s esae-out;
}

但如果想要实现keyframes的AutopreFixer，就需要用到一些奇淫巧技了，比如字符串转移、拼接等，有点绕，自行体会吧：

.autoprefix-keyframe-transform(@name, @func, @t1, @t2, @t3: undefined, @use-prefix: true) {
  .base(@prefix, @bind) {
    .t1() {
        @{prefix}@{func}: @t1;
    }
    .t2() {
        @{prefix}@{func}: @t2;
    }
    .t3() {
        @{prefix}@{func}: @t3;
    }
    @start: ~"@{bind}@@{prefix}keyframes @{name} { `'\n'` 0%";
    @{start} { .t1(); }
    .test() when (@t3 = undefined) {
      100% { .t2(); }
    }
    .test() when not (@t3 = undefined) {
      50% { .t2(); }
      100% { .t3(); }
    }
    .test();
  }
  @end:  ~"} `'\n'`";
  .end() {
    @{end} {.wtf {color: #fff}}
  }
  .base(~'', ~'');
  .base(-o-, @end);
  .base(-webkit-, @end);
  .base(-moz-, @end);
  .base(-ms-, @end);
  .end();
}

下列代码：

.autoprefix-keyframe-transform(test, top, 30px, 60px, 30px);

将被转换为：

@keyframes test {
    0% {
        top: 30px
    }

    50% {
        top: 60px
    }

    to {
        top: 30px
    }
}

@-webkit-keyframes test {
    0% {
        -webkit-top: 30px
    }

    50% {
        -webkit-top: 60px
    }

    to {
        -webkit-top: 30px
    }
}

@-o-keyframes test {
    0% {
        -webkit-top: 30px
    }

    50% {
        -webkit-top: 60px
    }

    to {
        -webkit-top: 30px
    }
}

@-moz-keyframes test {
    0% {
        -webkit-top: 30px
    }

    50% {
        -webkit-top: 60px
    }

    to {
        -webkit-top: 30px
    }
}

@-ms-keyframes test {
    0% {
        -webkit-top: 30px
    }

    50% {
        -webkit-top: 60px
    }

    to {
        -webkit-top: 30px
    }
}

【Flask/React】此博客服务端的缓存实现

dtysky — Thursday, 13 Oct 2016 21:00:00 -00:00

承接上篇【React/Redux】深入理解React服务端渲染，由于React服务端渲染带来的开销，在内存尚可的状况下使用缓存是个不错的选择，而对于这个项目，由于前后端是分离的，所以需要在Node这边和Flask那边来协作完成最完备的缓存，本片文章就将记录一下我的思路。

前端架构在前面两篇文章均已说清，而后端架构则和这篇差不多（【Flask/React/MongoDB】BlogReworkIII-如何搭建一个动态Blog），没怎么改过。

问题

由于前端服务器实现了服务端渲染，考虑这个博客的文章修改不会很频繁，其修改的频率远远小于访问频率，所以用Cache来减少这个渲染的开销是合适的。为了设计这个Cache，需要明确现在前后端的设计下一次客户端请求的完整响应流程：

客户端发起请求，服务端开始渲染，进入相应组件的生命周期并向后端发起ajax请求，后端响应后进行下一步操作。由于前后端是分离的，Blog内容管理的核心在后端，所以核心就在于判定后端返回什么状态时从Cache中拿东西，在什么状态时修改Cache，这就要求后端提供给前端一个约定的协议。

后端

在本Blog项目中，Cache这个方面，后端需要提供给前端的实际上是一个状态，这个状态表明前端向后端请求的数据是否发生了改动。一个显而易见的方法是由后端先缓存所哟已经被请求过的数据，在下次请求时再拿从数据库中得到的新数据来对比，根据比对的结果返回一个状态码（比如304），这样后端响应前端的结果可以表述为：

{
    content: {......},
    code: 200(304)
}

注意这个200和304虽然和HTTP标准中的状态码值一致，但却是两个东西，在两种状态下它们返回的状态都是200，只不过数据中有个code字段来标示状态。

这种做法很直观，但每次响应除了原先的数据库查询操作外，还要多一步对象对比的过程，这显然是不合适的，而且在这种设计下后端的这个Cache也失去了本来的意义，必须有其他的方案来解决这个问题。这里可以回顾一下后端的实现：

可以发现，数据库只会在程序监听pages文件夹内文件的改动后才会发生，并且这个改动事件是可以被程序捕获到的，这就提供了另一个解决方案——同时维护一个cache和与其对应的state，cache中存储响应内容，state中存储改内容对应的修改状态，而这个state中的内容除了初始化之外，只能伴随文章改动的事件而修改。

在这个思想的基础上，一个抽象的Cache和其成员便可以被构造出来：

class WebCache():
    def __init__(self):
        self._cache = {}
        self._state = {}

    @property
    def flag(self):
        ......

    def updateContent(self, parameters, content):
        ......

    def modifyState(self, parameters):
        .....

    def get(self, parameters):
        .....

    def delete(self, parameters):
        .....

    def has(self, parameters):
       ......

    def is_modified(self, parameters):
        ......

这是一个Cache的基类，它的作用和后端架构中其他基类基本一致（详见后端设计的那篇文章），它提供了一系列方法来维护内部的_cache和_state，其中updateContent、modifyState、delete是维护它们的核心方法，其他方法则负责在请求到来时判定状态和取值，由此，整个设计便完成如下：

文本解释如下：

当前端请求到来时，如果cache中没有请求对应的内容，则从数据库查出内容并调用updateContent放入缓存，此时_cache将被更新，同时_state中的对应的值将被设为False，表明未被修改，并直接返回一个code为200的响应。
当前端请求到来时，如果cache中拥有对应的内容，并且_state中对应状态为False（表明未被修改），则直接返回一个code为304的响应。
当前端请求到来时，如果cache中拥有对应的内容，并且_state中对应状态为True（表明已被修改），则重复1。
当文件监控器发现文件被更改、并进行到写入数据库这一步时，直接根据当前写入的条目判断该条目是否在cache中，如果在，则调用modifyState方法将_state中对应的值设为True。

如此，后端的缓存以及和前端的协议便已完成。

前端

前端服务器的Cache结构和后端基本一致，但也有一些不同，最明显在于前端的请求会有分页这个参数而后端没有，并且Redux中维护的状态和最终渲染的页面也并非对应，比如：

在文章列表、也就是/category/Skill/0这种页面中，其对应Redux的store中的state是一个维护着list和payload的变量，list存储着所有的文章，payload负责分页，由于Blog自身的性质，我设计的是在一次用于访问中只会获取一次list，分页通过设置payload中的page加之组件渲染逻辑来实现（本质上就是数组切片）。

在这种情况下，如果两次请求的路由中分类都是一致的，只是分页不同，那么将其作为两种请求来多做一次服务端渲染显然是不合适的，因为我们完全可以利用第一次请求的list、加之对payload的修改来直接进行二次渲染，而不必再走一次状态的初始化，这也就要求将Redux中的store和最终页面的内容分别进行缓存：

let cacheStore = Immutable.fromJS({});
let cachePage = Immutable.fromJS({});

cacheStore用于缓存不同请求下的store，以后端接口url为key；cachePage则用于缓存最终的结果，以客户端请求url为key。有了Cache基本框架，便可以结合客户端请求和后端响应来进行最后的设计：

当一次客户端请求来到时，先解析出此次请求对应的后端接口url，并向后端发出请求。
得到后端响应，判断状态码code，如果是200，直接重新走一遍完整的服务端渲染流程，如果是304，则先去查cachePage中有没有对应的数据，如果有，则直接返回其中的内容。
如果code是304但cachePage中没有对应的内容，假如cacheStore中也没有对应的store，则走一遍完整的服务端渲染流程，如果有，则直接取出store执行相应的store.dispatch修改payload，接着直接进入二次渲染。
在二次渲染结束后，更新两个Cache。

改进

Cache带来的性能提升以内存消耗为代价，典型的空间换时间，所以能减少内存消耗的事情该做的还是要做。这一点也很简单，考虑到cachePage中存的是最终返回给客户端的页面，而这种页面终归是要被压缩的，所以在放入缓存之前就可以直接将其压缩，这样最后从里面取到的也是压缩后的数据，不但节省了空间还省去了每次的压缩带来的损耗：

cachePage = cachePage.set(
    frontUrl,
    zlib.gzipSync(page)
);

【React/Redux】深入理解React服务端渲染

dtysky — Tuesday, 11 Oct 2016 21:00:00 -00:00

在上一篇文章【React/Redux/Router/Immutable】React最佳实践的正确食用姿势中，已经论述了React最佳实践的前端部分，但在最后也已说明，那种基本实现对SEO并不友好，并且由于首屏渲染依赖于ajax所以在JS禁用状态下基本也就废了，所以我们需要利用服务端渲染（Server side rendering）来对首屏进行优化。虽然React官方提供服务端渲染的API，React-router也支持，但在渲染依赖于ajax请求的状况下仍然聊胜于无，但这并不是无解的，和Redux的合作便可以相对完美地解决这个问题。

接下来将以我的博客为例，论述一下如何正确进行React的服务端渲染，这一部分的代码基本都在server/server.bin.js中。

问题

如果没有服务端渲染，那么一个React架构的SPA的渲染是这样的：

客户端请求资源 -> 返回index.html模板 -> 请求js文件并加载 -> React执行，挂载组件 -> 进入路由 -> 一些根据组件生命周期而做的初始化操作 -> 渲染组件

在这种模式下，一开始客户端只会收到一个只有架子、没有内容的Html文件，等待js文件加载完毕后才会执行后续操作并渲染出期望中的页面。这也就是说，无论是哪个路由下的页面，一开始都会先进入index.html这个入口，然后再客户端进行接下来的渲染，这对于大部分用户确实是没有什么问题，但对于部分场景和搜索引擎就不是这样了。

某些场景

主要是JS被禁用的场景，比如是微信，在某些情况下，你在微信分享的页面可能会被判定为广告页面，在不做认证（备案）的情况下，JS脚本会被禁用，这会使得后续的渲染都无法执行。

SEO

SEO相较前面是更为严重和急迫的问题，搜索引擎这个绝大多数网站的主要流量入口，如果不加以重视，除非网站是故意不想被曝光，否则是一笔很大的损失。而根据前面的介绍不难得知，如果每次都将index.html作为入口，利用JS和ajax来渲染，搜索引擎是基本无法获得你的真正页面内容的，除了下面这个粗暴的解决方案。

一个粗暴的解决方案

这也是我上次重构最终选择的方案，对于一些搜索引擎（谷歌明确支持，必应似乎近期也支持了，百度万年技术最差不用等了），有着明确的对ajax页面的一个折中解决方案，我们可以在index.html的head里加上这么一句：

<meta name="fragment" content="!">

搜索引擎解析出这个meta信息后，便会在原始url后面加上一个?_escaped_fragment_来再次发起请求，这时候我们只需要在服务端备好另一套SEO专用的页面返回给其即可。这种方法虽然有效，但本质上还是要求我们另外准备一套界面，并且这一套和原来的代码还不能复用。比如，我在那时候就是专门写了一套jade模板来做SEO：

// Express.js的中间件
function SEO(req, res, next) {
    const escapedFragment = req.query._escaped_fragment_;
    if (escapedFragment) {
        const parsedUrl = url.parse(req.url);
        const rdPath = `/${jade}/parsedUrl.pathname`;
        logInfo("Redirect: from", req.path, "to ", rdPath);
        return res.redirect(rdPath);
    }
    return next();
}

这相当于将工作量翻了两倍。不仅如此，这还会使得server更加复杂，对于我这个Blog项目，这种妥协似乎还勉强可以接受，但对于一个复杂一些的网站就不是这样了，我们必须用一种新的方法来用最少的代码解决这个问题。

React服务端渲染

React+React-router+Redux便是解决这个问题的一套相对的完美的方案，虽然我们还是要对一些渲染逻辑做修改，但相较别的方案，仍然好得多。

ReactDom

React提供了一个API用于将虚拟DOM树在服务端环境下进行渲染，这个API是ReactDom/server中的renderToString。这个方法接受一个虚拟DOM树，并返回一个渲染后的HTML字符串，例如我有一个根级组件Root，我便可以使用下列语句得到结果：

import {renderToString} from 'ReactDom/server';
const markup = renderToString(
    <Root />
);

markup即为渲染后的结果。renderToString这个方法是服务端渲染的基础，但如果只是单纯这样使用，那么基本等于将React作为一个复杂很多的模板语言来写而已，因为这个渲染并不会理会任何的ajax请求，也不会根据url来做任何路由，它只会在第一次render方法调用后结束。这也就是说render方法之后的所有生命周期函数都不会被触发，再一次服务端渲染中，只有constructor、componentWillMount和render会被各触发一次，并且在期间使用setState也是没有意义的。

这显然不是我们期望的，为了愉快得满足我们的须有，这里有两个问题需要解决：

路由。
ajax请求。

React-router

正如上一篇文章所言，路由问题可以交由React-router解决。它提供了一系列方法来在服务端捕获请求参数，并和renderToString结合来渲染出路由最终对应的组件，其基本原理是通过一个match方法来根据客户端请求的url解析出已经定义好的routes的props，解析结果是error（错误）、redirectLocation（如果有重定向）和renderPorps（正常状况下解析到的props），我们只需要根据这些参数来执行对应的操作即可：

import {match, RouterContext} from 'react-router';
import routes from '../src/routes';
match({routes, location: req.url}, (error, redirectLocation, renderProps) => {
    if (error) {
        logError('Match routes failed: ', error, error.stack);
        return res.status(500).sendFile(config.error50xFile);
    }
    if (redirectLocation) {
        logError('Match routes redirectLocation: ', redirectLocation);
        return res.redirect(302, `${redirectLocation.pathname}${redirectLocation.search}`);
    }
    if (renderProps) {
        return render(req, res, renderProps);
    }
    logError('Miss match routes: ', error, error.stack);
    return res.status(404).sendFile(config.error404File);
});

除了前两种特殊情况和最后没有匹配到执行的404响应，一般情况下我们都会进入到render这个方法中根据renderProps来进行正常状况下的响应。renderProps的结构如下（以blog项目，并以当前这个页面的路由为例）：

{
    routes: [
        {path: '/', component: APP, ......}
        {path: 'article/:name', components: {content: Article}}
    ],
    params: [name: Skill-2016_10_11_a'],
    location: {
        pathname: '/article/Skill-2016_10_09_a',
        ......
    },
    components: [
        {
            [Function: Connect] displayName: 'Connect(APP)',
            ......
        },
        {content: Article}
    ],
    history: {......},
    router: {......},
    matchContext: {......}
}

这里面对我们有用的信息很多，但如果只是单纯用React-router配合来做服务端渲染，我们并不用了解这些，而是直接把renderProps传给待渲染的组件即可：

import {renderToString} from 'react-dom/server';
import {match, RouterContext} from 'react-router';
const markup = renderToString(
    <RouterContext {...renderProps} />
);

通过使用RouterContext，我们便得到了和客户端渲染时相似的Router组件，将其作为根组件并传入renderProps，再调用renderToString，一次具有路由的服务端渲染便完成。在此例中，它最终会返回主要区域是Article组件的真实DOM。

通过和React-router的结合，我们解决了第一个、也是相对容易的问题，但这仍然无法解决ajax调用的问题，这时候，Redux就该出场了。

Redux

Redux配合React进行服务端渲染的教程已经有许多，但这些教程大都不过是官网那篇例子的搬运，例子中所述方法的基本思想如下：

基本思想

首先要明确我们真正的问题是什么，由于服务端渲染只会走一遍生命周期，并且在第一次render后便会停止，所以想要真正渲染出最终的页面，我们必须在第一次渲染前就将状态准备好我们期望中的状态，这也就是说，我们必须要有一次超前的ajax请求实现获取状态，然后来根据这个状态渲染：

function serverSideRender(req, res) {
    request.get(url)
    .then(response => normalRender(res, response))
    .catch(err => render500(res, err))
}

在自己定义的normalRender这个方法里，我们可以通过Redux提供的createStore方法的第二个参数来进行创建带有初始状态的store，然后将这个状态送入根组件，并执行后续的渲染：

function normalRender(res, response) {
    // 假设response的响应体中就包含了所有状态信息
    const initState = response.body;
    const store = createStore(reducers, initState);
    const markup = renderToString(
        <Provider store={store}>
            <APP />
        </Provider>
    );
    // 将markup和最终的state塞到模板内渲染，这个模板取决于使用的模板引擎，也可以直接字符串替换
    return res.render(template, {
        markup,
        finalState: store.getState().toJSON()
    });
}

这个方法以响应结果为初始化状态渲染DOM，并将渲染后的结果塞入模板，值得注意的是，渲染参数里面有个finalState，这是初次渲染后、store的最终状态，我们需要将其序列化后强制写到返回的HTML的script标签中，将其赋予一个、例如叫initState的变量中，这样最终返回的HTML结构如下：

<html>
    <head>
        ......
        <script>window.initState = {{finalState}}</script>
    </head>
    <body>
        <div id="react-container"><div>{{markup}}</div></div>
    </body>
</html>

window.initState便拥有了我们服务端渲染后的状态，如此，客户端便有了一个途径来根据这个状态来初始化客户端的store，并接续接下来的操作，这实质上是完成了服务端和客户端之间状态的对接：

const store = createStore(reducers, window.initState);

特别注意，在将markup写入模板时我在React顶层DOM中又插入了一层div，这是为了解决一个特殊的警告，详细请看这里：Warning: React attempted to reuse markup in a container but the checksum was invalid。

要注意，我们可以延续状态，并非说Redux可以直接帮我们解决重复渲染的问题，无论如何，在每次重新执行初始渲染的时候，组件的生命周期还是会走一遍，如果阻止重复ajax请求、重复渲染，就是我们要在逻辑里自己把握的事情了，比如，我们的state里如果有一个字段是list，而这个list在这个应用的一次访问中只会初始化一次，那么我们便可以在初始化它的action中这么写：

function getList(currentList) {
    if (!currentList.isEmpty()) {
        return;
    }
}

那么list便不会被二次初始化，也不会进行进一步的无效渲染。

这样，官方建议的服务端渲染便完成。但这其实有另外两个问题，一个是路由的问题，还有一个，按照这种说法，我们难道要写另一套专门的逻辑来在渲染前初始化状态？一个两个状态还好，但一般SPA都不会只有这么点，而且这种ajax请求我们一般都会写在专门的action中，并在action成功或失败后交给ruducer，这些代码难道不能复用吗？客户端和服务端的同构化开发就不能实现吗？

当然可以。

路由

和React-router的结合实际上不是Redux的问题，而是React-router自身的问题，其核心在于如何根据匹配后的renderProps来获取用于初始化状态的信息，在上面一章我们已经拿到了renderProps的详细信息，接下来便可以妥善地利用这些信息。

虽然如何利用它们取决于项目的设计，但一个显而易见的策略是利用匹配后的params来作为根据进行ajax请求来获取初始数据：

const {params} = renderProps;
const {type, name} = params;
request.get(`${backendHost}/${type}/${name}`)
......

这只是一个例子，表明如何根据信息来获取响应数据来初始化状态。

在这个Blog项目中，我采用了一些特别的方法来进行这一步的操作。在我定义一个和路由相关的组件，比如Article时，我会为其赋予静态变量type：

export default class Article extends Base {
    static type = 'article';
    ......
}

再加上上面分析的内容，我们可以从renderProps.components[1].content（content是该路由对应的组件，在此处是Article，请见上一篇文章）中拿到这个type:

const {type} = renderProps.components[1].content;

然后根据这个type进行接下来的操作即可。

进阶

有了路由和基础的服务端渲染，要解决的问题便只剩同构化开发、避免多余代码的同构开发问题。这个问题解决的核心在于——store在渲染过程中是可变的，并且在服务端渲染进行过程中，有一个componentWillMount的阶段可供我们和客户端平等使用。这二者是接下来内容的基础。

由于componentWillMount会在服务端渲染过程中执行，并且执行时this.props中的内容已经根据路由信息被修改，我们可以将ajax请求放入其中：

componentWillMount() {
    const {dispatch, params} = this.props;
    const {type, name} = params;
    dispatch(getList(type, name));
}

我们可以在其中执行任意个ajax请求，由于store是可改变的，所以在请求结束后、reducer生效后将会我们便可以取到完整的、初始化过的store。也就是说，我们只要如此写好组件的生命周期，而后进行正常的服务端渲染，然后只需等待便可以得到一个初始化后的store，随后只需要将这个store作为初始化数据送入模板即可。

这听起来是不是很简单？确实很简单，但仍然有一点需要注意——ajax请求时异步的，一次服务端渲染结束后，并不代表ajax请求就结束了，我们仍然需要一些方法来确定所哟请求确实结束，这里就需要一点设计了——我们可以在store中创建一个state专门用于表示初始化是否结束，并配以相应的action和reducer来修改它：

componentWillMount() {
    const {dispatch, params} = this.props;
    const {type, name} = params;
    dispatch(getList(type, name))
        .then(() => dispatch({type: actionTypes.init.all.successful}))
        .catch(() => dispatch({type: actionTypes.init.all.failed}));
}

如此，我们便可以不断检查store.getState().state.initDone来确定所有请求是否结束：

function responseWithCheck(res, store, renderProps) {
    setImmediate(() => {
        if (!store.getState().state.get('initDone')) {
            return setImmediate(responseWithCheck, res, store, renderProps);
        }
        ......
        return res.render(......);
    });
}

setImmediate方法用于设置一个定时任务，此定时任务将在下一次mainLoop中被触发。

这样，我们便可以在基本不添加多余逻辑的情况下复用客户端代码。但这样还是有问题没有被解决，我们送到客户端的仍然只是一堆状态加上等待初始化的页面，所以还需要更近一步。

二次渲染

想要让服务端直接渲染出初始化store后的完整页面，方法很简单，只需要把第一次渲染后的finalState作为初始状态进行二次渲染即可：

const store = createStore(reducers, finalState);
const markup = renderToString(
    <Provider store={store}>
        <APP />
    </Provider>
);

如果设计足够规范，做了上述getList那样的检查，第二次渲染时是不会进行再次请求的，而是直接根据finalState渲染出真正的首屏页面。

store的dispatch方法在服务端同样可以使用，我们可以直接用store.dispatch来触发某些action来满足一些特别的需求。

至此，一个完整的、SEO友好的服务端渲染便已完成，但这样还是会有问题——客户端的方便是以服务端的消耗为代价的，客户端的每次请求都会导致服务端重新进行两次渲染和伴随的若干次ajax请求，这并不是我们期望的，所以这里就要用到Memory cache来缓存store和渲染后的页面，至于我的blog中是如何实现的，将在下一篇文章详细说明。

【React/Redux/Router/Immutable】React最佳实践的正确食用姿势

dtysky — Sunday, 09 Oct 2016 21:00:00 -00:00

现代前端框架基本都是对传统系统应用框架的搬运，React虽定位为一个View层的框架，实际上却包含了MVVM中的每一环，每一个组件都可以看做是拥有所有环节的结合体。其激进的设计不但体现在JSX这个融合了HTML+JS+CSS的语法糖，也体现在了对MVVM的杂糅，然而和直觉不同，这并没有使得三者混乱分离，或者说M V VM这三者的聚合并不会带来什么问题，反而有一些益处。真正的问题在于组件嵌套带来的组件通信和VDOM使用不当带来的性能问题，而Redux和Immutable就是来解决这个问题的。此外，React-router的出现使得前端路由成为可能，这几者结合起来大幅加强了一个SPA的开发效率和可维护性。

接下来将以我的博客为例，论述一下这个最佳实践。

React

React的出现首先打破的是HTML、JS、CSS分离的格局，许多遗老遗少大呼又回到了JSP时代，宣称这是在逆历史而行在开倒车，而新晋分子则都不以为然，认为这才是趋势。当然历史已经告诉我们二元论是站不住脚的，所以优劣必然并存，一切大都是博弈之下的选择。

Preview

传统前端开发主要是堆砌HTML结构，加之调优的样式并赋予小部分JS代码用于交互，逻辑大头基本都在后端。然而随着WEB业务的日趋复杂，前端逻辑的复杂度已不可同日而语，SPA的出现、以及后续一堆基于WEBKIT浏览器的加壳应用使得传统方式难以抗住需求，新的设计方法必须被提出。然而传统系统应用领域实际上早就对这些东西研究的十分深入，所以直接搬来即可。React搬来的是经典的MVC架构几次演化后迭代而成的MVVM，即“模型-视图-视图模型”模型，这种模型的一个经典实现就是MS的WPF，React的许多理念与其也十分相似，比如单向数据流，方法绑定等等，虽没有WPF这种经典完善，但也做的很好。其基本理念是：

组件化，每一个组件都拥有自己独立的namespace。
内部维护一个状态模型，称为state。
组件可以嵌套，并通过props变量完成和父级的通信，可以向此变量挂载方法来使得父级响应子级的请求。
内部状态可以影响视图层的渲染结果，视图层可以绑定事件控制状态，从而影响状态。
完备的生命周期，可以预测并控制整个组件的状态流向。

如此，便实现了一个健壮的、组件化的视图框架。通过这种设计，加之JSX的混写，我们可以对一个组件的所有状态进行非常细粒度的控制，也可以将整个组件封装好粗粒度调用，伸缩性非常好。不仅如此，内联样式的优先度可以使得整个页面渲染更快，通过一些lib也可以实现伪类样式，唯一的缺点大概就是和设计人员的分工和IDE的智能补全了（笑）。

要注意的是，对于数据的流向，React是强制单向数据流的，也就是说，数据只能由状态单向得传递到视图层，而不能直接由视图层传回来，视图层对状态的影响只能通过绑定事件来实现。这可以预防双向绑定带来的状态预测困难问题，当然，双向绑定也有其好处，但个人认为其好处是远小于负面影响的。

对React基本原理和应用具体如何编写，此文章不做多余探讨，阅读者应当有一些基本的功底。下面主要讨论标题所论述的“最佳实践”。

有一定React使用经验的的程序员，应当都或多或少遇到过工程庞大后的性能、以及当组件树嵌套过深时组件间的通信问题。前者主要由VDOM处理不当导致的反复render造成，而后者，则是React自身的设计特性造成的。

DOM相关优化

VDOM是React的核心概念之一，“虚拟DOM树”，相对于真实的DOM树，它由用户创建后只存在于预处理阶段，只有在满足一定条件的状况下才会被渲染为真实的DOM。比起操作真实的DOM，虚拟DOM多了一步differ的过程，所以其实是要比直接操作慢的，但考虑到其带来的工程性的提升，这点性能损失根本不足为道——本因如此，但现实的很多使用中却并非总是如此。除了differ之外，不适当的重绘都会使得性能的显著下降，这大都是因为使用不当造成的。在组件的生命周期中，有一个阶段是shouldComponentUpdate，这个方法的参数是nextProps和nextState，返回的是一个bool值，React会根据这个返回值来允许或阻止组件重绘。这是一个影响性能的核心方法，其基本使用如下：

shoudComponentUpdate(nextProps, nextState) {
    return nextPropppps !== this.props;
}

当然，这一句只是伪代码，在真实情况下这么写是没用的（JS的机制）。通过设置合适的条件，我们可以防止绝大部分的无效重绘，这也是React应有的使用方法。这要求我们在设计之初就对组件的功能有着清晰的了解，但好在如果设计的尚可，组件应该是有一个合适的粒度的，这一部分也不会太复杂。

除了自己判断之外，如果结合下面所言的Redux，还可以用其提供的辅助函数connect来决定子级组件需要件听哪些父级状态，这个下面说。

在此之外，我们还需要根据React的建议对组件设计好key，这是其进行VDOM differ的核心凭据，尤其在以数组的形式描写一个序列的子级组件之时，这个key是必须提供的：

<Parent>
    [
        <Child0 key=0/>,
        <Child1 key=1/>,
        ......
    ]
</Parent>

组件间状态传递

组件间的状态传递是原生React的一个老大难问题，第一节已经介绍过，原生的方法只能使得状态在相邻的父级和子级之间传递，如果嵌套超过三层，便很容易出现下面的情况：

表现为代码即：

// child.js
handleTextChange(value) {
    handleTextChangeParent(value);
}

// parent.js
handleTextChangeParent(value) {
    handleTextChangeGrandparent(value);
}

如果组件的层级再增长，这无疑是灾难性的，但很遗憾在现代开发中这种状况很常见。解决这种问题的方法之一是自己定义全局单例和事件管理器来共享变量，就像这篇文章写得这样，我们可以在组件初始化的时候注册若干事件，并在合适的地方dispatch来实现组件间的跨级方法调用，而状态，则可以用全局单例来共享：

// child1.js
import globalState from './globalState';
import eventManager from './globalState';
export default class Child1 extends React.Component{
    constructor(props){
        super(props);
        this.state = {playing: false};
        eventManager.register("ChangeMode", ::this.refresh);
    }

    refresh() {
        this.setState(globalState);
    }
}

// child2.js
export default class Child2 extends React.Component
    refresh() {
        eventManager.dispatch('ChangeMode');
    }
}

// globalState.js
export default {playing: false}

这样实际上也有一些问题，我们可以发现，如果将globalState的变换交给一个单独的模块，将其称为controller，便又成了经典的MVC模式。这种模式最后C这一层一般会非常臃肿庞大，所以小应用也就罢了，大应用.......
但好在我们还有Redux，并且不难发现，Redux和以上这种策略其实有一些思想上的相似。

Redux

原理

在Redux之前，FB官方出过一个配套的库叫做Flux，它从一定程度上解决了上述的问题，但无奈过于复杂，使得很多场景下难以使用。所幸不久后Redux应运而出，它脱胎于Flux，并借鉴了一些elm语言的思想，整体走函数式风格——单向数据流，无状态编程。Redux的基本思想是这样的：

维护一个顶层数据仓库，称为store。
全局只能存在一个store，所有的状态都存在于其中。
有一些被称为reducer的方法，例如reducer/theme.js，它是唯一可以准许被修改store中state的方法，每个reducer对应一个state，他接受上一次的state、一个action的type和可选的修改量，根据type来进行操作并返回下一级的state。
一些被称为action的东西，例如action/index.js，至于说东西，因为这个东西比较抽象，只能说它定义了一些可预测的行为，他可以是type，也可以是一些带有副作用的方法，一般和dispatch方法配合使用。
dispatch方法是Redux的核心方法，它是触发action的唯一途径。

store、action、reducer和dispatch，加上一个getState，便构成了Redux。我们用store作为顶层实例，action定义行为，dispatch触发行为，reducer改变状态，getState获取状态，如下：

这便是Redux的基本原理，十分简单。在默认状态下，所有使得数据的变动方法都是pure的，没有任何副作用，一切都是同步可预测的（所谓同步可预测，就是可以精确掌控在什么时刻的状态时什么样的），我们可以在初始化时赋予它任何状态，以此作为整个应用的开端，这也是Redux下的服务端渲染的基础。

和React绑定

虽然Redux是一个通用性的库，但目前还是和React结合使用最多，在安装了react-redux这个绑定之后，我们便可以利用它提供的Provider组件和connect方法将store和React的根级组件进行连接：

const store = createStore(
    reducers,
    initState,
    applyMiddleware(...middleware)
);
const Root = <Provider store={store}>
        <APP />
    </Provider>;

// APP
@connect(
    state => ({...state})
)

这里面，reducers的定义可见reducers.js，它利用combineReducers这个语法糖合并许多二级的reducer到根级reducer，并自动根据其生成二级的state树，注意里面的initState，这是一个可选的初始状态，在服务端渲染中至关重要，而applyMiddleware这个方法则是用于应用中间件的，中间件在下一节会有详解。Provider组件将APP这个应用根级组件包起来，作为新的根级组件。connect这个方法通过一个方法（这里可以理解为filter）筛选要传给下一级的state，由于是根级组件，所有状态都要传，所以将其解包即可。

这里不难发现，如果每一次状态改变都要从根组件向下传递，那么默认状况下，所有子级组件都会响应改变事件，可能会引起大量不必要的重绘或逻辑操作，这除了用上一章所言的shouldComponentUpdate来屏蔽之外，还可以注意connect这个方法提供的筛选，它实际上会帮我们做一次类似于内部的shouldComponentUpdate，合理利用它甚至可以帮我们完全解决子级组件重绘的问题。

如此一来，我们便可以将一个应用的文件目录组织为这样：src，components是React组件，actions里面定义行为，reducers里定义改变状态的方法。

执行action

在理想状况下，数据的改变都是pure的，无副作用，整个过程中没有IO操作也没有异步调用，这样数据的流向非常清晰，不会混乱。我们只需要不断使用以下语句来改变状态即可：

dispatch({type: actionTypes.change.theme.current, theme: 'home'});

接下来的事情交给Redux自己去解决就好，它会根据这个action的type去适配reducer并修改相应的state，并从根组件经过一路筛选将状态传递到需要的组件中，有需求的子级组件监听到了变化便可以执行相应的操作。

这种理想的状况确实很美好，但是现实世界是复杂的，这种情况对于绝大多数SPA是不可能存在的——ajax是基本需求。所以我们便需要一些具有副作用的action来帮我们执行操作，这里就需要提到Redux的中间件机制了，他的中间件充分利用了高阶函数的特性，有兴趣的可以在官网自行查看原理，这里我们需要了解的仅仅是——中间件本质上就是类似于流水线的东西，一个action请求被发出后，Redux会将其轮流送入被注册的中间件，经过这些中间件之后再最终进入reducer之内改变状态。利用这个特点，我们便可以使用中间件来拦截action请求，实现副作用。

Redux官方提供了这样的一个中间件——redux-thunk，其原理十分简单，代码只有寥寥几行，不再赘述。通过它，我们便可以定义一种特殊的action，并在其中执行有副作用的操作：

function getListSource(url: string) {
    return dispatch => {
        dispatch({type: actionTypes.get.list.waiting});
        return request.get(url)
            .timeout(1000)
            .then(res => {
                const list = res.body.content || [];
                dispatch({type: actionTypes.get.list.successful, url, list});
                return Promise.resolve(res);
            })
            .catch(err => {
                dispatch({type: actionTypes.get.list.failed, url});
                return Promise.reject(err);
            });
    };
}

// 执行
dispatch(getListSource('/someting'));

如此，异步操作也可以在Redux中实现了，我们在action中发起了一次ajax请求，并根据返回结果执行不同的pure-acition，来改变最终的状态。这种操作在Blog项目中共有三个——action/source.js，读者可以通过这些了解更多。

中间件的用处很多，除了这个之外，有一个很常用的中间件是redux-logger，它用于调试模式下的状态路径追踪，将其应用后可以在浏览器控制台看到如下输出：

这会使得调试变得方便清晰起来，也是Redux使得数据可预测的一个直观体现。

reducer改变state

在接收到dispatch的请求之后，Redux会将此次的action分发到对应的reducer，它实现的分发方式本质上就是“轮询”，正如前面所言，combinReducers只是一个语法糖，实际上在分发是还是会走一遍所有的reducer，reducer接收到参数后进入适当的分支，从而完成对状态的修改。

这里要特别注意，Redux的函数式特性决定了它的上一次状态是不可变的，你不能去通过修改上一次状态然后将其返回作为下一次的状态，而是必须建立一个新的状态来修改并返回它。这在一些情况下非常容易实现，但如果状态层级比较深、本身比较复杂，JS自己的对象内部又是地址引用的，所以新建并维护状态就可能变得格外复杂。虽然可以用lodash这样的工具库来简化一些操作，但仍然没有根本上解决问题，而这时候，FB官方的Immutable库便出现了，它和Redux的相容性非常好。

Immutable.js

Immutable.js是FB出的一个不可变数据结构库，它提供了一系列的数据结构和丰富的API，其数据结构有自己的内部实现，和JS原生对象的原理有所不同。作为使用者，我们需要关心的只是他提供的接口和特性。它有一个非常重要的特性就是不可变性，也就是说，Immutable对象自身是不可被修改的，一切对它的修改只会体现在修改它的方法的返回值上，它本身是不变的，这和Redux的理念不谋而合，加之其丰富得不亚于lodash的API，和Redux配套使用基本可以算是最佳组合。

在实际使用中，Immutable最常见的是下列API：

import Immutable from 'immutable';

// 将JS对象转换为Immutable对象
const im = Immutable.fromJS(obj)
// 将Immutable对象转换为JS对象
const obj = im.toJS();
// 将Immutable对象转换为JSON对象
const json = im.toJSON();
// 判断对象中是否有值
const bool = im.has(name);
// 判断两个对象是否相等
const bool = im1.equals(im2);
// 赋值/深度赋值，SetIn方法将依次查找到最后一层的key并执行赋值
// 要注意这两个方法并不会自动将obj转换为immutable对象存储！
const newIm = im.set(key, value);
const newIm = im.setIn([key1, key2, ......], value);
// 取值/深度取值
// 深度取值第二个参数是一个可选的默认值，这是一种optional的实现，如果找不到值，将会返回默认值
const value = im.get(key);
const value = im.getIn([key1, key2, ......], defaultValue);
// 归并，obj可以是Immutable对象也可以是JS对象
const newIm = im.merge(obj);

在绝大多数应用中，这几个API可以撑起半边天，尤其是merge这个方法会被经常使用（我们最好保证可以用Immutable的地方都用它）。此外equals方法也可以在shouldComponentUpdate中配合使用，使得两次props的对比变得非常简单。

React+Redux+Immutable这个组合由此完成了，合理使用它们，可以使我们的开发变得条理明晰，维护方便（当前，前提是配好那一堆恶心的环境，这里不再赘述，详情可以看这个Blog项目的配置文件（还没有单元测试相关的东西，如果加上单元测试还需要趟更多的坑，比如这个项目））。

React-router

至此，一个简单的SPA的构造条件便都满足，但这又会带来一个问题——SEO相关的问题。在这种SPA的模式下，页面是没有自己的独立URL的，这样不利于伪静态页面的生成，不便于搜索引擎索引，也不便于用户访问，前端路由就是来解决这个问题的。其核心在于利用js代码截获浏览器history中的url，通过捕获跳转或回退事件来完成应用内部的跳转行为，并同步浏览器的地址栏。

有了前端路由，我们便可以实现对SPA的分页，基于此，我们可以指定各自的url给各个页面，这使得页面的静态化成为可能。React-router则是FB官方给React提供的前端路由库，使用它，无论是搜索引擎还是用户都可以直接通过静态的url来访问单个页面。同时值得一提的是，React-router也可以在服务端使用，这样便可以实现WEB和服务端渲染的同构实现。在Blog项目中，这一部分在这个文件中src/routes，其一个经典的实现如下：

const routes = (
    <Route path="/" component={App}>
        <IndexRoute components={{content: Home}} />
        <Route path="archives(/:index)" components={{content: Archives}} />
        <Route path="category/:name(/:index)" components={{content: Category}} />
        <Route path="article/:name" components={{content: Article}} />
        ......
        <Route path="*" components={{content: NotFound}} />
    </Route>
);

Route是React-router的核心组件，他的第一个属性path是相对于根域名的路由地址，第二个component或者components是路由对应的组件。在这个路由中，根路径对应的组件是APP，所以网站会将APP作为整个应用的入口，我们必须实现APP这个组件，并让它能够在不同路由下接受不同的components，来渲染出对应的DOM树。

在此Blog工程中，这个APP组件在src/app，它的render方法中定义了许多基础的视图组件，并根据当前路由传来的params和由对应路由中components参数传来的content来确认主视图中应当显示哪些组件，这个主视图实际上就是你当前在看的这个文章主体的位置。

比如在本页中，url为http://dtysky.moe/article/Skill-2016_10_09_a，相对于根域名的地址是/article/Skill-2016_10_09_a，它会走到article/:name这个路由中，而这个路由中有个必选参数name（形如(/:index)这种参数就是非必须选的），当进入这个路由后，APP组件首先会接收到参数this.props.param={name: Skill-2016_10_09_a}和this.props.content=Article，接下来我们只需要使用cloneElement方法将content组件加上需要传入的参数放入DOM树中即可：

render() {
    const {params, content} = this.props;
    return (
        <div>
            ......
            {cloneElement(content, {params, ......})}
            ......
        </div>
    )
}

如此，当用户访问当前的这个url后，Article这个组件将会被装入DOM树，接受params和其他的一些参数并渲染出响应的页面。

完成了这一切后，我们将Routes作为根级组件挂载到React-redux的Provider下便可以完成和Redux的链接：

const Root = (
    <Provider store={store}>
        <Router
            routes={routes}
            history={browserHistory}
        />
    </Provider>
);

使用React-router要特别注意组件自身生命周期的问题，清晰了解路由跳转时组件的行为非常重要，请务必通读官方的这篇说明Component Lifecycle。

至此，React最佳实践的第一部分就差不多了，之所以说第一部分，是因为上面这些并没有真正解决SEO、即首屏渲染的问题，这会涉及到React/Redux/React-router协作的服务端渲染，下一篇文章将会详细说明如何去操作。

知识可以学习，技术只能练习，这里只能说个脉络，更多请参考我的BlogReworkPro工程。

【CSAPP】笔记-Cp3-3-控制与过程数据存储

dtysky — Monday, 04 Jul 2016 21:00:00 -00:00

CSAPP（深入理解计算机系统）第三章“程序的机器级表示”第二部分“控制、过程、和数据存储”的笔记和课后习题。
Github的同步工程在这

控制

汇编中使用控制语句来实现线性程序之外的跳转、选择等功能。

条件码

条件码用于表示一些CPU最近的状态，它们被存在一个单独的条件寄存器中，它们是：

CF：进位标志，最近操作发生了进位，可以检查无符号数的溢出。
ZF：零标志，最近操作结果为0。
SF：符号标志，最近操作的结果为负数。
OF：溢出标志，最近操作导致补码溢出。

要注意的是，lea系列指令不会不会改变这些标志，因为它本质上不是ALU运算而是地址运算；inc和dec会设置溢出标志但不会设置进位标志等......

还有一些特殊的指令只改变条件码而不发生实际运算，比如test、cmp，前者对应sub、后者对应and。

要访问这些条件码，有一系列的set d指令被提供，其中d是单字节寄存器，这组指令直接利用条件码去做出一些常用的判断，比如setge d相当于给d赋予~(SF ^ OF)，即前一个运算的两个操作数是否存在大于关系。

跳转

跳转指令jmp .L和jmp *e*会导致程序在执行时切换到另一个位置。前一种方式中，它的参数L是一个标示符，这个标示符类似于高级语言中的函数名，用于标示一段程序的开始，汇编中就是用这种方式来管理子程序的；后一种方式中，它的参数e是一个寄存器或者以寄存器为地址的(%eax)这种存储器的值，这些值将会给当做跳转地址。
还有一些跳转叫做条件跳转，它们是基本跳转语句的特化版本，比如je就是当ZF位为1时跳转之类的。它们也是高级语言条件语句的基础。

至于C语言的条件语句翻译成汇编，一般都是先开一个条件跳转语句，然后后面更上else的内容。

循环

循环语句在C中有do-while、while和for，太基础就不细说了。

do-while它们可以对应汇编中的goto和条件跳转指令的组合，像是：

loop:
    xxx
    je next
    goto loop

while和do-while类似，但它的判断放在loop段的开始，这允许产生零长度的循环：

loop:
    je next
    xxx
    goto loop

for一般等价于while形式，是另一种写法。但当和continue语句合作是可能有例外。详见习题24。

条件传送语句

条件传送语句是现代CPU都有的一条指令，它本质上是以下C代码的翻译：

int absdiff(int x, int y){
    return x < y ? y - x : x - y;
}

在汇编中，会先计算好y-x和x-y，然后通过一条cmovl指令（l表示小于）直接判断前面cmp的比较结果即条件码然后送走y-x或者x-y而不是通过条件跳转。这样做的效率一般会很高，这是由于CPU内部的流水线采用的分支预测机制。因为对于此指令，处理器只是读数据、检查条件码、然后更新或者不动目的寄存器，不会有额外的跳转。

当然这个指令并非时时有效，由于它要事先计算两个分支的结果，所以可能会造成无谓的计算浪费，也受编译器的影响。

switch指令

对应于C中的switch语句，当分支较多并且每个分支的条件间隔较小时，会生成一个跳转表，有个这个表，可以使得分支实现和复杂度无关，相对于经典的条件转移，利用查表的方式可以说复杂度都是固定的，是并行判断。

过程

过程调用将数据和控制进行跳转，而后又可以恢复现场继续执行刚才的操作。这是通过转移到控制和转移出控制实现的。

栈帧

栈帧实际上就是栈的一种应用，它是为单个过程所分配的栈，由存放于%ebp中的帧指针和存放于%esp中的栈指针控制。

转移控制

当一个过程被call指令调用时，首先将返回地址入栈，然后当前一些需要保护的局部变量什么的入栈，保护现场，随后跳转到被调用过程的首地址，调用结束后再使用leave指令做好准备，之后ret指令恢复现场并返回跳转前的地址继续。

调用控制中的寄存器分配是约定俗成的%eax、%edx和ecx被分配给被调用者，可以被覆盖，而%ebx、%esi和%edi则分配给调用者，再覆盖之前要先入栈以便恢复。

对于递归过程，编译器会将每次函数对自身的调用都视为调用一个其他的函数，本质上并无区别。

数组和结构体

数组是一种聚合数据类型，它在C中实现很简单，为T A[N]的形式，这段代码会在内存中分配N个数据类型T需要的内存空间，A作为一个标示符，是一个指向数组开头的指针，而A和下标的组合即可给这个指针加上偏移来访问数组内的任意数据。

比如定义数组char A[8]，首先分配8个字节的内存，然后将A指向这八个字节的开头，A[4]则构造A+4的指针，可以用其访问数组中的第四个数据。这在汇编中是movl (%edx, %ecx, 4), %eax。

本质上，我们使用A[i]相当于先得到元素A[i]的引用，然后用*A[i]来获得该地址的值。

嵌套数组

即多维数组，比如int A[5][5]，这和一般数组没什么两样，只不过在计算地址的时候会多一套工序，考虑你是在一个二维矩阵中取值就可以了，比如取值A[i][j]，那么地址就是A + 4(5i + j)。

定长和变长数组

定长数组是指大小在编译期就能就确定的的数组，而变长数组则不然，可能会在运行时动态改变。对于前者，尤其是多维的情况下，在编译的时候可以将其地址计算优化为常数乘法，而后者不但不能事先分配内存，必须在需要的时候才动态运算和分配，并且在取值时也要动态使用乘法来计算，所以性能会有所下降。

结构

C中的结构struct声明创建一个数据类型，将可能不同类型的对象聚合到一个对象，不同的对象用名字来引用。它本质上是方便编程的，因为对于数据本身而言，其在内存上是不变的，结构仅仅是改变去解释他们的方式，每个名字对应一个偏移，而这个偏移用于计算地址，比如：

struct S{
    int i;
    char c;
    short s;
}

S总共占据7个字节，如果其首地址为0，则S.i地址为0，S.c为4，S.s为5。

由于结构的存在，我们可以非常方便得管理聚合型数据，合理利用它也可以免除数据类型转换、新建内存的开销。

结构中的对象也可以是指针，这可以用于仿造OOP，比如将指针指向一个函数。

联合

联合union和struct不同，它用于用不同的类型去解释相同的数据，联合中所有部分的地址偏移都是一致的，它们只是用不同的方式去解释一段数据。比如：

union U{
    int i;
    char c;
    double d;
}

U会占据8字节，即double的长度，其中i、c、d的地址偏移都是0。

数据对齐

数据对齐对于提高存储器读写性能很关键，原则来讲，如果一个类型占用字节数是K，那么其地址应当是K的倍数。这就要求short类型的地址最低位为0而int型为00。对于Windows系统，对齐非常严格按照上述规则执行，而对于unix，8字节只需对齐4字节。
由于SSE指令要求存储器地址是16的倍数，所以栈帧的长度都是16的整数倍。

存储器越界引用和缓冲区溢出

缓冲区溢出是一个问题，比如在存储一个字符串时，如果没有分配足够的空间，便会发生溢出。发生溢出时，会错误覆盖栈帧中寄存器的值，这会导致被保存的现场不可恢复、代码无法正确返回等等，可能受到严重的攻击。比如库函数gets、strcpy等都有这个问题。好一点的方法是使用他们的具有限制最大长度的替代函数fgets等。

这种错误常被用于网络攻击，比如给字符串内巧妙加入一些可执行代码的字节编码，然后让其溢出，覆盖返回地址，这样就可以执行攻击代码。

对抗

对抗溢出攻击有几种方式。其中一种是栈随机化，它给程序端之前分配一些随机的、不使用的空闲空间，来是的程序的实际地址发生偏移，这样可以让程序字段的地址不可预测，是的攻击程序对地址的把握困难，这可以消除一部分影响。栈随机化被扩展后是地址空间布局随机化(ASLR)，除了栈之外，全局变量、堆等都要随机化。

另一种方法是栈破坏检测，也就是在栈帧的局部缓冲区与栈状态之间存储一个哨兵，被称为栈保护者，程序运行中不断检测它，当其被改变，即破坏时便会识别出被入侵。

还有一种就是限制可执行区域，即限定代码可以存储在什么区域。

习题

13

A. l为32位，比较为对补码的小于，所以为int。
B. w为16位，比较对补码，所以为short。
C. b为8位，比较对无符号数，所以为uchar。
D. l为32位，比较是不等于或非零操作，所以为int活uint。

14

和13类似。

15

A. 0x8048291 + (0x05 = 5)
B. 0x8048359 + (0xe7 = -25) C. 0x8048391 - (0x12 = 18)
D. 0x80482c4 + (0xffffffe0 = -32)
E. 0x8049ffc的小端是0xfc9f0408

16

A. 不想写goto，略过。
B. 本质上是吧p && a > 0拆分为了两部分来实现。

17

A. 简单，略过。
B. 两种方法等价，但是!t这种判断在没有else的状况下可以节省代码量，和if (!x) return;一样。

18

int test(int x, int y){
    int val = x;
    if(x < -3){
        if(x > y)
            val = x * y;
        else
            val = x + y；
    }
    else if(x > 2){
        val = x - y;
    }
    return val;
}

19

A. 这是一个数学问题， $n! \le 2^{32} - 1$ 即可。
B. $n! \le 2^{63} - 1$ 。

20

寄存器	初始值
%eax	x
%ecx	y
%edx	n

B. do的是body，while后的是test，前者对应.L2中的addl、imull、subl，后者则是testl、jle、cmpl、jl。
C. 略过。

21

A. 这是a+b的结果。
剩下的题略过。

22

基础，略过。

23

基础，略过。

此函数的目的在于将传入参数x进行按位镜像。

24

A. 会导致无限循环。
B. 很简单，在body之前加上判断跳转回loop。

25

概率题，套上面公式可得 $T_MP = (31 - 16)*2 = 30$ 个周期，错误时需要46个周期。

26

\运算符，本质上是为了解决负数情况下的偏置问题。

27

int test(int x, int y){
    int val = 4 * x;
    if(y > 0){
        if(x < y){
            val = x - y;
        }
        else{
            val = x ^ y;
        }
    }
    else if(y < -2){
        val = x + y;
    }
    return val;
}

28

略过。

29

int switcher(int a, int b, int c){
    int answerl
    switch(a){
        case 5:
            c = b ^ 15;
        case 0:
            answer = c + 112;
            break;
        case 2:
        case 7:
            answer = (c + b) << 2;
            break;
        case 4:
            answer = a;
            break;
        default:
            answer = b;
    }
    return answer;
}

30

A. 被设置为pop指令的地址。
B. 这不是一个过程调用，他没有ret，控制和指令顺序一致，返回值从栈中弹出。
C. 这是IA32将PC的值放到整数寄存器中唯一的方法。

31

除了必须被保存的三个寄存器之外，其他寄存器随意被被更改，不会影响调用者的行为。

32

int fun(short c, char d, int *p, int x)

33

略过。这道题主要让我们明白编译器会分配大量不会使用的空间，这可能是为了数据对齐。

34

A. %ebx保存x的值，所以它可以被用于计算表达式结果。
B.

int rfun(unsigned x){
    if(x == 0){
        return 0;
    }
    unsigned nx = x >> 1;
    int rv = rfun(nx);
    return (x & 0x01) + rv; 
}

C. 它计算x中所有位的和。

35

GCC为long double分配12个字节。
指针类型固定占用4个字节。

数组	元素大小	整个数组大小	起始位置	元素i
short S[7]	2	14	$x_S$	$x_S+2i$
short *T[3]	4	12	$x_T$	$x_T+4i$
short **U[6]	4	24	$x_U$	$x_U+i$
long double V[8]	12	96	$x_Y$	$x_Y+12i$
long double *W[4]	4	16	$x_W$	$x_W+4i$

36

表达式	类型	值	汇编代码
S+1	short *	$x_S+2$	leal 2(%edx), %eax
S[3]	short	$M[x_S+6]$	movw 6(%edx), %ax
&S[i]	short *	$x_S+2i$	leal (%edx, %ecx, 2), %eax
S[4*i+1]	short	$[x_S+8i+2]$	movw 2(%edx, %ecx, 8), %ax
S+i-5	short *	$[x_S+2i-10]$	leal -10(%edx, %ecx, 2), %eax

37

M = 5, N = 7

38

详见代码。

这样的写法对特定的规则优化，能够消除乘法，提高效率。

39

A. 0，4，8，16
B. 24个字节
C.

void sp_init(struct prob *sp){
    sp -> s.x = sp -> s.y;
    sp -> p = $(sp -> s.x);
    sp -> next = sp;
}

40

略过。

41

A. 4字节对齐。
B. 4字节对齐。
C. 2字节对齐。
D. 4字节对齐。
E. 4字节对齐。

看基本类型里最大的K。

42

A. 基础，略过。
B. 4字节对齐。
C. 按照字节大小降序排列即可，最终总和是32。

【Javascript】实现事件管理器

dtysky — Friday, 01 Jul 2016 21:20:00 -00:00

描述如何在Js中事件事件管理器，在别的语言中也差不多。

在Js中实现事件机制，可以用以下的一个类（ES6写法）实现。这是一个事件管理器，包含了注册、解除注册、发送事件三个功能，这三个功能一般足以满足轻量的事件驱动需求。

事件驱动器核心是一个hash table_events，他的键是事件名称，值是一个由方法构成的数组。
register函数用于注册事件，新建事件或者向事件中添加方法；unregister解除注册，从事件中移除方法或者自动移除事件；dispatch方法通过事件的名字执行事件，按照注册的顺序顺序执行。

class EventManager{
    constructor(){
        this._events = {};
    }

    register(event, method){
        if(this._events[event] === undefined){
            this._events[event] = [];
        }
        this._events[event].push(method);
    }

    unregister(event, method){
        if(this._events[event] === undefined){
            throw new NoEventException(
                `Can not unregister method, the event named "${event}" is not existed!`
            );
        }
        const index = this._events[event].indexOf(method);
        if(index === -1){
            throw new NoEventException(
                `Can not unregister method, the method named "${method}" is not in event "${event}"!`
            );
        }
        this._events[event].splice(index, 1);
        if(this._events[event].length === 0){
            delete this._events[event];
        }
    }

    dispatch(event){
        if(this._events[event] === undefined){
            throw new NoEventException(
                `Can not dispatch event, the event named "${event}" is not existed!`
            );
        }
        this._events[event].map(
            method => {
                method();
            }
        );
    }
}

【CSAPP】笔记-Cp3-1-程序编码、数据格式、访问信息和数据操作

dtysky — Friday, 01 Jul 2016 21:00:00 -00:00

CSAPP（深入理解计算机系统）第三章“程序的机器级表示”第一部分“程序编码、数据格式、访问信息和数据操作”的笔记和课后习题。
Github的同步工程在这

计算机执行的是机器码，即一条一条的01序列，这些序列经过CPU的控制译码器译码后以数字电路的形式操作CPU的其他部件进行工作。但机器码对人的可读性极其差，所以有了汇编代码。汇编代码可以看做是机器码的文本表现，十分接近于机器码的原本性质，但其抽象程度过低，难以构建大型工程，所以又有了C这样系统级语言，他可读性和抽象性更高，同时不会损失太多性能，但对于日渐膨胀的效率需求，系统及语言很多时候也无法更上迭代的速度，所以便有了C#这种编译型的高级语言和Python这种解释型的脚本语言，他们比C更上层，开发效率更高，门槛更低。但一般而言，开发效率和运行效率是不可兼得的。

对于C，需要一个编译器将其编译到汇编，汇编器再将汇编转换为机器码，而不同硬件平台的汇编代码往往有差异，所以高级语言还有一个重要的特点就是帮我们屏蔽了硬件底层，将兼容工作交给工具去做。

“精通细节是理解更深和更基本概念的先决条件。”

程序编码

在xinx系统中，可以使用以下代码编译一个C文件：

gcc -o1 -o p p1.c p2.c

编译两个C文件到p中，使用第一级优化。优化随着等级上升性能提高，但和原始代码的对应会下降，并且会增加编译时间。

在编译过程中，编译器文件首先会将代码中的#include和#define扩展插入代码，然后编译成汇编文件.s，随后汇编为机器码.o文件，然后和预制库进行连接，生成最后的可执行文件。

程序中的代码段存储在程序存储器中，比如操作系统信息、运行时栈等，其使用虚拟地址来寻址，操作系统负责将虚拟地址转换成物理地址。

一个例子

如果我们有一段C代码code.c，运行gcc -O1 -S code.c将其编译为汇编文件后便是code.s，其中是这段代码对应的汇编代码，这段代码一般会用push指令保护现场，然后执行函数，最后pop指令恢复现场。运行gcc -O1 -c code.s会得到code.o，这是二进制的机器码，其大小很大因为包含了执行开始等附加信息。可以通过反汇编器来从机器码中得到原始函数的字节长度并用gdb来检查。

作为CISC，即复杂指令集的CPU，IA32和X86架构的机器指令长度均不一致，有的长有的短。

数据格式

机器中的数据格式和C中的数据类型有一定的对应关系。整形数据格式有8bits的字节，16bits的字，32bits的双字和64bits的四字等，浮点数据格式有32bits的单精度，64bits的双精度和60~72bits的扩展精度。这些格式在汇编中拥有各自专属的指令，会在一般指令后加上后缀，比如两个双字相加就是addl等。

对于IA32处理器，由于四字不被直接支持，所以四字的运算和操作会被扩展。

访问信息

新时代的CPU对寄存器的专用性需求不再存在，所以CPU中的寄存器都是通用寄存器，但一般有一种约定，IA32中每一个CPU包含八个32bits的寄存器，有些指令会使用固定的源寄存器和目的寄存器，eax、ecx、edx特殊，ebp和esp保存栈指针和帧指针，等等。

每一个指令都有其操作数，一些指令又分为源操作数和目的操作数，这些操作数可以是立即数、存储器地址和寄存器，对于存储器，可以用许多种方式进行寻址，比如绝对寻址、变址寻址等，详细请自行查找CPU寻址相关。

数据传送指令将数据从一个位置复制到另一个位置，mov系列传送数据，movs系列传送符号扩展字节，movz系列传送零扩展字节，push和pop分别压栈和出栈。需要注意的是，传送指令的两个操作数不能都为存储器。

栈是一种特殊的数组，遵循先入后出原则，但由于其和一般数据的存储本质上并无不同之处，所以还是也可以使用一般的寻址方式访问其中的任意元素。

C中的间接引用运算符*可以将一个指针指向地址的值取出放入一个局部变量之内，这和取地址操作符&相反，后者返回一个变量的地址，而*p=x这种形式则是指针间接引用形式，它把x复制到x指向的位置。

C中的局部变量一般保存在寄存器中，访问起来比在存储器中要快得多。

算术和操作逻辑

算术像是加减乘除移位这些操作大多都可以对应汇编里的一条单独指令，比如ADD S, D就是将S+D的结果放到D中，INC D就是将D中的数据自加1等。

除此之外，还有leal指令，即加载有效地址指令，是movl指令的变形，它可以看做是普通计算，lea 7(%edx, %edx, 4)， %eax表示将%eax中的值设定为5x+7，括号中三个操作数记为x1、x2、x3则表示x1 + x2 * x3。此指令最大的好处在于他不通过ALU，可以单周期进行计算，效率极高。

移位操作SAR、SHR等的源操作数是立即数或cl寄存器中的数，并且范围在0~31，功用基本和C中的一一对应。

对于乘除法，除了提供截断到32位的乘除法之外，IA32指令集同样提供mull、imull这样的存储64位结果的无符号或者有符号指令，分别有单操作数和双操作数。对于单操作数，其中一个参数在%eax中，对于乘法，结果高位存储在%edx、地位存储到%eax；对于除法，商在%eax，余数在%edx。还有像是cltd这种指令，设置除数，将%eax符号扩展到%edx。

习题

所有有代码的练习都以以题号为名字的单个文件内。

代码位于CSAPP-Chapter3内。

1

基础，略过。

2

movl
movw
movb
movb
pushl
movw
popl

3

%bl不能作为存储器地址
应该使用movw
源操作数和目的操作数不应该都为存储器地址
寄存器sh不存在
不能将立即数作为目的操作数
指令和目的寄存器的大小不符
应该是movw

4

基础，略过。

只要认清8bitsyongal，符号扩展用movs等即可。

5

这段汇编代码本质上是将xp的内容复制到yp，yp的内容复制到zp，zp的内容复制到xp。

void decode1(int *xp, int *yp, int *zp*){
    int x, y, z;
    *yp = x;
    *zp = y;
    *xp = z;
}

6

x + 6
x + y
x + 4y
9x + 7
4y + 10
x + 2y + 9

7

基本操作，略过。

8

movl 8(%ebp), %eax
sal $2, %eax
movl 12(%ebp), %ecx
sar %cl, %eax

9

int arith(int x, int y, int z){
    int t1 = y;
    int t2 = t1 ^ x;
    int t3 = !(t2 >> 3);
    int t4 = z - t3;
    return t4;
}

10

A. 两个相同的数异或，结果恒为0，本质上是将%edx寄存器置零
B. 更直接的操作是movl $0, %ebx
C. xorl版本只需要2个字节，mov版本需要5个

11

将cltd指令替换为mov $0, %edx，并且将idivl替换为divl即可。

12

A. 这显然是64位数的运算并且第四行使用的是无符号运算，所以num_t是unsigned long long类型。
B. 首先将x和yh相乘，结果记为s，sl存入%ecx，而后将x与yl相乘得t，th存入%edx，tl存入%eax，而后将s和th相加得到的r存入%edx，最后将 $dest=2^{32}tl + r$ 。

【CSAPP】笔记-Cp2-2-数的表示与运算

dtysky — Wednesday, 22 Jun 2016 21:00:00 -00:00

CSAPP（深入理解计算机系统）第二章“信息的表示和处理”第二部分“数的表示与运算”的笔记和课后习题。
Github的同步工程在这

整形

整形数据顾名思义，是指整数，整数在计算机中的表示是精确的，也是有限的。一般而言，如果一个整数的位宽为w，则其表示的无符号整数所能表示数的范围为 $0 \sim 2^w-1$ ，而有符号整数则能表示 $-2^{w/2} \sim 2^{w/2}-1$ 。比如，对于一个32位的系统，其int型有符号整数的位宽是32，所以其范围是-2147483648 ~ 2147483647。

C中的整形数据类型一般有char、short、int、long、long long，位宽逐级递增，具体位宽取决于系统，在这些类型前加上unsigned便可以定义一个无符号数。

再次声明注意，在依赖于通信的应用中，字节序和位宽的匹配是特别重要的，如果可以，尽量使用c++中的stdint中的类型，或者自己定义一些uint_8t之类的类型。

编码

整数的编码可以区分为有符号和无符号两种，无符号编码整数对应的值即为其二进制对应的值，无需多言。有符号编码整数对应的值，一般是其二进制对应的补码。
补码是一种表示有符号数的编码形式，对于一个n位的有符号数A，其最高位为符号位，为1表示负数，为0表示正数，其他位为数值位。当A为正数时，数值位对应的二进制数即为A所代表的值，比如0111所代表的有符号数为7；A为负数时，数值位对应的二进制数的补码加上负号为A的值，比如1111表示-1。其计算规则为：

A的补码 = A的取反加1。比如当A = 111时，其补码为000 + 1 = 001。

当然，这并非最简单和最原始的算法，书中给出的方法是，对于有符号数A = abcd，其中abcd均为0或者1：

$$A = -a*2^3 + b*2^2 + c*2 + d $$

除了补码之外，有符号数的表示方式还有反码和原码，反码即为补码减1，而原码即为将数值位直接作为其绝对值的负数。在整数的表示形式中，这二者除了在某些底层硬件应用外并不常用，不再过多讨论。需要注意的是这二者的0都有+0和-0两种形式。

补码的英文为Two's complement，反码为Ones' complement。我们可以用 $2^w - x$ 来计算一个位宽w并且原码为x的数的补码，可以用 $2^w\{1\} - x$ 来计算其反码。

转换

C中有符号数和无符号的转换在不同基础的计算机上不同，但都遵循同样的原则——不改变其最底层的字节本身，而只是改变解释的方式。这样会导致这种转换出现反直觉的结果，比如下面代码：

int x = -111;
unsigned int y = (unsigned int)x;
printf("%u", y);

输出为4294967185。

通过以上定义，不难推出一系列的所谓补码和无符号数转换公式，但目测作用不大。

在C中

转换

C中的基础数据类型转换可以显示进行，也可以隐式进行。前者表现为float y = (float) x;这样的语句，其中x是int型变量；后者的表现则丰富的多，有float y = x;这种，也有在格式化输出时的printf("%u", x);这种，他会把int型变量x转换为无符号数输出。

在运算中，如果一个数是有符号而另一个为无符号的，则有符号数会被隐式转换为无符号数，这体现在加减乘除个各种比较运算中，比如：

int x = -1;
unsigned int y = 0;
printf("%d", x < y);

得到的结果是0，即false，因为此时x被当做无符号数处理了，是一个很大的正数。

在标准库文件limits.h中定义了int的最大和最小值，其中：

#define INT_MIN (-INT_MAX - 1)

这是由于一些比较隐晦的原因。

扩展和截断

数的位扩展一般发生在不同字长的整数的转换时，例如当一个整数从char型转换为int型时，就需要将8bits的数转换为32bits（在32bits的系统下）。对于无符号数，直接将低八位保留，高八位补零即可，但对于有符号数，则需要根据符号位的情况选择补零还是补一。

数的截断类似于扩展，不过与后者相反。截断在位级对于有符号数和无符号数都是相同的，都是高位裁剪，但结果还保留着原先的性质，无需多说。

一个利用符号数的漏洞

C中，memcpy函数将一块内存从一个地址拷贝到另一个地址，这个函数有一个参数n，表示要拷贝内存的长度，n的类型是size_t，是一个无符号数。如果给n赋予一个有符号的负数，将会导致被复制的内存大小改变，这显然会导致一些意外的结果。

这个现象导致了曾经FreeBSD中getpeername函数的漏洞。

一般而言，高级语言都尽量避免无符号数直接被程序员操作。这也是为了防止错误。

整数运算

计算机中的整数运算本质上和数学上的整数运算等价，但由于计算机中数值的有限性，所以可能会出现一些反直觉的现象。

无符号加法

无符号加法最大的一个问题就是溢出，虽然在Lisp系等语言中无限精度的运算是可能的，但像是C系的语言，运算还是有限精度的，这就会出现溢出问题。比如两个32bits的数进行运算，运算结果超过了32bits，这就造成了一次溢出。

对于有限精度的等宽w位无符号整数，其加法本质上等于两个数的算术和对 $2^w$ 取模，这表现为对溢出位w+1的舍弃。比如两个四位整数9和16，其算术和为25，二进制表示为11001，将最高为舍弃后为1001，即9 = 25 % 16。

补码加法

有符号加法在此处指补码的加法，其最大的问题同样是溢出。对于一个两个w位的补码有符号数相加，当其和sum正向超出w位可表示的补码有符号数范围时，会发生正溢出，最终结果为 $sum - 2^w$ ；反之，当逆向超过时发生负溢出，最终结果为 $sum + 2^w$ 。

补码的非

补码的非由于INT_MIN的存在变得有点奇怪，对于不等于INT_MIN的数，其取反就是自己的相反数，反之就是其自身。

无符号乘法

无符号乘法就是加法的叠加，对于两个w位的补码有符号数x和y，其乘法本质为：

x * y = (x * y) % $2^w$

补码乘法

补码乘法在位级上与无符号乘法完全一致，截断也一样，只是在最后的解释上有所不同。

乘以常数

一种常用的优化，可以将乘法拆为左移和加减法的组合来提高性能。比如：

y = x * 3 = x * 1 + x * 2 = x + x << 2

2的幂的除法

和常数乘法类似，常数除法也可以拆分，不过拆分到的是右移运算。在正整数除法的前提下，无论是算术还是逻辑右移1位和除以2是等价的，虽然在除不尽的情况下，结果应该是一个小数，但在整数除法中定义将商+余数这种结果中的商，也就是小数结果的向下舍入后的舍入值作为最终结果。
而对于负数，则应当是向上舍入 ，并不和算术右移等价。修正的方法是：

$$\lceil x/y \rceil = \lfloor (x+y-1)/y \rfloor$$

本质上，无论对于正数还是负数，原则都是向零舍入。它们在计算时唯一的区别是如何构造那个偏置值是y-1还是0。详见习题42的解答。

浮点数

浮点数是计算机内部采用的用于表示实数的系统，他可以表示整形无法表示的小数部分，当然，在某些特殊领域中也常用定点数，但浮点数还是最一般的。但理解定点数仍然对理解浮点数有着不小的好处。

定点数

首先考虑十进制实数的表达，一个拥有m位整数位和n为小数位的实数，其本质上是：

$$x = \sum_{i=0}^ma_i10^i + \sum_{i=n}^0a_i10^i$$

二进制也类似，为：

$$x = \sum_{i=0}^ma_i2^i + \sum_{i=n}^0a_i2^i$$

在实数的表示中，我们用.这个符号来分隔整数和小数部分，成为点。在计算机中，一个数的位宽确定的情况下，当点的位置固定时，我们就称这个数为定点数，以下便是一个4位整数4位小数的二进制定点数：

整数	点	小数
0101	.	1000

它代表的数为5.5。

需要注意的是，计算机中除了整形和部分小数之外，很多数都是不精确的，这其实相当于十进制中有理数和无理数。

IEEE浮点表示

IEEE浮点表示规则是一种当前几乎所有计算机遵循的通用标准，它规定一个浮点数的构造如下：

$$(-1)^s * M * 2^e$$

其中，s为符号，M为尾数，是一个二进制小数，E为阶码，其作用为对浮点数加权，可以为负数。我们可以很清晰看到，这实际上是一种科学计数法。下表表示了一个32位浮点数：

31	30~23	22~0
s	exp	frac

其中s为符号位，exp为为模式或者阶码，frac为尾数，通过设置exp可以将浮点数设为几种不同的模式：

规格化的值

exp各位不全为0或1时，为规格化的值。此时，阶码被解释为一个以偏置形式表示的有符号整数，为阶码E=exp-Bias，exp被作为无符号整数，而Bias为exp位数减1所能代表的最大有符号数减1。同时，此时frac被作为一个整数位为0的小数的小数位，尾数为frac+1，即将整数位替换为1，这种方式被称作隐含的以1开头的表示。于是，此时的数为：

$$x = (-1)^s * (1 + frac) * 2^{exp - Bias}$$

非规格化的值

这种格式的一个作用是表示0，exp和frac全为0时，当s为0时，表示数+0.0，s为1时，表示数-0.0。

另一个作用是表示非常接近于0的数，此时exp仍然为0，但是frac却不一定，这提供了一种叫做逐渐溢出的属性。此时的E=1 - Bias，M=frac，使得从最小规格数到最大非规格数的平滑过渡。

特殊值

当exp各位全为1时，表示特殊值。若frac全为0，得到的值表示无穷，s为0为正无穷，否则为负无穷。若frac不为0，则值为NaN，这表示运算结果不是一个实数或者无穷值。

为何如此设计

一切设计都是为了平滑、方便。比如如果将浮点数解释为无符号整数，会发现在浮点数自身升序排列时，此整数也是升序的，它们有着一致性，这意味着可以用一套排序解决两个问题。

舍入

由于浮点数无法准确表示很多数字，所以舍入就显得有些重要，IEEE浮点格式规定了四种不同的摄入方式，分别为向偶数舍入、向上舍入、向下舍入、向零舍入四种。

后三种已经在前面的有符号乘法探讨过，看似最符合直觉，但实际上浮点数中默认使用的却是向偶数舍入。对于一个二进制数，最低位为1则为奇数，否则为偶数。
当XXX...YYY...Y100这种形式时，向偶数舍入才有效，我们总是倾向于让最低位为0。

运算

浮点数运算基本上可以看做是两个浮点数精确运算后的舍入解，但考虑到浮点数种有规格外和特殊的值（Nan、inf等），所以运算并非总是可以这么去做。
由于舍入的存在，浮点数运算也不具备结合性。例如，对于0.000001 + 1000000 - 1000000和0.000001 + (1000000 - 1000000)，其结果就完全不同，前一个式子在第一运算中由于舍入会将0.000001丢失。

C中的浮点数

在C中，浮点数有float个double两种类型，前者单精度，32bits，后者双精度，64bits。但由于C中不要求机器使用IEEE标准，所以对于特殊值，并没有标准要求，不同编译器定义不同。

需要注意的是强制类型转换的时候，会发生许多期望之外的状况：

int转为float或者double时不会溢出但可能舍入，double转为float时可能发生溢出为正负无穷的状况，double和float到int时发生向零舍入。

习题

所有有代码的练习都以以题号为名字的单个文件内。

代码位于CSAPP-Chapter2内。

17

基础计算，略过。

18

A: 0b0000000110111000 = 440
B: 0b0000000000010100 = 20
C: 0b1111111001011000 = - (0b0000000110100111 + 1) = -424
......

19

将十进制的二进制补码表示按照二进制无符号数解释即可。

20

比如对于-8，其补码为1000，位宽w = 4，所以，补码转换为无符号数的结果为 $-8 + 2^4 = 8$ ，结果和直接将二进制解释为无符号数时一致。

21

只需要注意有符号数和无符号是在计算式会被隐式转换为无符号数即可。

22

对于A：

$$x = -1 * 2^3 + 1 * 2 + 1 * 1 = -5$$

对于其他也一样。

23

fun1先对word左移24位，再逻辑右移24位，之后转换为有符号数。
fun2先将word转换为有符号数，之后左移24位，再算术右移24位。

w	fun1(2)	fun2(w)
0x00000076	0x00000076	0x00000076
0x87654321	0x00000021	0x00000021
0x000000c9	0x000000c9	0xffffffc9
0xedcba987	0x00000087	0xffffff87

24

位级去掉最高位，将剩余解释为有符号或者无符号数即可。

25

详见代码。

当数组长度为0时，由于length为无符号数，所以length - 1语句将得到一个无符号数的结果，在32bits的机器上，此结果为0xffffffff对应的无符号数，是一个很大的正数。所以在循环时，会有数组越界发生，即访问未初始化的存储区域，发生错误。

将i <= length - 1改为i < length可破。

26

详见代码。

size_t为无符号数，s与t的长度的相减也会的到一个无符号结果，这使得改结果与0相比较大或相等，无法得到正确结果。
将相减后与0比较直接改为两个长度相比较即可。

27

比较x + y 和 x（或y）的大小即可。

28

套公式，略过。

29

基础计算，略过。

30

详见代码。

溢出只有可能在x和y同号时出现，都为正时可能发生正溢出，即最终和为负，都为负时则可能发生负溢出，即和最终为正。

31

溢出是可逆的，即便sum溢出了，但sum - x = y却还是成立的。

32

因为补码的值域不是关于y轴对称的，所以当y为INT_MIN时，-y会直接发生溢出，变为y，此时如果x为0，题目所示的函数将不会认为溢出，但实际上已经溢出了。

在原先的代码加一个分支即可。

33

0xF的补码是其自身，其他都是相反数。

34

基础运算，略过。

35

1

$$B2T_{2w}(x) = -x_{2w-1} 2^{2w-1} + x_{2w-2} 2^{2w-2} + ... + x_w * 2^2 + \sum_{i=0}^{w-1}x_i2^i$$

$$=2^w({-x_{2w-1} 2^{w-1} + x_{2w-2} 2^{w-2} + ... + x_w}) + \sum_{i=0}^{w-1}x_i2^i$$

$$=2^w({-x_{2w-1} 2^{w-1} + \sum_{i=0}^{w-2} x_i2^i}) + \sum_{i=0}^{w-1}x_i2^i$$

$$=2^wv + u$$

已知有符号和无符号乘法在位形式上一致，令上述公式的x=x*y，其中p是乘积x*y在w位时的补码形式，则有：

$$u=p_{w-1}2^w+p$$

于是有：

$$x*y = 2^w(v+p_{w-1})+p$$

令 $t = v+p_{w-1}$ 则：

$$x*y = t2^w+p$$

即证。

2

由于p是一个整数，所以其总是可以被分解为一个非零整数、商和余数的和，即：

$$p = xq + r$$

即证。

3

令q=y，则有：

$$p = xy + r$$

而 $p=xy-t2^w$ ，固有：

$$r=-t2^w$$

由于r的绝对值小于x的绝对值，而x又是一个补码，所以x的最大值为 $2^w$ ，同时t为一个大于等于1的数，所以要使此等式成立，r和t都必须为0，即证。

36

详见代码。

37

改进是这段代码的乘法计算部分不再溢出，但由于malloc的最后一个参数是size_t，所以还是存在问题的。

解决方法就是将相乘的两个数都声明为int型，这样它们都为正数时，相乘放入一个size_t中时便不会溢出。
而实际上，这两个值的确都是正数。

38

b为0时，可以计算1、2、3、8倍，为a时，可以计算2、3、5、9倍。

39

$$(2^{n+1} - 2^m)x = 2^m(2^{n+1-m}-1)x$$

即：

((x << n+1-m) - x) << m

40

x << 3 - x << 1

x << 5 - x

x << 1 - x << 3

y = x << 2 + x; y << 1 + y << 3

41

如果n有可能超过位宽，选A。
否则，选B。

42

详见代码。

可以使用31位的符号右移确定x是正数或者负数，而后使用mask得到合适的偏置，最后直接根据公式求解。

43

$$M = 2^6 - 1$$

$$N = 2^3$$

44

要使该式为假则必须要找到整数x，使得x-1>=0且x<=0，这样的x在C中是存在的，即x=INT_MIN，减1运算后会发生溢出。
若x&7为7则x的低三位全为1，而x<<29大于0则x的倒数第3位为0，这样的x不存在，所以原式必然为真。
当结果会溢出的时候，原式便可能为假。
事实上，整数x如果不是负数就是0要么就是正数，并且原式没有特别的边界情况，恒成立。
与4基本一致，但当x=INT_MIN的时候，-x由于溢出仍然为x=INT_MAX,还是为负，这可以使得原式为假。
恒成立，C中，当无符号数和有符号数做运算时，会把有符号数转为无符号数，而有符号数和无符号数在位级上运算又是等价的。
-y=~y+1 -> ~y=-y-1，所以这个式子本质上和6中的一致，原式成立。

45

基础运算，略过。

46

A. 为0.{23个0}1100110011001100.......

B. 为$\sum_{i=-\inf}^{-24}a_i2^i$，其中，当i % 4 == 0 or 1时， $a_i=1$ ，否则为0。求和如下：

$$sum = 2^{-24} + 2^{-25} + 2^{-28} + 2^{-29} + ......$$

$$=2^{-24}(1 + 1/2) + 2^{-28}(1 + 1/2) + ......$$

$$=3 * 2^{-25} * (1 + 2^{-4} + ......)$$

$$=1/(2^{20} * 10) \approx 9.53 * 10^{-8}$$

C. 约为 $9.53 * 10^{-8} * 36000 = 0.034$秒。

D. 约为0.034 * 2000 = 68米。

47

基础计算，略过。

48

整形数的二进制表示为00000000001 101011001000101000001。
浮点数的二进制表示为0 10010100 10101100100010100000100。

浮点数的s = 1，exp = 148 -> e = 148 - 127 = 21，frac = 0.6739811897277832 -> M = 1.6739811897277832。

通过上面对比可见，整形表示的最后21位和浮点数frac中的前21位是一致的。

49

$$min = 2^{n + 1} + 1$$

$$2^24 + 1 = 16777217$$

50

基本计算，略过。

51

A. 由于末尾0后两个1，原数加1舍入更为合理，即x' = 0.00011001100110011001101。

B. 为 $\sum_{i=-\inf}^{-24}a_i2^i$ ，其中，当i % 4 == 0 or 1时， $a_i=0$ ，否则为1。求和如下：

$$sum = 2^{-26} + 2^{-27} + 2^{-30} + 2^{-31} + ......$$

$$=2^{-26}(1 + 1/2) + 2^{-28}(1 + 1/2) + ......$$

$$=3 * 2^{-27} * (1 + 2^{-4} + ......)$$

$$=1/(2^{22} * 10) \approx 2.38 * 10^{-8}$$

C. 约为0.0008秒。

D. 约为1.71米。

52

基础计算，略过。

53

假设1e400溢出位正无穷，则有：

POS_INFINITY = 1e400
NEG_INFINITY = -POS_INFINITY
NEG_ZERO = -1.0 / POS_INFINITY

54

A. 真，int到double的转换不会有任何精度损失，而转回时不会发生舍入。
B. x为INT_MAX时会发生溢出。
C. d超过了float的范围数会发生舍入。
D. 真，float到double的转换不会有任何精度损失，而转回时不会发生舍入。
E. 真，浮点数取反只影响符号位。
F. 真，整形和浮点数计算是会被转换为浮点数。
G. 真，即便d*d发生了溢出到正无穷，但规则保证此不等式成立。
H. 当f远大于d时，会发生舍入。

【Python】内建函数

dtysky — Wednesday, 08 Jun 2016 17:00:00 -00:00

Python中一些很有用的内建函数，包括zip、类型转换、反射等。

zip

zip函数用于改变数据的构造，它将会返回一个元组，元组的构造视传入的参数而定，在一般的应用中，一般会传入几个长度相等的可迭代量，比如列表。

例子：

test = zip([1, 2, 3], [3, 2, 1], [2, 1, 3])
print test

输出为：

[(1, 3, 2), (2, 2, 1), (3, 1, 3)]

可见，zip本质上是将三个列表进行了某种合并。

那么如何将已经被合并的三个列表还原呢？

加上不定参数符号*即可，如以下代码，其本质上是将test中的三个元组作为参数传入：

print zip(*test)

输出为：

[(1, 2, 3), (3, 2, 1), (2, 1, 3)]

bin/hex/oct/chr/str

一组相似的函数，可以将一个数组转换为某种进制下的字符串：

x = 0x40
print bin(x)
print hex(x)
print oct(x)
print chr(x)

分别输出：

bin为二进制： '0b1000000' hex为十六进制： '0x40'
oct为八进制： '0100'
chr为ascii码： '@'

当不在ascii码范围内时，chr输出和hex一致。

str函数将任意数据类型转换为字符串：

print str([1, 2, 3])

输出为[1, 2, 3]。

ord/int/float

ord和int、float函数的功能皆为数据类型转换，不过三者对象有所不同。

ord是chr的逆函数，将一个ascii码还原为整形数字：

print ord("@")

输出是40。

int可以看作是bin、hex和oct等的逆函数，其形式为int(c, base)，第一个参数是字符，第二个是数的基，一般是2（十六进制）、8（八进制）、10（十进制）以及16（十六进制），默认是十进制。

print int("10") # 10
print int("10", 2) # 2
print int("10", 16) # 15
print int("10", 8) # 8

当然，int函数也有数字类型转换的功能，它可以将浮点等类型等转换为整形：

print int(1.1) # 1
print int(1.9) # 1

可见，int对于浮点数的转换使用的是向下取整。

float函数接受形式为小数的字符串或者整形等：

print float("1.1") # 1.1
print float(1) # 1.0

isinstance/issubclass/dir/getattr/type

Python的反射特性，详见此处：

【Python】反射

eval/execfile

这两个函数本质上是一回事，不过一个参数是字符串，一个是文件。execfile可以看做是将文件的文本完整读入后传入eval函数执行。

eval函数是一种高级特性，它将文本解析后作为python的表达式执行：

x = 1
eval("x += 1")
print x

输出是2，可见x += 1作为表达式被执行了。

map/filter

这两个函数都针对可迭代量，比如元组和列表。
要注意可迭代量iterable和迭代器iterators是不同的东西。这两个可能会在后面的文章说到。

map函数的参数是一个可迭代量I和一个函数F，调用时，L中的元素Li被逐个取出，送入F中，F需要返回处理后的值Lia，然后Li将会被Lia替换。

x = [1, 2, 3]
def inc(x):
    return x + 1
print map(inc, x)

结果是[2, 3, 4]。

filter函数顾名思义，是一个滤波器，他的参数和map函数一致，不过函数F的返回值是一个bool量，表示是否要保留该元素，如果为True则会保留。filter返回的是一个被筛选过的数组：

x = [1, 2, 3]
def odd(x):
    return x & 2 == 1
print filter(odd, x)

结果是[1, 3]。

open/file

属于文件操作的一部分，后面开文章单写。

sorted/reversed

该函数用于排序，比较复杂，以后开文章单写。

abs/max/min/pow/divmod/round/sum

一些运算。

abs对数字取绝对值： abs(-1) = 1。
max/min对列表或者元组取最大/最小值： max([1, 2, 3]) = 3，min([1, 2, 3]) = 1，这两个函数和sorted函数一样，也可以自定义排序规则。
pow是乘方： pow(2, 3) = 8。
divmod返回两个参数的商和余： divmod(3, 2) = (1, 1)。
round是取整，采用四舍五入： round(1.4) = 1.0，round(1.5) = 2.0。
sum是求和： sum([1, 2, 3]) = 6，sum(1, 2, 3) = 6。

range/xrange

range生成一个列表：

print range(1, 4)

输出[1, 2, 3]。

xrange生成一个xrange对象：

print xrange(1, 4)

输出xrange(1, 4)。

二者皆可用于循环，以for i in xrange(1, 10)类似的形式，但是xrange对大规模循环的支持更好，效率也更高。

input/raw_input

这两个函数用于读取控制台输入，将开文章单写。

【CSAPP】笔记-Cp2-1-信息存储

dtysky — Wednesday, 08 Jun 2016 12:00:00 -00:00

CSAPP（深入理解计算机系统）第二章“信息的表示和处理”第一部分“信息存储”的笔记和课后习题。
Github的同步工程在这

计算机本质上是开关电路，底层就是MOSFET等的打开、关断和饱和为基础所构成的一系列变化，“开”和“关”可以抽象为0和1两种状态，计算机中的一切都是有0和1构成的，信息的存储也不例外。

信息在计算机中以0和1的系列表示，再高一点就是bytes序列，不过没有本质区别。单纯的0、1序列没有任何意义，意义是我们所赋予的，我们人为地定义一些数据类型，再通过这种定义01序列转义，便可以使它们表现出具体的含义。

比如，1111这个二进制数，如果是无符号整形，它代表15，如果是有符号整形，则是-1，如果是定点位为3的定点数，则是7.5。
同时，这种由4个bit构成的一个数，其值域为0~15，是一个十六进制数，十六进制数在计算机中十分重要。

一般来讲，有符号数用补码表示，小数由浮点数表示，不过在一些特殊的领域，比如FPGA，定点数使用地更为广泛，定点化问题也是值得关注的。

原始数据类型

和代数定义基本相同，可以分为：

整数：有符号整数和无符号整数，在C中，可以按照位宽分为很多类型，有8bits的char，有32bits的int，也有64bits的int等，但它们都遵循一个规则。

小数：在计算机软件中，小数都是有符号的，也可以根据位数进行划分，在C中，有32bits的float，有64bits的double等。

注：在C中，指针本身定义为一个全字长的变量。其它详见下面几节。

溢出和误差

溢出是指——运算结果的大小超越了该类型的数所能表示的最大值。比如对于一个无符号char型变量，如果给他赋予一个超过255的值，则发生了溢出，结果会被截断（当然有的编译器会发现这个错误）。

误差则是指浮点数和定点数系统的有限，对于整数，总是存在一个二进制数可以作为十进制数的对应，但对于小数或者分数则并非如此，例如0.2这个数，你就无法找到一个二进制的数来表达他，只可能在有限的精度下非常接近它。

总而言之，整数在计算机中是有限但精确的，而小数是无限却近似的。

指针

指针提供了引用数据结构的元素的机制，它指向某个存储块的第一个字节的虚拟地址。
指针包含一个值和一个类型，值就是指向对象的地址，而类型则是对象的类型。

在C中，用T *p定义一个名为p的指针，T可以使任意基本的数据类型，用p可以获取p的首字节地址，*p可以直接获取该变量。而使用&可以获取任何一个变量的首字节地址，它返回一个指针变量，如果定义的是一个int型指针变量，那么p指向的对象实际占据的地址空间就是p、p+1、p+2和p+3。
根据不同的系统，这四个字节的排序各有不同。低字节在前的称为小端LE，反之则为大端BE，这可能是一个坑，要注意。

比如&p=0x100，则同时p指向的对象为int型，表示0x01234567，则： 1. 大端表示，0x100 ~ 0x103地址分别为 0x01 ~ 0x67。 2. 小端表示，0x100 ~ 0x103地址分别为 0x67 ~ 0x01。

一般来说，x86 系列 CPU 都是 little-endian 的字节序，PowerPC 通常是 big-endian，网络字节顺序也是 big-endian还有的CPU 能通过跳线来设置 CPU 工作于 Little endian 还是 Big endian 模式。

指针的引用可以用数组表示法来表示，比如对于int *p，p[1]取得是&p后1*4个字节开始的int型变量，和数组的使用十分相似。指针的只允许被赋值指针型变量，也就是一个&返回的一个变量的地址或者由*定义的数据。

char *p;
char i = 10;
p = &i;
printf("%d", p[0]);
printf("%d", *p);

结果都是10。

强制类型转换

cast，强制类型转换，可以将一个类型的数据以另一种类型的形式表现出来。在系统编程中极为重要。

void show_as_float(int p){
    printf("%f", (float) p);
}

位宽

处理器位宽决定了虚拟存储器的寻址范围，n位的寻址范围是 2ⁿ。

sizeof(T)函数可以给出当前系统中，类型T占据的字节数。由于不同系统对各种基本类型赋予的位宽可能不同，为了避免麻烦，在c++中应尽量使用stdint包中的uint_8t等类型。

字符串

字符串也是对二进制流的一种编码，它被编码为一个以null(值为0)字符结尾的字符(char)数组。每个字符都需要指定编码，常见的为ASCII码，当然，多用unicode，善待程序员（对Python我就是在说你）。

逻辑运算与位运算

逻辑运算是布尔代数中的一部分，基本包括与预算、或运算、非运算、异或运算，可以用于进行一些基本的逻辑运算。这也是数字电路的基础，其实很简单。
逻辑运算也有各种运算定律、化简方法（卡诺图）等，可以自行研究。

一般的，在软件中，逻辑运算通常有两种，单目运算&等和双目运算&&等，前者是位运算，返回原始类型的值，后者是逻辑运算，返回逻辑值。所以单目运算符常常可以被用于位屏蔽和掩码等，比如0xff & 0x0f就屏蔽了前者的前四位。

除以上，还有一种位相关的操作，被称为移位操作，移位操作一般分为逻辑移位（无符号扩展）和算数移位（有符号扩展），也有被称为循环移位的存在但不在此讨论。移位即将一个二进制数的所有位向左或向右平移若干位，他可以用于替换一些特殊的乘除法，速度快很多。比如除以二可以用左移两位表示。

需要注意的是，在C中，如果移动的位数超过了字长w，可能会造成类似循环移位的异常状况，所以要尽量避免。

一般情况下，加减乘除逻辑运算位运算移位操作都可以直接对应为CPU的一条指令。

习题

所有有代码的练习都以以题号为名字的单个文件内。

代码位于CSAPP-Chapter2内。

1，2，3，4，

略过。

5

A：
BE -> 0x87
LE -> 0x21

B:
BE -> 0x8765
LE -> 0x2143

C:
BE -> 0x876543
LE -> 0x214365

6

这实际上是浮点数和整形的模型问题，略过。

7

为各个字符对应的ascii码，略过。

8

基本逻辑运算，略过。

9

颜色的补就是把每一位取反，B是基本逻辑运算，略过。

10

异或运算满足自反率：

$$A \oplus A \oplus B = B$$
$$A \oplus B \oplus B = A$$

步骤	*x	*y
初始	a	b
1	a	a ^ b
2	b	a ^ b
3	b	a

11

原来函数只能对偶数个数元素的数组工作，是因为对于奇数个数元素的数组，会出现first = last的状况，这种状况下实际上是数组中间的元素自己和自己做运算，即inplace(&a[first], &a[first])，此运算将返回0。
返回0是因为以上三步运算中，步骤1使得a = a, b = 0，步骤2使得a = a, b = a，步骤3使得a = a, b = 0，由于inplace函数的两个参数指向同一个元素，所以对b赋值的结果会覆盖对a的赋值，所以结果为0。
如何改动请见代码，将奇数作为特殊情况即可，也就是，将first <= last改为first < last。

12

// A
x & 0x000000ff
// B
x ^ 0xffffff00
// C
x | 0x000000ff

13

本质上：

bis(x, y) = or(x, y)
bic(x, y) = and(x, ~y)

int bool_or(int x, int y){
    return bis(x, y);
}

可以用逻辑代数通过or求得xor：

xor(x, y) = or(and(x, ~y), and(y, ~x))

int bool_xor(int x, int y){
    return bis(bic(x, y), bic(y, x));
}

14

基本运算，略过。

15

详见代码。

16

基本运算，略过。

【CSAPP】笔记-Cp1-计算机系统漫游

dtysky — Wednesday, 08 Jun 2016 11:00:00 -00:00

CSAPP（深入理解计算机系统）第一章“计算机系统漫游”的笔记和课后习题。
Github的同步工程在这

编译系统

步骤

一次编译分为以下步骤：

预处理cpp：根据#开头的命令修改和注入代码，处理完的代码一般为“.i”文件。

编译ccl：将“.i”文件翻译成文本“.s”文件，里面是汇编代码。

汇编as：将汇编代码翻译成机器语言，保存在“.o”文件中。

连接ld：将某些预编译好的代码合并到目标程序中，比如标准库中的一些函数，最终得到可执行文件。

CNU项目

GNU's Not Unix。
开发出一个完整的类unix系统，内核是linux。包括EMACS、GCC、GDB、汇编器、连接器等等，GCC支持许多种编译型语言。

系统硬件

构成

CPU、存储器（磁盘存储器算外设）和外设构成，现代中一般是CPU和存储器中由存储器总线连接，和外设则是IO总线，还有加速计算的GPU等。

学学HDL，写个简单的CPU可以加深理解，一个简单的CPU的例子，使用Verilog编写：

SIMPLE_MIPS_CPU

GPU一般由用于计算的ALU（包括加减乘除法器、逻辑运算单元），寄存器堆（特殊的高速存储器，存储特殊数据），控制译码单元（将机器码转译为各个模块的控制信号），指令存储器（存储代码数据），数据存储区（存储数据）以及连接各个模块的数据路径（指令地址计数器PC算一部分）。运行时，PC借由ALU的运算来使自己跳转，而后CPU取出PC指向的指令存储器中的数据作为指令送入控制译码单元，而后调动各模块执行操作。

运行开销

比如运行一个简单的打印字符串的程序，加载时，复制到主存（SDRAM），运行时，主存复制到CPU的寄存器堆中，显示时，又复制到显示设备，这些“复制”就是主要开销之一。

高速缓存

高速缓存是为了解决“复制”开销而构造的，它们由SRAM构成，容量介于寄存器堆和主存之间，速度也介于寄存器堆和主存之间。

一般来讲，会有一个CPU片上的L1缓存，容量高于寄存器堆但访问速度等同于寄存器堆，但速度高于主存两个数量级；L2缓存容量高于L1缓存，速度为L1的五分之一；一些系统拥有L3缓存。

高速缓存中会存放一些经常会使用到的指令，合理提高cache的命中率将会有效提高性能。（大概现在还有必要？）

操作系统

操作系统隔离了上层应用和底层硬件，它提供两个功能：

防止硬件被失控的应用程序滥用。

向应用程序提供简单一致的机制来控制复杂而多样的硬件设备。

简而言之，OS通过自身高度的复杂度对上层应用提供了简单而良好的抽象，使得程序员不需要关心乱七八糟的兼容问题，使得分工和高效率成为了可能。

这些抽象基本包括：

文件：对IO设备的抽象。

虚拟存储器：对主存和IO设备的抽象。

进程：对IO设备、主存和CPU的抽象。

进程

进程是操作系统对一个正在运行的程序的一种抽象。一个系统可以运行多个进程。
但本质上，一个CPU在同一个时刻只能执行一个进程，多进程的假象（或者说也并不完全是假象）是通过交叉执行实现的，这种交叉执行的流程如下：

正在执行A进程，发现需要切换到B进程。

保存A进程的状态（上下文），将执行控制权转移给B进程，执行B进程。

B进程执行一段时间，需要切换到A进程，保存B进程上下文，恢复A进程的上下文。

线程

线程是对进程的进一步分割，它们可以是同一进程中的若干执行单元，共享进程的上下文、代码和全局数据，所以一般也比多进程更加高效，也适合多并发场景。

虚拟存储器

虚拟存储器是一种抽象，它使得进程可以认为它们都是在独占地使用主存，即主存对于它们而言都是一致的。
虚拟存储器提供了一个抽象的虚拟地址空间，每一个地址段中存储器的内容都有着严格的定义，它们包括：

程序代码和数据：对所有进程，代码从同一固定地址开始，然后是数据。

堆：代码和数据区后就是运行时的堆，堆是可以动态改变大小的。

共享库：存储库。

栈：编译器使用它进行函数调用，也是可以动态改变大小的。

内核虚拟存储器：这是OS的一部分，为内核保留。

写几段汇编，调试调试可以加深理解。

文件

文件就是二进制序列，在类unix系统中，一切皆为文件，系统所有的输入输出都是抽象成文件读写来实现的。

通信

通信通过网络实习，网络也可以被视为一个IO设备。

一些重要概念

并发和并行

并发只一个系统同时具有多个活动，并行只用并发使得一个系统更快地运行。

线程级并发

在单处理器系统中，并发是通过多个进程的快速切换实现的。
一个处理器上如果拥有多个带有独立处理单元和高速缓存的处理器，则为多核处理器，它们共享更高层的高速缓存，但相互保持独立。
超线程，即让一个处理器可以“同时”执行多个线程。要注意的是，这个同时也并非真同时，这种处理器的某些硬件有多个备份，可以在单个周期级别去决定执行哪一个线程，这不同于常规的处理器——它们需要大约20000个时钟周期去做不同线程转换，所以基本可以看做是拥有可以同时执行两个线程的能力。

指令级并行

一个周期可以执行多个指令，这个理论效率可以通过一些不那么疯狂和疯狂、不那么玄学和玄学的技术达到。通常，这些手段包括“流水线”、“分支预测”等。
“超标量”这个术语指处理器可以比一个周期一个指令的速度更快。

单指令、多数据并行

允许一条指令产生多个可以并行执行的操作称为“单指令、多数据”，即SIMD并行。比如并行对多对浮点数做加法的特殊指令。
一般建议用特殊的数据类型来编写需要这些运算的程序，比如在GCC中的向量数据和SIMD优化配置。

【Python】二进制字节流处理库struct

dtysky — Monday, 06 Jun 2016 13:00:00 -00:00

struct类用于打包和解包二进制字节流，对于二进制数据的处理至关重要。

pack

pack方法用于将数据打包成字节流，数据可以是数字、字符串、数组，其使用方法为：

import struct
struct.pack(fmt, data)

fmt是格式化的格式，data为数据，fmt的规则为[order][format]，order为字节顺序，比如小端LE、大端BE等，format就是字节的格式了，可以是字节、整形、浮点数等，比如：

In[13]: struct.pack(">II", *[1, 2])
Out[13]: '\x00\x00\x00\x01\x00\x00\x00\x02'
In[14]: struct.pack("<II", *[1, 2])
Out[14]: '\x01\x00\x00\x00\x02\x00\x00\x00'

以下是详细规则：

字节顺序

Character	Byte order	Size	Alignment
@	native	native	native
=	native	standard	none
<	little-endian	standard	none
>	big-endian	standard	none
!	network (= big-endian)	standard	none

格式

Format	C Type	Python type	Standard size	Notes
x	pad byte	no value
c	char	string of length	1	1
b	signed char	integer	1	(3)
B	unsigned char	integer	1	(3)
?	_Bool	bool	1	(1)
h	short	integer	2	(3)
H	unsigned short	integer	2	(3)
i	int	integer	4	(3)
I	unsigned int	integer	4	(3)
l	long	integer	4	(3)
L	unsigned long	integer	4	(3)
q	long long	integer	8	(2), (3)
Q	unsigned long long	integer	8	(2), (3)
f	float	float	4	(4)
d	double	float	8	(4)
s	char[]	string
p	char[]	string
P	void *	integer		(5), (3)

注意

首先要注意的是大端小端的问题，这个在上面的例子已经有所体现，如果不加order标志，默认使用的是@这个order。
其次，使用时如果相对数组使用，必须要加上不定参数标志*。

unpack

用于解包二进制数据，基本和pack的用法一致，不过是逆运算，fmt的格式和pack一模一样，第二个参数为二进制字节流，返回一个由结果构成的元祖。

In[15]: struct.unpack("<II", '\x01\x00\x00\x00\x02\x00\x00\x00')
Out[15]: (1, 2)

效率

测试表明，打包和解包的性能的确会随着数据量的大小而发生变化。这个变化似乎并不是线性的，在一定数据量以下时，性能并不会成为瓶颈，但当数据量超过某个数量级时，性能会极速恶化，这一点需要注意。

【Python】科学绘图库Matplotlib

dtysky — Monday, 06 Jun 2016 11:00:00 -00:00

这是一个Python的科学绘图库的使用心得，涉及平面绘制、子图绘制、格点、三维(3D)绘制以及动态绘图。
http://matplotlib.org/

基本绘制

直接导入库后，提供数组进行绘制即可：

基础

import matplotlib.pyplot as plt
x = [1, 2, 3]
y = [1, 2, 3]
# 绘制线图
plt.plot(x, y, color, ...)
# 绘制散点图
plt.scatte()
plt.show()

还可以绘制别的图像，详见官网。

进阶

子图

可以添加多张子图进行绘制，并且修改图像的标题和坐标轴等：

plt.subplot(2, 2, 1)
plt.title("子图像1")
plt.subplot(2, 2, 2)
plt.title("子图像2")
plt.subplot(2, 2, 3)
plt.title("子图像3")
plt.subplot(2, 2, 4)
plt.title("子图像4")

面向对象

除了这种类似于matlab的用法，还可以用面向对象的用法来进行绘制：

import matplotlib.pyplot as plt
fig = plt.figure()
axi = fig.add_subplot(2, 2, 1)
axi.set_title("子图1")
axi.set_xlabel("x轴")
axi.set_ylabel("y轴")
ax.set_xlim(min(0, 10)
ax.set_ylim(0, 10)
......

细化分隔

也可以进一步细化控制每一个子图所占区域范围：

import matplotlib.gridspec as gridspec
gs = gridspec.GridSpec(2, 2)
fig = plt.figure(1, figsize=(16, 9), dpi=72)
fig.suptitle("Distance offset from start")
ax1 = fig.add_subplot(gs[:, 0])
ax1.set_title("Total")
ax1.set_xlabel("X(m)")
ax1.set_ylabel("Y(m)")
ax2 = fig.add_subplot(gs[0, 1])
ax2.set_title("X")
ax2.set_xlabel("t(s)")
ax2.set_ylabel("0m")
ax3 = fig.add_subplot(gs[1, 1])
ax3.set_title("Y")
ax3.set_xlabel("t(s)")
ax3.set_ylabel("0m")

这种情况下，第一张子图将占据第一行，第二张子图占据第二行的第一列，第三张则是第二行的第二列。

三维

三维图的绘制也是被支持的，只需要导入一个模块便可以在绘制的时候加上z轴的参数：

import matplotlib.pyplot as plt
from mpl_toolkits.mplot3d import Axes3D
fig = plt.figure(1, figsize=(16, 9), dpi=72)
ax1 = fig.add_subplot(1, 1, 1, projection="3d")
ax1.set_title("三维图")
ax1.set_xlabel("X")
ax1.set_ylabel("Y")
ax1.set_zlabel("Z")
ax1.scatter([1, 2, 3], [1, 2, 3], [1, 2, 3])

动画

动画也是被支持的，其核心在于一个模块和一个方法，以下是我常用的方案更详细可以看这里：

导入核心库和使用核心方法：

# 核心库
import matplotlib.animation as animation
# 生成动画对象
ani = animation.FuncAnimation(fig_p, draw_distances_run, draw_distances_data_gen, interval=200)

其中draw_distances_run方法是绘制每一帧更新时用于绘制的方法，draw_distances_data_gen方法用于在绘制中修改绘制数据，而interval参数则是一个毫秒的时间，是每两帧之间的间隔。那么如何具体的来使用呢？

我此处选择的是一个并非那么合理但是快速的方法，当然，其实外面用个类包起来其实就好，满足需求就行。。。

初始化数据

def draw_distances_start():
    fig = plt.figure(1, figsize=(16, 9), dpi=120)
    fig.suptitle("Distance offset from start")
    ax1 = fig.add_subplot(1, 1, 1, projection="3d")
    ax1.set_title("图1")
    ax1.set_xlabel("X")
    ax1.set_ylabel("Y")
    ax1.set_zlabel("Z")
    data1 = ax1.scatter([], [], [])
    return fig, ax1, data1
# 全局变量
fig, ax1, data1 = draw_distances_start()
data_now = ["x": [], "y": [], "z": []]
data_new = ["x": [], "y": [], "z": []]

更新数据

def draw_distances_data_gen():
    for key in data_now:
        data_now[key].extend(data_new[key])
    yield data_now

更新绘制

def draw_distances_run(d):
    x, y, z = d["x"], d["y"], d["z"]
    data1.set_offsets([(x[-1], y[-1])])
    data1.set_3d_properties([z[-1]], "z")
    ax1.set_xlim(min(x), max(x))
    ax1.set_ylim(min(y), max(y))
    ax1.set_zlim(min(z), max(z))
    return data1

注意，这里更新x和y用的是set_offsets方法，而更新z用的是set_3d_properties方法。

提供新数据

以上代码中，一个全局的data_now变量用于存储当前要绘制的数据，而data_new则是该帧的新数据。在实际使用中，为了防止卡顿，一般选择用一个新的线程来更新data_new的数据：

def refresh():
    while True:
        data_new = get_new_data()

thread.start_new(refresh, ())

一切准备就绪后，调用plt.show()即可开始绘制动画。

【UWB/室内定位】坑和结论

dtysky — Saturday, 30 Jan 2016 23:00:00 -00:00

年轻人，初入职场，没事不要给自己找坑。

继续深入研究，身心俱疲，这里是一些坑和结论。

1 坑和结论

这里所用UWB芯片皆为Decawave家的DW1000，分别使用TREK1000套件和某公司的产品进行了测试。
这里首先声明，DWM1000这个小模块基本只能拿来玩玩,想要做正事的可以直接跳过。

1.0 算法

TREK1000套件的定位算法基本是直接解算，产品则对原始的测距信息有限幅，定位输出有卡尔曼滤波。
以下Python随便写的用最小二乘法通过同一个平面的若干个基站和tag的距离求xy坐标的函数，比较糙，有兴趣自己看看吧：
函数输入是每个anchor的位置构成的数组,以及每个anchor和tag的距离序列构成的数组.

from scipy.optimize import leastsq, curve_fit
from numpy import sqrt, square, array, subtract, add, multiply
def get_xyz_by_ls(anchors, distances):
    def fun(ps, ds):
        res_x, res_y = ps
        anchors_x, anchors_y = ds
        res = add(
            add(multiply(2, multiply(anchors_x[0], res_x)), anchors_x[1]),
            add(multiply(2, multiply(anchors_y[0], res_y)), anchors_y[1]))
        return res

    def error(ps, ds, dis):
        return dis - fun(ps, ds)

    length = len(distances)
    ps = [
        [a[0] for a in anchors],
        [a[1] for a in anchors]
    ]
    # ps[0]: xi+1 - xi, xi+1 ^ 2 - xi ^ 2
    # ps[1]: yi+1 - yi, yi+1 ^ 2 - y1 ^ 2
    ps[0] = [
                 [ps[0][i] - ps[0][i+1] for i in xrange(length - 1)],
                 [square(ps[0][i+1]) - square(ps[0][i]) for i in xrange(length - 1)]
    ]
    ps[1] = [
                 [ps[1][i] - ps[1][i+1] for i in xrange(length - 1)],
                 [square(ps[1][i+1]) - square(ps[1][i]) for i in xrange(length - 1)]
    ]
    ps = array(ps)
    # ds: di+1 ^ 2 - di ^ 2
    ds = [square(distances[i+1]) - square(distances[i]) for i in xrange(length - 1)]
    x0 = [1, 1]
    x, y = leastsq(error, x0, args=(ps, ds))[0]
    return x, y

1.1 适用范围

UWB一般应用场合是室内定位，低空定位，动态性能要求不太高的定位。
定位原理在上一篇说过了，都是测距后用三边法或者多基站下的线性拟合。而测距使用的原理一般是TOF（飞行时间），这个和微波雷达、激光测距等基本是一个原理，所以也面临相同的问题。
定位对基站的布局是有需求的，基本要求tag不能越过anchor所框的区域内，同时基站的布置和定位要求密切相关，有几个维度的需求，基站就应该有几个维度的变化，如果要三维定位，一般要求至少一个基站在空中。

1.2 精度

精度方面，由于我们用于空中的水平定位，所以关心的是水平、也就是xy轴的精度，我分别进行了地面的静态测试和无人机上的动态测试，结论如下：

单对精度可以认为始终在15cm之内，但要求天线位置最佳，天线的坑会在下面说道。与此同时，两米之内的测距误差可能较大，这个是原理所决定的，暂时无解。

定位精度和基站围成的范围与tag到基站的距离都有着很大关系，一般要求需要定位的距离和基站围成的距离越接近越好。在13m x 6m的布局下，tag随着和基站绝对距离的增加，其定位精度会有所下降： 5-15m时，精度在20cm左右；15-25m时，精度在30cm左右；25-35m时，精度在40cm左右。

1.3 静态性能

静态性能指测距和定位可以达到的帧率，实测最高大概在三十多帧（产品），开发套件只有10帧左右（算法决定），不过对于一般应用也足够了。
在静态测试中，测距的定位均有一定的失效率，失效率大概在3%左右。失效率和tag到基站的距离密切相关，同时微波传播的路径也有不小关系，和电源、机械振动、电磁环境都有一定的关系。以上3%的失效率只是去除了机械振动与环境干扰后的结论。

1.4 动态性能

动态性能指的是在运动时的定位的失效率以及跟随性。
和无人机上的差分GPS进行对比，跟随性方面基本可以认为是实时跟随，这个和算法有很大的关系（这里采用限幅和卡尔曼滤波）。失效率方面，距离越远失效率越高，基本可以认为每十米会增加20%左右的失效率。

1.5 失效分析

综上，影响UWB测距（这个是定位的基本）性能的元素如下：

距离：距离越远，测距性能受环境的影响越明显，这是一个被动技能，可以理解为基础能力下降，受到异常状态的概率上升。

传播路径：空中明显比地面性能差，室外明显比楼道性能差，这应该是由于墙面对微博的反射导致的信号增强造成的，虽然反射同时也会出现多径效应，但在实验中体现并不明显，所以基本可以认为有墙面对测距性能是有利的。

电源：电源功率不足时，可能会导致信号发射接收时基站/TAG宕机，笔记本的USB口供电时出现过这个问题。

机械振动：这个不同于一定范围内运动时的失效，而是电机等造成的小幅度高频机械振动，这种振动会对二十米以上的测距性能造成毁灭性影响。

电磁干扰：这个比较玄学了，我这没什么好的解释。

影响定位，却无关于测距的元素就是算法方面了，由于算法的问题，所以基站的布局必须和tag和基站之间的最大距离同步，比如tag可能在空中100m，那么最好有一个100m x 100m的基站布局，如果要测三维，应该至少有两个基站将tag夹在中间。

完。

【UWB/室内定位】DW1000大坑-基础系统搭建1

dtysky — Sunday, 22 Nov 2015 01:00:00 -00:00

如果自嘲只不过是将真诚化为伪装的工具。
那么。
就让我将之坚持到底吧。

由于公司项目需求所以研究了一下UWB定位，UWB即超宽频定位，一般用于室内离线定位，在众多离线定位方法中它算是精度最高的之一，其定位原理一般为TOA活着TDOA。DW1000则是公司研发的一款UWB定位芯片，它同时也可以用于通信。此芯片据说可以达到300M、6.8mbps的传输速度，定位精度可以到达10cm，并且除了官方的开发套件外也有现成的开源方案。本章将会说明如何搭建一个基础的UWB硬件系统，着重于说明期间遇到的一些大坑，比如电源...

1 UWB

UWB定位，超宽频定位，本质上和GPS卫星定位的原理是一样的，它不过是将卫星放在了地面上，也就是自己搭建作为卫星的基站，然后去根据和GPS定位相同的算法计算出每个Anchor（基站）到Tag（移动站）的距离，从而解算出移动站的空间坐标，对于三维空间定位而言一般至少需要四个Anchor，Anchor的数量增加不但可以构建超定方程组使用一些算法提高精度，同时也可以作为通信质量不佳下的冗余设计，所以在可以接受的条件下，基站的数量一般越多越好。

1.1 DW1000

DW1000是DecaWave公司推出的一款UWB定位芯片，按照其DATASHEET说明，其有效距离可以达到300m，同时据代理商提供的信息，其定位精度可以到到10cm的程度，这在业内算是一个非常不错的参数。不过介于每个厂商总会吹一些牛的这个业界常识，我们还是要自己测试一下才知道具体的事实。
对于有钱的开发者，建议直接购买EVK1000或者TREK1000进行开发，这两者都是官方自己生产的开发板，无论是电路走线还是电源方面都有着很可靠的保证，操作上更是做到了去除对PC的依赖，开机即可在LCD屏上看到测距效果。对于一般的开发者，则建议购买DWM1000这个官方封装好的模块进行开发，相对于裸片，它集成了时钟和天线等，比较便于测试。

下面是我购买到的DWM1000模块，260一块~：

DW1000的控制比较简单，其指令和数据的传输全部是基于SPI总线的，这是最简单的一种总线，通过有SPI支持的单片机几乎可以进行无痛操作，而具体的寄存器介绍和配置请见DW1000 UserManual。

1.2 TOA/TDOA

UWB定位的原理是TOA或者TODA，当然也有还有AOA等，不常见。

1.2.1 TOA

TOA即“到达时间”，这种方式定位是通过Anchor和Tag之间的多次通信实现的，如下图：

Anchor首先发给Tag一个包，同时记录下Anchor当前的时间信息，记为T1。

Tag收到基站的信息，返回一个ACK。

Anchor收到Tag的ACK，记录当前的时间信息，记为T2。

Anchor计算时间差Tr = T2 - T1，并且根据此计算出距离：

d = c * Tr / 2

其中c为光速。

当然，实际应用中为了更加靠谱，往往不仅仅是利用两次通信来测距，还会有更加复杂的多次通信来提高精度，详细的同样可以看DW1000的UserManual最后一节。
对于空间定位，只需要利用SX（球面相交法）便可以得出最后的坐标。
可见，为了一次定位，每个Anchor和Tag之间要进行两次通信，故DecaWave又将这种定位方式称为“Two-way-ranging”。这种定位的优势在于其实现的便捷性和对硬件的宽容，只需要有几个摆放在不同位置的Anchor和一个Tag便可进行定位，而缺点嘛...首先自然是定位速度了，其次，由于每次通信的质量无法保证，而一对Anchor/Tag又无法做自我的校准，精度自然也会受到相当的影响。

1.2.2 TDOA

TODA即“到达时间差”，这种方式的一次测距是由两个Anchor和一个Tag实现的。在这种模式下，多个时钟完全同步的Anchor同时接受来自一个Tag的包，对于不同位置的Anchor，同一个Tag的同一次广播包到达的时间是不同的，所以便有有以下算法：

Tag发出一个广播包。

两个Anchor接收到同一个包，Anchor1接收到的时间为T1，Anchor2接收到的时间为T1。

计算时间差Td = T2 - T1。

对于至少四个Anchor，可以得到三组这样的两两之间的信息。

通过数学方法（multi-lateration）可以解算出Tag的空间坐标。

由于算法比较复杂，这里不再赘述。

由此可见，TDOA的优势首先在于一次定位的通信次数显著减少，其次由于是用时间差而非绝对时间进行测距，其精度也比TOA高出一些。但优势总是以一些代价换来的，TDOA系统中各个Anchor的时钟必须严格同步，由于这种定位本质上是依赖于光速的，所以1ns的固有时钟误差便可以造成30cm的固有距离误差，这一点显然是不可接受的。而要打造一个间距比较大的精确同步系统成本又是比较高昂的，所以从这个层面来讲，TDOA并非一般人或者公司可以玩得起的。
当然，DecaWave自身研究出了另一种TDOA的方式(详见APS003)，也就是在时钟之外另外加了一个同步位用于同步，不过看起来也是比较复杂的，暂时没有深究。

2 基础系统搭建/电源需求

在搭建系统之前首先调研有没有现成的项目可以用于测试，寻找后首先进入视线的是基于arduino的这个项目，此项目使用Arduino作为主控，提供了一系列的API和例子。

2.1 基于Arduino的系统

首先在淘宝上购买了二十多一片的山寨Arduino Nano，用面包板搭建了一个最基础的两片测距系统进行测试，系统如图，测试遇到的一些问题如下：

程序无法工作，重复setup或者跑着跑着跑飞了。

使用示波器检测SPI通信，表明正常；使用逻辑分析仪抓SPI包，分析正常。排除SPI接口问题。

可连接性测试例子调试，程序跑飞，操蛋过程略，在每次打印设备信息前加100ms的延迟，跑通。

基础收发例子，跑飞，在打印信息前加延迟，无效，全部注释逐个取消注释，发现代码超过一定量跑飞，初步定为为片子质量有问题。

基础收发例子，将缓冲数组的长度从1024改为了256，程序跑通，第二天到公司又跑不通。

经过提醒在电源和地之间加了个大电容，跑的时间长了点，粗略定位为供电问题。

不再使用山寨Arduino的3.3v输出口给DWM1000供电，而是换上了独立的线性电源，程序基本跑通，定位为电源问题。

测试基础收发，发现程序虽然可以跑但是收不到数据，于是对源代码进行了改造，不对数据进行判断直接读DW1000的RX_BUFFER之中的数据进行打印，发现一部分数据数对的，但后面都会乱码。

将“Hello DW1000”改成了“Fuck DW1000”，程序跑通，初步定位为山寨片子质量问题。

以下为测试过程中的一些现场图：

之后购买了Arduino中文网推荐的卖家之一的DFROBOT生产的正版Arduino Nano，搭建了系统进行测试：

测试经历：

测试基础收发，还是和之前一样的问题，看来山寨片子或许只是供电差了一些，其他也倒还好。

测试MessagePingPong，发现可以跑通，但通信质量并不好，有时还是会出现乱码。

测距测试，使用其中一个座位Anchor，一个作为Tag，初步测距成功，并且RX_POWER和开源项目自身的指标比较相近。

多个Anchor测距测试，通信质量急速下降，再次判定为电源问题。

改进电源后再次测试，发现测距很不稳定，总是某个Anchor信号很强，其他很弱，或者都很弱。

对Anchor和Tag之间距离进行了变换，发现当前系统的有效距离和稳定性很差。

由于电子工程师为了省钱买的线性电源，Arduino全烧了，实验中止。

以下是这一段测试的一些现场图：

2.2 基于MBED的系统

虽然Arduino全烧了，但我们还有山寨的MBED，虽然是山寨的，也比正版的Arduino Nano贵不了多少，但其性能还是要高出不少的，加上无意中发现了这个开源项目，所以就不妨尝试了一下。

基于MEBD的这套系统比起前面那个开源项目的例子要成熟一些，可以直接指定几个Anchor并且同步串口打印Tag到几个Anchor的距离，测试结果也比较喜人，稳定性和速度皆甩出Arduino一截，并且自身的3.3v输出可以带的动DW1000。注意，在实际使用中，三个MBED加上DW1000在测距时的功率达到了12W左右，可见功耗还是非常可观的，并且远远超出了官方文档标出的3.3v/500ma的极限。

以下是一些测试结果，比较不幸的是三号姬的DW1000在两次炸板事件中光荣牺牲了（后来换到了二号姬的面包板上），所以测试数据少一组：

3 结论

由于补充的片子暂时没有到货，实验暂时如此，以下是这次总结出的DW1000使用注意点：

供电很重要，DW1000非常吃功率，其瞬间电流可能非常大，对电源的稳定性也有一定要求，这一点务必注意。

对于复杂一点的应用，低端Arduino还是不要用。

如果可能，电路问题还是交给专业的玄学工程师去解决，否则容易事倍功半。

对于某些开源项目，你还是要明白底层原理，要能改源代码，这是没有办法的。

Over，暂时进行距离->坐标的算法实现。

【SICP】过程抽象:递归，迭代和高阶函数

dtysky — Thursday, 10 Sep 2015 12:00:00 -00:00

银河疾走。
疾走，疾走的终点是死亡，盛宴却永不会落幕。

这个系列是在学习魔法导论SICP时某些精要部分的归纳和总结，本节是第一章的总结，第一章在复习了一些常见算法的同时，讲述了在极其简单的基本scheme环境下如何适当的对程序的过程进行抽象，道出了抽象的一般形式，并给出了如何写出高可读性的代码——这些代码是符合人类的逻辑思维过程的。
第一章所有的习题如下，使用DrRacket环境：
SICP-Chapter1

1 Scheme

Scheme是一种Lisp方言，Lisp，即表处理语言，他的基本编程思想是函数式和递归的，所以对数学的亲和性很高，但对于人类而言就没有这么容易理解了，和其他C系的编程语言不同，在写Lisp的时候往往需要首先进行人肉优化，这会带来两个结果：

增加思考成本，降低短期效率

让代码结构变得更为清晰，增加可读性，降低维护成本

当然，现在Lisp嫡系的编程语言境遇都不怎么好，所以虽然其有通用语言之名，但却没有实际生产之实，而本书用到的Scheme更是只用于教学领域，那么这本书讲的东西就毫无实践意义了么？并非如此，SICP并不是一本讲语言的书，他讲的是对程序设计进行抽象的思想，而使用Scheme只是恰好有许多优秀、无所不包的特性，同时还能方便使用者造轮子，而造轮子，则是学习的最高效手段之一。

1.1 本节用到的Scheme语法

基本运算：

(+ 1 2) ;3
(- 1 2) ;-1
(* 1 2) ;2
(/ 1 2) ;1/2
(/ 1 2.0) ;0.5
(< 1 2) ;#t
(> 1 2) ;#f

逻辑运算：

(and (1 < 2) (1 > 2)) ;#f
(or (1 < 2) (1 > 2)) ;#t
(not (1 < 2)) ;#t

过程定义：

(define (inc x)
    (+ x 1))
(inc 2) ;3

分支语句：

(define (if-test x)
    (if (< x 5)
    1
    2))
(if-test 4) ;1
(if-test 6) ;2

(define (cond-test x)
    (cond   ((< x 5) 1)
            ((< x 10) 2)
            (else 3)))
(cond-test 4) ;1
(cond-test 9) ;2
(cond-test 100) ;3

匿名函数：

((lambda (x) (+ x 1)) 1) ;2
(let ((x (+ 1 1))) x) ; 2

2 递归和迭代

递归和迭代是两种基本的过程，他们都只需要一个过程的递推公式，通常而言，求得递推公式往往比求得通项公式要来的容易，所以这其实也是一种可以简化思考的方式。

2.1 线性递归和迭代

考虑一个函数，其定义为：

n! = 1 x 2 x 3 x ... x n

显然，这就是阶乘函数的定义，其递推公式是十分简单和浅显的，而通项公式则不是那么简单，下面我们可以分别用递归和迭代来实现它：

递归：

(define (factor n)
    (if n 0)
    1
    n * (factor (- n 1)))

这个递归实现的实际运算过程如下：

(factor 5)
(x 5 (factor 4)
(x 5 (4 x (factor 3)))
......
(x 5 (x 4 (x 3 (x 2 (factor 1))))
(x 5 (x 4 (x 3 (x 2 1))))
......
120

可见，递归过程中，原先的表达式会先被展开，直到无法再继续展开之时再回归计算。同时注意到递归总是发生在条件分支的末尾，这种递归而形式叫做“尾递归”，也是最常用的一种递归。

迭代：

用递归过程计算阶乘实际上是按照以下公式进行的：

n! = n x (n - 1) x (n - 2) x ... x 2 x 1

这有一个展开后回归的过程，所以必须使用一个特殊的存储结构（堆栈）去存储整个展开的轨迹，以用于之后的回归计算，虽然这种形式十分直观和便于理解，但往往也会造成大量资源的消耗，于是有了以下的迭代形式：

(define (factor n)
    (define (iter count result max-count)
        (if (= count max-count)
            result
            (iter
                (+ count 1)
                (* result count)
                max-count)))
    (iter 1 1 n))

迭代的实际运算过程如下：

(factor 5)
(iter 1 1 5)
(iter 2 1 x 2 5)
(iter 3 2 x 3 5)
(iter 4 6 x 4 5)
(iter 5 24 x 5 5)
120

可见，在迭代形式下，计算是实时的，没有展开的概念，也无需回归计算，计算过程中只需要维护count, result和max-count三个变量即可，需求的资源大大减少，然而这个的代价是代码的形式不够直观（阶乘这种小东西还好，一旦复杂起来...）

2.2 树形递归和迭代

树形递归实际上就是多个分支的线性递归，也可以说线性递归是单分支的树形递归，考虑以下函数：

$$Finb(n) = \begin{cases}0 && n = 0 \\1 && n = 1\\ Finb(n-1) + Finb(n-2) && others\ \end{cases}$$

这个函数即Fibonacci数列，它有许多有趣的性质和广泛的应用然而在这里只用它来讨论树形递归，它的递归形式如下：

(define (fib n)
    (cond
        ((= n 0) 0))
        ((= n 1) 1))
        (else (+ 
                (fib (- n 1))
                (fib (- n 2))))))

你可以自行按照上面的展开过程进行展开，可以看到，由于最末的分支中有两个分支，这两个分支将会分别展开，并且每一次的进一步展开也是如此，所以最后将会形成一个树状的结构。

迭代形式：

与线性迭代不同，线性迭代中下一个状态只和当前状态有关，而fib函数下一个状态还和前一个状态有关，所以需要额外增加一个变量来保存前一个状态的值，其实现如下：

(define (fib n)
    (define (iter count result last) 
        (if (= n 0) 
            result
            (iter 
                (- count 1)
                (+ result last)
                result)))
    (iter n 1 0))

2.3 比较

由以上分析可见，递归过程一般比较直观，便于编写，但空间复杂度和时间复杂度均比迭代过程高，相反，迭代过程比较考验设计能力，但其复杂度相对迭代过程占有优势。

3 高阶函数

高阶函数是一类特殊的函数，得益于Lisp语系函数式一等公民的这个特性，让其得以实现，在Scheme中，函数也是一种数据类型，可以作为函数的参数或者函数的返回值，这也给我们提供了一种思维的方式——我们可以定义一些函数，它们以函数参数，返回一些函数，就像是某些用于生成“生产设备”的工厂一样，生产出用于加工其他部件的机器。

注：Scheme中也将“函数”称为“过程”。

比如，我们都知道“加法”是一种抽象，加法的对象不仅可以是数，还可以是各种函数（数也是一种特殊的函数，即f(x) = x），所以我们就可以对加法进行抽象：

(define (plus a b)
    (lambda (x)
        (+ (a x) (b x))))
(define (square x) (* x x))
(define (cube x) (* x x x))
((plus square cube) 2) ;12

函数plus接受两个过程a和b，返回一个另一个过程，这个过程用匿名函数产生，它首先分别将变量x应用于过程a和b，随后将这两个过程的返回值进行相加运算。

在初步了解之后，我们可以做一些有趣的实验：

比如，我们知道“萌”是一个状态，也是一种行为，它可以表达为以下的含义——如果某某属性对于我而言是可以划分到“萌”的状态中的，那么我就是“moe”它的。这样一来，我们就可以定义为一个名为“moe”的过程，它接受一些属性，返回一个布尔值，如果返回值为真，则说明我是萌这个属性的，否则不萌：

(define (moe xxx)
    (if (yyy)
        true
        false))

在这里xxx和yyy均没有被定义，由于萌属性错综复杂，为了简化演示，我们将这个属性限定为“年龄”，如下：

(define (moe age)
    (< age 9))

现在这个moe过程的含义是：如果对象的年龄小于9岁，那么我就是萌她的，否则不是。但这种做法局限性是很强的，如果我不仅仅想用9岁作为一个阈值，而是想自己去定义我萌的年龄段，该怎么办？在其他语言中，一般想到的做法或许是加一个参数作为标示，来确定自己究竟萌哪一个年龄段，然后在函数中加上若干的分支去判断以给出答案，比如以下的python版本：

def moe(type, age):
    if type == 'loli':
        return age > 8 and age < 12
    elif type == 'girl':
        return age < 16
    ......

但在Scheme中，我们可以使用高阶函数来完成同样的需求，我们可以定义一个参数为函数的函数moe：

(define (moe tpye)
    (lambda (x)
        (type x)))

接下来定义每个属性的年龄段：

(define (loli age)
    (and (> age 8) (< age 12)))
(define (girl age)
    (and (> age 11) (< age 16)))

然后便可以使用moe函数来判定某个年龄是否符合你所萌的属性了：

((moe loli) 9) ;#t
((moe girl) 10) ;#f

是不是有点人工智能的意思？这也就是Lisp语系的魅力所在——随时随地，无时不刻，只要你想，就可以建立你自己的DSL。

【FPGA/图像处理】板上验证

dtysky — Sunday, 31 May 2015 22:00:00 -00:00

要证明模块的可靠性，需要对所有的设计进行板上验证，本次毕设课题与Xilinx的XUP(Xilinx University Program，Xilinx大学计划)合作，使用了XUP提供的Zybo开发板，Zybo是一个ZYNQ平台的开发板，片上搭载了一个双核的ARM，并且具有VGA等接口作为视屏输出，输入采用XUP提供的摄像头以及配套的驱动程序，测试硬件如图4-1所示。同时考虑到资源的压力，摄像头被配置为320x240的模式。本章将会说明如何设计一个测试框架，并对所有已实现的模块放入框架进行测试。
测试需要所有的模块，测试工程在这里： TestOnBoard

4 板上验证

要证明模块的可靠性，需要对所有的设计进行板上验证，本次毕设课题与Xilinx的XUP(Xilinx University Program，Xilinx大学计划)合作，使用了XUP提供的Zybo开发板，Zybo是一个ZYNQ平台的开发板，片上搭载了一个双核的ARM，并且具有VGA等接口作为视屏输出，输入采用XUP提供的摄像头以及配套的驱动程序，测试硬件平台如图4-1所示。同时考虑到资源的压力，摄像头被配置为320x240的模式。本章将会说明如何设计一个测试框架，并对所有已实现的模块放入框架进行测试。

图4-1 测试硬件平台

4.1 测试框架

测试框架可以分为输入、处理和输出三个部分，如图4-2所示。其中输入采用摄像头模块，在其后放置一个帧缓存来存储输入数据，但考虑到Zybo的片上RAM资源并不多，同时灰度图像已经足以满足测试，所以首先将摄像头输出的数据进行灰度化再存入帧缓存，这样可以节省一半的RAM资源。在帧缓存后使用读取模式帧控制器来读取数据，进入处理部分，在处理部分中，每一个处理模块对数据进行并行处理，并按照实际的需求对先后顺序做出一些调整，从而并行输出各自的处理结果。处理部分之后是输出部分，输出采用一个VGA控制器进行，由于VGA无法和处理模块同步，所以中间需要加一个帧缓存，帧缓存使用一个写入模式的帧控制器进行控制，由于需要接受多个处理模块的输入数据，所以必须有一个多路选通器来选择将那一个结果送给帧控制器，多路选通器接受外部控制，以此间接决定VGA的最终输出。
一部分处理模块需要外部进行配置参数的输入，比如TH核就需要输入阈值化模式和阈值，所以要考虑如何对其进行配置，此处利用ZYNQ的ARM平台和AXI协议，构建一个AXI总线的配置模块用于各个模块参数的配置，同时提供系统复位和多路选通器的输入，即用软件的方法配置硬件，可以大大提高灵活性和降低调试成本。

图4-2 测试框架

4.2 AXI总线模块的构建

4.2.1 AXI总线模块的结构和原理

基于AXI总线的模块是一种特殊的模块，可以通过它利用AXI协议使得ARM平台(PS端)和可编程硬件平台(PL端)进行通信^[28]，Vivado中提供了一种便捷的方式来进行这种模块的创建^[29]，创建的时候有三种模式进行选择，分别是"AXI-Lite"，"AXI-Full"和"AXI-Stream"，三种模式各有各的用处，同时还可以选择有几个从模块，考虑到本次需要建立的模块实现的功能比较简单，所以采用了Lite模式，只有一个从模块。创建完成后可以看到在被创建的模块目录下有一些文件夹和文件，如图4-3所示，我们需要关心的只有这几个文件，其中XX为模块名：

hdl/XXV1_0.v：这是此模块的顶层HDL文件，用于管理所有从模块。

hdl/XXV1_0_S00_AXI.v：从模块的HDL文件，用于功能的实现，如果有若各从模块，将有多个这样的文件。

drivers/XXV1_0/src/XX.c: ARM端驱动程序，用于定义上位机部分的功能。

drivers/XXV1_0/src/XX.c: ARM端驱动程序的头文件。

对于Lite模式，Xilinx已经预先生成了模块的AXI协议部分模板，用户只需要在指定的地方编写自己需要的逻辑即可。

图4-3 AXI总线模块的结构

AXI总线模块的工作原理如图4-4，PS端运行的是ARM环境下的C程序，它用于执行用户的软件指令，当需要和PL端通信时，它先通过Xilinx封装的IO函数，利用AXI总线将数据传输到PL端的寄存器中，随后PL端再通过寄存器中的数据来执行相应的操作，随后将需要输出的数据输出给其他PL端的模块。

图4-4 AXI总线模块的原理

4.2.2 配置模块的构建

配置模块有三类输出——配置参数信号、复位信号和选择信号，但本质上它们都是同样的信号，每一个信号都由PS端提供数据，并由一个单独的端口进行输出，端口的输出来自于PS端送入PL端中寄存器的数据。同时，配置模块还需要能够接受外界的硬件复位和PLL的锁定信号，这两个信号和AXI的复位信号、PS端的复位指令综合产生一个复位输出。配置模块的GUI如图4-5所示。

图4-5 配置模块的GUI

配置模块的驱动部分需要考虑两点，即地址管理和函数设计。将配置模块命名为"BOARDINIT_AXI"，则模块创建成功时会提供一系列已经定义好的宏，如下：

#define BOARDINIT_AXI_S00_AXI_SLV_REG0_OFFSET 0
#define BOARDINIT_AXI_S00_AXI_SLV_REG1_OFFSET 4
......

这些宏定义了PL端寄存器的地址偏移量，为了便于管理，可以在上面再加一层宏定义：

#define BOARDINIT_RstN BOARDINIT_AXI_S00_AXI_SLV_REG0_OFFSET
#define BOARDINIT_Sels BOARDINIT_AXI_S00_AXI_SLV_REG1_OFFSET
......

同时，在用到配置模块的工程生成完硬件数据流后，可以在SDK建立的项目工程中的BSP中找到"xparameters.h"文件，里面有此模块基地址的偏移量XPAR_BOARDINIT_AXI_0_S00_AXI_BASEADDR：

#define XPAR_BOARDINIT_AXI_0_DEVICE_ID 0
#define XPAR_BOARDINIT_AXI_0_S00_AXI_BASEADDR 0x43C00000
#define XPAR_BOARDINIT_AXI_0_S00_AXI_HIGHADDR 0x43C0FFFF

有了基地址偏移量和寄存器地址偏移量，便可以管理所有的输出地址了，通常将所有的地址放在一个结构体中备用：

typedef struct
{
    u32 BaseAddress;
    u32 RstN;
    ......
    u32 Sels;
} BOARDINIT;

函数设计要考虑到初始化、IO和数据转换。其中初始化用于将结构体中所有的地址初始化，数据转换则是将用户输入的数据转换为PL端可用的数据，比如对于一些模块，其参数要求指定位数的浮点数，但AXI协议传输的是无符号整数，所以不可以直接进行IO，必须进行转换。初始化部分可以使用下面的函数完成：

void BOARDINIT_Init(BOARDINIT *bdit, u32 BaseAddress){
    bdit->BaseAddress = BaseAddress;
    bdit->RstN = BaseAddress + BOARDINIT_RstN;
    ......
    bdit->Sels = BaseAddress + BOARDINIT_Sels;}

IO部分，所有的IO都要依赖与Xilinx提供的IO函数：

#define BOARDINIT_Set(address, data) Xil_In32(address)
#define BOARDINIT_Get(address) Xil_Out32(address, data)

为了便于使用，在上面加上一层封装，这个函数的目的是保证输出的数据确实被写入了寄存器内。

void BOARDINIT_SetWithCheck(u32 Address, u32 data){
    while(BOARDINIT_Get(Address) != data){BOARDINIT_Set(Address, data);}
    return;}

一些参数需要被进行浮点数到指定位数的定点数的转换，以下函数完成了这个功能，其中rel_width为整数部分位数，dec_width为小数部分位数。

u32 Format2Fixed(float num, int rel_width, int dec_width){
    u32 s = 0;
    u32 r = 0;
    float dtmp = 0;
    if (num < 0){
        s = 1 << (rel_width + dec_width);
        r = (int)(-num);
        dtmp = (int)num - num;}
    else{
        r = (int)num;
        dtmp = num - r;}
    r = r << dec_width;
    u32 d = 0;
    int i =0;
    for (i = 0; i < dec_width; i++){
        dtmp = dtmp * 2;
        if (dtmp >= 1){
            d += 1 << (dec_width - 1 - i);
            dtmp--;}}
    if (s){return s + s - (r + d);}
    return s + r + d;}

至此，配置模块的驱动部分完成。

4.3 测试-点操作

点操作的Board工程如图4-6，原始图像和灰度图像如图4-7，阈值化的结果如图4-8，对比度变换的结果如图4-9，亮度变换的结果如图4-10，色彩反转的结果如图4-11。

图4-6 点操作Board

图4-7 原始图像和灰度图像，上侧为原始图像，下侧为灰度图像

图4-8 阈值化，上侧为一般全局阈值化，阈值为150，下侧为等高线阈值化，阈值为130和170

图4-9 对比度变换，上侧系数为1.8，下侧系数为0.3

图4-10 亮度变换，上侧系数为50，下侧系数为-50

图4-11 色彩反转

4.4 测试-局部滤波器

局部滤波器的Board工程如图4-12，原始图像和灰度图像如图4-13，均值滤波器的结果如图4-14，排序滤波器的结果如图4-15，局部阈值化的结果如图4-16，腐蚀膨胀的结果如图4-17。

图4-12 局部滤波器Board

图4-13 原始图像和灰度图像，上侧为原始图像，下侧为灰度图像

图4-14 均值滤波器

图4-15 排序滤波器，上侧为中值滤波器，中间为最大值滤波器，下侧为最小值滤波器

图4-16 局部阈值化，上侧的前置滤波器为均值滤波器，下侧为中值滤波器

图4-17 腐蚀膨胀，上侧为腐蚀，源为中值滤波后的局部阈值化图像，模板为000011010，下侧为膨胀，源为均值滤波后的局部阈值化图像，模板为000011011

4.5 测试-几何变换

几何变换的Board工程如图4-18，原始图像和灰度图像如图4-19，裁剪的结果如图4-20，平移的结果如图4-21，镜像的结果如图4-22，缩放的结果如图4-23，错切的结果如图4-24，旋转的结果如图4-25。

图4-18 几何变换Board

图4-19 原始图像和灰度图像，上侧为原始图像，下侧为灰度图像

图4-20 裁剪，上边界为40，下边界为240，左边界为0，右边界为200

图4-21 平移，上侧横向偏移100，纵向100，下侧横向偏移-100，纵向-100

图4-22 镜像，上侧为横向，中间为纵向，下侧为全部

图4-23 缩放，上侧横向比例为1.3，纵向为0.6，下侧横向为0.6，纵向为1.3

图4-24 错切，上侧横向比例为0.5，纵向为0.5，下侧横向为-1.671，纵向为0.539

图4-25 旋转，上侧角度为90度，下侧角度为225度

4.6 结论

经过实际测试，所有的模块都可以正常工作，设计完全成功。

参考文献

[28] Xilinx, AXI Reference Guide, UG761 v14.3[EB/OL], November 15, 2012
[29] Xilinx, Packaging Custom AXI IP for Vivado IP Integrator, XAPP1168 (v1.0)[EB/OL], June 01, 2013

感谢

硬件支持：
Xilinx上海

测试图像来源：
初心社-世界旅行 - 荷兰/阿姆斯特丹，英国/伦敦，希腊/爱琴海

【FPGA/图像处理】几何变换-旋转

dtysky — Saturday, 30 May 2015 00:30:00 -00:00

旋转同样是仿射变换的一种特例，它接受一个角度，将图像绕着某个中心进行转动，适合逆向映射。旋转的实现有多种，比如两次错切的旋转^[26]、直接坐标变换^[27]等，中心点的选取方式也有许多，但对于FPGA采用图像的几何中心较为合适。。本节将会说明如何用FPGA实现旋转的模块。
这个IP核的资源在这里：
Rotate

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.21 几何变换-旋转

旋转同样是仿射变换的一种特例，它接受一个角度，将图像绕着某个中心进行转动，适合逆向映射。旋转的实现有多种，比如两次错切的旋转^[26]、直接坐标变换^[27]等，中心点的选取方式也有许多，但对于FPGA采用图像的几何中心较为合适。。本节将会说明如何用FPGA实现旋转的模块。

3.21.1 原理

此设计中旋转的前向映射基本原理如式3-21-1，其中angle为旋转角度,$x_c$和$y_c$分别为图像中心横纵坐标。对于逆向映射应该对此式进行调整，变换为3-21-2的形式，可见旋转操作比较复杂，不仅涉及多次符号乘法、符号加法，还涉及到三角函数的计算。

$$\begin{cases}Q[x_t,y_t] = I[x,y] \\x_t = xc + (x - xc) * cos(a) - (y - yc)*sin(a)\\ y_t = yc + (x - xc) * sin(a) + (y - yc)*cos(a)\\x \in[0, w) ,y \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-21-1)$$

$$\begin{cases}I[x,y] = Q[x_t,y_t] \\x = (x_t - xc) * cos(a) + (y_t - yc) * sin(a) + xc\\ y = (-x_t + xc) * sin(a) + (y_t - yc) * cos(a) + yc\\x_t \in[0, w) ,y_t \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-21-2)$$

首先要考虑三角函数的计算，如3.1中所述，FPGA中的特殊函数计算需要用查找表来实现，所以需要编写一个脚本来生成查找表，同时由于三角函数的值可能为负数，并且verilog中符号系统是补码系统，所以需要生成的是角度和此角度下三角函数值的补码。由于正弦和余弦的值域为[-1, 1]，同时一般用于变换的角度为[0,359]，所以综合考虑，最终选择将角度划分为360个点，使用1位符号位、1位整数位和18位的小数位的数据来表示函数值，这其中的难点在于如何将一个浮点数转换为20位的定点数补码，实现函数如下。

  def format(num):
    r, d = format(num, 'f').split('.')
    r = '0' + r[0] if len(r) == 1 else '1' + r[1]
    d = float('0.' + d)
    res = ''
    for i in xrange(18):
        d = d * 2
        res += '1' if d >= 1 else '0'
        d = d - 1 if d >= 1 else d
    res = r[1] + res
    if r[0] == '1':
        if eval(res) == 0:
            res = '0'
        else:
            res = bin(2 ** 19 - eval('0b' + res))[2:]
        for i in xrange(19 - len(res)):
            res = '0' + res
    res = r[0] + res
    if res == '10000000000000000000':
        res = '00000000000000000000'
    return res

旋转变换同样需要符号舍入，但整数位只有1位，所以没有溢出风险，可以将其简化，仅仅裁剪输出即可。

3.21.2 设计

根据原理可知，Rotate核(以下简称RTT核)需要四次符号乘法、四次符号舍入操作和四次符号加法，并且需要和基于行列计数的帧控制器进行合作。故其需要的配置参数与端口如表3-21-1和表3-21-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。
mul_delay	无符号	取决于乘法器配置，1-14	3	乘法器延迟。
ram_RL	无符号	取决于帧控制器	7	帧控制器输出延迟。

表3-21-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
angle	input	无符号	0 - 359	无	旋转角度。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
frame_in_ready	输入	无符号	无	无	连接到帧控制器的out_ready。
frame_in_data	输入	无符号	data_width - 1 : 0	无	连接到帧控制器的out_data。
frame_enable	output	无符号	无	无	连接到帧控制器的in_enable。
frame_out_count_x	output	无符号	im_width_bits - 1 : 0	无	连接到帧控制器的in_count_x。
out_count_y	output	无符号	im_width_bits - 1 : 0	无	连接到帧控制器的in_count_y。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-21-2 端口

名字	类型	说明
Sin	SinLUT	获取角度的正弦。
Cos	CosLUT	获取角度的余弦。
MulX1	Multiplier13Sx20SRTT	13位有符号数和20位有符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
MulX2	Multiplier13Sx20SRTT	13位有符号数和20位有符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
MulY1	Multiplier13Sx20SRTT	13位有符号数和20位有符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
MulY2	Multiplier13Sx20SRTT	13位有符号数和20位有符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
FRSX1	FixedRoundSigned	用于有符号浮点数的舍入。
FRSX2	FixedRoundSigned	用于有符号浮点数的舍入。
FRSY1	FixedRoundSigned	用于有符号浮点数的舍入。
FRSY2	FixedRoundSigned	用于有符号浮点数的舍入。

表3-3-3 子模块

3.21.3 实现

根据3.21.2的设计便可以实现一个RTT核，流水线模式和请求响应模式实现如下。

3.21.3.1 流水线模式

在帧控制器的输出使能后1个周期第一个结果被输出，开始流水化工作，波形如图3-21-1。

图3-21-1 流水线模式时序

3.21.3.2 请求响应模式读取

基本同3.21.3.1，但只有在in_enable上升沿时计数器才会加1才会被改变，波形如图3-21-2。

图3-21-1 流水线模式时序

3.21.3.3 IP核GUI

完成功能后对RTT核进行了封装，封装如图3-21-3。

图3-21-3 RTT核的GUI

3.21.4 仿真

只对RGB图像和灰度图像进行测试，考虑到仿真设计模块比较多，出于仿真压力，我选择了一张图像的灰度模式进行三套参数的测试，原始图像如图3-21-4。

图3-21-4 仿真原始图像

仿真参数如表3-16-4所示，选择原则是可以被二进制表示和不可以被表示的值都包含。

angle
45
131
270

表3-16-4 仿真参数

仿真并进行PSNR测试，仿真结果如图3-21-5所示。

图3-21-5 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.21.5 资源和时序

最终实现与图像大小和数据位宽有关，这里只分析大小为512x512和数据位宽为8时的状况，根据Vivado生成的报表，主要资源耗费如表3-21-5。

Slice LUTs*	Slice Registers	DSP
543	245	4

表3-21-5 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为4.414ns，即：

FMax = 226.55MHz

即说明，Rotate核在流水线模式下，理论上在处理1080p全高清图像时可以达到109帧。
与3.20相同，此FMax低于期望值，也来自于舍入核的加法，考虑时间此处暂时不做优化。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.21.6 分析与结论

PSNR如表3-21-6。

1-131	1-270	1-45	Total
1000000.00	54.89	1000000.00	666684.96

表3-21-6 PSNR

PSNR对于某些参数为最大值，对于一些不是，最终误差来自于符号乘法和查找表自身的误差，但PSNR均为50以上，可见在测试范围内，RTT核可以满足处理需求，设计成功。

参考文献

[26] 陈芳.一种基于错切原理的图像旋转方法[J].淮阴师范学院学报（自然科学版）,2004,3(4):319-322.DOI:10.3969/j.issn.1671-6876.2004.04.016.
[27] 王金辉.实时图像旋转系统的研究与FPGA实现[D].华中科技大学,2012.

感谢

仿真图像来源：
041-マツムシソウ

【FPGA/图像处理】几何变换-错切

dtysky — Friday, 29 May 2015 23:00:00 -00:00

错切也是仿射变换的一种特例，它接受水平和垂直两个方向的错切系数，将图像进行扭变，它同样适合进行逆向映射。错切常用于图像校正操作，同时也可以作为旋转变换的中间变换^[26]。本节将会说明如何用FPGA实现错切的模块。
这个IP核的资源在这里：
Shear

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.20 几何变换-错切

错切也是仿射变换的一种特例，它接受水平和垂直两个方向的错切系数，将图像进行扭变，它同样适合进行逆向映射。错切常用于图像校正操作，同时也可以作为旋转变换的中间变换^[26]。本节将会说明如何用FPGA实现错切的模块。

3.20.1 原理

错切变换的前向映射基本原理如式3-20-1，其中xsh和ysh为两个方向的错切系数。对于逆向映射应该对此式进行调整，变换为3-20-2的形式，$xsh_t$和$ysh_t$为逆向映射系数，没有使用前向映射的逆变换是考虑到错切本身意义模糊，如果采用逆变换会导致算法复杂度大大增加却无法得到理想的效果，所以直接根据前向映射的形式得出了逆向映射。

$$\begin{cases}Q[x_t,y_t] = I[x,y] \\x_t = x * xsh + y\\ y_t = y * ysh + x\\x_t \in[0, w) ,y_t \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-20-1)$$

$$\begin{cases}I[x,y] = Q[x_t,y_t] \\x = x_t * xsh_t + y_t\\ y = y_t * ysh_t + x_t\\x_t \in[0, w) ,y_t \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-20-2)$$

输出同样要进行边界判定，这和3.19中基本一致。同时由于涉及到定点数乘法，所以需要确定小数位，考虑到错切系数是有符号的定点数，所以此模块需要乘法器来实现一个无符号数(坐标)和与有符号定点数(错切系数)的乘法，最终确定了在3.19中设计的基础上加上一位符号位来保证精度，即错切系数的范围为(-64,64)。此模块同样涉及到舍入问题，并且是有符号数的舍入问题，故可以采用3.1中论述的FR核来完成舍入，舍入的原理如式3-20-3，$I_s$为符号位，首先判断输入的正负，随后根据正负来确定如何舍入。

$$Q = \begin{cases}I_r && I_{d1} = 0 \\I_r + 1 && I_{d1} = 1,\ I_s=0\\I_r - 1 && I_{d1} = 1,\ I_s=1\ \end{cases}.\ \ \ \ \ \ \ \ (3-20-3)$$

同时考虑到舍入核输出的数值将会进行一次加法，所以输出的位数越少越好，故此处设计了一个可选的输出位宽和一个溢出标志，同时在模块内部进行一次比较，来告知外部此次输入的值是否出现了溢出，溢出规则如式3-20-4，Orig为转换后的原码，Of为溢出标志，fp为定点位，resw为指定的输出位宽，numw为原始数据位宽，即在需求位数之外、被截取的高位数值不为0时则判定为溢出，最终只要把这个溢出标志加入到边界判定中即可。

$$Of = \begin{cases}0 && Orig[numw - 1 : resw] = 0 \\1 && Others\ \end{cases}.\ \ \ \ \ \ \ \ (3-20-4)$$

3.20.2 设计

根据原理可知，Shear核(以下简称SHR核)需要两次符号乘法、两次符号舍入操作和两次符号加法，并且需要和基于行列计数的帧控制器进行合作。故其需要的配置参数与端口如表3-20-1和表3-20-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。
mul_delay	无符号	取决于乘法器配置，1-14	3	乘法器延迟。
ram_RL	无符号	取决于帧控制器	7	帧控制器输出延迟。

表3-20-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
sh_u	input	有符号	定点数，1flag+6bits.18bits	无	横向错切系数。
sh_v	input	有符号	定点数，1flag+6bits.18bits	无	纵向错切系数。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
frame_in_ready	输入	无符号	无	无	连接到帧控制器的out_ready。
frame_in_data	输入	无符号	data_width - 1 : 0	无	连接到帧控制器的out_data。
frame_enable	output	无符号	无	无	连接到帧控制器的in_enable。
frame_out_count_x	output	无符号	im_width_bits - 1 : 0	无	连接到帧控制器的in_count_x。
out_count_y	output	无符号	im_width_bits - 1 : 0	无	连接到帧控制器的in_count_y。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-20-2 端口

名字	类型	说明
MulU	Multiplier12x25SSHR	12位无符号数和25位有符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
MulV	Multiplier12x25SSHR	12位无符号数和25位有符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
FRSU	FixedRoundSigned	用于有符号浮点数的舍入。
FRSV	FixedRoundSigned	用于有符号浮点数的舍入。

表3-3-3 子模块

3.20.3 实现

根据3.20.2的设计便可以实现一个SHR核，流水线模式和请求响应模式实现如下。

3.20.3.1 流水线模式

在帧控制器的输出使能后1个周期第一个结果被输出，开始流水化工作，波形如图3-20-1。

图3-20-1 流水线模式时序

3.20.3.2 请求响应模式读取

基本同3.20.3.1，但只有在in_enable上升沿时计数器才会加1才会被改变，波形如图3-20-2。

图3-20-1 流水线模式时序

3.20.3.3 IP核GUI

完成功能后对SHR核进行了封装，封装如图3-20-3。

图3-20-3 SHR核的GUI

3.20.4 仿真

只对RGB图像和灰度图像进行测试，考虑到仿真设计模块比较多，出于仿真压力，我选择了一张图像的灰度模式进行三套参数的测试，原始图像如图3-20-4。

图3-20-4 仿真原始图像

仿真参数如表3-16-4所示，选择原则是可以被二进制表示和不可以被表示的值都包含。

ush	vsh
0.5	0.5
-1.671	0.539
0.824	-1.793

表3-16-4 仿真参数

仿真并进行PSNR测试，仿真结果如图3-20-5所示。

图3-20-5 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.20.5 资源和时序

最终实现与图像大小和数据位宽有关，这里只分析大小为512x512和数据位宽为8时的状况，根据Vivado生成的报表，主要资源耗费如表3-20-5。

Slice LUTs*	Slice Registers	DSP
212	166	2

表3-20-5 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为4.103ns，即：

FMax = 243.72MHz

即说明，Shear核在流水线模式下，理论上在处理1080p全高清图像时可以达到117帧。
此FMax低于期望值，分析得知延迟主要来源于舍入核，有符号的舍入操作会涉及原码和补码转换，在此应用中每个周期会有一次35位的加法，如果将加法拆分会得到更好的FMax，但考虑时间此处暂时不做优化。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.20.6 分析与结论

PSNR如表3-20-6。

1--1.671x0.539	1-0.5x0.5	1-0.824x-1.793	Total
52.36	52.38	1000000.00	333368.25

表3-20-6 PSNR

PSNR对于某些参数为最大值，对于一些不是，但均为50以上，可见在测试范围内，SHR核可以满足处理需求，设计成功。

参考文献

[26] 陈芳.一种基于错切原理的图像旋转方法[J].淮阴师范学院学报（自然科学版）,2004,3(4):319-322.DOI:10.3969/j.issn.1671-6876.2004.04.016.

感谢

仿真图像来源：
ぜろきち-白の夢

【FPGA/图像处理】几何变换-缩放

dtysky — Friday, 29 May 2015 19:00:00 -00:00

缩放同样是仿射变换的一种特例，它接受水平和垂直两个方向的缩放值，将图像进行伸缩，缩放用前向映射实现会出现一个问题，就是在缩放值大于1的时候可能会出现空隙^[3]。这是由于在前向映射下，并非原图像的每一个像素都可以映射为目标图像的像素，在软件上这可以通过一些插值方法来实现，但对于FPGA而言同样的实现需要用更为复杂的逻辑，故此处暂且采用逆向映射，这实际上采用了最近邻插值算法。本节将会说明如何用FPGA实现缩放的模块。
这个IP核的资源在这里：
Scale

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.19 几何变换-缩放

3.19.1 原理

缩放变换的基本原理如式3-19-1，Q为输出，I为输入，x和y为输入像素坐标，$x_t$和$y_t$为输出像素坐标，xscale和yscale分别为两个方向的缩放比例，w和h为图像的宽和高，这是前向映射的一般定义，但对于逆向映射而言，应该对此式进行调整，变换为3-19-2的形式，$x_t$和$y_t$称为自己变换的输出坐标，x和y则通过$x_t$和$y_t$除以各自缩放比例得出，随后根据x和y得到需要输出的原图像像素，进行输出。

$$\begin{cases}Q[x_t,y_t] = I[x,y] \\x_t = x * xscale && x \in[0, w)\\ y_t = y * yscale && y \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-19-1)$$

$$\begin{cases}I[x,y] = Q[x_t,y_t] \\x = x_t / xscale && x_t \in[0, w)\\ y = y_t / yscale && y_t \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-19-2)$$

可见，这实际上是先得出需要输出的像素坐标，然后反向映射到原图像的像素坐标，最后查找到原图像的像素值进行输出。所以前面章节的方式不再适用，必须采用新的设计。考虑到输出坐标的生成依赖于外界没有意义，所以选用内部的计数器进行目标图像坐标的生成。最终采用的方案为，首先将原图像存入帧缓存，根据计数器生成的坐标进行两次并行乘法得到原图像对应的坐标，并联合3.15中的帧控制器，查找得到需要输出的像素值，同时进行边界判定，当求得的原图像的坐标超出了图像的范围，则输出为背景像素，算法如式3-19-3。

$$Q[x_t,y_t] = \begin{cases}I[x,y] && (x,y)\in I \\0 && (x,y) \notin I\ \end{cases}.\ \ \ \ \ \ \ \ (3-19-3)$$

由于本库采用的是定点数乘法，所以需要一个确定的小数位来保证精度，经过实验和DSP资源的考虑(一个DSP48最多实现12x25的乘法)，最终采用拥有6位整数和18位小数的定点数，即缩放比例的范围为[0, 64)。同时由于涉及小数乘法，所以需要选择一个舍入方式，几何变换对于舍入方式是敏感的，为了符合最邻近插值的定义，几何变换中所有模块的舍入方式均为就近舍入，故需要一个舍入核来完成舍入操作，考虑到缩放变换中的乘法为无符号乘法，故舍入核设计比较简单，例如对于一个12bits.12bits的定点数，舍入原理如式3-19-4，其中Q为输出，$I_r$为输入的整数部分，$I_{d1}$为输入的小数部分第一位，第一位为1，则I的小数部分必然大于0.5，否则小于。

$$Q = \begin{cases}I_r && I_{d1} = 0 \\I_r + 1 && I_{d1} = 1\ \end{cases}.\ \ \ \ \ \ \ \ (3-19-4)$$

3.19.2 设计

根据原理可知，Scale核(以下简称SCL核)需要两次乘法，两次舍入操作，并且需要和基于行列计数的帧控制器进行合作。故其需要的配置参数与端口如表3-19-1和表3-19-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。
mul_delay	无符号	取决于乘法器配置，1-14	3	乘法器延迟。
ram_RL	无符号	取决于帧控制器	7	帧控制器输出延迟。

表3-19-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
scale_x	input	无符号	定点数，6bits.18bits	无	横向缩放比例，必须是正确缩放比例的倒数。
scale_y	input	无符号	定点数，6bits.18bits	无	纵向缩放比例，必须是正确缩放比例的倒数。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
frame_in_ready	输入	无符号	无	无	连接到帧控制器的out_ready。
frame_in_data	输入	无符号	data_width - 1 : 0	无	连接到帧控制器的out_data。
frame_enable	output	无符号	无	无	连接到帧控制器的in_enable。
frame_out_count_x	output	无符号	im_width_bits - 1 : 0	无	连接到帧控制器的in_count_x。
out_count_y	output	无符号	im_width_bits - 1 : 0	无	连接到帧控制器的in_count_y。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-19-2 端口

名字	类型	说明
MulX	Multiplier12x24SCL	12位无符号数和24位无符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
MulY	Multiplier12x24SCL	12位无符号数和24位无符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！
FRUX	FixedRoundUnsigned	用于无符号浮点数的舍入。
FRUY	FixedRoundUnsigned	用于无符号浮点数的舍入。

表3-3-3 子模块

3.19.3 实现

根据3.19.2的设计便可以实现一个SCL核，流水线模式和请求响应模式实现如下。

3.19.3.1 流水线模式

输入使能后首先计数器工作，随后计算原图像的坐标，随后根据算出的坐标得到边界，同时将坐标输出到帧控制器，在帧控制器的输出使能后1个周期第一个结果被输出，开始流水化工作，波形如图3-19-1。

图3-19-1 流水线模式时序

3.19.3.2 请求响应模式读取

基本同3.19.3.1，但只有在in_enable上升沿时计数器才会加1才会被改变，波形如图3-19-2。

图3-19-1 流水线模式时序

3.19.3.3 IP核GUI

完成功能后对SCL核进行了封装，封装如图3-19-3。

图3-19-3 SCL核的GUI

3.19.4 仿真

只对RGB图像和灰度图像进行测试，考虑到仿真设计模块比较多，出于仿真压力，我选择了一张图像的灰度模式进行三套参数的测试，原始图像如图3-19-4。

图3-19-4 仿真原始图像

仿真参数如表3-16-4所示，选择原则是可以被二进制表示和不可以被表示的值都包含。

xscale	yscale
1.97	0.213
0.391	2.17
0.4	0.4

表3-16-4 仿真参数

仿真并进行PSNR测试，仿真结果如图3-19-5所示。

图3-19-5 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.19.5 资源和时序

最终实现与图像大小和数据位宽有关，这里只分析大小为512x512和数据位宽为8时的状况，根据Vivado生成的报表，主要资源耗费如表3-19-5。

Slice LUTs*	Slice Registers	DSP
77	69	2

表3-19-5 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为3.372ns，即：

FMax = 296.55MHz

即说明，Scale核在流水线模式下，理论上在处理1080p全高清图像时可以达到143帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.19.6 分析与结论

PSNR如表3-19-6。

1-0.391x2.17	1-0.4x0.4	1-1.97x0.213	Total
1000000.00	1000000.00	1000000.00	1000000.00

表3-19-6 PSNR

PSNR均值为最大值，可见在测试范围内，SCL核与软件等效，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013.

感谢

仿真图像来源：
あきのん-[C84]こもれび

【FPGA/图像处理】几何变换-平移

dtysky — Wednesday, 27 May 2015 22:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。平移是仿射变换的一种特例^[25]，仿射变换本质上是一个以输入坐标为自变量的线性函数，将在后面的章节详细介绍。平移变换每一个方向的变换只与该方向的输入坐标和偏移量有关，它将图像按照输入的偏移量向着水平和垂直两个方向进行移动，偏移量可正可负，所以会涉及越界的问题。大部分的仿射变换用前向映射实现都会比较复杂，但平移变换是一个例外，可以用特殊方法处理，本节将会介绍如何实现一个平移的模块。
这个IP核的资源在这里：
Pan

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.18 几何变换-平移

平移是仿射变换的一种特例^[25]，仿射变换本质上是一个以输入坐标为自变量的线性函数，将在后面的章节详细介绍。平移变换每一个方向的变换只与该方向的输入坐标和偏移量有关，它将图像按照输入的偏移量向着水平和垂直两个方向进行移动，偏移量可正可负，所以会涉及越界的问题。大部分的仿射变换用前向映射实现都会比较复杂，但平移变换是一个例外，可以用特殊方法处理，本节将会介绍如何实现一个平移的模块。

3.18.1 原理

平移变换的基本原理如式3-18-1，Q为输出，I为输入，x和y为输入像素坐标，$x_t$和$y_t$为输出像素坐标，xoffset和yoffset分别为两个方向的偏移量，w和h为图像的宽和高，可见其实现依赖于两次加法操作，由于偏移量可正可负，所以是有符号的加法操作，所以必须考虑到加法操作的结果大于图像最大边界或小于0的状况。

$$\begin{cases}Q[x_t,y_t] = I[x,y] \\x_t = x + xoffset && x \in[0, w)\\ y_t = y + yoffset && y \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-18-1)$$

由于平移变换的特殊性，故可以在加法得到的输出坐标越界时进行适当的加法或者减法操作，让输出坐标重新落到图像范围内，同时由于此时的像素是越界的，所以像素色彩置为背景，改进后的算法如式3-18-2、3-18-3、3-18-4和3-18-5，$sum_x$和$sum_y$分别为第一次加法的输出坐标。

$$\begin{cases}sum_x = x + xoffset && x \in[0, w)\\ sum_y = y + yoffset && y \in[0, h)\ \end{cases}.\ \ \ \ \ \ \ \ (3-18-2)$$

$$x_t=\begin{cases} sum_x && sum_x \in[0, w) \\sum_x + w && sum_x < 0\\sum_x - w && sum_x >= w \ \end{cases}.\ \ \ \ \ \ \ \ (3-18-3)$$

$$y_t=\begin{cases} sum_y && sum_y \in[0, h) \\sum_y + h && sum_y < 0\\sum_y - h && sum_y >= h \ \end{cases}.\ \ \ \ \ \ \ \ (3-18-4)$$

$$Q[x_t,y_t]=\begin{cases} I[x,y] && sum_x \in [0, w],sum_y \in[0, h) \\0 && Others\ \end{cases}.\ \ \ \ \ \ \ \ (3-18-5)$$

所以平移变换需要分两个阶段完成，第一个阶段用两次并行加法分别计算两个原生输出坐标，第二次则用四次并行加法得出假定越界后的输出，同时根据第一个周期得到的原生输出坐标判断输出点是否在边界之内，随后根据边界信息来确定选择原生输出坐标还是假定越界后的坐标进行最终的输出，这是一个二级流水线。

3.18.2 设计

根据原理可知，Pan核(以下简称Pan核)需要两级流水线，若干次并行有符号加法操作和比较操作，同时需要两个端口来确定输出偏移量。故其需要的配置参数与端口如表3-18-1和表3-18-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。

表3-18-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
offset_x	input	有符号	如果是正数，则必须是原码，否则为补码。	无	横向偏移量。
offset_y	input	有符号	如果是正数，则必须是原码，否则为补码。	无	纵向偏移量。
in_count_x	input	无符号	im_width_bits - 1 : 0	无	图像横向坐标输入。
in_count_y	input	无符号	im_width_bits - 1 : 0	无	图像纵向坐标输入。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。
out_count_x	input	无符号	im_width_bits - 1 : 0	无	图像横向坐标输出。
out_count_y	input	无符号	im_width_bits - 1 : 0	无	图像纵向坐标输出。

表3-18-2 端口

3.18.3 实现

根据3.18.2的设计便可以实现一个Pan核，流水线模式和请求响应模式实现如下。

3.18.3.1 流水线模式

输入使能后2个周期第一个结果被输出，开始流水化工作，波形如图3-18-1。

图3-18-1 流水线模式时序

3.18.3.2 请求响应模式读取

基本同3.18.3.1，但只有在in_enable上升沿时输入才会被改变，波形如图3-18-2。

图3-18-1 流水线模式时序

3.18.3.3 IP核GUI

完成功能后对Pan核进行了封装，封装如图3-18-3。

图3-18-3 Pan核的GUI

3.18.4 仿真

只对RGB图像和灰度图像进行测试，我选择了一张图像的RGB和灰度模式进行两套参数的测试，原始图像如图3-18-4。

图3-18-4 仿真原始图像

仿真参数如表3-16-3所示。

xoffset	yoffset
-100	100
200	-50

表3-16-3 仿真参数

仿真并进行PSNR测试，仿真结果如图3-18-5所示。

图3-18-5 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.18.5 资源和时序

最终实现与图像大小和数据位宽有关，这里只分析大小为512x512个数据位宽为8时的状况，根据Vivado生成的报表，主要资源耗费如表3-18-4。

Slice LUTs*	Slice Registers
55	71

表3-18-4 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为3.153ns，即：

FMax = 317.15MHz

即说明，Pan核在流水线模式下，理论上在处理1080p全高清图像时可以达到152帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.18.6 分析与结论

PSNR如表3-18-5。

1--100x100	1-200x-50	2--100x100	2-200x-50	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-18-5 PSNR

PSNR均值为最大值，Pan核与软件等效，同时可以达到不错的FMax，设计成功。

参考文献

[25] 王金辉,陈冰,王建庄等.实时图像仿射变换系统的研究与实现[J].机械与电子,2012,(2):59-62.DOI:10.3969/j.issn.1001-2257.2012.02.016.

感谢

仿真图像来源：
方向錯亂-Queen

【FPGA/图像处理】几何变换-镜像

dtysky — Wednesday, 27 May 2015 18:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。镜像的目的是将图像进行翻转，与色彩反转类似，不过它变换的是坐标。镜像可以用前向映射实现，同时由于输出坐标必然落在原先的图像区域内，所以不用进行区域判断，属于比较简单的几何变换，本节将说明如何实现一个镜像的IP核。
这个IP核的资源在这里：
Mirror

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.17 几何变换-镜像

镜像的目的是将图像进行翻转，与色彩反转类似，不过它变换的是坐标。镜像可以用前向映射实现，同时由于输出坐标必然落在原先的图像区域内，所以不用进行区域判断，属于比较简单的几何变换，本节将说明如何实现一个镜像的IP核。

3.17.1 原理

镜像有两种模式——水平镜像和垂直镜像，它的原理如式3-17-1所示，Q为输出，I为输入，x和y为输入像素坐标，$x_t$和$y_t$为输出像素坐标，width和height为图像宽度和高度。可见镜像的本质是将输入坐标和图像的宽度和高度做减法以得到输出坐标，同时由于减法的结果必然小于被减数，故这实际上是单纯的无符号数的减法。

$$\begin{cases}Q[x_t,y_t] = I[x,y] \\x_t = width - 1 - x && x \in[0, width)\\ y_t = height - 1 - y && y \in[0, height)\ \end{cases}.\ \ \ \ \ \ \ \ (3-17-1)$$

实际应用中会出现三种情况——水平镜像、垂直镜像和全镜像，所以需要一个模式选择来确定模块的工作方式，同时由于图像宽高的位宽均被限定到12位之内，所以只需要一个周期的流水便可以满足FMax。

3.17.2 设计

根据原理可知，Mirror核(以下简称MR核)需要若干次并行减法操作，同时需要根据模式来确定减法操作的次数，所以需要一个mode端口来确定工作的模式。故其需要的配置参数与端口如表3-17-1和表3-17-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。

表3-17-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
mode	input	无符号	0为水平镜像，1为垂直镜像，2和3为全镜像	无	工作模式。
in_count_x	input	无符号	im_width_bits - 1 : 0	无	图像横向坐标输入。
in_count_y	input	无符号	im_width_bits - 1 : 0	无	图像纵向坐标输入。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。
out_count_x	input	无符号	im_width_bits - 1 : 0	无	图像横向坐标输出。
out_count_y	input	无符号	im_width_bits - 1 : 0	无	图像纵向坐标输出。

表3-17-2 端口

3.17.3 实现

根据3.17.2的设计便可以实现一个MR核，流水线模式和请求响应模式实现如下。

3.17.3.1 流水线模式

输入使能后1个周期第一个结果被输出，开始流水化工作，波形如图3-17-1。

图3-17-1 流水线模式时序

3.17.3.2 请求响应模式读取

基本同3.17.3.1，但只有在in_enable上升沿时输入才会被改变，波形如图3-17-2。

图3-17-1 流水线模式时序

3.17.3.3 IP核GUI

完成功能后对MR核进行了封装，封装如图3-17-3。

图3-17-3 MR核的GUI

3.17.4 仿真

只对RGB图像和灰度图像进行测试，我选择了一张图像的RGB和灰度模式进行三种模式的测试，原始图像如图3-17-4。

图3-17-4 仿真原始图像

仿真并进行PSNR测试，仿真结果如图3-17-5所示。

图3-17-5 仿真结果，从左上角分别为流水线模式下的HDL功能仿真结果，请求响应模式下的HDL功能仿真结果，软件仿真结果

3.17.5 资源和时序

最终实现与图像大小和数据位宽有关，这里只分析大小为512x512个数据位宽为8时的状况，根据Vivado生成的报表，主要资源耗费如表3-17-3。

Slice LUTs*	Slice Registers
11	27

表3-17-3 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为1.941ns，即：

FMax = 515.19MHz

即说明，MR核在流水线模式下，理论上在处理1080p全高清图像时可以达到248帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.17.6 分析与结论

PSNR如表3-17-4。

1-All	1-Horizontal	1-Vertical	2-All	2-Horizontal	2-Vertical	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-17-4 PSNR

PSNR均值为最大值，MR核与软件等效，同时可以达到很高的FMax，设计成功。

参考文献

感谢

仿真图像来源：
LM7-nk

【FPGA/图像处理】几何变换-裁剪

dtysky — Wednesday, 27 May 2015 09:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。几何变换的基本操作单元是像素的坐标，它保留色彩信息，对坐标进行变换。几何变换有两种大方向的分类，分别是前向映射和逆向映射^[3]，对于FPGA而言，前向映射实现需要的资源较少，但是往往难度较高，但只能满足一部分简单的变换。裁剪操作可以用前向映射实现，它保留图像的一个区域的色彩信息，将其他部分的色彩置为背景，本节将说明如何实现一个裁剪模块。
这个IP核的资源在这里：
Crop

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.16 几何变换-裁剪

几何变换的基本操作单元是像素的坐标，它保留色彩信息，对坐标进行变换。几何变换有两种大方向的分类，分别是前向映射和逆向映射^[3]，对于FPGA而言，前向映射实现需要的资源较少，但是往往难度较高，但只能满足一部分简单的变换。裁剪操作可以用前向映射实现，它保留图像的一个区域的色彩信息，将其他部分的色彩置为背景，本节将说明如何实现一个裁剪模块。

3.16.1 原理

前向映射将原图像的像素坐标作为自变量，以某个变换函数得出目标图像的像素坐标，裁剪变换的变换函数如式3-16-1，Q为输出，I为输入，x和y为原图像坐标，t、b、l、r为四个边界，从某种角度来看，它实际上一种非线性滤波器，保留输入坐标的同时变换输出色彩。

$$Q=\begin{cases} I[x,y] && x \in [l, r], y \in [t, b] \\0 & & Others \ \end{cases}.\ \ \ \ \ \ \ \ (3-16-1)$$

所以，实现一个裁剪模块实际上是要通过给定的边界信息来确定可以输出的一个区域，然后根据是否在这个区域内来确定输出。

3.16.2 设计

根据原理可知，Crop核(以下简称CP核)需要进行区域判断，而判断是根据四次比较(上下左右)来完成的，故需要四个端口来输入四方的边界值，随后在模块内部进行并行比较，最后全部取与即可得到是否在区域内的信息。同时由于坐标被作为了基本的操作元素，所以输出中也应当包含坐标值。故其需要的配置参数与端口如表3-16-1和表3-16-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。

表3-16-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
top	input	无符号	取决于图像的高度，0 - im_height-1	无	裁剪区域的上边界。
bottom	input	无符号	取决于图像的高度，0 - im_height-1	无	裁剪区域的下边界。
left	input	无符号	取决于图像的高度，0 - im_widtht-1	无	裁剪区域的左边界。
right	input	无符号	取决于图像的高度，0 - im_widtht-1	无	裁剪区域的右边界。
in_count_x	input	无符号	im_width_bits - 1 : 0	无	图像横向坐标输入。
in_count_y	input	无符号	im_width_bits - 1 : 0	无	图像纵向坐标输入。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。
out_count_x	input	无符号	im_width_bits - 1 : 0	无	图像横向坐标输出。
out_count_y	input	无符号	im_width_bits - 1 : 0	无	图像纵向坐标输出。

表3-16-2 端口

3.16.3 实现

根据3.16.2的设计便可以实现一个CP核，流水线模式和请求响应模式实现如下。

3.16.3.1 流水线模式

输入使能后1个周期第一个结果被输出，开始流水化工作，波形如图3-16-1。

图3-16-1 流水线模式时序

3.16.3.2 请求响应模式读取

基本同3.16.3.1，但只有在in_enable上升沿时输入才会被改变，波形如图3-16-2。

图3-16-1 流水线模式时序

3.16.3.3 IP核GUI

完成功能后对CP核进行了封装，封装如图3-16-3。

图3-16-3 CP核的GUI

3.16.4 仿真

CP核的变换与色彩空间无关，所以适合所有色彩的变换，但综合考虑测试的必要性和测试平台的编写复杂度，只对RGB图像和灰度图像进行测试，我选择了一张图像的RGB和灰度模式进行测试，原始图像如图3-16-4。

图3-16-4 仿真原始图像

仿真参数如表3-16-3所示。

Top	Bottom	Left	Right
20	492	20	492
100	402	200	302

表3-16-3 仿真参数

仿真并进行PSNR测试，仿真结果如图3-16-5所示。

图3-16-5 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.16.5 资源和时序

最终实现与图像大小和数据位宽有关，这里只分析大小为512x512个数据位宽为8时的状况，根据Vivado生成的报表，主要资源耗费如表3-16-4。

Slice LUTs*	Slice Registers
29	5

表3-16-4 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为2.113ns，即：

FMax = 473.26MHz

即说明，CP核在流水线模式下，理论上在处理1080p全高清图像时可以达到228帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.16.6 分析与结论

PSNR如表3-16-5。

1-100x402x200x302	1-20x492x20x492	2-100x402x200x302	2-20x492x20x492	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-16-5 PSNR

PSNR均值为最大值，CP核与软件等效，同时可以达到很高的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013.

感谢

仿真图像来源：
おにねこ-メカニック・ロンド

【FPGA/图像处理】生成器-帧控制2

dtysky — Tuesday, 26 May 2015 09:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。和前面的帧控制器不同，这里的帧控制器主要为几何变换服务。几何变换操作的基本要素不是像素的色彩信息，而是它们的坐标信息，所以需要提供一个以坐标为输入的帧控制器，让几何变换模块可以控制帧缓存。本节将介绍如何实现一个以坐标为输入的帧控制器。
这个IP核的资源在这里：
FrameController2

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.15 生成器-帧控制2

和前面的帧控制器不同，这里的帧控制器主要为几何变换服务。几何变换操作的基本要素不是像素的色彩信息，而是它们的坐标信息，所以需要提供一个以坐标为输入的帧控制器，让几何变换模块可以控制帧缓存。本节将介绍如何实现一个以坐标为输入的帧控制器。

3.15.1 原理

与3.2一致，此处的帧控制器也是以改变RAM地址和控制使能信号来实现的，但地址的来源不是模块内部的计数器，而是外部输入的坐标，所以需要一个部分将坐标转换为地址，如式3-15-1所示，x为横坐标，y为纵坐标，width为图像宽度，address为输出地址，可见这实际上是一次乘法运算和一次加法运算的结合，所以需要用到乘法器。同时考虑到加法实际上可以看做最多12位的加法，所以可以不用专用加法器，交给综合器自行处理。

$$address=width * y + x\ \ \ \ \ \ \ \ (3-15-1)$$

3.15.2 设计

根据原理可知，FrameController2核(以下简称FR2核)需要一个乘法器，所以需要的配置参数、端口和子模块如表3-15-1、表3-15-2和表3-15-3。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
wr_mode	无符号	0为写，1为读。	0	模块的读写模式。
data_width	无符号	1 - 12	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。
addr_width	无符号	取决于图像的宽度和高度。	17	存储帧缓存的RAM的地址位宽。
ram_read_latency	无符号	0 - 15，取决于RAM。	2	RAM的读延迟，在Xilin器件中，典型为2。
mul_delay	无符号	乘法器延迟。	3	乘法器的延迟，取决于配置。

表3-15-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_count_x	input	无符号	im_width_bits - 1 : 0	无	图像宽度计数输入。
in_count_y	input	无符号	im_width_bits - 1 : 0	无	图像高度输入计数。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。
ram_addr	output	无符号	addr_width - 1 : 0	无	输出到RAM的地址。

表3-15-2 端口

名字	类型	说明
Mul	Multiplier12x12FR2	12位无符号数和12位无符号数的乘法器，用于得出帧地址。你可以自己配置乘法器，随后改变配置参数中的延迟。你不能改变端口的配置！

表3-15-3 子模块

3.15.3 实现

根据3.15.2的设计便可以实现一个FR2核，流水线模式和请求响应模式实现如下。

3.15.3.1 流水线模式写入

输入使能后乘法器延迟+1个周期第一个结果被输出，开始流水化工作，波形如图3-15-1。

图3-15-1 流水线模式时序

3.15.3.2 流水线模式读取

输入使能后乘法器延迟+2个周期第一个结果被输出，开始流水化工作，波形如图3-15-2。

图3-15-1 流水线模式时序

3.15.3.3 请求响应模式写入

基本与3.15.3.1一致，但只有in_enable的上升沿时才会有计数值和数据被输入，波形如图3-15-3。

图3-15-3 请求响应模式时序

3.15.3.4 请求响应模式读取

基本与3.15.3.2一致，但只有in_enable的上升沿时才会有计数值和数据被输入，波形如图3-15-4。

图3-15-4 请求响应模式时序

3.15.3.3 IP核GUI

完成功能后对FR2核进行了封装，封装如图3-15-5。

图3-15-5 FR2核的GUI

3.15.4 仿真

FR2核没有软件仿真，将原始图像作为比较源进行PSNR测试，仿真结果如图3-15-6所示。

图3-15-6 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.15.5 资源和时序

最终实现与乘法器配置和数据位宽有关，这里只分析使用DSP并且数据位宽为8的状况，根据Vivado生成的报表，主要资源耗费如表3-15-4。

Slice LUTs*	Slice Registers	DSP
38	64	1

表3-15-4 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为2.485ns，即：

FMax = 402.41MHz

即说明，FR2核在流水线模式下，理论上在处理1080p全高清图像时可以达到194帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.15.6 分析与结论

PSNR如表3-15-5。

1	2	3	Total
1000000.00	1000000.00	1000000.00	1000000.00

表3-15-5 PSNR

PSNR均值为最大值，FR2核与软件等效，同时可以达到很高的FMax，设计成功。

参考文献

感谢

仿真图像来源：
月岡月穂-ゆらゆら
 LM7-oxford eleKtricity
cotta-池

【FPGA/图像处理】局部滤波器-二值模板匹配

dtysky — Monday, 25 May 2015 23:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。二值模板匹配也可以看做是一种形态学操作，比起腐蚀膨胀它的目的更为极端和明确，如果一个窗口与模板完全一致，则保留中心像素，否则消除。这种效果适用于一些细化算法^[21,24]，比如在某些迭代算法中作为最后迭代结束的一个参照。本节将会说明一个二值模板匹配模块的实现。
这个IP核的资源在这里：
MatchTemplateBin

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.14 局部滤波器-二值模板匹配

二值模板匹配也可以看做是一种形态学操作，比起腐蚀膨胀它的目的更为极端和明确，如果一个窗口与模板完全一致，则保留中心像素，否则消除。这种效果适用于一些细化算法^[21,24]，比如在某些迭代算法中作为最后迭代结束的一个参照。本节将会说明一个二值模板匹配模块的实现。

3.14.1 原理

二值模板匹配的基本原理很简单，如式3-14-1所示，如果窗口和模板完全一致，则中心像素保留，否则置0，效果如图3-14-1。

$$Q=\bigwedge_{i,j \in T}I[x + i, y + j]\ \ \ \ \ \ \ \ (3-14-1)$$

图3-14-1 模板匹配效果

3.14.2 设计

根据原理可知，MatchTemplateBin核(以下简称MTB核)需要的配置参数和端口如表3-14-1与表3-14-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	工作模式
window_width	无符号	2 - 15	1	窗口宽度和高度。

表3-14-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
template	输入	无符号	window_width * window_width - 1 : 0	无	用于操作的模板。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-14-2 端口

3.14.3 实现

根据3.14.2的设计便可以实现一个MTB核，流水线模式和请求响应模式实现如下。

3.14.3.1 流水线模式

输入使能后1个周期第一个结果被输出，开始流水化工作，波形如图3-14-2。

图3-14-2 流水线模式时序

3.14.3.2 请求响应模式

基本与3.14.3.1一致，但只有in_enable的上升沿时才会有窗口被输入，波形如图3-14-3。

图3-14-3 请求响应模式时序

3.14.3.3 IP核GUI

完成功能后对MTB核进行了封装，封装如图3-14-4。

图3-14-4 MTB核的GUI

3.14.4 仿真

MTB核只对二值图像有意义，我选取了两张二值图像闭运算的二值图像作为仿真源，分别测试了两套模版，原始图像如图3-14-5。

图3-14-5 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-14-6所示。

图3-14-6 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

仿真结果的清晰图像如图3-14-8，可见模板匹配在适当的情况下的确可以满足一些效果。

图3-14-7 部分仿真结果，左侧为模板为000010000，右侧为111111111

3.14.5 资源和时序

最终实现与窗口大小关系很大，此处只对窗口为3x3的状况分析，根据Vivado生成的报表，主要资源耗费如表3-14-3。

Slice LUTs*	Slice Registers
5	2

表3-14-3 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为2.199ns，即：

FMax = 454.75MHz

即说明，MTB核在流水线模式下，理论上在处理1080p全高清图像时可以达到219帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.14.6 分析与结论

PSNR如表3-14-5。

1-000010000	1-111111111	2-000010000	2-111111111	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-14-5 PSNR

PSNR均值为最大值，MTB核与软件等效，同时可以达到很高的FMax，设计成功。

参考文献

[21] 施启乐,王从军,黄树槐等.数学形态学图像细化算法在RE中的应用研究[J].华中科技大学学报(自然科学版),2004,32(7):37-39.DOI:10.3321/j.issn:1671-4512.2004.07.013.
[24] 曹玉龙. 线划图像的细化算法研究[D].长安大学,2011.

感谢

仿真图像来源：
LM7-ｱｲｶﾂ
 ぜろきち-Blue star

【FPGA/图像处理】局部滤波器-二值形态学滤波

dtysky — Monday, 25 May 2015 19:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。形态学滤波器是很常用的一种局部滤波器，顾名思义，它针对图像的形态进行操作，关注的是“形状”。形态学滤波一般分为腐蚀和膨胀，而在其之上又可以叠加为开运算和闭运算，它对二值图像、灰度图像均有效，但二者实现的方式不同，一般最常用的是二值形态学滤波，针对灰度的本质上是极大值和极小值排序滤波器，暂时不再赘述。形态学滤波常用于图像细化、骨架提取等^{[21,22,23,24]}，可以作为图像识别的一种基本的预处理操作。本节将会说明FPGA的形态学滤波模块实现。
这个IP核的资源在这里：
ErosionDilationBin

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.13 局部滤波器-二值形态学滤波

形态学滤波器是很常用的一种局部滤波器，顾名思义，它针对图像的形态进行操作，关注的是“形状”。形态学滤波一般分为腐蚀和膨胀，而在其之上又可以叠加为开运算和闭运算，它对二值图像、灰度图像均有效，但二者实现的方式不同，一般最常用的是二值形态学滤波，针对灰度的本质上是极大值和极小值排序滤波器，暂时不再赘述。形态学滤波常用于图像细化、骨架提取等^{[21,22,23,24]}，可以作为图像识别的一种基本的预处理操作。本节将会说明FPGA的形态学滤波模块实现。

3.13.1 原理

二值形态学滤波的操作单元与其他局部滤波器一致，都是包含了某一个中心像素点及其邻域的窗口，但比起其他操作，它还有一个作为参照的“模板”，并根据模板和窗口的运算来得到输出。所有的二值图像都可以分为主体像素和背景像素，一般以1为主体像素，0为背景像素，这样最基本的基本的二值形态学操作-腐蚀和膨胀便可以定义为式3-13-1和3-13-2，其中I为输入，T为模板，可见腐蚀是一种收缩的变换，它将窗口与模版进行对比，如果模板中每一个主体像素都落在窗口内，则此时窗口的中心像素置1，否则为0；而膨胀则是一个扩张的变换，只要模板中的任一主体像素落在窗口内，则中心像素置1。腐蚀和膨胀的原理示意如图3-13-1，空心的点表示0，否则表示1。

$$Q=\bigwedge_{i,j \in T}I[x + i, y + j]\ \ \ \ \ \ \ \ (3-13-1)$$

$$Q=\bigvee_{i,j \in T}I[x - i, y - j]\ \ \ \ \ \ \ \ (3-13-2)$$

图3-13-1 腐蚀膨胀原理

腐蚀和膨胀还可以结合成开运算(先腐蚀后膨胀)和闭运算(先膨胀再腐蚀)，这可以利用两个基本操作的级联来完成。
在FPGA中，腐蚀膨胀可以由基本的逻辑运算来完成，并且可以用同一种结构完成^[3]，如图3-13-2所示，深色的方块代表窗口，浅色的代表模板，mode用于控制腐蚀和膨胀的模式，0为腐蚀，1为膨胀，Q为输出。如此，服饰和膨胀的逻辑运算形式便可以表示为式3-13-3，Q为输出，I为输入，T为模板，size为窗口宽度。可知，每一个像素点需要进行一次异或运算、一次非运算和一次或运算，之后所有的像素总共要进行NxN次的与运算，考虑FMax，所以选择和3.10一样的分级运算来完成。

$$Q=mode \oplus \bigwedge_{i,j = 0}^{size}I[i,j]\oplus{mode}\vee{\overline{T[i,j]}}\ \ \ \ \ \ \ \ (3-13-3)$$

图3-13-2 腐蚀膨胀逻辑结构

3.13.2 设计

根据原理可知，ErosionDilationBin核(以下简称EDB核)还需要一个用于确定与运算级数的配置参数，以及在腐蚀模式和膨胀模式之间选择的端口，还有一个用于输入模板的端口，故一个EDB核需要的配置参数和端口如表3-13-1与表3-13-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	工作模式
window_width	无符号	2 - 15	1	窗口宽度和高度。
pipe_stage	无符号	取决于窗口的宽度，为log2(window_width^2)	3	流水线级数。

表3-13-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
mode	输入	无符号	0为腐蚀，1为膨胀。	无	操作模式。
template	输入	无符号	window_width * window_width - 1 : 0	无	用于操作的模板。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-13-2 端口

3.13.3 实现

根据3.13.2的设计便可以实现一个EDB核，流水线模式和请求响应模式实现如下。

3.13.3.1 流水线模式

输入使能后pipe_stage个周期第一个结果被输出，开始流水化工作，波形如图3-13-3。

图3-13-3 流水线模式时序

3.13.3.2 请求响应模式

基本与3.13.3.1一致，但只有in_enable的上升沿时才会有窗口被输入，波形如图3-13-4。

图3-13-4 请求响应模式时序

3.13.3.3 IP核GUI

完成功能后对EDB核进行了封装，封装如图3-13-5。

图3-13-5 EDB核的GUI

3.13.4 仿真

EDB核只对二值图像有意义，我选取了两张二值图像作为仿真源，分别测试了对腐蚀和膨胀操作配置了两套模版，原始图像如图3-13-6。

图3-13-6 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-13-7所示。

图3-13-7 仿真结果，从左上依次为流水线模式下的HDL功能仿真结果，请求响应模式下的HDL功能仿真结果，软件仿真结果

仿真结果的清晰图像如图3-13-8，可见膨胀的确有扩张的功能，腐蚀的确有收缩细化的功能。同时也对开运算和闭运算做了实验，结果如图3-13-9所示，开运算可以将一些原本断续的线条“打开”，使图像零散化，而闭运算则是将线条闭合，使图像连续化。

图3-13-8 部分仿真结果，左侧为膨胀，右侧为腐蚀

图3-13-9 开闭运算结果，左侧为开运算，右侧为闭运算

3.13.5 资源和时序

最终实现与窗口大小关系很大，此处只对窗口为3x3的状况分析，根据Vivado生成的报表，主要资源耗费如表3-13-3。

Slice LUTs*	Slice Registers
12	9

表3-13-3 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为2.529ns，即：

FMax = 395.41MHz

即说明，EDB核在流水线模式下，理论上在处理1080p全高清图像时可以达到190帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.13.6 分析与结论

PSNR如表3-13-5。

1-Dilation-110110000	1-Dilation-111111000	1-Erosion-110110000	1-Erosion-111111000	2-Dilation-110110000	2-Dilation-111111000	2-Erosion-110110000	2-Erosion-111111000	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-13-5 PSNR

PSNR均值为最大值，EDB核与软件等效，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013.
[21] 施启乐,王从军,黄树槐等.数学形态学图像细化算法在RE中的应用研究[J].华中科技大学学报(自然科学版),2004,32(7):37-39.DOI:10.3321/j.issn:1671-4512.2004.07.013.
[22] 王怀群.二值图象的细化[J].无锡轻工大学学报,2001,20(3):315-318.DOI:10.3321/j.issn:1673-1689.2001.03.021.
[23] 李娜. 基于FPGA的图像实时检测系统识别系统设计[D].长春理工大学,2013.
[24] 曹玉龙. 线划图像的细化算法研究[D].长安大学,2011.

感谢

仿真图像来源：
LM7-ｱｲｶﾂ
 ぜろきち-Blue star

【FPGA/图像处理】局部滤波器-局部阈值化

dtysky — Friday, 22 May 2015 23:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。局部阈值化有别于全局阈值化，它并非利用一个全局的阈值作用于整张图像，而是对每一个单独的像素都使用一个单独的阈值，这个阈值通常来源于局部滤波器的输出。不同局部滤波器给出的阈值会产生非常不同的效果，而无论是哪一种阈值，最终的目的都是给出一个比较清晰而明确的边缘，通常这个效果比较容易达到，所以局部阈值化是一个不错的边缘检测子，本节将会说明如何实现一个局部阈值化的IP核。
这个IP核的资源在这里：
ThresholdLocal

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.12 局部滤波器-局部阈值化

局部阈值化有别于全局阈值化，它并非利用一个全局的阈值作用于整张图像，而是对每一个单独的像素都使用一个单独的阈值，这属于自适应二值化的一种^[3]这个阈值通常来源于局部滤波器的输出。不同局部滤波器给出的阈值会产生非常不同的效果，而无论是哪一种阈值，最终的目的都是给出一个比较清晰而明确的边缘，通常这个效果比较容易达到，所以局部阈值化是一个不错的边缘检测子，本节将会说明如何实现一个局部阈值化的IP核。

3.12.1 原理

局部阈值化大致与全局阈值化相同，唯一不同的是其阈值并非静态而是随着像素的输入而变化的。对于流水线模式，这个动态的变换有两种处理方式，要么要求外部提供的像素和该像素对应的阈值是同步的，要么将同步做到模块的内部，内建缓存进行同步。考虑到对用户的便利性，本模块选择了第二种模式，提供额外的配置参数来确定缓存级数，并且由额外的使能信号来确定输出值。如图3-12-1，buffer是缓冲器，ConOut是输出计数器的输出值，当像素数据输入使能时计数器开始计数，直到阈值数据输入使能计数停止，并由当前的ConOut确定选择Buffer中的哪一个数据与输入的阈值进行比较，之后流水化输出。

图3-12-1 内建缓存流水线

3.12.2 设计

根据原理可知，ThresholdLocal核(以下简称THL核)还需要有一个用于确定从像素数据有效到阈值数据有效的最大周期的配置参数max_delay，一个阈值数据输入端口ref_data，阈值数据使能端口ref_enable，故一个THL核需要的配置参数和端口如表3-12-1与表3-12-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	工作模式
in_window_width	无符号	1 - 15	1	如果输入像素以窗口中心的形式输入，则是窗口宽度，否则为1。
color_width	无符号	1 - 12	8	色彩位宽。
max_delay	无符号	取决于可能的延迟	8	像素使能到阈值使能之间可能的最大延迟周期。
max_delay_bits	无符号	取决于延迟周期	4	延迟周期的位宽。

表3-12-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * in_window_width * in_window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
ref_enable	输入	无符号	无	无	阈值数据使能。
ref_data	输入	无符号	color_width - 1 : 0	无	阈值数据，必须和ref_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-12-2 端口

3.12.3 实现

根据3.12.2的设计便可以实现一个THL核，流水线模式和请求响应模式实现如下。

3.12.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，系统复位，输出无效；否则阈值使能后1个周期第一个结果被输出，并且每一个clk的上升沿都会送入一个窗口进行处理，第一个输出有效之后，每一个周期都将送出一个结果，波形如图3-12-2。

图3-12-2 流水线模式时序

3.12.3.2 请求响应模式

基本与3.12.3.1一致，但只有in_enable的上升沿时才会有窗口被输入，波形如图3-12-3。

图3-12-3 请求响应模式时序

3.12.3.3 IP核GUI

完成功能后对THL核进行了封装，封装如图3-12-4。

图3-12-4 THL核的GUI

3.12.4 仿真

THL核只对灰度图有意义，我选取了两张灰度图像仿真源，分别测试了3x3和5x5窗口、均值滤波和中值滤波作为阈值来源的情况，原始图像如图3-12-5。

图3-12-5 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-12-6所示。

图3-12-6 仿真结果，从左上依次为流水线模式下的HDL功能仿真结果，请求响应模式下的HDL功能仿真结果，软件仿真结果

仿真结果的清晰图像如图3-12-7与3-12-8，并且同样用软件仿真进行了大窗口的测试，结果如图3-12-9。可见无论是哪一种阈值来源，对边缘的保留都比3.4中基本的阈值化算法的效果要好，同时中值滤波作为阈值来源时边缘保留的更好，但不如均值滤波干净，而均值滤波的干净是以牺牲某些细节换来的，但对于突出主体的应用很有效。同时，窗口并非越大越好，也并非越小越好，应当根据需求适当选取。

图3-12-7 均值滤波来源阈值，左侧为3x3窗口，右侧为5x5窗口

图3-12-8 中值滤波来源阈值，左侧为3x3窗口，右侧为5x5窗口

图3-12-9 11x11的窗口滤波来源阈值，左侧为均值滤波，右侧为中值滤波

3.12.5 资源和时序

最终实现与窗口大小关系很大，此处只对色彩位宽为8，最大延迟为8的状况分析，根据Vivado生成的报表，主要资源耗费如表3-12-3。

Slice LUTs*	Slice Registers
39	70

表3-12-3 主要资源耗费

同时根据时序报告，最大的Data Path Delay(数据路径延迟)为3.187ns，即：

FMax = 313.77MHz

即说明，THL核在流水线模式下，理论上在处理1080p全高清图像时可以达到151帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.12.6 分析与结论

PSNR如表3-12-5。

1-3-mean	1-3-mid	1-5-mean	1-5-mid	2-3-mean	2-3-mid	2-5-mean	2-5-mid	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-12-5 PSNR

PSNR均值为最大值，THL核与软件等效，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013

感谢

仿真图像来源：
H2SO4-蝶
 パセリ-Favour

【FPGA/图像处理】局部滤波器-排序滤波器

dtysky — Thursday, 21 May 2015 23:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。排序滤波器是一种非线性局部滤波器，它首先将窗口内的每个像素根据色彩的值进行排序，随后根据所给的序号得出最后的结果。排序滤波器的应用十分广泛，其中最常用的是中值滤波器，即为序号为窗口总大小的一半时的情况，此时滤波的结果是原窗口所有像素的中值，除此之外常用的还有极值滤波器，即得出窗口中的极大值或者极小值。排序滤波器常被用于去除椒盐噪声，或者作为后续处理的预处理，相比于均值滤波，排序滤波器能够比较好得保留边界特征。本节将会介绍如何用FPGA实现排序滤波器。
这个IP核的资源在这里：
RankFilter

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.11 局部滤波器-排序滤波器

排序滤波器是一种非线性局部滤波器，它首先将窗口内的每个像素根据色彩的值进行排序，随后根据所给的序号得出最后的结果。排序滤波器的应用十分广泛，其中最常用的是中值滤波器，即为序号为窗口总大小的一半时的情况，此时滤波的结果是原窗口所有像素的中值，除此之外常用的还有极值滤波器，即得出窗口中的极大值或者极小值。排序滤波器常被用于去除椒盐噪声^[16]，或者作为后续处理的预处理，相比于均值滤波，排序滤波器能够比较好得保留边界特征。本节将会介绍如何用FPGA实现排序滤波器。

3.11.1 原理

排序滤波器的基本原理见图3-11-1，将像素作为基本元素，一个窗口可以看做是一个列表，对于一个3x3的均值滤波器，列表大小为9。排序滤波器列表中所有的元素进行排序，随后根据序号“rank”得出结果，即式3-11-1所示，之后用这个结果来取代窗口的中心像素点。故可知，排序滤波器的核心在于给一个列表的所有元素进行排序。

图3-11-1 排序滤波器原理

$$Q=sorted(I)[rank]\ \ \ \ \ \ \ \ (3-11-1)$$

传统的软件排序算法有许多种，例如冒泡排序、插入排序、选择排序等[17]，这些算法有一个共同的特点是在最好的状况下时间复杂度为O(n)，同时根据不同状况需求的排序次数不定，对于FPGA而言这是不可接受的。用FPGA实现时，在流水线模式下，必须要保证排序次数对于拥有任何元素的列表都是确定的，并且由于直到第一个结果输出前每次都要保留整个列表的元素，如果排序周期过长，所造成的资源消耗是巨大的，所以必须找到一个周期确定并且非常快速的排序算法。

3.11.1.1 使用奇偶互换网络的冒泡排序

一种排序算法是使用奇偶互换网络的冒泡排序^[3]，它在冒泡排序的基础上进行改进，如图3-11-2所示，这是一个大小为9的列表进行排序的结构，每个周期都进行若干次两两排序，并将首或者尾元素进行保留，在9个周期后得到结果，可见，这种排序结构可以保证对于任何周期的排序周期一定，但时间复杂度仍然为O(n)，这意味着对于n个元素的列表，需要经过n个周期才能得到排序的结果，并且需要消耗$n^2$个像素的寄存器资源，当n值变大时这个消耗往往是难以接受的。

图3-11-2 使用奇偶互换网络的冒泡排序

3.11.1.2 基于3点比较器的排序

另一种适用于FPGA的排序算法是基于3点比较器的排序^[18]，它的原理如图3-11-3所示，可见，这实际上是对3.11.1.1中算法的改进，对于大小为9的列表，它将排序周期从9减少到了3，大大提升了效率。但这种排序算法适用性太为狭窄，基本只可能用于3x3的窗口，考虑到本库的通用性，无法满足需求。

图3-11-3 基于3点比较器的排序

3.11.1.3 并行全比较排序

适用于本库的排序算法为并行全比较排序^[19]，其基本原理如图3-11-4所示，首先为列表中的每个元素建立一个比较计数寄存器，在第一个周期将此元素和其他的元素进行并行比较，将比较的结果写入比较计数寄存器的对应位，之后对每一次寄存器中“1”的个数进行统计，统计得到的结果即为该元素经过排序后的序号。

图3-11-4 并行全比较排序

可见，此排序算法的核心是两次统计，第一次是某一元素和其他元素大小关系的统计，第二次是比其他元素大的情况的次数统计。第一次统计可以用一个二维数组来实现，但有一个边界的问题，就是如果出现相同的元素该如何处理^[20]，这里的处理方式是原序号在前优先的原则，序号为0的元素和所有元素进行比较，根据比较结果修改比较计数寄存器0的第n位和比较计数寄存器n的第0位，而后序号为1的元素便不和序号为0的元素进行比较，只比教剩下的元素，将比较计数寄存器定义为二维数组big_flag，则代码如下：

for (i = 0; i < `full_win_width; i = i + 1) begin
    always @(posedge clk)
        big_flag[i][i] <= 0;
end
for (i = 0; i < `full_win_width; i = i + 1) begin
    for (j = i + 1; j < `full_win_width; j = j + 1) begin
        always @(posedge clk) begin
            if(reg_in_data[i] >= reg_in_data[j]) begin
                big_flag[i][j] <= 1;
                big_flag[j][i] <= 0;
            end else begin 
                big_flag[i][j] <= 0;
                big_flag[j][i] <= 1;
            end
        end
    end
end

第二个实质上是若干次的加法，加法的个数由列表的大小确定，考虑到每个相加的数据位数均为1，所以一个周期内的多次加法是可以被接受的，但由于FMax的权衡，仍然要进行同3.10中一样的加法分级拆分，在若干次试验之后，最终将这个次数定为了8次，即一个周期内可以进行八次加法，由此，加法的级数由公式3-11-2确定。

综上，此排序的时间复杂度为O(log8(n)，加上第一次的统计时间，本模块最终的时间复杂度和空间复杂度如式3-11-3和3-11-4所示。

$$O(n)=\lfloor{log_8(n - 1)}\rfloor + 2\ \ \ \ \ \ \ \ (3-11-2)$$

$$O(n)=n * (\lfloor{log8(n - 1)}\rfloor + 2) * ColorWidth\ \ \ \ \ \ \ \ (3-11-3)$$

最终的排序查找输出相当于利用一个RAM完成，这之前需要使用一个编码器来完成最终序号的查找，编码器的输入位数为窗口的全大小，当窗口宽度大于5时综合器无法实现，所以此模块的窗口宽度被限定为2-5。

3.11.2 设计

根据原理可知，RankFilter核(以下简称RF核)核心是两次统计，它们分别由二维数组和分级加法实现。加法的分级可以使用verilog中的generate语句来批量生成，生成的流水线级数依赖于根据窗口宽度计算得出的某个参数，我将此参数命名为sum_stage。另外，还需要一个rank端口来确定输出的序号值。综上，一个RF核需要的配置参数和端口如表3-11-1与表3-11-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	工作模式
window_width	无符号	2 - 15	3	窗口的宽度和高度。
color_width	无符号	1 - 12	8	色彩位宽。
sum_stage	无符号	取决于窗口宽度，为int(log8(window_width^2)) + 1。	3	加法级数。
full_win_bits	无符号	取决于窗口大小	4	窗口总大小的位宽。

表3-11-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
rank	输入	无符号	full_win_bits - 1 : 0	无	输出序号，如果是整个窗口大小的一半，模块工作为中值滤波器，等等。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * window_width * window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-11-2 端口

3.11.3 实现

根据3.11.2的设计便可以实现一个RF核，流水线模式和请求响应模式实现如下。

3.11.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，系统复位，输出无效；否则加法级数加2个周期后第一个结果被输出，并且每一个clk的上升沿都会送入一个窗口进行处理，第一个输出有效之后，每一个周期都将送出一个结果，波形如图3-11-5。

图3-11-5 流水线模式时序

3.11.3.2 请求响应模式

基本与3.11.3.1一致，但只有in_enable的上升沿时才会有窗口被输入，波形如图3-11-6。

图3-11-6 请求响应模式时序

3.11.3.3 IP核GUI

完成功能后对RF核进行了封装，封装如图3-11-7。

图3-11-7 RF核的GUI

3.11.4 仿真

RF核虽然对于所有图像都有意义，但一般用于灰度图像的处理，所以我选取了两张灰度图像仿真源，并且考虑到仿真压力，仅测试了宽度为3和5的窗口，分别为中值和极大值的情况，原始图像如图3-11-8。

图3-11-8 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-11-9所示。

图3-11-9 仿真结果，从左上依次为流水线模式下的HDL功能仿真结果，请求响应模式下的HDL功能仿真结果，软件仿真结果

仿真结果的清晰图像如图3-11-10、3-11-11与3-11-12，可见中值滤波器的确可以在模糊的同时保留边缘，并且窗口越大越模糊，而极值滤波器将会损失更多细节，但能够让边缘更加明晰。

图3-11-10 3x3窗口的中值滤波结果

图3-11-11 5x5窗口的中值滤波结果

图3-11-12 3x3窗口的极值滤波结果

3.11.5 资源和时序

最终实现与窗口大小关系很大，此处只对色彩位宽为8，窗口大小为3和5时的情况进行分析，根据Vivado生成的报表，主要资源耗费如表3-11-3。

窗口大小	Slice LUTs*	Slice Registers
3x3	377	228
5x5	2715	1262

表3-11-3 主要资源耗费

同时根据时序报告，3x3窗口下最大的Data Path Delay(数据路径延迟)为3.705ns，即：

FMax = 269.90MHz

即说明，RF核在流水线模式下，理论上在处理1080p全高清图像时可以达到130帧。

5x5窗口下最大的Data Path Delay(数据路径延迟)为6.196ns，即：

FMax = 161.39MHz

即说明，RF核在流水线模式下，理论上在处理1080p全高清图像时可以达到77帧。
可见二者的资源耗费可以接受，但FMax均不理想，这是由于最后的输出实际上实现的是一个读延迟周期的分布式RAM，这种RAM的FMax本身就比较低，并且可以加上一级流水线进行优化，便可以大大提升FMax，考虑时效问题，此处暂且不再进行讨论。由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.11.6 分析与结论

PSNR如表3-11-5。

1-3-4	1-3-8	1-5-12	1-5-24	2-3-4	2-3-8	2-5-12	2-5-24	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-11-5 PSNR

PSNR均值为最大值，RF核与软件等效，同时资源消耗可以接受，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013
[17] 达文姣,任志国,王龙平等.静态链表上排序算法的研究[J].自动化与仪器仪表,2011,(2):12-14.DOI:10.3969/j.issn.1001-9227.2011.02.006.
[18] 李新春,赵璐.基于中值滤波算法滤波器的FPGA实现[J].计算机系统应用,2011,20(9):82-85,72.DOI:10.3969/j.issn.1003-3254.2011.09.018.
[19] 师廷伟,金长江.基于FPGA的并行全比较排序算法[J].数字技术与应用,2013,(10):126-127.
[20] 李飞飞,刘伟宁,王艳华等.改进的中值滤波算法及其FPGA快速实现[J].计算机工程,2009,35(14):175-177.DOI:10.3969/j.issn.1000-3428.2009.14.061.

感谢

仿真图像来源：
LM7-.410
色原みたび-夏空間

【FPGA/图像处理】局部滤波器-均值滤波器

dtysky — Wednesday, 20 May 2015 23:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。均值滤波器是局部滤波器的一种，又称为平滑线性滤波器^[15]，它通常用于去除图像中高斯噪声^[16]，其具有对图像的模糊效果。均值滤波器有两种，一种是算术均值滤波器，一种是加权均值滤波器，前者可以看做是后者的特例，但考虑到加权均值滤波需要消耗大量乘法运算，并且除法运算难以避免，对FPGA并不友好，故这里只讨论算术均值滤波器的实现，本节将说明如何用FPGA实现一个均值滤波器。
这个IP核的资源在这里：
MeanFilter

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.10 局部滤波器-均值滤波器

均值滤波器是局部滤波器的一种，又称为平滑线性滤波器^[15]，它通常用于去除图像中高斯噪声^[16]，其具有对图像的模糊效果。均值滤波器有两种，一种是算术均值滤波器，一种是加权均值滤波器，前者可以看做是后者的特例，但考虑到加权均值滤波需要消耗大量乘法运算，并且除法运算难以避免，对FPGA并不友好，故这里只讨论算术均值滤波器的实现，本节将说明如何用FPGA实现一个均值滤波器。

3.10.1 原理

算术均值滤波器的基本原理见图3-10-1，这是一个3x3的均值滤波器，它对窗口中所有的像素求和，之后除以像素个数，最终得到的是整个窗口中像素的算术平均值，即式3-10-1所示，之后用这个均值来取代窗口的中心像素点。所以可知，一次均值运算需要若干次加法和一次除法，在FPGA中一个周期内实现这么多次加法对于FMax很不友好，所以需要考虑将其拆分，同时除法运算如果可以避免尽量避免，因为除法消耗的资源比较多，如果不使用DSP其对FMax的影响也会比较大。综上，本设计应当重点关注加法分段和除法替代的算法。

图3-10-1 算术均值滤波器原理

$$Q=\frac{1}{n^2}\sum_{i=0}^{n^2}I_i\ \ \ \ \ \ \ \ (3-10-1)$$

3.10.1.1 加法

将像素视为基本元素，一个窗口可以看作是从左上到右下的元素构成的一个列表。当N为偶数时，列表中的N个元素的一次求和运算，可以用若干级求和运算来代替，每一级求和运算由若干组的两个元素的求和运算组成，每一级的求和运算次数为$\frac{n}2$、$\frac{n}{2^2}$、$\frac{n}{2^3}$......直到某一级的运算次数为1，该级的这唯一的运算结果便是列表中所有元素的和，此时求和结束。当N为奇数时，只需要让列表中的最后一个元素参与到第一组加法中即可，图3-10-2演示了3x3的窗口的求和过程。

图3-10-2 3x3窗口求和

可见，一个N个元素的列表求和需要分为的级数S如式3-10-2。

$$Q=\log_2N\ \ \ \ \ \ \ \ (3-10-2)$$

3.10.1.2 除法

由于本库限定窗口大小为2-15，个数不多，所以除法运算替代为若干次的移位相加操作是可以接受的。综合考虑到FPGA加法操作的延迟和运算消耗的周期，以三次移位两次加法为上限，同时为了防止最终的运算结果溢出，需要保证使用替代后的算法计算出来的结果不大于标准操作的结果，经过试验和删选，最终确定的替代算法如下：

case (window_width)
    2 : reg_out_data <= sum_all >> 2;
    3 : reg_out_data <= (sum_all >> 4) + (sum_all >> 5) + (sum_all >> 6);
    4 : reg_out_data <= sum_all >> 4;
    5 : reg_out_data <= (sum_all >> 5) + (sum_all >> 7) + (sum_all >> 10);
    6 : reg_out_data <= (sum_all >> 6) + (sum_all >> 7) + (sum_all >> 8);
    7 : reg_out_data <= (sum_all >> 6) + (sum_all >> 8) + (sum_all >> 10);
    8 : reg_out_data <= sum_all >> 6;
    9 : reg_out_data <= (sum_all >> 7) + (sum_all >> 8) + (sum_all >> 11);
    10 : reg_out_data <= (sum_all >> 7) + (sum_all >> 9) + (sum_all >> 13);
    11 : reg_out_data <= (sum_all >> 7) + (sum_all >> 12) + (sum_all >> 13);
    12 : reg_out_data <= (sum_all >> 8) + (sum_all >> 9) + (sum_all >> 10);
    13 : reg_out_data <= (sum_all >> 8) + (sum_all >> 9) + (sum_all >> 14);
    14 : reg_out_data <= (sum_all >> 8) + (sum_all >> 10) + (sum_all >> 12);
    15 : reg_out_data <= (sum_all >> 8) + (sum_all >> 11);
    default : /* default */;
endcase

使用Python进行软件测试，每个窗口大小所对应的误差为如表3-10-1。可见最大误差在2%左右，对于此应用可以接受。

窗口宽度	误差
2	0.00%
3	2.35%
4	0.00%
5	0.39%
6	2.35%
7	0.00%
8	0.00%
9	1.57%
10	1.57%
11	1.57%
12	2.35%
13	0.39%
14	0.00%
15	1.18%

表3-10-1 除法误差

3.10.2 设计

根据原理可知，MeanFilter核(以下简称MF核)核心是若干级的加法和最后的除法，加法的分级可以使用verilog中的generate语句来批量生成，生成的流水线级数依赖于根据窗口宽度计算得出的某个参数，我将此参数命名为sum_stage。综上，一个MF核需要的配置参数和端口如表3-10-2与表3-10-3。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	工作模式
window_width	无符号	2 - 15	3	窗口的宽度和高度。
color_width	无符号	1 - 12	8	色彩位宽。
sum_stage	无符号	取决于窗口宽度，为log2(window_width^2)。	3	加法级数。

表3-10-2 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * window_width * window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-10-3 端口

3.10.3 实现

根据3.10.2的设计便可以实现一个MF核，流水线模式和请求响应模式实现如下。

3.10.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，系统复位，输出无效；否则加法级数加2个周期后第一个结果被输出，并且每一个clk的上升沿都会送入一个窗口进行处理，第一个输出有效之后，每一个周期都将送出一个结果，波形如图3-10-3。

图3-10-3 流水线模式时序

3.10.3.2 请求响应模式

基本与3.10.3.1一致，但只有in_enable的上升沿时才会有窗口被输入，波形如图3-10-3。

图3-10-4 请求响应模式时序

3.10.3.3 IP核GUI

完成功能后对MF核进行了封装，封装如图3-10-5。

图3-10-5 MF核的GUI

3.10.4 仿真

MF核虽然对于所有图像都有意义，但一般用于灰度图像的处理，所以我选取了两张灰度图像仿真源，并且考虑到仿真压力，仅测试了宽度为3和5的窗口，原始图像如图3-10-6。

图3-10-6 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-10-7所示。

图3-10-7 仿真结果，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

仿真结果的清晰图像如图3-10-8与3-10-9，可见均值滤波的确有模糊图像的效果，窗口越大越明显，同时需要注意由于使用了窗口，所以图像出现了缺行现象，在实际使用时可以在写入帧缓存时利用row_init参数来配置初始写入行，当系统实际运行时，从第二张图像开始这个问题将会被自动弥补。

图3-10-8 3x3窗口的滤波结果

图3-10-9 5x5窗口的滤波结果

3.10.5 资源和时序

最终实现与窗口大小关系很大，色彩位宽为8，窗口大小为3时的情况进行分析，根据Vivado生成的报表，主要资源耗费如表3-10-4。

Slice LUTs*	Slice Registers
83	78

表3-10-4 主要资源耗费

同时由于根据时序报告，最大的Data Path Delay(数据路径延迟)为2.085ns，即：

FMax = 479.61MHz

即说明，MF核在流水线模式下，理论上在处理1080p全高清图像时可以达到231帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.10.6 分析与结论

PSNR如表3-10-5。

1-3	1-5	2-3	2-5	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-10-5 PSNR

PSNR均值为最大值，MF核与软件等效，同时可以达到很高的FMax，设计成功。

参考文献

[15] Rafael C. Gonzales, Richard E. Woods.数字图像处理(第三版)[M].阮秋琦,阮宇智等译.北京:电子工业出版社,2011.6
[16] 关新平,赵立兴,唐英干等.图像去噪混合滤波方法[J].中国图象图形学报,2005,10(3):332-337.DOI:10.3969/j.issn.1006-8961.2005.03.013.)

感谢

仿真图像来源：
おにねこ-クロス.ホエン
 月岡月穂-春爛漫

【FPGA/图像处理】生成器-窗口生成器

dtysky — Wednesday, 20 May 2015 16:00:00 -00:00

图像处理理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。窗口生成器跟在行缓存生成器之后，负责将行缓存生成的每一列扩展成以某个像素为中心、以这个像素的邻域为填充的窗口，以供后续的模块进行处理。原则上，窗口的生成可以在每个局部滤波器模块的内部生成，但考虑到可能有若干个模块复用同一个窗口，综合复用性和资源成本的考量后，我选择用这样的一个生成器来作为行缓存和处理模块的连接层，本节将介绍如何构造一个窗口生成器。
这个IP核的资源在这里：
WindowGenerator

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.9 生成器-窗口生成器

窗口生成器跟在行缓存生成器之后，负责将行缓存生成的每一列扩展成以某个像素为中心、以这个像素的邻域为填充的窗口，以供后续的模块进行处理。原则上，窗口的生成可以在每个局部滤波器模块的内部生成，但考虑到可能有若干个模块复用同一个窗口，综合复用性和资源成本的考量后，我选择用这样的一个生成器来作为行缓存和处理模块的连接层，本节将介绍如何构造一个窗口生成器。

3.9.1 原理

如图3-9-1中所示，窗口生成器接受包含若干行像素的一列，输出整个窗口的像素，并且窗口应当包含当前操作的中心像素以及其邻域像素。所以需要构造一个二维数组，数组的每一维都包含了一行，初始状态下窗口中的每个像素均为0，之后最左侧的一列不断接收外部数据，而每行的各个像素之间不断进行移位操作，以此来构造一个在图像上不断滑动的窗口。

图3-9-1 窗口的原理

3.9.2 设计

根据原理可知，WindowGenerator核(以下简称WG核)核心是一个二维数组每一维的像素之间的移位操作。考虑对于NxN的窗口，只有当第一个在图像上的像素作为窗口中心时才能够真正的输出，所以在N/2个周期之前，窗口的输出应该是无效的。但即使在无效的时候，窗口仍然需要外部输入数据来保证其继续被填充到有效，这和其他模块的设计不同，必须采用专用的设计来完成。考虑流水线模式，每一个周期模块接收外部送入的一列进行处理，由于移位是连续的，所以当第一个窗口填充完毕后输出有效，这和一般的流水线模式基本一致，而对于请求响应模式则不同，这种模式下输入数据受到输入使能的控制，移位是不连续的，所以当第一个窗口被填充完毕、窗口输出有效之前，必须有一个信号通知外部需要继续写入数据，我设计了一个端口input_ack来传递这个信号。综上，一个WG核需要的配置参数和端口如表3-9-1与表3-9-2。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	工作模式
window_width	无符号	2 - 15	3	窗口的宽度和高度。
color_width	无符号	1 - 12	8	色彩位宽。

表3-9-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width * window_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width * window_width * window_width - 1 : 0	无	输出数据，将会和out_ready同步输出。
input_ack	output	无符号	无	无	输入响应，仅仅被用于请求响应模式，这个端口将在输入数据被接受时给出一个响应。

表3-9-2 端口

3.9.3 实现

根据3.9.2的设计便可以实现一个WG核，流水线模式和请求响应模式实现如下。

3.9.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，系统复位，输出无效；否则窗口宽度加1个周期后第一个窗口被输出，并且每一个clk的上升沿都会送入一列进行处理，第一个窗口有效之后，每一个周期都将送出一个窗口，波形如图3-9-2。

图3-9-2 流水线模式时序

3.9.3.2 请求响应模式

基本与3.9.3.1一致，但只有in_enable的上升沿时才会有数据被输入，同时每一列输入后都会有一个input_ack信号响应此次输入，来提示外部进行下一次的输入，波形如图3-9-3。

图3-9-3 请求响应模式时序

3.9.3.3 IP核GUI

完成功能后对WG核进行了封装，封装如图3-9-4。

图3-9-4 WG核的GUI

3.9.4 仿真

WG核虽然对于所有图像都有意义，但一般用于灰度和二值图像的处理，所以我选取了一张图像的灰度模式与二值模式(来源于局部二值化，在后面的章节将会介绍)作为仿真源，并且考虑到仿真压力，仅测试了宽度为3和5的窗口，原始图像如图3-9-5。

图3-9-5 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-9-6所示。

图3-9-6 仿真结果之一，行缓存宽度为5，左侧为流水线模式下的HDL功能仿真结果，中间为请求响应模式下的HDL功能仿真结果，右侧为软件仿真结果

3.9.5 资源和时序

最终实现与窗口大小关系很大，这里只对512x512，色彩位宽为8，窗口大小为3时的情况进行分析，根据Vivado生成的报表，主要资源耗费如表3-9-3。

Slice LUTs*	Slice Registers
73	74

表3-9-3 主要资源耗费

同时由于根据时序报告，最大的Data Path Delay(数据路径延迟)为2.325ns，即：

FMax = 430.10MHz

即说明，WG核在流水线模式下，理论上在处理1080p全高清图像时可以达到207帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.9.6 分析与结论

由于WG核与一般的图像处理不同，所以不能采用PSNR来评估，只能对比软件仿真和硬件仿真每一行的文本，完全相同时则为正确(OK)，得到的数据如表3-9-4。

1-3	1-5	2-3	2-5	Total
OK	OK	OK	OK	OK

表3-9-4 文本对比

可见WG核有效，同时可以达到很高的FMax，设计成功。

参考文献

感谢

仿真图像来源：
パセリ-COMITIA100

【FPGA/图像处理】生成器-行缓存生成器

dtysky — Tuesday, 19 May 2015 16:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。行缓存是局部滤波操作的基础，它是生成窗口的前置条件。行缓存生成器的目的是截取图像的前N行，随后将其作为窗口数据的来源，设计一个行缓存生成器需要考虑到复用性和去耦合，以保证在有需求的情况下，一个行缓存能够被更多的后续模块利用。本节将会介绍如何实现一个行缓存生成器。
这个IP核的资源在这里：
RowsGenerator

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.8 生成器-行缓存生成器

行缓存是局部滤波操作的基础，它是生成窗口的前置条件。行缓存生成器的目的是截取图像的前N行，随后将其作为窗口数据的来源，设计一个行缓存生成器需要考虑到复用性和去耦合，以保证在有需求的情况下，一个行缓存能够被更多的后续模块利用。本节将会介绍如何实现一个行缓存生成器。

3.8.1 原理

如图3-8-1所示^[3]，左侧是第一种窗口生成的方式，行缓存和窗口并行，右侧则是和窗口串行。在FPGA的实现中，无论是哪一种方式，行缓存中的每一行通常都是由一个和图像等宽的Fifo来构造的，而Fifo所消耗的存储器或者LUT资源比较多，所以考虑到实现的便利性、行缓存复用性和去耦合，本库选择了与窗口并行的方式。

图3-8-1 窗口生成形式

由于用到了Fifo，所以需要调用Xilinx官方的IP核，根据Fifo的数据手册^[14]，可知其可以配置为为许多种模式，在这里最需要关心配置是读写时钟、Fifo宽度与Fifo深度。Fifo的读写时钟有两种模式，可以配置为读写同步和读写异步模式，同步模式是即读写共用一个时钟，这样可以达到理论上最大的FMax，同时符合本设计的流水化需求，所以这里选择同步读写模式。同步读写模式的读写时序分别如图3-8-2和3-8-3，可见写入是实时的，而读出则有一个周期的延迟，并且Fifo内部数据的计数值和可读出的数据是同步的，所以只需要在第N行的计数值达到要求后使能第N行的读有效信号，隔一个周期之后使能第N+1行的写有效信号，同时将第N行的输出数据和第N+1行的输入数据连接到一起(第一行数据的输入应当为模块的输入数据)，最后，将每一行的输出拼接起来作为整个模块输出即可。

图3-8-2 Fifo写时序

图3-8-3 Fifo读时序

3.8.2 设计

根据原理可知，RowsGenerator核(以下简称RG核)需要考虑Fifo宽度与Fifo深度。Fifo宽度根据应用场合(待处理图像的色彩位宽)变换较大，同时考虑到本库所允许的色彩位宽范围为1-12，并且在整个可能的项目中色彩位宽变幻的可能性较高，会因为IP重名而导致综合错误，所以我将其分为了四个阶段，并为每个阶段单独设置了一个Fifo，如表3-8-1，随后使用generate语句，让综合器自动根据当前色彩位宽选择实例化哪一个生成器，实现资源和泛用性的一个平衡。

色彩位宽	Fifo宽度
1	1
2, 3, 4	4
5, 6, 7, 8	8
9, 10, 11, 12	12

表3-8-1 色彩位宽与Fifo宽度

对于Fifo的深度，则是根据当前图像宽度确定的，同时对于Fifo的IP核，其深度必须为2的幂，考虑到在一个项目中图像宽度几乎不会改变，所以我将Fifo深度的配置权交给了用户，用户可以自己设置这个深度来达到自己的需求。除此之外，由于行缓存确实需要消耗存储器资源，但对于一般的应用消耗的又并不多，无法填满块RAM的一个最小单位18K，使用块RAM可能会造成不必要的浪费，所以默认配置为使用分布式RAM来节约资源，带来的负面影响是会降低FMax，但综合考虑下，这是值得的，如果确实有需要很高速的应用，用户可以自行选择配置为其他模式的实现。综上，一个RG核需要的配置参数、端口和子模块如表3-8-2、表3-8-3和表3-8-4。

名字	类型	范围	默认值	说明
rows_width	无符号	2 - 15	3	行缓存宽度。
im_width	无符号	1 - 4096	320	图像宽度。
color_width	无符号	1 - 12	8	色彩位宽。
im_width_bits	无符号	取决于图像宽度	9	图像宽度的位宽。

表3-8-2 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，作为第一个fifo的写使能。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width * rows_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-8-3 端口

名字	类型	说明
Fifo	Fifo1xWidthRows	位宽为1并且深度为N的Fifo(1 < N < 4096)，用于构造色彩位宽为1的行缓存。你可以自己对fifo进行配置，但是在一个项目中所有的同名的fifo必须拥有同样的配置。同时你只能够更改写入深度和fifo实现的类型，它的读延迟必须为1！
Fifo	Fifo4xWidthRows	位宽为4并且深度为N的Fifo(1 < N < 4096)，用于构造色彩位宽为1的行缓存。你可以自己对fifo进行配置，但是在一个项目中所有的同名的fifo必须拥有同样的配置。同时你只能够更改写入深度和fifo实现的类型，它的读延迟必须为1！
Fifo	Fifo8xWidthRows	位宽为8并且深度为N的Fifo(1 < N < 4096)，用于构造色彩位宽为1的行缓存。你可以自己对fifo进行配置，但是在一个项目中所有的同名的fifo必须拥有同样的配置。同时你只能够更改写入深度和fifo实现的类型，它的读延迟必须为1！
Fifo	Fifo12xWidthRows	位宽为12并且深度为N的Fifo(1 < N < 4096)，用于构造色彩位宽为1的行缓存。你可以自己对fifo进行配置，但是在一个项目中所有的同名的fifo必须拥有同样的配置。同时你只能够更改写入深度和fifo实现的类型，它的读延迟必须为1！

表3-8-4 子模块

3.8.3 实现

根据3.8.2的设计便可以实现一个RG核，但考虑到如果这个RG核采用请求响应模式没有意义，用一般的AXI协议与其交互会使得效率低下且造成资源浪费，同时可能带来比较严重的时序问题，所以AXI版本的行缓存生成不在本节讨论，会用专门的AXI-Stream协议完成。故，此RG核仅有流水线模式。

3.8.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
rst_n为低时，系统复位，输出无效；否则当in_enable使能时，第一个fifo开始填充，之后每一个clk的上升沿都会送入一个数据进行处理，当所有的fifo都被填充到图像宽度的深度时，输出有效，之后每一个周期都将送出一个有效数据，波形如图3-8-4。

图3-8-4 流水线模式时序

3.8.3.2 IP核GUI

完成功能后对RG核进行了封装，封装如图3-8-5，im_width_bits根据自行im_width自动计算。

图3-8-5 RG核的GUI

3.8.4 仿真

RG核虽然对于所有图像都有意义，但一般用于灰度和二值图像的处理，所以我选取了一张图像的灰度模式与二值模式(来源于局部二值化，在后面的章节将会介绍)作为仿真源，并且考虑到仿真压力，仅测试了宽度为3和5的行缓存，原始图像如图3-8-6。

图3-8-6 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-8-7所示。

图3-8-7 仿真结果之一，行缓存宽度为5，左侧为HDL功能仿真结果，右侧为软件仿真结果

3.8.5 资源和时序

由于最终实现和Fifo配置关系很大，这里只对512x512，色彩位宽为8，窗口大小为3，同时使用分布式RAM的状况，根据Vivado生成的报表，主要资源耗费如表3-8-5。

Slice LUTs*	Slice Registers
610	237

表3-8-5 主要资源耗费

同时由于根据时序报告，在使用分布式RAM的情况下，最大的Data Path Delay(数据路径延迟)为3.514ns，即：

FMax = 284.57MHz

即说明，RG核在流水线模式下，理论上在处理1080p全高清图像时可以达到137帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.8.6 分析与结论

由于RG核与一般的图像处理不同，所以不能采用PSNR来评估，只能对比软件仿真和硬件仿真每一行的文本，完全相同时则为正确(OK)，得到的数据如表3-8-5。

1-3	1-5	2-3	2-5	Total
OK	OK	OK	OK	OK

表3-8-5 文本对比

可见RG核有效，同时在使用分布式RAM的情况下也可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013
[14] Xilinx, Vivado Design Suite, FIFO Generator v12.0, Product Guide, PG057 [EB/OL]. October 1 , 2014

感谢

仿真图像来源：
パセリ-絵描き見習い

【FPGA/图像处理】点操作——色彩反转

dtysky — Sunday, 17 May 2015 20:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。色彩反转可以看做是变换系数为-1时的对比度变换和变换系数为色彩最大值的亮度变换之和，但考虑到在对比度变换时引入符号计算会增加额外的资源和时序消耗，并且一般情况下也不会有负向对比度变换的需求，所以单独将其提出作为一个模块。色彩反转常用于需要反转背景和主题元素的应用，例如解决某些眼障人群对一些色彩搭配不适，又例如在印刷工艺中的负片等，本节将会介绍如何实现一个色彩反转的IP核。
这个IP核的资源在这里：
ColorReversal

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.7 点操作——色彩反转

色彩反转可以看做是变换系数为-1时的对比度变换和变换系数为色彩最大值的亮度变换之和，但考虑到在对比度变换时引入符号计算会增加额外的资源和时序消耗，并且一般情况下也不会有负向对比度变换的需求，所以单独将其提出作为一个模块。色彩反转常用于需要反转背景和主题元素的应用，例如解决某些眼障人群对一些色彩搭配不适，又例如在印刷工艺中的负片等，本节将会介绍如何实现一个色彩反转的IP核。

3.7.1 原理

色彩反转的基本原理公式如式3-7-1^[3]，由于此变换同样适用于任何色彩通道数量和任何色彩位宽的图像，所以需要针对这两个参数来调整IP核的结构，此公式表示了一个像素中一个通道的色彩是如何被变换的，Q为输出，I为输入，N为色彩位宽，可见实现此运算需要一次减法。

$$Q = (2^N - 1) - I\ \ \ \ \ \ \ \ (3-7-1)$$

但考虑到这种减法的特殊性，即用于减去I的被减数实际上是色彩位宽能够表示的无符号数的最大值，所以可以直接对输入I按位取反来得到输出Q，如式3-7-2，按位取反是简单快速的逻辑运算，理论上比减法的逻辑延时要小，并且实现也更为容易。

$$Q = \sim I\ \ \ \ \ \ \ \ (3-7-2)$$

可见，色彩反转需要若干次并行的取反运算，同时要根据色彩通道数量和色彩位宽做相应的适配。

3.7.2 设计

根据原理可知，除了第2章的接口标准外，实现一个ColorReversal核(以下简称CR核)也需要根据输入参数做一些适配，但考虑到每一个通道、每一位的运算完全等价，所以不用考虑逻辑复制，直接对输入的每一位取反即可。综上，最终需要的配置参数和端口分别如表3-7-1、表3-7-2所示。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
color_channels	无符号	无	3	色彩通道数量，1为灰度，3为RGB等等。
color_width	无符号	1 - 12	8	色彩位宽。

表3-7-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-7-2 端口

3.7.3 实现

根据3.7.2的设计便可以实现一个CR核，流水线和请求响应两种模式的实现方式如下：

3.7.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，out_ready输出为0，即输出无效，系统不工作；否则一个周期后第一个数据被输出，并且每一个clk的上升沿都会送入一个数据in_data进行处理，第一个输出数据有效之后，每一个周期都将送出一个有效数据，波形如图3-7-1。

图3-7-1 流水线模式时序

3.7.3.2 请求响应模式

基本同3.7.3.1，但输入数据in_data只有在in_enbale的上升沿才会被送入处理，波形如图3-7-2。

图3-7-2 请求响应模式时序

3.7.3.3 IP核GUI

完成功能后对CR核进行了封装，封装如图3-7-3。

图3-7-3 CR核的GUI

3.7.4 仿真

CR核对于所有图像输入都有意义，所以我选取了一张图像的RGB模式、灰度模式与二值模式(来源于局部二值化，在后面的章节将会介绍)作为仿真源，对每张图进行流水线和请求响应模式的测试，原始图像如图3-7-4，每一张图像的测试流程如下：

流水线模式conf -> 存入*-conf1-pipeline-hdlfun.*内 -> 请求响应模式conf -> 存入*-conf-reqack-hdlfun.*内。

图3-7-4 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-7-5所示。

图3-7-5 仿真结果，左侧为请求响应模式下的HDL功能仿真结果，中间为流水线模式下的HDL功能仿真结果，右侧为软件仿真结果

3.7.5 资源和时序

由于两种模式的基本构成大致相同，所以只对第一种模式进行分析，根据Vivado生成的报表，主要资源耗费如表3-7-3。

Slice LUTs*	Slice Registers
49	25

表3-7-3 主要资源耗费
根据时序报告，最大的Data Path Delay(数据路径延迟)为2.298ns，即：

FMax = 435.16MHz

即说明，CR核在流水线模式下，理论上在处理1080p全高清图像时可以达到210帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.7.6 分析与结论

根据仿真结果计算PSNR，得到的数据如表3-7-4。

1	2	3	Total
1000000.00	1000000.00	1000000.00	1000000.00

表3-7-4 PSNR

PSNR均值为极大值，可见LT核和软件方法完全等效，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013

感谢

仿真图像来源：
パセリ-Fallen

【FPGA/图像处理】点操作——亮度变换

dtysky — Sunday, 17 May 2015 01:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。亮度变换同样是最基础的图像增强运算之一，通过3.3的论述可知，亮度实际上是像素的各个通道色彩分量的一个线性函数，故可以通过更改每个通道的色彩值来进行亮度的变换。所以，亮度变换就是对图像中每一个像素的色彩进行增加或者减少的线性变换，与对比度变相相同，亮度变换的方式也有很多，差异也基本都是变换系数所造成的，系数为常数的变换为线性变换，否则为非线性变换，本节将讨论如何实现线性的亮度变换。
这个IP核的资源在这里：
LightnessTransform

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.6 点操作——亮度换变

亮度变换同样是最基础的图像增强运算之一，通过3.3的论述可知，亮度实际上是像素的各个通道色彩分量的一个线性函数，故可以通过更改每个通道的色彩值来进行亮度的变换。所以，亮度变换就是对图像中每一个像素的色彩进行增加或者减少的线性变换，与对比度变相相同，亮度变换的方式也有很多，差异也基本都是变换系数所造成的，系数为常数的变换为线性变换，否则为非线性变换，本节将讨论如何实现线性的亮度变换。

3.6.1 原理

任何亮度变换都是通过调整变换系数实现的^[3]，其变换的原理公式如式3-6-1，其中I为输入，Q为输出，lm_gain为变换系数，为有符号数，可见其本质实际上是映射函数的截距，当变换系数大于0时，亮度增强，否则对比亮度降低。对于线性变换，这个变换系数为常数，即对于所有的输入色彩，所执行的运算都是一致的，这种变换的结果是整张图像所有的像素都被等效变换。

$$Q=I + lm\_gain\ \ \ \ \ \ \ \ (3-6-1)$$

可见，对比度变换需要加法运算，同时由于对比度变换不仅仅适用于灰度图像，还适用于多通道的彩色图像，并且所有通道的变换形式都是一致的。所以需要提供一个配置接口，用以确定输入图像所含的通道数量，并通过通道数量来对基本的单通道变换复制进行最终变换的实现。

3.6.2 设计

根据原理可知，除了第2章的接口标准外，实现一个LightnessTransform核(以下简称LT核)还需要有符号加法、输出使能计数器和复位系统，执行加法的次数的数量由输入色彩的通道数量决定，并且每一个通道的运算都是一致的，这个运算有溢出的可能，所以在实现时要考虑对输出作出裁剪，当加法的结果为负数或者超出了当前色彩位宽所能表示的最大值时，比如对于8位色彩为255，则裁剪到0或255。例如，对于9位和9位的有符号加法，要将输出裁剪到允许的输出范围内，则如式3-6-2，其中Res为10位的相加结果，Q为最终输出，Res的最高位为符号位，次高位看作是溢出位，符号位决定是否裁剪到0，溢出位决定是否裁剪到255。

$$Q=\begin{cases} 0 && Res[9] = 1 \\Res[7 : 0] && Res[9] = 0 \ \&\ Res[8] = 0 \\255 & & Res[9] = 0 \ \&\ Res[8] = 1 \ \end{cases}.\ \ \ \ \ \ \ \ (3-6-2)$$

综上，最终需要的配置参数和端口分别如表3-6-1、表3-6-2所示。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
color_channels	无符号	无	3	色彩通道数量，1为灰度，3为RGB等等。
color_width	无符号	1 - 12	8	色彩位宽。

表3-6-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
lm_gain	input	有符号	color_width : 0	无	亮度变换系数，有符号数，当大于零时，它的值必须是原码，小于零时则必须是补码。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-6-2 端口

3.6.3 实现

根据3.6.2的设计便可以实现一个LT核，流水线和请求响应两种模式的实现方式如下：

3.6.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，out_ready输出为0，即输出无效，系统不工作；否则系统根据lm_gain进行工作，计数器在2个周期后使能输出有效，第一个数据被输出，并且每一个clk的上升沿都会送入一个数据in_data进行处理，第一个输出数据有效之后，每一个周期都将送出一个有效数据，波形如图3-6-1。

图3-6-1 流水线模式时序

3.6.3.2 请求响应模式

基本同3.6.3.1，但输入数据in_data只有在in_enbale的上升沿才会被送入处理，波形如图3-6-2。

图3-6-2 请求响应模式时序

3.6.3.3 IP核GUI

完成功能后对LT核进行了封装，封装如图3-6-3，work_mode被设计为键值对的模式，方便用户理解和选择，其它参数都根据实际状况加上了范围限定。

图3-6-3 LT核的GUI

3.6.4 仿真

LT核对于二值操作没有意义，所以我选取了一张图像的RGB模式和灰度模式作为仿真源，并分别设置了两套参数(理论上可以设置任意套参数)，参数如表3-6-3。

lm_gain
-90
100

表3-3-4 仿真参数

对每种参数进行流水线和请求响应模式的测试，原始图像如图3-6-4，每一张图像的测试流程如下：

流水线模式conf1 -> 存入*-conf1-pipeline-hdlfun.*内 -> 请求响应模式conf1 -> 存入*-conf1-reqack-hdlfun.*内 -> 流水线模式conf2 -> 存入*-conf2-pipeline-hdlfun.*内 -> 请求响应模式conf2 -> 存入*-conf2-reqack-hdlfun.*内。

图3-6-4 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-6-5所示。

图3-6-5 仿真结果，左侧为请求响应模式下的HDL功能仿真结果，中间为流水线模式下的HDL功能仿真结果，右侧为软件仿真结果

3.6.5 资源和时序

由于两种模式的基本构成大致相同，所以只对第一种模式进行分析，根据Vivado生成的报表，主要资源耗费如表3-6-4。

Slice LUTs*	Slice Registers
67	57

表3-6-4 主要资源耗费
根据时序报告，最大的Data Path Delay(数据路径延迟)为2.533ns，即：

FMax = 394.78MHz

即说明，LT核在流水线模式下，理论上在处理1080p全高清图像时可以达到190帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.6.6 分析与结论

根据仿真结果计算PSNR，得到的数据如表3-6-5。

1--90	1-100	2--90	2-100	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-6-5 PSNR

PSNR均值为极大值，可见LT核和软件方法完全等效，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013

感谢

仿真图像来源：
LM7-NL

【FPGA/图像处理】点操作——对比度变换

dtysky — Saturday, 16 May 2015 23:00:00 -00:00

其实俺也知道每个简单的操作都写这么一大篇很无聊，但论文就是这样的东西，不是么233？
图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。对比度变换属于图像增强的一种，图像增强，即增强图像中有用的信息，其目的是是改变图像的视觉想过，针对应用刻意强调图像整体或局部特征，是一个失真的过程。对比度变换是最基础的图像增强运算之一，由于人眼不仅仅是根据色彩的绝对值，还会根据某个区域和其周边的一个对比来得到整体的感受，这个“对比”量化后即为对比度。对比度变换的方式有很多，但差异基本都是变换系数所造成的，系数为常数的变换为线性变换，否则为非线性变换，本节将讨论如何实现线性的对比度变换。
这个IP核的资源在这里：
ContrastTransform

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.5 点操作——对比度变换

对比度变换属于图像增强的一种，图像增强，即增强图像中有用的信息，其目的是是改变图像的视觉效果，针对应用刻意强调图像整体或局部特征，是一个失真的过程。对比度变换是最基础的图像增强运算之一，由于人眼不仅仅是根据色彩的绝对值，还会根据某个区域和其周边的一个对比来得到整体的感受，这个“对比”量化后即为对比度。对比度变换的方式有很多，但差异基本都是变换系数所造成的，系数为常数的变换为线性变换，否则为非线性变换，本节将讨论如何实现线性的对比度变换。

3.5.1 原理

任何对比度变换都是通过调整变换系数实现的^[3]，对比度变换的原理公式如式3-5-1，其中I为输入，Q为输出，ct_scale为变换系数，可见其本质实际上是映射函数的斜率，当变换系数大于1时，对比度增强，否则对比度降低。对于线性变换，这个变换系数为常数，即对于所有的输入色彩，所执行的运算都是一致的，这种变换的结果是整张图像所有的像素都被等效变换。

$$Q=ct\_scale * I\ \ \ \ \ \ \ \ (3-5-1)$$

可见，对比度变换需要乘法运算，同时由于对比度变换不仅仅适用于灰度图像，还适用于多通道的彩色图像，并且所有通道的变换形式都是一致的。所以需要提供一个配置接口，用以确定输入图像所含的通道数量，并通过通道数量来对基本的单通道变换复制进行最终变换的实现。

3.5.2 设计

根据原理可知，除了第2章的接口标准外，实现一个ContrastTransform核(以下简称CT核)还需要若干乘法器、输出使能计数器和复位系统，乘法器的数量由输入色彩的通道数量决定，并且每一个通道的运算都是一致的，这个运算有溢出的可能，所以在实现时要考虑对输出作出裁剪，当乘法的结果超出了当前色彩位宽所能表示的最大值时，比如对于8位色彩为255，则裁剪到255，裁剪过程理论上是一个“大于”的比较过程，但考虑到FPGA在实现“大于”和“小于”运算综合后是加法器实现的，会造成一定的性能影响，所以这里采用“等于”运算来替代。例如，对于8位和8位的无符号乘法，要将输出裁剪为8位，则如式3-5-2，其中Res为16位的相乘结果，Q为最终输出，Res的高八位看作是溢出位，将这高八位组成一个新的无符号数，大于0时则可以判定为溢出。

$$Q=\begin{cases} Res[7 : 0] && Res[15 : 8] = 0 \\255 & & Res[15 : 8] \neq 0 \ \end{cases}.\ \ \ \ \ \ \ \ (3-5-2)$$

综上，最终需要的配置参数、端口和子模块分别如表3-5-1、表3-5-2与表3-5-3所示。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
color_channels	无符号	无	3	色彩通道数量，1为灰度，3为RGB等等。
color_width	无符号	1 - 12	8	色彩位宽。
mul_delay	无符号	取决于乘法器的配置。	3	乘法器输出延迟（流水线级数）。

表3-5-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
ct_scale	input	无符号	23 : 0	无	对比度变换系数，定点数，12bits.12bis。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-5-2 端口

名字	类型	说明
Mul	Multiplier12x24CT	12位无符号数和24位无符号数的乘法器，被用于定点数的乘法。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并且不能更改端口的配置！

表3-3-3 子模块

3.5.3 实现

根据3.5.2的设计便可以实现一个CT核，流水线和请求响应两种模式的实现方式如下：

3.5.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，out_ready输出为0，即输出无效，系统不工作；否则系统根据ct_scale进行工作，计数器在乘法器延迟加1个周期(默认为4)后使能输出有效，第一个数据被输出，并且每一个clk的上升沿都会送入一个数据in_data进行处理，第一个输出数据有效之后，每一个周期都将送出一个有效数据，波形如图3-5-1。

图3-5-1 流水线模式时序

3.5.3.2 请求响应模式

基本同3.5.3.1，但输入数据in_data只有在in_enbale的上升沿才会被送入处理，波形如图3-5-2。

图3-5-2 请求响应模式时序

3.5.3.3 IP核GUI

完成功能后对CT核进行了封装，封装如图3-5-3，work_mode被设计为键值对的模式，方便用户理解和选择，其它参数都根据实际状况加上了范围限定。

图3-5-3 CT核的GUI

3.5.4 仿真

CT核对于二值操作没有意义，所以我选取了一张图像的RGB模式和灰度模式作为仿真源，并分别设置了两套参数(理论上可以设置任意套参数)，参数的选取原则是不可由有限二进制定点数表示，以此来得到最坏情况下的PSNR，参数如表3-5-4。

ct_scale
0.2
3.3

表3-5-4 仿真参数

对每种参数进行流水线和请求响应模式的测试，原始图像如图3-5-4，每一张图像的测试流程如下：

流水线模式conf1 -> 存入*-conf1-pipeline-hdlfun.*内 -> 请求响应模式conf1 -> 存入*-conf1-reqack-hdlfun.*内 -> 流水线模式conf2 -> 存入*-conf2-pipeline-hdlfun.*内 -> 请求响应模式conf2 -> 存入*-conf2-reqack-hdlfun.*内。

图3-5-4 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-5-5所示。

图3-5-5 仿真结果，左侧为请求响应模式下的HDL功能仿真结果，中间为流水线模式下的HDL功能仿真结果，右侧为软件仿真结果

3.5.5 资源和时序

由于两种模式的基本构成大致相同，所以只对第一种模式进行分析，根据Vivado生成的报表，主要资源耗费如表3-5-5。

Slice LUTs*	Slice Registers	DSP
38	27	3

表3-5-5 主要资源耗费
根据时序报告，最大的Data Path Delay(数据路径延迟)为2.746ns，即：

FMax = 364.16MHz

即说明，CT核在流水线模式下，理论上在处理1080p全高清图像时可以达到175帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.5.6 分析与结论

根据仿真结果计算PSNR，得到的数据如表3-5-6。

1-0.2	1-3.3	2-0.2	2-3.3	Total
55.11	61.09	55.09	59.53	57.70

表3-5-6 PSNR

PSNR均值为57.70，可见CT核满足处理要求，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013

感谢

仿真图像来源：
LM7-sn

【FPGA/图像处理】点操作——阈值化

dtysky — Saturday, 16 May 2015 01:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。阈值化是另一个基本操作，和灰度化一样，它简单地将图像像素分为两类，主要目的是简化后续的计算成本，以及节省存储空间，不过更为彻底。阈值化有二值阈值化，也有多值阈值化，但运用最多的还是二值阈值化，即“二值化”，经过二值化处理后的图像只有两个值——黑色和白色，这样便可以用最小的代价来表示整幅图像的形态特征。阈值化往往被用作某些操作的预处理，比如某些形态学操作(腐蚀，膨胀)就是基于二值图像的。阈值化的阈值可以有许多种来源，由此可以区分为自动阈值化、局部阈值化等等，但本节只讨论最基本的全局阈值化算法。
这个IP核的资源在这里：
Threshold

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.4 点操作——阈值化

阈值化是另一个基本操作，和灰度化一样，它简单地将图像像素分为两类，主要目的是简化后续的计算成本，以及节省存储空间，不过更为彻底。阈值化有二值阈值化，也有多值阈值化，但运用最多的还是二值阈值化，即“二值化”，经过二值化处理后的图像只有两个值——黑色和白色，这样便可以用最小的代价来表示整幅图像的形态特征。阈值化往往被用作某些操作的预处理，比如某些形态学操作(腐蚀，膨胀)就是基于二值图像的。阈值化的阈值可以有许多种来源，可以为线性的，也可以为非线性的，由此可以区分为自动阈值化、局部阈值化等等，但本节只讨论最基本的全局阈值化算法。

3.4.1 原理

所有的全局阈值化算法都有一个共同的特点，即整张图像都使用同一个阈值，这样做的基本策略是将图像中的每一个像素都与一个固定的阈值进行比较，然后根据比较的结果确定输出。一般的全局阈值化算法原理如式3-4-1，当某个像素的值I大于确定的阈值th时，输出结果Q为1，否则为0。

$$Q=\begin{cases} 0 && I <= th \\1 & & I > th \ \end{cases}.\ \ \ \ \ \ \ \ (3-4-1)$$

这样做有一个明显的缺点，就是会造成一些“误分类”，即将一些像素分类到我们所不期望的一侧去，这可以通过调整阈值来确定，但这并不总是有效的。由此，便产生了像是了局部阈值化这样的算法来解决这个问题，但这类算法往往要求比较复杂的前置过程，除了这类算法之外，在一些状况下还有一种简单的算法——等高线阈值化^[3]。
等高线阈值化的原理如式3-4-2，它要求两个阈值th1和th2，处于二者之间的像素被分类到1，否则为0。之所以称为等高线阈值化，是因为在像素值变化缓慢的图像中，像素的选择就像地图上的等高线一样。一般在选取同样合理的阈值的状况下，等高线阈值化能够比一般的全局阈值化保留更丰富的边界信息，在一些要求情况下也可以直接将其作为边界检测子来使用。

$$Q=\begin{cases} 0 && I <= th1 \\1 & & th1 < I <= th2 \\ 0 & & I > th2 \ \end{cases}.\ \ \ \ \ \ \ \ (3-4-2)$$

可见，阈值化运算并不涉及数值计算，只有简单的比较和分类，所以理论上可以直接采用组合逻辑实现。

3.4.2 设计

根据原理可知，由于逻辑比较简单清晰，所以只需要考虑第2章的接口标准外即可，并且可以直接使用组合逻辑实现，但考虑到一个单独的模块采用组合逻辑可能会造成与其他模块组合逻辑的串联，这样会增加整体的路径延迟，降低FMax，故本库中即使是一些简单的操作也会至少使用加一级缓冲，采用一级流水线进行实现。综上，实现一个Threshold核(以下简称TH核)需要配置参数、端口分别如表3-4-1和表3-4-2所示。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
color_width	无符号	1 - 12	8	色彩位宽。

表3-4-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
th_mode	input	无符号	0为基本全局阈值化，1为等高线阈值化	无	操作方法。
th1	input	无符号	color_width - 1 : 0	无	阈值1，用于两种模式。
th2	input	无符号	color_width - 1 : 0	无	阈值2，只能用于等高线阈值化模式。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-4-2 端口

3.4.3 实现

根据3.4.2的设计便可以实现一个TH核，流水线和请求响应两种模式的实现方式如下：

3.4.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，out_ready输出为0，即输出无效，系统不工作；否则系统根据th_mode、th1和th2的值进行工作，一个周期后输出第一个数据，并且每一个clk的上升沿都会送入一个数据in_data进行处理，第一个输出数据有效之后，每一个周期都将送出一个有效数据，波形如图3-4-1。

图3-4-1 流水线模式时序

3.4.3.2 请求响应模式

基本同3.4.3.1，但输入数据in_data只有在in_enbale的上升沿才会被送入处理，波形如图3-4-2。

图3-4-2 请求响应模式时序

3.4.3.3 IP核GUI

完成功能后对TH核进行了封装，封装如图3-4-3，work_mode被设计为键值对的模式，方便用户理解和选择，其它参数都根据实际状况加上了范围限定。

图3-4-3 TH核的GUI

3.4.4 仿真

TH核只对灰度图像有意义，所以我选取了两张灰度模式的图像，并分别设置了两套参数(理论上可以设置任意套参数)，对一般全局阈值化和等高线阈值化的模式进行配置，参数如表3-4-3。

mode	th1	th2
Base	128	0
Contour	50	200

表3-4-3 仿真参数

其中Base模式为一般全局阈值化，而Contour为等高线阈值化，对每种参数进行流水线和请求响应模式的测试，原始图像如图3-4-4，每一张图像的测试流程如下：

流水线模式conf1 -> 存入*-conf1-pipeline-hdlfun.*内 -> 请求响应模式conf1 -> 存入*-conf1-reqack-hdlfun.*内 -> 流水线模式conf2 -> 存入*-conf2-pipeline-hdlfun.*内 -> 请求响应模式conf2 -> 存入*-conf2-reqack-hdlfun.*内。

图3-4-4 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-4-5所示。

图3-4-5 仿真结果，左侧为请求响应模式下的HDL功能仿真结果，中间为流水线模式下的HDL功能仿真结果，右侧为软件仿真结果

3.4.5 资源和时序

由于两种模式的基本构成大致相同，所以只对第一种模式进行分析，根据Vivado生成的报表，主要资源耗费如表3-4-4。

Slice LUTs*	Slice Registers
11	2

表3-4-4 主要资源耗费
根据时序报告，最大的Data Path Delay(数据路径延迟)为2.671ns，即：

FMax = 374.39MHz

即说明，TH核在流水线模式下，理论上在处理1080p全高清图像时可以达到180帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.4.6 分析与结论

首先分析基本全局阈值化和等高线阈值化的效果，如图3-4-6和3-4-7所示，在给定参数的情况下，等高线阈值化对于边缘的保留的确更为完整，分类更为有效。

图3-4-6 一般全局阈值化结果

图3-4-7 等高线阈值化结果

根据仿真结果计算PSNR，得到的数据如表3-4-5。

1-Base-128-0	1-Contour-50-200	2-Base-128-0	2-Contour-50-200	Total
1000000.00	1000000.00	1000000.00	1000000.00	1000000.00

表3-4-5 PSNR

PSNR均值为极大值，可见TH核和软件处理完全等效，同时可以达到不错的FMax，设计成功。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013

感谢

仿真图像来源：
H2SO4-蝶
 パセリ-Favour

【FPGA/图像处理】点操作——灰度化

dtysky — Friday, 15 May 2015 18:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。灰度化是最基本的图像操作之一，它的目的是把一个具有RGB三个灰度通道的图像转换为只具有一个灰度通道的图像，这样做的目的主要是减少后期操作的运算量，因为对于许多应用而言，例如边缘检测、角点识别等，一个灰度通道就已经提供了足够的信息量，甚至在很多情况下，多通道的灰度图会在提高计算复杂度的同时降低运算效果。灰度化属于点操作，一个像素的输出只取决于一个像素的输入，输出像素是输入像素的一个映射，本节将会探讨如何用FPGA实现图像的灰度化。
这个IP核的资源在这里：
Graying

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.3 点操作——灰度化

灰度化是最基本的图像操作之一，它的目的是把一个具有RGB三个灰度通道的图像转换为只具有一个灰度通道的图像，这样做的目的主要是减少后期操作的运算量，因为对于许多应用而言，例如边缘检测、角点识别等，一个灰度通道就已经提供了足够的信息量，甚至在很多情况下，多通道的灰度图会在提高计算复杂度的同时降低运算效果。灰度化属于点操作，一个像素的输出只取决于一个像素的输入，输出像素是输入像素的一个映射，本节将会探讨如何用FPGA实现图像的灰度化。

3.3.1 原理

灰度化的算法有许多种，最直观的如式3-3-1，即将去三个通道的平均值作为灰度化的结果，这个算法虽然符合一般的逻辑规律，但却不符合人类的视觉，业界通用的灰度化算法如式3-3-2，这个算法在ITU-R(ITU Radiocommunication Sector，国际电信联盟无线电通信组)的ITU BT.601建议书^[12]中被定义。根据彩色电视系统的传输要求，色彩信号被分为亮度信号Y和色差信号R-Y、G-Y与B-Y，实际传输时只需要传输亮度信号和任意两个色差信号即可。实际上，亮度信号是根据人类的视觉心理原理计算的，它体现了各个基色的亮度总和。

$$Y = \frac{Red + Green + Blue}3\ \ \ \ \ \ \ \ (3-3-1)$$
$$Y = Red * 0.299 + Green* 0.587 + Blue * 0.114\ \ \ \ \ \ \ \ (3-3-2)$$

所以一次灰度化运算要执行三次乘法和两次加法，其中每一次乘法都是一个固定系数的小数和一个整数的乘法，加法的位数根据每一个通道的色彩位宽而定，由于本项目中色彩位宽被限定为1-12，考虑到FPGA的特性，在一次灰度化运算中，最多可能需要执行三次定点数乘法和两次12位的无符号加法运算。

3.3.2 设计

根据原理可知，除了需要考虑第2章的接口标准外，还需要使用三个乘法器和两个加法器，乘法器必须使用厂商提供的专用IP核实现，同时为了最高的FMax，一个周期内实现两次12位的加法是不被允许的，所以我将两次加法进行了拆分，设置了缓冲寄存器。不仅如此，考虑到实际应用场合的复杂，完全设定好的乘法器并不能够满足要求，所以我选择将乘法器的配置权交给用户，设定一个配置参数来让用户在配置好乘法器后修改流水线级数，以匹配乘法器的配置，综上，实现一个Graying核(以下简称GY核)需要配置参数、端口以及子模块分别如表3-3-1、表3-3-2和表3-3-3所示。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
color_width	无符号	1 - 12	8	色彩位宽。
mul_delay	无符号	取决于乘法器的配置。	3	乘法器延迟

表3-3-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。

表3-3-2 端口

名字	类型	说明
MulRed	MultiplierRedx0d299	12位无符号数和0.299的定点乘法器，被用于红色通道的计算。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并不能更改端口的配置！
MulGreen	MultiplierGreenx0d587	12位无符号数和0.587的定点乘法器，被用于绿色通道的计算。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并不能更改端口的配置！
MulBlue	MultiplierBluex0d114	12位无符号数和0.113的定点乘法器，被用于蓝色通道的计算。你可以自己配置这个乘法器，然后更改"mul_delay"，但所有的乘法器必须拥有相同的流水线级数，并不能更改端口的配置！

表3-3-3 子模块

3.3.3 实现

根据3.3.2的设计便可以实现一个GY核，此核主要由一个三个执行定参数定点数的乘法器、一个输出使能延时计数器、复位系统和两次12位的无符号数加法构成。乘法器使用厂商提供的乘法器IP核，这里使用的是Vivado中的乘法器IP核，这个IP核可以被配置为许多种模式^[13]，对于定参数的乘法，它的实现方式可以被配置为Distributed Memory(分布式存储器),Block Memory(块存储器)以及Dedicated Multiplier(专用乘法器)，前两者相当于建立一个查找表，用查表的方式来计算乘法，其需求的最佳流水线级数比较小，但逻辑延迟比较大，后者相反，这个可以根据用户自身的需求而定，本节默认配置为专用乘法器实现，以得到理论上最大的FMax。同时，为了达到资源和精度之间的平衡，GY核将使用24位的定点数来近似表示每一个参数，例如对于0.299，它的定点数为：

0.299 ≈ 0.010011001000101101000011 = 0.298999965...

可见完全满足要求，同时，为了达到最高的FMax，并考虑到此GY核对舍入方式不敏感，所以这里的舍入没有采用FR核(见3.1)，而是采用向下舍入的方式，直接将定点后的小数位截断，这等同于软件仿真中的int(x)强制类型转换。
而对于加法，由于要达到最高的FMax，在考察了Xilinx专用加法器的流水线后，发现12位无符号加法的最佳流水线级数为1级，所以直接采用自己设计的一级流水线和加法运算符即可实现，实现两次加法总共需要两级流水线，消耗两个周期。
综上，流水线和请求响应两种模式的实现方式如下：

3.3.3.1 流水线模式

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，输出使能延迟计数器不工作，out_ready输出为0，即输出无效，系统不工作；否则计数器工作，直到指定延迟周期(默认为5个周期)后，输出有效，并且每一个clk的上升沿都会送入一个数据in_data进行处理，第一个输出数据有效之后，每一个周期都将送出一个有效数据，波形如图3-3-1。

图3-3-1 流水线模式时序

3.3.3.2 请求响应模式

基本同3.3.3.1，但输入数据in_data只有在in_enbale的上升沿才会被送入处理，波形如图3-3-2。

图3-3-2 请求响应模式时序

3.3.3.3 IP核GUI

完成功能后对GY核进行了封装，封装如图3-3-3，work_mode被设计为键值对的模式，方便用户理解和选择，其它参数都根据实际状况加上了范围限定。

图3-3-3 GY核的GUI

3.3.4 仿真

GY核只对RGB图像有意义，所以我选取了三张RGB模式的图像，分别对它们进行了流水线和请求响应模式的测试，原始图像如图3-3-4，每一张图像的测试流程如下：

流水线模式 -> 存入*-pipeline-hdlfun.*内 -> 请求响应模式 -> 存入*-reqack-hdlfun.*内。

图3-3-4 原始测试图像

使用HDL功能仿真和软件仿真的结果进行PSNR的计算，仿真结果如图3-3-5所示。

图3-3-5 仿真结果，左侧为请求响应模式下的HDL功能仿真结果，中间为流水线模式下的HDL功能仿真结果，右侧为软件仿真结果

3.3.5 资源和时序

由于两种模式的基本构成大致相同，所以只对第一种模式进行分析，并且由于这里的乘法器配置采用的是专用乘法器，所以资源消耗和其他模式可能差距较大，仅供参考。根据Vivado生成的报表，主要资源耗费如表3-3-4。

Slice LUTs*	Slice Registers	DSPs
28	26	3

表3-3-3 主要资源耗费
根据时序报告，最大的Data Path Delay(数据路径延迟)为2.265ns，即：

FMax = 441.50MHz

即说明，GY核在流水线模式下，理论上在处理1080p全高清图像时可以达到212帧。
由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.3.6 分析与结论

根据仿真结果计算PSNR，得到的数据如表3-3-4。

1	2	3	Total
46.73	46.96	46.83	46.84

表3-3-4 PSNR

PSNR均值为46.84，可见GY核完全满足图像处理的要求，在配置灵活性高的情况下可以达到很高的FMax，设计成功。

参考文献

[12] ITU-R, Recommendation ITU-R BT.601-7, Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios [EB/OL]. 03/2011
[13] Xilinx, Vivado Design Suite, LogiCORE IP Multiplier v12.0, Product Guide, PG108 [EB/OL]. April 2, 2014

感谢

仿真图像来源：
041-尾翼
 月岡月穂-星を呑む
 LM7-xxxまとめ

【FPGA/图像处理】生成器——帧控制

dtysky — Thursday, 14 May 2015 17:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。帧缓存是FPGA图像处理的一个基本单元，它缓存一张完整的图像，而一张完整的图像是所有图像处理的基础，它为一切操作提供数据源，所以它的泛用性是很高的。一般FPGA中的帧缓存都是用ram来实现的，这些ram可以分为sram和sdram两种，前者控制简单，效率高，后者则控制较为复杂。这一节将会探讨如何使用Xilinx的FPGA中的RAM资源作为帧缓存，并对其进行控制。
这个IP核的资源在这里：
FrameController

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.2 生成器——帧控制

帧缓存是FPGA图像处理的一个基本单元，它缓存一张完整的图像，而一张完整的图像是所有图像处理的基础，它为一切操作提供数据源，所以它的泛用性是很高的。一般FPGA中的帧缓存都是用RAM(Random Access Memory，随机存储器)来实现的，这些RAM可以常用的可以分为SRAM(Static Random Access Memory，静态随机存储器)和SDRAM(Synchronous Dynamic Random Access Memory，同步动态随机存储器)两种，前者控制简单，效率高，后者则控制较为复杂。这一节将会探讨如何设计一个FramController核(以下简称FC核)对以Xilinx的FPGA中的RAM资源为基础的帧缓存进行控制。

3.2.1 原理

一般FPGA器件中的片内RAM分为两种，BlockRAM（块存储器，以下称BRAM）和DistributeRAM（分布式存储器，以下称DRAM）^[9]，两者本质上都是SRAM。不同的是前者是一些被集中在一些区域的专用存储器，后者是利用器件内的LUT构成的RAM。一般而言，BRAM的资源比较丰富，并且速度比较快，但由于其自身的特性，这些RAM被分为36K和18K两种形式，使用BRAM的单位是18Kb的倍数，所以在很多情况下会造成资源的浪费，另一方面，由于这些RAM的位置是固定的，所以在布局布线上可能会造成更多的延迟。而分布式RAM则正好相反，由于使用的是LUT，所以资源比较少，但比较灵活，不容易造成浪费。
对于帧缓存，考虑其一般比较大并且读写要求比较高，采用BRAM比较合适，但即使是BRAM，对于一些比较大的图像也是难以胜任的，中低端的FPGA器件的片内BRAM是比较少的，比如对于用于测试的xlg7Z010clg400，片内RAM只有256kb^[10]。这时只能够采用SDRAM进行扩展，但考虑到本项目主要论述的是图像处理的算法，所以不加以讨论。
在Vivado中，RAM的配置被分为许多种^[11]，比如Single Port RAM(单口RAM，只有一个读写数据的端口)，Simple Dual Port RAM(简单双口RAM，两个端口，但是只有一个端口可以写入)，True Dual Port RAM(真双口RAM，两个端口都可以写入)等，对于帧缓存，一般采用的是Simple Dual Port RAM，这种配置方式下的RAM读写时序如图3-2-1^[11]所示。

图3-2-1 RAM读写时序
可见，对于写操作，只需要使得地址和数据同步送入RAM相应端口即可，而对于读操作，则需要有一定的延迟，这个延迟是根据配置时选择插入的寄存器来决定的，对于不同的应用插入的级数不同，Vivado中可以最多插入三个寄存器来形成三级流水线，如图3-2-2^[11]所示。

图3-2-2 三级流水线下的读操作

3.2.2 设计

根据原理并综合第2章的接口标准，实现一个针对Xilinx器件的BRAM控制器，即这里的FC核需要的配置参数和端口分别如表3-2-1和表3-2-2所示。

名字	类型	范围	默认值	说明
work_mode	无符号	0为流水线模式，1为请求响应模式	0	模块的工作模式。
wr_mode	无符号	0为写，1为读。	0	模块的读写模式。
data_width	无符号	无	8	数据位宽。
im_width	无符号	1 - 4096	320	图像宽度。
im_height	无符号	1 - 4096	240	图像高度。
addr_width	无符号	取决于图像的宽度和高度。	17	存储帧缓存的RAM的地址位宽。
ram_read_latency	无符号	0 - 15，取决于RAM。	2	RAM的读延迟，在Xilin器件中，典型为2。
row_init	无符号	取决于输入的行偏移。	0	你想要写入的第一行的偏移，取决于应用，比如窗口。

表3-2-1 配置参数

名字	端口	类型	范围	默认值	说明
clk	输入	无符号	无	无	Clock.
rst_n	输入	无符号	无	无	复位，低有效。
in_enable	输入	无符号	无	无	输入数据使能，在流水线模式下，它是另一个复位信号，在请求响应模式下，只有在它有效的时候in_data才会被真正地改变。
in_data	输入	无符号	color_width - 1 : 0	无	输入数据，必须和in_enable同步输入。
out_ready	output	无符号	无	无	输出数据有效，在两种模式下，这个信号都会在out_data可以被读取的时候有效。
out_data	output	无符号	color_width - 1 : 0	无	输出数据，将会和out_ready同步输出。
ram_addr	output	无符号	addr_width - 1 : 0	无	输出到RAM的地址。

表3-2-2 端口

3.2.3 实现

根据配置参数和端口的设计便可以实现一个FC核，此核主要由一个地址输出计数器、一个读使能延时计数器和复位系统构成，由于工作模式有流水线和请求响应两种，读写模式也有两种，所以总共有四种模式，这些模式的实现方式如下：

3.2.3.1 流水线模式写

保证地址和数据同步流水化输出，在复位时二者皆输出为0，实现如下：
in_enable或rst_n为低时，out_ready输出为0，即输出无效，此时地址计数器不工作；否则输出有效，计数器在每个clk的上升沿加1，直到加满根据用户设定的宽和高算出来的地址最大值，开始下一次循环，波形如图3-2-3。

图3-2-3 流水线模式写入时序

3.2.3.2 流水线模式读

基本同3.2.3.1，但在工作模式时，读使能计数器首先有效，在地址输入后的ram_read_latency个周期后，读使能计数器锁定，并输出第一个有效值，之后每个周期都会输出一个有效值，波形如图3-2-4。

图3-2-4 流水线模式读出时序

3.2.3.3 请求响应模式写

地址和数据同步输出，一次请求一次响应输出，复位时输出为0，实现如下：
基本同3.2.3.1，但地址计数器只有在in_enable的上升沿才会加1，波形如图3-2-5。

图3-2-5 请求响应模式写入时序

3.2.3.4 请求响应模式读

基本同3.2.3.2，但变为一次请求一次响应输出，地址计数器只有在in_enable的上升沿才会加1，波形如图3-2-6。

图3-2-6 请求响应模式写入时序

3.2.3.5 IP核GUI

完成功能后对FC核进行了封装，封装如图3-2-7，work_mode和wr_mode被设计为键值对的模式，方便用户理解和选择，其它参数都根据实际状况加上了范围限定，addr_width使用expr表达式交由软件自行计算。

图3-2-7 FC核的GUI

3.2.4 仿真

FC核没有软件仿真，并且综合考虑到BRAM在仿真时的配置不便和仿真效率，HDL功能仿真只支持512x512像素和灰度模式下的图像，我选取了三张这样的图像，分别对它们进行了每一种模式进行了测试，每一张图像的测试流程如下：

流水线模式写RAM的仿真模型 -> 流水线模式读RAM的仿真模型 -> 存入*-pipeline-hdlfun.*内 -> 请求响应模式写RAM的仿真模型 -> 请求响应模式读RAM的仿真模型 -> 存入*-reqack-hdlfun.*内。

由于没有软件仿真，所以将原图像作为了软件仿真的结果，用来进行PSNR的计算，仿真结果如图3-2-8所示，保存为bmp格式是为了防止压缩时带来的差异影响到PSNR的计算。

图3-2-8 仿真结果，左侧为请求响应模式下的HDL功能仿真结果，中间为流水线模式下的HDL功能仿真结果，右侧为软件仿真结果

3.2.5 资源和时序

由于四种模式的基本构成大致相同，所以只对第一种模式进行分析，根据Vivado生成的报表，主要资源耗费如表3-2-3。

Slice LUTs*	Slice Registers
38	17

表3-2-3 主要资源耗费
根据时序报告，最大的Data Path Delay(数据路径延迟)为1.921ns，即：

FMax = 520.56MHz

由于数据路径延迟和应用的最终约束设置强相关，所以仅供参考。

3.2.6 分析与结论

根据仿真结果计算PSNR，得到的数据如表3-2-4。

1	2	3	Total
1000000.00	1000000.00	1000000.00	1000000.00

表3-2-4 PSNR

PSNR均值为极大值，可见FC核可以完美完成帧缓存的控制，同时资源利用率很低，可以达到很高的FMax，超过了BRAMFMax的极限，设计成功。

参考文献

[9] Xilinx, Xilinx 7 Series FPGAs Embedded Memory Advantages, WP377 (v1.1) [EB/OL]. February 17, 2012
[10] Xilinx,7 Series FPGAs Memory Resources, User Guide, UG473 (v1.11) [EB/OL]. November 12, 2014
[11] Xilinx, Vivado Design Suite, Block Memory Generator v8.2, LogiCORE IP Product Guide, PG058 [EB/OL]. April 1, 2015

感谢

仿真图像来源：
月岡月穂-ゆらゆら
 LM7-oxford eleKtricity
cotta-池

【FPGA/图像处理】算术系统

dtysky — Monday, 11 May 2015 19:00:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。图像处理中会用到一些基本的数学运算，这些运算构成一个算术系统，对于FPGA而言，如何在资源和运行频率之间保持平衡是一个基本的考量。本节将会说明如何在FPGA中实现符号数、定点数和函数的一些运算。

3 算法实现

明确了设计和架构，便可以进行算法的实现。本章将会说明如何实现图像处理的算法，以及如何运用它们。

3.1 算术系统

图像处理中会用到一些基本的数学运算，这些运算构成一个算术系统，对于FPGA而言，如何在资源和运行频率之间保持平衡是一个基本的考量。本节将会说明如何在FPGA中实现符号数、定点数和函数的一些运算。

3.1.1 Verilog的符号系统

在VerilogHDL2001的标准^[7]中，符号系统被加入，在使用时只需要加一个"signed"标志便可以将某一个变量标记成符号数，例如：

reg signed[7 : 0] num;

这表示定义了一个八位的寄存器型符号数num。
在Verilog中，符号数是以如表3-1-1的形式存在的，这也是目前DSP中最流行的符号系统。可见，所有的正数以原码形式保存，而负数则以2的补码的形式存在，2的补码的公式定义如式3-1-1。

$$X = -2^{N-1} + \sum_{n=0}^{N-2}x_n 2^n\ \ \ \ \ \ \ \ (3-1-1)$$

其在Verilog中的求得方式如下：

comp = {true_sign, ~true_num + 1}

其中comp表示补码,true_sign表示原码的符号位，true_num表示原码的数据位，可见，2的补码实质上就是在保留符号位的前提下，对数据位的每一位取反后整体加1。

Decimal Value	Signed Representation
3	3'b011
2	3'b010
1	3'b001
0	3'b000
-1	3'b111
-2	3'b110
-3	3'b101
-4	3'b100

表3-1-1 3bits的符号数

在实际使用中，考虑到与软件系统的兼容性，由于软件系统底层的符号系统一般也是使用2的补码对负数进行处理，所以所有具有符号数输入的模块都要求采用补码形式，对于原码，我提供了一个原码转换补码的模块，模块实现如下：

module True2Comp(
    true,
    complement);
    parameter data_channel = 1;
    parameter data_width = 17;
    input[data_channel * data_width - 1 : 0] true;
    output[data_channel * data_width - 1 : 0] complement;
    genvar i;
    generate
        `define h (i + 1) * data_width - 1
        `define l i * data_width
        for (i = 0; i < data_channel; i = i + 1) begin
            assign complement[`h : `l] = true[`h] == 0 ? 
                true[`h : `l] : {1'b1, ~true[`h - 1 : `l] + 1};
        end
        `undef h
        `undef l
    endgenerate
endmodule

此核为T2C核，T2C核的原理是——如果输入是正数，返回原码，否则对每一位进行取反，然后整体加1。T2C核可以完成任何位任何通道的原码到补码的转换。
Verilog中符号数的计算包含加法和乘法，减法使用相反数的加法代替，除法则需要专用电路实现，在简单应用中往往采用移位或者查找表来实现，这里不做讨论。在图像处理中，符号数的运算会涉及溢出问题，由于可以设置足够的保护位来防止运算本身的溢出，所以唯一需要考虑的溢出就是图像意义下的溢出，比如色彩为数为8的时候，255就是一个溢出上限，而由于一般状况下色彩和坐标都应当正值，所以0一般都作为一个溢出下限，所以这个时候需要一套舍入系统来完成结果的舍入，这一系统将在3.1.3中讨论。

3.1.2 定点数系统

在FPGA的图像处理所需要的算术系统中，另一个重要的系统是定点数系统，它的存在可以让FPGA进行小数运算，这对于图像增强或者几何变换等操作是必要的。一般而言，可以把定点数系统看做是整数系统的一个扩展，或者说将整数系统看做定点数系统的一个特例。在定点数系统中，我们人为地在某两个数字之间插入一个小数点的标志，来分割整数部分和小数部分，如表3-1-2所示。它和整数系统唯一不同的地方在于，整数系统的这个小数点永远处于最低位的右侧。同时，定点数所表示的数值与一致，均为式3-1-2的形式，包括符号定点数的计算公式也是与式3-1-1一致的，但n的范围则由原来的

([0, \infty])

，扩展到了

([-\infty, \infty])

，所以表3-1-2表示的实际上是3.5。
$$X = \sum x_n2^n\ \ \ \ \ \ \ \ (3-1-2)$$

Integral part

Point

Fractional part

表3-1-2 4bits.4bits的定点数

定点数的运算和整数运算过程基本一致，不同的是我们需要根据小数运算的规则对结果进行分割，来确立整数位和小数位，比如对于乘法，就需要将原先两个乘数的小数位的位宽相加，作为结果的小数位位宽，如表3-1-3。

Src1			0	1	.	1	0
Src2			0	1	.	1	0
Res	0	0	1	0	.	0	1	0	0

表3-1-3 定点数的乘法

3.1.3 舍入系统

由于图像处理所操作的数据基本都是有范围限制的整数，所以一个舍入系统是必要的，这个系统的作用在于对溢出的数据进行合理的截断，以及将小数舍入的整数。在这个项目中，我选择的是就近舍入，即将舍入到最近的数字，这也是软件算术系统中所广泛使用的。比如，对于一个16bits，定点位为8的定点数，其舍入规则如式3-1-3所示。

$$Res=\left\{\begin{aligned} 0 && Src < 0 \\255 & & Src>255\\ x + 1 & & Src = x.(5-9)\ \& \ x>0 \\x - 1 & & Src = x.(0-4)\ \& \ x>0 \\x - 1 & & Src = x.(5-9)\ \& \ x<0 \\x + 1 & & Src = x.(0-4)\ \& \ x<0 \ \end{aligned}\right.\ \ \ \ \ \ \ \ (3-1-3)$$

对于溢出，一个简单的边界检查便可以达到目的，而对于定点数的小数向整数的舍入，则需要先将定点数转换为原码，而后进行截断，再转换为补码，而后根据原来的补码进行最终的舍入，下面的FR核完成了这个功能：

module FixedRound(
    clk,
    fixed_num,
    round
    );
    parameter num_width = 42;
    parameter fixed_pos = 16;
    input clk;
    input signed [num_width - 1 : 0] fixed_num;
    output signed [num_width - fixed_pos - 1 : 0] round;
    reg signed [num_width - 1 : 0] num_true;
    reg signed [num_width - fixed_pos - 1 : 0] num_comp, tmp_comp;
    reg signed [num_width - fixed_pos - 1 : 0] reg_round;
    assign round = reg_round;
    always @(posedge clk) begin
        num_orig <= fixed_num[num_width - 1] == 0 ? fixed_num : 
            {fixed_num[num_width - 1], ~(fixed_num[num_width - 2 : 0] - 1)};
        num_comp <= num_orig[num_width - 1] == 0 ? num_orig[num_width - 1 : fixed_pos] : 
            {num_orig[num_width - 1], ~num_orig[num_width - 2 : fixed_pos] + 1};
        tmp_comp <= num_comp;
        //Why not use num_comp[25] to judge? : if 0
        case(num_orig[num_width - 1])
            0 : reg_round <= tmp_comp[fixed_pos - 1] == 0 ? num_comp : num_comp + 1;
            1 : reg_round <= tmp_comp[fixed_pos - 1] == 0 ? num_comp : num_comp - 1;
            default : /* default */;
        endcase
    end
endmodule

FR核的原理是，定点符号数fixed_num首先被转换为了原码num_true，而后将小数部分进行了整体的截断，之后再转换为了补码num_comp，最后根据num_true的符号位和fixed_num定点位后的第一位一位，即小数点后的第一位的值来确定舍入方式。如果这一位是1，则代表在十进制中，被舍入数的小数点后第一位大于5，否则小于5，之后根据四舍五入法则进行舍入即可。

3.1.4 函数

图像处理中会用到一些函数，最为常见的就是三角函数，在一些几何变换中这些函数非常有用，对于一些实现方式而言，函数的计算可以交由软件进行，在FPGA部分则不需要关心传来参数的具体意义，直接计算即可，这种做法的好处是泛用性强，但不够直观，所以当需要一定的直观性的时候，就需要一种方式来让FPGA直接得出这些函数的值。例如，如果想用FPGA求得三角函数的值，最常见的做法就是建立一个LUT(Lookup Table，查找表)，这相当于建立了一个经验公式，来快速地获得限定范围内函数的值，以下代码便定义了一个sin函数的0-359度的查找表，表的键值对由python脚本计算：

module SinLUT(angle, value);
    input[8 : 0] angle;
    output[17 : 0] value;
    reg[17 : 0] reg_value;
    assign value = reg_value;
    always@(*) begin
        case(angle)
            0 : reg_value <= 18'b000000000000000000;
            1 : reg_value <= 18'b000000010001110111;
            2 : reg_value <= 18'b000000100011101111;
            3 : reg_value <= 18'b000000110101100101;
            ......
            359 : reg_value <= 18'b100000010001110111;
            default: reg_value <= 0;
        endcase
    end
endmodule

参考文献

[7] IEEE Standard Verilog Hardware Description Language," IEEE Std 1364-2001 , vol., no., pp.0_1,856, 2001
doi: 10.1109/IEEESTD.2006.99495

【FPGA/图像处理】设计与架构-仿真与发布

dtysky — Monday, 11 May 2015 00:01:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。由于要提供给用户使用，所以必须要提供一套完整的仿真和实测流程，这些仿真程序又有必要遵循相同的架构，以保证开发时的方便和严谨，这考验着系统架构的功底。

2 设计与架构

由于所有的图像处理模块从属于同一个系列，并且需要兼容流水线和请求响应两种模式，所以需要一个标准的接口，这个接口用来连接各个模块，接口设计的标准是要使得每个模块之间的耦合最松，同时又不需要每一个处理结果都要开一个单独的帧缓存、以造成资源的浪费。不仅如此，在还需要考虑到模块自身的可定制(重用性)和软件可控性。同时由于要提供给用户使用，必须要提供一套完整的软件和实测流程。
本章将会说明如何去设计这样的一套接口，如何实现模块的标准化，以及提供给用户的仿真、实测和使用流程。

2.4 目录结构，测试与发布

由于这个图像处理库遵循同一套规范，并且面向用户，所以需要一个规范化的设计结构，这个结构被要求提供一套完整的：
可配置的可选测试样例 -> 软件仿真 -> 功能仿真 -> PSNR计算分析 -> 板上测试。

2.4.1 目录结构

由于以上原因，一套完善的目录结构是必要的，这不仅对于用户而言，也是对于开发的便利和严谨性而言，我将目录设计成了如图2-7的形式。

HDL: FPGA工程以及被打包好的IP核被放置在这个文件夹内，它们由Vivado建立。

ImegForTest: 一个用于存储图片的文件夹，你可以将你想要进行测试的图像放在这里，只有"jpg"和"bmp"格式的文件被支持，不仅如此，一个名为"conf.json"的文件被用来配置仿真参数。

SoftwareSim: 软件仿真的python源文件在这里，它们能够以软件的方法向你展示这个模块的功能。
仿真结果将会被放置在"SimResCheck"文件夹内。

HDLSimDataGen: 这里有一个python的源文件，它是用来创建"dat"文件的，这种文件被作为HDL功能仿真时图像数据的来源。
dat文件将会被放置在"FunSimForHDL"文件夹内。

FunSimForHDL: HDL功能仿真将在这里进行。

SimResCheck: 一个名为"covert.py"的python源文件将HDL功能仿真的结果转换为图像，此外，软件仿真的结果也会被放置在这里，另一个名为"compare.py"的源文件用于将所有的软件仿真结果和HDL功能仿真结果进行比对，然后生成一份报告，用于评估IPCore的质量。

DocGen: 自己编写的针对HDL的注释->文档解析器，用于快速生成一个当前项目的文档模板。

2.4.2 测试流程

测试分为软件仿真、功能仿真、PSNR计算和板上测试。

2.4.2.1 软件测试

我根据每一个模块的特性提供了一些用户可选的仿真参数，这些参数通过一个"conf.json"文件被配置，并作用于每一个张测试图像。这些参数和图像随后被用于软件仿真的程序读入，并生成软件仿真的结果，软件仿真程序遵循一个标准，其函数结构如下：

def name_format(root, name, ex, conf):
def transform(im, conf):
def debug(im, conf):

name_format函数接受的参数为所有图像的文件路径、文件名、扩展名，以及用户设定的配置文件，返回一个字符串，这个字符串将作为处理后图像的文件名。
transform函数接受一个Image对象的指针与用户设定的配置文件，返回一个Image对像的指针，这个对象即为经过这个模块处理后的图像。
debug函数接受的参数和transform函数一致，但返回的是一个字符串，这个字符串应当包含这个模块处理后的图像的像素数据，用于调试。

2.4.2.2 HDL功能仿真

功能仿真用于HDL文件的功能测试，其基本流程是：
将图像和配置转换为dat文件 -> 搭建Test bench并读入文本进行仿真 -> 输出结果到res文件 —> 转换为图像。
将图像转换为dat文件的过程是由python完成的，这个程序同样遵循一个标准：

def name_format(root, name, ex, conf):
def conf_format(im, conf):
def color_format(mode, color):
def create_dat(im, conf):

name_format函数接受的参数为所有图像的文件路径、文件名、扩展名，以及用户设定的配置文件，返回一个字符串，这个字符串将作为处理后图像的文件名。
conf_format函数接受一个Image对象的指针与用户设定的配置文件，返回写在目标dat文件起始位置的字符串，这个字符串可以视作与Test bench传递模块参数的接口，它作用于整张图像。
color_format函数接受一个图像的模式和一个像素的色彩值，返回的是一个格式化后的色彩值，格式化的格式根据模块的需求和图像模式而定，模式通常为RGB、灰度等。
create_dat函数接受一个Image对象的指针和用户设定的配置文件，它返回的是当前图像被转换后的dat文件所需要写入的所有内容。

有了数据的来源，需要考虑的便是Test bench的搭建，Test bench，即测试平台，是HDL验证领域所必须搭建的，这对于模块的功能判断和调试是十分有必要的，我使用SystemVerilogHDL来搭建测试平台，SV灵活强大，抽象能力强，几乎是业界搭建测试平台的标准，对于测试平台，虽然对于不同的模块难以完全标准化，我仍然设立了一套基本的标准：

interface TBInterface (input bit clk, input bit rst_n);
task init_file();
task init_signal();
task work_pipeline();
task work_regack();

TBInterface是一个接口，用于构造仿真需要的接口，这里使用接口并不是为了在设计的时候模糊接口完整的定义，因为它并不与verilog兼容，这样做的好处仅仅是让结构看起来更清晰，比如在实例化的时候可以这样去做：

TBInterface #(3, 8) RGBPipline(clk, rst_n);
Test Test1(RGBPipline.clk, RGBPipline.rst_n......

接口后是四个task(任务)。
init_file在每一张新的图像输入的时候被调用，一般用于将图像的宽高写入res文件，并且读取用户定义的配置参数，使其作用于整张图像。
init_signal用于在每张图像被处理前进行一些信号初始化工作，比如rst_n这个复位信号就可以在这个流程中完成模块的复位操作。
work_pipeline是工作流程，用于指定这个模块在流水线模式下如何被测试，以及将要输出怎样的数据。
work_regack同上，唯一的区别在于这个task用于请求响应模式下的测试。

仿真完成后得到的是一系列的res文件，这些文件中有处理结束后的图像数据，接下来将这些数据利用一个python脚本进行转换，便可以得到HDL功能仿真的结果。

2.4.2.3 PSNR计算分析

有了软件仿真和功能仿真的结果，便可以对模块实际运作的质量进行一个评估，这里选用PSNR进行评估，PSNR的计算公式如式2-1。
$$PSNR = 10\log10(\frac{MAX^2} {MSE})\ \ \ \ \ \ \ \ (2-1)$$

其中，MSE是原图像与处理图像之间的均方误差，MAX是图像在当前位宽下的最大值，这里用软件仿真的结果作为原图像，HDL功能仿真的结果作为处理图像。
PIL库提供了计算MSE的函数，加上math库中的log函数即可完成计算：

diffs = ImageChops.difference(Image.open(f_pair[0]), Image.open(f_pair[1]))
stat = ImageStat.Stat(diffs)
rms = sum(stat.rms) / len(stat.rms)
psnr = 20.0 * math.log10(255.0 / rms) if rms != 0 else 1000*1000

PSNR值的单位为dB，理论上，PSNR值越大失真越少，代表图像处理的质量越高，一般情况下PSNR > 30dB即为人眼可以容忍的范围。

2.4.3 板上测试

一些板上测试工程会被提供，它们由Vivado的图形化设计界面构建，使用xilinx提供的Zybo开发板，并使用Ov7670摄像头模块作为图像来源，使用VGA作为图像输出，同时建立一个AXI总线的IP核来完成简单的通过软件对模块的配置。

2.4.4 发布

项目拥有自己的发布网站，发布网站使用Pelican作为框架，用html、css和js开发，并搭建在VPS上，最终发布于fil.dtysky.moe。

参考文献

感谢

Alexis Metaireau and contributors, Pelican 3.5.0, https://github.com/getpelican

【FPGA/图像处理】设计与架构-接口与IP核设计

dtysky — Sunday, 10 May 2015 20:01:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。由于这些图像处理模块从属于同一个系列，并且要兼容流水线和请求响应两种模式，有必要遵循同一个标准的接口协议，我设计了一套简单的标准化接口协议，使得图像在处理过程中需要消耗的帧缓存最小化。不仅如此，模块本身的设计也要考虑到强可重用性和软件的可控性。

2 设计与架构

2.1 分类

在设计之前，首先要完成的是分类，由于图像处理种类繁多，所以考察这些不同的种类，并提取共同之处对于设计和架构是十分必要的，针对于FPGA的图像处理操作的分类工作已经在Donald G.Bailey的专著中^[3]有非常完整的结论，这里加以提取和重构，已实现的图像处理主要的操作分为如下几类：

Point :对每一个像素进行的操作，它意味着所有这种类型的IP核在一个操作周期内都只能够对一个点进行操作，所以这里将会有甚多的基础操作，像是灰度化、阈值化、对比度变换等等。

Generator: 这是一个特殊的分类，它包含一些用于生成数据结构或者控制内存的IP核，比如行缓存生成，帧控制等等。

LocaFilter: 基于窗口的操作，也就是局部滤波器，窗口是一种特殊的数据结构，这种数据结构将图片的一部分分割了出来。这个分类中的IP核经常用于模糊和锐化这些目的，比如均值滤波器，排序滤波器等等。

Geometry: 如其名所示，这个分类下的IP核被用于几何变换，和其他分类不同，这个分类操作的对象是坐标而不是色彩，比如平移、缩放、旋转等仿射变换。

Detection: 边缘检测，比如Harris角点检测等等。

Histogram: 创建直方图，并从中获取一些有用的信息。

2.2 接口设计

根据这些操作的功能和要求，可以将接口设计分为两个部分——基础端口和扩展端口。

2.2.1 基础端口

基础端口，也就是所有模块的接口中，至少包含的一些端口，这些端口被设计为如下形式：

clk: 时钟信号，用于提供同步时钟。

rst_n: 全局复位信号，用于复位和初始化。

in_enable: 输入数据使能，用于控制输入数据流。

in_data: 输入数据流，提供处理的数据源。

out_ready: 输出数据有效，作为操作结束的标志。

out_data: 输出数据流，送出处理后的数据。

这些端口保证了每个模块的基本功能，图示如图2-1。

图2-1 基础接口示意

模块的运作方式如下：
首先进行全局的复位，对模块进行初始化，而后输入数据随着输入数据使能信号输入模块，在同步时钟的若干个周期后准备好输出数据，使能输出数据有效信号，通知外部电路取出数据。

2.2.2 扩展端口

由于每个模块自身的独特性，基础端口提供的功能往往不足以满足模块的实现，所以这时候需要加入扩展端口来满足需求，扩展端口一般被设计为以下形式：

x: 不定端口，取决于模块自身的要求，比如对于阈值化模块，这个参数就是阈值。

in_count_x: 输入坐标的x分量，通常用于几何变换。

in_count_y: 输入坐标的y分量，通常用于几何变换。

out_count_x: 输出坐标的x分量，通常用于几何变换。

out_count_y: 输出坐标的y分量，通常用于几何变换。

frame_addr: 通常用于帧控制，提供某一个输出数据的地址。

这些端口和基础端口合并起来，便可以满足每一个模块的需求，如图2-2所示。

图2-2 完整接口示意

至此，接口的硬件部分便设计完毕。

2.2.3 接口协议

接口的硬件部分定义结束后，还必须定义其协议部分。由于每一个模块同时存在流水线模式和请求响应模式，同时为了兼容已有的接口标准，达到最简化的设计目的，我让两种模式遵循了同一套接口标准，不同的仅仅是在两种模式下接口的行为方式。

2.2.3.1 流水线模式

流水线模式时，在输入使能in_enable有效的情况下，从第一次输出数据有效标志out_ready有效开始，输出数据out_data便会源源不断地送出，每一个周期都会送出一个有效数据。在这种模式下，从第一个数据有效开始，输出便是连贯的，如图2-3所示，时序图均采用wavedrom绘制。

图2-3 流水线模式时序

这种模式一般用于需要连续数据流的应用中，由于采用了流水线做缓冲，所以一开始的若干个周期延迟在实际运用中是不需要关心的，也故理论上可以插入任意级流水来达到最高的Fmax(工作频率)。

2.2.3.2 请求响应模式

在这个模式下，in_enable和out_ready两个标志信号被当做请求信号req和响应信号ack，输入数据in_data随着每一次in_enable的上升沿被送入模块进行处理，处理完成后out_ready有效来通知外部电路取走数据，直到下次in_enable的上升沿到来为止，输出数据的状态都不会发生改变，如图2-4所示。

图2-4 请求响应模式时序

这种模式一般用于一些特殊的模块，比如直方图操作下的模块，对于这些模块，流水化的操作是没有意义的。此外，这种模式还可以被用于和软件的交互中，因为软件很难做到同步数据流的模式。

综上，最终模块的接口工作模式如图2-5。

图2-5 接口工作模式

2.3 可定制IP核设计

明确了每一个模块的接口以及其协议之后，便可以考虑IP核的设计了。IP核(intellectual property core，知识产权核)是指由某一方开发者提供的形式为逻辑单元、芯片设计的可重用模块，使用IP核能够为设计减少开发周期，并且达到比较好的效果。
对于图像处理操作，一个IP核应当用于良好的可重用性和软件可控性，可重用性本质上就是一个IP提供了若干种工作模式，用户可以根据参数对IP核进行不同的配置，使得IP核在不同配置下被综合成不同的模式。而软件可控性，这里指的是可以通过AXI总线使得SoC部分可以对IP核进行一定的控制，比如在流水线模式下可以提供一些配置参数，在请求响应模式下可以直接进行数据交互。

2.3.1 可重用性设计

在VerilogHDL中，可重用性一般是通过parameter语句和generate语句实现的，generate语句在VerilogHDL1995标准^[6]里是没有的，但在VerilogHDL2001标准^[7]中，向VHDL学习中它加入了这个语句，现在几乎所有的综合工具都支持这个语句。
parameter语句常用于配置静态参数，来决定模块的工作方式，generate语句则根据parameter语句设定的参数来告诉综合工具哪一部分需要被综合，比如以下代码：

// 0 for pipeline, 1 for req-ack
parameter work_mode = 0;
parameter color_width = 8;
input[color_width - 1 : 0] in_data;
......
generate
    if(work_mode == 0) beign
        ......
    end else beign
        ......
    end
endgenerate
......

根据color_width来确定输入数据的位宽，根据work_mode来确定要综合的部分。此外，generate语句还可以被用来实现逻辑复制，这为流水线的设计减少了不少工作量。

2.3.2 IP核设计

一般情况下，一个单独或者一个系列具有层次的HDL文件便可以被看成一个IP核，这种IP核通用性最强，但从使用效率的角度却不如针对每一个厂商的开发套件专用的封装，本项目使用Vivado作为开发工具，使用的是Vivado的封装工具。
Vivado的IP封装工具在基本的IP封装上加了一层GUI，用于和用户进行直接的交互，一个设计封装好的IP核如图2-5所示：

图2-6 Vivado封装的IP核

通过这个IP工具，我们可以给模块的参数添加任意形式的约束，由于它支持expr表达式^[8]，所以我们甚至可以通过某一个参数的取值来自动确定另一个参数的取值，避免了用户自行计算的这一个步骤，例如，我们想要通过im_width这两个参数来确定im_width_bits(图像宽度的位宽)时，可以利用下面的语句来完成；

if {[expr log($im_width)/log(2)] > [expr int(log($im_width)/log(2))] } {
    set ${im_width_bits} [expr int(log($im_width)/log(2)) + 1]
} else {
    set ${im_width_bits} [expr int(log($im_width)/log(2))]
}

封装后的IP核有资源文件，一个用于记录IP结构的xml文件和一个控制GUI的tcl文件，以及可能存在的一个服务于expr表达式的gtcl文件构成，这些文件使用相对路径，所以可以很方便地将IP核转移到任何位置。

参考文献

[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013
[6] IEEE Standard Hardware Description Language Based on the Verilog(R) Hardware Description Language," IEEE Std 1364-1995 , vol., no., pp.1,688, Oct. 14 1996
doi: 10.1109/IEEESTD.2006.99495
[7] IEEE Standard Verilog Hardware Description Language," IEEE Std 1364-2001 , vol., no., pp.0_1,856, 2001
doi: 10.1109/IEEESTD.2006.99495
[8] Xilinx, Vivado Design Suite, Creating and Packaging Custom IP, UG1118 (v2014.3)[EB/OL]. October 8, 2014

感谢

WaveDrom user group, wavedrom, http://wavedrom.com

【FPGA/图像处理】绪论-背景知识

dtysky — Saturday, 09 May 2015 15:01:00 -00:00

图像处理系列文章基本都是我本科毕设论文同步发布，这个项目以LGPL许可被发布在F-I-L。图像处理技术服务于人类的视觉系统，而视觉是人类感知外界最为重要的知觉之一，所以图像处理对于我们的意义是重大的，历史上的图像处理有多个阶段，到了我们这个时代，则是以数字图像处理为主，其中的算法又可以分为软件和硬件两种实现，硬件实现在速度等方面比起软件实现有许多优势，但其复杂程度和局限性也是比较显然的，所以我们应当做的合理分配和利用二者，做到效率的最大化。

1. 绪论

1.1 引言

图像处理(Image Processing)服务于人类的视觉系统，而视觉作为人类最重要的感觉器官，对我们的意义是十分重大的，所以，视觉数据的记录和处理十分重要，经过漫长的发展，人类对视觉信号的处理方式由原始的间接记录演化成了由电子器件主导的直接记录，通过感光器件，我们可以得到记录光强的若干信息，对这些信息进行处理，也就是对视觉信息进行分析和再构，其重要性不言而喻。
我们知道，本质上人类所有活动的都依赖于信息的操作，正如当巴贝奇在发散地研究各个领域、想要制作计算机器来尝试一些东西的时候，他真正的研究主题实际上信息，是信息的通信、编码、处理等^[1]。这一点在现代社会显得尤为清晰。而图像处理就是对图像信息的操作，它一般处于图像信息输入和输出之间，本质上是对输入信息进行各种各样的滤波，来转换其信息所处的空间，从而达到强调、提取信息等等目的。
传统的图像处理方法是模拟和光学的，在精确的现代记录方式出现之前，人们用自己的双手和画笔进行着图像处理，那个时代，任何图像信息再被输入之前就已经经过一次处理了，不过那个时候我们往往把这些处理称为“艺术加工”，当然，一幅图像是否具备着相对于自然完全的“真实性”并不重要，因为“真实”本就是一个玄学的概念，最重要的是我们想要获得什么，正如贡布里希在《艺术与错觉》一书中所言，“艺术家同样无法转录他所见到的东西，他所能做的只是把他所见翻译成他的绘画手段的表现形式罢了。”^[2]。事实上，图像处理就是有着这样的一个目的——去得到相对于原始图像的、我们想要的东西。
然而对于这些历史上的处理方式有一个比较重要的问题，就是绝大多数人基本不可能对同一个原图像进行机械而重复的操作，这是绘画这种处理方式本身的门槛所决定的，所以图像处理技术一直没有从艺术领域踏入工业领域，因为实际上它并不具备一般意义上广泛的生产力，但随着技术的飞快进步，尤其是CCD和CMOS这种感光元件以及存储器的出现，让我们获得了记录和复制同一副图像的能力，一旦一件事物被加上了可以复制的属性，它的成本的降低几乎是必然的，所以我们拥有了更多的自由去做一些实验，加上电子技术的进一步发展，数字图像处理技术诞生了，比起传统的处理方式，它大大提高了研发和生产的效率，可以完成的操作是传统方式望尘莫及的。

1.2 数字图像处理

数字图像处理，即为使用计算机对量化和数字化后的图像数据进行处理，数字图像的定义是：“一个存储着数值的二维数组”，这意味着图像被映射到了一个二维空间内，由若干坐标和坐标信息来表示图像本身的信息，每一个这样的坐标点就被称为“点”，“点”一般作为图像的基本操作单元。有了被存储在数据单元内的图像数据，便可以对图像进行各种操作，操作的基础是各种数学运算，比如加减乘除卷积等等，利用这些操作可以实现^[3]：

图像增强：改善图像的主观质量，比如降噪、对比度调整、色彩校正等等。

图象复原：对已经发生退化的图像进行修正，分析退化的原因进行逆运算，从而将图像恢复到应有的状态。

图象重建：将图像数据重组，比如缩放、旋转、色彩空间转换等。

图像分析：使得计算机可以从图像中获取知识，经常表现为某种形式的测量。

模式识别：基于测量的模式进行物体识别，比如人脸识别等等。

计算机视觉便是建立在以上基础操作的一种学科，研究出一系列模型来处理图像，最终给出人们需求的结果。
传统的机器视觉是基于软件的，理论上任何一种图像处理算法都可以在一个单独的处理器上实现，区别是越复杂的算法，需要消耗的时间越多，这对于追求效率的人类显然是不可接受的，所以越来越多的并行架构出现，比如空间并行和逻辑并行，对于这样的系统，软件的方案就不再是完美的了，软件适合高层的图像处理操作，比如与某些智能操作，而操作级的处理则需要另辟蹊径，FPGA的出现则提供了这样的一种途径。

1.3 图像处理的FPGA实现

FPGA(Field Programmable Gate Array ,现场可编程逻辑阵列)属于VLSI(Very Large Scale Integration，超大规模集成电路)的一种^[4]，在和其他专用定制的ASIC不同，FPGA属于在设计成本和最终性能之间的一个平衡产物，它是一种包含可反复使用字段的小规模逻辑模块和元件的可编程器件。由于不需要考虑一次性工程成本，所以它的设计成本和上市成本要比传统ASIC低得多，但由于缺少了一些额外的IC后端流程，所以它的性能和功耗一般无法与专用ASIC相提并论，但即便是如此，对于以软件处理为主导的领域，它的性能仍然是一个巨大的优势，图像处理就是这样的一个领域。
FPGA本质上是一个通用电路，它利用厂商预设的逻辑单元、存储资源和布线资源构成的数字电路来实现一些算法操作，由于开发FPGA本质上是搭建数字电路，FPGA实际上拥有着先天的并行性，这对于图像处理是非常契合的，因为对于大多图像处理操作，每一个像素点，乃至每一个结构元素都是互相独立的，使用FPGA可以对任意处理模块进行复制，从而达到一个周期处理一张图像的理论效果。
不仅如此，FPGA还十分是和流水化操作，保证每个周期都有一个输出，并且这种输出是连续而不间断的，同时，即便不是流水化操作，FPGA也可以通过自己设计的协议完成请求响应的等工作模式。总而言之，FPGA是十分灵活的。
许多算法已经被证实过可以使用FPGA进行实现，比如一些点操作、形态学操作等等，同时得到了良好的效果。

1.4 SoC平台-ZYNQ

SoC(System on Chip，片上系统)是指一个将计算机或者其他电子系统集成到单一芯片中的集成电路，也就是说，在单一芯片中放置一个CPU，随后提供它的BSP(Board Support Package，板级支持包)，让这个芯片支持软件开发，这种设计常常被用在嵌入式软件领域，众多的微控制器就是其中的一种典型实现。
这里要探讨的是SoC和FPGA的结合，Xilinx很早就做出过PowerPC硬核和FPGA结合的架构(Virtex-4, 5系列)，但最后由于需求等问题无疾而终，之后又出现了Altera的Nios和Xilinx的Microblaze软核系统，它们利用一部分的逻辑资源构建一个CPU，并提供基本的BSP进行开发，虽然支持面广，但资源和性能仍然不如硬核架构。
ZYNQ架构是Xilinx最新推出的一种SoC+FPGA的架构，采用7系列的FPGA和ARM硬核的结构，将系统部分称为“PS”端，逻辑部分称为“PL”端，两端通过AXI总线进行交互，并提供了对开发者友好的全套、一体化设计环境，很大程度上解决了性能和资源问题。
利用ZYNQ平台，我们可以很方便地使用PS部分对PL部分进行配置和数据交互，这为软件算法的硬件加速提供了GPU外的另一种便利的可能，比如可以将两个矩阵送给PL端计算，返回给PS端，由于Xilinx提供了完善的AXI总线模块模板，让这个开发过程变得非常简单。

1.5 本文研究目的和实现内容

基于以上原因，我选择实现一个FPGA的图像处理库，这个库将会包含许多基础的图像处理操作，每一个操作都分为流水线和请求响应两个模式，并拥有各自的软件仿真、HDL功能仿真和板上测试，并计算PSNR进行可信度分析。
每一个操作都会被封装成Xilinx的Vivado设计套件中的IP核，并利用图形化设计界面进行板上测试工程的搭建。
对于语言的选择，由于VerilogHDL比起VHDL更适合算法描述，而图像处理比起系统架构更多的是算法问题，所以选择使用VerilogHDL进行模块的设计。
测试平台利用业界普遍用于测试的SystemVerilogHDL进行搭建，功能仿真使用Modelsim软件进行。
软件仿真则选择简单强大的Python和PIL库实现。
除此之外，还会简单地展示如何在ZYNQ平台上实现PS和PL端的交互，实现SoC系统和FPGA的高效协作。
FPGA-Imaging-Library(FPGA的图像处理库)属于自由软件，以LGPL(GNU Lesser General Public License)^[5]许可发布。

参考文献

[1] 詹姆斯.格雷克.信息简史[M].高博译.北京:人民邮电出版社,2013:12.
[2] E.H.贡布里希.艺术与错觉[M]杨成凯,李本正,范景中译.南宁:广西美术出版社,2012:3.
[3] Donald G.Bailey.基于FPGA的嵌入式图像处理系统设计[M].原魁,何文浩,肖晗译.北京:电子工业出版社,2013.
[4] U.Meyer-Basese.数字信号处理的FPGA实现(第3版)[M].刘凌译.北京:清华大学出版社,2011:3.
[5] Free Software Foundation, Inc. GNU LESSER GENERAL PUBLIC LICENSE Version 2.1[EB/OL]. February 1999.

【FPGA】Modelsim的文件结构和使用

dtysky — Friday, 08 May 2015 23:01:00 -00:00

Modelsim是一个HDL仿真软件，其相比其他的软件，最大的优势在于可以在个人电脑上跑出很不错的速度，用起来也颇为顺手，一般分为SE, ISE, ASE几个版本，第一个是原版，后面的是xilinx和altera定制版，SE版本最为强大，支持混合仿真，同时仿真速度不是后两个版本可以比的。

1.工程文件结构

对于一般的需求，使用Modelsim主要是通过建立project来完成的，一般情况下这个project都会在被选择在默认的work库中，并且我们选择的应该是不导入文件和不独立创立一个Ini文件，也就是将安装目录下默认的ini文件作为配置文件，这样，建立好一个project后，目录下一般会有两个文件，假设项目名字为EX：

EX.mpf
Ex.cr.mti

然而真正有用的文件实际上只有EX.mpr一个，也就是说，如果我们想要转移一个仿真工程，原则上只需要复制这一个文件就OK。
Modelsim的这个工程文件也是明文的，但和Vivado不同，它并不遵从xml语法，它使用的是一套类似标记语言的语法，打开它后，我们将会看到很多行的文件，这些行基本说明了这个工程的所有配置，但有很多是我们不需要关心的，我们需要关心的，实际上只有：
检索到：

[Project]

这一行，我们会看到下面有很多类似这样的文本：

Project_Version = 6
Project_DefaultLib = work
Project_SortMethod = unused
Project_Files_Count = 4
Project_File_0 = ../HDL/ContrastTransform.srcs/sources_1/ip/Multiplier12x24LUT/Multiplier12x24LUT_funcsim.v
......

这便是我们需要主要关心的主体内容，来一一解析：

Project_Version = 6

这表明了项目的版本号。

Project_DefaultLib = work

这表明了项目默认所在的库。

Project_SortMethod = unused

项目排序，暂时不知道是做什么的，估计是给文件排序？

Project_Files_Count = 4

项目文件总数，如果和实际不符，小了的话少文件，多了的话报错。

Project_File_0 = ../HDL/ContrastTransform.srcs/sources_1/ip/Multiplier12x24LUT/Multiplier12x24LUT_funcsim.v

第零个文件的路径，这里使用的是相对路径，要注意的是，在modelsim里，一般情况下是不能够使用相对路劲的，似乎只有工程目录下的文件才能使用相对路径表示同时有时候也不行，所以如果相对路径行不通就用绝对路径吧。

至此，我们需要关心的内容基本就搞定了。

2.使用

使用Modelsim的基础部分就不再赘述，已经有无数篇文章写过这种问题，这里主要说几点觉得有用的经验。

1.编译xilinx仿真库到modelsim

在Vivado里面，你只需要在它的控制台中输入以下指令：

 compile_simlib -directory <library_output_directory>  -simulator <agr>  
                            -simulator_exec_path<sim_install_location>

之后,在modelsima安装目录中打开modelsim.ini文件（去掉只读属性），然后粘贴下列语句：

>ini
[Library]
std = $MODEL_TECH/../std
ieee = $MODEL_TECH/../ieee
verilog = $MODEL_TECH/../verilog
vital2000 = $MODEL_TECH/../vital2000
std_developerskit = $MODEL_TECH/../std_developerskit
synopsys = $MODEL_TECH/../synopsys
modelsim_lib = $MODEL_TECH/../modelsim_lib
simprim_ver = G:/EDA/Xilinx/simprim_ver（库的路径，以下同）
unisim_ver = G:/EDA/Xilinx/unisim_ver
xilinxcorelib_ver = G:/EDA/Xilinx/xilinxcorelib_ver

最后，还原只读属性即可。

2.自动化测试

使用tcl脚本和控制台来完成，我的一般做法如下：

首先，使用以下指令创建work库：

vlib work

而后，编译文件并执行仿真，一次仿真结束后ctrl+s保存一个wave.do文件，之后新建一个run.do文件，在wave.do文件开头和结尾加上两行内容：

vsim work.glbl -voptargs=+acc -L unisims_ver work.ContrastTransform_TB
(wave.do)
run -all

work.glbl是由于使用了xilinx的仿真库，必须先加载这个才可以进行仿真，后面的则是禁止优化参数，为了调试而准备，这条指令只要结构是vsim xxx，开始仿真的意思。

之后再次仿真只需要执行：

do run.do

即可。

当然，我们也可以建立一个tcl脚本来完成自动化测试，不过看需求了，完。

【FPGA】Vivado的文件结构和配置

dtysky — Friday, 08 May 2015 21:01:00 -00:00

Vivado是Xilinx公司最新的开发套件，ISE不再支持最新的7系列以及后面将要出的系列，然而Vivado本身也不支持7系列以前的硬件，这就表明它本身是一个分水岭，也或许可以说是一次决意的革新，当然，本人对ISE的坑爹早有耳闻所以以前一直用的是A家的Quartus，不过由于某些原因，嘛，总之Vivado用完了还是很顺手的，尤其是其文件结构值得一提，控制台脚本强大，IP封装比较顺滑并且不得不承认或许先封装IP再图形化连接的确可以提高效率（当然这是在用verilog和vhdl的情况下，抽象强大的sv如果被广泛支持就没他啥事了ww），不过将IP的UI层和IP的逻辑层分离值得赞许，但编辑器还是一如既往的狗屎。

1.目录结构

当我们新建了一个工程并且完成了文件添加和综合、布局布线以及生成bit流生成，最后导出sdk后，整体的目录主要如下，此处假设工程名称为EX:

EX.xpr: 项目管理文件，里面记录了该工程的文件索引。
Ex.srcs: 项目源文件目录，里面又分文sources_n, sim_n,和constrs_n而sources_n和sim_n内又分为import和new，顾名思义，源文件和仿真文件被分离开，但源文件实际上也是参与仿真的，sources_n下属子目录的子目录中除了自己新建的设计文件，又可以分为ip、bd等,ip目录下是ip核生成的文件，bd则是vivado专用图形设计界面的文件（bd的创建和文件解析将会在后面的教程中说到），sim_n内的文件通常是test bench，constrs_n内是XDC约束文件，用于时序约束和引脚约束等。此外，如果使用了ip，将可能生成ipshare目录，此目录中存放了一些保存被引用ip的一个临时副本。
EX.runs: 内部有许多名为(name)_synth_n和(name)_imp_n形式的文件夹，里面是综合和布局布线生成的一些临时文件，对于主模块，其(name)为空，里面生成的文件中包含报告文件和bit流。
EX.hw: 此目录中是存放硬件信息的，包括使用器件和综合后的网表，同时ila的波形调试结果也在此目录中存储。
EX.sdk: 只有在使用了CPU(无论是软核还是硬核)时才会出现这个目录，这个目录下存放的是SDK的工程，内部包括根据硬件生成的BSP和你自己新建的软件工程。
EX.cache: 临时缓存文件，无视即可。

这里需要注意的是，vivado使用的是相对路径，这个相对是相对于.xpr文件而言的，实际上这带来了很大的方便，这意味着我们不必关注绝对路径，只要保证文件结构的基本不变，便可以随意使用，不但如此，xilinx的工程师很欣慰的使用了xml明文方式记录文件架构，无论是xpr文件，还是后面教程中要提到的bd文件，还是后面同样提到的ip管理文件，这意味着如果我们需要创建一系列的工程，比如我做的图像处理库，它们都拥有着相似的结构，那么只需要用文本编辑器对xpr等文件进行编辑基本就可以构建相似的工程。

2.文件结构

xpr等文件遵从由明文的xml语法，如果你打开任意一个新建好的工程的xpr文件，将会看到类似于以下的内容：

<?xml version="1.0" encoding="UTF-8"?>
......
<Project Version="7" Minor="2" Path="......">
    <DefaultLaunch Dir="$PRUNDIR"/>
    <Configuration>
        <Option Name="Id" Val="58d46179d1874f22945d718ae416c55f"/>
        ......
    </Configuration>
    <FileSets Version="1" Minor="31">
    <FileSet Name="sources_1" Type="DesignSrcs" RelSrcDir="$PSRCDIR/sources_1">
        <Filter Type="Srcs"/>
        <File Path="$PSRCDIR/sources_1/new/ContrastTransform.v">
        <FileInfo>
            <Attr Name="UsedIn" Val="synthesis"/>
            <Attr Name="UsedIn" Val="implementation"/>
            <Attr Name="UsedIn" Val="simulation"/>
        </FileInfo>
        </File>
        <Config>
        <Option Name="DesignMode" Val="RTL"/>
        <Option Name="TopModule" Val="ContrastTransform"/>
        <Option Name="TopAutoSet" Val="TRUE"/>
      </Config>
    </FileSet>
......
</Project>

结构一目了然，非常清晰，Project块表示这个项目中所有的元素，Version等属性代表着项目的属性，内部的一些如同Configuration、FileSet等标签则是表明了这个项目的一些配置和文件结构，比如我这个项目拥有一个名为ContrastTransform.v的主要源文件，所以FileSet的sources_1内便有一个File标签内定义着这个文件，随后还给这个文件定义了作用域，比如

Name="UsedIn" Val="synthesis"

就表明这个文件被用于综合。
其他还有一些设置通过名字就能猜得出来，不再多说。
那么，我们如何善用这种结构呢，很简单。
比如我有一个AImage的工程，其中有许多文件，这些文件都是以A_X.v, A_Y.sv形式命名的，新建一个工程再添加未免烦躁，这时候我们可以拷贝整个工程，将所有文件的"A_"改成"B_"，并且在xpr文件中将所有的"A_"替换成"B_"即可。
如果你会脚本语言，那就更简单了，写个小脚本处理一下就OK（python死忠www）。

3.配置

文件目录结构以上就说的差不多了，这里再说一些vivado的配置。
众所周知，对于一个程序员，一个优雅的编辑器是多么的重要，当用惯了还算优雅的quartus的编辑器再来使用vivado的编辑器时，我感觉我吃到了什么不好的东西，这里我想对x家的工程师说一下，工程师何苦为难工程师。
当然x家工程师还算有良心，提供了编辑器的可配置选项，在vivado的GUI下，点击标题栏的Tools -> Options -> General -> Text Editor:

如果你是高贵的vim党啊，emacs党啊，还有不怎么高贵的notepad++党啊，他有默认配置，当然我用的sublime他也有，不过不知道是不是环境变量的问题并没有啥用，所以我用了一下策略：
在这里选择Custom Editor，并且点击后面的...按钮输入打开编辑器时候的指令：

B:/Poetic_Being/Sublim_Text_3/sublime_text.exe [file name]:[line number]

B:/Poetic_Being/Sublim_Text_3/sublime_text.exe是我的sublime执行文件路径，替换掉就可以了。

其他配置也没什么好说的了，基本都是大家都会的，好，结束。

【impress.js】告别PPT从我做起

dtysky — Tuesday, 05 May 2015 02:01:00 -00:00

impress.js是一个牛逼的js库，它为我们开创了演示界面的新纪元，相比其他同样牛逼的类似的js库，它做到了真正的简单易用却效果强大，其提供的接口十分简洁易懂，同时却不失复杂的变化性，结合CSS能够达到你想达到的几乎任何效果，当然有些太复杂的做起来还不如直接用PPT但是，很多时候那些复杂的东西有必要吗？看需求吧www反正我觉得没有必要。

1.获取和示例

在这里直接获取源代码，一个js文件，下下来即可
impress.js

官方示例
Demo by bartaz

我的示例
这个是纯粹为支持impress.js的终端做的，不支持的情况下采用抛出信息的处理方式。
Publihed Projects
这个为不支持的终端做了一下处理，其实也就是不同的CSS。
FPGA-Imaging-Library

2.使用

首先需要有一定的Html和CSS基础，这个很简单，自行了解即可，因为严格意义上这两个不算编程（基本不涉及逻辑），并且同时，impress.js的使用基本也不涉及逻辑。

1.链接

这一点首先单独列出来是为了澄清一些东西，一般情况下，我们会在head块内加入一些metadata，并链接js和CSS文件，但对于impress.js不能这么做，所以不要在header块内引用它，具体在哪里会在下面说明。

2.作用域

作用域，也就是impress.js发生作用的区块，根据它的设计，你需要建立一个id为impress的div，并将你需要作为impress.js演示对象的内容放到其中：

<div id="impress">

</div>

在这个div中，一般而言我们需要加入一个class为no-support-message的div，这个div中的内容会在终端不支持impress.js的时候显示出来，比如：

<div class="no-support-message">
    Your browser doesn't support impress.js.It can't phones.<br>
    你的浏览器不支持impress.js.请更换，它不支持手机。
</div>

当然位置和样式是由你自己决定的，比如在我的第一个实例中我这样定义：

.no-support-message { 
display:none; 
width:940px; 
margin:0 auto 24px auto; 
text-align:center;
}

效果就是当不支持的时候，这段内容就会显示在页面开头的中间部分。
对于第二个示例，由于我采用的是其他解决方案，所以没有这段内容。

3.设计

确定作用域后便可以开始设计，在上面的作用域中加入若干你需要演示的div，每个div都是一个演示页面，它们必须都拥有step这个class，没有这个class的div会当做一般元素处理，也就是不受impress控制。
第一个例子的首页：

<div id="first-page" class="step" data-x="0" data-y="0">
    <h1 id="first-title">Published Projects</h1>
    <p id="first-desc">My published projects are here.</p>
    <p id="first-link"><a href="http://dtysky.moe" target="_blank">Blog</a>&nbsp;&nbsp;<a href="https://github.com/dtysky" target="_blank">Github</a>&nbsp;&nbsp;dtysky@outlook.com</p>
    <p id="page-top">Click a page you want to view, you can also press "←", "→" or whitespace.
    <br>点击你想进入的页面或者按下 "←"、"→"或空格键.</p>
</div>

为了显示这些演示页面，必须要为step定义样式，第一个示例中定义的样式如下：

.no-support-message { 
display:none; 
width:940px; 
margin:0 auto 24px auto; 
text-align:center;
}

每一个页面宽度为940px，位置是浏览器页面正中，所有文字居中。
你应该注意到了，和一般的属性不同，这个首页的div中拥有data-x和data-y两个属性，而这种属性就是impress.js效果的依赖源。
这些属性定义了每一个页面的位置信息，这个位置是相对于你的浏览器主页面而言的，主页面的中心位置被定义为原点，所有的属性如下：

data-x: 距离原点的横向偏移量，像素值
data-y: 距离纵向的纵向偏移量，像素值
data-rotate-x: 相对当页中心点的x轴旋转偏移量，角度
data-rotate-y: 相对当页中心点的y轴旋转偏移量，角度
data-rotate-z: 相对当页中心点的z轴旋转偏移量，角度
data-scale: 相对于主体页面的比例，比例值

有了这些属性，我们便可以开始设计了，具体的设计就是在上面这些块中加入属性值，这里说的已经足够清晰，自己尝试一下就可以了。

4.工作

完成了页面设计之后便可以开始开始演示了，在这之前，我们需要链接impress.js并启动它，在你的impress块后加入两行代码即可：

<div id="impress">
    ......
</div>
<script type="text/javascript" src="js/impress.js"></script>
<script>impress().init();</script>

5.其他技巧

不知道是否只有我有这个需求，就像第一个示例一样，将演示页面分类，一块一块展示，展示完一块可以选择直接返回主页面，这个需求可以直接通过以下方式实现：

观察启动后的标题栏，我们可以知道每一个页面的url是这么表示的：

(主页面url)/#/演示页面id

比如对于第一个实例的首页，url是：

http://proj.dtysky.moe/#/first-page

所以可以在某个演示页面中插入一个超链接：

<div class="step">
    ......
    <div class="return-first"><a href="#/first-page"><b>Return / 返回页首</b></a></div>
</div>

class为return-first的块中有一个链接，这个链接指向了首页。

3.示例代码

这里提供一个简洁版本的模板，除了主要内容之外一切皆无：
将三个文件放入一个文件夹即可。

html

<!DOCTYPE html>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Test</title>
    <link rel="stylesheet" href="style.css"/>
</head>
<body>
<div id="impress">
    <div class="no-support-message">
        Your browser doesn't support impress.js.It can't phones.<br>
        你的浏览器不支持impress.js.请更换，它不支持手机。
    </div>
    <div id="first-page" class="step" data-x="0" data-y="0">
        <h1>首页</h1>
        <br>点击你想进入的页面或者按下 "←"、"→"或空格键.</p>
    </div>
    <div class="step" data-x="-700" data-y="-200" data-scale="0.6" data-rotate-z="-45">
        <h1>第一块-第一页</h1>
    </div>
    <div class="step" data-x="-1100" data-y="100" data-scale="0.4" data-rotate-z="-135">
        <h1>第一块-第二页</h1>
    </div>
    <div class="step" data-x="-1300" data-y="-100" data-scale="0.2" data-rotate-z="-45">
        <h1>第一块-第三页</h1>
        <div class="return-first"><a href="#/first-page"><b>Return / 返回页首</b></a></div>
    </div>
    <div class="step" data-x="800" data-y="-300" data-scale="0.6" data-rotate-z="45">
        <h1>第二块-第一页</h1>
    </div>
    <div class="step" data-x="1150" data-y="50" data-scale="0.4" data-rotate-z="135">
        <h1>第二块-第二页</h1>
    </div>
    <div class="step" data-x="1400" data-y="-200" data-scale="0.2" data-rotate-z="45">
        <h1>第二块-第三页</h1>
        <div class="return-first"><a href="#/first-page"><b>Return / 返回页首</b></a></div>
    </div>
</div>
<script type="text/javascript" src="impress.js"></script>
<script>impress().init();</script>
</body>
</html>

css

h1,h2,h3,h4,h5,h6,a,p{
font-family: "Microsoft YaHei" ! important;
}
body{
    margin: 0px;
}
.return-first{
    margin-top: 50px;
}
.return-first a{
    font-size: 20px;
    text-decoration: none;
    color: #000000;
}
.return-first a:hover{
    font-size: 21px;
    color: #006688;
}
.step { 
    width:940px; 
    margin:0 auto 24px auto; 
    text-align:center; 
}
.no-support-message { 
    display:none; 
    width:940px; 
    margin:0 auto 24px auto; 
    text-align:center;
}

js

自备impress.js

【VPS/DNS/Nginx】Blog域名，服务器转移

dtysky — Sunday, 26 Apr 2015 20:01:00 -00:00

由于某些原因我将Blog的域名从dtysky.github.io转移到了dtysky.moe，并且由于另一些原因将服务器转移到了某家的VPS上（正好有Github学生包的Digitalocean的优惠，可以用一年），这二者加上Dnspod提供的解析服务，基本足够满足我以后的某些需求了，比如某些项目的发布和Wiki，比如准备在一个半月内发布的这个FPGA Imaging Library。

1.注册域名：

首先去Godaddy注册了dtysky.moe域名，这个没什么特别需要注意的，不过有朋友推荐moe域名（或者说泛ACG域名，比如.lu .wtf啥的，有没人想搞个"foreveralone.wtf.lu.rip"哈哈哈）在hostker买，看了一下的确要便宜不少（差不多一半），如果一定要在Godaddy购买的话，建议去搜一下优惠码，我就优惠了30%...

2.注册Dnspod并添加网站：

由于Godaddy提供的DNS解析可能被墙，所以建议去Dnspod注册一个账号，随后将你的域名添加进去，之后然后按照这里的教程在Godaddy上修改你的域名服务器，生效需要十几分钟到几十个小时。
改完域名服务器后，在Dnspod的控制台对你的域名添加DNS记录，记录类型啥的知识这里就不说了，总之，至少建立一条记录类型为A的记录，主机记录填写@，也就是根域名，随后将记录值指向你的服务器IP，对于这个IP的选择：

1.继续使用Github-pages：

如果你仍然想使用Github的github-pages服务，那么在这里找到你需要的IP地址，填上，并且再建立一条类型为CNAME的记录，主机记录填写www（如果你期望将根域名作为你的blog地址）或者其他（将二级域名作为blog地址，比如blog），记录值指向你原来的Github-pages的地址就OK了（比如dtysky.github.io）。
之后，在你的Github-pages工程根目录下新建一个名为CNAME的文件，把你的域名（比如dtysky.moe）填进去就OK。

2.使用自己的服务器：

如果你想使用自己的服务器（搭建服务器可以参考下面），那么就将服务器IP填上，随后再建立一条A记录，主机记录填写*，也就是泛解析，在泛解析下，所有的二级域名都会被解析到指定的记录值，记录值同样填写服务器IP。

3.购买VPS并配置服务器：

由于每个人选择的VPS服务商不同，所以如何购买就不赘述了，要注意在选择VPS类型的时候，按照需求即可，对于挂几个静态网站而言，512内存完全够了。。。系统的选择，我这里实例用的是Ubuntu，看需求吧（俺不是xxxer，见谅）。

1.准备：

建立了VPS后，应该可以看到服务商给了你一个IP地址，这个IP就是上面那个记录值需要的IP，这个IP同样也要用于管理你的VPS。
至于VPS的安全协议，随便吧，懒点就SSH，下个PuTTYGen生成一个就成，使用说明自己找吧，挺简单的。
接下来就是实际的服务器配置了，这里建议首先备好工具PuTTY和Winscp，前者是命令行环境，用于调试，后者是FTP环境，用于文件管理。

2.配置

首先打开PuTTY，按照你选的安全协议连接到服务器，之后安装nginx，nginx是一个HTTP和反向代理服务器，这里用来做域名管理，安装只需要执行以下命令行代码：

apt-get update
apt-get install nginx

等待安装完成，完成后首先执行以下命令启动以下并检测状态（假定安装使用默认设置）：

/etc/init.d/nginx start
/etc/init.d/nginx status

如果显示not running，一般是80端口被占用，要么在配置文件改端口，要么停止冲突的服务，如何查看端口被某个服务占用请自行谷歌。
解决冲突问题或者需要更改配置来解决冲突或者没有冲突的，可以进行配置文件管理了，打开Winscp，连接到服务器，打开以下文件夹：

/etc/nginx

为了方便管理，我们新建一个名为vhosts的文件夹，顾名思义就是“虚拟主机”的意思，随后打开nginx.conf文件，在

http {
    .....
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

的最后添加这一句：

include /etc/nginx/vhosts/*.conf;

然后根据你要管理的域名建立若干配置文件，比如我要管理dtysky.moe和fil.dtysky.moe，我就建立了：

dtysky.moe.conf
fil.dtysky.moe.conf

然后根据建立虚拟主机的语法修改每个配置文件就可以了，比如我打开dtysky.moe.conf文件，写入以下内容：

server { 
    listen 80; 
    server_name dtysky.moe; 
    root /www/dtysky.moe;
    index index.html index.htm;
    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html; 
    location = /50x.html {
          root html;
    }
} 
server { 
    listen 80; 
    server_name www.dtysky.moe; 
    location / {
        rewrite ^/(.*)$ http://dtysky.moe/$1 permanent;
    }
}

想解决上面端口冲突的朋友可以把这里的端口（listen 80;）改成别的，同时还要对enable-site/default文件进行同样的修改。

第一个server内表明将域名dtysk.moe的请求定向到/www/dtysky.moe文件夹下，这个文件夹就是我本地放blog资源的文件夹，你可以按照你的需求更改。
第二个server下的内容表示将www.dtysky.moe的请求重定向到dtysky.moe，具体请自行学习nginx的语法规则。

fil.dtysky.moe.conf基本是同样的写法，如下：

server { 
    listen 80; 
    server_name fil.dtysky.moe; 
    location / {
        root /www/fil.dtysky.moe; 
        index index.html index.htm;
    }
    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html; 
    location = /50x.html {
          root html;
    }
}

当然这不是唯一的方法，我们同样可以直接把每个虚拟主机的配置都直接写到nginx.conf内，看需求了。

配置完成后，用以下命令对nginx进行重启：

/etc/init.d/nginx reload
/etc/init.d/nginx restart

【Vivado/FPGA】包含Fifo或者BRam等xci文件的IP封装注意

dtysky — Sunday, 12 Apr 2015 20:01:00 -00:00

Vivado提供了全新的设计模式，其中一项就是用户自己可以封装IP，然后在其他工程中方便地调用，用户可以自己设计IP界面等等，IP的文件结构我已经很清晰了，不过不会在这里写出，将会在之后的毕业论文中同步写出一个系列。此片博文主要记录了在封装IP中的一个问题，这个问题将会引起严重警告[filemgmt 20-1741]和[Synth 8-2488]。

1.问题描述

我封装的某些IP中使用到了官方IP库中的Fifo和BlockRam，在封装时包含了它们的xci文件，由于需求问题，我封装的IP形式如下：

Rows8x512和Rows1x512

这二者的区别在于它们内部实例化的Fifo的位宽，一个是8位，一个是1位，为了方便起见，我将两个IP内的Fifo都实例化为了“Fifo”这个名字，也就是说两个IP内包含的、依赖于xci文件的子IP拥有着相同的名字。
随后我在一个工程中同时实例化了这两个IP，综合后出现了以下警告：

[filemgmt 20-1741] File 'Fifo.vhd' is used by one or more modules, but with different contents, and may lead to unpredictable results:
Fifo (b:/Complex_Mind/Graduation_Project/ProjectBuilt/Gobang/Gobang.srcs/sources_1/bd/Gobang/ip/Gobang_Rows8x512_0_0/sources_1/ip/Fifo/synth/Fifo.vhd)
Fifo (b:/Complex_Mind/Graduation_Project/ProjectBuilt/Gobang/Gobang.srcs/sources_1/bd/Gobang/ip/Gobang_Rows8x512_1_0/sources_1/ip/Fifo/synth/Fifo.vhd)
* Fifo (b:/Complex_Mind/Graduation_Project/ProjectBuilt/Gobang/Gobang.srcs/sources_1/bd/Gobang/ip/Gobang_Rows1x512_0_0/ip/Fifo/synth/Fifo.vhd)
Please reset and regenerate these modules to resolve the differences, or synthesize them independently.

[Synth 8-2488] overwriting existing primary unit fifo ["b:/Complex_Mind/Graduation_Project/ProjectBuilt/Gobang/Gobang.srcs/sources_1/bd/Gobang/ip/Gobang_Rows1x512_0_0/ip/Fifo/synth/Fifo.vhd":59]

一开始并没有在意这种问题，但是实际测试的失败让我不得不回来查找问题的所在之处，在查看综合后的原理图之后我发现了以下问题：

很显然，Rows8x512中位宽为8的Fifo被覆盖了，覆盖成了位宽为1的Fifo，所以in_data直接被削减为了1位，这是由于两个IP钟Fifo子IP的名字是一致的，因为xci只会生成一个总的子IP文件，而不会为每个IP单独生成。

2.解决方案

解决方案就是改名，将不同的IP中依赖的子IP起上不同的名字就好，这样虽然改起来麻烦点，但却可以保证IP中只包含子IP的xci文件，这是十分轻量的做法，予以推荐，当然这种做法并不能保证百分百得完美，毕竟工程大了之后重名的可能性也会提高不少，但没有其他办法。

【Graphviz/Dot】网络图设计

dtysky — Monday, 02 Mar 2015 20:01:00 -00:00

诚然，MS的visio是个很强大的网络图工具，不但如此，其他的工具也很多，他们有一个共同点就是图形化界面，这对于一般用户是很友好的，但对于码农，或者说追求更加一点的可控性和效率亦或是懒人而言，还是码代码来的好写，生成排版就交给程序自己去做嘛（当然控制欲极强的人就绕道吧，用这个实现只会更加复杂），所以在基友的推荐下，用了下Graphviz——一个基于Dot语言的流程设计环境，意外感觉不错？

1.安装

在这里下载Graphviz：
http://www.graphviz.org/Download..php

根据自己os的类型选择下载完毕后，打开gvedit，我们就可以开始使用了。

2.入门

1.新建：
点击New按钮，新建一张流程图。

2.第一张图：首先，在xxx.gv文件中输入代码：

graph x{
a -- c;
b -- c;
}

其次，键盘F5，便可以生成：

这是一张最简单的无向图，使用graph定义，元素依存关系用双横杠表征。

3.编码：
如果没有做任何设定，中文无法被正常编码，只会出现一个个方块，这时候我们可以这样解决：

首先，将文本保存为utf-8（默认是utf-8）。
其次，将字体设定为包含中文的自定字体:

edge [fontname="yourfontname"];
node [fontname="FangSong"];

前一个表示边缘的字体，后一个是节点的字体。

比如我这里是：

graph x{
    edge [fontname="FangSong"];
    node [fontname="FangSong"];
    a [label="我"];
    b [label="妹妹"];
    c [label="女儿"];
    a -- c;
    b -- c;
}

结果是：

4.属性：
不错，以上“编码”便是图的一种属性，每个元素都可以拥有各自的属性。

属性的定义方式也很简单，其基本形式如下：

x [xa="",xb=""....]

如上面说的一样，label也是一种属性，指的是元素的内容，还有很多其他属性，比如框图样式、连线样式等，不再赘述。

5.有向图：
有向图用digraph定义，反向和依存关系用横杠加箭头表征，例子如下：

digraph x{
    edge [fontname="FangSong"];
    node [fontname="FangSong"];
    a [label="我",color=blue];
    b [label="妹妹",color=green];
    c [label="女儿",color=red,shape=box];
    a -> b [label="兄妹",dir=both];
    a -> c [color=blue,label="父亲"];
    b -> c [color=green,label="母亲"];
}

结果：

6.和sublime协作：
如果不想用他自带的ide，又想达到差不多或者更好的使用体验，可以用别的编辑器，我用sublime，如下操作：
新建sublime的bulid文件dot.sublime-bulid，写入以下内容：

{
"shell_cmd": "yourdot.exepath -Tpng $file -o $file.png",
"file_regex": "^.+ in (.+) on line ([0-9]+)",
"selector": "source.dot",
"encoding":"cp936"
}

把yourdot.exepath替换成你graphviz安装目录下bin\dot.exe文件的绝对路径，或者将bin目录加到环境变量，直接写dot就可以。
之后打开你的dot文件，写入你的语句。
ctrl+b进行bulid，第一次生成png图像（你可以控制参数生成不同的）。
用sublime打开Png。
以后修改的时候直接bulid，之后sublime会自动响应刷新修改后的图像（本来想直接写个插件不用这么麻烦来着，没时间，以后再说ww）。
整体如下：

【Python】反射

dtysky — Sunday, 22 Feb 2015 15:01:00 -00:00

以下例子皆基于这个工程：
https://github.com/dtysky/Gal2Renpy/tree/master/Gal2Renpy
反射，指的是程序可以对自身进行访问、修改等等的能力，一个具有反射特性的语言能够为我们提供许多便利-比如轻松地实现扩展，轻松地实现事件等添加等等，我们可以获得任何一个类、函数、实例、模块等自身的信息，通过这些信息进行一些动态的操作，使得某些功能的实现更为简单和清晰。

1.需求

在编写游戏剧本解析器的时候我遇到了某些问题，这源于一个需求：

如何能够采用某种方式，使得用户可以自己扩展一个标签，并且编写自己的py代码去实现这个标签的所有功能？

这意味着我需要去寻找这样的一种方法：

一开始搜索所有具有某种相同特性的“类”，之后自动创建他们的实例，在之后去调用这些实例中相同的方法

如果能够实现这样的方法，之后只需要提供给用户一个接口（扩展的规范），用户按照这个规范来编写自己的类，放到指定位置，程序就能够自动识别这个类作为自己的一部分，从而便完成了扩展。
在寻找了一段时间后，我终于找到了方法，这个灵感是在编写sublime的插件时出现的，也就是利用py的反射特性和“万物皆对象”的哲学，来完成这个需求，下面我就会用这个实例来说明。

2.实现

1.获取当前类名：
定义一个类后，我们可以使用以下方法获取类自身的信息：

self.__class__.xxx

对于类的名字，我们可以用以下方法获得：

self.__class__.__name__

这样一来我们就有了判断某个类是否属于某个预定好的类型的一个简单方法——使用正则去检查类的名字，属于某个规范的均为一类，比如我想要设定一个规范，这个规范下的类要执行的是一些要创建某些东西的方法，我可以这样命名：

class CreatA:
    pass
class CreatB:
    pass

之后使用CreatX去匹配，便可以判断当前类是否是某个规范下的类。
当然我并没有用这个方法，而是用了比较偷懒的方法（也是为了方便管理嘛）——将所有同样类型的类放在同一个文件夹下，比如这个文件夹内就是用于执行所有标签解析方法（规范Sp）的类。

2.继承：
光是获得了类名显然还是不够的，我们必须对类名进行某些处理以便于之后的操作，这里我设计了一个父类，在父类预先定义好一些方法，作为某个规范的标准，之后所有从属于这个规范的类均继承自这个父类。
所有子类使用了驼峰式命名法，并均会被继承自父类的GetFlag方法解析，比如我的Sp规范下的子类：

def GetFlag(self):
    s=self.__class__.__name__.replace('Sp','')
    tmp=''
    for _s_ in s:
        tmp+=_s_ if _s_.islower() else '_'+_s_.lower()
    return tmp[1:]

此方法会返回解析后的类名，比如SpAaBb会返回aa_bb。

3.获取：
创建完所有子类后，我们便可以对他们进行实例化，在程序运行时（比如此处是在剧本解析时），只需要根据他们的名字（此处是标签）来选择对应的实例进行操作即可。
为了实现这个目的，我们首先要获取所有这个规范下的类，我采用的方法如下：
GetAllClass
这是一个函数，用于获取一个文件夹下所有的类，并且判断这个类是否属于某个标签。
py可以传递任何东西，包括模块、类、函数，这位我提供了很大的便利。
这个函数的两个参数中前一个是子类的文件夹路径，后一个是子类的父类。
首先遍历这个文件夹，将后缀为.py的文件作为模块动态导入，并存入Mds列表：

Mds.append(__import__(n))

__import()__

函数用于动态导入模块。

之后遍历拥有所有模块的队列，从模块中获取类的名字：

for d in dir(m):
    d=getattr(m,d)

先注意dir()函数，它是反射的一部分，用于列举参数中所有的属性、方法等等，比如我们可以执行：

>>> import os
>>> dir(os)
['F_OK', 'O_APPEND', 'O_BINARY', 'O_CREAT', 'O_EXCL', 'O_NOINHERIT', 'O_RANDOM', 'O_RDONLY', 'O_RDWR', 'O_SEQUENTIAL', 'O_SHORT_LIVED', 'O_TEMPORARY', 'O_TEXT', 'O_TRUNC', 'O_WRONLY', 'P_DETACH', 'P_NOWAIT', 'P_NOWAITO', 'P_OVERLAY', 'P_WAIT', 'R_OK', 'SEEK_CUR'
...............

再注意getattr()函数，它的作用是获取m.d属性：

>>> getattr(os,'walk')
<function walk at 0x00000000020AD9E8>

接下来便可以判断这个当前的对象是不是类、以及是不是我们需要的子类了：

def IsClass(d):
    return type(d)==type(ParentClass)
def IsSubOfTag(d):
    return issubclass(d,ParentClass)

第一个函数用于判定当前对象的类型，如果是类则返回真，否则返回假。这里使用了type()方法，这个方法用于判定对象的类型：

>>> type(getattr(os,'walk'))
<type 'function'>

第二个函数判定当前已经被判定为类的对象是否为父类ParentClass的子类，使用了issubclass方法。

以上都结束后便可以将所有符合要求的子类构成干的列表返回备用了。

4.实例化：
有了子类构成的列表我们便可以开始利用这些子类了，利用的先决条件是进行实例化，实例化之后可以选择立即使用或者存以待用，比如以下代码是存以待用的一个例子：

def SpCreat(SpSyntaxPath='SpSyntax'):
    Cls=GetAllClass(SpSyntaxPath,SpSyntax)
    Objs={}
    for c in Cls:
        obj=c()
        Objs[obj.GetFlag()]=obj
    return Objs

首先使用上面的GetAllClass方法获取所有Sp规范的子类，然后对每一个子类进行实例化，实例化之后利用每一个子类的GetFlag方法获取其名字，之后将名字和其本身作为键值对存入字典，之后便可以根据标签名来查找这个字典、去调用对应对象的方法了。
比如，我可以设定一个规范，所有Sp规范下的子类必须有一个Show方法，去返回这个子类职责下执行的结果，那么日后我便可以这样用：

SpC = SpCreat()
SpC[NowTag].Show()

结束。