Le 13 novembre 2022 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.
Sommaire
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, 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, 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à.
Fausse 3D
De manière diamétralement opposée, certains jeux proposent de la fausse 3D. Par exemple, 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.
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 affiche un monde en 3D, mais les créatures sont des sprites.
Enfin, le raster
C'est probablement avec 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 a gagné.
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. 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 et 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 et ses textures.
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 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.
Aller plus loin
- Le site d'OpenSceneGraph (359 clics)
# Doom n’était pas en 3D
Posté par Anthony Jaguenaud . Évalué à 10.
Hello,
merci pour la rétrospective, juste un détail. Dans Doom, c’est la même technique que dans Wolfenstein. Avec quelques améliorations comme la hauteur du sol. Mais, on ne pouvait pas avoir d’étage par exemple. La technique c’est le ray-casting. Duke Nukem 3D a encore amélioré le système avec des scènes reliées par des portails permettant d’avoir l’impression que les pièces étaient superposées. Le premier à être 100% en 3D est bien Quake, mais c’est vrai pour les décors également, pas juste les monstres. Je ne considère pas le ray-casting comme de la 3D :-p.
[^] # Re: Doom n’était pas en 3D
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 8.
Et tout ceci est expliqué avec brio ici : https://twobithistory.org/2019/11/06/doom-bsp.html (en anglais)
[^] # Re: Doom n’était pas en 3D
Posté par small_duck (site web personnel) . Évalué à 6.
Merci pour ces précisions. J’ai également omis le rendu par voxel, utilisé par exemple par le jeu d’hélico Comanche, qui permettait de rendre de très beaux paysages et qui restait du ray casting. Technologie qui a été en grande partie abandonnée faute de support matériel.
[^] # Re: Doom n’était pas en 3D
Posté par Anthony Jaguenaud . Évalué à 6.
En Voxel, il y avait aussi l’excellent Magic Carpet… le gros avantage de cette technologie, c’est l’adaptation automatique à la machine, et que les décors extérieurs paraissaient infinie… À l’époque ce n’était pas envisageable autrement.
Merci pour tous les souvenirs que ça fait ressurgir ;-)
# Descent (1995)
Posté par Moonz . Évalué à 10. Dernière modification le 22 novembre 2022 à 09:23.
Avant Quake, je me souviens de Descent (wikipedia me confirme qu’il est sorti un an avant Quake, en 1995)
[^] # Re: Descent (1995)
Posté par WrathOfThePixel . Évalué à 2.
Et encore avant ça, il y avait le moteur Freescape d'Incentive Software sur 8/16 bits, et son outil de création 3D Construction Kit rendu disponible par les développeurs.
# SIMD et shaders
Posté par jseb . Évalué à 5.
Un paragraphe présente le SIMD comme la technologie au cœur des cartes 3D (les fameux « shaders »).
Les shaders me paraissent différents: ils sont sourds, muets et aveugles à leur voisin.
Un registre SIMD est situé dans le processeur. Cela existe sur toute les architectures majeures. Côté Intel(tududududuu™), cela a commencé avec MMX en précision fixe, puis SSE en flottant, puis AVX (amélioration du SSE pouvant traiter jusqu'à 64 octets simultanément).
Le registre SIMD, contrairement à un shader, n'est pas sourd/muet/aveugle à ses voisins. Il peut être découpé en types de taille variable (integers, float, double…).
Les opérations sur les registres permettent l'application de masques (pour trouver par exemple une donnée initialisée à traiter) ou d'opérations mathématique (saturation lors d'un calcul d'un type contenu dans le registre, ou au contraire report, entre autres).
Le shader est limité à ce qu'il reçoit, et ne communique pas avec ses voisins.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
# OpenGL
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Il me semble qu'OpenGL avait plutôt bien négocié le virage "shaders" et que ce n'est pas ce qui a motivé la création de Vulkan.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: OpenGL
Posté par rewind (Mastodon) . Évalué à 10.
Ce qui a motivé Vulkan, c'est d'une part l'architecture globale d'OpenGL : une machine a états opaque, c'était sans doute bien au début des années 90, ça ne l'est plus du tout aujourd'hui. Et d'autre part les architectures parallèles : faire de l'OpenGL sur plusieurs threads, c'est quasiment impossible, et c'est pas fait pour ça.
Après, l'origine de Vulkan, c'est… Mesa. Et en particulier Gallium3D qui proposait une API très bas niveau pour l'abstraction des cartes graphiques sur laquelle venait se brancher les API haut niveau (OpenGL) via un state tracker. AMD a proposé une API de même niveau et reprenant les mêmes concepts (Mantle) et c'est ce qui a servi de base à Vulkan. Pendant ce temps, MS faisait de même de son côté avec Direct3D 12.
Les shaders sont présents dans OpenGL (et OpenGL ES) depuis plus de 15 ans maintenant je pense (GLSL 1 c'est 2004 dans OpenGL 2).
# Fil de fer ?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Puisque on en parle, quelqu'un parmi vous pourrait-il m'indiquer une bibliothèque utilisable depuis le C (voire même le Fortran moderne) pour faire de la 3D "fil de fer" sur un carte graphique de base ?
Et si elle gère les faces cachées, ça serait encore mieux :)
[^] # Re: Fil de fer ?
Posté par small_duck (site web personnel) . Évalué à 4. Dernière modification le 26 novembre 2022 à 16:05.
J'aurais envie de dire, avec un OpenGL de base et les options fil de fer
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE)et de face culling (par défaut à ma connaissance). Ou alors, si le C++ est une option, carrément avec OpenSceneGraph et le PolygonMode qui va bien.Après, peut-être est-ce qu'il y a mieux ?
[^] # Re: Fil de fer ?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Mais dans ce cas, on perd la possibilité d'un rendu purement logiciel. Alors que je voudrais aussi utiliser ce code pour des écrans spéciaux sans GPU,
comme un Raspi Pico connecté à un mini écran LCD.
Ceci dit, un ami m'a conseillé de regarder small 3d lib, que je ne connaissais pas, et que je vais explorer. Par contre, je ne sais pas si il y a des fonctions spécialisée en fil-de-fer…
[^] # Re: Fil de fer ?
Posté par Pol' uX (site web personnel) . Évalué à 3.
Non.
Adhérer à l'April, ça vous tente ?
[^] # Re: Fil de fer ?
Posté par Guillaum (site web personnel) . Évalué à 3.
Mesa support très bien le rendu "software".
# Commentaire supprimé
Posté par Anonyme . Évalué à -1. Dernière modification le 27 novembre 2022 à 18:48.
Ce commentaire a été supprimé par l’équipe de modération.
# 3dfx
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 5.
Une petite pensée pour la 3dfx et Glide…
# Dungeon Master ...
Posté par dcp . Évalué à 4.
J'ai failli pleurer en voyant l'image de Dungeon Master :-)
Merci pour les souvenirs. Me reviennent quand même à l'esprit certains jeux en 3D surfaces pleines sur mon viel ST : Stunt Car Racer, Frontier Elite, Vroom …
[^] # Re: Dungeon Master ...
Posté par omc . Évalué à 4. Dernière modification le 09 décembre 2022 à 07:01.
Oui moi aussi, ça m'a fait quelque chose de voir cette image… mais j'ai plutôt ressenti de l'angoisse. Ce jeu était super flippant, surtout pour qui souffre de claustrophobie notoire :-)
# Alone in the Dark
Posté par Buf (Mastodon) . Évalué à 8.
Il y a eu un autre type de rendu intermédiaire qui n'est pas mentionné dans la dépêche, utilisé entre autres par Alone in the Dark (sorti en 1992). Ici, le personnage, les ennemis et les objets sur lesquels on peut agir sont en vraie 3D avec un rendu temps réel, et les décors sont précalculés (et donc gérés comme de simples images 2D), avec des positions de caméra fixes.
À l'époque, l'animation des personnages était une vraie révolution, avec des mouvements parfaitement fluides de modèles 3D.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.