Attention à Fred

Roman Science Fiction

Bonus Jeux Software

Cette page se consacre aux temps actuels sur Terre. 


Sommaire



Jouer tout de suite

Jeux d'arcade en Javascript "Canvas"

Venez pulvériser quelques aliens sur ce petit Defender sans prétention quoique très jouable et peu goumand en CPU. La patine des machines de l'époque a fait l'objet d'un soin particulier. Sorti à l'origine sur console, il a été porté en javascript à des fins pédagogiques pour apprendre à coder un jeu d'arcade. Le code est commenté.

Dirigez votre vaisseau avec les flèches, tirez avec A, faites exploser tous les aliens de l'écran avec S. Les meilleurs scores sont sauvés sur la machine locale. Entrez vos initiales avec les flèches droite et gauche, validez avec A.

Defender HTML5 javascript. Affichage Canvas




Arrivé 10 années plus tard dans les arcades, Arkanoid est un casse-briques évolué au graphisme plus travaillé que les versions antérieures.

Arkanoid développé en Js en 2007


Arrivé quelques mois avant Defender, Asteroid est le premier de sa génération de jeux d'arcades sur processeur 8 bits. Mu par un processeur 6502 de Rockwell (comme Comodore 64, Oric, ...) et entièrement programmé en assembleur sur un écran vectoriel qui tient plus de l'oscilloscope que de la télévision, il incorpore le génie du début des années 80. Contrairement au Defender ci-dessus, cette version a été portée de l'assembleur 6502 vers Javascript ce qui présage une consommation MAXIMUM de CPU. Par contre, c'est bien le jeu original tel qu'il était dans sa console et non pas une reproduction.

Attention à la consommation CPU !

Asteroid original émulé en Javascript


Le site de son auteur regorge d'information sur l'émulation javascript qui est un vrai défi technique. Javascript est bien implémenté dans les navigateurs mais son interprétation du code à la volée et sa résolution tardive des types en font l'un des langages les plus lents actuellement. Lenteur qu'on peut contourner en optimisant le code pour exploiter son étroite imbrication dans le document, ses librairies d'affichage les plus affûtées du moment, tâches qu'un émulateur ne peut pas remplir correctement.

Asteroid WebGL


Serious games

Plus que ludique, le jeu est un medium qui passe des messages, programme des réflexes, sensibilise sur des points infiniment précis. Il scénarise des situations fictives sans intervention humaine. Il se déploie à des millions d'exemplaires, il transmet bien plus qu'une information de QCM ou un cours magistral, il est infatigable...

Si on lui ajoute des périphériques comme des commandes de pilotage ou un casque type Oculus, un détecteur de mouvement type Kinect, il enseigne, signale les erreurs de timing, de manipulation, simule des sensations visuelles, auditives et temporelles, inculque du stress ou de la récompense comme aucun autre médium ne sait le faire.

La réalité virtuelle (VR) est une composante majeure de WebGL.

Cours, entrainement psychomoteur, examen peuvent se faire à une échelle impensable. Concept.

L' immersion sensorielle des serious games séduit aussi la médecine neurologique :

Jeux en Javascript WebGL, plus performants

C'est justement à cause de la lenteur de Javascript qu'on va essayer d'accélérer l'affichage en exploitant les librairies HTML 5. La plus importante pour animer un écran est WebGL.

WebGL apporte sur le navigateur les fonctions d'OpenGL ES et l'accélération matérielle (GPU), y compris sur mobile et tablettes. La nouvelle API qui hérite d'OpenGL ES s'appelle Vulkan et fédère des acteurs aussi importants qu'AMD et ARM (désormais NVidia). L'affichage est accéléré même en l'absence de GPU. Le code Javascript n'a plus besoin de gérer l'affichage.  Il peut donc accéder au plein écran et se concentrer sur l'heuristique pour aller beaucoup plus vite. 





Programmation WebGL 2D 3D

La plateforme de hackatons CodinGame utilise WebGL 2D pour afficher ses terrains de jeu et propose de programmer les IA's qui sont mises en compétition pour trouver la meilleure.

L'histoire de WebGL n'a rien d'un long fleuve tranquille. Spécifié par le group Khronos qui régule aussi OpenGL - dont WebGL est issu - et OpenCL (accélération matérielle de calculs sur GPU concurrent de CUDA), il souffre et/ou profite de la relation complexe que Khronos entretient avec les géants du logiciel.

Google l'a finalement adoubé non sans avoir montré quelques réticences de prime abord et édité une librairie concurrente qui le complémente désormais : la librairie o3d. Ce revirement entre dans le cadre de sa politique Native Client qui vise à faire tourner du code natif CC++ dans le navigateur et favoriser l'éclosion de l'écosystème Chrome OS où le navigateur remplace le système d'exploitation.

Native Client est désormais obsolète. WebAssembly a pris sa place avec pour ambition de faire tourner toutes sortes de langages en lieu et place de Javascript lorsque celui-ci se montre trop lent. Hélas, les issues de sécurité s'enchainent et il semble très dangereux de faire tourner WebAssembly aujourd'hui. Les efforts de Google pour détrôner les OS n'ont pas encore atteint leur matûrité.

WebGL n'est finalement pas obligatoirement lié à OpenGL. Il peut aussi s'installer en surcouche de DirectX (la librairie 3D de Microsoft), Google ayant, à cette fin, développé ANGLE, sans doute pour préserver son indépendance.

Une page d'introduction et de liens vers les frameworks se trouve ici :


Frameworks WebGL

  • Three.js. Populaire, il sert de librairie à de nombreux autres. Modeleur 3D en ligne.
  • Pléthore de jeux, démos, interfaces de design, simulations et autres réalisations sur la page de la librairie babylon.JS . Jouez, programmez, incorporez vos résultats dans vos pages web. Attention toutefois au volume des données 3D, en particulier les textures, RAM occupée et temps de chargement qui peuvent devenir pénalisants.
  • A-FRAME Basé sur Three.js. Syntaxe plus intéressante pour le web, il utilise des tags HTML modifiés plutôt que du code javascript. Sa liste de référence clients a de quoi impressionner. Le préféré de ce site.
  • PlayCanvas : Framework jeu complet, partiellement payant bien que la version gratuite soit très fonctionnelle. Modeleur/éditeur 3D avancé dans le navigateur. Bonne documentation. Tutoriel ici.

WebGL extrême






Trousse logicielle d'Attention à Fred

Attention à Fred a été réalisé avec les logiciels suivants

  • Blender 3D Le logiciel de création 3D open source qui rivalise avec ses concurrents payants est un trésor numérique néerlandais qui a permis de construire le visuel d'Attention à Fred, mais aussi de réaliser les effets spéciaux de nombreux films de premier plan et bien d'autres choses.

  • GIMP
  • Une alternative à GIMP pour l'imagerie en open source : https://krita.org/en/. Honnêtement, je ne l'ai pas vraiment utilisé car GIMP me convient. Son interface semble mieux finie et le logiciel a des sponsors prestigieux qui ont permis l'implémentation de fonctions HDR. Tutoriel Krita.
  • Inkscape : Le plus connu des éditeurs SVG open source.
  • BlueGriffon : Un des derniers éditeurs html wysiwyg gratuits encore en ligne. Il est signé Mozilla et sa maintenance laisse à désirer. Quelques comportements atypiques mais dans l'ensemble, c'est un passe-partout pour qui n'a pas peur d'éditer le code HTML en cas de blocage. Bon logiciel résilient aux erreurs qui ne bloque pas son utilisateur dans une logique restrictive.
  • Libre office Writer (quelques soucis)
  • Word
  • PSPad
  • ManuelBastioniLab L'addon Blender 2.79 pour la création de personnages humains, auquel on doit le visage de Fred, a cessé d'être maintenu par son auteur et son site web vidé de son contenu.
    Maj 12-2019 : L'intégralité des travaux de Manuel Bastioni a été "forkée" dans un nouveau projet open source nommé mblab.dev et placée sur Github ici.
    La dernière mise à jour concerne uniquement Blender version 2.80 et supérieures.

    Néanmoins, c'est à regret que Fred devra renaître sous Poser. L'originale était destinée à une couverture de livre. La prochaine devra également jouer dans des vidéos. Pour ce faire, il faudra l'équiper de vêtements. 
    Par ailleurs, la vidéo requiert des finitions en termes de rigging (animation propre à un corps). Pour toutes ces raisons, l'addon open source de Blender n'a pas encore la maturité requise.

ébauche du portrait de Fred
Première ébauche du portrait de Fred

Simulations 2D 3D (scènes d'action en navette)

L'importance des simulations est abondamment plaidée dans la page Robots - Intelligence artificielle. Toutes les scènes d'action du livre n'ont pas été simulées mais les exemples testés ont fait fonctionner le mécanisme de rêve éveillé... Concomitamment, les concours de Codingame ont mis en évidence quelques "super-pouvoirs" dont jouit l'IA, lesquels ont échappé aux auteurs SF jusqu'ici. La seule théorie ne peut pas remplacer la pratique.

  • C# (pictureBox)
  • Javascript Canvas pour la simulation des orbites (mais pas celle des engins)
  • Quelques modèles de collision empruntés à Magus qu'on peut rencontrer sur le Discord de codingame. Merci à lui... Les collisions 3D proviennent du Blender Game Engine qui n'existera plus dans la version 2.8 de Blender. Apparemment remplacé par un logiciel spécifique nommé Armory 3D. Armory s'annonce comme un redoutable challenger dans le monde du framework de création de jeux.
  • La simulation 3D avec détection de collision n'est pas l'apanage exclusif du jeu vidéo. L'équipementier industriel Farnell propose un simulateur dédié aux machines-outil. L'ensemble machine et logiciel constitue ce qui se rapproche le plus des robots d'Attention à Fred à notre époque.





N-Body

Le calcul des N-Bodies est un enjeu scientifique de portée mondiale. Les puissances spatiales rivalisent de moyens pour modéliser d'immenses objets tels que galaxies ou à l'inverse, d'infimes particules de poussière formant les nuages ou nébuleuses.

Aussi l'algorithme a-t-il fait l'objet d'une infinité de publications, ciblant aussi bien les petits ordinateurs que les supercalculateurs réunissant des milliers de processeurs graphiques. 

Une simulation du système solaire en Javascript :

Algorithmes décrivant la mécanique spatiale

La mécanique spatiale n'est pas difficile à concevoir pour un cerveau humain. Le tourbillon d'un lavabo, les jeux de balle ont formé nos esprits dès l'enfance. La capacité du cerveau à simplifier les problèmes par un choix judicieux d'approximations est très utile pour qui ne veut pas y consacrer des années d'apprentissage. (cf. heuristique)

De leur côté, les simulations numériques ne tolèrent pas beaucoup d'approximation. Il faut s'interresser à Newton et Kepler pour avoir des résultats.

En 2020, un smartphone d'entrée de gamme rivalise de puissance avec un projet scientifique de portée mondiale il y a seulement un siècle. Reste à mettre en oeuvre la logique pour modéliser la mécanique spatiale.

Cette logique porte un nom : N-Body.


En quoi consistent les N-Bodies ?

En simplifié, l'algorithme N-Body part d'une base de données d'objets célestes et calcule leurs intéractions gravitationelles pour simuler leur mouvement.

Chaque objet ayant une influence sur tous les autres, le temps de calcul croît exponentiellement selon le nombre d'objets de la base de données.  Pour un objet de la base, tous les autres sont affectés. Les N-Bodies travaillent donc par paires d'objets et on va traiter [nombre d'objets] au carré.  Sur un ordinateur domestique, il faudra limiter leur nombre mais tant qu'on reste dans un système de quelques dizaines d'objets, le temps de calcul ne sera pas trop pénalisant.


Maj 09-20 Un petit simulateur de système solaire a été porté sur ce site : 

Si vous agrandissez la fenêtre du navigateur pendant l'exécution du simulateur, pensez à recharger la page (touche F5) pour agrandir le canvas au plein écran. Pour occuper tout l'écran, taper F11 (sous windows).


Pour ajouter une planète au simulateur, dessiner simplement le premier vecteur de sa trajectoire à la souris. Utiliser la combo box en haut à gauche pour spécifier sa masse.

Le code et la philosophie du simulateur sont tirés du cours en ligne de Darrel Huffman.

Image simulation système solaire
Cliquer pour afficher le simulateur

A propos du simulateur de système solaire

Le simulateur AàF se veut très simple d'utilisation. Il suffit de cliquer un bouton et surtout, de regarder attentivement ce qui se passe à l'écran pour se forger sa propre opinion sur les comportement des objets qui font l'ordinaire d'un mineur spatial.

Il existe d'autres simulateurs sur le web. Notamment celui-ci : gravitySimulatorCloud. Tous focalisent sur l'aspect scientifique et mettent le ressenti au second plan. AàF est une oeuvre de science fiction, son simulateur offre une vue simple et parlante de son décor. Il ne fait ni plus ni moins d'infractions à la science que les autres mais place le confort de son lecteur au sommet de ses préoccupations. 

Ecrit en Javascript-Canvas et très pratique à utiliser quoique lent, le simulateur est pensé comme un objet de geek plutôt que scientifique dont il n'a pas la rigueur (ni le caractère rébarbatif). Il s'améliore au fil des versions et donne un aperçu des sujets abordés sur ce site, mais pas que...

Le comportement des corps quant à la gravité, vitesses et distances est aussi fidèle que le permet la librairie double précision. C'est à dire, beaucoup mieux que ce dont disposaient les missions Apollo ou Voyager. Pour mémoire, en 1969, l'alunissage du LEM était piloté manuellement, l'horloge d'Apollo 11 était un mécanisme d'horlogerie à balancier rotatif et la navigation se faisait avec un sextant optique, comme celui-ci :

Marine sextant fr

Crédit image : Joaquim Alves Gaspar, CC BY-SA 3.0
Cliquer pour voir la source.

Le simulateur reproduit à l'identique les forces physiques qui lient les planètes, les positions sont calculées à partir des données orbitales du JPL Small-Body Database Browser NASA.

Sa consommation de CPU n'est pas négligeable sur une machine ancienne. Par contre, il se désactive immédiatement lorsque sa fenêtre devient invisible comme lorsqu'on change d'onglet ou quand l'écran se met en veille.

Bugs, anomalies connus :

Au 25-10-20, les ellipses décrites par certains corps sont affinées empiriquement sur la base des min/max (Aphélie/Périhélie) à l'aide d'un algorithme bruteforce. Certaines sont rendues circulaires, notamment sur la vue Neptune. Les orbites très excentriques perdent de la précision lorsque l'accélération du temps est très forte, or, Pluton tourne vraiment très lentement...
L'orbite très excentrique de Pluton a, par ailleurs, été compressée pour éviter aux autres planètes de tomber dans un trou de serrure bouillonnant... Priorité à l'ergonomie. L'alternative eût été de ne pas le montrer.

La constante gravitationnelle (constante de Newton), ne reflète pas encore la réalité. Les différences d'échelle pèsent sur son estimation - C'est un peu comme si on filmait le système solaire avec un objectif grand-angle qui déformerait le temps comme l'espace...   Les astres situés loin du Soleil ont une période orbitale plus courte que dans la réalité. En octobre 2020, l'affinage de cette constante n'est pas encore automatisée sur la simulation.

Si Pluton se retrouve quasi immobile alors que la Terre tourne si vite qu'on ne la voit plus, l'ergonomie primera sur la rigueur et l'orbite lointaine sera rendue moins élliptique. C'est un choix de science fiction...

La dimension z est parfois absente des objets (inclinaison). Le calcul d'injection orbitale ne la prend pas encore en compte et le brute force non plus. Le point de vue est situé au nord du soleil à 45° de latitude.

La précision globale du programme n'est aucunement fiable sur de longues périodes. La simulation permet de "comprendre comment ça marche", visuellement et sans explications longues. Elle n'a pas vocation à remplacer le logiciel NASA pour préparer une mission à millions de dollars ! 

Au démarrage, Jupiter débute sa course au sud-ouest de l'écran. Cela suffit pour provoquer un déplacement très lent du soleil vers la droite. Jupiter et le soleil tournent l'un autour de l'autre dans la réalité aussi. Après une trentaine de minutes d'animation, il faudra faire Reset animation pour recentrer le soleil.

Les astres sont affichés (beaucoup) plus gros que dans la réalité (y compris le soleil) :
C'est un choix arbitraire du développeur à l'instar de tous les schémas publiés à ce jour. L'oeil ne distingue pas les millipixels...

La position des astres au démarrage ne correspond à aucune observation. Les données de date sont actuellement ignorées. Ajouter cette fonction est subordonné à la résolution de la constante de Newton et la refonte de toutes les injections en orbite que cela impose.

Les influences gravitationnelles sont limitées aux objets affichés. Pas de noyau galactique avec son trou noir supermassif, pas de planète 9, ni de matière noire...

En accélérant la vitesse, il se peut que le calcul sorte des marges de tolérance. Cela entraine des déviations de trajectoire (surtout sensible sur "For fun"). En effet, pour des raisons de performance, le calcul des intéractions gravitationnelles est synchrone avec le rafraichissement d'écran. En accélérant l'animation, ce calcul s'effectue à une fréquence moindre. Les vecteurs s'allongent et peuvent sortir des limites tolérables pour maintenir les caractéristiques orbitales. Dans ce cas :

Ralentir la vitesse et cliquer sur Reset animation.

Le reste semble fidèle.

FAQ :

L'orbite de Mercure semble décentrée, Est-ce normal  ?
Oui, l'orbite de Mercure a une excentricité de 0.2056 (cf. wiki)

L'orbite d'Itokawa dépasse (un peu) celle de Mars par moments....
Les injections sont affinées par un algorithme brute force. Les relations entre objets reflètent bien ce qui se passe dans notre ciel. C'est tout l'intérêt d'une animation. Itokawa dépasse ou non l'orbite de Mars selon la période orbitale de ce dernier. Tantôt proche de son aphélie (distance maximum au Soleil), Mars est alors trop haut pour être atteint, tandis qu'il se fait largement dépasser lorsqu'il s'approche du Soleil.

Non-détection des collisions

Cette simulation ne détecte pas les collisions. Les corps peuvent occuper brièvement le même espace. Mais les centres ont fort peu de chance de se chevaucher à 15 décimales près. Dans ce cas, le logarithme du calcul de la gravité amplifie considérablement l'influence des deux corps qui accélèrent dans des proportions absurdes. Bien que ce cas soit rarissime, il faut alors cliquer Reset animation.

Créer une orbite très éliptique sur le simulateur : Le lancer de planète : Tracer un trait de quelques millimètres à la souris à bonne distance du Soleil et observer la trajectoire de l'astre ainsi créé.  (Plusieurs essais seront nécessaires, entrecoupés de Reset animation ...).

Ce que montre cette animation :

Le rapport altitude/vitesse est invisible sur une image fixe. D'autre part, la plupart des schémas animés, y compris Asterank, dessinent les orbites complètes en pointillés. Or, en réalité, les orbites sont toujours ouvertes, càd que l'orientation du demi grand axe change à chaque révolution. Dessiner une orbite avec un polygone fermé induit donc en erreur. Seule une animation calculée en temps réel peut montrer les orbites réelles comme un mineur spatial les verra dans un siècle.

L'accélération à l'approche d'un objet massif est à l'origine des frondes gravitationnelles que les sondes spatiales exploitent pour atteindre des vitesses hors de portée de leurs réserves de combustible. Plus tard, un animation spécifique sera ajoutée pour illustrer l'effet de fronde gravitationnelle. A défaut, la comète Tchouri, visible depuis la vue principale Terre-Jupiter, donne un aperçu de ce principe.

La simulation est exacte au point de vue Newton - dans la limite des corps présents dans sa liste.

demo simulateur de système planétaire
For fun - Voir la démo du simulateur

Perspectives du simulateur

Le portage de l'affichage canvas vers WebGL est en projet. On pourra alors zoomer un objet mobile et verrouiller la camera dessus. Néanmoins, l'affichage classique ne manque pas d'un charme qui sera perdu par la suite. Qu'importe ! Si WebGL permet de calculer la gravité sur GPU, la vitesse sera mutipliée par 200 au moins.

A ce sujet, la limite des calculs GPU est qu'il est difficile de rapatrier les résultats de calcul vers le CPU (goulot d'étranglement).





N-Bodies en Vidéo

Démo sur +131 000 corps, soit plus de 17 milliard de paires par image, calculées en CUDA sur GPU NVidia. Les sources sont disponibles sur GitHub.




Courte vidéo de 16 secondes montrant comment 1 million de particules uniformément réparties se regroupent en structure filamenteuse par la seule gravité.


Logiciel de Simulation spatiale en téléchargement

Le simulateur d'univers

Space Engine de Vladimir Romanyuk Une réalisation colossale ! Simulation réaliste de l'univers connu et inconnu par extrapolation et rendu aléatoire borné par les statistiques. Vous pouvez y voyager d'étoile en étoile, changer de galaxie, visiter les paysages très fouillés d'une planète probable située à un milliard d'années lumière, altérer le déroulé du temps... Toutes les transitions sont fondues pour rendre l'expérience plus immersive. La génération procédurale de planètes et d'étoiles respecte l'état des probabilités connues. Les corps connus sont quant à eux, reproduits avec précision et une touche artistique qui exploite parfaitement le moteur de rendu. Les exoplanètes découvertes récemment sont évidemment là.

Digne successeur de l'ancien Celestia dont le développement a été stoppé en 2002, Space Engine est stable même sur des machines modestes (4Gb minimum, 8Gb conseillés). Bon voyage.

NASA

General Mission Analysis Tool (GMAT) Le logiciel NASA spécialisé dans la conception de missions, optimisation, navigation, propagation, orbites basses, géosynchrones, libération et espace profond. Open source daté de 2016 (vérifier d'éventuelle version plus récente avec Google), il a fait l'objet de nombreux bugfixes  et reçu de nouvelles primitives mathématiques. C'est évidemment une référence pour qui projette une mission spatiale à l'international.

CNES

Catalogue des logiciels distribués par le CNES Le Centre National d'études Spatiales publie son ensemble logiciel développé pour les missions européennes dont une partie en open source.







Shaders

La révolution WebGL 2 et 3D

WebGL promet de bouleverser la vie quotidienne de milliards de terriens.

Jusqu'ici, le web a lentement conquis sa place dans les média en s'inspirant de la presse écrite, à laquelle il ajoute des liens hypertextes, des vidéos, des choses animées et réactives. Parallèlement, il multiplie les écrans, smartphones, tablettes, consoles de commandes d'automobile, d'appareils électroménagers...

Au départ, on trouve une page web. C'est là que figurent les liens qui mênent vers des expériences diverses, parfois inclassables.

WebGL change radicalement cette approche. La "page de journal" devient un écran d'accueil. L'ergonomie, le graphisme et le comportement sont ceux d'un jeu vidéo.

L'interface homme machine s'enrichit de tactile, de commandes vocales tandis que la machine répond en faisant pivoter des menus, scroller un paysage, un schéma, en synthétisant une voix ou un son associé à un état précis.

Les écrans s'enchainent par fondu ou par scroll, la lecture de texte n'est pas nécessaire pour intéragir. Tous les sens sont mis à contribution.

Le jeu vidéo est un joker dans l'univers des média. Il est  rarement cité comme tel, ne bénéficie pas de passe-droits comme la presse ou l'audiovisuel. Pas de subventions, pas de privilège légal. Clairement sous-estimé par le monde politique, il se développe à bas bruit, uniquement sur la base de ses qualités intrinsèques.

C'est pourtant lui qui apporte l'intéraction sensorielle la plus riche et la plus développée. Celle qui convient à l'immensité du web.

Réalité augmentée, effets visuels, analyse de mouvement, vision numérique, tous ces domaines ont connu des bouleversements et WebGL les relie entre eux, entre différentes consoles, adaptées aux handicaps physiques, ignorant les distances, les langues...

  • WebGL sur Wikipedia. L'article évoque le potentiel qui se dégage de l'adoption de WebGL par l'ensemble des navigateurs.

Présents aussi bien en 2D qu'en 3D, les shaders deviennent incontournables dans le rendu graphique et bouleversent des disciplines qu'on croyait intouchables.

Les Shaders, qu'on appelait "textures" autrefois, sont mal connus alors que leur évolution, liée au hardware graphique, s'avère époustouflante. C'est un métier en soi, où les artistes 2D non-figuratifs trouvent leurs marques.

L'origine des shaders est indissociable de la 3D alors qu'aujourd'hui, ils sont aussi une composante essentielle de la 2D au format WebGL.

La courte histoire des shaders

L'imagerie 3D a toujours été associée à la géométrie qui consiste à assembler des polygones pour former des objets en 3 dimensions : Les meshes. Les polygones suffisaient à l'industrie manufacturière mais ne convenaient pas à celle du cinéma qui ne pouvait se contenter de formes colorées à plat, à peine nuancées par l'ombrage calculé des premiers moteurs (cf. le film Tron). On a alors collé des images sur les polygones pour ajouter du réalisme, mais le résultat restait fade. De nombreuses techniques d'habillage de surfaces sont apparues et se sont entremêlées sans ordre précis.

Durant les 90's , les cartes graphiques accélérées pour la 3D sont arrivées à peu près en même temps que le jeu Doom II. Les éditeurs de jeu ont développé leurs moteurs sur le nouveau hardware qui déchargeait le CPU d'un énorme travail : Rendre chaque surface avec toutes ses textures. En multipliant les coeurs pour le calcul parallèle, les constructeurs de GPU ont plus ou moins standardisé les techniques d'alors mais en ont aussi introduit de nouvelles, si bien que l'art de l'habillage est resté touffu. Néanmoins, le mariage des mondes hardware et software s'effectua dans les studios des éditeurs. Les Shaders étaient nés.

Inclassables...

Notion de geek, les shaders défient les théories en mêlant les contraintes de temps d'exécution, de "parallèlisabilité" et d'approximations telle que l'emploi des normales 3D pour simuler un relief alors qu'elles n'affectent que l'ombrage...

Surfaçage de matériaux, bas relief, rendu d'une patine, l'appétissant d'un aliment... Les artistes ont pris le relais sans complexe et hacké toutes les techniques pour satisfaire les joueurs. Si le texturage est facile à comprendre - on colle un "papier peint" sur un objet 3D - les shaders sont une discipline à part qui n'a cessé d'évoluer de sorte qu'on ne sait plus très bien si on regarde une simple image, une topologie de polygones 3D ou des bitmaps traités pour leur donner une profondeur. Chaque moteur, chaque logiciel apporte des nouveautés qui peuvent renverser la table et pousser les réalisations antérieures vers l'obsolescence puisqu'impossibles à convertir vers les nouveaux standards.

L'adoption de WebGL par l'ensemble des fabricants et éditeurs était donc une condition essentielle pour permettre aux shaders de remplacer progressivement l'imagerie classique, déjà affectée par HDR. Contrairement à ce dernier, les shaders n'ajoutent pas seulement de nouvelles couches dans les données d'une image, mais aussi du "code exécutable" qui va permettre de s'adapter au format d'affichage ainsi qu'au processeur graphique (GPU) disponible.

En effet, Javascript n'est pas adapté au travail parallèle, il est lent et plutôt monotâche. Il ne sait donc pas afficher une image pendant que sa suivante se construit en mémoire.

En général, les shaders consistent à rendre les infractuosités d'une surface, son grip, son absorption de lumière, son brillant, sa transparence ou plus subtilement, la manière dont elle irise la lumière pour la faire rebondir ailleurs...

En WebGL, il s'agit aussi de décharger complètement Javascript de l'affichage et même de le paralléliser dans une puce spécialisée qui n'a rien d'autre à faire. Le GPU exécute un code compilé pour lui et synchronise avec la fréquence de rafraichissement de l'écran (vertical blanking). Ce dernier détail procure une sensation de fluidité caractéristique.

Passons au concret

Voici un résumé de ce qu'on trouve dans la famille principale des logiciels 3D (Blender, Maya, 3DS, WebGL, ...) à l'exclusion des logiciels orientés "nuages de points" ou spécialisés dans les particules (Houdini).

Sur un objet 3D (mesh), on colle plusieurs couches :

Les Bump Maps, Normal maps, Displacement ou Parallax maps ajoutent du relief à la surface sur laquelle on les pose. Chacune de ces techniques agit différamment et requiert un fichier image particulier. Normal map stocke l'orientation de chaque pixel en X, Y, Z dans les composantes RVB d'une image (généralement un .png ou tga/tiff) sans modifier la position du point. Seule l'orientation change. Normal map est très utilisé parce que sa consommation en calcul est faible pour une bonne qualité perçue. 

Le Displacement Map ou Parallax Map va, quant à lui, modifier la géométrie de l'objet 3D au prix d'un calcul plus long. Displacement map n'est pas supporté par tous les moteurs de rendu (Blender Cycles ne le supporte pas en natif mais propose une alternative). WebGL et GLSL supportent bien le displacement map. Il est donc conseillé d'en user abondamment sur des objets à géométrie simple, plutôt que de multiplier les polygones. Un bitmap  complexe n'est pas plus long à charger qu'un bitmap simple alors qu'une géométrie 3D s'alourdit massivement selon sa complexité...

On trouve aussi, les Ambient Occlusion pour renforcer l'ombrage des interstices, les Specularity Maps qui définissent les zones brillantes et bien sûr, les Diffuse Maps (anciennes textures) qui ne concernent que les couleurs. Sans oublier la transparence qui permet de superposer les effets. La liste ne s'arrête pas là puisqu'on peut cartographier tous les comportements des matériaux soumis à la lumière. Le Subsurface Scattering et la très importante réflexion de Fresnel qui oréole les objets d'un mince filet lumineux, feront une grande différence dans une image mais, faute d'y consacrer un site web, laissons ce travail aux artistes.

Une tendance du texturage évolue vers le procédural où on essaie de substituer des algorithmes aux images bitmaps, comme des générateurs de bruit, formes mathématiques, fractales ou autres afin de les rendre insensibles à la résolution du rendu. En effet, les objets 3D on la fâcheuse manie de s'approcher très près de la caméra, laissant apparaître leurs pixels en gros plan alors que les algorithmes ne pixellisent pas.

La synthèse de tout cela relève d'un mélange entre image 2D fortement retouchée voire fortement dégradée pour ne rendre que des ombres ou des brillances par exemple, image obtenue par voie procédurale et géométrie 3D. Les proportions de chacunes dépendent de la sensibilité de l'artiste et du moteur de rendu. 

Dans le monde WebGL, le standard pour les shaders s'appelle GLSL.

Liens logiciels pour création de shaders en WebGL :


Les Shaders sous Blender Cycles ne sont pas compatibles GLSL. Par contre, ils ont le même usage et s'appuient sur le même matériel. Cycles optimise l'architecture de Blender (ou Poser) alors que WebGL est un standard pour la diffusion mondiale sur navigateurs web. Blender produit des images et des vidéos pour le web, le cinéma ou la télévision dont le calcul peut durer plusieurs semaines. WebGL se limite au web et tourne sur la machine de l'utilisateur en temps réel.

La différence est énorme puisque le temps réel, en vidéo, limite le temps de calcul d'une image à 16 ou 33 millisecondes. Cette limite conditionne la capacité du joueur à intéragir avec la 3D. Dans le cas d'un film, le spectateur ne peut pas changer le déroulé de l'histoire. Les temps de calcul peuvent donc s'étendre sur de longues périodes et les machines coûter des sommes sans rapport avec le budget d'un particulier.

Dans un jeu en revanche, tout doit être calculé en 30 ms. sur une machine personnelle, laquelle est, le plus souvent, un portable avec une puce GPU NVidia, AMD ou Intel basse consommation.

Quelques liens sur les shaders sous Blender :

N'oubliez pas de stocker les tutos vidéos dans vos favoris, il vous faudra probablement y revenir plusieurs fois. Pour reproduire les manipulations, lister les commandes dans un fichier texte ouvert conjointement à la lecture.


Ecran nme

L'éditeur Node Material Editor (nme) de BabylonJS, lui-même écrit en BabylonJS, est un éditeur de shaders typé "node" qui sauvegarde au format code/texte. Doté de la même ergonomie que Blender (zoom, move), il offre un moyen de s'affranchir du code pour faire des milliers d'essais à la souris (niveau avancé).




Le coin des développeurs

Voici le langage fétiche de l'auteur :

Compilateur développé en France par Frédéric Laboureur. Extrêmement rapide, produisant des exécutables compacts qui fonctionnent sans runtime ni setup. Son IDE se lance en une seconde, son débugger source est complet, il accepte l'assembleur dans le code en lui apportant les variables basic avec leur garbage collection. Irremplaçable pour les petits morceaux de soft très performants, temps réel, traitement de signal (exemple à venir).

Né sur Commodore Amiga (version Amiga disponible en open source sur le site), il a gardé l'esprit pionnier des GFA basic, STOS, ..., tout en trouvant sa place sur les machines actuelles 64 bits, Windows, Mac, Linux.

Sa communauté est très active, peuplée de grands professionnels, répondant aux débutants comme à leurs pairs.

Plus qu'un langage, c'est une expérience de vie pour quiconque veut s'affranchir de la jungle mainstream et profiter d'innombrables ficelles introuvables ailleurs. 

PureBasic implémente un accès simplifié et complet du moteur 3D Ogre. Orienté temps réel (Jeu, VR, ...) et bien implanté dans le monde 3D depuis 2001, Ogre est multiplateforme, comme Purebasic. Les convertisseurs depuis et vers d'autres formats (Blender, 3DS, ...) sont disponibles.


Spider Basic

Du même éditeur, Spider Basic utilise la même syntaxe que Pure Basic pour produire des applications Web après conversion en Javascript. Spider Basic apporte la compatibilité Web à Pure Basic. Un développeur Purebasic pourra "recompiler" son application et fonctionner immédiatement sur tout device compatible web , téléphone, tablette, TV connectée ou machine exotique.

L'objectif est que le travail de développement en Purebasic pourra fonctionner avec peu de modification sur presque toutes les machines en Javascript dans le navigateur.

L'intéret de Spiderbasic ne s'arrête pas à la bibliothèque de programmes déjà développés en Pure. Il constitue une formidable base de travail pour un développement Web avec IDE, débugger et tous les modules présents dans ces deux plateformes.









Vue d'artiste d'un asteroide


Accueil





©2018-10 - aafred.com
wbase.net