Skizze zu fotorealistischem Rendering

Was macht Skizze zu fotorealistischem Rendering?

Verwandle eine Architekturzeichnung – Handskizze, Aufriss, SketchUp- oder Revit-Export, farbiger Lageplan, PDF-Blatt – in ein Bild, das wie mit einer Vollformat-DSLR aufgenommen aussieht, wobei das Design exakt wie gezeichnet erhalten bleibt. Gemini erzeugt die Pixel (gemini-3-pro-image, Legacy generateContent). Deine Aufgabe ist alles rund um diesen Aufruf: die Zeichnung lesen, die Aufgabenbeschreibung schreiben, die Kosten überwachen und jedes Ergebnis vor der Auslieferung mit seiner Quelle abgleichen.

scripts/render.py erledigt die Mechanik, ein Modellaufruf pro Durchlauf: Es erweitert die Quelle auf das nächstgelegene der zehn vom Modell angebotenen Seitenverhältnisse (damit das Modell nie neu komponieren muss), rendert in diesem Verhältnis, schneidet das ursprüngliche Rechteck der Quelle wieder aus, markiert jede Neurahmung und schreibt einen Vorher-/Nachher-Vergleichsbogen. Die Pfade unten sind relativ zum Ordner dieser Skill; rufe das Skript mit seinem absoluten Pfad und dem Python auf, das render.py check besteht.

Wo dies läuft

Live-Rendering benötigt Claude Code auf dem Rechner des Benutzers, mit gesetztem GOOGLE_API_KEY. Wenn du keine lokale Shell oder kein Dateisystem hast – claude.ai-Chat, der Claude-API-Skills-Container – sag dies klar: Du kannst die Zeichnung lesen, die Aufgabenbeschreibung schreiben und, falls Python und Pillow vorhanden sind, einen --prompt-only-Prompt anzeigen, aber du kannst nicht rendern. Biete niemals an, den Schlüssel zu nehmen.

Die ständige Richtlinie – zitiere sie, paraphrasiere nicht

Die Render-Richtlinie des Benutzers, gegeben am 28. August 2026:

Aufgabe: Rendere das Eingabebild zuerst in 1K-Qualität, um Kosten zu sparen. – Behalte 100 % genaue Geometrie, Maßstab und Verhältnis bei. – Keine Halluzination, kein Hinzufügen/Entfernen von Elementen, es sei denn, ausdrücklich angewiesen. – Ersetze Materialien durch echte Oberflächen (z. B. Terrakotta-Dächer, realistische Bäume, Pools, Landschaften). – Die Ausgabe muss wie hochwertige DSLR-Architekturfotografie aussehen. – Alle Bearbeitungen und Überarbeitungen sollten bis zur Bestätigung in 1K-Qualität bleiben.

Nach Genehmigung skaliere dasselbe Bild auf 4K-Qualität hoch: – Liefere gestochen scharfe, detaillierte Genauigkeit ohne Unschärfe oder Verschmieren. – Jedes Element muss beim Zoomen echt und fotorealistisch erscheinen. – Behalte exakte Geometrie und Detailtreue des Referenzbildes bei.

Endgültige Regel: Rendere Bearbeitungen immer zuerst in 1K, dann verbessere auf 4K nur nach expliziter Bestätigung.

Die Anforderung des Benutzers an den Vergleichsbogen, gegeben am 31. August 2026:

Gib mir bei allen zukünftigen Renderings nach jedem Rendering einen Vergleichsbogen zur Überprüfung. Aktualisiere überall.

Wenn du eine dieser Aussagen wiederholst, zitiere sie. Kostenangaben und Hintergrund: references/policy.md.

Harte Beschränkungen

1. Frage vor dem Ausgeben. Sage dem Benutzer vor jedem kostenpflichtigen Aufruf die Bildanzahl, die Stufe und die Kosten und warte auf ein explizites Ja. Füge erst dann --spend-ok hinzu. Das Skript erzwingt dies: Ohne --spend-ok gibt es die Schätzung aus und beendet sich mit Exit-Code 3, ohne den Schlüssel zu lesen. Ein Ja gilt genau für das, was du zitiert hast; jede spätere Überarbeitung, Korrektur oder Wiederholung eines fehlgeschlagenen Durchlaufs ist eine neue Ausgabe, also zitiere sie (ein Bild, 1K, bis zu USD 0,268) und hole erneut ein Ja. Du kannst den Plan und den Preis in einer Nachricht zusammenfassen („Als Nächstes: Ansicht 02 überarbeiten, um die Dachfarbe zu korrigieren – 1 Bild bei 1K, bis zu USD 0,268. Fortfahren?“). Die Zitate basieren auf dem Bildpreis; Google berechnet auch das Eingabebild jedes Versuchs (ca. USD 0,0011), den Prompt-Text und die Denk-Token des Modells, also sage, dass die tatsächlichen Kosten etwas über dem Zitat liegen.
2. 4K gilt pro Bild, nach Genehmigung. Führe upscale --confirmed nur für ein Bild aus, das der Benutzer auf seinem Vergleichsbogen gesehen und namentlich genehmigt hat. „Sieht gut aus“ bei einem Satz ist keine Genehmigung, den Satz auf 4K zu bringen, und „mach es schärfer“ ist keine Genehmigung, in 4K neu zu rendern – frage, welches einzelne Bild. Zitiere es wie jede Ausgabe: den Dateinamen, 1 Bild, 4K, bis zu 2 Versuche, max. USD 0,48 (USD 0,24 pro Versuch).
3. Iteriere niemals bei 4K. Korrigiere alles zuerst bei 1K; der 4K-Durchlauf reproduziert Fehler getreu. Eine 4K-Datei ist endgültig und wird nie überarbeitet.
4. Jeder Durchlauf liefert seinen Bogen, und du prüfst ihn zuerst. Öffne nach jedem Durchlauf das Bogenbild mit dem Read-Tool und prüfe es mit references/review-checklist.md. Entscheide ein Urteil (Übereinstimmung / geringfügig / schwerwiegend) mit den von dir gesehenen Problemen, dann übergebe das Rendering, den Bogen und das, was der Bogen zeigt. Ein Rendering ohne seinen Bogen ist nicht fertig.
5. Überschreibe niemals und schreibe niemals in diesen Skill-Ordner. Das Skript verwendet nie einen Dateinamen wieder und verweigert einen Ausgabeordner innerhalb des Skills; verschiebe, benenne um oder ersetze gelieferte Dateien oder Quellen nicht selbst.
6. Behandle den API-Key niemals im Chat. Frage nicht danach, akzeptiere ihn nicht, drucke ihn nicht aus und schreibe ihn nicht in eine Datei. Wenn ein Benutzer einen einfügt, sage, dass er nun im Chat offen liegt, dass er ihn in AI Studio löschen und neu erstellen und den neuen als Umgebungsvariable setzen sollte. Bevorzuge die Benutzer-Umgebungsvariable gegenüber einer .env-Datei und lege niemals eine .env in einen Skill-Ordner, der kopiert, gezippt oder hochgeladen wird.
7. Sage einmal pro Projekt, vor dem ersten Live-Aufruf, dass die Zeichnung an die Google Gemini API (generativelanguage.googleapis.com) gesendet wird, um gerendert zu werden. Zeichnungen von Kunden sind vertraulich; hole die Zustimmung des Benutzers ein.
8. Jeder Wiederholungsversuch wird abgerechnet, einschließlich Versuche, die kein Bild zurückgeben. Korrigiere den Prompt; erhöhe niemals --attempts, um einen schlechten zu retten (das Skript begrenzt es auf 3).

Was diese Skill nicht kann

Die Pipeline behält die eigene Kamera der Zeichnung bei. Sie kann keine andere Seite des Gebäudes, einen neuen Winkel, einen Zoom, einen Ausschnitt oder ein anderes Seitenverhältnis zeigen, und sie kann keinen Grundriss in eine perspektivische oder augenhöhe Ansicht verwandeln: Im Baum wurde ein als Bild gesendeter Plan als ein anderes Haus zurückgegeben, und rein promptbasierte Kamerabewegungen ergaben jedes Mal eine andere Villa (references/art-direction.md Abschnitt 13). Wenn der Benutzer so etwas verlangt, gib kein Geld aus: Erkläre es und bitte um einen neuen Export dieser Ansicht aus dem 3D-Modell, dann rendere diesen Export als neuen Auftrag. Setze niemals Kamera- oder Bildausschnittsänderungen in revise- oder patch-Notizen; das Skript gibt !! CAMERA / FRAMING WORDS aus, wenn du es tust.

Es löscht auch keine Beschriftungen, registriert keine Paneele, kachelt keine steilen Luftbilder oder setzt keine Hintergrundebenen zusammen, was der Baum um seine Renderings herum tat (references/failure-modes.md). Wenn dies funktioniert hat, warne den Benutzer vor dem Ausgeben, dass die Formulierung allein möglicherweise nicht ausreicht.

Setup-Prüfung (einmal pro Maschine)

Führe python scripts/render.py check aus. Es gibt die Python-, Pillow- und PyMuPDF-Versionen aus, die Schriftart des Bogens, die Modell-ID und wo der Schlüssel gefunden wurde (nur die Quelle, niemals den Wert); ohne Schlüssel gibt es die Schritte zum Setzen eines solchen aus. Wenn es bei einem Import fehlschlägt, führe python -m pip install -r scripts/requirements.txt mit diesem Python aus. Mit einem vorhandenen Schlüssel führt check --online den kostenlosen models.get-Metadatenaufruf durch, um zu beweisen, dass der Schlüssel und das Modell funktionieren; er wird niemals abgerechnet.

Workflow für eine Ansicht

1. Aufnahme

Hole vom Benutzer: die Datei als Pfad auf der Festplatte (ein eingefügtes Bild hat keinen Pfad – frage, wo die Datei ist), einen Ansichtsnamen und Notizen in vier Feldern – Materialien, Beleuchtung, Umgebung, Sonstiges (jeweils optional). Frage nach allem, was die Zeichnung offen lässt und das Bild verändern würde (ist dieser ebene Bereich Rasen oder Pflaster? Aus welcher Richtung kommt die Sonne?), anstatt zu raten. Sortiere die Eingabe:

• Ein Blatt mit mehreren Tafeln (Stockwerke, Aufrisse) oder ein PDF, dessen Ansicht nicht auf Seite 1 ist: Lasse eine Tafel oder Seite exportieren, oder beschneide sie selbst in eine neue Datei in einem ... Input-Ordner, eine Ansicht pro Auftrag. Sage dem Benutzer, dass der Vergleichsbogen diese Tafel mit ihrem Rendering paart. Dichte Möbelgrundrisse sind im Baum generativ fehlgeschlagen; sage dies vor dem Ausgeben.
• Eine Anfrage, die die Pipeline nicht erfüllen kann (siehe oben): Stoppe und erkläre vor jeder Ausgabe.
• Ein Blatt mit einem Schriftfeld, Flächenplan, Beschriftungen oder gesetzlichen Grenzlinien: Diese müssen exakt wie gezeichnet bleiben, und das Modell kann Text nicht halten (die Aufgabenbeschreibung verbietet es). Lasse sie vor dem Rendering wegschneiden und unverändert auf dem endgültigen Blatt außerhalb des Renderings platzieren; benenne jede gesetzliche Linie in einer Warnung, damit sie nicht in eine Wand verwandelt oder gelöscht wird.
• Eine Anfrage, die der Zeichnung widerspricht (ein Flachdach, wo ein Walmdach gezeichnet ist): Weise darauf hin und frage nach. Die Richtlinie behält die Geometrie wie gezeichnet bei, es sei denn, der Benutzer sagt ausdrücklich etwas anderes.

2. Zeichnung lesen und Aufgabenbeschreibung schreiben

Führe zuerst einen kostenlosen --prompt-only-Durchlauf aus, immer mit --out (außerhalb dieses Skill-Ordners; für assets/test_sketch.png einen temporären Ordner): Er rasiert Seite 1 eines PDFs und schreibt das gepaddete Input in <out>/_work/prompt-only/<view>_<tier>_padded.jpg (maximal 2400 px), die einfachste Datei zum Betrachten. Öffne sie mit dem Read-Tool und studiere sie. Schreibe dann die Aufgabenbeschreibung als JSON gemäß references/art-direction.md:

{"elements": ["zweigeschossiger Block, Walmdach, linke Hälfte des Bildausschnitts", "..."],
 "finishes": ["warme, gebrochen weiße Kalkputzwände", "..."],
 "cautions": ["RAHMUNG: Villa erstreckt sich über 20-78 % der Breite, Traufe bei 37 % Höhe; wenn sie wächst, zentriert oder Himmel hinzugefügt wird, ist das Ergebnis fehlgeschlagen", "..."]}

• elements: Jedes Bauelement, jede Öffnung, Dachform, Ebene, Geländer, Pool, Pflasterfläche, Bepflanzungsmasse und jedes Möbelstück mit seiner Position und seiner Anzahl (max. 30 Elemente, 160 Zeichen).
• finishes: Die echten Materialien (max. 15, 120 Zeichen).
• cautions: ZUERST den messbaren Rahmungsanker mit seinem „das Ergebnis ist fehlgeschlagen wenn …“-Test; dann Geschossanzahlen, Zeichnungsartefakte, die keine Objekte sind, und für diesen Bildausschnitt spezifische Negativbeispiele (max. 10, 160 Zeichen).

Halte die Aufgabenbeschreibung kurz – lange Beschreibungen haben im Baum die Rahmung verloren. Speichere sie neben dem Auftrag, z. B. <out>/_briefs/<view>.json. Längere Material- oder Umgebungstexte gehören in --materials / --environment (Notizen dürfen insgesamt 4000 Zeichen umfassen).

3. Flags auswählen

• Dächer sind nicht aus Terrakotta (Flachdächer, Membran, Schiefer, Metall, Gründach)? Füge --no-terracotta-example hinzu, setze eine Dachwarnung in die Aufgabenbeschreibung („alle Dächer sind flach – keine Ziegel, keine Neigung, kein Terrakotta“ oder „das Flügeldach ist eine flache Platte – keine Ziegel, keine Neigung“) und nenne die echte Dachoberfläche. Die gemeinsame Detailtreue-Aufgabenbeschreibung verwendet Terrakotta als Beispieloberfläche und hat rote Ziegeldächer zu Villen mit Flachdach hinzugefügt; das Flag entfernt dieses positive Beispiel. Eine Warnung darf Terrakotta dennoch als Negativbeispiel nennen.
• Standardstufe ist 1K. Schlage --size 2K (gleicher Listenpreis) nur vor, wenn Schlüsselelemente bei 1K unter etwa 20 px Durchmesser wären, wie bei einer weiten Luftaufnahme eines Anwesens, und verwende es nur, nachdem der Benutzer zustimmt; 4K ist niemals eine Entwurfsstufe.
• Die Eingabe ist eine vorbereitete Kopie (Achsenlinien bereinigt, Beschriftungen gelöscht, eine weiße Leere vorab ausgefüllt)? Übergib den unberührten Export als --original FILE, damit der Bogen das wahre Original paart.
• --out standardmäßig auf einen Geschwisterordner 03 Output, wenn die Eingabe in einem ... Input-Ordner liegt, sonst <input folder>/03 Output; es darf niemals innerhalb dieses Skill-Ordners sein.

4. Prompt prüfen (kostenlos)

Führe den Durchlauf mit der Aufgabenbeschreibung und Notizen sowie --prompt-only erneut aus, lies den ausgegebenen Prompt und überprüfe, dass nichts darin nach einem Element fragt, das die Zeichnung nicht hat.

5. Schätzen, fragen, rendern

Führe den Befehl ohne Gate-Flag aus, um die Schätzung zu erhalten (Exit-Code 3), zitiere sie dem Benutzer und warte auf ein Ja. Führe ihn dann erneut mit --spend-ok aus. Ein Live-Aufruf dauert normalerweise 20-60 s, aber ein Versuch kann bis zu 15 Minuten warten, länger als ein Vordergrund-Bash-Aufruf: Führe Live-Durchläufe im Hintergrund aus (run_in_background) und warte auf sie. Wenn ein Live-Befehl unterbrochen wird, führe render.py status aus, melde den unterbrochenen Durchlauf als möglicherweise abgerechnet und frage vor jedem erneuten Lauf. Mehrere Ansichten: Zitiere die Batch-Summe (Ansichten x 1K x bis zu 2 Versuche) und hole ein Ja für den Batch, dann führe die Ansichten nacheinander aus.

6. Bogen prüfen

Öffne <out>/_Before After - <view>_1K.jpg mit dem Read-Tool. Folge references/review-checklist.md: Rahmung und Proportionen, Anzahlen, Öffnungen, Dachform, Geschosse, hinzugefügte oder fehlende Objekte, Text, Materialien, Realismus. Ein orangefarbener Hinweis „aspect a -> b (framing changed)“ oder eine WARNING-Zeile vom Skript bedeutet, dass das Modell neu gerahmt hat: Dieses Rendering kann weder überarbeitet noch genehmigt werden, also rendere erneut aus der Quelle mit einem stärkeren Rahmungsanker und einer Warnung, die genau benennt, was der fehlgeschlagene Durchlauf getan hat („PREVIOUS ATTEMPT FAILED: …“). Wenn zwei 1K-Renderings einer Ansicht neu rahmen, stoppe und melde, anstatt neu zu würfeln. Öffne das Rendering selbst, wenn der Bogen zu klein ist, um ein Detail zu beurteilen.

7. Bericht

Gib dem Benutzer: den Rendering-Pfad, den Bogen-Pfad, dein Urteil mit den von dir gefundenen Problemen, die Kosten (render.py status zeigt sie an) und die Optionen – dieses Bild für 4K genehmigen, eine Sache überarbeiten, eine Region korrigieren oder erneut aus der Quelle rendern.

Überarbeitungsschleife (bleibt bei 1K)

revise "<aktuelles Rendering>" --notes "<eine Änderung>". Regeln:

• Eine Änderung pro Durchlauf. Mehrere Änderungen in einer Bearbeitung neigen dazu, den gesamten Bildausschnitt neu zu generieren.
• Beschreibe den Zielzustand des Objekts, nicht die Korrektur („die Eingangstür ist aus massiver, warm-bronzefarbener Eiche mit zwei vertikalen Zugstangen“, nicht „die Tür reparieren“). Zoome in das Rendering, bevor du es schreibst: Eine Neufärbung ist keine Hinzufügung.
• Das „Vorher“ ist das Bild, das überarbeitet wird; der Bogen paart es mit der neuen Datei (BEFORE · <view>_1K / AFTER · <view>_1K_rev02).
• Nur die aktuelle Datei (der neueste Nicht-4K-Durchlauf des Auftrags) kann überarbeitet werden; das Skript nennt sie, wenn du eine andere auswählst. Eine Überarbeitung eines 2K-Renderings wird bei 1K erstellt und als _1K_revNN benannt.
• Wenn die Komposition selbst falsch ist (Kamera bewegt, Subjekt vergrößert, Warnung vor Neurahmung), überarbeite nicht: Führe render erneut aus der Quelle mit einer besseren Aufgabenbeschreibung aus.

Korrektur (eine lokale Korrektur, bleibt bei 1K)

patch "<aktuelles Rendering>" --box x0,y0,x1,y1 --notes "<die Änderung>" mit der Box als Bruchteilen des Bildausschnitts (0,0 oben links). Die Box wird zugeschnitten, in voller 1K bearbeitet, zurück skaliert und mit einer 36-Px-Weichzeichnung an den Kanten innerhalb des Bildausschnitts eingefügt; jedes Pixel außerhalb der Box bleibt byte-identisch. Verwende es für ein Objekt oder einen Bereich (eine erfundene Wand, eine falsche Pflanze, eine Tür). Sage, was sich ändern muss und dass es deutlich sichtbar sein muss; sage ihm nicht, das zu behalten, was du genau geändert haben willst. Jede Seite der Box muss mindestens 72 Pixel betragen.

4K (ein genehmigtes Bild)

Wenn der Benutzer ein Bild auf seinem Vergleichsbogen gesehen und namentlich genehmigt hat, führe upscale "<render file>" --confirmed aus. Der Befehl rendert dasselbe Bild bei 4K neu (bis zu 2 Versuche), erstellt einen Vergleichsbogen ... 4K_01.jpg und überschreibt nichts. Gib den Bogen und das Rendering aus und berichte die endgültigen Kosten. Das 4K-Rendering ist endgültig: Keine Überarbeitung, keine Korrektur, kein erneuter Lauf.

Referenzen

Datei	Zweck
references/art-direction.md	Formulierung der Aufgabenbeschreibung, Beispiele für Elemente/Oberflächen/Warnungen, Kamerabewegungshinweise
references/review-checklist.md	Checkliste zur Bogenprüfung: Rahmung, Proportionen, Öffnungen, Materialien, Realismus
references/policy.md	Hintergrund zur Richtlinie, Kostenmodell, frühere Fehlermodi
references/failure-modes.md	Was die Pipeline nicht kann (Beschriftungen, Grundrisse, Kamerafahrten), archivierte Fälle

---

Vergiss nicht: Die Benutzer-Richtlinie besagt, dass jedes Rendering zuerst in 1K erfolgt, und der Bogen wird nach jedem Rendering benötigt. Zitiere dies, wenn relevant.