Hedra implémente un moteur 3D open‑source complet avec OpenGL moderne

Contexte et portée du projet

Project Hedra est né d’un projet scolaire réalisé à 15 ans pour comprendre le fonctionnement d’OpenGL. Au fil de plusieurs années, le code a atteint environ 100 000 lignes et s’est transformé en un jeu‑engine complet supportant Linux et Windows. Le produit final propose un monde ouvert généré procéduralement, plus de 100 objets avec un système de rareté, quatre classes jouables, un arbre de compétences extensible et des quêtes générées dynamiquement. Aucun fichier de sauvegarde du monde n’est créé ; seul le seed et les inventaires du joueur sont persistés, ce qui impose une génération à la volée à chaque lancement.

Architecture du moteur et du rendu

Le cœur du moteur est écrit en C# et s’appuie sur une implémentation personnalisée d’un Entity Component System. Des allocateurs de type heap et stack, ainsi que des listes et tableaux natifs, sont fournis pour réduire les allocations automatiques du garbage collector pendant le rendu. Le rendu utilise OpenGL moderne : le WorldRenderer.cs ne nécessite que trois appels de dessin grâce à glMultiDrawElements, comme illustré ci‑dessous :

glMultiDrawElements(GL_TRIANGLES, countArray, GL_UNSIGNED_INT, offsetArray, drawCount);

Les techniques de post‑process incluent le Screen‑Space Reflections, le Screen‑Space Ambient Occlusion, le Bloom, le FXAA et le MSAA. La géométrie du monde repose sur un système de chunks infinis, chaque chunk étant converti en maillage via l’algorithme Marching Cubes appliqué à des voxels. Le maillage résultant est simplifié à la volée grâce à un LOD basé sur la distance à la caméra. Le moteur intègre également BulletPhysics pour la dynamique, OpenAL pour le son, et IronPython pour le scripting de mods.

Analyse des performances et limites

Le choix d’un rendu en draw‑call minimal (trois appels) réduit la surcharge du driver, mais la dépendance à glMultiDrawElements impose que les données soient pré‑agrégées dans des buffers contigus, ce qui peut compliquer la mise à jour dynamique des objets. La génération procédurale en temps réel, combinée à la reconstruction de maillages via Marching Cubes, consomme du CPU et du GPU ; aucune métrique de temps de génération n’est fournie, ce qui rend difficile l’évaluation de la scalabilité sur des machines modestes. L’absence de sauvegarde du monde limite la persistance des environnements, rendant le jeu moins adapté aux expériences multijoueurs persistantes, même si une implémentation UDP Hole‑Punching a existé auparavant.

Sur le plan de la maintenabilité, le projet propose plus de 1 000 tests unitaires et un framework de mock, ce qui indique une bonne couverture, mais la coexistence de modules C# et de scripts Python peut introduire des incompatibilités de version. Enfin, le support limité aux formats .PLY et .DAE (sans textures) simplifie le pipeline d’import mais restreint la richesse visuelle possible sans modifications supplémentaires.