Procedural 3D without GLTF — why I generate everything in code

Most 3D web demos ship a .glb that is larger than the JavaScript itself. VULPA-9 does the opposite: every CPU pin, heatsink fin, and lab wall is generated at runtime from Three.js primitives, shaders, and canvas textures.

Why not just import a model?

An average hardware showroom with five .glb assets is 3–8 MB compressed. That already breaks the performance budget before any code loads. Procedural generation flips the cost:

No extra network requests for models
Instancing reuses geometry (one heatsink fin → 42 fins)
Canvas textures replace image textures without an extra fetch

The initial bundle lands <1 MB gzipped, and the app is fully offline-capable via a Service Worker.

One fin becomes forty-two

A heatsink is a perfect example. Instead of modeling 42 fins by hand, I generate one BoxGeometry and instance it:

const finGeometry = new THREE.BoxGeometry(0.02, 0.8, 0.6);
const fins = new THREE.InstancedMesh(finGeometry, material, 42);
for (let i = 0; i < 42; i++) {
  dummy.position.set(i * 0.035 - 0.7, 0, 0);
  dummy.updateMatrix();
  fins.setMatrixAt(i, dummy.matrix);
}
scene.add(fins);

Add a slight emissive shader and a baked ambient-occlusion canvas, and it reads like a real cooler without any texture file.

Voice control without frustration

VULPA-9 also ships a bilingual Voice AI that understands Indonesian and English. The Web Speech API is powerful but mishears technical terms. I layer a Levenshtein distance fuzzy matcher with dynamic thresholds:

Short words (ram, cpu) get a strict threshold (distance ≤ 1)
Long phrases (tampilkan mode x-ray) tolerate distance ≤ 3
A phonetic dictionary maps common mishearings (vulpa ↔ falpa ↔ bulpa)

That pipeline — transcript → tokenize → fuzzy match → intent — turned “show ex-ray” into XRAY_MODE reliably.

The constraint was the feature

Going model-free forced better engineering: instancing taught me about GPU memory, shaders replaced Photoshop, and the voice pipeline made the app accessible without a mouse. Sometimes the cheapest asset is no asset at all.

Procedural is not about showing off. It's about paying the cost where it matters — in code that can be versioned, cached, and reused.

Why not just import a model?

An average hardware showroom with five .glb assets is 3–8 MB compressed. That already breaks the performance budget before any code loads. Procedural generation flips the cost:

No extra network requests for models

Instancing reuses geometry (one heatsink fin → 42 fins)

Canvas textures replace image textures without an extra fetch

The initial bundle lands <1 MB gzipped, and the app is fully offline-capable via a Service Worker.

One fin becomes forty-two

A heatsink is a perfect example. Instead of modeling 42 fins by hand, I generate one BoxGeometry and instance it:

const finGeometry = new THREE.BoxGeometry(0.02, 0.8, 0.6); const fins = new THREE.InstancedMesh(finGeometry, material, 42); for (let i = 0; i < 42; i++) { dummy.position.set(i * 0.035 - 0.7, 0, 0); dummy.updateMatrix(); fins.setMatrixAt(i, dummy.matrix); } scene.add(fins);

Add a slight emissive shader and a baked ambient-occlusion canvas, and it reads like a real cooler without any texture file.

Voice control without frustration

Short words (ram, cpu) get a strict threshold (distance ≤ 1)

Long phrases (tampilkan mode x-ray) tolerate distance ≤ 3

A phonetic dictionary maps common mishearings (vulpa ↔ falpa ↔ bulpa)

That pipeline — transcript → tokenize → fuzzy match → intent — turned “show ex-ray” into XRAY_MODE reliably.

The constraint was the feature

Procedural is not about showing off. It's about paying the cost where it matters — in code that can be versioned, cached, and reused.