Déboguer un problème de rendu avec le code et des captures
Votre objet apparaît au mauvais endroit, mais le shader se compile. Une capture d'écran montre le symptôme ; le code montre plusieurs causes plausibles. Demander à l’IA de « corriger l’image » sans la caméra, les matrices ou le résultat attendu encourage une supposition convaincante.
Préparer un pack de preuves de rendu
Incluez le moteur de rendu/API, les étapes de shader pertinentes, les valeurs des variables uniform, la géométrie, le viewport, la caméra, le résultat attendu, l'image réelle et l'action de reproduction. Enregistrez les erreurs graphiques et compilez/liez les diagnostics sous forme d’observations, et non comme un résumé disant « tout va bien ».
| Preuve | Contenu utile | Ce qu'une capture d'écran seule ne peut pas établir |
|---|---|---|
| Image attendue et image obtenue | Même caméra et même résolution, région affectée marquée | Quelle transformation ou quel état a causé la différence |
| Shader et variables uniform | Révision exacte, convention matricielle, valeurs | Si l'hôte a transmis les valeurs prévues |
| Configuration du rendu | Géométrie, disposition des attributs, état de profondeur/culling/mélange | Quels objets ont été réellement dessinés |
| Reproduction | Scène et étapes minimales | Si un correctif suggéré corrige une autre scène |
Une texture manquante et un éclairage incorrect peuvent sembler similaires à la taille de la vignette. Fournissez un recadrage non compressé lorsque cela est possible et évitez de changer de caméra entre les images de comparaison.
Un exemple d'ordre de transformation avec une attente vérifiable
projection * view * model * position, avec la transformation la plus à droite appliquée en premier.Supposons que le shader contienne :
gl_Position = uProjection * uModel * uView * vec4(position, 1.0);(1,0,0,1), le résultat en coordonnées de clip prévu est (0,0.6,0,1) :Model: (1,0) -> (3,0)
View: (3,0) -> (0,3)
Projection: (0,3) -> (0,0.6)
Wrong order: View (1,0)->(0,1), Model ->(2,1), Projection ->(0.4,0.2)Demandez une hypothèse, une reproduction et un patch minimal
Examinez l’inadéquation du rendu fourni.
Utilisez le shader, l'état de l'hôte, le comportement attendu, l’image réelle et la révision.
Traitez les images comme des observations et non comme la preuve d’une cause fondamentale particulière.
Retour :
1. le symptôme observé et les preuves à l’appui ;
2. hypothèses classées, avec un test discriminant pour chacune d'entre elles ;
3. le plus petit test pour l'hypothèse principale ;
4. un correctif uniquement si le test étaye le défaut allégué ;
5. variables uniform, état ou contexte manquants qui empêchent une conclusion.
Utilisez la convention matrice/vecteur indiquée.
Ne réécrivez pas le moteur de rendu et ne changez pas la caméra pour masquer le défaut.
Ne prétendez pas avoir exécuté des tests si vous les avez seulement proposés.
Entrées : ensemble de preuves et contrat de transformation requis.Pour cet exemple, le correctif candidat est :
gl_Position = uProjection * uView * uModel * vec4(position, 1.0);Fournissez d’abord la convention matricielle et le shader fautif. Demandez une hypothèse et un correctif minimal ; distinguez (0,0.6) de (0.4,0.2) avec le test numérique avant de vérifier l’image réelle.
Effectuez une petite vérification numérique avant de juger l’image
Le code JavaScript suivant reflète la partie bidimensionnelle des transformations de cet exemple :
const model = ([x, y]) => [x + 2, y];
const view = ([x, y]) => [-y, x];
const projection = ([x, y]) => [x * 0.2, y * 0.2];
const correct = projection(view(model([1, 0])));
const wrong = projection(model(view([1, 0])));
if (Math.abs(correct[0]) > 1e-9 || Math.abs(correct[1] - 0.6) > 1e-9) {
throw new Error("Unexpected reference transform");
}
if (Math.abs(wrong[0] - correct[0]) < 1e-9 &&
Math.abs(wrong[1] - correct[1]) < 1e-9) {
throw new Error("Fixture does not distinguish transform order");
}Quand la même capture d'écran pourrait signifier un autre bug
| Symptôme | Test pour distinguer les causes |
|---|---|
| Changements de position avec le mouvement de la caméra | Vérifier les transformations et les valeurs transmises par rapport à un point connu |
| L'objet disparaît d'un côté | Inspecter l’ordre des sommets/l'culling et visualiser l'orientation |
| Position correcte mais mauvaise occlusion | Inspecter le buffer de profondeur, l'effacement et l'état de comparaison |
| Une texture semble étirée ou inversée | Inspecter les UV, l'orientation de l'image et les données de l'échantillonneur |
| Seuls les écrans haute densité diffèrent | Comparez la taille du tampon de dessin avec la taille de le viewport et du CSS |
Changez une condition à la fois. La désactivation de l'culling peut révéler la géométrie, mais n'établit pas que sa désactivation constitue la solution finale correcte. Enregistrez l’expérience et son interprétation séparément.
Conservez une scène de régression avec le correctif
Conserver un cas où la translation et la rotation ne commutent pas ; les matrices d'identité masqueraient le bug dans cet exemple. Ajoutez un mouvement de caméra normal et une géométrie représentative une fois le cas minimal passé. Comparez la même révision de scène et notez tout artefact restant comme un problème distinct.
FAQ
Une capture d'écran peut-elle identifier la cause exacte ?
Habituellement, il fournit un symptôme et une localisation. Le code, l’état et la reproduction distinguent des causes concurrentes.
Un shader compilé prouve-t-il que les calculs sont corrects ?
Non. Des expressions valides peuvent appliquer des transformations dans le mauvais ordre.
Dois-je essayer tous les correctifs suggérés en même temps ?
Utilisez une hypothèse et testez à la fois afin que le résultat ait une cause interprétable.
La vérification JavaScript vérifie-t-elle la sortie GPU ?
Il vérifie l'arithmétique indiquée. Le rendu et la validation de l’état hôte sont des étapes distinctes.
Le modèle doit-il recevoir l'intégralité du référentiel ?
Commencez par la scène et l’état pertinent nécessaires pour reproduire l’inadéquation. Ajoutez des dépendances lorsqu'une hypothèse l'exige.
Qu'est-ce qui appartient à l'enregistrement final du bug ?
Révision, entrées, comportement attendu et observé, expérience, correctif accepté, contrôles de régression et incertitude restante.
Sources
- Khronos : transformation de sommet : étapes de coordonnées.
- MDN : variables uniform matricielles : exigences de transmission des matrices WebGL.
