Que fait polywright-references ?
Les références déterminent la majeure partie du résultat 3D : un modèle image-vers-3D copie l'éclairage, la perspective et les erreurs de son entrée ; un modeleur ou un script bpy a besoin de dimensions et de vues. Rassemblez-les ou générez-les d'abord, placez-les dans le dossier refs/ de l'actif, enregistrez chaque référence avec pw.py manifest --add-source (les références générées précisent le modèle et la graine).
Retour au hub : ../polywright/SKILL.md. Modèles de prompts et vérifications : references/reference-kit.md.
Étape 1 : de quoi ce modèle a besoin
| Modèle | Collecter (réel) | Générer (imaginé ou manquant) |
|---|---|---|
| Objet réel | photos sous 6 côtés avec une règle dans le plan, gros plans, dimensions réelles (fiche fabricant, Wikipédia, mètre) | nettoyages orthographiques seulement si les photos sont médiocres |
| Véhicule, produit, meuble | plans ou dessins CAO (vérifier une dimension connue), dimensions fabricant | vues de face, côté, dessus en style dessin technique |
| Bâtiment | empreinte au sol (OSM), hauteur ou nombre d'étages, photos de chaque face, forme du toit | élévations par face, plan de toit |
| Lieu réel | extrait de carte, altitude, photo aérienne, photos au sol des points de repère | aucune : les lieux proviennent de données (polywright-capture) |
| Objet imaginaire | références de style | une image hero trois-quarts, puis face/gauche/droite/arrière à la même échelle |
| Personnage ou créature | références de style et de costume | tournage : face, côté, dos, trois-quarts, pose A, barre de hauteur, fond uni |
| Surfaces (murs, sol, terrain) | photo du matériau, plate et éclairée uniformément | albédo tessellable sans couture, puis cartes (étape 4) |
Ajoutez toujours une référence d'échelle : une dimension connue, une silhouette humaine de 1,8 m, une barre de hauteur sur la feuille.
Un pack de recherche historique (un dossier contenant answer.md, refs/index.json et anachronism.md, créé par le plugin historywright) est déjà un dossier d'actif valide : partez de celui-ci, ne refaites pas la recherche. Lisez refs/index.json : chaque référence a sa propre date, lieu, institution, numéro d'inventaire et licence. N'utilisez que les références dont object_date correspond à la période du brief. Gardez une référence avec nc: true hors d'un modèle commercial. Vérifiez chaque vue générée par rapport à anachronism.md avant de la convertir en maillage.
Étape 2 : générer les vues (règles importantes)
Demandez à l'outil d'image : un objet, centré, occupant environ les deux tiers du cadre ; fond blanc ou gris clair uni ; lumière plate, uniforme, sans ombre ; perspective peu marquée (longue focale ou aspect orthographique) ; 1024 px ou plus ; pas de texte. Les personnages sont debout dans une pose A détendue (bras à 30-45 degrés vers le bas, jambes légèrement écartées) : les poses T déforment les proportions et les poses d'action échouent dans les générateurs et les riggers. Les modèles par type sont dans le kit.
Pour obtenir des vues supplémentaires cohérentes à partir d'une seule image, un modèle d'édition d'image avec un adaptateur multi-angles (Qwen Image Edit avec un LoRA Multiples Angles, 2025-2026) conserve mieux l'identité que de générer une invite par vue ; attendez-vous à une dérive des couleurs et réalignez la couleur de chaque vue sur la vue de face. Vérifiez chaque vue générée par rapport à la vue de face : mêmes proportions, même nombre de bras, mêmes éléments, rien n'est réorienté. Jetez une vue qui dévie ; une vue arrière erronée est pire que pas de vue du tout. Nommez la couleur d'un objet réel à partir des pixels de la photo (médiane de teinte, saturation, valeur), et non à partir d'un mot : le modèle d'édition suit le mot plutôt que l'image (L-003). Les vues arrière ont tendance à copier un marquage avant sur l'arrière.
Un workflow prêt pour un hôte Z-Image Turbo : references/zimage-reference.api.json (espace réservé {SUBJECT} ; testé le 2026-10-11).
Étape 2b : la fiche d'un objet conçu provient du modèle
Quand l'objet est conçu (une arme, un outil, une pièce de véhicule décrite en mots ou sur une feuille de fan) et que les invites textuelles ne donnent que la moitié de la forme, arrêtez de générer : construisez-le avec un script bpy (recette polywright-blender "Un objet conçu à partir d'une description écrite") et générez la fiche à partir du modèle, vue de côté et de dessus orthographique sur fond gris moyen, Cycles sur CPU quand le GPU est occupé. Un modèle est exact, se re-rend en quelques secondes après chaque note, et le même fichier composera plus tard l'objet dans une image (hub : "Composer un modèle dans une image"). Élevez la caméra de côté de 10 à 15 degrés lorsque des pièces viennent en paires miroir, ou qu'une se cache derrière l'autre.
Étape 3 : vues à partir d'une maquette (quand les vues ne cessent de diverger)
Construisez une maquette grossière (primitives, ou un premier maillage généré côté face uniquement), générez-la avec pw.py render <fichier> --out refs/blockout --views front,right,back,left --color clay, puis faites repeindre chaque rendu gris par un modèle d'édition d'image dans les couleurs et les détails du sujet (image-to-image avec le rendu comme première référence et la vue de face comme seconde). Seule la caméra bouge, donc rien ne peut être réorienté ni gagner de membres supplémentaires ; l'arrière ne peut montrer que ce que la maquette implique. Alimentez l'ensemble repeint dans la génération multi-vues.
Étape 4 : textures et matériaux
- Préférez un matériau CC0 (Poly Haven, ambientCG) plutôt qu'un matériau généré.
- Tessellable généré : demandez "sans couture, tessellable, vue de dessus, lumière plate et uniforme" à une puissance de deux, puis
pw.py texture <img> --out refs/tex --seamless(mixage de décalage) et examinez un carrelage 2x2. - Cartes rapides à partir d'une photo ou d'un albédo :
pw.py texture <img> --out refs/tex [--convention opengl|directx]écrit les cartes de hauteur, normale et rugosité dérivées de la luminance. Convient pour les objets et le terrain, incorrect pour les matériaux mesurés. Cartes normales : OpenGL (Y+) pour Blender, Unity, Godot, glTF, three.js, Roblox ; DirectX (Y-) pour Unreal. - La lumière cuite dans une photo devient la lumière cuite dans l'albédo : corrigez en amont avec une lumière plate, ou ajoutez
--delight(divise les gradients larges ; les ombres portées nettes restent, repeignez-les). Les cartes normales ne modifient que l'ombrage : les silhouettes restent plates et les grandes formes se brisent aux angles rasants, donc modélisez les grandes formes et cartographiez uniquement les petits détails.
Étape 5 : mettez-les au travail
- Dans Blender : images de référence comme empties dans les vues de face, droite et dessus, mises à l'échelle selon une dimension connue (les rendus orthographiques de
pw.py rendersignalentmetres_per_px) ; recette dans polywright-blender. - Pour image-vers-3D : carré, rempli, 1024 px ;
pw.py genremplit et supprime les fonds lui-même. Jugez l'image avant le lancement GPU, et ce qu'il faut corriger dans celle-ci plutôt que dans le maillage : references/images-for-3d.md. - Sur un tableau (PureRef 2.1) pour un humain : groupez par vue, notez les dimensions sur le tableau.
Maintenance
Evergreen, tier fast. Fichiers compagnons : RESEARCH.md, CHANGELOG.md, LEARNINGS.md, TESTS.md avec evals/evals.json, MAINTENANCE.md, état dans evergreen.json. Lisez evergreen.json à chaque utilisation ; rafraîchissez quand nécessaire.