Naissance d'un shader - étape 3 : transcription en code des maths.
Dimanche 19 octobre 2008 à 14 h 11
Un moteur de rendu programmable intégre de base tout ce qu'il faut : calculs vectoriels, conditions, toute les functions d'un math.h, plus des choses déjà encodées pour des fonctions "normales" d'un moteur de rendu : boucle d'illuminances, corrections couleurs, calcul d'angle de reflection/refraction(qu'on utilisera pas ici par soucis d'optimisation), raytracing, ...
Dans le cas qui nous interesse, la transcription est relativement rapide. La premiere étape fut le developpement de procedures de resolution d'équations du 3ème degré (qui servira lors de la resolution des chemins de la lumiere dans le poil - pour le TT et le TRT).
Ca peut paraitre tout bete, mais on est justement pas en c++ : il faut recoder l'ensemble, et donc impossible de piquer directement le code d'un site ou l'autre. C'est en fait plus rapide de partir des equations de base qu'un code déjà tapé :)
La 2ème étape, et l'une des plus longues, est de savoir ce qui nous est disponible dans le moteur et quel sont leurs equivalents dans les formules.
En 3d, un cheveux, c'est une courbe. L'epaisseur n'est finallement qu'une sorte de "cheat". Pas grave, les formules estiment que le poil n'a pas d'épaisseur. Mais nous avons le plus important : le vecteur tangent du poil, et sa direction (racine vers pointe). Reste le vecteur de vue (camera), et le vecteur de la lampe. Deux des choses disponibles "de base".
Il faut néamoins vérifier que les directions sont correctes. Dans ce cas-ci, entre renderman et le papier de marschner, tout était exactement inversé (X = -X, Y=-Y, Z=-Z, vecteur de light = -vecteur de light,...). Ce qui au final donnera le meme resultat, mais par soucis de simplification du debogage, il a fallu vérifier notre répère spatial, et que toutes les operations trigonométriques donnaient le resultat voulu - c'est à dire celui du papier. Une réinversion totale sera faite à la fin quand tout sera debogé.
Pas très complexe en théorie, mais très long en pratique car cette étape se doit de fonctionner parfaitement de A à Z, il faut donc vérifier chaque petite composante :
1. - lampe et camera à 90° du poil, racine en bas : angle de reflection correct ? angle incident correct ?
D'abord calculer le resultat qu'on doit avoir, le vérifier en 3d. C'est bon, on continue.
2. camera rasante au poil, lampe à 90° du poil, racine en bas : angle de reflection correct ? angle incident correct ?
- Oui, etape 3, non, retour à l'étape 1.
Bon, vous pouvez devinez tout les cas et le nombre d'étapes de verifications :) Il faut vérifier quand la camera et la lampe sont de part et d'autre du poil,...
En sauter est possible, mais pas une bonne idée : se rendre compte au dernier moment qu'un cas est incorrect remet en cause tout le travail effectué depuis le debut.
Une fois sûrs de nos vecteurs, on peut se lancer dans le calcul de la premiere (et plus simple) composante du poil : la reflection (R).
Si la première verification est bonne, cette étape est assez rapide : corriger un - oublié par ici, une racine mal mise entre () par là,...
Il faut non seulement calculer l'angle de reflection en tenant compte de la deflection des ecailles, mais surtout la quantité de lumiere qui va etre réflechie (le reste ira dans le TT et TRT).
On peut donc résumé le calcul final à :
prendre le nombre de lampe
pour chaque lampe :
illumination totale = illumination totale + (Reflection * Quantité de reflection + Refraction * Quantité de refraction + subscattering * Quantité de subscatter) * intensité de la lampe.
ou
Ci += (NR*MR+NTT*MTT+NTRT+MTRT)*Cl
NR, MR, MTT et MTRT ont étés effectivement rapides.
NTT fut le premier à utiliser le resolveur d'équation débuggé à part et fut rapide egalement..
Le NTRT sera pour le prochain article :)
Dans le cas qui nous interesse, la transcription est relativement rapide. La premiere étape fut le developpement de procedures de resolution d'équations du 3ème degré (qui servira lors de la resolution des chemins de la lumiere dans le poil - pour le TT et le TRT).
Ca peut paraitre tout bete, mais on est justement pas en c++ : il faut recoder l'ensemble, et donc impossible de piquer directement le code d'un site ou l'autre. C'est en fait plus rapide de partir des equations de base qu'un code déjà tapé :)
La 2ème étape, et l'une des plus longues, est de savoir ce qui nous est disponible dans le moteur et quel sont leurs equivalents dans les formules.
En 3d, un cheveux, c'est une courbe. L'epaisseur n'est finallement qu'une sorte de "cheat". Pas grave, les formules estiment que le poil n'a pas d'épaisseur. Mais nous avons le plus important : le vecteur tangent du poil, et sa direction (racine vers pointe). Reste le vecteur de vue (camera), et le vecteur de la lampe. Deux des choses disponibles "de base".
Il faut néamoins vérifier que les directions sont correctes. Dans ce cas-ci, entre renderman et le papier de marschner, tout était exactement inversé (X = -X, Y=-Y, Z=-Z, vecteur de light = -vecteur de light,...). Ce qui au final donnera le meme resultat, mais par soucis de simplification du debogage, il a fallu vérifier notre répère spatial, et que toutes les operations trigonométriques donnaient le resultat voulu - c'est à dire celui du papier. Une réinversion totale sera faite à la fin quand tout sera debogé.
Pas très complexe en théorie, mais très long en pratique car cette étape se doit de fonctionner parfaitement de A à Z, il faut donc vérifier chaque petite composante :
1. - lampe et camera à 90° du poil, racine en bas : angle de reflection correct ? angle incident correct ?
D'abord calculer le resultat qu'on doit avoir, le vérifier en 3d. C'est bon, on continue.
2. camera rasante au poil, lampe à 90° du poil, racine en bas : angle de reflection correct ? angle incident correct ?
- Oui, etape 3, non, retour à l'étape 1.
Bon, vous pouvez devinez tout les cas et le nombre d'étapes de verifications :) Il faut vérifier quand la camera et la lampe sont de part et d'autre du poil,...
En sauter est possible, mais pas une bonne idée : se rendre compte au dernier moment qu'un cas est incorrect remet en cause tout le travail effectué depuis le debut.
Une fois sûrs de nos vecteurs, on peut se lancer dans le calcul de la premiere (et plus simple) composante du poil : la reflection (R).
Si la première verification est bonne, cette étape est assez rapide : corriger un - oublié par ici, une racine mal mise entre () par là,...
Il faut non seulement calculer l'angle de reflection en tenant compte de la deflection des ecailles, mais surtout la quantité de lumiere qui va etre réflechie (le reste ira dans le TT et TRT).
On peut donc résumé le calcul final à :
prendre le nombre de lampe
pour chaque lampe :
illumination totale = illumination totale + (Reflection * Quantité de reflection + Refraction * Quantité de refraction + subscattering * Quantité de subscatter) * intensité de la lampe.
ou
Ci += (NR*MR+NTT*MTT+NTRT+MTRT)*Cl
NR, MR, MTT et MTRT ont étés effectivement rapides.
NTT fut le premier à utiliser le resolveur d'équation débuggé à part et fut rapide egalement..
Le NTRT sera pour le prochain article :)
Dans ce genre de travail, le problème que je rencontre souvent est la difficulté de vérification des maths. Un test sur papier n'est pas toujours super fiable à cause de potentielles étourderies, en plus d'être souvent très long.
Peux tu détailler un peu ta méthode de débuggage ? Vous faites 4 ou 5 tests sur papiers puis vous comparez à l'implémentation informatique, corrigeant les étourderies de l'implémentation comme celles des tests papiers ?
Combien de temps passez vous sur la vérification comparé à l'implémentation ?
Et oui : on fait la verif sur papier, sur pc, on compare. Y a pas d'autres solutions malheureusement. Bon evidemment au bout de quelques fois tu as plus trop besoin de calculer pour voir si le resultat est bon ou pas..
Malheureusement, les erreurs d'étourderies sont evidentes à corriger, ce qui prend le plus de temps, ce sont des problèmes d'implentation : du style on voudrait la normale du poil mais on l'a pas, donc faut d'abord trouver une methode vectorielle pour la déduire correctement. Se rendre compte que ça marche pas, tenter une autre approche de vérification,..
En tout cas le rapport temps de codage / temps de debuggage de 6x... En général pour un shader, je planifie 2 ou 3x, et me retrouve toujours à exploser mon calendrier malgré tout. Peut être que je vais suivre ta méthode maintenant et prévoir 6 fois plus de temps au débuggage qu'à l'implémentation.
Très intéressante série de billet, j'attends le prochain avec impatience !