Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2022-05-15T23:00:53+02:00Les derniers messages parus sur le forum de Zeste de Savoir.Variables constantes dans un langage de shader, message #2429752022-05-15T23:00:53+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242975<p>Je précise un truc qui n’est pas clair dans mon message précédent : si ton but c’est de faire un langage pour apprendre à faire un langage (après tout tu n’a pas donné le contexte de cette question), prends ce qui te parait le mieux ou ce qui te simplifie la vie.</p>Variables constantes dans un langage de shader, message #2429712022-05-15T22:33:13+02:00kbz_8/@kbz_8https://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242971<p>D’accord, je vais réfléchir plus profondément à ce qu’implique chaque solution (à noter que je compte aussi implémenter des <code>constval</code> pour faire comme les <code>constexpr</code> du c++ avec des variables et des conditions). Merci pour tous vos avis et vos conseils en tout cas <img src="/static/smileys/svg/heureux.svg" alt=":D" class="smiley"></p>Variables constantes dans un langage de shader, message #2429642022-05-15T20:17:23+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242964<p>Il y a aussi la solution qui consiste à toujours déclarer explicitement la mutabilité, que la variable soit mutable ou non. Comme en Kotlin (<code>var</code>/<code>val</code> – oui, les opérateurs ont presque le même nom), en Swift (<code>var</code>/<code>let</code>) ou en JS moderne (<code>let</code>/<code>const</code> – on notera que <code>let</code> est une variable en JS mais une constante en Swift…).</p>
<p>À noter que, selon le langage, ça ne résous pas le problème de la distinction entre « variable immutable » et « constante connue et résolue par le compilateur » – qui sont deux choses très différentes – ni entre – « variable immutable y compris son contenu (variable immutable qui contient une structure immutable) » et « variable immutable au contenu mutable », un autre grand classique des incompréhensions de ce qu’est une variable immutable, et très important pour les performances et les problèmes de parallélisation.</p>
<p>Ça c’est dans le cas générique.</p>
<p>Dans le cas spécifique des langages de shader, c’est un contexte d’exécution avec des contraintes très spécifiques. Donc si le but est d’écrire un langage de shader, il faudrait s’assurer de bien comprendre ces contraintes et ce qu’elles impliquent sur la programmation, tant d’un point de vue technique (je pense aux performances, c’est des domaines où c’est souvent primordial) que d’un point de vue « utilisateur final » – les développeurs qui vont devoir utiliser le langage dans la réalité.</p>
<p>C’est très important (et hélas très compliqué) d’avoir les deux connaissances pour faire un langage efficace et que tu ne sois pas le seul à utiliser ; et honnêtement je ne pense pas que le code existant t’aide beaucoup à ce sujet. Notamment parce que les contraintes des langages existants impactent énormément leur usage. Par exemple en Java, les variables sont mutables par défaut, ce qui conduit à beaucoup de réutilisation non nécessaire de variables, qui sont donc réutilisées (avec une réaffectation dans le code) sans raison valable – pas exemple à cause de croyances sur les optimisations faites par le compilateur ou l’interpréteur.</p>
<p>Un exemple dans la vraie vie : dans les langages qui tournent sur la JVM et compatibles avec des bibliothèques Java, on trouve entre autres Scala et Kotlin. Scala est beaucoup plus « propre » selon la théorie des langages, mais sa lenteur atroce de compilation (partiellement corrigée) et sa syntaxe parfois difficile à lire font qu’il est sensiblement moins utilisé que Kotlin, un langage pensé par des développeurs, pour des développeurs, pour être le plus efficace possible dans leur contexte.</p>
<p>En résumé : sur ce point de détail, c’est pas très important et tu peux t’en sortir en bottant en touche (tout déclarer explicitement). Mais d’une façon générale, pour bien concevoir un langage qui ne soit pas un pur produit de recherche ou de développement, tu vas avoir besoin de beaucoup de connaissances sur l’utilisation souhaitée et sur les contraintes techniques d’exécution.</p>Variables constantes dans un langage de shader, message #2429612022-05-15T19:50:43+02:00Taurre/@Taurrehttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242961<p>Salut,</p>
<p>Le C n’est probablement pas un bon exemple de ce côté, parce que le mot clé <code>const</code> et sa sémantique sont assez peu utiles (pour ne pas dire inutile <img src="/static/smileys/svg/siffle.svg" alt=":-°" class="smiley"> ). Dans les faits, il est sous utilisé (parce que c’est chiant à employer, honnêtement).</p>
<p>Pour le reste, je dirai que ça dépend de ce que tu veux faire. Le choix de Rust est pertinent au vu du modèle qu’ils ont choisis, mais n’est pas un absolu. Le choix de Rust se base entre autres sur la problématique de la programmation concurrente (c’est plus facile d’avoir des garanties fortes si la plupart des variables sont immutables puisque cela élimine la possibilité qu’une variable soit par exemple modifiée par un <em>thread</em> pendant qu’un autre est en train de lire sa valeur). Maintenant, Go s’en sort aussi très bien sans pour autant avoir fait ce choix (avec un modèle et un contexte différent, on est bien d’accord, mais tout de même).</p>Variables constantes dans un langage de shader, message #2429602022-05-15T19:27:48+02:00ache/@achehttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242960<p>Effectivement je répondai dans le cas général. Pas du tout dans le cas particulier des langages de shader que je ne connais pas du tout.</p>Variables constantes dans un langage de shader, message #2429582022-05-15T17:42:24+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242958<blockquote>
<p>Cette stratégie sera probablement biaisée par le fait que la plupart des langages de shaders existants ont des variables modifiables par défaut et donc que le style d’écriture avec ces langages s’en accommode</p>
</blockquote>
<p>Biaisée en faveur du style de programmation employé par les êtres humains qui seront le plus certainement à même d’utiliser notre travail. Ce qui revient à aller dans leur sens plutôt qu’à les mépriser en leur imposant la façon dont ils <em>devraient penser</em> en exerçant un métier qui nous est étranger.</p>
<p>En l’absence de toute expertise sur le sujet qui me permettrait de me faire un avis et une opinion tranchés, j’assume totalement cette position et j’accueille ce biais à bras ouvert, comme celui qui maximise les chances d’avoir des utilisateurs tout court.</p>Variables constantes dans un langage de shader, message #2429572022-05-15T17:14:12+02:00adri1/@adri1https://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242957<p>Cette stratégie sera probablement biaisée par le fait que la plupart des langages de shaders existants ont des variables modifiables par défaut et donc que le style d’écriture avec ces langages s’en accommode. Peut être que ce choix est pertinent pour des shaders, peut être que c’est en fait une mauvaise idée mais qu’on s’en est pas encore rendu compte parce qu’il n’y a pas de langage sur le marché qui rend une approche différente utilisable.</p>
<p>Ce qui est évident, c’est que la mutabilité des variables vient toujours avec son lot de défauts pour raisonner sur le code et en particulier pour le rendre robuste face à la parallélisation (ou autre scénario où l’aliasing peut causer des erreurs de façon extrêmement subtile). D’un autre côté, la mutabilité est essentielle pour les performances lorsqu’on travaille sur de grosses matrices. La question est alors de trouver un modèle mémoire et de mutabilité qui d’une part réduit les risques de se prendre les pieds dans le tapis à cause des effets de bords qui clashent et d’autre part n’affecte pas les perfs. Et là, j’ai envie de dire que c’est pas scrapper les codes existants ni regarder ce que les langages à la mode font qui permettra de répondre de manière tranchée, il faut s’y connaitre à la fois sur les problématique rencontrées dans le monde des shaders et en design de langages.</p>Variables constantes dans un langage de shader, message #2429562022-05-15T16:35:17+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242956<p>Telle que posée, cette question appelle juste les gens à décrire ce qui est fait dans leur langage préféré. Ce qui est totalement subjectif et sujet à la mode et aux avis de personnes pas nécessairement expertes en écriture de shaders, qui sont pourtant probablement ta cible.</p>
<p>À ta place, pour y répondre, je scrapperais le maximum possible de code de shaders que je pourrais trouver, et je regarderais quel est le cas le plus fréquent entre une variable qui reste constante tout le long de sa durée de vie et une variable qui est modifiée pendant sa durée de vie.</p>
<p>Le choix final serait celui qui pousserait à écrire un mot-clef de moins dans le cas le plus fréquemment rencontré.</p>Variables constantes dans un langage de shader, message #2429552022-05-15T15:27:15+02:00ache/@achehttps://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242955<p>Il vaut mieux qu’une variable soit immuable par défaut. Et donc déclarer une variable muable explicitement comme en Rust.</p>
<p>Pour les constantes, c’est toujours bien de le mettre malheureusement peu de langage font la distinction entre constante (à la compilation) et à l’exécution (variable immuable).</p>Variables constantes dans un langage de shader, message #2429542022-05-15T15:03:29+02:00kbz_8/@kbz_8https://zestedesavoir.com/forums/sujet/16266/variables-constantes-dans-un-langage-de-shader/?page=1#p242954<p>Bonjour,
Je voudrais votre avis sur une question. Vaut il mieux devoir déclarer explicitement qu’une variable est constante (comme en C) ou devoir déclarer explicitement qu’elle est mutable (comme en Rust) ?</p>Langage de Shader POO, message #2414732022-03-12T12:54:01+01:00kbz_8/@kbz_8https://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241473<figure><blockquote>
<p>J’ai un peu de mal à imaginer ce que ça donnerait, tu pourrais illustrer par un exemple ?</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241221">Zephyr</a></figcaption></figure>
<p>J’avais comme idée quelque chose dans ce style</p>
<div class="hljs-code-div hljs-code-kotlin"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span><span data-count="7"></span><span data-count="8"></span><span data-count="9"></span><span data-count="10"></span><span data-count="11"></span><span data-count="12"></span><span data-count="13"></span><span data-count="14"></span><span data-count="15"></span><span data-count="16"></span><span data-count="17"></span><span data-count="18"></span><span data-count="19"></span><span data-count="20"></span><span data-count="21"></span><span data-count="22"></span><span data-count="23"></span><span data-count="24"></span><span data-count="25"></span><span data-count="26"></span><span data-count="27"></span><span data-count="28"></span><span data-count="29"></span><span data-count="30"></span><span data-count="31"></span><span data-count="32"></span><span data-count="33"></span><span data-count="34"></span><span data-count="35"></span><span data-count="36"></span><span data-count="37"></span><span data-count="38"></span><span data-count="39"></span><span data-count="40"></span><span data-count="41"></span><span data-count="42"></span><span data-count="43"></span><span data-count="44"></span><span data-count="45"></span><span data-count="46"></span><span data-count="47"></span></div><pre><code class="hljs language-kotlin"><span class="hljs-comment">// Global part</span>
<span class="hljs-keyword">var</span> pos: vec3 = location(<span class="hljs-number">0</span>); <span class="hljs-comment">// location is equivalent to layout in GLSL</span>
<span class="hljs-keyword">var</span> color: vec4 = location(<span class="hljs-number">1</span>);
<span class="hljs-meta">@entry</span> vert <span class="hljs-comment">// vertex shader</span>
uniform <span class="hljs-keyword">var</span> view: mat4;
uniform <span class="hljs-keyword">var</span> proj: mat4;
uniform <span class="hljs-keyword">var</span> model: mat4;
fn main() -> vec4
{
pos = vec3(model * vec4(pos, <span class="hljs-number">1.0</span>));
<span class="hljs-keyword">return</span> proj * view * vec4(pos, <span class="hljs-number">1.0</span>);
}
<span class="hljs-meta">@entry</span> frag <span class="hljs-comment">// fragment shader</span>
<span class="hljs-class"><span class="hljs-keyword">class</span> <span class="hljs-title">Light</span></span>
{
<span class="hljs-keyword">public</span>:
fn Light(<span class="hljs-keyword">var</span> pos: vec3, <span class="hljs-keyword">var</span> color: vec3, <span class="hljs-keyword">var</span> radius: float) -> Light
{
_pos = pos;
_color = color;
_radius = radius;
}
mtd get_result() -> vec3
{
<span class="hljs-comment">/* Some lights calculations */</span>
<span class="hljs-keyword">return</span> light;
}
<span class="hljs-keyword">private</span>:
<span class="hljs-keyword">var</span> _pos: vec3;
<span class="hljs-keyword">var</span> _color: vec3;
<span class="hljs-keyword">var</span> _radius: float;
}
fn main() -> vec4
{
obj light = Light((<span class="hljs-number">0</span>, <span class="hljs-number">10</span>, <span class="hljs-number">5</span>), (<span class="hljs-number">255</span>, <span class="hljs-number">255</span>, <span class="hljs-number">255</span>), <span class="hljs-number">15.7</span>);
<span class="hljs-keyword">var</span> frag_color: vec4 = color * vec4(light.get_result(), <span class="hljs-number">1.0</span>);
<span class="hljs-keyword">return</span> frag_color;
}
</code></pre></div>
<p>L’orienté objet dans ce cas-ci n’a pas grand intérêt mais cela peut en avoir dans d’autres situations</p>Langage de Shader POO, message #2412212022-02-25T23:25:39+01:00Zephyr/@Zephyrhttps://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241221<p>J’ai un peu de mal à imaginer ce que ça donnerait, tu pourrais illustrer par un exemple ?</p>Langage de Shader POO, message #2411852022-02-24T00:44:17+01:00adri1/@adri1https://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241185<p>Salut,</p>
<p><a href="https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/gator-oop/">Ça existe déjà</a>, même si en l’occurrence ce projet n’a pas l’air très actif.</p>
<blockquote>
<p>Et un des soucis que je pense qui risque de se produire, c’est que la POO n’est pas très optimisée pour les gros calculs à faire rapidement, donc le langage devrait convertir les process objets en process fonctionnels, pour correspondre au modèle de calcul des GPU.</p>
</blockquote>
<p>Cet argument me parait plutôt faible. Le niveau d’abstraction que permet de manipuler un langage donné ne détermine pas les performances au runtime. Les performances sont une question d’écrire un compilateur (que ce soit vers le langage machine, du bytecode pour une VM, ou un autre langage) qui optimise correctement en passant du niveau d’abstraction du langage à celui de la cible. Dit autrement, choisir un langage OO est une question de design du langage alors que les performances sont une question d’implémentation. Certes, on sait mieux optimiser certains paradigmes que d’autres, mais en l’occurrence avoir un langage OO qui soit rapide au runtime, on sait faire. C++ est l’exemple évident ; Rust peut aussi se qualifier selon la définition d’OO sur laquelle on s’accorde. Clairement, on ne peut donc pas dire que "la POO n’est pas optimisée pour les gros calculs".</p>Langage de Shader POO, message #2411842022-02-24T00:00:31+01:00kbz_8/@kbz_8https://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241184<figure><blockquote>
<p>Je pense que ça risque de poser des problèmes d’interopérabilité, la plupart des langages existants ne fonctionnent que pour une plateforme donnée.</p>
<p>Ou alors il faudrait que ce soit un langage transpilé, pour bénéficier du support hardware des autres langages.</p>
<p>Et un des soucis que je pense qui risque de se produire, c’est que la POO n’est pas très optimisée pour les gros calculs à faire rapidement, donc le langage devrait convertir les process objets en process fonctionnels, pour correspondre au modèle de calcul des GPU.</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241180">amael</a></figcaption></figure>
<p>Ouais donc ça poserait plus de soucis que ça n’apporterait de choses utiles.</p>Langage de Shader POO, message #2411802022-02-23T22:10:29+01:00amael/@amaelhttps://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241180<p>Je pense que ça risque de poser des problèmes d’interopérabilité, la plupart des langages existants ne fonctionnent que pour une plateforme donnée.</p>
<p>Ou alors il faudrait que ce soit un langage transpilé, pour bénéficier du support hardware des autres langages.</p>
<p>Et un des soucis que je pense qui risque de se produire, c’est que la POO n’est pas très optimisée pour les gros calculs à faire rapidement, donc le langage devrait convertir les process objets en process fonctionnels, pour correspondre au modèle de calcul des GPU.</p>Langage de Shader POO, message #2411732022-02-23T17:40:17+01:00kbz_8/@kbz_8https://zestedesavoir.com/forums/sujet/16082/langage-de-shader-poo/?page=1#p241173<p>Bonsoir.
Je n’ai pas vraiment besoin d’aide, j’aurais juste besoin d’avis sur une question.
Que pensez-vous d’un langage de shaders orienté objet ? Pensez-vous que ça serait une bonne chose ou que cela serait plutôt inutile ?</p>[Shading] Ombrage de Gouraud, message #1368112016-12-28T16:10:04+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/7652/shading-ombrage-de-gouraud/?page=1#p136811<p>Désolé pour les titres !</p>
<p>Je n’avais pas du tout l’impression de confondre des notions (juste de rentrer dans les détails), mais je vais lire attentivement les tutos <img alt=";)" src="/static/smileys/clin.png"> !</p>
<p>Edit :</p>
<p>Heum je ne pense pas que des tutos sur OpenGL puissent me servir, je m’intéresse surtout à l’aspect théorique des ombrages (comment ils sont effectués, la terminologie utilisée, etc.). Et de telles ressources ne courent pas les rues sur Internet, c’est pour ça que j’ai créé ce topic en fait <img alt=":ange:" src="/static/smileys/ange.png"></p>[Shading] Ombrage de Gouraud, message #1368092016-12-28T15:48:11+01:00Glordim/@Glordimhttps://zestedesavoir.com/forums/sujet/7652/shading-ombrage-de-gouraud/?page=1#p136809<p>Perso j’ai banni le h1 de mes posts, à mes yeux ça convient plus à un tuto ou un article. Dans le fofo on devrait commencer au h2.<br>
Bref on discutera de ça ailleurs. <img alt="^^" src="/static/smileys/hihi.png"></p>[Shading] Ombrage de Gouraud, message #1368062016-12-28T15:39:16+01:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/7652/shading-ombrage-de-gouraud/?page=1#p136806<figure>
<blockquote>
<p><strong>Ps:</strong> Évite les gros titres en orange, à la limite mets juste ta question en gras ça sera plus digeste. <img alt=">_<" src="/static/smileys/pinch.png"></p>
</blockquote>
<figcaption><a href="https://zestedesavoir.com/forums/sujet/7652/shading-ombrage-de-gouraud/?page=1#p136802">Glordim</a></figcaption>
</figure>
<p>C’est le rendu par défaut des titres générés avec le Markdown, en fait. Si c’est gênant, il faudrait en parler sur le forum des bugs et suggestions.</p>[Shading] Ombrage de Gouraud, message #1368022016-12-28T15:31:43+01:00Glordim/@Glordimhttps://zestedesavoir.com/forums/sujet/7652/shading-ombrage-de-gouraud/?page=1#p136802<blockquote>
<p>Si la carte graphique est sollicitée, est-ce que la triangulation a lieu ? (autrement dit : la triangulation est-elle systématiquement réalisée) ?</p>
</blockquote>
<p>La carte graphique ne travaille qu’avec des triangles et on lui passe ces infos via des API comme OpenGL. Dans les premières versions d’OpenGL je crois qu’on pouvait lui passer des Quad et c’est l’API qui se chargeait en interne de passer ça en triangle. Mais aujourd’hui OpenGL a empreinté une voie beaucoup plus bas niveau. Donc il faut lui passer des triangles ou faire le triangulate soit même.</p>
<p><strong>Ps:</strong> Si on exporte un modèle 3D d’un logiciel comme Maya ou Blender il sera automatique triangulate à se moment là (en Fbx ou Obj par exemple). Donc on se prend rarement la tete avec ça.</p>
<blockquote>
<p>Dire qu’une normale possède une couleur signifie la même chose que dire que le pixel situé à l’origine de cette normale possède cette même couleur. Mais c’est un abus de langage.</p>
</blockquote>
<p>Je ne rappel pas avoir dis ca, ou alors je me suis mal exprimer. C’est le vertex qui possèdes une normale et une couleur (en plus de sa position). Les vertices c’est la base de tout en 3D.</p>
<p>(tu verras surement plus tard que c’est aussi lui qui possèdes les coordonnées UV pour la plaquage de texture)</p>
<hr>
<p>Pour le reste de tes questions je pense qu’un bon tuto t’expliquera tout ça mieux que moi.<br>
Mais je te conseil quand même de commencer par quelque chose de plus simple, ça te permettra de poser de bonnes bases en 3D. J’ai l’impression que tu parles de tout ça de manière très théorique et on sent pas mal de confusion dans tes questions.</p>
<p>Un peu pratique ne ferait pas de mal :</p>
<ul>
<li>Bon tuto sur OpenGL en anglais : <a href="https://learnopengl.com/">lien</a> </li>
<li>Autre tuto en Francais : <a href="http://www.opengl-tutorial.org/fr/beginners-tutorials/">lien</a></li>
</ul>
<p>Bon courage ! <img alt=";)" src="/static/smileys/clin.png"></p>
<p><strong>Ps:</strong> Évite les gros titres en orange, ça sera plus digeste. <img alt=">_<" src="/static/smileys/pinch.png"></p>[Shading] Ombrage de Gouraud, message #1367942016-12-28T14:50:11+01:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/7652/shading-ombrage-de-gouraud/?page=1#p136794<p>Salut, merci d’avoir répondu !</p>
<p>J’ai quelques questions sur tes explications du coup <img alt=":p" src="/static/smileys/langue.png"></p>
<h3>Question 5. Au sujet de la triangulation…</h3>
<p>Si la carte graphique est sollicitée, est-ce que la triangulation a lieu ? (autrement dit : la triangulation est-elle systématiquement réalisée) ?</p>
<h3>Question 6. Normale et couleur</h3>
<p>Dire qu’une normale possède une couleur signifie la même chose que dire que le pixel situé à l’origine de cette normale possède cette même couleur. Mais c’est un abus de langage.</p>
<h3>Au sujet de l’Ombrage Plat, de l’Ombrage de Gouraud et de l’Ombrage de Phong</h3>
<p>Les affirmations suivantes sont-elles correctes ?</p>
<h4>Question 7. Interpolation ou non ?</h4>
<p>Gouraud et Phong utilisent l’interpolation. Flat n’utilise pas d’interpolation.</p>
<h4>Question 8. Utilisation ou non des normales ?</h4>
<ol>
<li>
<p>Le Flat Shading utilise la normale de la surface du polygone ainsi que des couleurs (celle de la source de lumière et celle de la normale de la surface du polygone) ;</p>
</li>
<li>
<p>Le Gouraud Shading n’utilise pas de normale, mais uniquement des couleurs (celle de chaque sommet du polygone et celle de chaque intersection "scanline - côté du polygone") ;</p>
</li>
<li>
<p>Le Phong Shading interpole des normales (celle de chaque pixel du polygone) et utilise des couleurs.</p>
</li>
</ol>
<h4>Fonctionnement de ces trois ombrages</h4>
<h5>Question 9. Flat Shading</h5>
<p>Aucun sommet du polygone n’est utilisé pour calculer les couleurs (contrairement à Gouraud et Phong pour lesquels les trois sommets du triangle sont utilisés).</p>
<p>L’angle entre la normale de la surface du polygone et la direction de la source de lumière, ainsi que la couleur de la lumière et celle de l’objet sont utilisés pour calculer une même couleur (= luminosité) qui sera assignée à CHAQUE pixel du polygone.</p>
<p>Un polygone éclairé grâce à l’Ombrage Plat sera donc d’une seule et même couleur.</p>
<p>Remarque : "Flat shading computes lighting values <strong>for one vertex</strong> per polygon and uses the resulting color for the entire polygon,
resulting in a single flat color for every polygon" (<a href="https://www.opengl.org/discussion_boards/showthread.php/185547-Difference-between-Gouraud-and-Phong-Shading">Source</a>) : ici, on parle bien de "vertex", c’est-à-dire de "sommet"… <strong>Le gars qui dit ça se trompe non ?</strong></p>
<h4>Question 10. Gouraud Shading</h4>
<blockquote>
<p>Gouraud Shading : Applique la lumière par pixel mais en utilisant cette fameuse ScanLine.</p>
</blockquote>
<p>Heum… tous les pixels de la scanline sont-ils (horizontalement évidemment) parcourus pour être colorié un à un, d’une couleur qui peut tout à fait être différente (valeur d’interpolation horizontale légèrement différente) ?</p>
<p>De plus, cette scanline commence-t-elle vraiment au centre (verticalement parlant) du polygone, comme sur la vidéo que j’ai montrée dans l’OP ? Ou bien commence-t-elle tout en haut du polygone, pour descendre petit à petit jusqu’au bas de ce dernier (la valeur d’interpolation verticale est donc différente plus on descend) ?</p>
<p>En résumé : ce qui me pose problème dans la vidéo que j’ai postée, c’est qu’on considère SEULEMENT la scanline AU CENTRE VERTICAL du polygone, et qu’on considère SEULEMENT le CENTRE HORIZONTAL de cette scanline.<strong> Du coup dans la vidéo, on ne colorie qu’un seul point : celui du centre du polygone. C’est très bizarre puisque chaque pixel du polygone est colorié.</strong></p>
<h4>Question 11. Phong Shading.</h4>
<p>La luminosité du polygone est calculée à chaque pixel.</p>
<p>Pour chaque sommet :</p>
<ol>
<li>
<p>La normale de la surface du polygone,</p>
</li>
<li>
<p>Le vecteur dont l’origine est le sommet courant, et la destination : la caméra,</p>
</li>
<li>
<p>Et la direction de la lumière…</p>
</li>
</ol>
<p>… sont interpolées sur chaque pixel du polygone.</p>
<h4>Question 12. Différence entre Gouraud et Phong</h4>
<p>Au final, ces deux algorithmes colorent chaque pixel du polygone un à un.</p>
<p>Pourtant quand on fait des recherches sur Google, on trouve souvent des phrases du genre "Contrairement à Gouraud, Phong calcule la luminosité de chaque pixel".</p>
<p>Du coup il y a contradiction, et je suis un peu perdu…</p>