CommunityBildgithub.com

Photoreal-Asset

Erstelle fotorealistische Blender-Assets aus Referenzfotos mit einem einzelnen Builder und einem unabhängigen Fotokritiker. Optional können gebackene Texturen, LODs und Kollisionen für Godot oder Unreal Engine vorbereitet werden. Ideal für fotorealistische Requisiten, Szenen und referenzgesteuerte Verfeinerungen in Blender. Beginne eine weitere Verfeinerungsrunde nur auf Anfrage des Benutzers.

Was ist Photoreal-Asset?

Diese Fähigkeit (Skill) automatisiert den Erstellungsprozess fotorealistischer 3D-Assets in Blender, gesteuert durch Referenzfotos. Sie führt einen strukturierten Workflow durch: zuerst eine Research-Phase zur Analyse der Referenzen und Erstellung eines Blockouts, gefolgt von einem Build-Durchlauf, in dem ein einzelner Builder das finale Asset erstellt. Ein unabhängiger Fotokritiker (photo_check.py) bewertet das Ergebnis anhand der Originalfotos und erstellt eine detaillierte Kritik. Der gesamte Workflow ist plattformunabhängig und unterstützt sowohl Godot als auch Unreal Engine für Spielexporte. Die Fähigkeit legt Wert auf reproduzierbare Ergebnisse durch fixierte Kameras und Beleuchtung, sowie auf die strikte Trennung zwischen Builder und Kritiker. Sie ist besonders nützlich für Entwickler und 3D-Künstler, die hochwertige, referenzgetreue Assets für Spiele, Filme oder Architekturvisualisierung benötigen. Der Workflow ist in Runden organisiert, wobei jede Runde verfeinert wird, bis der Benutzer zufrieden ist.

Funktioniert mit✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add https://github.com/choobi-doobi/skill-blender-photoreal-asset/tree/HEAD

Installed? Explore more Bild skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

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örige scripts/-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 numpy und Pillow (python -m pip install -r "{SKILL}/requirements.txt"). SciPy ist optional und beschleunigt UV-Überprüfungen. Blender verwendet sein gebündeltes Python für bpy-Skripte.
  • Finde blender im PATH, oder setze PHOTOREAL_BLENDER auf 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ützte bpy-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_DEVICE auf CPU, OPTIX, CUDA, HIP, METAL oder ONEAPI, um die automatische Auswahl zu überschreiben. Führe Renderings sequenziell durch. Eine optionale externe gpu_slot.py-Warteschlange kann über PHOTOREAL_GPU_TOOLS bereitgestellt werden; sie ist nicht im Skill enthalten oder erforderlich.
  • Pfade in asset.json sind relativ zu dieser Datei. Ein leerer hdri-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

  1. 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. Setze render_as, photo_kind und scope_note für den Kritiker.
  2. Fülle templates/TASK_research.md aus: {ASSET}, {PROJECT}, {PREFIX}, {SUBJECT_PLURAL}, {SKILL} und {SCRIPTS}. Speichere es als research/TASK.md. Führe einen Forscher über die Agent-Tools des Hosts aus oder führe die Recherche direkt durch.
  3. Liefere Referenzfotos mit Quellennachweisen, BRIEF.md, research/layout.py mit einer Zone pro Teil und einer Besitzer-Collection, den Blockout sowie owner_refs / overall_refs in asset.json.
  4. Ü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

  1. Erstelle rounds/r01-build/TASK.md aus templates/TASK_build.md. Fülle {ROUND}, {ASSET}, {PROJECT}, {ROUND_DIR}, {FILE} und {SCRIPTS} aus.
  2. 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.
  3. 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

  1. Rendere die finale Szene:
    python "{SCRIPTS}/run.py" --asset "{PROJECT}/asset.json" --parts "{ROUND_DIR}/final/{FILE}.blend" --out "{ROUND_DIR}/final/renders"
    
  2. Lese NOTES.md und die letzte critique.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.
  3. Vergleiche mit der vorherigen Runde, falls vorhanden:
    python "{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"
    
    Überprüfe die resultierenden _all.jpg- und _focus.jpg-Tafeln. Verwende die von compare_rounds.py --help erwarteten Rundepfade.
  4. Für Spielexporte führe die zielspezifische Validierung in GAME_READY.md durch. Beschreibe einen Unreal-Import nicht als durch den Godot-GLB-Prüfer validiert.
  5. Falls unterstützte Transkripte verfügbar sind, führe optional Folgendes aus:
    python "{SCRIPTS}/audit_round.py" "{ROUND_DIR}" --root "{PROJECT}"
    
    Dieses Audit versteht Antigravity- und Claude Code-Protokolle, nicht jedoch von jedem Host. Verwende --session für eine Antigravity-Konversation und --allow für zusätzlich erlaubte Tool-Verzeichnisse. Die Dateipfadprüfung erkennt Windows-Laufwerkspfade; überprüfe andere Pfadstile separat. Protokollwurzeln können mit PHOTOREAL_ANTIGRAVITY_LOGS und PHOTOREAL_CLAUDE_LOGS überschrieben werden.
  6. 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

  1. 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.md auf.
  2. Setze die stärksten Referenzen an die erste Stelle der owner_refs-Liste des Besitzers; jede Gruppe erhält bis zu sechs.
  3. Kopiere die vorherigen Build-Skripte, tex/ und final/{FILE}.blend in einen neuen Ordner rounds/rNN-<fokus>/. Bewahre die Notizen als NOTES_<vorherige>.md, die letzte Überprüfung als renders/<vorherige>_check/ und die finalen Renderings als renders/<vorherige>_final/ auf.
  4. 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.
  5. 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

SkriptZweck
run.py / render.pyRendere prefix-matchende Collections in der gesperrten Cycles-Szene; schreibe Kamera-PNGs und sheet.jpg.
photo_check.pyBeschneide 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.pyValidiere 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.pyVergleiche 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.

Verwandte Skills