Si vous êtes développeur de jeux 3D, vous avez probablement déjà rencontré les termes. rendu en avant et rendu différé dans votre recherche de moteurs graphiques modernes. Et, souvent, vous devrez en choisir un à utiliser dans votre jeu. Mais que sont-ils, en quoi sont-ils différents et lequel faut-il choisir??
Rendu différé pour de nombreuses lumières (Image reproduite avec la permission de Hannes Nevalainen)Pour commencer, nous devons comprendre un peu les pipelines graphiques modernes ou programmables..
À l'époque, nous étions limités par le pipeline graphique de la carte vidéo. Nous ne pouvions pas changer la façon dont il dessinait chaque pixel, mis à part l'envoi d'une texture différente, et nous ne pouvions pas déformer les sommets une fois qu'ils étaient sur la carte. Mais les temps ont changé et nous avons maintenant pipelines graphiques programmables. Nous pouvons maintenant envoyer du code sur la carte vidéo pour modifier l'apparence des pixels, leur donner une apparence cahoteuse avec des cartes normales et ajouter de la réflexion (et beaucoup de réalisme).
Ce code est sous la forme de géométrie, sommet, et shaders de fragments, et ils changent essentiellement la façon dont la carte vidéo rend vos objets.
Le rendu direct est la technique de rendu standard prête à l'emploi que la plupart des moteurs utilisent. Vous fournissez à la carte graphique la géométrie, elle la projette et la décompose en sommets, puis ceux-ci sont transformés et divisés en fragments, ou pixels, qui obtiennent le traitement de rendu final avant d'être transmis à l'écran..
Il est assez linéaire et chaque géométrie est passée dans le tuyau une par une pour produire l’image finale..
Dans le rendu différé, comme son nom l'indique, le rendu est légèrement différé jusqu'à ce que toutes les géométries soient passées dans le canal. l'image finale est ensuite produite en appliquant un ombrage à la fin.
Maintenant, pourquoi ferions-nous cela?
L'éclairage est la raison principale pour choisir un itinéraire par rapport à l'autre. Dans un pipeline de rendu direct standard, les calculs d'éclairage doivent être effectués sur chaque sommet et sur chaque fragment de la scène visible, pour chaque lumière de la scène..
Si vous avez une scène avec 100 géométries et que chaque géométrie a 1 000 sommets, vous pouvez avoir environ 100 000 polygones (une estimation très approximative). Les cartes vidéo peuvent gérer cela assez facilement. Mais lorsque ces polygones sont envoyés au fragment shader, les calculs d’éclairage coûteux et les ralentissements réels peuvent se produire..
Les développeurs tentent d'introduire autant de calculs d'éclairage que possible dans le Vertex shader afin de réduire la quantité de travail que le fragment Shader doit effectuer..Les calculs d'éclairage coûteux doivent être exécutés pour chaque fragment visible de chaque polygone à l'écran, qu'il chevauche ou soit masqué par les fragments d'un autre polygone. Si votre écran a une résolution de 1024x768 (ce qui n’est certainement pas une résolution très élevée), il vous reste près de 800 000 pixels à restituer. Vous pouvez facilement atteindre un million d'opérations de fragments à chaque image. En outre, de nombreux fragments ne parviendront jamais à l'écran car ils ont été supprimés avec des tests de profondeur et le calcul de l'éclairage a donc été perdu..
Si vous avez un million de ces fragments et que vous devez tout à coup rendre cette scène à chaque lumière, vous avez sauté sur [nombre de lumières] x 1 000 000
fragmenter les opérations par image! Imaginez si vous aviez une ville pleine de réverbères où chacun est une source de lumière ponctuelle…
La formule pour estimer cette complexité de rendu en avant peut être écrite, en grosse notation O, comme O (num_geometry_fragments * num_lights)
. Vous pouvez voir ici que la complexité est directement liée au nombre de géométries et au nombre de lumières..
Désormais, certains moteurs l’optimisent en supprimant les lumières éloignées, en les combinant ou en utilisant des cartes claires (très populaires, mais statiques). Mais si vous voulez beaucoup de lumières dynamiques, nous avons besoin d'une meilleure solution..
Le rendu différé est une approche très intéressante qui réduit le nombre d'objets, en particulier le nombre total de fragments, et effectue les calculs d'éclairage sur les pixels de l'écran, en utilisant ainsi la taille de la résolution au lieu du nombre total de fragments..
La complexité du rendu différé, en grande notation O, est la suivante: O (résolution_écran * num_lights)
.
Vous pouvez constater que le nombre d'objets que vous avez à l'écran détermine le nombre de lumières que vous utilisez. Vous pouvez donc facilement augmenter le nombre de vos lumières. (Cela ne signifie pas que vous pouvez avoir un nombre illimité d’objets. Ils doivent toujours être attirés vers les tampons pour produire le résultat final du rendu.)
Voyons voir comment ça fonctionne.
Chaque géométrie est rendue, mais sans ombrage clair, à plusieurs tampons d’espace écran en utilisant plusieurs cibles de rendu. En particulier, la profondeur, les normales et la couleur sont tous écrits dans des tampons distincts (images). Ces tampons sont ensuite combinés pour fournir suffisamment d’informations pour que chaque lumière éclaire les pixels..
En sachant à quelle distance se trouve un pixel et son vecteur normal, nous pouvons combiner la couleur de ce pixel avec la lumière pour produire notre rendu final..
La réponse courte est que, si vous utilisez plusieurs éclairages dynamiques, vous devez utiliser le rendu différé. Cependant, il existe des inconvénients importants:
Si vous ne disposez pas de beaucoup de lumières ou si vous voulez pouvoir utiliser du matériel ancien, vous devez vous en tenir au rendu direct et remplacer vos nombreuses lumières par des cartes de lumières statiques. Les résultats peuvent encore sembler étonnants.
J'espère que cela a permis de faire la lumière sur le sujet. Vos options sont là pour résoudre vos problèmes de rendu, mais il est très important de choisir le bon au début du développement de votre jeu pour éviter des modifications difficiles plus tard.