Three.js

Was ist es?

Three.js ist die De-facto-Library für WebGL — Szenen, Kameras, Materialien, Loader, Post-Processing. Imperativ, low-level genug für volle Kontrolle, hoch-level genug für schnellen Einstieg.

Quickstart

pnpm add three
pnpm add -D @types/three

import * as THREE from 'three'
const scene = new THREE.Scene()
const camera = new THREE.PerspectiveCamera(75, w/h, 0.1, 1000)
const renderer = new THREE.WebGLRenderer({ antialias: true })
renderer.setSize(w, h)
scene.add(new THREE.Mesh(geo, mat))
renderer.render(scene, camera)

Typische Patterns

• GLTFLoader für 3D-Assets aus Blender / SketchUp.
• requestAnimationFrame-Loop für Render-Updates, niemals setInterval.
• OrbitControls aus three/examples/jsm/controls/ für Mouse-Steuerung.
• InstancedMesh für Tausende identischer Objekte (eine Draw-Call).
• dispose() explizit aufrufen — Three managt kein GC für GPU-Ressourcen.

Gotchas / Was oft schiefgeht

• Memory-Leaks: Geometries, Materials, Textures müssen manuell dispose()d werden — sonst frisst die GPU sich voll.
• Renderer-Resize bei Window-Resize vergessen → verzerrtes Bild. renderer.setSize + camera.aspect + updateProjectionMatrix.
• pixelRatio auf Retina nicht setzen → blurry. Aber: Math.min(2, window.devicePixelRatio) als Cap.
• Three-Versionen brechen oft API (z. B. OutlinePass, EffectComposer-Imports) — Changelog lesen.
• In React: Lifecycle vs Render-Loop entkoppeln, sonst Re-Renders zerstören Szene.

Wann nicht?

Reines 2D oder einfache Charts → Canvas-API / PixiJS / D3 reichen. WebGPU-only-Projekte → Babylon.js oder native WebGPU. In React fast immer @react-three/fiber als Wrapper.