Motion Diorama

Motion Diorama — Skill für die Produktion von Erklärvideos (v3.0 · öffentliche Ausgabe)

Grundprinzip: Prüfen vor dem Rendern, nicht danach. Alles, was sich günstig prüfen lässt (Timeline, Standbilder, Textbreite) MUSS vorher bestehen. Ein Full-Resolution-Rendering erfolgt nur einmal, ganz am Ende, nachdem alle Gates grün sind.

Diese Datei ist der KERN. Visuelle Details pro Modus finden sich in references/ — mode-a.md für Modus A, mode-b.md für Modus B, mode-c.md für Modus C (MÜSSEN dem Modus des aktuellen Videos entsprechend gelesen werden, BEVOR die Szene aufgebaut wird). Das Testszenario befindet sich in evals/evals.md. Skripte in scripts/ werden GENAU SO ausgeführt — die Funktionen dürfen nicht umgeschrieben werden.

Festgelegte Entscheidungen (vom Skill-Ersteller — nicht stillschweigend ändern; wenn du diesen Skill nutzt und änderst, tue es bewusst)

• Drei aktive Modi: Modus A (Landschaft/Geschichte + Karten-Variante), Modus B (Explosionsansicht — Funktionsweise von Objekten/Maschinen) und Modus C (Anatomie — Serie „Der menschliche Körper“). Der Benutzer wählt den Modus pro Video zu Beginn per Prompt; die Sitzung liest die Referenzdatei für diesen Modus vor Phase 2.
• Ziel: Aufbau einer Zuschauergemeinschaft. Standardausgang = Zusammenfassung (Modus A) / Callback (Modus C) + Abblenden auf Schwarz. Es gibt NIEMALS Serienkarten/-label im Video und NIEMALS Phasen-Pills/Positionsmarker auf dem Bildschirm (Entscheidung des Benutzers vom 13. Nov. 2026, v2.8) — die Serienidentität lebt nur in den Untertiteln. Call-to-Value NUR gelegentlich, wenn das Thema passt und der Benutzer es für dieses Video anfordert — kein Pflichtelement. Verkaufs-CTAs sind verboten.
• Zahlen/Daten = HYBRID: Bildschirm-Readout (DOM-Overlay) ist das primäre System für ALLE Zahlen. Ausnahme: maximal EINE goldene 3D-Held-Zahl pro Video, und zwar nur für die Spitzenzahl dieses Videos - und dieselbe Zahl MUSS weiterhin als Readout/Untertitel erscheinen, da die 3D-Version eine visuelle Betonung und nicht der Informationsträger ist.
• Endgültige Dauer 30–60 Sekunden, im Takt des Audios.
• Audio: Dieser Skill ist AUDIO-AGNOSTISCH — verwende jede vom Benutzer bereitgestellte MP3-Sprache in public/narasi.mp3.
• Musik: Datei vom Benutzer in public/musik.* — wähle keine Musik aus.
• Fakten: Der Benutzer ist die PRIMÄRE Quelle und hat bei Widersprüchen Vorrang. Die Sitzung DARF durch Internet-Recherchen ergänzt werden, unter der Bedingung: Quellen müssen im Abschlussbericht genannt werden, bevorzuge autoritative Quellen (Zeitschriften, Institutionen, offizielle Stellen), und nicht verifizierte Behauptungen MÜSSEN als unsicher gekennzeichnet werden — es ist verboten, Vermutungen als Tatsachen darzustellen.
• Einzeloperator: eine Person. Alle Ergebnisse MÜSSEN als Dateien in der Sitzung vorliegen (Standbilder, Vorschau, Final), damit sie heruntergeladen werden können.
• Ziel-Rhythmus: 1–2 Videos/Tag. Effizienz ist ein Designkriterium - verwende Gerüste, Primitiven und Komponenten wieder; baue nichts neu, was bereits existiert.
• Gates — Live-Modus ist Standard der öffentlichen Ausgabe: Die Sitzung WARTET NICHT auf die Zustimmung des Benutzers. Gate 1 (Timeline-Zusammenfassung) und Gate 2 (Kontaktabzug Standbilder) werden INTERN ausgeführt: Die Sitzung bewertet ihre eigenen Phasenergebnisse anhand der schriftlichen Kriterien dieses Skills (Validator PASS + QC-Checkliste), behebt Mängel selbstständig (max. 2 Korrekturversuche pro Szene) und fährt dann fort. Die Entscheidungen folgen dem ENTSCHEIDUNGSBLOCK im Prompt (Standard: zu lange Sprache wird auf max. 1,25× beschleunigt; nicht verifizierte Fakten werden im Bericht gekennzeichnet). Nicht beantwortete Fragen dieses Blocks werden IN EINER NACHRICHT vor Baubeginn gestellt - es ist verboten, zwischendurch nachzufragen. Die Sitzung darf NUR bei HARTEN HINDERNISSEN anhalten: (a) Material fehlt oder ist beschädigt, (b) Transkript unmöglich zu erstellen, (c) Sprache bleibt nach max. Atempo außerhalb von 30–60 s. Wenn der Prompt „Live-Modus: NEIN“ angibt, gelten klassische Gates — zwei Benutzerzustimmungen (nach Phase 1 und nach Phase 3) mit einer Beweis-basierten Lockerungsleiter für Gate 2: 3 saubere Durchgänge in Folge → 1 Standbild pro Szene; 3 weitere → optional für bewährte Szenentypen; Gate 1 wird nie gelockert; eine große visuelle Überarbeitung setzt das volle Format zurück; jede Lockerung wird im Abschlussbericht festgehalten.

Strenge Verbote

• Verboten sind KI-Bilder/Fotos/2D/Sprites/externe Texturen/heruntergeladene Modelle als Szene. Alle Visuals = prozedurale 3D-Geometrie aus Three.js.
• Verboten ist Letterbox; native Kamera 9:16.
• Bewegung nur durch die Kamera im 3D-Raum (echte Parallaxe). Verboten, Bewegung durch Zoom/Pan von 2D-Bildern zu simulieren.
• Menschen nur als kleine, dunkle Silhouetten ohne Gesicht. Hauptsubjekte in Modus A nicht im Close-up (Mindestkameraabstand 8 m für Tiere/Heldenobjekte der Landschaft) — in Modus C gilt diese Abstandsregel nicht: Heldenorgane füllen den Bildausschnitt; in Modus B bindet diese Regel nur die Rahmung der Kontextphase — Heldenobjekte in der Laborphase füllen den Bildausschnitt (siehe references/mode-b.md und references/mode-c.md).
• Ein Renderer, ein Materialsatz, ein Licht-Rig für alle Szenen.
• Verboten, die Dauer aus der Wortanzahl/einem Storyboard zu schätzen. Timing NUR aus dem Original-Audio (siehe Zeitplanung).
• Verboten sind Animationen mit useFrame(), Math.random(), Date.now() oder Frame-Akkumulation — alle Bewegungen werden von useCurrentFrame() und fest gesetzten Zufallskonstanten abgeleitet.

Zeitplanung — timeline.json ist die einzige Wahrheitsquelle

1. Stelle sicher, dass public/narasi.mp3 existiert. Wenn nicht: STOPP, informiere den Benutzer. Lege keine Zeitplanung fest, bevor das Audio verfügbar ist.
2. Erstelle Zeitstempel pro Wort mit dieser Hierarchie: a. TTS-interne Zeitstempel (z.B. ElevenLabs with-timestamps) falls vom Benutzer bereitgestellt - am genauesten. b. Fallback Whisper: NUR das GROSSE Modell, language="id" erzwingen (keine Auto-Erkennung), und Whisper liefert NUR die ZEIT — der Textsatz MUSS aus dem offiziellen Manuskript des Benutzers stammen, nicht aus dem Transkript (ASR für Indonesisch macht leicht Fehler bei Zahlen und Namen).
3. Erstelle docs/timeline.json exakt nach diesem Schema:

{
  "fps": 30,
  "audio_duration_s": 40.20,
  "total_duration_s": 41.00,
  "sentences": [
    {"id": 1, "text": "…", "start_s": 0.00, "end_s": 3.68, "scene": 1}
  ],
  "scenes": [
    {"id": 1, "sentence_ids": [1, 2], "start_s": 0.00, "end_s": 6.44}
  ]
}

4. Zuordnungsregel: Szenengrenze = Startsekunde des ersten Satzes der nächsten Szene; Zuordnung basiert auf dem INHALT der Sätze — es ist verboten, Sätze zum Füllen der Dauer zu gruppieren; Abweichung des tatsächlichen Schnitts zur Timeline ≤ 0,3 s.
5. Führe python3 scripts/validate_timeline.py docs/timeline.json aus. Bei FEHLER: Timeline korrigieren, wiederholen. Weiterverfahren bei FEHLER verboten.
6. Erstelle eine Timeline-Zusammenfassung (Satzanzahl, Szenenzuordnung, Gesamtdauer) und bewerte sie selbst anhand dieser Kriterien — das ist Gate 1. Live-Modus: nicht anhalten; Zusammenfassung für den Abschlussbericht speichern. Klassischer Gate-Modus: dem Benutzer anzeigen und auf Zustimmung WARTEN.
7. total_duration_s muss 30–60 s betragen. Außerhalb: Live-Modus — Prompt-Richtlinie anwenden (Atempo max. 1,25× bei Überlänge; Pausenende dehnen bei Unterlänge) und im Bericht vermerken; bleibt es außerhalb des Bereichs, liegt ein HARTES HINDERNIS vor: Anhalten und melden. Klassischer Modus: dem Benutzer melden - nicht stillschweigend schneiden oder flicken. Unbegründete Stille ist verboten; ein Payoff-Pause von 0,3–1 s am Ende ist erlaubt und wird in der Gesamtdauer berechnet.

Style Lock (kurzgefasst — Details pro Modus in references/)

Modus A (Details in references/mode-a.md)

• Stilisierte, halb-realistische 3D-Dioramen: warme, cineastische Palette, ein festes Dämmerlicht-Rig, saubere, glatte Oberflächen, vereinfachter Hintergrund. Die Palette darf sich dem Thema/Jahreszeit anpassen; das Licht-Rig und die Materialien nicht.
• Titel des Themas: Serifen-Typografie in Großbuchstaben über einer sich bewegenden Establishing Shot. Hook = erster Satz der Erzählung (Frage/Widerlegung eines Mythos/ Paradoxon), der als Text + Ton + Visual in ca. 1,5 Sekunden erscheint.
• Untertitel: Karaoke pro Wort in Gruppen von 2–4 Wörtern (nicht einzelne Wörter), aktives Wort fett, Schlüsselwörter in Akzentfarbe, im unteren Sicherheitsbereich.
• Daten-Readout: animierter Zähler, der genau dann zählt, wenn die Zahl im Audio genannt wird + kleines Label + Führungslinie; nachfolgende Readouts im gleichen Stil. Der einzige 3D-Text, der erscheinen darf: eine goldene Heldenzahl für die Spitzenzahl (siehe Festgelegte Entscheidungen).
• Kamera: kontinuierliche Reise innerhalb der Segmente; Zoom-Leiter als Argumentstruktur; harte Schnitte nur zwischen Faktensegmenten, als Abblenden auf Schwarz von ca. 0,1 Sekunden.
• Erzählstruktur: bei System-/Ablaufthemen „einem Fluss folgen“; ein Video kann zwei Fakten zu einem Thema mit einem Demonstrationssegment enthalten.
• Abschluss: Beauty Shot + wiederholter Serifen-Titel/Ära + Schlusssatz. Abblenden auf Schwarz; ohne Serienkarten/-label im Video (v2.8). (Call-to-Value nur, wenn für dieses Video angefordert.)

Modus B — Explosionsansicht (Details in references/mode-b.md)

• ZWEI Weltphasen: warmes, Modus-A-artiges KONTEXT-Diorama (Objekt erscheint vollständig in seinem Habitat) → LAB-Phase mit dunklem, technischem Gitterhintergrund, in der das Objekt zerlegt wird; Übergang durch kontinuierlichen Zoom (Hintergrund verblasst/Iris), ohne harten Schnitt.
• Ein prozedurales Heldenobjekt-Modell, einmal erstellt; Explosionsansicht und Schnitte werden vom gleichen Modell abgeleitet.
• OHNE Titel-Slide (Hook = erster Satz der Erzählung im Kontext-Shot) und OHNE dauerhafte HUD-Elemente — Breadcrumbs, Zoom-Zähler und Referenz-Minimap sind ENTFERNT (Forschungsergebnis + Richtung v2.8). Navigation durch kontinuierliche Kamera, Leaderline-Labels und kurzfristige Phasentitel.
• Standardphasen: Kontext → Zoom + Objekt-Label → ZERLEGT (zweisprachige Teile-Labels: ID + EN-Begriff, erscheinen in Erzählreihenfolge) → AUFGESCHNITTEN (Prozess animiert + Prozess-Readout) → IM BETRIEB (Schnitt läuft, einem Fluss folgen, Prozess-Labels, semantisch farbcodierte Flusspartikel) → Makro des bestimmenden Mechanismus → Payoff mit einem einzeiligen Prinzip-Label, während die Kamera zurückzieht.
• Abschluss Modus B: Schlusssatz/Prinzip + Abblenden auf Schwarz; ohne Serienkarten/-label (v2.8).

Modus C — Anatomie (Details in references/mode-c.md)

• KEIN Diorama: ein glänzendes 3D-Heldenorgan schwebt in einer dunkelvioletten, mit Bokeh versehenen Leere; ein Organmodell wird einmal erstellt und für alle Szenen verwendet. Standard-Serienname z.B.: „Der menschliche Körper“ (durch deinen Seriennamen ersetzen).
• ABSOLUTE Fluss-Farbcodierung: blau = sauerstoffarm, hellrot = sauerstoffreich — niemals umgekehrt, weder in diesem noch in anderen Videos der Serie. Zellpartikel ändern ihre Farbe am Austauschpunkt, genau im passenden Satz.
• ZWINGEND einem Fluss folgende Struktur: Kamera begleitet ein Paket durch den gesamten Kreislauf; Zoom-Leiter: Organ → System → mikroskopisch → Organ → ganzer Körper (Silhouette).
• Hook = Echtzeit-Referenz für den Zuschauer + Live-Zähler, der synchron zum visuellen Organschlag ab der ersten Sekunde läuft. Serifen-Titel wird VERZÖGERT bis ca. 5–8 s (nach dem Hook), gefolgt von Faktenannotation.
• OHNE Phasen-Pills und OHNE HUD (v2.8): die Flussposition wird aus dem Kamerapfad abgelesen; Anatomie-Label-Chips haften am Organ und leuchten auf, wenn ihr Teil aktiv ist.
• Abschluss Modus C: animierter Finalzähler + CALLBACK-Satz, der den Hook aufgreift; Abblenden auf Schwarz; ohne Serienkarten/-label (v2.8). Gore/medizinischer Realismus grafischer Art verboten.

Textregeln (Anti-Clipping — häufigste Ursache für Überarbeitungen)

• ALLER lesenswerte Text ist DOM-Overlay (Remotion-Komponenten), NICHT Text innerhalb der WebGL-Leinwand. Einzige Ausnahme: die hybride 3D-Heldenzahl aus den festgelegten Entscheidungen — anderer 3D-Text verboten.
• Messe JEDEN Text mit measureText/fitText aus @remotion/layout-utils NACH DEM Laden der Schriftart; fontSize = min(Modus-Grenze, Ergebnis von fit); maximale Breite 90% der Bildbreite; Sicherheitsabstand 5% auf allen Seiten; respektiere die Sicherheitszonen der Plattform (vermeide ±250 px oben und ±310 px unten für wichtigen Text).
• Wenn der Text bei der Mindestlesbarkeitsgröße nicht passt: AUFTEILEN in zwei Seiten/Zeilen — es ist verboten, ihn unleserlich zu verkleinern; es ist verboten, ihn abgeschnitten zu lassen.
• Kontrast: Helle Schrift auf hellem Hintergrund MUSS einen dunklen Umriss/Schatten haben.
• Leaderline-Labels folgen denselben Regeln.

Audio

• Die Erzählung ist die Master-Clock: alle Szenengrenzen, Untertitel, Zähler und Kamerabewegungen lesen aus docs/timeline.json — es gibt keine zweite Zeitquellen.
• Vom Benutzer bereitgestellte Musik wird als Hintergrundbett unter der Erzählung eingefügt (einfaches Ducking; Wörter nicht überdecken). Keine Musikdatei vom Benutzer: keine Musik erfinden — Benutzer informieren.
• Final wird auf −14 LUFS normalisiert, Spitzenwert ≤ −1 dB.

Produktionsablauf (Reihenfolge darf nicht übersprungen werden)

• Phase 0 — Gerüst: Verwende bereits vorhandenes Projektgerüst; Renderer, Kamera-Rig, Style Lock und Primitiven werden NICHT neu geschrieben. Wenn das Repository noch kein Remotion-Projekt enthält (erste Produktion): baue das Gerüst aus dem Ordner starter/ im Skill-Paket-Repository auf (Abhängigkeiten in exakt den Versionen, die nachweislich funktionieren), und behandle es dann als bestehendes Gerüst.
• Phase 1 — Zeitplanung: Gemäß Abschnitt Zeitplanung → Validator PASS → Gate 1 (intern im Live-Modus; Benutzerzustimmung im klassischen Modus).
• Phase 2 — Szenen bauen: Liest timeline.json und die Referenzdatei des aktuellen Videomodus (references/mode-a.md, references/mode-b.md oder references/mode-c.md).
• Phase 3 — Standbild-Gate: Rendere 3 Standbilder pro Szene (Anfang/Mitte/Ende der Szene) + Kontaktabzug. Live-Modus: bewerte den Kontaktabzug anhand der QC-Checkliste dieses Modus, korrigiere Mängel in der Standbild-Phase (max. 2 Versuche pro Szene), dann weiter — warte nicht auf den Benutzer; speichere Kontaktabzug + Bewertungsliste für den Abschlussbericht. Klassischer Modus: Zeige sie an und WARTE auf die Zustimmung des Benutzers. Korrigiere in der Standbild-Phase — das ist weitaus günstiger als im Video.
• Phase 4 — Vorschau + eigenständige Qualitätssicherung: Rendere eine Vorschau im Maßstab 0,5, führe die Qualitätssicherung unten an den eigenen Ergebnissen durch, korrigiere alle Mängel (rendere nur die geänderten Szenen neu), bevor du Bericht erstattest.
• Phase 5 — Final: Rendere Full-Resolution EINMAL; führe bash scripts/check_output.sh out/<slug>-final.mp4 aus; zeige die Datei + den Qualitätssicherungsbericht in der Sitzung an.

Schnelles Rendern (festgelegte Pipeline)

• Rendere PRO SZENE: out/scenes/scene-N.mp4; füge sie mit FFmpeg Concat -c copy zusammen (Codec/Auflösung/fps MÜSSEN zwischen den Szenen identisch sein, sonst ist der Zusammenschnitt beschädigt).
• --concurrency = Anzahl der CPU-Kerne der Sitzung (mit nproc prüfen), nicht den Standardwert.
• Vorschau immer mit --scale=0.5; Full-Resolution 1080×1920 nur in Phase 5.
• Halte die Kosten pro Frame niedrig: primitive Geometrie, Instancing für Elemente [...]