Usando resolução total do buffer de profundidade para renderização 2D

Estou trabalhando em um renderizador de frente para trás para um mecanismo 2D usando uma projeção ortográfica. Eu quero usar o buffer de profundidade para evitar excesso. Eu tenho um buffer de profundidade de 16 bits, uma câmera em Z = 100 olhando para Z = 0, zNear é 1 e zFar é 1000. Cada sprite renderizado define suas coordenadas Z para valores cada vez mais distantes, permitindo que o teste de profundidade ignore a renderização qualquer coisa que está por baixo.

No entanto, eu sei que a maneira como as posições Z acabam com os valores do buffer Z não é linear. Eu quero fazer uso da resolução completa do buffer de profundidade de 16 bits, ou seja, permitindo 65536 valores exclusivos. Portanto, para cada sprite renderizado, quero incrementar a posição Z para a próxima posição para correlacionar com o próximo valor exclusivo do buffer de profundidade.

Em outras palavras, eu quero transformar um índice incremental (0, 1, 2, 3 ...) do sprite sendo atraído para a posição Z apropriada para cada sprite para ter um valor único de buffer de profundidade. Eu não tenho certeza da matemática por trás disso. Qual é o cálculo para fazer isso?

Observe que estou trabalhando no WebGL (basicamente OpenGL ES 2) e preciso oferecer suporte a uma ampla gama de hardware, portanto, embora extensões como gl_FragDepth possam facilitar isso, não posso usá-lo por motivos de compatibilidade.

opengl 2d rendering depth-buffer AshleysBrain
fonte

Não consigo imaginar que o uso do buffer z ofereça muito ganho de desempenho (se houver) depois de adicionar toda a escrita, cálculos e comparações do buffer z contra copiar texturas de trás para frente, sem mencionar qualquer transparência / mistura alfa desgraças.

Matt Esch

@MattEsch: A idéia é que todos esses cálculos sejam feitos na GPU em velocidades incrivelmente altas, por isso faz sentido fazer isso.

Panda Pyjama

@MattEsch: O FWIW é voltado para GPUs integradas da Intel, que usam memória do sistema em vez de memória dedicada da GPU. Isso os torna muito lentos e passíveis de atingir os limites de taxa de preenchimento se você desenhar muitos sprites. A Intel recomendou essa abordagem para mim como uma maneira de contornar isso. Presumivelmente, a implementação dos testes de profundidade está bem otimizada e pode economizar muito na taxa de preenchimento. Ainda está para ser visto, ainda não o perfilei!

AshleysBrain

A memória de cópia em bloco do @PandaPajama é realmente muito rápida, portanto, se você estivesse apenas inserindo texturas em uma superfície, seria muito rápido. A primeira grande sobrecarga é obter dados na GPU em primeiro lugar, o que, como destaca Ashley, pode ser mais caro em GPUs integradas. Você descobre que muitos jogos 3D realizam uma quantidade não trivial de trabalho na CPU (como a animação óssea), porque o upload dos dados necessários para realizar esses cálculos matriciais é muito caro.

Matt Esch

@ MatEsch: Há muito que você pode fazer com apenas cegar. Rotações, redimensionamento e deformações vêm à mente, mas também como você tem sombreadores de pixel / vértice, o limite do que você pode fazer com o hardware é muito maior do que o que você pode fazer com apenas cegos.

Panda Pajama

Respostas:

De fato, os valores armazenados no buffer z não são lineares às coordenadas z reais de seus objetos, mas às suas recíprocas, a fim de dar mais resolução ao que está próximo ao olho do que ao que está mais próximo do plano traseiro.

O que você faz é que você mapear o zNearque 0e sua zFara 1. Para zNear=1e zFar=2, deve ficar assim

Zbuffer

A maneira de calcular isso é definida por:

z_buffer_value = k * (a + (b / z))

Onde

 k = (1 << N), maximum value the Z buffer can store
 N = number of bits of Z precision
 a = zFar / ( zFar - zNear )
 b = zFar * zNear / ( zNear - zFar )
 z = distance from the eye to the object

... e z_buffer_value é um número inteiro.

A equação acima é apresentada como cortesia desta página incrível , que explica os z-buffers de uma maneira realmente boa.

Portanto, para encontrar o necessário zpara um dado z_buffer_value, basta limpar o z:

z = (k * b) / (z_buffer_value - (k * a))

Panda Pajama
fonte

Obrigado pela resposta! Estou um pouco confuso sobre como você conseguiu sua fórmula final. Se eu pegar z_buffer_value = k * (a + (b / z))e simplesmente reorganizar para resolver z, então eu recebo: z = b / ((z_buffer_value / k) - a)- como você chegou à última fórmula diferente?

AshleysBrain #

@AshleysBrain: você pega o denominador (v / k) - a => (v - k * a) / ke reduz para (k * b) / (v - (k * a)). É o mesmo resultado.

Panda Pyjama

Ah entendo. Obrigado pela resposta, está funcionando bem!

AshleysBrain

Talvez você deva mudar sua abordagem para algo mais simples. O que eu faria; Mantenha sua profundidade Z, mas mantenha uma lista do que você renderiza. Encomende essa lista com base no valor z Profundidade e renderize os objetos na ordem da lista.

Espero que isso possa ajudar. As pessoas sempre me dizem para manter as coisas simples.

HgMerk
fonte

Desculpe, isso não ajuda muito. Eu já estou fazendo isso. A questão é sobre quais posições Z escolher.

AshleysBrain

Como você já tem uma lista ordenada de itens a serem renderizados (da frente para trás), realmente precisa incrementar o índice Z? Você não pode usar "menor ou igual" para a "função de verificação"? Dessa forma, ele realmente verifica se um pixel específico já foi desenhado ou não.

Elven
fonte

"menor ou igual" ainda fará com que absolutamente tudo seja excedido, pois tudo sempre teria um índice Z igual e, portanto, passaria no teste de profundidade.

AshleysBrain