Mit Claude Code in einer einzigen Sitzung ein 2.5D-Parallax-Animationsstudio aufbauen: 3 zentrale Codeabschnitte für den deterministischen Frame-für-Frame-Export als MP4

Anmerkung des Autors: Von der Eingabeaufforderung über die Tiefenschärfe-Kompensationsformel bis zum Frame-für-Frame-Export mit Playwright und ffmpeg. Dieser Beitrag zeigt Schritt für Schritt, wie Sie mit Claude Code ein 2.5D-Parallax-Animationsstudio bauen, dessen Export keine Frames verliert.

Viele erleben beim ersten Animationsprojekt mit einem KI-Programmierassistenten dasselbe: Die Vorschau im Browser läuft flüssig, aber beim Videoexport ruckelt es, Frames springen, und die Dauer stimmt nicht. Die Ursache liegt oft in der Architektur: Der Export wurde von Anfang an nicht als Teil des Designs betrachtet. Dieser Artikel dreht sich um den Ansatz reine Funktion renderAt(t) + Screenshot per Frame-Seek. Er zeigt, wie Sie mit Claude Code in einer einzigen Sitzung ein 2.5D-Parallax-Animationsstudio aufbauen und zuverlässig MP4-Dateien exportieren.

Das ist nicht noch eine Demo nach dem Motto „Lass die KI eine Animation schreiben“. Der Artikel zerlegt die Herleitung der Tiefenschärfe-Kompensationsformel, einen sehr typischen Offset-Bug und den grundlegenden Unterschied zwischen Echtzeitwiedergabe und Frame-für-Frame-Export.

Kernnutzen: Nach der Lektüre haben Sie eine wiederverwendbare Struktur für Eingabeaufforderungen, eine reproduzierbare Export-Pipeline und eine Prüfliste, die sich auf andere programmatische Videoprojekte übertragen lässt.

Die wichtigsten Punkte zum 2.5D-Parallax-Animationsstudio mit Claude Code

Die hier beschriebene Praxis stammt aus einem Artikel vom 09.11.2026. Der Autor hat mit Claude Code und Opus 5.5 in nur einer einzigen Sitzung ein Studio als einzelne HTML-Datei gebaut, dazu ein Playwright-Exportskript mit rund 25 Zeilen. Auf dem Laptop des Autors war ein 720p-Video mit 6 Sekunden Länge (180 Frames) in etwa 20 Sekunden exportiert. Der Autor nennt keine Hardwarekonfiguration, daher taugt dieser Wert nur als grobe Größenordnung.

Das Prinzip der 2.5D-Parallax-Animation

Beim 2.5D-Ansatz werden flache 2D-Assets in unterschiedlichen Tiefen in einen 3D-Raum gelegt, und eine virtuelle Kamera fährt dann durch sie hindurch. Ebenen nahe an der Kamera bewegen sich schnell, weit entfernte langsam. Das Auge liest diesen Geschwindigkeitsunterschied als Tiefe – das ist die Parallaxe (Parallax). Dafür braucht es weder Modellierung noch Beleuchtung noch eine 3D-Engine; die CSS-Eigenschaften perspective und preserve-3d im Browser reichen völlig aus.

Der Unterschied zwischen einem „Studio“ und einer „Einmal-Animation“ liegt darin, ob drei Bausteine vollständig vorhanden sind: Szenengraph, Zeitleiste und deterministischer Renderer. Viele Tutorials überspringen den dritten, dabei entscheidet er, ob das exportierte MP4 ruckelt. Deshalb sollten Sie ihn schon in der ersten Zeile der Eingabeaufforderung als feste Anforderung festlegen.

Umgebung und Modellkonfiguration für das Claude-Code-2.5D-Studio

Die Referenzmaterialien empfehlen, den ersten Build mit Opus 5.5 durchzuführen. In der offiziellen Modellübersicht von Anthropic wird es als Modell für „lang laufende agentische Programmierung und Wissensarbeit“ positioniert, mit 1M Token Kontextfenster und maximal 128K Token Ausgabe. Der offizielle Preis liegt bei 4 bzw. 20 US-Dollar pro Million Eingabe- bzw. Ausgabe-Token. Maßgeblich sind jedoch immer die aktuellen Angaben auf der offiziellen Seite.

Wir empfehlen, beim Start eine konkrete Modell-ID festzulegen. So vermeiden Sie, dass ein Alias mitten im Projekt auf ein anderes Modell wechselt und sich das Verhalten plötzlich ändert:

claude --model claude-opus-5-5 --effort high

Opus 5.5 nutzt standardmäßig medium effort. Beim ersten Build muss der Agent Projektionsmathematik, Keyframe-Engine und Export-Pipeline in einem Durchgang korrekt schreiben, deshalb lohnt sich die Einstellung high. Für kleinere Änderungen danach, etwa an Keyframe-Werten oder Farben, können Sie wieder auf medium zurückgehen und so Token sparen.

Wie gut andere Modelle denselben Build hinbekommen und wie stark sich die Kosten unterscheiden, dazu liefern die Referenzmaterialien keine Vergleichsdaten. Wenn Sie das Modell wechseln wollen, lassen Sie am besten jedes Modell mit derselben Eingabeaufforderung einmal durchlaufen und vergleichen die Ergebnisse dann Punkt für Punkt mit der Standbild-Validierung, die weiter unten beschrieben wird.

Aufbau der Eingabeaufforderung für ein 2.5D-Studio mit Claude Code

Eine konkret formulierte Eingabeaufforderung bringt mehr als fünf vage. In der Referenzquelle steht die Build-Spezifikation als ein einziger zusammenhängender Absatz. Hier ist die Version, die den Sinn beibehält:

Build a 2.5D motion studio as one file, studio.html, with no dependencies.
- Scene: 6 layers (sky, moon, hills, city skyline, a title card "Ship it.",
  foreground foliage), each at its own z depth, using CSS perspective and preserve-3d.
- Camera: keyframes for x, y, z (dolly) and yaw (orbit around the card).
- Per-layer tracks: opacity, scale, y. Easings: linear, easeInOutCubic,
  easeInOutSine, easeOutBack.
- A timeline bar with keyframe markers, a playhead, click to scrub, space to play or pause.
- renderAt(t) must be pure in t. Expose window.__seek(t) that resolves after
  the frame paints, and a ?capture mode that hides the UI.
Then write export.mjs: Playwright opens ?capture, seeks every frame at 30 fps,
screenshots it and pipes PNGs to ffmpeg as H.264.

Die Eingabeaufforderung lässt sich in vier Ebenen aufteilen: Szene, Kamera, Spuren mit Easings und interaktive UI. Dazu kommt als Abschluss der Export-Vertrag. Entscheidend sind die letzten beiden Zeilen. Sie verlangen, dass renderAt(t) eine reine Funktion von t ist. Außerdem soll ein __seek bereitgestellt werden, das erst zurückkehrt, wenn das Bild fertig gezeichnet ist, und es soll einen ?capture-Modus geben, der die UI ausblendet. Damit wird die Exportfähigkeit zu einer Architekturvorgabe, an der sich der Agent beim Schreiben des Codes orientiert.

Wenn Sie das auf Ihr eigenes Projekt übertragen wollen, können Sie diese Struktur als Vorlage nutzen: Beschreiben Sie zuerst genau, „was gezeichnet wird“. Legen Sie dann am Ende in zwei oder drei Zeilen fest, „wie Frames deterministisch abgegriffen werden“.

Analyse des von Claude Code generierten 2.5D-Kerncodes

Das gesamte Studio umfasst etwa 150 Zeilen, entscheidend sind die folgenden drei Abschnitte.

Keyframe-Sampling und Easing

Jede Spur ist ein nach Zeit sortiertes Array von Keyframes. sample() sucht zunächst die beiden Keyframes vor und nach t, berechnet mit der Easing-Funktion des vorherigen Keyframes den Fortschritt und interpoliert dann alle numerischen Felder:

function sample(keys, t) {
  if (t <= keys[0].t) return keys[0];
  for (let i = 0; i < keys.length - 1; i++) {
    const a = keys[i], b = keys[i + 1];
    if (t <= b.t) {
      const p = (easings[a.ease] || easings.linear)((t - a.t) / (b.t - a.t));
      const out = {};
      for (const k in b)
        if (typeof b[k] === 'number' && k !== 't') out[k] = a[k] + (b[k] - a[k]) * p;
      return out;
    }
  }
  return keys[keys.length - 1];
}

Diese Funktion liest weder die aktuelle Zeit noch hängt sie vom Zustand des vorherigen Frames ab, und Zufallszahlen verwendet sie auch nicht. Für dasselbe t erhält man immer dieselben Werte – daher stammt die Determiniertheit von renderAt(t).

Tiefenkompensation: Die zentrale Formel für 2.5D-Parallaxe

Die Idee dahinter: Die Kamera bleibt stehen, dafür bewegt sich die gesamte Welt in die Gegenrichtung. Jede Ebene wird nicht nur auf der z-Achse verschoben, sondern zusätzlich mit einem Kompensationsfaktor skaliert:

const PERSPECTIVE = 1200; // Muss mit der perspective von #viewport übereinstimmen
world.style.transform =
  `translate3d(${-cam.x}px, ${-cam.y}px, ${cam.z}px) rotateY(${-cam.yaw}deg)`;
const comp = 1 - L.z / PERSPECTIVE;
el.style.transform = `translate(-50%,-50%) ` +
  `translate3d(${x * comp}px, ${y * comp}px, ${L.z}px) scale(${comp * s})`;

So kommt man auf die Formel: Bei einer CSS-Perspektivdistanz p wird ein Punkt in der Tiefe z (ein negatives z bedeutet: weg vom Betrachter) auf dem Bildschirm um den Faktor p / (p - z) skaliert. Mit p = 1200 und z = -900 ergibt sich 1200 / 2100 ≈ 0.571. Die Ebene erscheint also nur noch mit etwa 57 % ihrer Originalgröße.

Um diese Verkleinerung auszugleichen, multipliziert man mit dem Kehrwert (p - z) / p = 1 - z/p = 1 + 900/1200 = 1.75. Genau das ist der Wert comp im Code. Weil 0.571 × 1.75 = 1 gilt, erscheint jede Ebene bei ruhender Kamera in der Größe und an der Position, die Sie festgelegt haben.

Wie entsteht nun die Parallaxe? Wenn sich die Kamera bewegt, wird die gesamte world um dasselbe dx verschoben, aber die Verschiebung jeder Ebene auf dem Bildschirm wird weiterhin mit ihrem eigenen p/(p - z) multipliziert. Ferne Ebenen haben einen kleinen Faktor und wandern deshalb wenig, nahe Ebenen haben einen großen Faktor und wandern entsprechend mehr. Die Kompensation korrigiert nur die Komposition im Ruhezustand und lässt die Geschwindigkeitsunterschiede während der Bewegung unberührt. Darauf beruht der gesamte 2.5D-Effekt.

(Die Werte in der Tabelle sind mit p = 1200 berechnet; die Zeilen für -300 und -1800 sind als Beispielableitungen gedacht.)

Ein Bug, den man sich merken sollte: Nur die Größe kompensiert, den Versatz nicht

In der ersten Version des Codes wurde die Ebene nur mit scale(comp) multipliziert, der x/y-Versatz dagegen nicht mit comp. Dadurch wurde der Versatz der fernen Hügel von der Perspektive gestaucht, die gesamte Komposition verschob sich, die Hügel stiegen immer weiter an und verdeckten etwa zwei Drittel des Himmels. Die Lösung ist simpel: x und y ebenfalls mit comp multiplizieren, denn die Perspektive skaliert Position und Größe mit demselben Faktor.

Interessanter ist allerdings, wie der Bug entdeckt wurde. Der Autor bemerkte das Problem an einem einzigen gerenderten Frame, beim Lesen des Codes war es ihm nicht aufgefallen. Bevor Sie also irgendeiner Kamerabewegung trauen, sollten Sie den Agenten drei Standbilder rendern lassen: Start, Mitte und Ende.

Deterministischer Frame-für-Frame-Export von 2.5D-Parallax-Animationen als MP4

Der grundlegende Unterschied zwischen Echtzeit-Wiedergabe und Frame-Export

Die Echtzeit-Vorschau läuft über requestAnimationFrame. Ist der Rechner ausgelastet, gehen Frames verloren – in der Vorschau ist das akzeptabel. Beim Export dürfen aber keine Frames fehlen. Bei einer Bildschirmaufnahme erhalten Sie nur das, was zufällig gerade in Echtzeit auf dem Bildschirm zu sehen war. Hinkt der Rechner um einen Frame hinterher, entstehen doppelte oder fehlende Frames.

Minimales Export-Skript

Die Zeit des Exporters wird über die Bildnummer gesteuert. Pro Frame wird zuerst per Seek an die richtige Stelle gesprungen, dann wartet das Skript, bis das Bild fertig gezeichnet ist, macht einen Screenshot und schreibt das PNG in die Standardeingabe von ffmpeg:

import { chromium } from 'playwright';
import { spawn } from 'node:child_process';
import { pathToFileURL } from 'node:url';

const out = process.argv[2] || 'out.mp4';
const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1280, height: 720 } });
await page.goto(pathToFileURL('studio.html').href + '?capture');

const { duration, fps } = await page.evaluate(() => window.__scene);
const ffmpeg = spawn('ffmpeg', ['-y', '-f', 'image2pipe', '-framerate', String(fps),
  '-i', '-', '-c:v', 'libx264', '-pix_fmt', 'yuv420p', '-crf', '18', out],
  { stdio: ['pipe', 'ignore', 'inherit'] });

const frames = Math.round(duration * fps);
for (let i = 0; i < frames; i++) {
  await page.evaluate(t => window.__seek(t), i / fps);
  ffmpeg.stdin.write(await page.screenshot({ type: 'png' }));
}
ffmpeg.stdin.end();
await new Promise(r => ffmpeg.on('close', r));
await browser.close();

Ein paar Details sind wichtig: window.__seek(t) wird erst nach zwei Animationsframes aufgelöst, damit der Screenshot garantiert das neue Transform zeigt. image2pipe sorgt dafür, dass ffmpeg die PNG-Sequenz von stdin liest. yuv420p stellt sicher, dass sich die erzeugte Datei im Browser problemlos abspielen lässt. Falls Playwright noch keinen Browser installiert hat, führen Sie einmal npx playwright install chromium aus.

// In studio.html: deterministisches Seek, kehrt erst nach zwei gezeichneten Frames zurück
window.__seek = (t) => new Promise(resolve => {
  renderAt(t);                       // Reine Funktion: hängt nur von t ab
  requestAnimationFrame(() =>
    requestAnimationFrame(resolve)); // Sicherstellen, dass Styles übernommen und gezeichnet wurden
});

// stills.mjs: Rendert drei Standbilder (Anfang / Mitte / Ende) – erst das Bild ansehen, dann der Kamerafahrt vertrauen
import { chromium } from 'playwright';
import { pathToFileURL } from 'node:url';

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1280, height: 720 } });
await page.goto(pathToFileURL('studio.html').href + '?capture');
const { duration } = await page.evaluate(() => window.__scene);

for (const [name, t] of [['start', 0], ['mid', duration / 2], ['end', duration - 1e-3]]) {
  await page.evaluate(t => window.__seek(t), t);
  await page.screenshot({ path: `still-${name}.png` });
}
await browser.close();

Messergebnisse des Autors: 180 Frames, 1280×720, 30 fps, 6,0 Sekunden Länge, die MP4-Ausgabe ist etwa 420 KB groß, die Gesamtdauer beträgt rund 20 Sekunden. Die Stadttürme im Bild verschieben sich weniger als der dunkle Hügel im Vordergrund, der am Ende komplett aus dem Bild wandert – genau das ist der Parallaxeneffekt.

Eine Funktion „Kameraeinstellung beschreiben“ für das 2.5D-Studio

Als Nächstes kann der Autor eine einzelne Beschreibung einer Kameraeinstellung eingeben, und das Modell liefert die Keyframes als JSON zurück. In den Referenzmaterialien wird dafür direkt die Anthropic Messages API aufgerufen:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2026-10-21" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 4096,
    "output_config": { "effort": "low" },
    "system": "Return only JSON: {\"camera\": [{\"t\",\"x\",\"y\",\"z\",\"yaw\",\"ease\"}], \"tracks\": {}}. Times in seconds, 0 to 6.",
    "messages": [{ "role": "user", "content": "Slow push-in, slight orbit right, title fades up in the first second." }]
  }'

Dabei gibt es zwei typische Stolperfallen. Erstens: effort gehört in output_config.effort. Zweitens: Opus 5.5 verwendet immer adaptives Denken. Wenn Sie thinking: {"type": "disabled"} übergeben, kommt ein 400-Fehler zurück. Außerdem zählen auch die Denk-Token zu max_tokens. Ist max_tokens zu niedrig gesetzt, wird das JSON mitten im Array abgeschnitten, und stop_reason lautet "max_tokens".

Abgeschnittene Antworten oder solche mit überflüssigem Text drumherum lassen sample() beim Rendern fehlschlagen. Deshalb sollten Sie für diesen Aufruf einen Contract-Test einrichten. In den Referenzmaterialien lässt man die Apidog CLI in derselben Claude-Code-Sitzung einen Test erstellen und ausführen. Er prüft den Statuscode 200, dass stop_reason nicht "max_tokens" ist, dass sich der zurückgegebene Text als JSON parsen lässt und dass t im camera-Array von 0 bis 6 aufsteigt. Mit anderen API-Testwerkzeugen oder einem selbst geschriebenen Assertion-Skript erreichen Sie dasselbe. Nach jeder Änderung am System-Prompt oder an effort sollten Sie den Test erneut laufen lassen, denn beides verändert die Antwort.

Häufig gestellte Fragen (FAQ)

Claude Code 2.5D Parallax-Animation: die wichtigsten Punkte

• Der Export gehört zum Design: Legen Sie in den letzten Zeilen der Eingabeaufforderung die reine Funktion renderAt(t) und den Seek-Vertrag fest.
• Formel für den Tiefenausgleich: comp = 1 − z/perspective, und zwar sowohl auf die Größe als auch auf die x/y-Verschiebung angewendet.
• Woher die Parallaxe kommt: Der Ausgleich korrigiert nur die statische Komposition. In Bewegung erscheinen die Ebenen je nach Tiefe weiterhin mit unterschiedlicher Geschwindigkeit.
• Erst die Standbilder prüfen, dann der Kamerafahrt trauen: Drei Bilder (Anfang, Mitte, Ende) zeigen Bugs, die man beim Lesen des Codes nicht sieht.
• Zeit über die Bildnummer steuern: Playwright macht Seek und Screenshot, ffmpeg kodiert per image2pipe zu H.264.
• Effort stufenweise anpassen: high für den ersten Aufbau, medium für die Feinabstimmung, bei strukturierten JSON-Schnittstellen mit low beginnen.
• Modellausgaben mit Vertragstests absichern: So verhindern Sie, dass ein Abschneiden durch max_tokens dazu führt, dass Keyframes nicht mehr geparst werden können.

Fazit

Wer mit Claude Code ein 2.5D-Parallax-Animationsstudio aufbaut, sollte sich drei Dinge merken:

1. Architektur: Szenengraph, Zeitachse und deterministischer Renderer bilden das Trio. Der dritte Baustein entscheidet über die Qualität des fertigen Videos.
2. Mathematik: Der Perspektivausgleichsfaktor 1 - z/p wirkt gleichzeitig auf Größe und Verschiebung. Im Stillstand stimmt die Komposition, in Bewegung entsteht die Parallaxe von selbst.
3. Pipeline: Bild für Bild per i/fps suchen (Seek), einen Screenshot machen und an ffmpeg zum Kodieren übergeben. So hängt das Ergebnis nicht von der Leistung des Rechners ab.

Spielen Sie am besten zuerst einmal einen 6-Sekunden-Testclip mit der Struktur der Eingabeaufforderung aus diesem Artikel durch und machen Sie es sich zur Gewohnheit, nach jeder Änderung an der Kamera zuerst die drei Standbilder anzuschauen. Danach können Sie weitere Ebenen hinzufügen, eine „Kamera beschreiben“-Schnittstelle anbinden oder denselben deterministischen Ansatz auf andere programmatische Videolösungen wie Remotion übertragen.

📚 Referenzen

1. How to Build a 2.5D Motion Studio With Opus 5.5: Praxisquelle dieses Artikels
2. Link: apidog.com/blog/build-2-5d-motion-studio-opus-5-5

3. Hinweis: Enthält die vollständige Eingabeaufforderung, den Studio-Code, das Export-Skript und ein Beispiel für die „Kamera beschreiben“-Schnittstelle

4. Anthropic-Dokumentation zu Modellen und effort: Modellpositionierung, Kontext, Preise und Erläuterung des effort-Parameters

5. Link: docs.anthropic.com

6. Hinweis: Zum Prüfen der Modell-ID von claude-opus-5-5, des API-Versions-Headers und der Verwendung von output_config

7. ffmpeg-Formatdokumentation: Beschreibung von Eingabeformaten wie image2pipe

8. Link: ffmpeg.org/ffmpeg-formats.html

9. Hinweis: Zum Verständnis, wie eine PNG-Sequenz über stdin gelesen wird, sowie der H.264-Kodierungsparameter

10. Playwright-Dokumentation: Browser-Automatisierung und Screenshot-API

11. Link: playwright.dev
12. Hinweis: page.evaluate, page.screenshot und die Befehle zur Browser-Installation

Weiterführende Artikel

• Claude erstellt Videos nicht mit einem Videomodell: eine Zeitfunktion + Rendering Bild für Bild in 4 Schritten – das Prinzip in einem Zug erklärt: Die vollständige Funktionsweise von Claudes Videoproduktion aufgeschlüsselt: Jeder Frame ist eine reine Funktion der Zeit seek(t), gerendert in vier Schritten mit Headless-Browser und ffmpeg; geschlossene Federn und Beat-Synchronisierung sorgen für flüssige Animationen, gefolgt von einer direkt umsetzbaren 5-Schritte-Anleitung zum Einstieg.