从场景图到数据导向：WebGPU渲染架构的范式转移与工程实现

传统3D渲染引擎的核心是一个树状场景图。每个物体是一个节点，节点持有变换矩阵、材质引用和网格数据。渲染一帧的流程是：从根节点开始递归遍历，逐节点更新世界矩阵，逐节点提交绘制调用。这套架构在几百个物体的场景下工作良好，但当物体数量增长到几万甚至几十万时，它开始崩溃。

崩溃的根源不在于GPU不够快，而在于CPU成为了瓶颈。每帧遍历十万个节点、为每个节点更新矩阵、为每个节点发起一次draw call——这些操作全部在主线程上串行执行。渲染时间不再是“可见物体数量”的函数，而是“场景中总物体数量”的函数。一个在屏幕外被完全遮挡的物体，仍然要消耗一次遍历、一次矩阵更新和一次draw call的成本。

2026年，WebGPU的成熟让前端渲染架构有了重新设计的可能。Compute Shader、Storage Buffer、Indirect Draw这些WebGL时代不存在的能力，让“GPU驱动的渲染管线”从理论走向了工程实践。本文以NullGraph的数据导向设计为参照，从内存布局、GPU驱动可见性、无GC架构和增量编译四个层面，拆解WebGPU渲染引擎的架构范式转移。

一、数据导向设计：从AoS到SoA的内存布局重构
传统场景图采用面向对象的设计。一个物体是一个对象，包含position、rotation、scale、material、mesh等属性。在内存中，这些属性以结构体数组（AoS, Array of Structures） 的形式存储——每个物体对象的字段连续排列，对象之间也连续排列。

这种布局的问题在于缓存局部性。当渲染器需要遍历所有物体的变换矩阵时，它实际上只需要modelMatrix一个字段，但每次读取都会把整个对象加载到CPU缓存中。一个包含位置、旋转、材质引用、网格引用的对象可能有几百字节，其中真正被遍历用到的只有64字节的变换矩阵。缓存命中率因此极低。

数据导向设计将布局翻转为数组结构体（SoA, Structure of Arrays） 。所有物体的变换矩阵连续存储在一个Float32Array中，所有物体的材质ID连续存储在另一个Uint32Array中。遍历时，渲染器只访问需要的那一个数组，缓存行被充分利用。

javascript
// 传统 AoS 布局（不推荐）
const objects = [
  { position: [0,0,0], rotation: [0,0,0,1], scale: [1,1,1], materialId: 0, meshId: 0 },
  { position: [1,0,0], rotation: [0,0,0,1], scale: [1,1,1], materialId: 1, meshId: 0 },
  // ...
];

// 数据导向 SoA 布局
class RenderData {
  constructor(capacity) {
    // 每个物体的 4x4 变换矩阵，连续存储
    this.matrices = new Float32Array(capacity * 16);
    // 每个物体的材质 ID
    this.materialIds = new Uint32Array(capacity);
    // 每个物体的网格 ID
    this.meshIds = new Uint32Array(capacity);
    // 每个物体的包围盒（用于 GPU 剔除）
    this.aabbs = new Float32Array(capacity * 6); // minX,minY,minZ,maxX,maxY,maxZ
    this.count = 0;
  }

  addObject(matrix, materialId, meshId, aabb) {
    const i = this.count++;
    this.matrices.set(matrix, i * 16);
    this.materialIds[i] = materialId;
    this.meshIds[i] = meshId;
    this.aabbs.set(aabb, i * 6);
  }

  // 将数据直接映射到 GPU Storage Buffer
  getMatrixBufferView() {
    return this.matrices.subarray(0, this.count * 16);
  }

  getMaterialBufferView() {
    return this.materialIds.subarray(0, this.count);
  }
}
SoA布局的工程收益是直接的：变换矩阵的遍历速度提升数倍，因为一次缓存行加载可以覆盖多个物体的矩阵数据。更重要的是，这些Float32Array可以零拷贝地映射到WebGPU的Storage Buffer。渲染器不需要把数据从JS对象序列化为GPU可读的格式，数据在Web Worker中计算完成后，直接通过postMessage的Transferable传递到主线程，然后device.queue.writeBuffer写入GPU——全程没有对象创建，没有GC压力。

二、零场景图：GPU直接读取扁平数组
传统场景图的traverse()和updateMatrixWorld()是渲染管线中最昂贵的两个操作。前者递归遍历树结构，后者为每个节点计算世界矩阵（通常是父矩阵乘以本地矩阵的4x4矩阵乘法）。

零场景图的核心思想是：把世界矩阵的计算移到GPU上。CPU只负责维护一个扁平的变换矩阵数组，不做任何层次遍历。渲染时，Vertex Shader直接从这个数组中读取矩阵，完成顶点变换。

这听起来简单，但有一个前提条件：所有物体的变换必须已经在世界空间中，或者GPU需要知道父子关系。对于静态场景（地形、建筑），世界矩阵在数据加载时一次性计算完成，可以直接存储。对于动态场景，CPU在每帧更新需要变化的矩阵，但更新的是扁平数组中的特定位置，而不是树结构中的节点。

javascript
// 零场景图的更新逻辑：直接修改数组中的矩阵
function updateObjectTransform(data, index, localMatrix) {
  // 世界矩阵 = 父矩阵 × 本地矩阵
  // 但在扁平数组模型中，"父矩阵"在加载时已经合并
  // 这里只处理物体自身的本地变换
  const offset = index * 16;
  // ... 直接写入 data.matrices[offset..offset+15]
}

// 顶点着色器伪代码
// layout(std430, binding = 0) buffer Matrices { mat4 modelMatrices[]; };
// @vertex fn vs_main(@location(0) position: vec3, @builtin(instance_index) iid: u32) -> ... {
//   let worldPos = modelMatrices[iid] * vec4(position, 1.0);
//   ...
// }
这套设计消除了CPU侧的树遍历开销。渲染时间不再随场景中物体总数增长，而是只随可见物体数量增长。一个包含十万个物体的场景，如果只有一千个在视锥体内，CPU只需要提交一次draw call（通过Indirect Draw），GPU在Vertex Shader中自动跳过不可见实例。

三、GPU驱动可见性：Compute Shader剔除与Indirect Draw
传统渲染管线中，视锥剔除在CPU上执行——遍历所有物体，检查其包围盒是否与视锥体相交，跳过不可见的物体。十万个物体的剔除计算量是巨大的，而且剔除结果需要回传给CPU，再由CPU发起draw call，产生了额外的CPU-GPU同步开销。

WebGPU的Compute Shader让剔除可以完全在GPU上执行。流程是：

第一步，CPU将所有物体的包围盒数据（AABB）和变换矩阵写入Storage Buffer。这些数据在上一帧或更早就已经准备好，不需要每帧重新传输。

第二步，Compute Shader在每个线程中处理一个物体，将AABB从本地空间变换到世界空间，然后测试其是否与视锥体相交。相交的物体写入一个“可见列表”缓冲区。

第三步，另一个Compute Shader统计可见物体的数量，生成IndirectDrawArgs结构。这个结构包含顶点数、实例数和起始偏移量。

第四步，drawIndirect命令直接读取这个结构，发起绘制。CPU完全不知道有多少物体可见——它只是发起了一个indirect draw调用。

javascript
// Compute Shader 剔除管线（伪代码）
// @compute @workgroup_size(64)
// fn cull_frustum(@builtin(global_invocation_id) gid: vec3<u32>) {
//   let i = gid.x;
//   if (i >= objectCount) { return; }
//
//   // 从 Storage Buffer 读取 AABB
//   let aabbMin = aabbs[i * 6 + 0..2];
//   let aabbMax = aabbs[i * 6 + 3..5];
//   let modelMatrix = matrices[i];
//
//   // 变换到世界空间
//   let worldMin = (modelMatrix * vec4(aabbMin, 1.0)).xyz;
//   let worldMax = (modelMatrix * vec4(aabbMax, 1.0)).xyz;
//
//   // 视锥体测试
//   if (frustumTest(worldMin, worldMax, frustumPlanes)) {
//     let idx = atomicAdd(&drawArgs.instanceCount, 1u);
//     visibleIndices[idx] = i;
//   }
// }
GPU驱动剔除的价值在于消除CPU-GPU同步点。传统管线中，CPU必须等待上一帧的剔除结果才能发起下一帧的绘制，形成了串行依赖。GPU驱动管线中，剔除、绘制、下一帧的剔除可以流水线并行执行，帧时间不再受CPU处理速度的限制。

四、无GC架构：预分配内存与对象池
JavaScript的垃圾回收对渲染循环是致命的。如果每帧创建临时对象——矩阵、向量、包围盒——GC会在某个时刻触发，暂停整个渲染循环几十毫秒。对于目标60fps（每帧16.6ms）的实时渲染，一次GC暂停足以导致肉眼可见的卡顿。

无GC架构的核心原则是：渲染循环内零对象创建。所有需要的数据结构在初始化时预分配，循环中只读写已有对象的字段，不创建新对象。

javascript
// 预分配的对象池
class VectorPool {
  constructor(size = 1024) {
    this.data = new Float32Array(size * 4); // x, y, z, w
    this.freeList = [];
    for (let i = 0; i < size; i++) this.freeList.push(i);
  }

  alloc() {
    if (this.freeList.length === 0) throw new Error('Pool exhausted');
    return this.freeList.pop();
  }

  free(index) {
    this.freeList.push(index);
  }

  // 直接操作 Float32Array，不创建 Vector 对象
  set(index, x, y, z, w = 0) {
    const o = index * 4;
    this.data[o] = x; this.data[o + 1] = y;
    this.data[o + 2] = z; this.data[o + 3] = w;
  }

  getX(index) { return this.data[index * 4]; }
  getY(index) { return this.data[index * 4 + 1]; }
  getZ(index) { return this.data[index * 4 + 2]; }
}
对于矩阵运算，同样采用“目标参数”模式，而不是返回新对象：

javascript
// 不返回新矩阵，而是写入目标数组
function mat4Multiply(out, outOffset, a, aOffset, b, bOffset) {
  const a00 = a[aOffset], a01 = a[aOffset+1], /* ... */;
  const b00 = b[bOffset], b01 = b[bOffset+1], /* ... */;

  out[outOffset]    = a00 * b00 + a01 * b10 + a02 * b20 + a03 * b30;
  out[outOffset+1]  = a00 * b01 + a01 * b11 + a02 * b21 + a03 * b31;
  // ... 64 个乘法加法
}
这种模式在C语言和Rust中是标准做法，但在JS生态中常常被忽略——因为大多数开发者习惯了vec3.add()这样返回新对象的API。对于渲染循环，必须改用“就地更新”模式。

五、多线程架构：Web Worker中的ECS布局
WebGPU的GPUDevice对象可以在Web Worker中使用。这意味着整个渲染管线——数据准备、Compute Shader调度、Draw Call提交——都可以脱离主线程运行。

数据导向设计与多线程架构天然互补。ECS（Entity-Component-System）的核心是组件数组，每个组件类型是一个连续的TypedArray。在Web Worker中，系统遍历这些数组，更新位置、速度、旋转等组件数据。完成后，通过postMessage的Transferable机制将ArrayBuffer的所有权转移给主线程，无需拷贝。

javascript
// Worker 中的 ECS 更新循环
class ECSWorld {
  constructor() {
    this.positions = new Float32Array(MAX_ENTITIES * 3);
    this.velocities = new Float32Array(MAX_ENTITIES * 3);
    this.matrices = new Float32Array(MAX_ENTITIES * 16);
    this.count = 0;
  }

  update(dt) {
    const pos = this.positions;
    const vel = this.velocities;
    const mat = this.matrices;

    for (let i = 0; i < this.count; i++) {
      const pi = i * 3;
      // 更新位置
      pos[pi]     += vel[pi]     * dt;
      pos[pi + 1] += vel[pi + 1] * dt;
      pos[pi + 2] += vel[pi + 2] * dt;

      // 更新矩阵
      const mi = i * 16;
      mat[mi + 12] = pos[pi];
      mat[mi + 13] = pos[pi + 1];
      mat[mi + 14] = pos[pi + 2];
    }
  }

  // 将矩阵数据转移到主线程
  transferMatrices() {
    const copy = this.matrices.slice(0, this.count * 16);
    return copy.buffer;
  }
}

// 主线程
worker.onmessage = (e) => {
  const buffer = e.data.buffer; // ArrayBuffer 转移
  device.queue.writeBuffer(matrixBuffer, 0, buffer);
  // 直接提交渲染，不需要等待 CPU 处理
};
这套架构的工程价值在于主线程只负责GPU命令提交，所有数据计算在Worker中完成。UI交互、事件处理、布局计算都不受渲染负载影响，页面在渲染十万个物体时仍然保持响应。

六、增量编译与状态持久化
数据导向架构的另一个优势是增量更新。传统场景图中，修改一个物体的变换需要遍历树找到该节点，更新本地矩阵，然后递归更新所有子节点的世界矩阵。在扁平数组模型中，修改就是直接写入数组的特定偏移位置。

但这带来一个问题：如果GPU正在读取这个数组进行渲染，CPU同时修改它，会产生竞态条件。WebGPU的解决方案是双缓冲——维护两份数据数组，一份供GPU读取（当前帧），一份供CPU写入（下一帧）。帧结束时交换缓冲区。

对于Compute Shader的持久化，更进一步的优化是状态驻留。上一帧的剔除结果、可见列表、间接绘制参数都可以保留在GPU内存中，下一帧只需增量更新变化的部分。如果场景中只有少数物体移动，Compute Shader可以只重新处理这些物体的包围盒，复用上一帧的剔除结果。这把每帧的GPU工作负载从“全量重新计算”降低到“增量更新”。

javascript
// 双缓冲 + 增量更新
class RenderPipeline {
  constructor(capacity) {
    // 双缓冲矩阵数据
    this.matrixBuffers = [
      device.createBuffer({ size: capacity * 64, usage: STORAGE | COPY_DST }),
      device.createBuffer({ size: capacity * 64, usage: STORAGE | COPY_DST }),
    ];
    this.frontIndex = 0;

    // 脏标记：记录哪些物体的数据发生了变化
    this.dirtyFlags = new Uint8Array(capacity);
    this.dirtyCount = 0;
  }

  markDirty(index) {
    if (!this.dirtyFlags[index]) {
      this.dirtyFlags[index] = 1;
      this.dirtyCount++;
    }
  }

  flushToGPU() {
    if (this.dirtyCount === 0) return; // 无变化，跳过传输

    const back = this.matrixBuffers[1 - this.frontIndex];
    // 只传输脏数据（简化示例，实际需要更精细的 sub-range 管理）
    device.queue.writeBuffer(back, 0, this.matrixData);

    this.frontIndex = 1 - this.frontIndex;
    this.dirtyFlags.fill(0);
    this.dirtyCount = 0;
  }
}
七、性能对比与工程取舍
将上述技术串联，一个数据导向的WebGPU渲染管线在十万物体场景下的典型性能表现是：CPU帧时间从传统场景图的数十毫秒降至亚毫秒级，GPU利用率显著提升，帧率从个位数提升到稳定60fps。

但这个架构并非没有代价。复杂度显著上升：开发者需要手动管理内存布局、处理双缓冲同步、编写Compute Shader剔除逻辑。调试难度增加：GPU端的状态无法直接用console.log查看，需要依赖GPU调试工具和帧捕获。灵活性降低：扁平数组模型不适合频繁增删物体的场景——物体池需要预分配，删除物体只是标记为空位，不能真正释放内存。

工程上的取舍是：如果场景中物体数量在几千以内，传统场景图仍然是最简单可靠的选择。数据导向架构的优势在物体数量超过一万时才开始显现，在十万级时变得不可替代。选择架构的关键判断标准是物体的预期最大数量，而不是当前的需求。

八、总结
从场景图到数据导向，从CPU剔除到GPU驱动可见性，从每帧创建对象到预分配零GC，WebGPU渲染架构的每一次演进都在解决同一个问题：如何让CPU不再成为渲染管线的瓶颈。

SoA内存布局解决了缓存局部性问题，零场景图消除了树遍历开销，Compute Shader剔除消除了CPU-GPU同步点，预分配对象池消除了GC暂停。这四个优化措施是正交的，可以独立实施，也可以组合使用。对于正在构建大规模Web 3D应用的团队而言，理解这些底层机制比选择某个具体引擎更重要——引擎会过时，但数据导向设计和GPU驱动管线的原则，正在成为下一代Web渲染的基础范式。