Gerando terreno na GPU

No meu mecanismo, crio um terreno infinito com o uso do algoritmo de ruído Perlin calculado na CPU.

A criação do terreno é assim:

Se a câmera estiver perto do patch descarregado, crie-o
Calcule uma matriz de ruído de 513 x 513 com limites especificados
Cálculo de normais, tangente, binormal, índices
Passar dados para vbo

Prós:

Só precisa ser renderizado quando necessário
Fácil de fazer colisão

Vigarista

64 patches lentos de 513x513 são criados em 3,1s (um encadeamento). Para cada bloco ~ 20ms de criação de ruído, ~ 25ms de vértices, normais, tangente, bitangente, índices. Quando a câmera se move rapidamente, o usuário pode perceber o carregamento de peças.
consumindo memória ???

Agora eu estava pensando em como acelerar isso, gerando terreno completamente na GPU. Mas há algumas dúvidas:

Se os shaders executam todos os quadros, esse desperdício de energia não é computado para calcular o ruído repetidamente? Isso pode ser evitado escrevendo o resultado na textura RBGA e usado posteriormente no shader de vértice para deslocamento, mas aumenta o uso da memória. Por outro lado, se a criação for super rápida, apenas os blocos visíveis devem permanecer na memória. No entanto, a desanexação do buffer causa a sincronização gpu-cpu, o que pode tornar o aplicativo mais lento (estou certo?)
Se o terreno é apenas uma grade plana deslocada pelo sombreador de vértices, o mesmo trabalho precisa ser feito na CPU para calcular a altura e o normal em um determinado ponto para colisão.
Este é apenas um conceito, mas para acelerar tudo, eu estava pensando em projetar uma grade na janela de exibição, para que apenas uma quantidade mínima de vértices seja usada. Você acha que isso funcionaria?

Minha pergunta final é:

Qual a melhor / mais rápida / técnica amplamente usada para criar terrenos infinitos na GPU?

terrain

— user1075940
fonte

Observe que a criação de terreno na GPU dificultará a detecção de colisões, a detecção de coletas ou praticamente qualquer tipo de interação com o terreno.

— MichaelHouse

Um sombreador de computação (DX10 ou 11) pode ser usado para gerar o terreno na GPU. Mas como o Byte56 afirmou, você precisará extrair os valores da GPU para interagir com ela. msdn.microsoft.com/pt-BR/library/windows/desktop/…

— UnderscoreZero

criar terreno em um tipo de GPU parece uma má ideia para mim. Pode funcionar, mas acho que provavelmente funcionaria um pouco melhor se você apenas gerar o terreno no lado da CPU e enviar o material de desenho padrão para a GPU.

— Benjamin Danger Johnson

Apenas minha experiência; Na verdade, eu fiz exatamente isso com aparapi e realmente consegui que a maldita coisa funcionasse; mas acabou sendo mais lento do que apenas fazer com que a CPU fizesse o trabalho. Eu acho que por causa da sobrecarga de enviar dados de / para a GPU. Se bem me lembro gpu só funciona realmente se o cálculo for grande em comparação com o tamanho dos dados (e também grande em termos absolutos)

— Richard Tingle

Este artigo pode lhe dar algumas idéias http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

— Jeremias Leslie

Bem, se eu tentasse usar a GPU para tal coisa, acho que iria usar o comput / opencl / cuda.

No entanto, independentemente do uso da GPU ou CPU (que é o que eu realmente faço), eu o faria de maneira assíncrona, decidindo que você precisa de um novo terreno para o quadro atual provavelmente é tarde demais (por exemplo, considere 1000ms / 60 = 16.666ms, e o quadro inteiro quer se encaixar nisso).

Comece a gerar (ou carregar a partir de arquivos compactados) terreno em um segmento de trabalho e disponibilize-o para o resto do jogo e renderize assim que o trabalhador terminar, geralmente esse será o próximo quadro, ou talvez o quadro depois disso. o usuário não perceberá a diferença lá, mas isso torna as coisas mais suaves.

— Vai
fonte