Skill: One-Take-Weißmodell-Previs (Daham0/blender-previs-one-take)
Ein-Satz-Positionierung: Der Nutzer gibt ein Bild oder eine Beschreibung, dieses Skill erzeugt ein Weißmodell-Video; nach Fertigstellung des Weißmodells werden die Prompts geschrieben, und das Weißmodell-Video wird als Bewegungsreferenz zusammen mit den Prompts an das Videomodell übergeben. Lange Kamerafahrten basieren nicht auf esoterischen Prompts, sondern darauf, dass der Kamerapfad vorher berechnet und vom Nutzer visuell bestätigt wird.
0. Ausführungsmodus (nach außen immer nur diese drei Schritte)
- Der Nutzer gibt ein Referenzbild oder eine Beschreibung (z. B. „10 Sekunden, von hinten um mich herum zur Vorderseite, die Dinge auf dem Tisch schweben zuerst hoch“).
- Das Skill erzeugt ein 3D-Weißmodell-Previs-Video, beide iterieren gemeinsam, bis der Nutzer sagt: „Genau so fühlt es sich an“.
- Nach der Fertigstellung werden zwei Dinge übergeben: das Weißmodell-Previs-Video + die detaillierten Videoprompts, die zusammen an Seedance 2.5 oder ein anderes Videomodell übergeben werden.
Wie intern gerechnet wird (Szene, Koordinaten, Validierung) ist Sache des Skills; technische Details werden dem Nutzer nicht aufgedrängt. Die vollständigen Einstiegsregeln, Pflichtfragen und Übersetzungstabelle für einfache Sprache finden sich in references/00-flow-intake-iteration.md. Dies ist die Prozessübersicht des Skills; bei jeder Auslösung wird sie zuerst gelesen.
1. Sechs-Phasen-Hauptablauf (Reihenfolge nicht umkehrbar)
| Phase | Was der Nutzer tut | Was du liefern musst | Freigabebedingung |
|---|---|---|---|
| ① Anforderungsaufnahme | Referenzbild / eine Beschreibung geben | Drei Sätze, die „meine verstandene Szene“ wiedergeben: Subjekt, Kamerarichtung, ob Schweben/Schwerelosigkeit | Nutzer sagt „ja“ oder korrigiert einen Satz; Bestätigung von Bildformat und Dauer |
| ② Umgebungserkennung | Auswahl (installieren / nicht installieren) | check_blender.py-Ergebnis + ein Satz mit Routenbeschreibung | Route klar, Eintritt in A oder B |
| ③ Erstes Weißmodell-Video | Video ansehen | Abspielbares mp4/webm + 3–4 Keyframes + „Sag mir direkt, was nicht stimmt“ | Video tatsächlich erstellt und ausgeliefert. Nur eine Koordinatentabelle zu liefern = Vertragsbruch |
| ④ Dialog-Iteration | Feedback in Alltagssprache | Neue Version v2/v3… + 1 Zeile Änderungsbeschreibung | Nur eine Änderung pro Runde; Nutzer bestätigt explizit |
| ⑤ Fertigstellung + Prompt-Schreiben | Bestätigung des Gefühls | Vier Validierungen RESULT: PASS + Sechs-Spalten-Prompts | Bei nicht bestandener Validierung keine Prompts erlaubt |
| ⑥ Auslieferung | Material nehmen und ausgeben | Weißmodell-Video + Prompts + Upload-Beschreibung (Video1 = Bewegungsreferenz, Bild1 = visuelle Referenz) | Alle Prompt-Koordinaten aus JSON der Messung |
Die Phasen ③④ erlauben mehrere Iterationen – das ist der Hauptwert dieses Skills: Kameraprobleme werden im 3D-Raum gelöst, nicht durch „Kartenziehen“ im Videomodell.
2. Sechs eiserne Regeln
- Reihenfolge eisern: Szene aufbauen → Weißmodell-Video → Nutzerbestätigung → dann Prompts schreiben. Ein Prompt ohne Nutzeransicht ist ein Ausschuss.
- Die visuelle Basis der Prompts ist ausschließlich das Referenzbild des Nutzers. Das Weißmodell ist keine visuelle Referenz; es dient nur zur Festlegung von Bewegung, Timing und Koordinaten; Bildqualität, Form, Licht und Farbe kommen ausschließlich aus dem Referenzbild.
- Kamerafahrt in eine Richtung, kontinuierlich. Der Polwinkel muss monoton steigen oder fallen; Hin- und Herbewegungen sind verboten; ein Zickzack bedeutet Fehlschlag und erfordert eine Neujustierung der Kurve.
- Das Subjekt verlässt nie das Bild. Frame-für-Frame-Projektionsprüfung: Der NDC des Subjekts muss im Sicherheitsrahmen bleiben; wenn das Subjekt aufsteigt, muss die Kamera synchron nach oben schwenken.
- Null Kollisionen (Zero Clipping). Wenn der Abstand zweier bewegter Objekte in einem Frame unter dem Schwellwert liegt, gilt dies als Fehlschlag; gelöst durch die Reihenfolge „erst Platz machen, dann aufsteigen“, „erst leichte, dann schwere Objekte fliegen lassen“, nicht durch Dichteanhäufung.
- Der Nutzer spricht nur Alltagssprache. Sagt der Nutzer „höher“ oder „der Stuhl stößt ans Bein“, übersetzt du dies in Parameter und änderst nur diese eine Sache; du erklärst dem Nutzer keine Polwinkel, NDCs oder AABBs.
3. Umgebungserkennung & Routenauswahl (Tipp 1: Erkennung & Modellierung)
check_blender.py
├─ Installiert → Zweig A (Blender, höchste Präzision, exportiert Frame-für-Frame-Messdaten)
├─ Nicht installiert
│ ├─ Nutzer stimmt Installation zu → Portable Version führen (05-blender-setup.md) → Zweig A
│ ├─ Nutzer hat andere Version/Pfad → Pfad eingeben → Zweig A
│ └─ Nutzer lehnt Installation ab (oder keine Berechtigung, Zeitdruck) → Zweig B (Three.js-Web-Weißmodell)
└─ Zweig B durchläuft ebenfalls die vollständigen sechs Phasen, liefert nur „Bewegungsreferenz“, Validierung und Prompt-Schreibung sind identisch
Kommunikationsstil bei der Installationsführung – immer nur eine Entscheidung auf einmal, kein langer Text:
Auf diesem Computer ist kein Blender installiert. Zwei Wege:
- Ich installiere die portable Version (ca. 300 MB, wird auf Nicht-System-Laufwerk installiert, schreibt keine Registry, belegt kein C-Laufwerk, kann komplett gelöscht werden) – höchste Präzision, exportiert Frame-für-Frame-Koordinaten;
- Keine Installation, ich generiere das Weißmodell-Video mit Three.js im Browser – in wenigen Minuten sichtbar, etwas geringere Koordinatengenauigkeit. Welche Option?
Wählt der Nutzer 1 → references/05-blender-setup.md folgen; wählt er 2 → references/06-threejs-fallback.md folgen.
4. Phasendetails
① Anforderungsaufnahme
references/00-flow-intake-iteration.md §1–§3 lesen: Bestimmen, ob die Eingabe ein Bild, eine Beschreibung oder beides ist. Nur drei Pflichtfragen (Dauer/Bildformat, Subjektausrichtung, Kameraintention); falls möglich, ableiten; sonst mit Standardwerten aus knowledge/kb-levitation-office.md auffüllen. Sagt der Nutzer „ist mir egal“, die erste Version mit Standardwerten erstellen und ihn das Video bemängeln lassen.
③ Erstes Weißmodell-Video (Tipp 3: Zuerst das Weißmodell-Previs)
Zuerst das statische Weißmodell aufbauen und die Weltkoordinaten festlegen (1 Einheit = 1 Meter, Ursprung am Boden) → parametrische Kameraspur → 480P Low-Sample-Rendering → Ausgabe + Keyframes. In dieser Phase keine Prompts schreiben. Abnahme: abspielbar, keine schwarzen Frames, Subjekt im Bild, Wände/Boden/Dach statisch.
④ Dialog-Iteration
Gemäß der Übersetzungstabelle in 00 §4 die Worte des Nutzers in Parameter übersetzen, immer nur eine Änderung pro Runde, neue Version erstellen und 1 Zeile Änderungsbeschreibung schreiben (z. B. v2: Radius 3.45→2.95, Subjekt im Endframe voller). Versionierungsregeln siehe 00 §5.
⑤ Fertigstellung, Validierung & Prompt-Schreiben (Tipp 2: Automatische Prüfung + Tipp 4: Gegen das Weißmodell schreiben)
Vier Validierungen (Polwinkel-Monotonie / Subjektverlust aus Bild / gruppenübergreifende Kollision / Durchschlagen der Decke) müssen RESULT: PASS sein; dann das Frame-für-Frame-Mess-JSON exportieren und die Prompts nach sechs Spalten schreiben. Jeder Koordinate in den Prompts muss aus diesem JSON stammen; handschriftliche Schätzungen sind verboten. Schreibregeln siehe references/04-prompt-format.md.
⑥ Auslieferung (Anbindung an Seedance 2.5)
Gemäß den Übergaberegeln in 00 §6: Das Weißmodell-Video als Bewegungs-/Kamera-/Timing-Referenz kennzeichnen, das Referenzbild als einzige visuelle Referenz kennzeichnen; der erste Satz der Prompts betont „Kamerafahrt und Startreihenfolge des Referenzvideos exakt nachbilden“; Dauer mit Weißmodell abgleichen; Kamerafahrt in 2–3-Sekunden-Abschnitte unterteilen.
5. Zweig A: Blender-Ausführungshandbuch
- Szenen- und Koordinatenspezifikation:
references/01-scene-spec.md - Kamerafahrtspezifikation:
references/02-camera-motion.md - Gestaffelte Schwerelosigkeit & Anti-Kollisions-Timing:
references/03-levitation-timing.md - Installation & Verbindung:
references/05-blender-setup.md - Skripte:
scripts/build_scene_template.py— Baut weiße Szenenskelett (Raum, Tisch, Dual-Monitor, Stuhl, menschliche Blockfigur)scripts/render_previs.py— Low-Sample-480P-Previs-Rendering (EEVEE, ohne Material)scripts/export_cam_data.py— Exportiert Frame-für-Frame-Kamera/Blickpunkt/Höhenwinkel/Objekt-z in JSONscripts/validate_trajectory.py— Vier Validierungen (Monotonie / Verlust aus Bild / Kollision / Durchschlagen der Decke)
Befehlssequenz (lokal getestet; $BLENDER ist der absolute Pfad zu blender.exe; Pfade entsprechend ersetzen):
# 1 Erkennung
python scripts/check_blender.py --json
# 2 Szene aufbauen + Orbit-Trajektorie + gestaffelte Levitationsanimation (--orbit 1) + Koordinatenliste exportieren
"$BLENDER" -b --python scripts/build_scene_template.py -- \
--orbit 1 --center 0.0 0.15 --dur 10 --fps 24 \
--a0 186 --a1 300 --r0 3.45 --r1 2.45 --z0 0.78 --z1 1.20 --l0 1.05 --l1 1.45 \
--out "Z:/project/scene.blend" --csv "Z:/project/coords.csv"
# 3 Vier Validierungen (vor Fertigstellung zwingend erforderlich), muss RESULT: PASS sein
"$BLENDER" -b "Z:/project/scene.blend" --python scripts/validate_trajectory.py -- \
--center 0.0 0.15 --ceiling 2.75 \
--keys Person_Head,Person_Torso,Desk_Top,Monitor_H_Body \
--moving Minion_,Monitor,PC_Case,Keyboard,Mouse,Person_,Desk_,Chair_
# 4 Messdaten Frame für Frame exportieren (nur diese Daten für Prompt-Schreibung)
"$BLENDER" -b "Z:/project/scene.blend" --python scripts/export_cam_data.py -- \
--out "Z:/project/cam.json" --center 0.0 0.15 --keys Person_Head,Desk_Top,Chair_Seat
# 5 Previs-Rendering: zuerst 16-Frame-Test, dann gesamtes Video
"$BLENDER" -b "Z:/project/scene.blend" --python scripts/render_previs.py -- \
--out "Z:/project/previs.mp4" --res 960x540 --samples 4 --start 1 --end 240
Für Iterationen reicht es, Schritt 2 (Parameter ändern) → Schritt 5 (Video rendern) zu wiederholen; nach der Fertigstellung werden Schritte 3 und 4 ergänzt.
--keys enthält nur Hauptpunkte des Subjekts (Kopf, Rumpf, Tischplatte, Hauptmonitor); Anhängsel unter 1 m über dem Boden (Stuhlsitz etc.) führen bei Aufnahme zwangsläufig zu Verlust aus dem Bild – dies ist ein physikalisches Kameragebnis.
--moving enthält nur Präfixe von Objekten, die sich bewegen; ohne Angabe keine Kollisionserkennung; Objekte werden nach Namenspräfix gruppiert; Kontakt innerhalb derselben Gruppe wird nicht gezählt.
6. Zweig B: Three.js-Web-Weißmodell
- Schema & Einschränkungen:
references/06-threejs-fallback.md - Direkt ausführbar:
scripts/threejs_previs.html(Einzeldatei, CDN-Import von three, enthält Trajektorienwiedergabe, Perspektiv-/Draufsichtswechsel, JSON-Export, WebM-Aufnahme) - Einschränkungen: menschliche Figuren als Blocknäherungen, alle Materialien weiß; nur Bewegungsrichtung, Komposition, Timing überprüfbar; Licht und Textur nicht überprüfbar.
- Ausgabe: webm + Keyframe-Screenshots; Koordinaten werden von derselben Parametersammlung der Seite exportiert.
7. Prompt-Übergabespezifikation (Tipp 4)
Feste sechs Spalten, keine darf fehlen: 【Generation Unit】 【Referenz】 【Kontinuität】 【Erzählung und Sound】 【Zeitachse mit Koordinaten】 【Negative Prompts】`.
Drei harte Anforderungen:
- Gegen das Weißmodell schreiben, nicht raten: Jeder Satz zur Kamerafahrt muss auf einen Zeitcode des Weißmodells verweisen, z. B. „0–2,5s startet hinter dem Subjekt links, Kamerahöhe 0,78 m, Radius 3,45 m, Polwinkel 186°, Höhenwinkel 3,7°“.
- Referenzrollen klar trennen: Das Weißmodell-Video fixiert nur die Bewegung, das Referenzbild fixiert die visuelle Darstellung; beide Sätze müssen konkret sein.
- Anti-Kollision als kausale Reihenfolgesätze schreiben, nicht als „Achtung, nicht kollidieren“.
Schreibtechniken, Satzstrukturen, Negativbeispiele, häufige Fehlerursachen siehe references/04-prompt-format.md; projektspezifische Parameter siehe knowledge/kb-levitation-office.md (direkt als Vorlagenwerte wiederverwendbar).
8. Häufige Fehler und schnelle Lösungen
| Phänomen | Ursache | Behandlung |
|---|---|---|
| Kamera zuckt hin und her, pendelt | Polwinkelkurve nicht monoton / Interpolation federt zurück | Monotone Parametrisierung + Vorzeichenprüfung erster Differenz + LINEAR-Interpolation |
| Subjekt verlässt Bildmitte | Subjekt steigt auf, Kamera folgt nicht | Kamera-z und Blickpunkt-z synchron mit Follow-Faktor 0,8–0,95 keyframen |
| Tisch/Stuhl und Person kollidieren | Person und Stuhl starten gleichzeitig | Person zuerst fliegen lassen, Stuhl um 0,4–0,7s verzögern, zuerst horizontal ausweichen, dann aufsteigen |
| Gerät und Tisch kollidieren | Gerät und Tisch starten gleichzeitig | Gerät zuerst auf ca. 1,3 m Heben und schweben lassen, Tisch um 2–3s verzögern |
| Raum schwebt mit | Blickpunkt oder Elternbeziehung falsch geschrieben | Nur Subjektgruppe in z verschieben; Wände, Boden, Fenster statisch halten |
| Fertige Personen drehen sich (Gesicht verformt) | Ausrichtung nicht fixiert | In 【Referenz】 fest „Rücken-/Halbrückenansicht“ schreiben; Negative um Drehung, Umdrehung, Nahaufnahme des Gesichts ergänzen |
| Fertig wirkt wie 3D-Grau | Weißmodell als visuelle Referenz verwendet | In 【Referenz】 klar „Weißmodell nur Bewegungsreferenz“; Bildstil durch „Realistische Fotografie“ festlegen |
| Modell ignoriert Referenzvideo komplett | Erster Satz betont nicht die Nachbildung | Erster Satz schreiben: „Kamerafahrt und Startreihenfolge des Referenzvideos exakt nachbilden“; Fahrt in 2–3s Abschnitte unterteilen |
| Prompt-Koordinaten passen nicht zum Bild | Geschätzte Koordinaten verwendet | Zurück in Phase ⑤ und aus Mess-JSON nehmen; handschriftliches Eintragen verboten |
9. Checkliste für hochwertige Lieferung
- Nutzer hat Referenzbild oder Beschreibung gegeben und „meine verstandene Szene“ bestätigt
- Erstes Weißmodell-Video tatsächlich erstellt und ausgeliefert (nicht nur Koordinaten)
- Iterierte Versionen haben Nummern und Änderungsbeschreibungen; finale Version explizit vom Nutzer bestätigt
- Vier Validierungen
RESULT: PASS - Referenzbild in Prompts als @image1 spezifiziert, Weißmodell-Video als Bewegungsreferenz
- Zeitachse in Sekundenabschnitte unterteilt, jeder mit „Startkameraposition → Endkameraposition + Blickpunkt + Höhenwinkel + Radius“
- Gestaffelte Reihenfolge: wer zuerst fliegt, wer später, Aufstiegshöhe, finale Staffelungshöhe
- Anti-Kollisionslogik in Kausalsätzen
- Negative Prompts abdecken: Personenausrichtung & Gesichtsdetails, Geräteänderungen & Ausrichtung, Kollision & Herunterfallen, Raumschweben, Kamerazickzack, Stilwechsel, Untertitel/Wasserzeichen
- Bei Lieferung erklären: „Previs prüft nur Bewegung; visuelle Darstellung basiert auf Referenzbild“ und Upload-Beschreibung angeben
10. Skriptparameter-Schnellreferenz
| Skript | Schlüsselparameter | Beschreibung |
|---|---|---|
check_blender.py | --json | Nur lesen; Ausgabe found/path/source/version |
build_scene_template.py | --orbit 1 --center cx cy --dur --fps --a0 --a1 --r0 --r1 --z0 --z1 --l0 --l1 --out --csv | Ohne --orbit nur statische Szene; mit Orbit Frame-für-Frame Kamerakeyframes und Levitationskeyframes (LINEAR) |
validate_trajectory.py | --center --ceiling --keys --moving --margin --tol | Exit-Code 0=PASS 1=FAIL; vier Prüfungen |
export_cam_data.py | --out --center --keys | Ausgabe [{f,cam,rad,ang,pitch,object:[x,y,z]}] |
render_previs.py | --out --res --samples --fps --start --end --engine | Zuerst 16-Frame-Test, dann gesamtes Video |
install_blender.ps1 | -TargetDir -Version `-Mirror auto | official |
Parameter werden immer nach -- an das Python-Skript übergeben.
11. Außendarstellung (Antwort auf „Was kann dieses Skill?“)
Gib ihm ein Referenzbild oder eine Beschreibung, es baut deine Kamerafahrt zuerst als 3D-Weißmodell auf und führt es dir vor; stimmt etwas nicht, änderst du es, bis es passt; dann schreibt es die Prompts, und du gibst beides – Weißmodell-Video und Prompts – an Seedance 2.5 oder ein anderes Modell. Erkennung & Modellierung, vier automatische Validierungen, Weißmodell-Previs, Prompt-Schreibung gegen die Bewegung – alles dabei. Egal ob Umfahrung, Aufstieg oder Schwerelosigkeit, das Bild bleibt flüssig und kollidiert nicht plötzlich. Mit diesem One-Take-Skill werden lange Fahrten stabil – brauchst du für KI-Videos noch stundenlanges esoterisches Prompt-Tuning?
12. Selbstteststatus dieses Skills
| Schritt | Ergebnis |
|---|---|
| Blender-Erkennung | Bestanden (4.5.15 LTS portable, Laufwerk D) |
| Szene & Trajektorie & Levitationsanimation | Bestanden (240 Frames @24fps, Koordinaten-CSV erzeugt) |
| Vier Validierungen | PASS: Bildverlust 0 (960 NDC-Prüfungen), neue Kollisionen 0, Deckendurchbruch 0, drei Monotonieprüfungen alle True |
| Frame-für-Frame-Daten-Export | Bestanden (240-Frame-JSON) |
| Previs-Rendering | Bestanden (EEVEE_NEXT, 16-Frame-Test-mp4 normal) |
| Installationsskript | Bestanden (-DryRun getestet: offiziell 403 → Aliyun 4.5.16, ca. 380 MB) |
Vorlagen-Standardparameter siehe knowledge/kb-levitation-office.md; können direkt als Startpunkt für neue Projekte verwendet werden.