Esquisse vers rendu photoréaliste

Que fait Esquisse vers rendu photoréaliste ?

Transformez un dessin architectural – croquis manuel, élévation, export SketchUp ou Revit, plan de site coloré, feuille PDF – en une image qui ressemble à une photo prise avec un appareil plein format, tout en conservant exactement le design tel que dessiné. Gemini fabrique les pixels (gemini-3-pro-image, generateContent hérité). Votre travail consiste en tout ce qui entoure cet appel : lire le dessin, rédiger le briefing, surveiller les coûts et vérifier chaque résultat par rapport à sa source avant de livrer quoi que ce soit.

scripts/render.py effectue la mécanique, un appel de modèle par passage : il étend les bords de la source au plus proche des dix formats d'image proposés par le modèle (pour ne jamais lui demander de recomposer), effectue le rendu dans ce format, recadre le rectangle de la source, signale tout recadrage et écrit une feuille de comparaison avant/après. Les chemins ci-dessous sont relatifs au dossier de cette compétence ; appelez le script par son chemin absolu, avec le Python que render.py check valide.

Où cela s'exécute

Le rendu en direct nécessite Claude Code sur la machine de l'utilisateur, avec GOOGLE_API_KEY configurée. Si vous n'avez pas de shell local ou de système de fichiers – chat claude.ai, conteneur de compétences de l'API Claude – dites-le clairement : vous pouvez lire le dessin, rédiger le briefing et, si Python et Pillow sont présents, afficher une invite --prompt-only, mais vous ne pouvez pas effectuer le rendu. Ne proposez jamais de prendre la clé.

La politique permanente – citez-la, ne la paraphrasez jamais

La politique de rendu de l'utilisateur, donnée le 28 août 2026 :

Tâche : Effectuer le rendu de l'image d'entrée en qualité 1K d'abord pour réduire les coûts.

• Maintenir une géométrie, une échelle et un rapport 100 % précis.
• Pas d'hallucination, pas d'ajout/suppression d'élément sauf instruction explicite.
• Remplacer les matériaux par des finitions réelles (par exemple, toits en terre cuite, arbres réalistes, piscines, paysages).
• Le résultat doit ressembler à une photographie architecturale haut de gamme au DSLR.
• Toutes les modifications et révisions doivent rester en qualité 1K jusqu'à confirmation.

Une fois approuvée, améliorez la même image en qualité 4K :

• Offrir une netteté et une précision détaillées, sans flou ni bavure.
• Chaque élément doit sembler réel et photoréaliste en zoomant.
• Préserver la géométrie et la fidélité des détails de l'image de référence.

Règle finale : Effectuez toujours les rendus des modifications en 1K d'abord, puis passez en 4K uniquement après confirmation explicite.

L'exigence de feuille de comparaison de l'utilisateur, donnée le 31 août 2026 :

dans tous les futurs rendus, après chaque rendu, je veux une feuille de comparaison pour vérification croisée. mettre à jour partout.

Si vous reformulez l'une ou l'autre, citez-la. Les chiffres de coût et le contexte : references/policy.md.

Barrières strictes

1. Demandez avant de dépenser. Avant tout appel facturé, indiquez à l'utilisateur le nombre d'images, le niveau et le coût, et attendez un 'oui' explicite. Ajoutez ensuite --spend-ok. Le script applique cette règle : sans --spend-ok, il affiche l'estimation et se termine avec le code 3 sans lire la clé. Un 'oui' couvre exactement ce que vous avez cité ; chaque révision, correctif ou relance ultérieure d'un passage échoué constitue une nouvelle dépense, donc citez-la (une image, 1K, jusqu'à 0,268 USD) et obtenez un nouveau 'oui'. Vous pouvez mettre le plan et le prix dans un seul message (« Suivant : réviser la vue 02 pour corriger la couleur du toit – 1 image en 1K, jusqu'à 0,268 USD. On continue ? »). Les devis sont au tarif par image ; Google facture également l'image d'entrée de chaque tentative (environ 0,0011 USD), le texte de l'invite et les jetons de réflexion du modèle, alors précisez que le coût réel est légèrement supérieur au devis.
2. La 4K est par image, après approbation. Exécutez upscale --confirmed uniquement pour une image que l'utilisateur a vue sur sa feuille de comparaison et approuvée par son nom. « Ça a l'air bien » sur un ensemble n'est pas une approbation pour passer l'ensemble en 4K, et « rends-le plus net » n'est pas une approbation pour refaire le rendu en 4K – demandez quelle image en particulier. Citez-le comme toute dépense : le nom du fichier, 1 image, 4K, jusqu'à 2 tentatives, max 0,48 USD (0,24 USD par tentative).
3. N'itérez jamais en 4K. Corrigez tout d'abord en 1K ; le passage en 4K reproduit fidèlement les défauts. Un fichier 4K est définitif et n'est jamais révisé.
4. Chaque passage produit sa feuille, et vous la révisez en premier. Après chaque passage, ouvrez l'image de la feuille avec l'outil de lecture et examinez-la à l'aide de references/review-checklist.md. Décidez d'un verdict (correspondance / mineur / majeur) avec les problèmes que vous voyez, puis transmettez le rendu, la feuille et ce que la feuille montre. Un rendu sans sa feuille n'est pas terminé.
5. Ne jamais écraser, et ne jamais écrire dans le dossier de cette compétence. Le script ne réutilise jamais un nom de fichier et refuse un dossier de sortie à l'intérieur de la compétence ; ne déplacez, renommez ou remplacez pas vous-même les fichiers livrés ou les sources.
6. Ne manipulez jamais la clé API dans le chat. Ne la demandez pas, ne l'acceptez pas, ne l'imprimez pas et ne l'écrivez pas dans un fichier. Si un utilisateur en colle une, dites qu'elle est désormais exposée dans le chat, qu'il doit la supprimer et la recréer dans AI Studio, et expliquez comment configurer la nouvelle comme variable d'environnement. Préférez la variable d'environnement de l'utilisateur à un fichier .env, et ne placez jamais un fichier .env dans un dossier de compétence qui est copié, compressé ou téléchargé.
7. Dites une fois par projet, avant le premier appel en direct, que le dessin est envoyé à l'API Google Gemini (generativelanguage.googleapis.com) pour être rendu. Les dessins des clients sont confidentiels ; obtenez l'accord de l'utilisateur.
8. Chaque relance est facturée, y compris les tentatives qui ne renvoient aucune image. Corrigez l'invite ; n'augmentez jamais --attempts pour sauver une mauvaise invite (le script la limite à 3).

Ce que cette compétence ne peut pas faire

Le pipeline conserve la caméra du dessin. Il ne peut pas montrer un autre côté du bâtiment, un nouvel angle, un zoom, un recadrage ou un format d'image différent, et il ne peut pas transformer un plan d'étage en perspective ou en vue à hauteur d'œil : dans l'arbre, un plan envoyé comme image est revenu comme une maison différente, et les mouvements de caméra basés uniquement sur l'invite ont donné une villa différente à chaque fois (references/art-direction.md section 13). Lorsque l'utilisateur demande l'un de ces éléments, ne dépensez pas : expliquez-le, et demandez un nouvel export de cette vue à partir du modèle 3D, puis effectuez le rendu de cet export comme un nouveau travail. Ne mettez jamais de modifications de caméra ou de cadrage dans les notes revise ou patch ; le script affiche !! MOTS DE CAMÉRA / CADRAGE si vous le faites.

Il n'efface pas non plus les étiquettes, n'enregistre pas les panneaux, ne tuile pas les vues aériennes abruptes et ne compose pas de plaques de fond, ce que l'arbre faisait autour de ses rendus (references/failure-modes.md). Lorsque ces éléments fonctionnaient, avertissez l'utilisateur avant de dépenser que les mots seuls peuvent ne pas suffire.

Vérification de configuration (une fois par machine)

Exécutez python scripts/render.py check. Il affiche les versions de Python, Pillow et PyMuPDF, la police de la feuille, l'identifiant du modèle et l'endroit où la clé a été trouvée (uniquement la source, jamais la valeur) ; sans clé, il affiche les étapes pour en configurer une. Si l'import échoue, exécutez python -m pip install -r scripts/requirements.txt avec ce Python. Avec une clé en place, check --online effectue l'appel gratuit models.get pour prouver que la clé et le modèle fonctionnent ; il n'est jamais facturé.

Flux de travail pour une vue

1. Réception

Obtenez de l'utilisateur : le fichier sous forme de chemin sur le disque (une image collée n'a pas de chemin – demandez où se trouve le fichier), un nom de vue et des notes dans quatre champs – matériaux, éclairage, environnement, autres (chacun optionnel). Demandez tout ce que le dessin laisse ouvert et qui changerait l'image (cette zone plate est-elle une pelouse ou un pavement ? d'où vient le soleil ?) au lieu de deviner. Triez l'entrée :

• Une feuille avec plusieurs panneaux (étages, élévations) ou un PDF dont la vue n'est pas en page 1 : faites exporter un panneau ou une page, ou recadrez-les vous-même dans un nouveau fichier dans un dossier ... Input, une vue par travail. Dites à l'utilisateur que la feuille de comparaison associe ce panneau à son rendu. Les dispositions denses de meubles ont échoué de manière générative dans l'arbre ; dites-le avant de dépenser.
• Une demande que le pipeline ne peut pas honorer (voir ci-dessus) : arrêtez-vous et expliquez avant toute dépense.
• Une feuille avec un cartouche, un tableau de surfaces, des étiquettes ou des limites réglementaires : ceux-ci doivent rester exactement tels que dessinés, et le modèle ne peut pas conserver le texte (le briefing l'interdit). Faites-les recadrer avant le rendu et remettez-les en place inchangés sur la feuille finale en dehors du rendu ; nommez toute ligne réglementaire dans une mise en garde pour qu'elle ne soit pas transformée en mur ou effacée.
• Une demande qui contredit le dessin (un toit plat alors qu'un toit en croupe est dessiné) : signalez-le et demandez. La politique conserve la géométrie telle que dessinée, sauf si l'utilisateur dit explicitement le contraire.

2. Lire le dessin et rédiger le briefing

Exécutez d'abord un passage gratuit --prompt-only, toujours avec --out (en dehors de ce dossier de compétence ; pour assets/test_sketch.png, un dossier temporaire) : il pixellise la page 1 d'un PDF et écrit l'entrée remplie dans <out>/_work/prompt-only/<vue>_<niveau>_padded.jpg (au maximum 2400 px), le fichier le plus facile à regarder. Ouvrez-le avec l'outil de lecture et étudiez-le. Ensuite, rédigez le JSON du briefing en suivant references/art-direction.md :

{"elements": ["bloc de deux étages, toit en croupe, moitié gauche du cadre", "..."],
 "finishes": ["murs en plâtre à la chaux blanc cassé chaud", "..."],
 "cautions": ["CADRAGE : la villa s'étend de 20 à 78 % de la largeur, avant-toit à 37 % de hauteur ; si elle grandit, se recentre ou si du ciel est ajouté, le résultat a échoué", "..."]}

• elements : chaque élément du bâtiment, ouverture, forme de toit, niveau, garde-corps, piscine, zone de pavage, masse végétale et meuble, avec sa position et son nombre (max 30 éléments, 160 caractères).
• finishes : les matériaux réels (max 15, 120 caractères).
• cautions : l'ancrage de cadrage mesurable en PREMIER, avec son test « le résultat a échoué si ... » ; puis les nombres d'étages, les artefacts de dessin qui ne sont pas des objets, et les points négatifs spécifiques à ce cadre (max 10, 160 caractères).

Gardez le briefing court – les briefings longs ont perdu le cadrage dans l'arbre. Enregistrez-le à côté du travail, par ex. <out>/_briefs/<vue>.json. Tout texte plus long sur les matériaux ou le décor va dans --materials / --environment (les notes peuvent totaliser 4000 caractères).

3. Choisir les options

• Les toits ne sont pas en terre cuite (dalles plates, membrane, ardoise, métal, toit végétalisé) ? Ajoutez --no-terracotta-example, mettez une mise en garde sur le toit dans le briefing (« tous les toits sont plats – pas de tuiles, pas de pente, pas de terre cuite », ou « le toit de l'aile est une dalle plate – pas de tuiles, pas de pente ») et nommez la finition réelle du toit. Le briefing de fidélité partagé utilise la terre cuite comme exemple de finition et a ajouté des toits de tuiles rouges à des villas à toit plat ; l'option supprime cet exemple positif. Une mise en garde peut encore nommer la terre cuite comme négatif.
• Le niveau par défaut est 1K. Suggérez --size 2K (même prix catalogue) uniquement lorsque des éléments clés feraient moins d'environ 20 px de large en 1K, comme sur une vue aérienne d'un vaste domaine, et utilisez-le uniquement après l'accord de l'utilisateur ; la 4K n'est jamais un niveau de brouillon.
• L'entrée est une copie préparée (axes nettoyés, étiquettes effacées, vide blanc pré-rempli) ? Passez l'export non modifié comme --original FILE afin que la feuille associe le véritable original.
• --out par défaut dans un dossier frère 03 Output lorsque l'entrée se trouve dans un dossier ... Input, sinon <dossier d'entrée>/03 Output ; il ne peut jamais se trouver à l'intérieur du dossier de cette compétence.

4. Auditer l'invite (gratuit)

Relancez avec le briefing et les notes et --prompt-only, lisez l'invite imprimée et vérifiez que rien dedans ne demande un élément que le dessin ne possède pas.

5. Estimer, demander, effectuer le rendu

Exécutez la commande sans aucun indicateur de barrière pour obtenir l'estimation (code de sortie 3), citez-la à l'utilisateur et attendez un 'oui'. Exécutez-la à nouveau avec --spend-ok. Un appel en direct prend généralement 20 à 60 secondes, mais une tentative peut attendre jusqu'à 15 minutes, plus longtemps qu'un appel Bash en avant-plan : exécutez les passages en direct en arrière-plan (run_in_background) et attendez-les. Si une commande en direct est interrompue, exécutez render.py status, signalez le passage interrompu comme peut-être facturé et demandez avant toute relance. Plusieurs vues : citez le total du lot (vues x 1K x jusqu'à 2 tentatives) et obtenez un 'oui' pour le lot, puis exécutez les vues les unes après les autres.

6. Examiner la feuille

Ouvrez <out>/_Avant Après - <vue>_1K.jpg avec l'outil de lecture. Suivez references/review-checklist.md : cadrage et proportions, nombres, ouvertures, forme du toit, étages, objets ajoutés ou manquants, texte, matériaux, réalisme. Une note orange « format a -> b (cadrage modifié) » ou une ligne d'AVERTISSEMENT du script signifie que le modèle a recadré : ce rendu ne peut être ni révisé ni approuvé, effectuez donc à nouveau le rendu à partir de la source avec un ancrage de cadrage plus fort et une mise en garde nommant exactement ce que le passage échoué a fait (« TENTATIVE PRÉCÉDENTE ÉCHOUÉE : ... »). Si deux rendus 1K d'une vue recadrent, arrêtez-vous et signalez-le plutôt que de relancer. Ouvrez le rendu lui-même lorsque la feuille est trop petite pour juger un détail.

7. Rapport

Donnez à l'utilisateur : le chemin du rendu, le chemin de la feuille, votre verdict avec les problèmes que vous avez trouvés, le coût (render.py status l'affiche) et les choix – approuver cette image pour la 4K, réviser une chose, corriger une région ou effectuer à nouveau le rendu à partir de la source.

Boucle de révision (reste en 1K)

revise "<rendu actuel>" --notes "<un changement>". Règles :

• Un changement par passage. Plusieurs changements dans une seule édition ont tendance à régénérer l'ensemble du cadre.
• Décrivez l'état cible de l'objet, pas la correction (« la porte d'entrée est en bois bronze chaud massif avec deux barres de tirage verticales », pas « répare la porte »). Zoomez sur le rendu avant de l'écrire : une recoloration n'est pas un ajout.
• L'avant est l'image en cours de révision ; la feuille l'associe au nouveau fichier (AVANT · <vue>_1K / APRÈS · <vue>_1K_rev02).
• Seul le fichier actuel (le passage non 4K le plus récent du travail) peut être révisé ; le script le nomme si vous en choisissez un autre. Une révision d'un rendu 2K est effectuée en 1K et nommée _1K_revNN.
• Lorsque la composition elle-même est erronée (caméra déplacée, sujet agrandi, avertissement de recadrage), ne révisez pas : exécutez render à nouveau à partir de la source avec un meilleur briefing.

Correction (une réparation locale, reste en 1K)

patch "<rendu actuel>" --box x0,y0,x1,y1 --notes "<le changement>" avec la boîte en fractions du cadre (0,0 en haut à gauche). La boîte est recadrée, éditée en pleine 1K, redimensionnée et collée avec un fondu de 36 px sur les bords à l'intérieur du cadre ; chaque pixel en dehors de la boîte reste identique octet par octet. Utilisez-la pour un objet ou une zone (un mur inventé, une mauvaise plante, une porte). Dites ce qui doit changer et que cela doit être clairement visible ; ne lui dites pas de conserver exactement ce que vous voulez changer. Chaque côté de la boîte doit faire au moins 72 px.

4K (une image approuvée)

Lorsque l'utilisateur a dit « approuve [nom de fichier] pour la 4K » : exécutez upscale --confirmed "<chemin du rendu>". Le script effectue jusqu'à 2 tentatives, citées à up to USD 0.48. Ouvrez la feuille, vérifiez la netteté et la fidélité par rapport à l'original, et remettez-la avec le rendu en disant que le fichier ne sera jamais révisé.

---

Pour les images, les feuilles et les briefings, lisez references/.