Was macht Photoreal-Asset?
Recherchiere eine Aufgabenbeschreibung, führe einen einzelnen Build-Durchlauf durch, vergleiche das Ergebnis mit Fotos und berichte das Resultat. Nutze die installierte Blender-Version und die verfügbaren Agent-Tools des Hosts; es wird kein bestimmter Agent-Anbieter, kein bestimmtes Modell, kein bestimmter Blender-Installationspfad und kein bestimmter Projektort vorausgesetzt.
Einrichtung
- Ersetze
{SKILL}durch das Verzeichnis, das diese Datei enthält, und{SCRIPTS}durch das dazugehörigescripts/-Verzeichnis. Ersetze{PROJECT}durch das vom Benutzer gewählte Projektverzeichnis. Setze Pfade in Anführungszeichen. Die Beispiele verwenden Schrägstriche, die Python unter Windows, macOS und Linux akzeptiert. - Verwende Python 3 mit
numpyundPillow(python -m pip install -r "{SKILL}/requirements.txt"). SciPy ist optional und beschleunigt UV-Überprüfungen. Blender verwendet sein gebündeltes Python fürbpy-Skripte. - Finde
blenderimPATH, oder setzePHOTOREAL_BLENDERauf den vollständigen Pfad der ausführbaren Datei, ohne Anführungszeichen im Wert. Verwende dieselbe ausführbare Datei für Build-Skripte und das Harness. Überprüfe die Version und passe den Build-Code an die unterstütztebpy-API an; gehe nicht von einer festen Version aus. - Cycles wählt ein verfügbares GPU-Backend aus und fällt auf die CPU zurück. Setze
PHOTOREAL_CYCLES_DEVICEaufCPU,OPTIX,CUDA,HIP,METALoderONEAPI, um die automatische Auswahl zu überschreiben. Führe Renderings sequenziell durch. Eine optionale externegpu_slot.py-Warteschlange kann überPHOTOREAL_GPU_TOOLSbereitgestellt werden; sie ist nicht im Skill enthalten oder erforderlich. - Pfade in
asset.jsonsind relativ zu dieser Datei. Ein leererhdri-Eintrag verwendet einen prozeduralen Tageshimmel; andernfalls verweise auf eine vorhandene HDRI. Sobald der Bau beginnt, sollten Beleuchtung und Kameras festgelegt bleiben. - Die Standardauslieferung ist eine bearbeitbare
.blend-Datei mit eingebetteten Bildern und Review-Renderings. Füge Spielexporte nur auf Anfrage hinzu, gemäß der templates/GAME_READY.md.
Projektstruktur
<project>/
asset.json Kameras, Beleuchtung, Collection-Präfix und Kritiker-Referenzen
BRIEF.md Research-Brief plus die ausgefüllte RULES.md-Vorlage
ref/SOURCES.md Quellennachweise der Fotos; Referenzbilder werden nicht mitgeliefert
research/ layout.py, blockout.py, blockout.blend, NOTES.md
rounds/r01-build/ TASK.md, build.py, NOTES.md, tex/, renders/, final/, DONE.txt
<Titel>.md Runden-Tabelle und Projekttagebuch
Verwende eine vorhandene Asset-Bibliothek, falls der Benutzer eine bereitstellt. Zeichne Quell-URLs und Lizenzen für externe Bilder und Texturen auf. Kennzeichne unbekannte Lizenzen als unbekannt; erfinde keine Eigentumsverhältnisse und gib Referenzfotos nicht mit dem Ergebnis weiter.
1. Research
- Kopiere templates/asset.json in das Projekt und passe das Subjekt, den
collection_prefix, Himmel und Boden an. Rahme eine Helden-, Seiten-/Front-, Dreiviertel-Top- und Nahaufnahme des schwierigsten Teils ein. Setzerender_as,photo_kindundscope_notefür den Kritiker. - Fülle templates/TASK_research.md aus:
{ASSET},{PROJECT},{PREFIX},{SUBJECT_PLURAL},{SKILL}und{SCRIPTS}. Speichere es alsresearch/TASK.md. Führe einen Forscher über die Agent-Tools des Hosts aus oder führe die Recherche direkt durch. - Liefere Referenzfotos mit Quellennachweisen,
BRIEF.md,research/layout.pymit einer Zone pro Teil und einer Besitzer-Collection, den Blockout sowieowner_refs/overall_refsinasset.json. - Überprüfe die Blockout-Renderings mit dem Bildbetrachter des Hosts. Passe die Kameras an, bis jede ihr Subjekt einfängt, und sperre sie dann.
Bei einem mitgelieferten Design-Blatt kopiere es unverändert in ref/, zeichne den gelieferten Quellennachweis auf
(unbekannt, wo nicht angegeben), und erstelle Detail-Ausschnitte. Verwende dessen Ansichten für die bewerteten Kameras.
Setze critic_goal, wenn das Ziel darin besteht, ein stilisiertes Design zu treffen, anstatt als Foto durchzugehen;
Passe die Aufgabenformulierung und etwaige zusätzliche Ergebnisse entsprechend an.
2. Build
- Erstelle
rounds/r01-build/TASK.mdaus templates/TASK_build.md. Fülle{ROUND},{ASSET},{PROJECT},{ROUND_DIR},{FILE}und{SCRIPTS}aus. - Lasse
{GAME_READY}für ein reines Blender-Asset leer. Andernfalls füge die ausgefüllte templates/GAME_READY.md ein und wähle Godot, Unreal Engine oder beide aus. - Gib die Aufgabe an einen einzelnen Builder. Verwende das aktuelle Modell, sofern der Benutzer kein anderes anfordert. Behalte die Sitzungskennung bei, falls der Host eine bereitstellt. Ein Builder kontrolliert die Geometrie; unabhängige Kritiker überprüfen sie nur.
3. Überprüfung jeder Runde
- Rendere die finale Szene:
python "{SCRIPTS}/run.py" --asset "{PROJECT}/asset.json" --parts "{ROUND_DIR}/final/{FILE}.blend" --out "{ROUND_DIR}/final/renders" - Lese
NOTES.mdund die letztecritique.md. Überprüfe Vollformat-Ausschnitte der schwierigen Teile neben den Fotos, einschließlich aufgehellter Ausschnitte, wo sinnvoll. Die Anzahl der Schweregrade ist verrauscht; verwende die tatsächlichen visuellen Unterschiede, um den Fortschritt zu beurteilen. - Vergleiche mit der vorherigen Runde, falls vorhanden:
Überprüfe die resultierendenpython "{SCRIPTS}/compare_rounds.py" --asset "{PROJECT}/asset.json" --rounds <vorherige-runde> <aktuelle-runde> --focus <zonen-ids> --refs "<foto>:x0,y0,x1,y1" --out "{PROJECT}/compare_rounds"_all.jpg- und_focus.jpg-Tafeln. Verwende die voncompare_rounds.py --helperwarteten Rundepfade. - Für Spielexporte führe die zielspezifische Validierung in
GAME_READY.mddurch. Beschreibe einen Unreal-Import nicht als durch den Godot-GLB-Prüfer validiert. - Falls unterstützte Transkripte verfügbar sind, führe optional Folgendes aus:
Dieses Audit versteht Antigravity- und Claude Code-Protokolle, nicht jedoch von jedem Host. Verwendepython "{SCRIPTS}/audit_round.py" "{ROUND_DIR}" --root "{PROJECT}"--sessionfür eine Antigravity-Konversation und--allowfür zusätzlich erlaubte Tool-Verzeichnisse. Die Dateipfadprüfung erkennt Windows-Laufwerkspfade; überprüfe andere Pfadstile separat. Protokollwurzeln können mitPHOTOREAL_ANTIGRAVITY_LOGSundPHOTOREAL_CLAUDE_LOGSüberschrieben werden. - Dokumentiere die Runde und berichte über Bilder, Verbesserungen, Regressionen, Validierungsergebnisse und eine Empfehlung. Berichte Kosten nur, wenn sie gemessen wurden. Stoppe nach der angeforderten Runde; beginne eine weitere Verfeinerung nur, wenn der Benutzer darum bittet. Kopiere oder importiere in eine externe Bibliothek nur, wenn dieses Ziel und diese Aktion angefordert wurden.
4. Verfeinerung auf Anfrage
- Besorge bessere Fotos der genannten Teile aus relevanten Blickwinkeln: sitzend, leer, seitlich und aus
dem Winkel der bewertenden Kamera. Zeichne die Quellennachweise in
ref/SOURCES.mdauf. - Setze die stärksten Referenzen an die erste Stelle der
owner_refs-Liste des Besitzers; jede Gruppe erhält bis zu sechs. - Kopiere die vorherigen Build-Skripte,
tex/undfinal/{FILE}.blendin einen neuen Ordnerrounds/rNN-<fokus>/. Bewahre die Notizen alsNOTES_<vorherige>.md, die letzte Überprüfung alsrenders/<vorherige>_check/und die finalen Renderings alsrenders/<vorherige>_final/auf. - Fülle templates/TASK_refine.md aus, einschließlich der Teile, Zonen-IDs und neuen Referenzen. Beschränke Änderungen auf diese Teile, außer bei Schweregrad-3-Fehlern an anderer Stelle. Behalte die Regel bei, dass Fotos widersprüchliche Positionen und Winkel, einschließlich verbundener Teile, dominieren.
- Führe einen einzelnen Builder aus, überprüfe wie oben und zeige die vorherigen und aktuellen Ergebnisse neben den Fotos.
Agentenübergabe und unabhängige Kritik
Verwende die native Agenten-Schnittstelle des Hosts, anstatt einen Tool-Namen oder Modell-Alias anzunehmen.
Gib dem Forscher oder Builder sein Arbeitsverzeichnis und die vollständige Aufgabendatei. Beschränke Schreibvorgänge auf das
zugewiesene Projekt- oder Rundenverzeichnis. Die Aufgabe endet mit dem Schreiben von DONE.txt.
Falls die Builder-Delegation nicht verfügbar ist, baue direkt, während du dieselben Aufgabengrenzen einhältst.
Der Kritiker gemäß Regel 11 muss unabhängig vom Builder sein. photo_check.py erstellt Prompts und ein
critic_jobs.json-Manifest. Sende jeden Prompt an einen neuen Prüfer mit Leseberechtigung für Bilder/Dateien,
keine Netzwerk- oder Bearbeitungswerkzeuge, speichere dann seine JSON-Antwort in der response_file des Manifests und führe die Zusammenführung durch.
Führe Kritiker nur gleichzeitig aus, wenn der Host dies unterstützt, unter Berücksichtigung von critic.parallel.
Verwende den Bildbetrachter des Hosts, wo ein Prompt sich auf Bild-/Dateilesen bezieht.
Falls unabhängige Unteragenten nicht verfügbar sind, kann --runner claude eine installierte, authentifizierte Claude Code CLI verwenden. Andernfalls liefere die Renderings und vorbereiteten Review-Jobs aus und melde die unabhängige Kritik als unvollständig. Ersetze nicht die eigene Überprüfung des Builders und nenne sie nicht unabhängig.
Überprüfungen
| Skript | Zweck |
|---|---|
run.py / render.py | Rendere prefix-matchende Collections in der gesperrten Cycles-Szene; schreibe Kamera-PNGs und sheet.jpg. |
photo_check.py | Beschneide Layout-Zonen, bereite unabhängige Kritiker-Jobs vor und führe JSON-Antworten in critique.md zusammen. --from verwendet vorhandene Renderings; --groups wählt Besitzer aus. |
game_check.py / game_check_bl.py | Validiere Godot-LOD-Meshes, UVs, konvexe Kollisionen und eingebettete GLB-Texturen; erstelle ein LOD-Drehtellerbild. Siehe GAME_READY.md für die Unreal-Validierung. |
compare_rounds.py | Vergleiche Runden und fokussierte Ausschnitte mit einer Referenzzeile. |
audit_round.py | Überprüfe optional unterstützte Transkripte auf Dateizugriffe, Geschwister-Runden, Webaufrufe und gemessene Token-Nutzung. |
Überprüfungsprinzipien
- Bessere Fotos des schwachen Teils helfen meist mehr als das Hinzufügen von Regeln zur Aufgabenbeschreibung.
- Vergleiche jede Verfeinerung mit der vorherigen Runde: Eine Korrektur kann frühere Verbesserungen zunichtemachen.
- Überprüfe Maßstabsbeschwerden mit einer maßstabsgetreuen Überlagerung, bevor du die Geometrie änderst.
- Dunkle Hohlräume benötigen sichtbare Kanten-Highlights, Wandstärke und inneren Abfall. Aufhellung dient nur der Inspektion; halte die bewertete Beleuchtung fix. Überspringe die Aufhellung, wenn sie ein High-Key-Bild abschneidet.
- Verwende Kritiken als Reparaturliste innerhalb einer Runde, nicht als numerische Bewertung zwischen Runden.