Projet 2023-2024
Cette partie est en français car elle concerne les étudiants de l'école d'ingénieur Imac et les Master 2 Images de l'université Gustave Eiffel.
- Date de rendu: Dimanche 17 Mars 2024 23h59
- Une note de TDs sur 10 points, une note de projet sur 10 points
- Modalité:
- Ajouter une ligne à la spreadsheet fournie en TD en remplissant les colonnes:
- Nom
- Prénom
- Filière: Master ou Imac
- Lien repo git
- Ce repository doit être publique, ou privé mais me donnant un accès en "Developer"
- Mon profil Gitlab: https://gitlab.com/c2ba
- Binome: Nom Prénom de votre binome, si applicable
- Commit TD: hash Git de commit correspondant à votre rendu de TD
- Commit Project: hash Git de commit correspondant à votre rendu de projet (en théorie un commit plus récent que le précédent, puisque le projet se construit par dessus ce qui aura été fait en TD)
- Si vous n'avez plus le lien vers la spreadsheet, envoyer un mail à laurent.noel.c2ba@gmail.com
- Ajouter une ligne à la spreadsheet fournie en TD en remplissant les colonnes:
- A la racine du repertoire du repo: Rapport d'une à deux pages en pdf indiquant:
- Le ou les sujets choisis
- Comment utiliser votre viewer s'il a des spécificités
- Les difficultés rencontrées
- Les connaissances acquises en implémentant les features
- Votre projet doit compiler via la procédure utilisée en TD (
cmake_prepare,cmake_build) et utilisable a minima avec les deux modèles de test sponza et helmet.
Procédure de notation
J'assignerais une note de TD et une note de projet. Donc en théorie si vous finissez les TDs vous avez au moins 10.
J'utiliserais des scripts python et bash permettant de lancer votre viewer en mode "rendu to image" (https://gltf-viewer-tutorial.gitlab.io/drawing/#implement-the-output-functionnality) sur toutes les images du repo officiel de samples glTF.
Vous pouvez lancer vous même ces scripts afin de voir le résultat. Pour cela il faut déjà récupérer les modifications de la branche tutorial-v1 de mon repository:
1 2 | |
Vous ne devriez pas avoir de merge conflict en théorie, sinon fixez les ou appelez moi.
Ensuite lancez la commande:
1 | |
Ce script suppose que vous ayez a la racine un repertoire
gltf-sample-modelscontenant des modeles. Le plus simple est de cloner mais il vous faut assez de place sur votre machine:
1git clone https://github.com/KhronosGroup/glTF-Sample-Models gltf-sample-models
La commande de rendu va créer un repertoire output-images/{date-heure-minutes-secondes} contenant des images produites par votre viewer pour chaque modele 3D.
Voici une archive produite avec mon viewer en fin de TD. Votre viewer doit produire des images similaires lorsque je lance le script sur votre code en étant sur le commit de rendu de TD.
Votre viewer doit également produire des images en étant sur le commit de rendu de projet, mais différentes en fonction du sujet choisit. Ce script vous permettra de rapidement constater si votre viewer fonctionne comme attendu ou produit des artefacts visuels.
Apres avoir lancé le script, je lancerais votre viewer en interactif sur Sponza et Damaged Helmet pour voir si la caméra fonctionne comme prévu et si le rendu est correct en interactif.
Sujet
Le sujet de ce projet est assez simple: il consiste à améliorer le viewer glTF développé pendant les TPs. Pour cela, voici une liste de possibilités (détaillées plus bas avec des liens vers des tutoriaux en ligne) avec la difficulté associée (en nombre d'étoiles sur 3):
- Many lights *
- Normal mapping **
- Deferred Rendering et Post Process (SSAO, DOF) **
- Shadow Mapping ***
- PBR Lighting ***
Il faut choisir un de ces sujets et et l'implémenter entierement et correctement:
- Sur le fork de votre repo
- Code propre, structuré et factorisé, mais pas d'over enginerring
- Si la méthode implémentée à des paramètres, ils doivent être controlable via la GUI
- Si la méthode implémentée utilise des données intermédiaires sous forme de textures (shadow mapping, deferred rendering), elles doivent être visualisable via une option dans la GUI.
Un projet à difficulté plus élevée n'aura pas forcément une meilleure note mais sera notée de manière plus indulgente.
Vous pouvez choisir plusieurs sujets mais il ne faut pas s'éparpiller: d'abord en finir un, puis passer à un deuxième s'il vous reste du temps et l'envie.
Si aucun de ces sujets ne vous plait, vous pouvez m'envoyer un mail pour m'en proposer un autre.
Pensez à bien tester votre code sur plusieurs modèles 3D des glTF Sample models et de sketchfab.
Détails et resources en ligne
Normal mapping *
Le normal mapping consiste à utiliser une texture de normale pour rajouter artificiellement des détails aux objets. Le format glTF spécifie une normal map dans son materiaux, il faudra donc bien lire la documentation avant de se lancer dans le code.
Voici un bon tutorial en ligne pour implémenter cette fonctionnalité: Normal-Mapping
Le tuto détaille la méthode et donne également d'autres liens.
Une partie compliquée du processus est la récupération des données du glTF pour calculer les tangentes et bitangente. Heureusement vous pouvez prendre example sur la fonction computeSceneBounds de utils/gltf.cpp qui parcourt toutes les positions des meshs.
Many lights *
Ce sujet est composé de deux parties: - la gestion de tous les types de light glTF (point, directional, spot) - la gestion d'un nombre arbitraire de light
Ce tuto détaille chaque type de light: Light-casters
Ce tuto détaille une méthode pour en gérer plusieurs: Multiple-lights
Néammoins, la méthode décrite ne permet pas un nombre arbitraire (les tableaux de light ont une taille max). Si vous voulez aller plus loin, vous pourrez utiliser un Shader Storage Buffer Object pour stocker vos lights (à chercher sur le net).
Shadow Mapping **
Le shadow mapping consiste à utiliser la depth map d'un rendu du point de vue de la lumière pour calculer des ombres portées.
Le shadow mapping d'une lumière directionelle n'est pas très compliqué à implémenter et les deux tutos suivants peuvent être suivi:
Si vous avez en plus choisi de faire le sujet "many lights", vous pouvez implémenter le shadow mapping sur les points lights. Cela augmente la difficulté du sujet à 3 étoiles. Voici un tuto:
Deferred Rendering et Post Processing ***
Le deferred rendering est une technique consistant à splitter le rendu en deux parties: une partie "geometry", qui se contente de faire un rendu des propriétés de geometrie et materiaux et objets dans des textures intermédiaires (le GBuffer), et une partie "lighting" qui utilise le GBuffer pour faire le rendu final.
Cette technique n'est en soit pas très compliquée à implémenter, c'est pourquoi ce sujet comporte aussi une partie Post Processing, qui exploite les textures intermédiaires calculées par le deferred rendering pour rajouter des effets à l'image.
Le deferred rendering peut être implémenté en suivant les tuto:
Je conseille également de permettre à l'utilisateur de switcher entre forward rendering (le rendu comme on l'a fait jusqu'a présent) et deferred rendering. Cela vous obligera à garder votre ancien code fonctionnel.
Il faudra qu'il soit possible d'afficher les textures du GBuffer via une option de la GUI.
Pour ce qui est du post processing, il faudra au moins implémenter le Screen Space Ambiant Occlusion (SSAO), en suivant ce tuto:
Après ça vous etes libre d'implémenter d'autres effets post process comme: - le Bloom - le Depth of field en screen space (je n'ai pas de tuto mais ça doit se trouver facilement) - la detection et l'affichage de contours (pareil)
PBR Lighting ***
Le lighting PBR (physically based rendering) permet d'exploiter toute la puissance du modèle de materiaux glTF et ainsi obtenir un rendu vraiment réaliste.
Les deux tutos suivant donnent plus de détails sur le modèle de matériau PBR que l'on a implémenté, je conseille de les lire avant de passer à l'applicatif: - Theory - Lighting
C'est globalement le même modèle de materiaux que celui de glTF, avec peut être quelques différences mais rien de majeur.
La partie à implémenter est détaillée par les tutos suivants: - Diffuse-irradiance - Specular-IBL
Travail en binôme et Git
Si vous travaillez en binome vous allez probablement être amené à utiliser Git de manière plus avancé (branches, merge, etc).