Accueil » Dossier » Doom III : Behind the scenes » Page 3

Doom III : Behind the scenes

1 : Introduction, historique 2 : Historique, suite 4 : Technologie : le Per Pixel Lighting 5 : Les code path 6 : Conclusion

Technologie : les Shadow Volumes

Vous ne pouvez pas y échapper : la première chose qui frappe lorsque l’on regarde Doom III par rapport aux autres jeux c’est sa gestion extrêmement réaliste des ombres. Pour cela Carmack s’appuie sur un algorithme découvert en 1977 appelé volume d’ombre. Le principe est simple : un volume d’ombre est tout simplement le demi espace défini par une source lumineuse et un objet projetant une ombre, toute surface dans le volume d’ombre n’est pas affectée par l’éclairage de la source lumineuse en question. La façon dont cet algorithme est implémenté dépasse le cadre de cet article toutefois il est assez facile d’avoir une idée intuitive de son fonctionnement tant que l’on n’entre pas dans le détail.
La première partie de l’algorithme consiste tout d’abord à déterminer le volume d’ombre, ce n’est pas évident. En fait ça consiste à trouver la silhouette de l’objet du point de vue de la source lumineuse (cette étape est effectuée par le CPU) puis à la projeter à partir de la position de la lumière (peut être effectué dans un vertex program). La scène est ensuite rendue en deux passes : d’abord avec la source lumineuse activée en mettant à jour uniquement les fragments dans la région éclairée, puis avec la source lumineuse désactivée en mettant à jour les fragments dans l’ombre. Mais comment contrôler la mise à jour de ces régions ? Et bien dans la pratique on pose un tag pour différencier les fragments. C’est là qu’entre en jeu le stencil buffer. La scène est tout d’abord rendue de façon classique en mettant le stencil à zéro, ensuite le volume d’ombre est ensuite rendu mais en désactivant l’écriture dans le frame et le depth buffer en se contentant juste d’inverser le stencil buffer lorsque le test de profondeur passe (la face du volume d’ombre est devant l’objet). Ainsi il est possible de différencier les fragments éclairés (dont le stencil contient 0) des fragments dans l’ombre (dont le stencil contient 1).
Un schéma valant mieux que de longs discours voici le principe :


Voilà pour le principe de base, en pratique ça ne fonctionne que pour les volumes d’ombres ne se chevauchant pas ce qui est assez rare. Dans ce cas au lieu d’utiliser une simple inversion l’algorithme se complexifie et il faut compter le nombre de fois où l’on entre dans un volume d’ombre et le nombre de fois d’où l’on en sort (il faut donc effectuer deux passes une pour les faces avant « on rentre dans le volume d’ombre » on incrémente le stencil et une pour les faces arrières « on sort du volume d’ombre » on décrémente le stencil).
Et c’est tout ? Non évidemment ce serait bien trop simple dans la pratique bien des problèmes se posent en particulier l’intersection du volume d’ombre censé être un demi espace donc s’étendant à l’infini avec les plans de clipping. Les plans de clipping peuvent supprimer les polygones du volume d’ombre réduisant notre bel algorithme à néant. Plusieurs solutions ont été proposées mais ce serait bien trop long à expliquer et assez technique à décrire : le but de cet article est de comprendre grossièrement comment fonctionne Doom III ce n’est pas un tutorial sur la façon de faire des ombres réalistes. Sachez juste que Carmack lors de ses travaux préliminaires sur Doom III a proposé une solution connue sous le nom de « Carmack’s reverse ».
Cette méthode de calcul des ombres est certes très impressionnante mais elle présente quand même plusieurs défauts que certains jugent particulièrement gênants. D’une part elle ne permet pas de produire ce que l’on appelle des ombres douces c’est-à-dire des ombres dont le contour est diffus. Les ombres de Doom III sont très nettes et accentuent en partie le deuxième défaut : un nombre de polygones utilisés pour les personnages relativement peu élevé, défaut qui n’a de cesse d’être pointé du doigt à chaque nouvelle fournée de screenshots.
Il faut savoir à ce propos que les personnages utilisent entre 2000 et 6000 polygones ce qui reste très raisonnable, augmenter le nombre de polygones de nos jours n’est plus vraiment un problème : les processeurs graphiques disposent de suffisamment de ressources au niveau de la partie T&L pour traiter un très grand nombre de sommet alors pourquoi un programmeur de génie comme John Carmack est-il obligé de se limiter à ce niveau ? Tout simplement à cause de l’algorithme expliqué ci-dessus : augmenter le nombre de polygones du modèle n’est certes pas un problème mais ce n’est que la face cachée de l’iceberg : une telle augmentation complexifiera énormément la calcul de la silhouette en augmentant le nombre d’arêtes à examiner pour la déterminer et il ne faut pas perdre de vue que ce calcul est effectué par le CPU ! Et qui dit plus d’arêtes dans la silhouette dit aussi plus de fill rate consommé lors du rendu des volumes d’ombre. Bref cette amélioration a priori triviale a des conséquences bien plus importantes qu’il n’y paraît au premier abord sur les performances et il est évident que Carmack a étudié tout ça de près pour trouver le meilleur compromis.
Les fonctions matérielles nécessaires pour implémenter cet algorithme sont réduites : il suffit d’un stencil buffer (apparu sur certain chips Dx5 comme le Permedia 2 démocratisé sur l’ensemble des chips Dx6).

Sommaire :

  1. Introduction, historique
  2. Historique, suite
  3. Technologie : les Shadow Volumes
  4. Technologie : le Per Pixel Lighting
  5. Les code path
  6. Conclusion