Le rendu / ombrage différé est-il possible avec OpenGL ES 2.0?

J'ai posé cette question sur StackOverflow , mais cela pourrait avoir plus de sens ici:

Quelqu'un a-t-il implémenté un rendu / ombrage différé sous OpenGL ES 2.0? Il ne prend pas en charge les MRT, donc avec un seul tampon de couleur, ce n'est pas quelque chose qui peut être implémenté de la manière "habituelle".

Plus précisément, j'explore sur iPad, iPhone4 (maaaybe iPhone 3gs) et Android. Sur l'application GLESView sur iPad / iPhone4 / iPhone3gs, l'extension GL_OES_RGB8_RGBA8 est présente, et je n'ai pas encore regardé trop profondément, mais avec 8bits / canal, cette idée est intéressante: http://www.gamedev.net/topic/ 562138-opengl-es-20-and-deferred-shading /

D'autres idées? Est-ce que cela vaut même la peine, en termes de performances?

Oui c'est possible. Cependant, cela ne vaut pas particulièrement la peine.

Tout d'abord, sauf si vous avez accès à l'extension NV_draw_buffers (comme son nom l'indique, elle est uniquement NVIDIA. Donc, sauf si vous exécutez sur Tegra, vous ne l'avez pas), les objets framebuffer sous ES 2.0 ne peuvent être rendus que sur une seule image à la fois. Ainsi, pour générer vos tampons G, vous devrez rendre votre scène plusieurs fois, supprimant ainsi l'un des avantages du rendu différé.

Deuxièmement, la bande passante sur les plates-formes mobiles n'est pas la même que celle que vous obtiendriez même sur des GPU de qualité moyenne. Et la bande passante est essentielle pour que le rendu différé (pour de nombreuses lumières) en vaille la peine. Sans cette bande passante, les passages de lumière vont vraiment faire mal, en termes de performances.

Troisièmement, le matériel PowerVR n'est vraiment pas conçu pour ce genre de chose. Il optimise le rendu avec son matériel de rendu basé sur des tuiles. Un rendu différé en plus serait donc moins utile que dans une architecture de conversion de scan traditionnelle.

Le principal problème est Fillrate. Sur les GPU mobiles, votre taux de remplissage est faible et vous ne pouvez pas faire d'ombrage différé en temps réel avec une résolution native.

Sur iPhone 4 et iPad 1, le taux de remplissage est tout simplement ridicule. Le seul appareil IOS avec un bon taux de remplissage est l'iPad 2, mais je doute qu'il y en ait assez ... Sur Android, seuls les appareils Tegra ont les GL_NV_draw_buffers pour utiliser MRT mais le taux de remplissage est également très faible. Le Mali 400 semble avoir le meilleur taux de remplissage. Si vous voulez pleurer, essayez simplement de remplir un rectangle de couleur en résolution plein écran 4 fois ... De nombreux appareils ne peuvent pas le faire à 60 ips.

Sur les GPU de bureau, vous avez 10 fois (ou plus) le taux de remplissage en tant que GPU mobiles. N'oubliez pas que les GPU mobiles utilisent la même mémoire que le CPU et que vous n'avez pas de mémoire dédiée.

Il y a quelques exemples dans WebGL (même API) donc ce n'est pas une limitation de l'API.

Vraiment, vous devez considérer quel est le minimum absolu dont vous avez besoin pour un rendu différé. Si vous revenez à un éclairage différé, cela réduit la quantité de données qui doivent être stockées dans le GBuffer, et c'est vraiment beaucoup moins cher que de rendre la moitié de la scène 3 fois ou plus pour prendre en charge une faible quantité de lumières.

Je choisirais le format GBuffer suivant:

• Réutilisez le tampon de profondeur pour le passage d'éclairage, vous ne savez pas dans quelle mesure cela est pris en charge sur les appareils mobiles, mais c'est une texture de profondeur gratuite.
• Une seule texture GBuffer, à l'intérieur, je stockerais: Normal U, Normal V, Param 0, Param 1. L'encodage Lambert-Azimuthal est vraiment agréable pour les normales et les comprime en seulement deux composants, relativement bon marché pour encoder et décoder également.
• Deux paramètres pour les variables d'éclairage, c'est beaucoup, pourrait en utiliser un comme énumération pour plusieurs fonctions d'éclairage si le matériel fonctionne bien avec la ramification dynamique.

L'éclairage différé est similaire au rendu différé, sauf que vous effectuez un rendu deux fois de la scène:

1. Rendre la profondeur de la géométrie, les normales et les paramètres d'éclairage dans le GBuffer.
2. Rend les lumières dans le tampon d'accumulation.
3. Rendez la géométrie avec des shaders de matériaux, composez également votre éclairage ici. Si vous êtes bon avec l'élaboration d'opérateurs inverses d'équations d'éclairage, vous pouvez faire BEAUCOUP de choses vraiment cool avec cette étape.
4. Faites n'importe quel post-traitement que vous pouvez vous permettre, assurez-vous d'abuser de la profondeur et des textures normales ici pour des raisons d'efficacité.

À propos du stockage des résultats d'éclairage. Je suis devenu friand de stocker des couleurs diffuses et de la luminance spéculaire de sorte que le tampon d'accumulation ne doit être qu'une texture de couleur standard de 32 bits. Vous pouvez estimer la couleur spéculaire en calculant la chrominance de la couleur diffuse et en la combinant avec la luminance spéculaire.

Cependant, la partie la plus importante va être d'utiliser le tampon de profondeur-pochoir au maximum, assurez-vous que vous ne restituez aucun du code d'éclairage là où il n'est pas nécessaire. J'irais même jusqu'à ajouter des instructions de rejet dans les shaders de fragments selon des termes qui feront tomber la visibilité de la lumière sous la plage affichable de l'appareil (1e-3 est généralement une coupure sûre).

Envisagez un éclairage différé. En résumé, l'éclairage différé est une technique qui utilise une version réduite de l'ombrage différé pour calculer une image lumineuse de l'espace d'écran. Dans un deuxième passage, la géométrie est à nouveau rendue en utilisant le plan lumineux de l'espace d'écran comme information d'éclairage.

Cette technique est utilisée pour réduire la taille du G-Buffer, car moins d'attributs sont nécessaires. Cela vous offre également l'avantage que le G-Buffer et le lightmap de l'espace d'écran peuvent être de résolution inférieure à celle de l'écran.

J'avais implémenté un rendu basé sur GLES 2.0 strict (bien qu'expérimental), et j'ai réussi à réduire le G-Buffer à une seule texture RGBA (oui, j'ai utilisé une texture2D au lieu d'un renduerbuffer). Il contenait la carte normale de l'espace d'écran + le tampon de profondeur dans le canal alpha (qui a été compressé à l'aide d'un logarithme, pour autant que je m'en souvienne).

Les attributs de position (appelés ici monde ) peuvent être calculés lors du passage d'éclairage en utilisant le fait que, dans une projection perspective, .xy est divisé par .z , de sorte que:

J'ai approximé le xy de l'attribut position en faisant:

Remarque: J'ai dû faire d'autres ajustements en fonction des paramètres de la matrice de projection.

Il convient également de noter que j'étais capable d'omettre la composante .z des vecteurs normaux, car je pouvais reconstruire .z à partir de .xy car le vecteur normal est normalisé de sorte que:

En utilisant cette technique, j'ai pu libérer un autre canal dans mon RGBA G-Buffer et l'ai utilisé pour stocker la carte spéculaire de l'espace d'écran (ou la brillance, si vous voulez).

Oui, c'est absolument possible. Le taux de remplissage n'est pas un problème car les puces graphiques mobiles sont conçues pour gérer des écrans à très haute résolution. En fait, le rendu différé aide à cela car votre calcul d'éclairage est indépendant de la complexité de la scène, donc le sur-tirage ne provoque pas de ralentissement. Voici mon implémentation sur un iPad de quatrième génération: http://www.youtube.com/watch?v=K4X1oF6b4V8

Si vous voulez quatre fois la performance, juste la moitié de la résolution de la texture à laquelle vous effectuez le rendu. De toute façon, je ne vois pas vraiment de différence avec les graphismes 3D sur un écran rétine.

Les puces graphiques mobiles sont extrêmement bonnes pour le rendu différé en raison de la façon dont elles gèrent le rendu en texture. Contrairement aux cartes graphiques pour PC, qui génèrent généralement un énorme impact sur les performances lorsque vous commencez à rendre une texture au lieu d'un contexte de fenêtre, les graphiques mobiles sont conçus pour cela sans aucun impact sur les performances. Ainsi, vous obtenez l'évolutivité d'un rendu différé, sans la pénalité de performance initiale que vous rencontrez sur une carte graphique de bureau.

Au moment de mon implémentation, OpenGLES manquait de rendu sur plusieurs cibles, j'ai donc dû dessiner la couleur de l'écran et la normale en plusieurs passes. Cela peut être corrigé dans les versions plus récentes d'OpenGLES, mais je ne sais pas si les solutions sont encore disponibles dans le matériel mobile grand public.