Na computação gráfica, Back-face culling determina quando um polígono presente em um objeto gráfico é visível. Essa é uma etapa do pipeline gráfico que testa se os pontos contidos em determinado polígono são exibidos no sentido horário ou anti-horário quando projetados na tela. Se o usuário previamente especificar que os polígonos estão voltados para a frente, um movimento no sentido horário acontece, mas se o polígono projetado na tela tem um movimento no sentido anti-horário, então ele foi girado para ficar de frente para a câmera e não será desenhado.

À esquerda, um modelo sem Back-face culling; à direita, o mesmo modelo com Back-face culling: as faces posteriores são removidas.

O processo implica renderizações mais rápidas e eficientes, reduzindo o número de polígonos necessários para o programa "desenhar" na tela. Em uma cena que contenha a rua de uma cidade, geralmente não há necessidade de desenhar os polígonos contidos nas laterais dos edifícios que estão de costas para a câmera.

Em geral, pode-se considerar que back-face culling não possui efeito visível em uma cena renderizada se ela contiver apenas geometria fechada e opaca. Em cenas contendo polígonos transparentes, os polígonos voltados para trás podem se tornar visíveis através do processo de composição alfa (alpha composition). Na renderização com wire-frame, back-face culling pode ser usado para resolver parcialmente o problema de remoção de linha oculta (hidden line removal), mas apenas para geometria convexa fechada.

Uma técnica relacionada é o clipping , que determina se os polígonos estão no campo de visão da câmera.

Outra técnica similar é a Z-culling, também conhecida como seleção de oclusão , que tenta pular o "desenho" de polígonos que estão fora do ponto de vista.

Implementação editar

Um método para implementação do back-face culling é descartar todos os triângulos onde o produto escalar de sua superfície normal e o vetor de câmera para triângulo for maior ou igual a zero.

  

onde P é o ponto de vista, V0 é o primeiro vértice de um triângulo e N é o seu normal, definido como um produto vetorial de dois vetores representando lados do triângulo adjacente a V0:

  

Como o produto vetorial não é comutativo, definir o normal em termos de produto vetorial permite especificar a direção normal em relação à superfície do triângulo usando ''vertex order(winding)'' :

 

Se os pontos já estiverem no espaço de visualização, P pode ser assumido como sendo (0, 0, 0) , a origem.

 

Também é possível usar este método no espaço de projeção, representando a desigualdade acima como determinante de uma matriz e aplicando-lhe a matriz de projeção.[1]

Existe outro método baseado na paridade de reflexão, que é mais apropriada para duas dimensões onde a normal da superfície não pode ser calculada (também conhecida como verificação CCW).

Deixe um triângulo unitário em duas dimensões ( coordenadas homogêneas ) ser definido como

 

Então, para algum outro triângulo, também em duas dimensões,

 

Definir uma matriz que transforma o triângulo da unidade nele

 

de modo a

 
 
 

Descarte o triângulo se a matriz M contiver um número ímpar de reflexões (voltado para o lado oposto do triângulo unitário)

 

O triângulo unitário é usado como uma referência e a transformação M é usada como um traço para dizer se a ordem do vértice é diferente entre dois triângulos. A única maneira pela qual a ordem dos vértices pode mudar em duas dimensões é por reflexão. A reflexão é um exemplo de função involutiva (com respeito à ordem do vértice), o número par de reflexões deixará o triângulo voltado para o mesmo lado, como se nenhuma reflexão fosse aplicada. Um número ímpar de reflexões deixará o triângulo voltado para o outro lado, como se exatamente depois de uma reflexão. Transformações contendo um número ímpar de reflexos sempre têm fator de escala negativo, assim como o fator de escala é positivo se não houver reflexos ou mesmo número deles. O fator de escala de uma transformação é calculado pelo determinante de sua matriz.

Referências editar

  1. David H. Eberly (2006). Projeto de motor de jogo 3D: uma abordagem prática para computação gráfica em tempo real , p. 69