Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O exemplo PRTDemo e o simulador PRTCmdLine incluídos no SDK do DirectX representam vetores de transferência nos vértices de uma malha. A fim de representar o sinal PRT com precisão, tal pode exigir tesselações que podem ser impraticáveis para os jogos atuais. Representar vetores de transferência em mapas de textura é uma abordagem alternativa que tem o mesmo custo de dados independentemente da complexidade da malha. Há várias maneiras de gerar mapas de textura vetorial de transferência usando a Biblioteca PRT D3DX.
Pré-computação de vetores de transferência
Uma abordagem seria modificar as amostras PRTDemo e PRTCmdLine para calcular um vetor de transferência em cada texel em uma parametrização de uma superfície. Para fazer isso:
- Modifique a chamada para D3DXCreatePRTEngine para extrair as coordenadas de textura da malha (ExtractUVs deve ser TRUE)
- Substitua chamadas de D3DXCreatePRTBuffer por D3DXCreatePRTBufferTex usando o mesmo tamanho de textura.
Todos os métodos ID3DXPRTEngine funcionam com simulações por texel, exceto ComputeBounceAdaptive, ComputeSSAdaptive, ComputeSS e ComputeDirectLightingSHAdaptive. Embora a simulação textura-espaço gere o resultado correto, muitas vezes pode ser bastante lenta, uma vez que provavelmente estará computando vetores de transferência em alta densidade.
Outra abordagem é calcular uma simulação PRT adaptativa por vértice (com coordenadas de textura que serão usadas para os dados por texel) e, em seguida, chamar ID3DXPRTEngine::ResampleBuffer (usando um buffer de saída criado usando D3DXCreatePRTBufferTex na resolução apropriada). Isso funciona com todas as funcionalidades do D3DX PRT no SDK e muitas vezes pode ser muito mais eficiente do que calcular diretamente um buffer de transferência por texel.
Cálculos de tempo de execução
Se for usado um único cluster, os resultados podem ser filtrados e mip-mapeados como qualquer outra textura, e o sombreador de pixel é idêntico ao código do sombreador de vértice que acompanha o PRTDemo.
Se a compactação gerar vários clusters, não será possível filtrar ou mipmapear os dados porque os índices de clustering não são contínuos. Aqui estão algumas alternativas para lidar com dados multiclusterizados.
- Faça você mesmo toda a filtragem no sombreador de pixel. Infelizmente, isso é geralmente impraticável por razões de desempenho.
- Se as texturas forem texturas não mapeadas por mip de baixa resolução (ou seja: mapas de luz), é provavelmente mais eficiente apenas calcular a iluminação diretamente no espaço de textura - onde nenhuma filtragem ocorrerá e renderizar o objeto com uma textura sombreada. Este é essencialmente um mapa de luz dinâmico que é criado inteiramente na GPU.
- Se um atlas de textura for usado (consulte Usando UVAtlas (Direct3D 9)), você pode agrupar manualmente a cena fazendo com que todos os vetores de transferência em um componente conectado no espaço de textura estejam no mesmo cluster. Desta forma, é possível filtrar a textura, uma vez que, por construção, todos os texels acedidos estariam no mesmo cluster. O ID do cluster para uma determinada face pode ser propagado a partir do sombreador de vértice.
Os sombreadores de pixel têm muito menos registros constantes que não podem ser indexados, portanto, o sombreador de pixel é um pouco diferente do sombreador de vértice. Armazenar o trabalho por cluster em uma textura dinâmica de baixa resolução e usar cargas de textura seria a maneira mais eficiente de renderizar ao usar vários clusters.
Tópicos relacionados