FR first 3 chapters + 1 note

pull/61/head
nicolas barradeau 8 years ago
parent 2bf83cb714
commit 42126a1ab2

2
.gitignore vendored

@ -1,3 +1,4 @@
/src
.DS_Store
.dropbox
tmp.md
@ -5,3 +6,4 @@ tmp*.png
book.tex
book.pdf
log/*
/.idea

@ -1,48 +1,60 @@
# Introduction
# Introduction
<canvas id="custom" class="canvas" data-fragment-url="cmyk-halftone.frag" data-textures="vangogh.jpg" width="700px" height="320px"></canvas>
Les images au-dessus ont été faites de différentes manières. La première a été peinte à la main par Van Gogh, couche après couche. Cela lui a pris des heures. La deuxième a été produite en quelques secondes par la combinaison de quatre matrices de pixels: une pour le cyan, une pour le magenta, une pour le jaune et une pour le noir. La principale différence est que la seconde image n'a pas été produite de manière sérielle (c'est-à-dire non étape par étape, mais tout en même temps).
les images ci-dessus onté été crées de différentes manières.
La première est un tableau de Van Gogh, réalisée en appliquant des couches de peinture successives.
ça lui a pris des jours, voire des semaines.
La seconde est réalisée en temps réel en combinant 4 matrices de pixels ; une pour le cyan, une pour le magenta, une pour le jaune et une pour le noir.
La différence principale entre ces deux images (hormis le medium), est que la seconde n'est pas sérielle ; elle n'est pas créée par étapes successives mais d'un bloc grâce à un shader.
Ce livre traite de la technique informatique révolutionnaire, les *fragment shaders*, qui élargissent les possibilités de la génération d'images numériques. Vous pouvez le voir comme l'équivalent de la naissance de l'imprimerie par Gutenberg, mais pour la fabrication d'image.
Ce livre parle d'une technique, les *shaders*, qui permet à l'imagerie numérique de s'affranchir de la plupart des contraintes.
On peut comparer l'avènement des *shaders* à l'avancée qu'a représenté la presse de Guntenberg à son époque.
![Gutenberg's press](gutenpress.jpg)
![la presse de Gutenberg](gutenpress.jpg)
Les fragment shaders vous donnent un contrôle total sur les pixels générés à l'écran et ceci à une très grande vitesse. C'est pourquoi ils sont utilisés dans toutes sortes de cas, depuis les filtres vidéos sur téléphone aux époustouflants jeux vidéos en 3D.
Les shaders donnent un contrôle total sur les pixels de l'écran à une vitesse très élevée.
c'est pourquoi ils sont utilisés dans une grande variété de domaines allant des filtres photo et vidéo, aux téléphones mobiles jusqu'aux jeux vidéos 3D.
![Journey by That Game Company](journey.jpg)
![Journey par That Game Company](journey.jpg)
Dans les chapitres suivants, vous allez découvrir à quel point cette technique est incroyablement rapide et puissante et comment l'appliquer à votre travail personnel et professionnel.
Au fil des chapitres, vous découvrirez combien les shaders sont efficaces et comment vous pourrez vous en servir pour vos projets personnels et/ou professionnels.
## A qui s'adresse ce livre?
## à qui s'adresse ce livre?
Ce livre est écrit pour les codeurs créatifs, les développeurs de jeux et ingénieurs qui ont une expérience de la programmation, des connaissances de base en algèbre linéaire et en trigonométrie, et qui veulent pousser leur travail afin d'atteindre un niveau de qualité graphique encore plus palpitant. (Si vous voulez apprendre à programmer, je vous recommande vivement de commencer avec [Processing](https://processing.org/) et de revenir plus tard lorsque vous vous sentirez à l'aise avec la programmation.)
Ce livre est écrit pour les *creative coders*, les développeurs de jeux, les ingénieurs et les curieux ayant un bagage de code, des connaissances basiques en algèbre linéaire et en trigonométrie et désireux d'améliorer la qualité graphique de leurs productions.
Si vous n'avez aucune connaissance en code, nous vous recommandons chaudement de commencer par [Processing](https://processing.org/) puis de revenir à ce livre lorsque vous vous sentirez plus à l'aise.
Ce livre va vous apprendre comment utiliser et intégrer les shaders dans vos projets, en améliorant leur performance et leur qualité graphique. Parce que les shaders GLSL (OpenGL Shading Language) compilent et s'exécutent sur un grand nombre de plateformes, vous serez à même de déployer vos connaissances sur des sketches [Processing](https://processing.org/), des applications [openFrameworks](http://openframeworks.cc/), des installations interactives [Cinder](http://libcinder.org/), des sites avec [Three.js](http://threejs.org/) ou des jeux sous iOS/Android.
Ce livre vous montrera comment utiliser et intégrer des shaders dans vos projets, comment améliorer leurs performances et leur rendu graphique.
Du fait que les shaders GLSL (OpenGL Shading Language) peuvent être compilés sur diverses plateformes, il vous sera possible de réutiliser ce que vous aurez appris ici dans n'importe quel environnement utilisant OpenGL, OpenGL ES ou WebGL. Autrement dit, vous pourrez réutiliser vos connaissances sur des plateformes comme [Processing](https://processing.org/), [openFrameworks](http://openframeworks.cc/), [Cinder](http://libcinder.org/), [Three.js](http://threejs.org/) ou iOS et Android.
## De quoi traite ce livre?
## que contient ce livre?
Ce livre se concentrera sur l'utilisation des pixel shaders GLSL. Dans un premier temps, nous définirons ce que sont les shaders; puis nous apprendrons comment, grâce à eux, faire des formes procédurales, des motifs, des textures et des animations. Vous apprendrez les bases du langage des shaders et l'appliquerez à des scénarios plus utiles comme: le traitement d'images (les opérations sur les images, les matrices de convolution, les flous, les filtres de couleur, les tables de correspondances et autres effets) et les simulations (le jeu de la vie imaginé par John H. Conway, le système à réaction-diffusion de Gray-Scott, les ondulations à la surface de l'eau, les effets aquarelle, les diagrammes de Voronoï, etc). A la fin de ce livre, nous verrons un ensemble de techniques avancées basées sur le Ray Marching.
Ce livre se concentre sur l'utilisation des Fragment Shaders.
nous définirons ce que sont les shaders, puis nous apprendrons à dessiner des formes, des textures et des motifs procéduraux (à base d'instructions mathématiques).
nous apprendrons les bases du langage de shading avant de les utiliser sur des cas concrets comme le traitement d'image (transformations, convolution, flou, filtres et autres effets), les simulations (le jeu de la vie de Conway, la réaction diffusion de Gray-Scott, les vaguelettes sur un plan d'eau, les cellules de Voronoi, etc. ), enfin nous aborderons les techniques avancées basées sur le Ray Marching.
*Dans chaque chapitre, des exemples interactifs vous permettront de vous amuser avec les concepts traités. *Lorsque vous modifierez le code, le résultat de ces changements sera visible instantanément. Certains concepts peuvent être abstaits et déroutants, dans ce cas les exemples interactifs sont les bienvenus pour vous aider à comprendre les informations. Le plus vite vous mettrez ces concepts en mouvement, le plus simple sera votre apprentissage.
Ce dont ne traite pas ce livre:
*Chaque chapitre comporte des exemples interactifs, n'hésitez pas à jouer avec!* lorsque vous changez le code des exemples, le shader est recompilé et - s'il est valide - vous verrez le résultat instantanément. Les concepts paraîssent souvent abstraits et peuvent laisser perplexe donc les exemples sont là pour vous aider à mieux comprendre ce qui se passe. nous sommes partisans de l'apprentissage par l'exemple, n'hésitez pas à vous approprier les exemples, quitte à les casser (plusieurs fois s'il le faut).
* Ce *n'est pas* un livre sur openGL ou webGL. OpenGL/webGL est un sujet plus vaste que GLSL ou les fragment shaders. Pour en apprendre plus sur OpenGL/webGL, je vous recommande de jeter un oeil sur: [OpenGL Introduction](https://open.gl/introduction), [la 8ème édition du OpenGL Programming Guide](http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321773039/ref=sr_1_1?s=books&ie=UTF8&qid=1424007417&sr=1-1&keywords=open+gl+programming+guide) (aka le livre rouge) ou [WebGL: Up and Running](http://www.amazon.com/WebGL-Up-Running-Tony-Parisi/dp/144932357X/ref=sr_1_4?s=books&ie=UTF8&qid=1425147254&sr=1-4&keywords=webgl)
ce que ce livre n'est pas:
* Ce *n'est pas* un livre de maths. Bien que nous couvrirons certains algorithmes et certaines techniques reposant sur la compréhension de l'algèbre et la trigonométrie, nous ne les expliquerons pas en détail. Pour ce qui concerne les mathématiques, je recommande de garder près de vous un des ouvrages suivant: [La 3ème édition de Mathematics for 3D Game Programming and computer Graphics](http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Third/dp/1435458869/ref=sr_1_1?ie=UTF8&qid=1424007839&sr=8-1&keywords=mathematics+for+games) ou [La 2ème édition de Essential Mathematics for Games and Interactive Applications](http://www.amazon.com/Essential-Mathematics-Games-Interactive-Applications/dp/0123742978/ref=sr_1_1?ie=UTF8&qid=1424007889&sr=8-1&keywords=essentials+mathematics+for+developers).
* ce *n'est pas* livre sur l'openGL ou le webGL. OpenGL/webGL dépasse de loin le GLSL ou les shaders. si vous voulez en savoir plus, les liens suivants vous aideront [OpenGL Introduction](https://open.gl/introduction), [the 8th edition of the OpenGL Programming Guide](http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321773039/ref=sr_1_1?s=books&ie=UTF8&qid=1424007417&sr=1-1&keywords=open+gl+programming+guide) (alias "the red book") ou [WebGL: Up and Running](http://www.amazon.com/WebGL-Up-Running-Tony-Parisi/dp/144932357X/ref=sr_1_4?s=books&ie=UTF8&qid=1425147254&sr=1-4&keywords=webgl)
## De quoi avez-vous besoin pour commencer?
* ce *n'est pas* un livre de maths. Même si le livre contient un certain nombre de notions et d'algorithmes nécessitant des connaissances en algèbre et en trigonométrie, nous ne rentrerons pas dans le détail. Pour toute question relative aux maths, vous pouvez choisir un de ces livres et le garder près de vous : [3rd Edition of Mathematics for 3D Game Programming and computer Graphics](http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Third/dp/1435458869/ref=sr_1_1?ie=UTF8&qid=1424007839&sr=8-1&keywords=mathematics+for+games) ou [2nd Edition of Essential Mathematics for Games and Interactive Applications](http://www.amazon.com/Essential-Mathematics-Games-Interactive-Applications/dp/0123742978/ref=sr_1_1?ie=UTF8&qid=1424007889&sr=8-1&keywords=essentials+mathematics+for+developers).
Pas grand-chose! Si vous avez un navigateur moderne qui supporte WebGL (comme Chrome, Firefox ou Safari) et une connexion internet, cliquez sur le bouton du chapitre suivant en bas de page pour commencer.
## bien démarrer
Sinon, au vu de ce que vous avez ou de ce que vous avez besoin pour ce livre, vous pouvez:
si vous avez un navigateur récent (comme chrome, firefox ou safari) et une connection internet, il vous suffira de cliquer sur "suivant" en bas de page pour commencer l'aventure.
- [Faire une version hors-ligne de ce livre](http://thebookofshaders.com/appendix/)
Cela étant et selon ce que vous voulez faire de ce livre, vous pouvez :
- [Exécuter les exemples sur un RaspberryPi sans navigateur](http://thebookofshaders.com/appendix/)
- [créer une copie locale de ce livre pour le consulter hors-ligne](http://thebookofshaders.com/appendix/)
- [Faire un PDF de ce livre pour impression](http://thebookofshaders.com/appendix/)
- [lancer les exemples directement sur RaspberryPi, sans navigateur](http://thebookofshaders.com/appendix/)
- Utiliser le [répertoire github](https://github.com/patriciogonzalezvivo/thebookofshaders) afin d'aider à résoudre des problèmes et de partager du code.
- [créer un PDF du livre pour l'imprimer](http://thebookofshaders.com/appendix/)
- vous servir du [repo online](https://github.com/patriciogonzalezvivo/thebookofshaders) pour contribuer ou nous aider à débugger.

@ -0,0 +1,84 @@
# bien démarrer
## qu'est-ce qu'un fragment shader?
Au chapitre précédent, nous avons décrit les shaders comme l'équivalent l'avènement de la presse de Gutenberg pour l'impression. Pourquoi cette comparaison mais surtout: Qu'est-ce qu'un shader?
![de la copie manuelle, lettre à lettre, à l'édition page à page (gauche: William Blades 1891, droite: Rolt-Wheeler 1920)](print.png)
Si vous avez déjà dessiné avec un ordinateur, vous savez qu'il faut dessiner un cercle, puis un rectangle, une ligne, quelques triangles jusqu'à pouvoir composer l'image qu'on veut.
Ce processus est très similaire à l'écriture d'une lettre ou d'un livre voire à la peinture, c'est un ensemble d'instructions, exécutées en série, l'une après l'autre.
Les shaders sont également des ensembles d'instructions, mais à la différence des API de dessin classiques, *toutes les instructions sont exécutées sur chaque pixel de l'écran*.
Cela signifie que le code va devoir se comporter différemment selon la position du pixel à l'écran.
Comme la presse d'imprimerie, le fragment shader est une fonction à laquelle on passe une position et qui nous renvoie une couleur.
Une fois _compilé_, ce programme peut s'exécuter extrêmement rapidement.
![presse chinoise à caractères amovibles](typepress.jpg)
## Pourquoi sont-ils si rapides?
La réponse est le *traitement parallèle*.
Imaginez le CPU de votre ordinateur comme un *tuyau* et chacune des tâches que vous lui demandez d'exécuter comme *quelque chose* qui passe par ce tuyau, comme dans une usine.
Certaines tâches seront sans doute plus importantes que d'autres, elles demanderont plus de temps et d'énergie pour être traitées, on dit qu'elles nécessitent plus de ressources ou de puissance de calcul.
Du fait de l'architecture des ordinateurs, les tâches sont traitées en série ; chaque tâche doit être terminée avant que le CPU puisse traiter la suivante.
Les ordinateurs récents ont généralement plusieurs processeurs qui jouent le rôle de *tuyaux*, ce qui permet d'enchaîner les tâches en série tout en gardant une certaines fluidité, ces tuyaux s'appellent des *threads*.
![CPU](00.jpeg)
Les jeux vidéos et autres applications graphiques demandent beaucoup plus de puissance de calcul que les autres programmes.
Par nature, ils demandent de grandes quantités d'opérations au pixel, chaque changement d'image demandent de recalculer l'ensemble des pixels de l'écran.
Dans les applications 3D, on doit également mettre à jour les modèles, les textures, les transformations etc. ce qui rajoute encore du poids à la charge CPU.
Revenons à notre métaphore des tuyaux et des tâches où:*"trouver la couleur d'un pixel à l'écran"* représente une petite tâche toute simple.
En soi, chaque tâche n'est pas bien méchante mais il faut l'appliquer sur chaque pixel de l'écran! et c'est là que ça se corse ; il nous faut à présent exécuter cette petite opération un nombre considérable de fois.
Par exemple pour exécuter l'ensemble des tâches permettant de dessiner l'ensemble des pixels d'un vieux moniteur ayant une résolution de 800 x 600 pixels, il faut compter 800 x 600 = 480.000 appels à cette petite tâche.
Ces 480.000 appels ne valent que pour dessiner une seule frame, si on veut animer notre écran à 30 images/seconde pendant une seconde, il nous en coûtera 11.520.000 appels et si on veut du 60fps, on passe à 28.800.000 de tâches à traiter.
Peut-être que le problème est plus facile à identifier lorsqu'on commence à parler de dizaines de millions d'opérations/seconde, si on prend une configuration moderne, 2880/1800 pixels devant tourner à 60 fps, on atteint 311.040.000 calculs / seconde.
des centaines de millions d'opérations par seconde, ce sont des quantités propres à freezer voire à détruire un microprocesseur. alors comment fait-on?
![](03.jpeg)
C'est là qu'intervient le traitement parallèle (parallel processing).
Au lieu d'avoir quelques gros *tuyaux* (microprocesseurs), on préfère avoir de nombreux petits microprocesseurs qui tournent en parallèle et simultanément, c'est l'essence du GPU: Graphics Processing Unit.
![GPU](04.jpeg)
Imaginez ces petits microprocesseurs comme une trame de tuyaux, et les données de chaque pixel comme des balles de pingpong.
14.400.000 balles de pingpong par secondes pourraient boucher à peu près n'importe quel tuyau.
Mais une trame de 800 * 600 (480.000) petits tuyaux recevant 30 vagues de 480.000 balles de pingpong par secondes peuvent traiter la charge facilement.
Et ça marche pour des résolutions plus élevées ; plus le matériel est capable de traiter d'informations en parallèle, plus il pourra traiter des flux importants.
Un autre pouvoir magique des GPU c'est l'accélération matérielle de certaines fonctions mathématiques.
Certaines fonctions souvent un peu complexes seront traitées directement par le matériel au lieu de passer par la couche logicielle.
Ce qui signifie que certaines opérations mathématiques un peu complexes comme les transformations de matrics et les opérations trigonométriques seront traitées très vite, en fait, à la vitesse de l'électricité.
## qu'est ce que le GLSL?
GLSL est l'acronyme de 'openGL Shading Language' (où GL signifie Graphics Library), c'est une norme servant à écrire les programmes de shaders que nous aborderons dans les chapitres suivants.
Il existe d'autres types de shaders, selon les plateformes et le matériel utilisé, nous nous concentrerons sur l'OpenGL, dont les spécifications sont faites par le [Khronos Group](https://www.khronos.org/opengl/).
Comprendre l'histoire d'OpenGL peut être utile pour comprendre certaines conventions un peu bizarres, si ça vous intéresse, vous pouvez vous reporter à [openglbook.com/chapter-0-preface-what-is-opengl.html](http://openglbook.com/chapter-0-preface-what-is-opengl.html).
## Pourquoi les gens tremblent en entendant le mot Shader?
Comme disait Uncle Ben's ([?!](http://quoteinvestigator.com/2015/07/23/great-power/) NDT) "une grande responsabilité est la suite inséparable dun grand pouvoir", le traitement parallèle ne déroge pas à cette règle et aussi puissante que soit la programmation GPU, elle apporte un cortège de contraintes et de restrictions.
Pour pouvoir travailler avec une *trame* de *threads*, il faut que thread soit indépendant des autres. On dit que le thread est *aveugle* à ce que font les autres threads.
Cette restriction implique que toutes les données doivent aller dans le même sens, il est donc impossible de se servir ou simplement de connaître les résultat d'un autre thread.
Autoriser la communication entre threads au moment de l'exécution pourrait compromettre l'intégrité des données en cours de traitement.
Il faut également savoir que le GPU s'assure que tous ses microprocesseurs (la *trame de threads*) sont actifs en permanence ; dès qu'un thread a fini son traitement, le GPU lui ré-assigne une tâche à traiter.
Le thread ne garde aucune trace de ce qu'il faisait la fois précédente ; s'il était en train de dessiner un le pixel d'un bouton sur une interface graphique, sa tâche suivante pourra être de rendre un bout du ciel dans un jeu, puis de rendre un bout de texte sur un client mail etc.
Donc un thread est non seulement **aveugle** mais aussi **amnésique**
En plus du niveau d'abstraction élevé requis pour coder une fonction générique qui saura rendre une image entière uniquement à partir de la variation d'une position, les deux contraintes des threads, **aveuglement** et **amnésie** rendent la programmation de shaders assez impopulaire auprès des programmeurs débutants.
Mais n'ayez crainte! au cours des chapitres suivants, nous abordons les problèmes étape par étape et passerons d'un simple shader à des calculs avancés.
Si vous lisez ceci dans un navigateur récent, vous apprécierez de pouvoir manipuler les exemples interactifs et beaucoup de ce qui vient d'être dit s'éclairera de soi même.
Sans plus attendre, jetons nous dans le vif du sujet.
appuyez sur *Next >>* pour commencer!

@ -1,3 +1,8 @@
### Scott M
* You say “pipes” and also “threads”. This is a small thing but I wonder if you can reconcile those metaphors. I think in terms of threads, but “pipes” makes more sense with your illustration. Also works better with the concept of a “pipeline” or “graphics/rendering pipeline”.
* You say “pipes” and also “threads”. This is a small thing but I wonder if you can reconcile those metaphors. I think in terms of threads, but “pipes” makes more sense with your illustration. Also works better with the concept of a “pipeline” or “graphics/rendering pipeline”.
### Nicolas B
* clearly answer the "what is a fragment shader?" question in some sort of recap paragraph.
* beef up explanations around the compilation step (a brief overview will do).

@ -0,0 +1,82 @@
## Hello World
Généralement le "Hello World" est la première étape dans l'apprentissage d'un nouveau langage.
C'est un programme court qui renvoie un message enthousiaste et fait miroiter un avenir radieux.
Au pays du GPU, rendre du texte est une tâche extrêmement complexe (et un champ de recherche très actif NDT) donc au lieu d'un message texte, nous allons choisir une couleur chatoyante pour déchaîner notre enthousiasme!
<div class="codeAndCanvas" data="hello_world.frag"></div>
Si vous lisez ceci dans un navigateur récent, le bloc précédent est interactif.
Cela signifie que vous pouvez cliquer et éditer le code. Les changements seront pris en compte immédiatement, recompilés et si le shader est valide, il sera remplacé *à la volée*.
Vous pouvez essayer de changer les chiffres de la ligne 6.
Si ce program paraît simple, nous pouvons déjà faire quelques observations intéressantes:
1. ça ressemble à du C, un shader possède une fonction ```main``` dont le seul but est d'assigner une couleur.
2. la couleur du pixel est assignée à une variable globale (réservée) ```gl_FragColor```.
3. ce langage aux allures de C, possède des *variables* (comme ```gl_FragColor```), des *fonctions* et des *types*.
dans l'exemple, nous venons de voir le type ```vec4``` qui représente un vecteur de chiffres (des floats) à 4 dimensions. plus tard nous verrons d'autres types comme: ```vec3``` & ```vec2``` et d'autres plus fréquents comme: ```float```, ```int``` & ```bool```.
4. si l'on regarde ```vec4``` de plus près, on peut déduire que les 4 arguments correspondent aux 4 canaux: RED, GREEN, BLUE & ALPHA du pixel.
On note également que les valeurs sont *normalisées*, ce qui signifie qu'elles vont de ```0.0``` à ```1.0```.
plus tard nous verrons pourquoi c'est intéressant de manipuler des valeurs normalisées et comment *mapper* des valeurs entre elles.
5. une autre remarque importante est la présence de *macros de pré-traitement*
les macros font partie de l'étape de précompilation, elles permettent de définir (```#define```) des variables globales et de faire des opérations conditionnelles de base ( avec ```#ifdef``` & ```#endif```).
toutes les macros commencent par un hashtag (```#```).
la précompilation se produit - comme son nom l'indique - avant la compilation du shader, elle copie et renseigne tous les ```#define``` et vérifie si les ```#ifdef``` sont définis et si les ```#ifndef``` ne sont pas définis.
dans l'exemple ci-dessus, ligne 1, nous vérifions uniquement si ```GL_ES``` est défini, ce qui se produit principalement lorsque le code est compilé sur mobile ou dans un navigateur.
6. le type Float est vital dans les shaders, donc le niveau de *précision* des Float est crucial.
une précision basse permet un rendu plus rapide mais une qualité moindre et inversement, une précision élevée permet un meilleur rendu au prix de performances réduites.
on peut spécifier la précision de chaque variable se servant des Float, ligne 2 (```precision mediump float;```), nous assignons la précision *medium* à tous les floats de l'application.
nous pourrions leur donner une valeur *low* (```precision lowp float;```) ou *high* (```precision highp float;```).
7. la dernière remarque, probablement la plus importante, est que les spécifications GLSL ne garantissent pas que les variables seront *castées* automatiquement.
qu'est-ce à dire? si les fabricants ont des approches différentes pour accélérer leurs cartes graphiques, ils doivent toutefois se conformer à un ensemble de spécifications communes pour être utilisable par le plus grand nombre.
le casting automatique des variables ne fait pas partie des spécifications.
Dans notre exemple, ```vec4``` attend des ```floats``` et rien d'autre. si vous voulez obtenir un code homogène et éviter de passer des heures à débugger un écran blanc, prenez l'habitude de mettre des points ( ```.``` ) dans vos floats.
ce genre de code ne marchera pas toujours:
```glsl
void main() {
gl_FragColor = vec4(1,0,0,1); // ERROR
}
```
alors que celui ci à de plus grandes chances de marcher:
```glsl
void main() {
gl_FragColor = vec4( 1., .0, 0., 1. ); // BETTER
}
```
notez que le point peut être placé avant ou après un *0*.
Maintentant que nous avons passé en revue quelques éléments importants du programme "hello world!", il est temps de clicker sur le bloc de code et de mettre en application ce que nous venons d'apprendre.
Vous remarquerez que le programme ne se recompilera pas tant qu'il restera des erreurs. voici quelques idées intéressantes à tester:
* essayez de remplacer les *float* par des *int* la carte graphique vous autorisera ou non à le faire.
* essayez de commenter ( ```//``` ) la ligne 6 ce qui n'assignera aucune valeur au pixel.
* essayez de créer une fonction qui retourne une couleur en dehors de ```main()``` et essayez de l'utiliser pour assigner la valeur de ```gl_FragColor``` dans ```main()```.
pour vous aider, voici le code d'une fonction qui retourne une ```vec4``` de couleur rouge:
```glsl
vec4 red(){
return vec4(1.0,0.0,0.0,1.0);
}
```
* on peut construire un ```vec4``` de plusieurs façons, essayez de découvrir d'autres manières'. par exemple:
```glsl
vec4 color = vec4(vec3(1.0,0.0,1.0),1.0);
```
Bien que cet exemple ne soit pas très excitant, c'est le plus basique qui soit ; nous donnons à l'ensemble des pixels de l'image la même couleur.
Dans le chapitre suivant, nous verrons comment changer cette couleur en fonction de 2 facteurs: l'espace (l'emplacement du pixel à l'écran) et le temps (le nombre de secondes écoulées depuis le chargement de la page).

@ -1 +1 @@
Subproject commit 28774a4359120d2e02e8b6285ed05670c1bc7053
Subproject commit 490a8f35a4163f59230f53c34f1fbb22a864c01e
Loading…
Cancel
Save