Architecture Overview

How Particle Engine v2 is organized — from GPU hardware to gameplay systems. Everything flows through the VirtualGPU abstraction layer.

The Big Picture

Particle Engine v2 is a pure-browser WebGPU game engine. There is no Node.js, no build step, no transpilation. Every module is an ES module that runs directly in the browser. The engine is organized into layers, each building on the one below it:

Key insight: The VirtualGPU layer is the foundation of everything. All rendering, simulation, and compute work goes through it. Understanding vGPU is the single most important thing for working with this engine. Read the vGPU guide →

Layer Breakdown

Layer 1: WebGPU API (Browser)

The raw WebGPU API provided by the browser. It gives low-level access to GPU hardware — device creation, buffer allocation, shader compilation, command encoding, and queue submission. Powerful but verbose.

Layer 2: VirtualGPU — The Core Abstraction

The VirtualGPU class wraps the raw WebGPU API with automatic resource management. Instead of writing 20+ lines of boilerplate, you write 1 line:

// Initialize once
const vgpu = await VirtualGPU.create();

// Create a buffer — vGPU handles usage flags, pooling, tracking
const { buffer } = vgpu.buffer.create({ size: 1024, usage: 'vertex' });

// Compile a shader — cached automatically
const module = vgpu.shader.compile('myShader', wgslCode);

// Create a render pipeline — blend states resolved from strings
const pipeline = vgpu.pipeline.render({ vertex: { module }, fragment: { module }, blend: 'alpha' });

The vGPU layer manages 6 core subsystems plus 20+ advanced modules:

SubsystemAccessPurpose
vgpu.bufferAPI →Buffer creation, writing, pooling
vgpu.bindingsAPI →Bind group layouts, bind groups, caching
vgpu.shaderAPI →Shader compilation, caching, hot reload
vgpu.pipelineAPI →Render/compute pipelines, async creation
vgpu.textureAPI →Texture & sampler creation
vgpu.commandAPI →Command batching & scheduling

Layer 3: ECS + Rendering

The Entity-Component-System holds all game state. Entities are just IDs. Components are typed data arrays. Systems are functions that run each frame. The rendering pipeline reads from ECS components to draw the world.

Entity created
Components attached
Systems process
Renderer draws

Layer 4: Simulation Systems

GPU-accelerated simulation runs on compute shaders via vGPU. This includes:

Layer 5: Applications

The top layer is what users interact with:

Directory Map

The repository is organized by concern. Each top-level folder has a clear purpose:

engine/                     ← Engine core (the library)
├── core/
│   ├── gpu/                ← VirtualGPU + 50 GPU utilities
│   ├── math/               ← Vec3, Mat4, Quat, scalar math
│   ├── events/             ← Event bus, signals
│   └── framegraph/         ← Frame graph resource scheduling
├── ecs/                    ← Entity-Component-System
│   ├── components/         ← Transform, Camera, Light, etc.
│   ├── systems/            ← Physics, Render, Camera systems
│   └── world/              ← World management
├── render/                 ← Rendering pipeline
│   ├── particles/          ← 30+ particle renderers
│   ├── shaders/            ← WGSL shader modules
│   ├── materials/          ← Material system
│   └── passes/             ← Render passes (depth, color, post)
├── sim/                    ← Simulation
│   ├── particles/          ← 60+ particle sim modules
│   ├── physics/            ← Rigid body physics
│   ├── cloth/              ← Mass-spring cloth solver
│   └── fluids/             ← Eulerian fluid sim
├── audio/                  ← Audio engine
│   ├── synth/              ← Procedural synthesis nodes
│   ├── bridge/             ← Material↔sound bridges
│   └── core/               ← Audio context, worklets
└── net/                    ← Networking (protocol, replication)

editor/                     ← Scene editor application
├── js/
│   ├── modules/            ← EditorParticles, EditorAudio, etc.
│   ├── panels/             ← Viewport, Inspector, World panel
│   └── components/         ← UI components
└── css/                    ← Editor styles

tests/                      ← Documentation & demo site (you are here)
├── guide/                  ← Engine manual
├── api/                    ← API reference
├── examples/               ← Interactive demos
└── common/                 ← Shared theme & utilities

Data Flow: A Single Frame

Here's what happens every frame in the editor (the most complex case):

1. Input
Mouse, keyboard → camera orbit, entity selection
2. ECS Step
stepWorldFrame() → all systems run
3. Particle Sim
GPU compute: physics, thermal, SPH, flocking, collisions
4. Cloth/Rope Sim
GPU compute: PBD constraints
5. Audio Extract
GPU readback: particle lights, heat
6. Render Frame
Depth pre-pass → Entity meshes → Grid → Particles (half-res) → Composite → Post-FX
7. GPU Submit
vgpu.command encoder → queue.submit() → present to canvas

Design Principles

GPU-First

Heavy work runs on compute shaders. The CPU orchestrates, the GPU executes. Particle physics, sorting, fluid sim, and even audio extraction happen on the GPU.

ECS-Driven

All game state lives in components. No inheritance hierarchies, no scene graph. Entities are IDs, components are data, systems are functions.

Pure Browser

No Node.js, no bundler, no build step. Every file is an ES module loaded directly by the browser. Development is instant — save and refresh.

vGPU Abstraction

The VirtualGPU layer eliminates WebGPU boilerplate. Buffers, pipelines, shaders, and textures are created with clean one-liners while caching and pooling happen automatically.

What to Read Next

Virtual GPU Guide

The most important page. Learn how the vGPU abstraction simplifies everything.

Read vGPU Guide →

ECS v2 Guide

Understand the entity-component-system that holds all game state.

Read ECS Guide →

Particle System

The engine's flagship system — 100M+ GPU particles with full physics.

Read Particles Guide →

API Reference

Complete function-by-function reference for all engine modules.

Browse API →