Quelles sont les techniques courantes d'optimisation du rendu pour la passe de géométrie dans un rendu d'ombrage différé? [fermé]

J'ai développé un moteur de jeu utilisant OpenGL 3 et C ++ (et glfw pour la gestion des fenêtres). J'ai avancé jusqu'à présent, j'ai fait la plupart des choses à l'exception des entités sonores et des optimisations. Le moteur utilise un ombrage différé, car l'ombrage différé étant lui-même un processus fatigant pour un GPU moyen, je souhaite optimiser le processus de rendu autant que possible.

Le système actuel se compose d'une scène, contenant un moteur de rendu et le monde actuel et le monde contient des entités et des entités d'éclairage séparément std::vectors.

Donc, fondamentalement, chaque fois que la scène est appelée ->render(), et elle appelle le rendu, en passant le monde en tant que paramètre et obtient les itérateurs d'entité du monde, les attire vers le FBO, puis passe par les entités d'éclairage pour la deuxième passe. Et je pense que cela ne suffit pas.

Mon algorithme actuel parcourt tout, même si l'entité n'est pas dans l'espace d'écran. Je pense à un moyen d'optimiser l'algorithme de rendu actuel afin qu'il n'appelle les fonctions API que pour les objets visibles, alors quelles sont les techniques courantes pour optimiser un tel rendu?

L'ombrage différé n'est qu'une technique pour "différer" l'opération d'ombrage réelle pour les étapes ultérieures, cela peut être excellent pour réduire le nombre de passes nécessaires (par exemple) pour rendre 10 lumières qui nécessitent 10 passes. Mon point est que quelle que soit la technique de rendu que vous utilisez, il existe certaines optimisations de rendu possibles qui réduisent le nombre d'objets (sommets, normales, etc.) que votre pipeline de rendu doit traiter.

Il n'y a pas de norme de facto pour les optimisations de rendu, mais plutôt un certain nombre de techniques qui peuvent être utilisées de manière interchangeable ou ensemble pour atteindre certaines caractéristiques de performances. L'utilisation de chaque technique dépend fortement de la nature de la scène rendue.

Le rendu différé essaie de résoudre le problème lorsque le nombre de lumières augmente, ce qui pourrait faire exploser le nombre de passes dans le rendu avant.

Ces techniques n'optimisent pas directement la partie d'ombrage différé, mais selon votre description, la partie d'ombrage différé n'est PAS votre problème. Votre problème est que vous soumettez la scène entière au pipeline de rendu. Votre moteur doit donc traiter (par exemple tous les 100 millions de sommets) dans votre scène juste pour pouvoir soumettre le résultat au g-buffer, tandis que la plupart de ces 100 millions de sommets peuvent être éliminés de manière triviale et non soumis à la le sommet et les fragments de prétraitement passent.

Dans le cas d'un rendu vers l'avant, le sommet N sera traité par le stade sommet comme un total vertex count*lights countet par le stade fragment en tant que total fragments count*number Lights, l'ombrage différé réduit effectivement cela uniquement vertex countau stade sommet et fragments countau nombre de fragments, avant de résoudre le problème. ombrage réel. Mais N peut encore être trop lourd à traiter, surtout lorsque la plupart d'entre eux peuvent être éliminés de manière triviale.

Cela rend le tri plus efficace en cas de rendu vers l'avant / plusieurs passes. Mais gardez à l'esprit que la plupart des moteurs utiliseront une approche à double rendu, car l'ombrage différé seul ne peut pas résoudre les objets transparents, cela rend l'utilisation de ces optimisations indispensable, je ne connais aucun moteur commercial qui ne les fasse pas tous.

Frustum Culling

Seuls les objets entièrement ou partiellement inclus dans le tronc de vue doivent être soumis au pipeline de rendu. Il s'agit du concept de base de l'abattage du tronc, malheureusement, vérifier si un maillage est dans / hors de la vue, le tronc peut être une opération coûteuse, donc à la place, les concepteurs de moteurs utilisent un volume de délimitation approximatif comme une boîte de délimitation ou une sphère de délimitation alignée (AABB). , même si cela peut ne pas être aussi précis que l'utilisation du maillage réel, la différence de précision ne vaut pas la peine d'être vérifiée avec le maillage réel.

Même avec des volumes englobants, vous n'avez pas vraiment besoin de vérifier chacun d'eux, sinon vous pouvez construire une hiérarchie de volumes englobants pour effectuer une élimination antérieure, en utilisant cela dépend fortement de la complexité de la scène.

C'est une bonne et simple technique pour un moteur plus petit, et elle est presque utilisée dans tous les moteurs que j'ai jamais utilisés. Je recommande d'utiliser une vérification de volume / Frustum "normal" sans hiérarchie si votre moteur ne nécessite pas de rendre des scènes très complexes.

Abattage de la face arrière

C'est un must, pourquoi dessiner des visages qui ne seront pas visibles de toute façon? Les API de rendu fournissent une interface pour activer / désactiver l’abattage des faces arrière. À moins que vous n'ayez une bonne raison de ne pas l'activer, comme certaines applications de CAO qui doivent dessiner des backfaces dans certaines circonstances, c'est une chose incontournable.

Élimination par occlusion

En utilisant le Z-buffer, vous pouvez résoudre la détermination de la visibilité. Mais le problème est que le tampon Z n'est pas toujours excellent en termes de performances, car le tampon Z ne peut être résolu qu'aux étapes ultérieures du pipeline, les objets occlus doivent être tramés et peuvent être écrits dans le tampon Z et le Tampon de couleur avant d'échouer au test Z.

L'abattage d'occlusion résout ce problème en effectuant quelques premiers tests pour éliminer les objets occlus qui se trouvent dans le tronc de rendu. Une mise en œuvre pratique de l'élimination des occlusions consiste à utiliser des requêtes basées sur des points et à vérifier si certains objets sont visibles à partir d'une vue ponctuelle spécifique. Cela peut également être utilisé pour éliminer les lumières qui ne contribuent pas à l'image finale, ce qui est particulièrement utile dans un moteur de rendu différé.

Un grand exemple du monde réel d'une telle technique est dans GTA5, où les gratte-ciel sont stratégiquement placés au centre de la ville, ne sont pas seulement des décorations, mais ils fonctionnent également comme des occluseurs, occluant efficacement le reste de la ville et l'empêchant d'être tramé.

Niveau de détail

Le niveau de détail est une technique largement utilisée, l'idée est d'utiliser une version plus simple du maillage lorsque le maillage contribue moins à la scène. il existe deux implémentations communes; on change simplement le maillage avec un plus simple quand il ne contribue plus beaucoup, le maillage est sélectionné en fonction d'un facteur comme la distance et le nombre de pixels (zone sur les éboulis) que le maillage occupe. L'autre version mosaïque dynamiquement le maillage, ce qui est largement utilisé dans le rendu du terrain.

Et si tout cela ne fonctionnait pas?

Eh bien, c'est une bonne question.

La première chose que vous devez faire est de profiler votre application à l'aide d'un profileur graphique et de déterminer où se trouve le goulot d'étranglement. Gardez à l'esprit que le goulot d'étranglement peut changer à mesure que le contenu rendu change. Les goulots d'étranglement peuvent également faire partie du code exécuté sur le processeur, vous devez donc également le mesurer.

Après cela, vous devez faire quelques optimisations sur le goulot d'étranglement, gardez à l'esprit qu'il n'y a pas de bonne réponse à cela, et sera différent d'un matériel à l'autre.

Quelques astuces d'optimisation GPU courantes:

• Évitez les ramifications dans les shaders.
• Essayez différentes structures de sommets, par exemple {VNT}entrelacées dans le même tableau ou {V},{N},{T}dans différents tableaux.
• Dessinez la scène d'avant en arrière.
• Désactivez le Z-buffer à certains moments, par exemple si une image n'a pas besoin d'un test Z.
• Utilisez des textures compressées.

Quelques astuces courantes d'optimisation du processeur:

• Utilisez des fonctions en ligne pour les petites fonctions.
• Utilisez SIMD (Single Instruction Multiple Data) lorsque cela est possible.
• Évitez les sauts de mémoire hostiles au cache.
• Utilisez des VBO avec la «bonne» quantité de données. (en fonction de votre matériel) mais généralement moins d'appels de tirage sont meilleurs.

Mais que faire si mon goulot d'étranglement était dans l'ombrage différé?

Dans ce cas, étant donné que l'ombrage différé concerne davantage les lumières, la partie la plus évidente consiste à optimiser les calculs d'ombrage réels. certains des points à surveiller:

• Rend les lumières qui affectent réellement l'image finale. En d'autres termes, abattez les lumières qui ne contribuent pas. Cela peut être efficacement mis en œuvre en utilisant l'abattage d'occlusion que j'ai mentionné précédemment.
• Cette lumière a-t-elle besoin du spéculaire ou de quelques autres composants? Peut être pas.
• Cette lumière projette-t-elle de l'ombre? Certaines lumières n'ont pas besoin de projeter d'ombres.
• Cette légère contribution peut-elle être pré-calculée? S'il ne bouge pas, certains aspects peuvent probablement être précalculés.

Votre problème n'est pas lié à l'ombrage différé , vous devez implémenter les éléments de base d'un moteur de rendu avant d'essayer d'accélérer une partie spécifique.

Lorsque vous avez terminé avec ce que concept3d a expliqué, si vous constatez réellement que vous avez besoin d'optimiser le shader différé lui-même (par opposition à l'ensemble de la passe de pixellisation), vous pouvez implémenter un ombrage différé basé sur les tuiles.

Si vous n'êtes pas limité par le nombre de lumières dynamiques, vous devriez vous demander pourquoi vous utilisez un ombrage différé, mais si vous l' êtes, vous voudrez essayer l'optimisation qui a rendu Battlefield 3 possible. (Ils y font allusion dans la diapositive 10 de leur PDF public: http://dice.se/wp-content/uploads/GDC11_DX11inBF3_Public.pdf )