Ombrage physique - éclairage ambiant / indirect

J'ai implémenté un traceur de chemin basé physiquement après avoir étudié le PBRT par M. Pharr et G. Humphreys. Maintenant, j'essaie d'appliquer un rendu basé physiquement à des graphiques en temps réel à l'aide d'OpenGL ES (dans une application iPhone).

Je veux commencer à utiliser Oren-Nayar et Cook-Torrance comme BRDF diffus et spéculaire mais j'ai un problème: comment modéliser l'éclairage indirect?

Dans un traceur de chemin (comme celui contenu dans pbrt), la lumière indirecte / ambiante est fournie "automatiquement" par l'algorithme de traçage de chemin, car elle suit le chemin des rayons lumineux en tenant compte de l'éclairage direct et indirect.

Comment modéliser l'éclairage indirect dans un rendu physique écrit en OpenGL ES, donc en utilisant des graphiques informatiques en temps réel?

Les graphiques en temps réel déploient une variété d'approximations pour faire face aux dépenses de calcul liées à la simulation de l'éclairage indirect, en faisant le compromis entre les performances d'exécution et la fidélité de l'éclairage. Il s'agit d'un domaine de recherche active, avec de nouvelles techniques qui apparaissent chaque année.

Éclairage ambiant

À l'extrémité la plus simple de la gamme, vous pouvez utiliser l'éclairage ambiant : une source de lumière globale et omnidirectionnelle qui s'applique à tous les objets de la scène, sans égard aux sources de lumière réelles ou à la visibilité locale. Ce n'est pas du tout exact, mais c'est extrêmement bon marché, facile à modifier pour un artiste, et peut sembler correct en fonction de la scène et du style visuel souhaité.

Les extensions courantes de l'éclairage ambiant de base incluent:

• Faites varier la couleur ambiante en direction, par exemple en utilisant des harmoniques sphériques (SH) ou un petit cubemap , et en recherchant la couleur dans un shader en fonction du vecteur normal de chaque sommet ou pixel. Cela permet une certaine différenciation visuelle entre des surfaces d'orientations différentes, même lorsqu'aucune lumière directe ne les atteint.
• Appliquer des techniques d' occlusion ambiante (AO) , y compris le sommet AO pré-calculé, les cartes de texture AO, les champs AO et l'espace AO d'espace d'écran (SSAO) . Tout cela fonctionne en essayant de détecter des zones telles que les trous et les crevasses où la lumière indirecte est moins susceptible de rebondir et en assombrissant la lumière ambiante.
• Ajoutez un cubemap d'environnement pour fournir une réflexion spéculaire ambiante. Un cubemap avec une résolution décente (128² ou 256² par face) peut être assez convaincant pour les spéculaires sur des surfaces courbes et brillantes.

Éclairage indirect cuit

Le "niveau" suivant, pour ainsi dire, des techniques implique la cuisson (pré-calcul hors ligne) d'une certaine représentation de l'éclairage indirect dans une scène. L'avantage de la cuisson est que vous pouvez obtenir des résultats de très bonne qualité pour de petites dépenses de calcul en temps réel, car toutes les parties dures sont effectuées pendant la cuisson. Les compromis sont que le temps nécessaire au processus de cuisson nuit au taux d'itération des concepteurs de niveau; davantage de mémoire et d'espace disque sont nécessaires pour stocker les données précalculées; la possibilité de modifier l'éclairage en temps réel est très limitée; et le processus de cuisson ne peut utiliser que les informations de la géométrie de niveau statique, de sorte que les effets d'éclairage indirect d'objets dynamiques tels que des personnages seront manqués. Pourtant, l'éclairage cuit est très largement utilisé dans les jeux AAA aujourd'hui.

L'étape de cuisson peut utiliser n'importe quel algorithme de rendu souhaité, y compris le traçage de chemin, la radiosité, ou utiliser le moteur de jeu lui-même pour rendre des cubemaps (ou des hémicubes ).

Les résultats peuvent être stockés dans des textures ( lightmaps ) appliquées à la géométrie statique dans le niveau, et / ou ils peuvent également être convertis en SH et stockés dans des structures de données volumétriques, telles que des volumes d'irradiance (textures de volume où chaque texel stocke une sonde SH) ou mailles tétraédriques . Vous pouvez ensuite utiliser des shaders pour rechercher et interpoler les couleurs de cette structure de données et les appliquer à votre géométrie rendue. L'approche volumétrique permet d'appliquer un éclairage cuit aux objets dynamiques ainsi qu'à la géométrie statique.

La résolution spatiale des lightmaps etc. sera limitée par la mémoire et d'autres contraintes pratiques, vous pouvez donc compléter l'éclairage cuit avec certaines techniques AO pour ajouter des détails à haute fréquence que l'éclairage cuit ne peut pas fournir et pour répondre aux objets dynamiques (comme assombrir la lumière indirecte sous un personnage ou un véhicule en mouvement).

Il existe également une technique appelée transfert de rayonnement précalculé (PRT) , qui étend la cuisson pour gérer des conditions d'éclairage plus dynamiques. Dans PRT, au lieu de cuire l'éclairage indirect lui-même, vous cuisez la fonction de transfert d'une source de lumière, généralement le ciel, à l'éclairage indirect résultant de la scène. La fonction de transfert est représentée comme une matrice qui transforme les coefficients SH source vers destination à chaque point d'échantillon de cuisson. Cela permet de changer l'environnement d'éclairage et l'éclairage indirect de la scène répondra de manière plausible. Far Cry 3 et 4 ont utilisé cette technique pour permettre un cycle jour-nuit continu, avec un éclairage indirect variant en fonction des couleurs du ciel à chaque heure de la journée.

Un autre point concernant la cuisson: il peut être utile d'avoir des données de cuisson séparées pour un éclairage indirect diffus et spéculaire. Les cubemaps fonctionnent beaucoup mieux que SH pour les spéculaires (car les cubemaps peuvent avoir beaucoup plus de détails angulaires), mais ils occupent également beaucoup plus de mémoire, vous ne pouvez donc pas vous permettre de les placer aussi densément que les échantillons SH. La correction de parallaxe peut être utilisée pour compenser quelque peu cela, en déformant heuristiquement le cubemap pour que ses réflexions soient plus ancrées dans la géométrie qui l'entoure.

Techniques entièrement temps réel

Enfin, il est possible de calculer un éclairage indirect entièrement dynamique sur le GPU. Il peut répondre en temps réel à des changements arbitraires d'éclairage ou de géométrie. Cependant, là encore, il existe un compromis entre les performances d'exécution, la fidélité de l'éclairage et la taille de la scène. Certaines de ces techniques nécessitent un GPU costaud pour fonctionner, et ne sont réalisables que pour des tailles de scène limitées. Ils ne prennent également généralement en charge qu'un seul rebond de lumière indirecte.

• Un cubemap d'environnement dynamique, où les faces du cubemap sont restituées chaque image à l'aide de six caméras regroupées autour d'un point choisi, peut fournir des réflexions ambiantes décemment bonnes pour un seul objet. Ceci est souvent utilisé pour la voiture du joueur dans les jeux de course, par exemple.
• Illumination globale de l'espace écran , une extension de SSAO qui rassemble un éclairage indirect des pixels voisins sur l'écran dans une passe de post-traitement.
• La réflexion par rayons tracés de l'espace écran fonctionne en faisant défiler les rayons à travers le tampon de profondeur dans un post-passage. Il peut fournir des réflexions de très bonne qualité tant que les objets réfléchis sont à l'écran.
• La radiosité instantanée fonctionne en traçant des rayons dans la scène à l'aide du processeur et en plaçant une lumière ponctuelle à chaque point d'impact de rayon, qui représente approximativement la lumière réfléchie sortante dans toutes les directions à partir de ce rayon. Ces nombreuses lumières, appelées lumières ponctuelles virtuelles (VPL), sont ensuite restituées par le GPU de la manière habituelle.
• Les cartes d'ombres réfléchissantes (RSM) sont similaires à la radiosité instantanée, mais les VPL sont générées en rendant la scène du point de vue de la lumière (comme une carte d'ombres) et en plaçant un VPL à chaque pixel de cette carte.
• Les volumes de propagation de la lumière sont constitués de grilles 3D de sondes SH placées sur toute la scène. Les RSM sont rendus et utilisés pour «injecter» de la lumière de rebond dans les sondes SH les plus proches des surfaces réfléchissantes. Ensuite, un processus de type inondation propage la lumière de chaque sonde SH vers les points environnants de la grille, et le résultat est utilisé pour appliquer un éclairage à la scène. Cette technique a également été étendue à la diffusion volumétrique de la lumière .
• Le traçage du cône de Voxel fonctionne en voxélisant la géométrie de la scène (probablement en utilisant différentes résolutions de voxel, plus fin près de la caméra et plus grossier très loin), puis en injectant la lumière des RSM dans la grille de voxel. Lors du rendu de la scène principale, le pixel shader effectue une "trace de cône" - une marche des rayons avec un rayon qui augmente progressivement - à travers la grille de voxels pour recueillir la lumière entrante pour un ombrage diffus ou spéculaire.

La plupart de ces techniques ne sont pas largement utilisées dans les jeux aujourd'hui en raison de problèmes d'évolution vers des tailles de scène réalistes ou d'autres limitations. L'exception est la réflexion de l'espace écran, qui est très populaire (bien qu'elle soit généralement utilisée avec les cubemaps comme solution de rechange, pour les régions où la partie espace écran échoue).

Comme vous pouvez le voir, l'éclairage indirect en temps réel est un sujet énorme et même cette réponse (plutôt longue!) Ne peut fournir qu'une vue d'ensemble et un contexte de 10000 pieds pour une lecture plus approfondie. L'approche qui vous convient le mieux dépendra en grande partie des détails de votre application particulière, des contraintes que vous êtes prêt à accepter et du temps dont vous disposez.

Il s'agit du principal problème «difficile» qui subsiste dans la CG en temps réel, et de nombreuses recherches sont en cours pour le résoudre.

Le plus grand obstacle est que dans les graphiques raster, chaque composant de la scène est rendu `` dans le vide '' - chaque triangle est rendu sans référence à aucun autre triangle de la scène, et il en va de même pour les pixels, contrairement aux approches de lancer de rayons où chaque rayon a accès à la scène entière en mémoire. Les programmeurs en temps réel doivent donc utiliser des astuces pour faire des trucs comme des reflets et des ombres, et il en va de même pour l'éclairage global.

Une méthode d'exécution bon marché consiste à utiliser des cartes de lumière cuites au four, où vous exécutez d'abord quelque chose de lent mais impressionnant comme la radiosité ou le traçage hors ligne, puis enregistrez les informations d'éclairage avec vos données de sommet habituelles. Ceci est idéal pour la géométrie statique, mais devient problématique dès que vous ajoutez des objets en mouvement. Michal Iwanicki a fait une bonne présentation sur la façon dont ils ont résolu cela pour «The Last of Us».

Les harmoniques sphériques sont beaucoup utilisées dans les moteurs de jeu pour représenter la lumière indirecte. Il s'agit essentiellement d'une transformée de Fourier à travers la surface d'une sphère, en éliminant les composants haute fréquence, vous pouvez obtenir un éclairage d'environnement visuellement agréable et surtout précis en seulement 9 coefficients par couleur. Unity, par exemple, utilise SH pour cuire des «sondes de lumière» à différents points de la scène, les objets en mouvement peuvent alors interpoler entre les sondes proches pour obtenir une approximation de la lumière indirecte à leur position. Le papier de Robin Green est fondamentalement la Bible sur cette technique, mais c'est assez lourd.

La technique chaude en ce moment semble être le Voxel Cone Tracing, qui n'implique aucune étape de pré-cuisson. Je ne le connais pas trop moi-même, mais si je comprends bien, cela implique de voxéliser votre scène dans un monde de style Minecraft basse résolution, de placer les voxels dans une structure spatiale rapidement traversable comme un octree, puis d'en jeter quelques-uns de large rayons (cônes) de chaque point et vérifier quels voxels ils frappent pour recueillir l'éclairage de rebond. NVidia pousse cela assez fort en ce moment, et il y a des papiers là- dessus ici et ici .

J'espère que cela pourra aider :)

Le traçage de chemin est un algorithme très coûteux en calcul, et ne convient pas au temps réel. L'architecture de PBRT n'est pas non plus adaptée au temps réel, l'objectif principal de PBRT est de résoudre l'équation de rendu, en utilisant une intégration Monte Carlo non biaisée. Voir https://en.wikipedia.org/wiki/Unbias_rendering pour plus d'informations.

Sans beaucoup d'optimisation et de contraintes, je doute que vous puissiez atteindre des performances décentes sur un appareil mobile.

Dans tous les cas, le traçage de chemin peut être implémenté en OpenGL, je suggérerais de chercher des shaders de calcul qui sont très puissants. OpenGL ES 3.1 prend en charge les shaders de calcul avec quelques limitations mineures, contrairement à Desktop GL.

Lisez cette page pour obtenir plus d'informations: https://github.com/LWJGL/lwjgl3-wiki/wiki/2.6.1.-Ray-tracing-with-OpenGL-Compute-Shaders-(Part-I)

Bonne chance!