Aceleradoras de vídeo: 3D

O eixo do Z

O universo é tridimensional. Na verdade há quem afirme que ele tem muitas mais dimensões, mas vamos ficar aqui com o singelo universo newtoniano e nos restringirmos às boas e velhas largura, altura e comprimento, nossas bem conhecidas três dimensões.

Quando olhamos para uma cena de animação gerada por uma placa aceleradora 3D e exibida na tela de nosso computador nos damos conta apenas da largura e altura, as duas dimensões que aparecem na tela. Se quisermos identificar um determinado pixel nesta tela, podemos fazê-lo especificando duas distâncias: uma, horizontal, da moldura esquerda até ele, outra, vertical, dele até a moldura superior (não reclamem comigo; eu sei que vocês estão acostumados a medir esta segunda distância “de baixo para cima”, desde a moldura inferior, mas por razões que não cabem discutir aqui, nas telas de computadores ela é medida “de cima para baixo”). Se nós batizarmos a moldura esquerda de “eixo dos Y” e a superior de “eixo dos X”, poderemos identificar a posição de qualquer pixel na tela fornecendo estas duas distâncias (ou “coordenadas”) X e Y. Como sabemos, todo este conjunto de pixels (na verdade, os números que representam suas cores, o que dá no mesmo) estão armazenados na memória de vídeo.

O problema é que até agora discutimos apenas uma parte da verdade. Porque quando as placas aceleradoras geram imagens em 3D, o conjunto de pixels que representa uma cena ocupa apenas uma parte da memória de vídeo, parte esta denominada “frame buffer” (que, mal traduzida do inglês, significa mais ou menos “armazenamento de um quadro” ? ou de uma cena). Mas além do frame buffer, a UGP se serve de mais duas regiões da memória.

Em uma delas são armazenadas as texturas. E não vamos perder muito tempo com ela, já que sua função é simples: como um objeto pode desaparecer de cena e depois retornar, ou “se esconder” por detrás de outro e reaparecer, melhor manter sua textura armazenada para não ter que recriá-la sempre que o objeto tiver que ser renderizado. Vamos então à outra, que é a que nos interessa: o “z-buffer“, ou a região da memória que armazena as coordenadas “Z”.

Mas que coordenadas “Z” são estas que surgiram assim de repente?

Ora, você sabe. Pense um pouco: se a largura e a altura são, respectivamente, representadas pelas coordenadas “X” e “Y”, em um mundo tridimensional a coordenada “Z” só pode representar uma coisa: o comprimento. Ou, melhor dizendo: a dimensão perpendicular à tela. A profundidade. Que, no nosso caso, representa a distância entre o plano da tela e a posição que o ponto teoricamente ocuparia “por detrás” dela.

Então trace uma linha imaginária a partir do canto superior esquerdo de sua tela e se prolonga para trás dela até o infinito, perpendicularmente a seu plano. Esta linha é o “Eixo dos Z”.

Pois bem: o terceiro trecho de memória de vídeo ao qual nos referimos, denominado Z-buffer, armazena a coordenada Z de cada pixel da tela.

Para que serve isto, se as imagens renderizadas (ou seja, as cenas armazenadas no frame buffer) já levam em conta a posição dos objetos aos quais pertencem cada pixel?

Se as imagens permanecessem estáticas, não serviriam para nada. Mas, como sabemos, tridimensionalidade em computação gráfica tem muito a ver com movimento, deslocamento, mudança de posição. E quando passamos de uma cena para a próxima, todo o frame buffer tem que ser refeito.

Ora, para refazer (recalcular) o frame buffer é essencial manter um registro da distância entre cada objeto (ou entre cada pixel pertencente a cada objeto) e o plano da tela. E a razão disto é simples: se o objeto que se move estiver mais distante que o que permaneceu imóvel, como por exemplo um inimigo que se esconde atrás de uma árvore, seus pixels não serão renderizados no frame buffer pois seus lugares serão ocupados pelos pixels da árvore.

E como o mecanismo de renderização “sabe” quais pixels serão renderizados e quais não serão? Da forma mais simples possível: se dois pixels pertencentes a dois diferentes objetos possuírem as mesmas coordenadas X e Y (ou seja, se estiverem “disputando” a mesma posição na tela), será renderizado o que tiver menor coordenada Z, já que uma coordenada Z menor corresponde a uma menor distância da tela, o que indica que o objeto a que pertence este pixel está “na frente” do outro, escondendo-o.

Veja, na parte de cima da figura 6 (obtida na Wikipedia), o aspecto de uma imagem renderizada (ou seja, o conteúdo da área de memória de vídeo que denominamos frame buffer) e na parte inferior da mesma figura uma representação do conteúdo do Z-buffer, onde os pixels pertencentes aos objetos mais próximos são representados em uma cor mais escura (ou seja, cuja representação usa números menores).

Mas note que este é apenas um dos usos do Z-buffer. Pois nem todo objeto é opaco. Alguns são transparentes (veja a esfera azul da Figura 5) ou translúcidos e, neste caso, os pixels de diferentes coordenadas Z devem ser combinados de acordo com as características da transparência ou translucidez do objeto em primeiro plano. Além disso, a luz refletida por um objeto de maior coordenada Z (mais distante) pode iluminar os mais próximos “por detrás” ou de forma obliqua. E tudo isto deve ser levado em conta nos cálculos efetuados pela placa aceleradora 3D.

Finalmente, convém notar a importância do adjetivo “aceleradora”. Porque computadores são máquinas extraordinárias para fazer cálculos. E se lhes dermos tempo suficiente, serão capazes de efetuar os cálculos mais complexos. Mesmo a estrambótica calculeira necessária para gerar imagens tridimensionais.

O detalhe a considerar é a expressão “tempo suficiente”.

Minha primeira experiência com computação gráfica tridimensional foi obtida através de uma das primeiras versões do excelente programa AutoCad. Uma versão tão antiga que rodava em um velho clone de XT, sem coprocessador matemático e sem qualquer aceleração gráfica.

Um dos arquivos incluídos com o programa a guisa de demonstração era a vista tridimensional, se não me engano em wireframe, de uma belíssima obra arquitetônica (se a memória não me trai, uma catedral; mas eu tenho certeza que alguém de melhor memória que a minha também a viu e logo me corrigirá ou acrescentará os devidos detalhes nos comentários).

Para apreciá-la era preciso carregar o arquivo e esperar que a imagem fosse renderizada e exibida. E quando eu digo “esperar”, quero dizer “esperar” mesmo. Dava para ver cada linha ser traçada na tela (um pobre monitor monocromático de fósforo verde, se é que me entendem). E eram milhares de linhas. Era carregar o arquivo, ir tratar de outros afazeres e alguns (muitos) minutos mais tarde retornar para apreciar a imagem ? caso já estivesse “pronta”.

E tudo isto apenas para renderizar uma cena em wireframe.

Agora deu para perceber o verdadeiro valor de uma placa aceleradora 3D e entender porque ela dispõe de tanto poder de processamento, consome tanta potência, esquenta tanto que precisa de um dissipador de calor ativo e ainda por cima usa uma substancial capacidade de memória de vídeo de alto desempenho?

É que, além de renderizar a imagem ? tarefa na qual meu velho XT gastava dezenas de minutos ? ela precisa gerar texturas, cuidar da iluminação, reflexos, transparências, atmosfera e tudo o mais. E fazer isto, incansavelmente, sessenta a setenta vezes por segundo.

Que dureza…

Pois na próxima coluna discorreremos sobre um exemplo prático.

Até lá

B.Piropo