STREAMING BUFFER CHUNKS // 60 FPS SYNC
STREAMING BUFFER CHUNKS // 60 FPS SYNC
When I set out to engineer my portfolio, I made a conscious choice to avoid conventional approaches. I did not want another static resume or an off-the-shelf 3D template wrapped in generic UI components. Most developer portfolios demonstrate visual polish without systems substance: they embed third-party widgets, rely on pre-baked animations, and hide behind shallow CSS transitions.
I spent six grueling months of full-time systems engineering treating this platform not as a website, but as an operational computing environment.
The journey was tough and unforgiving. I spent weeks debugging subtle concurrency race conditions between Web Workers and the main WebGPU render loop, untangling WebGL2 driver discrepancies across mobile webviews, rewriting shader pipelines in Three Shading Language (TSL), and designing a custom virtual machine from raw C++17 up through a TypeScript assembler toolchain.
The result is the Neurogrid Engine: a web runtime fusing the atmospheric spatial identity of retro-futuristic monoliths (monolithic floating memory towers, ambient cobalt fog, and celestial cluster topology drawn from Japanese cyberpunk aesthetics and tactical telemetry) with an experimental virtual machine running in WebAssembly, and in-browser sandboxed execution environments.
This technical retrospective documents the architectural decisions, low-level mechanics, engineering battles, and the long-run roadmap for the platform.
Building this platform from scratch required six distinct phases of disciplined, test-driven development:
The earliest architectural hurdle was reconciling a continuous 3D world with the Next.js App Router. Traditional multi-page routing destroys the WebGL context on every page switch. Recreating the scene on every route caused memory leaks, shader recompilation hitches, and jarring layout shifts. I spent weeks restructuring the layout hierarchy so a single persistent canvas remains alive at the root while the camera glides smoothly between spatial coordinates derived purely from the URL pathname.
Moving from standard Three.js materials to Three Shading Language (TSL) node materials allowed the engine to target WebGPU natively while maintaining automated fallback to WebGL2. To ensure visual parity across backends, I built a pure TypeScript Structural Similarity Index (SSIM) test harness that renders offscreen golden frames and validates that rendering fidelity never degrades below a 0.985 threshold.
Instead of animating UI elements with standard timer intervals, I authored a custom register-based virtual machine core in C++17 (kei.wasm). I engineered a dedicated Web Worker runtime, a custom instruction set architecture (ISA), memory-mapped I/O channels (MMIO), and a TypeScript assembler toolchain.
To support interactive code execution without remote server infrastructure, I engineered the .kpk LZ4 binary package format. I integrated in-browser execution environments capable of extracting compressed archives directly in client memory.
Rather than loading large audio files over the network, I built a complete procedural sound generator using the Web Audio API. I synthesized chord pads, mechanical feedback, and frequency modulation glitches directly in code, followed by accessibility hardening and a comprehensive refactor.
In conventional 3D web applications, developers frequently mount and unmount separate canvas instances on individual routes. This introduces severe architectural penalties:
1. The GPU hardware context is destroyed and reallocated on every route transition.
2. Shader programs must be re-parsed, compiled, and linked on each navigation, causing dropped frames.
3. Garbage collector spikes from abandoned geometry and texture buffers degrade performance on lower-tier hardware.
To solve this, the application mounts a single Immortal Canvas at the root layout of the Next.js App Router:
The 3D scene never maintains divergent internal routing state. The browser pathname (/, /work, /lab, /oss, /writing, /about, /contact, /dev) is the definitive authority.
When navigation occurs, the CameraRig calculates the target vector for that sector using critically damped exponential decay:
| 1 | const lambda = 4.5; |
| 2 | const delta = clock.getDelta(); |
| 3 | const alpha = 1.0 - Math.exp(-lambda * delta); |
| 4 | |
| 5 | currentCameraPos.lerp(targetSectorPos, alpha); |
| 6 | currentCameraLookAt.lerp(targetSectorLookAt, alpha); |
| 7 | camera.position.copy(currentCameraPos); |
| 8 | camera.lookAt(currentCameraLookAt); |
This mathematical formulation ensures that camera velocity scales proportionally with distance, coming to a rest without oscillation regardless of frame rate fluctuations.
To ensure the graphics pipeline remains viable for modern hardware while maintaining compatibility with legacy systems, all 3D materials are authored in Three Shading Language (TSL):
| 1 | import { uniform, float, vec3, sin, time } from "three/tsl"; |
| 2 | |
| 3 | export function createMonolithMaterial(baseHex: string, emissiveHex: string) { |
| 4 | const pulseSpeed = uniform(1.8); |
| 5 | const glowFactor = sin(time.mul(pulseSpeed)).mul(0.4).add(0.6); |
| 6 | const finalEmissive = vec3(emissiveHex).mul(glowFactor); |
| 7 | |
| 8 | return { |
| 9 | colorNode: vec3(baseHex), |
| 10 | emissiveNode: finalEmissive, |
| 11 | }; |
| 12 | } |
TSL node graphs compile directly to WebGPU Shading Language (WGSL) when WebGPU support is present, and translate to GLSL ES 3.0 when falling back to WebGL2.
To detect rendering discrepancies between backends, I built an automated SSIM (Structural Similarity Index) parity test in pure TypeScript:
| 1 | export function computeSSIM(bufferA: Uint8Array, bufferB: Uint8Array, width: number, height: number): number { |
| 2 | const c1 = 6.5025; |
| 3 | const c2 = 58.5225; |
| 4 | |
| 5 | let meanA = 0, meanB = 0; |
| 6 | for (let i = 0; i < bufferA.length; i += 4) { |
| 7 | meanA += bufferA[i] * 0.299 + bufferA[i + 1] * 0.587 + bufferA[i + 2] * 0.114; |
| 8 | meanB += bufferB[i] * 0.299 + bufferB[i + 1] * 0.587 + bufferB[i + 2] * 0.114; |
| 9 | } |
| 10 | meanA /= (width * height); |
| 11 | meanB /= (width * height); |
| 12 | |
| 13 | return calculateStructuralCovariance(bufferA, bufferB, meanA, meanB, c1, c2); |
| 14 | } |
Automated verification ensures that modifications to post-processing or lighting do not break visual fidelity between WebGPU and WebGL2.
A foundational architectural conviction in this project was breaking away from simple JavaScript timers for scene telemetry. I wanted visual modulation, chromatic pulses, and node heartbeats to stem from an authentic low-level computing process.
The virtual machine powering the current engine is an early, highly experimental 16-bit prototype.
Built in C++17 and compiled to WebAssembly (kei.wasm, 12.8 KB raw / 4.5 KB gzip), it implements a 16-bit register architecture executing inside a dedicated 60 Hz Web Worker:
The current prototype executes a custom bytecode binary (scene.kbc), driving GPU uniforms (HOT_00..HOT_03) and trigger flags (TRIG_00..TRIG_04) across a zero-allocation ring buffer.
However, Kei was never intended to remain a 16-bit microcontroller simulation. It is the beginning of a multi-year, long-run systems vision.
The long-term roadmap transitions Kei from a shader-driving prototype into a full-scale 64-bit hardware & software emulator and in-browser reverse engineering workbench:
The near-term transition to vm/v2 migrates Kei into full 64-bit land:
RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, R8 through R15, instruction pointer RIP, and status flags RFLAGS.CR0, CR2, CR3, CR4).Rather than requiring custom bytecode compilation, the emulator will ingest compiled binaries directly:
.text, .rdata, .data, and .pdata slices directly into virtual addresses.IMAGE_DIRECTORY_ENTRY_BASERELOC blocks, computing ASLR deltas and fixing absolute 64-bit pointer references.VirtualAlloc, CreateThread, memcpy, printf) with virtual host thunks inside the WebAssembly runtime.By executing x86/x64 binaries inside WebAssembly, the portfolio becomes a zero-installation binary analysis workbench:
To bridge the emulator directly with artificial intelligence, I am designing an in-browser Model Context Protocol (MCP) server:
- read_registers: Fetches current GPR and flag states.
- read_memory_slice: Extracts struct data and string tables directly from the emulated memory space.
- disassemble_range: Queries decoded instructions around target virtual addresses.
- set_breakpoint & step_execution: Sets execution traps and advances instructions during runtime debugging.
To allow visitors to verify engineering work interactively, the /lab sector hosts sandboxed environments:
.kpk format to compress multi-file directories into a single compact binary payload using LZ4 compression.To deliver responsive acoustic immersion without network overhead, I implemented a procedural audio engine using the Web Audio API:
Throughout the development of this project, I followed a strict set of engineering guidelines:
1. Spec-Data-Test Driven Architecture: Every theme preset, hardware tier, sector configuration, and content metadata item is defined and validated by strictly typed data schemas.
2. Zero Redundant Comments: Code is written to be self-explanatory through naming and structure.
3. Automated Verification: Every build runs data validation (pnpm validate:data), integrity tests (pnpm test:integrity), unit tests (pnpm test:unit), and visual parity tests (pnpm test:parity).
The Neurogrid project represents my commitment to systems-level thinking, deep craftsmanship, and long-term architectural vision.