Pourquoi les jeux modernes utilisent-ils une approche de rendu en texture pour les miroirs?

Lorsque vous regardez de vieux jeux comme Mario64 ou DukeNukem3D, tous les miroirs du jeu sont essentiellement des trous dans le mur avec une copie en miroir de la géométrie devant le miroir placé derrière eux. Dans le cas de DukeNukem3D, on peut même activer le mode No-Clip et entrer dans cette pièce en miroir.

En revanche, les jeux modernes utilisent une approche de rendu en texture pour les miroirs. Cela conduit à une nette pixellisation des miroirs lorsqu'ils se rapprochent d'eux. L'un des premiers jeux où j'ai remarqué cette approche était le Luigi's Mansion, mais il semble être utilisé dans presque tous les jeux modernes.

Quel changement dans le matériel ou les moteurs a rendu la deuxième approche si dominante de nos jours et quels en sont les avantages? En termes de graphismes purs, la première approche semble supérieure, car elle ne souffre pas de problèmes de pixelisation.

1. L’utilisation de RTT (render-to-text) permet d’échelonner facilement la qualité du rendu (résolution, niveau de détail, complexité de la lumière) pour des performances ajustables. Le RTT facilite également le remplacement de la surface par un cubemap à une certaine distance où il est difficile de voir le reflet de manière exacte.
2. Comme la sortie est une texture, il y a plus d'options concernant ce que l'on peut en faire par la suite (éclairage, ombrage, fusion, distorsion, etc.).
3. Si une version en miroir de la géométrie est placée dans la scène, cela nécessiterait une élimination plus complexe lorsqu'il intersecte la géométrie réelle et peut être vu derrière le coin. Dans les jeux plus anciens, les niveaux ont été conçus pour éviter cela. Sans oublier que quelqu'un doit faire la mise en miroir réelle.
4. Si la géométrie n'est pas mise en miroir manuellement, le rendu doit être effectué en modifiant la matrice de vue et le mode de sélection (pour compenser l'inversion d'espace dans la matrice), puis en utilisant le tampon de gabarit pour découper le miroir. Les moteurs modernes préfèrent créer tous les états de rendu à l'avance, ce qui pose un problème mineur lors de la copie de chaque état de rendu avec les modifications requises pour le rendu miroir.

Donc, utiliser RTT donne plus de liberté à tout le monde.

Non, vous avez tort - ce n'est pas ainsi que fonctionnaient les miroirs de Duke Nukem 3D.

DN3D a utilisé un moteur de portail . Un joint entre deux secteurs était dans une certaine mesure arbitraire, et lorsque le moteur de rendu est arrivé sur un portail, il a su qu'il devait commencer à transformer un autre secteur dans ce domaine. Le secteur derrière le rétroviseur était essentiellement un substitut pour faire face à une bizarrerie dans le moteur - le seul point du secteur était d'être plus gros que ce que vous aviez besoin de "refléter". Il ne contenait aucune géométrie réelle. En fait, cela fonctionnait à peu près de la même manière que les "portails" dans Portal - sauf que Portal (lui-même basé sur un moteur de portail) crée les portails au moment de l’exécution et limite le nombre de fois que les portails peuvent être renvoyés (c.-à-d. -> B -> A -> B -> A ...), alors que Build (DN3D) plantait simplement lorsque sa pile débordait si vous dirigiez un miroir vers un autre miroir.

Il est évident combien il est simple à mettre en œuvre un miroir qui - faire un portail des points dos dans la pièce. Cela signifiait que le rendu du miroir coûterait exactement le même prix que celui de la pièce elle-même, ce qui donnerait d'excellentes performances et une cohérence. Tant que vous n'avez pas dirigé un miroir sur un autre miroir, c'est. Si vous examinez le code source du moteur de génération, vous verrez qu'il n'y a pas de miroir de traitement du code - il n'en doit pas nécessairement exister, car c'est ainsi que fonctionnent les portails. REMARQUE: en réalité, il existe du code pour retourner les pixels rendus - il simplement ne pas retourner la géométrie et tous les différents sprites et effets. L'éditeur devait cependant être capable de créer ces "faux" portails - en se retournant. Si vous voulez en savoir plus sur le moteur de construction assez intelligent, Fabien Sanglard a réalisé une excellente analyse à la section Construction de moteurs internes. L’ensemble du moteur a été ouvert et transféré sur des plates-formes modernes, bien que l’ancien fonctionne toujours parfaitement sous Windows 10 (testé pour vous: P). De nombreux jeux basés sur Build ont également été open source et / ou refaits.

Pourquoi n'est-ce plus utilisé? Eh bien, certains moteurs ne préfèrent plus les portails, par exemple. Il est délicat d’appliquer beaucoup d’optimisations graphiques et d’optimisations - je ne peux vous indiquer d’aide spécifique, mais beaucoup de post-traitement dépend de piratages qui ne fonctionneraient pas dans un véritable moteur de portail (ils supposent beaucoup de choses. ne tient plus). C'est fondamentalement le même genre de problème que ces jeux ont avec l'imagerie stéréoscopique - les hacks ne fonctionnent plus.

Plus important encore, les miroirs sont devenus plus compliqués. Ils peuvent avoir des formes et des textures complexes, ils peuvent être au sol (également appelés "eau"), etc. Alors que tous ces problèmes peuvent être résolus dans un moteur de portail, RTT devient le choix le plus simple à un moment donné, et les GPU sont assez rapides pour le gérer.

Cependant, malgré tout cela, il existe de nombreux jeux avec accélération 3D matérielle qui font des choses "réelles". Parmi les jeux plus anciens, Quake 3 ou Alien vs. Predator, par exemple. Autant que je sache, les jeux à moteur Source utilisent encore de "vrais" miroirs. Si vous vous attendez à ce que les gens s'approchent du miroir et si vous pouvez garantir qu'il n'y aura pas trop de surfaces réfléchissantes en même temps (par exemple, grâce à la conception de niveaux), les miroirs de portail sont toujours très attractifs.

RTT aurait été utilisé si cela avait été possible, mais le pipeline de rendu matériel était à sens unique.

Les matériels plus anciens présentaient également des limitations empêchant le rendu de la texture. Ecrire en RAM signifie qu'il ne peut pas être lu en même temps. Pour améliorer les performances de rendu, le tampon de destination était verrouillé en écriture uniquement, seul le matériel d'affichage pouvait le lire. Vous pouvez demander la lecture, mais cela verrouille la RAM et le rendu doit attendre que le verrou se dégage avant de pouvoir commencer la trame suivante. RTT causerait un goulot d'étranglement majeur au pipeline et d'autres solutions ont donc été utilisées.

Vous constaterez que les pipelines de rendu matériel étaient la norme RTT car ils offraient un moyen de réduire la charge de rendu. Rendu 3D aux images-objets pour fournir un contenu pseudo-3D. Le rendu de la texture était beaucoup trop coûteux (CPU) pour être utilisé à l'époque, mis à part des machines spécialisées en dehors du marché grand public.

Duke Nukem résout le problème en remodelant la géométrie derrière le miroir, les autres réponses étant partiellement correctes. Il y a des zones derrière les miroirs qui ne contiennent aucune géométrie (dans les fichiers de données de jeu), la géométrie est restituée au moment de l'exécution, la raison de ces zones est d'éviter de placer accidentellement un morceau de niveau lors de l'édition du niveau. :

comme il y a une zone marquée, vous ne placerez pas accidentellement une géométrie dedans.