Représentation de PRT avec des textures (Direct3D 9)
L’exemple PRTDemo et le simulateur PRTCmdLine inclus dans le Kit de développement logiciel (SDK) DirectX représentent les vecteurs de transfert aux sommets d’un maillage. Afin de représenter le signal PRT avec précision, cela peut nécessiter des pavages qui peuvent être peu pratiques pour les jeux en cours. La représentation des vecteurs de transfert dans les mappages de textures est une autre approche qui a le même coût de données, indépendamment de la complexité du maillage. Il existe plusieurs façons de générer des mappages de textures de vecteurs de transfert à l’aide de la bibliothèque PRT D3DX.
Précalculation des vecteurs de transfert
Une approche consisterait à modifier les échantillons PRTDemo et PRTCmdLine pour calculer un vecteur de transfert à chaque texel dans un paramétrage d’une surface. Pour ce faire :
- Modifiez l’appel à D3DXCreatePRTEngine pour extraire les coordonnées de texture du maillage (ExtractUVs doit avoir la valeur TRUE)
- Remplacez les appels D3DXCreatePRTBuffer par D3DXCreatePRTBufferTex en utilisant la même taille de texture.
Toutes les méthodes ID3DXPRTEngine fonctionnent avec des simulations par texel, à l’exception de : ComputeBounceAdaptive, ComputeSSAdaptive, ComputeSS et ComputeDirectLightingSHAdaptive. Bien que la simulation d’espace de texture génère le résultat correct, elle peut souvent être assez lente, car il s’agit probablement de calculer des vecteurs de transfert à haute densité.
Une autre approche consiste à calculer une simulation PRT adaptative par vertex (avec des coordonnées de texture qui seront utilisées pour les données par texel), puis à appeler ID3DXPRTEngine::ResampleBuffer (à l’aide d’une mémoire tampon de sortie créée à l’aide de D3DXCreatePRTBufferTex à la résolution appropriée). Cela fonctionne avec toutes les fonctionnalités PRT D3DX dans le SDK et peut souvent être beaucoup plus efficace que le calcul direct d’une mémoire tampon de transfert par texel.
Calculs du runtime
Si un seul cluster est utilisé, les résultats peuvent être filtrés et mappés comme n’importe quelle autre texture, et le nuanceur de pixels est identique au code du nuanceur de vertex fourni avec PRTDemo.
Si la compression génère plusieurs clusters, vous ne pouvez pas filtrer ou mappper les données, car clustering index ne sont pas continus. Voici quelques alternatives pour gérer les données multi-cluster :
- Effectuez tout le filtrage vous-même dans le nuanceur de pixels. Malheureusement, cela est généralement peu pratique pour des raisons de performances.
- Si les textures sont des textures à faible résolution non mip-mappées (c’est-à-dire des cartes de lumière), il est probablement plus efficace de calculer simplement l’éclairage directement dans l’espace de texture , où aucun filtrage ne se produit, et de restituer l’objet avec une texture ombrée. Il s’agit essentiellement d’une carte de lumière dynamique qui est créée entièrement sur le GPU.
- Si un atlas de textures est utilisé (voir Utilisation d’UVAtlas (Direct3D 9)), vous pouvez regrouper manuellement la scène en plaçant tous les vecteurs de transfert dans un composant connecté dans l’espace de texture dans le même cluster. De cette façon, vous pouvez filtrer la texture, car tous les texels consultés se trouvent dans le même cluster par construction. L’ID de cluster d’un visage donné peut être propagé à partir du nuanceur de vertex.
Les nuanceurs de pixels ont beaucoup moins de registres constants qui ne peuvent pas être indexés, de sorte que le nuanceur de pixels est légèrement différent du nuanceur de vertex. Le stockage du travail par cluster dans une texture dynamique à basse résolution et l’utilisation des charges de texture seraient le moyen le plus efficace de rendre lors de l’utilisation de plusieurs clusters.
Rubriques connexes