Un moteur de rendu logiciel en 500 lignes de C++ pur

• Implémentation d’un moteur de rendu logiciel à partir de zéro, sans bibliothèque graphique externe, pour comprendre le fonctionnement interne d’OpenGL, Vulkan, Metal et DirectX
• Transformation d’un modèle 3D en image, à partir d’un maillage de triangles et de textures ; l’implémentation d’une GUI ou d’une application GPU n’est pas abordée
• Le code final compte environ 500 lignes, et les étudiants mettent généralement 10 à 20 heures avant de commencer à obtenir un moteur de rendu fonctionnel
• Seules une classe de traitement TGA prenant en charge RGB, RGBA et les niveaux de gris, ainsi qu’une fonction de définition d’un pixel unique, sont fournies ; le tracé de segments et de triangles doit être implémenté directement
• Pour comprendre les concepts de rendu et saisir le fonctionnement interne des bibliothèques 3D, il faut écrire le code soi-même plutôt que copier le code final

---

Construire soi-même un pipeline de rendu

• Apprentissage du fonctionnement du pipeline de rendu en suivant librement la structure des bibliothèques graphiques 3D modernes
  • Plutôt que d’apprendre à écrire une application GPU, on reproduit le fonctionnement interne avec un moteur de rendu logiciel
  • L’entrée est un modèle 3D composé d’un maillage de triangles et de textures, et la sortie est une image rendue
  • Le programme génère un fichier image sans interface graphique
• Utilisation du format d’image simple TGA afin de réduire les dépendances externes
  • Les seules fonctionnalités fournies au départ sont le chargement et l’enregistrement d’images, ainsi que la définition de la couleur d’un seul pixel
  • Aucune fonction intégrée ne permet de tracer des segments ou des triangles : tout doit être écrit à la main
• L’exemple de départ crée un framebuffer RGB 64x64, définit en blanc les pixels de trois coordonnées, puis l’enregistre sous framebuffer.tga
  • Les valeurs de couleur sont indiquées dans l’ordre BGRA

Build et exécution du code

• L’implémentation complète est disponible dans le dépôt tinyrenderer sur GitHub, et le code source initial fourni aux étudiants est également publié séparément
• Build et exécution avec les commandes suivantes

git clone https://github.com/ssloy/tinyrenderer.git &&
cd tinyrenderer &&
cmake -Bbuild &&
cmake --build build -j &&
build/tinyrenderer obj/diablo3_pose/diablo3_pose.obj obj/floor.obj

• Le résultat de l’exécution est enregistré dans framebuffer.tga
• Même si le code final compte environ 500 lignes, le processus d’implémentation soi-même est essentiel à la compréhension des concepts ; il n’est donc pas recommandé d’utiliser tel quel le code fourni

[GN⁺]

Avis sur Hacker News

• Il y a quelques mois, j’ai implémenté moi-même un moteur de rendu logiciel en Rust, sans LLM, puis ajouté un petit jeu ainsi qu’un shader pixelisé et un effet d’aberration chromatique sur les bords d’une lampe torche
  https://github.com/kshitijl/tinyrenderer-rs
  Le dépôt contient beaucoup de captures d’écran du processus de développement et de bugs visuels amusants. J’ai beaucoup appris, non seulement sur les principes du rendu, mais aussi sur le fait que les CPU modernes sont extrêmement rapides et qu’un moteur de rendu CPU monothread peut faire tourner un jeu 3D interactif avec des effets spéciaux spectaculaires
  • Je me demande pourquoi il dépend de wgpu alors que c’est un moteur de rendu logiciel
  • Je me demande s’il est vraiment nécessaire d’ajouter jusqu’à un ECS quand on écrit la logique d’un jeu en Rust
• Cette ressource et Mathematics for Computer Graphics de John Vince ont été indispensables pour créer mon moteur de rendu logiciel
  C’était avant les LLM, donc cela m’a pris au moins deux mois, passés en grande partie à comprendre les maths de l’infographie et à traquer des erreurs de segmentation en C
  • Je me demande combien d’heures par jour tu y as consacré pendant ces quelques mois
• Je me demande si le livre de Foley et Van Dam reste la référence majeure du domaine. Il a été révisé en 2013, mais je connais mieux l’édition de 1982, centrée sur la 2D, qui était à l’époque un peu la bible de l’infographie
  • Je ne l’ai pas rouvert depuis longtemps ; pour moi, il s’apparente surtout à une encyclopédie singulière ayant une valeur historique
    Les notes de cours sur ce GitHub étaient meilleures pour réviser les concepts. Je n’aime pas le style du code du dépôt, et le rasterizer à l’ancienne est aussi trop simple et inefficace, mais je trouve tout de même le tout plus agréable à lire que le livre de Foley
  • Moi aussi, j’ai appris avec la 2e édition et je possède aussi la dernière édition de 2013, qui est correcte
    Au fil des éditions, le langage utilisé est passé de Pascal à C, puis à C et C++, et la dernière édition contient aussi un peu de C#. Plusieurs concepts récents manquent, mais je pense qu’il reste encore beaucoup de contenu précieux
• J’aimerais qu’au moins un tutoriel de moteur de rendu logiciel traite correctement du clipping des triangles. Dans un moteur de rendu pratique, même pour une scène de base, il faut absolument gérer les cas où la géométrie intersecte le frustum de vue, mais c’est personnellement la partie que je trouve la plus difficile
  • Un chapitre entier traite de ce sujet : https://gabrielgambetta.com/computer-graphics-from-scratch/11-clipping.html
  • Le clipping des triangles n’est nécessaire que lorsque l’interpolation des attributs de très grands triangles est importante, et il existe deux approches : rejeter rapidement ou synthétiser des primitives
    Le clipping au frustum peut être géré par une sélection de points sur des tuiles locales, et la synthèse de primitives est plus simple si l’on traite le rectangle de clipping transformé inversement dans le système de coordonnées barycentriques. On peut contrôler les erreurs d’arrondi avec de la double précision ou du point fixe, et la principale difficulté consiste à régénérer les valeurs Z et 1/Z des nouveaux sommets. Avec un rasterizer à synthèse différée des attributs, le reste traverse naturellement le pipeline ; on peut voir des exemples dans l’implémentation open source d’OpenSWR.org
  • Moi aussi, je suis longtemps resté bloqué à l’étape « il faut implémenter le clipping », mais j’ai fini par écrire du code qui fonctionnait sans grande difficulté, avant de découvrir plus tard que j’avais redécouvert indépendamment l’algorithme de Sutherland–Hodgman
    Le plus grand obstacle psychologique est le manque de familiarité avec l’espace projectif et les coordonnées homogènes. Les six plans de l’espace de clipping sont simples : x = ±w, y = ±w, z = ±w. Il suffit de parcourir chaque arête du polygone, de déterminer si ses deux extrémités sont à l’intérieur ou à l’extérieur, puis d’interpoler linéairement la position du point d’intersection avec la frontière et les attributs du sommet. En appliquant ce processus successivement à tous les plans, le triangle devient un polygone convexe de 9 sommets au maximum, facile à retrianguler. En précalculant les outcodes, on peut éviter le clipping des triangles entièrement à l’intérieur ou à l’extérieur
    Article : https://dl.acm.org/doi/10.1145/360767.360802
• Dans un environnement moderne, le C++ pur n’existe pratiquement pas. On ne peut pas produire une image en écrivant directement dans les registres et la VRAM comme sur les ordinateurs des années 1980 ; au final, on dépend d’énormément de code au-dessus d’épaisses couches d’API, de pilotes et de firmware
• Par nostalgie des années 1990, je me remets au rendu logiciel, en mélangeant des banques CLUT à la manière de la 2D avec des techniques modernes de triangles classés par intervalles et de coordonnées barycentriques
  En conservant une forme de pipeline fixe, on peut traiter un nombre étonnant de triangles avec des fonctions de dessin assez simples
• J’ai découvert un bug de traitement d’OpenMP sur macOS et j’ai soumis mon premier PR à ce dépôt depuis très longtemps