URL: https://linuxfr.org/news/le-rendu-3d-retrospective Title: Le rendu 3D, rétrospective Authors: small_duck Julien Jorge Date: 2022-11-19T22:47:26+01:00 License: CC By-SA Tags: c++, opengl et vulkan Score: 5 Le 13 Novembre est sorti Vulkan Scene Graph 1.0.0 (VSG). C'est la première version stable de cette bibliothèque en C++ qui fournit un graphe de scène basé sur l'API graphique Vulkan. Son concepteur, Robert Osfield, avait créé et maintenu OpenSceneGraph (OSG), basé sur OpenGL. Vulkan étant devenu la référence, il était temps de mettre à jour OSG en utilisant les toutes dernières fonctionnalités du C++. Comme c'est un sujet touffu, je vous propose dans cette première dépêche de revenir sur l'histoire des graphismes 3D. Dans une deuxième dépêche, nous verrons ce qu'est un graphe de scènes, et dans une troisième, nous nous pencherons plus spécifiquement sur OpenSceneGraph et VulkanSceneGraph. ---- [Le site d'OpenSceneGraph](http://www.openscenegraph.com/) ---- # La 3D dans mon PC # Aux temps anciens et légendaires de l'informatique, très tôt on a voulu tenter de représenter des environnements en 3D, et de nombreuses techniques ont été crées pour cela. L'on peut évoquer les [raytracers](https://fr.wikipedia.org/wiki/Ray_tracing), qui tentent de s'approcher de la réalité physique du rendu en simulant un grand nombre de rayons lumineux et leur trajet dans une scène en 3D avant de frapper l’œil de l'observateur, mais cette technologie a longtemps été beaucoup trop lente pour représenter des environnements en temps réel. ## Rendu fil de fer ## [BattleZone](https://fr.wikipedia.org/wiki/Battlezone), jeu arcade de 1980, a popularisé la technique du rendu en fil de fer. Le monde est composé de polygones en 3D, et chaque polygone est transformé puis projeté afin de déterminer où l'afficher sur un écran en 2D. L'affichage fil de fer, qui nécessite juste de tracer une ligne entre les sommets, est diablement efficace, ce qui permettait de le faire tourner sur le matériel de l'époque. Ce fut une révolution, avec une immersion qui était inconnue jusque là. ![BattleZone](https://technoturtle.net/images/battletank.png) ## Fausse 3D ## De manière diamétralement opposée, certains jeux proposent de la fausse 3D. Par exemple, [Dungeon Master](https://fr.wikipedia.org/wiki/Dungeon_Master), en restreignant les déplacements à du case par case, se contente d'ajuster des éléments en 2D comme un puzzle pour émuler un univers de couloirs et de créatures, avec un rendu extrêmement réaliste pour l'époque. ![Dungeon Master](https://technoturtle.net/images/dungeon_master.jpg) ## Approches intermédiaires ## D'autres jeux choisissent une approche intermédiaire. Les rendus en 3D précalculée ont longtemps été populaires. Par exemple, les graphistes d'un jeu de combat dans l'espace créent un vaisseau ennemi dans un modeleur 3D et font toute une série de rendus en raytracing pour créer une galerie d'images du vaisseau, les sprites, vu depuis un certain nombre d'angles. Lorsque le jeu tourne, il utilise transformations et projections afin de déterminer où se situe le vaisseau ennemi sur l'écran du joueur, et affiche le sprite le plus proche de l'angle de vue réel. Suivant le même principe, [Doom](https://fr.wikipedia.org/wiki/Doom_(jeu_vid%C3%A9o,_1993)) affiche un monde en 3D, mais les créatures sont des sprites. ![Doom](https://technoturtle.net/images/doom.jpg) # Enfin, le raster # C'est probablement avec [Quake](https://fr.wikipedia.org/wiki/Quake) que le monde entre enfin complètement dans le monde du raster. Dans Quake, le monde ainsi que les créatures du jeu sont complètement en 3D, et il est possible de regarder dans toutes les directions, dont le haut et le bas. Une révolution à l'époque ! Le [raster](https://fr.wikipedia.org/wiki/Rast%C3%A9risation) a gagné. ![Quake](https://technoturtle.net/images/quake.jpg) L'idée derrière le raster est la suivante : le monde est défini comme une liste de triangles. Les coordonnées des sommets de chaque triangle sont transformés via une série de matrices, qui projettent ces sommets sur notre écran. Ensuite, chaque pixel appartenant au triangle va être rendu via un système d'interpolation. Par exemple, je peux interpoler un vecteur normal qui m'indiquera à quel point mon pixel fait face à la source de lumière. Je combine cette information de luminosité avec une coordonnée de texture interpolée, voire de transparence. Enfin, j'affiche le pixel, avec une information supplémentaire de profondeur (l'axe Z), qui me permet de ne pas remplacer un pixel qui se trouverait devant par exemple. ## Les premières cartes graphiques ## C'est super, mais au fur et à mesure que les concepteurs ont trouvé de nouvelles techniques pour un rendu de plus en plus beau, la quantité de calculs a explosé. Mais ça tombe bien ! Ces calculs sont plutôt répétitifs : il s'agit généralement de faire tourner la même petite routine pour chaque pixel. Et une technologie fait ça très bien: le [SIMD](https://fr.wikipedia.org/wiki/Single_instruction_multiple_data). Les fabricants de matériel ont donc commencé à proposer au grand public des cartes graphiques qui implémentaient de façon matériel ce pipeline graphique, avec de nombreux cœurs de calcul qui travaillaient en parallèle. Plusieurs API tentent de mettre de l'ordre dans ce bazar, en fournissant des primitives de calcul et un accès au matériel, en particulier [OpenGL](https://fr.wikipedia.org/wiki/OpenGL) et [Direct3D](https://fr.wikipedia.org/wiki/Direct3D). ## Les cœurs programmables ## La technologique évoluant, les développeurs ont commencé à vouloir faire des choses de plus en plus folles, et en particulier pouvoir programmer certaines parties du pipeline. Le concept de shader était né. L'idée est de permettre d'injecter des programmes dans chaque petit cœur de calcul. D'un côté, les vertex shaders permettent de contrôler la transformation de chaque sommet. De l'autre, les fragment shaders permettent de contrôler l'affichage de chaque fragment (pixel) de polygone, permettant donc de finement contrôler la lumière et l'assemblage de textures. ## Fin du pipeline fixe, et PBR ## Finalement, plus personne n'a voulu du pipeline fixe : de nos jours, il est nécessaire de programmer via les shaders. La nouvelle technologie à la mode, permise par la puissance monstrueuse des cartes graphiques d'aujourd'hui, est le PBR (physics based rendering), autrement dit le rendu basé sur la physique. L'on définit pour chaque objet une série de textures, représentant sa couleur de base, ses normales (permettant de reproduire des surfaces rugeuses ou en creux, ou encore avec des inscriptions gravées), sa rugosité (qui va rendre l'objet plus ou moins brillant ou mat) et une information dite de métal qui indique de quelle couleur doivent être les reflets. Mélangés dans un shader approprié, cela donne un rendu exceptionnel qui s'intègre dans n'importe quel environnement 3D. Là où le graphiste auparavant devait créer plusieurs objets (une poubelle dans la nuit, une poubelle un jour de pluie, une poubelle en plein soleil), il n'en a besoin que d'un seul muni de ses textures PBR. Voyez par exemple ce [colt](https://www.artstation.com/artwork/R3NbRW) et ses textures. ![Colt1](https://technoturtle.net/images/gun.jpg) ![Colt2](https://technoturtle.net/images/gun_pbr.jpg) ## Et Vulkan, dans tout ça ? ## L'API OpenGL avait fonctionné de manière exceptionnelle pendant des dizaines d'années, et avait réussi à évoluer, mais elle commençait vraiment à atteindre ses limites. dans un monde où le pipeline fixe n'existe plus, où tout repose sur des shaders, où les ordinateurs sont massivement multi-cœurs, ce n'était juste plus possible. L'API [Vulkan](https://fr.wikipedia.org/wiki/Vulkan_(API)) propose des primitives plus modernes, plus bas niveau. Un exemple : dans OpenGL, c'est l'API qui décide quand envoyer une texture vers la mémoire de la carte graphique et peut l'en retirer si la place manque. À l'affichage d'une trame, si la texture n'est pas chargée, il faudra la chercher dans la mémoire principale, ce qui peut provoquer des saccades dans l'affichage. Vulkan étant devenu la nouvelle référence, OpenSceneGraph se devait de réagir et de fournir une nouvelle bibliothèque plus appropriée.