OpenGL
Origem: Wikipédia, a enciclopédia livre.
Índice |
[editar] História do OpenGL
Na década de 80, cada fabricante de hardware tinha seu próprio conjunto de instruções para desenho de gráficos 2D e 3D. Construir aplicações com essas tecnologias que suportassem vários hardwares era um verdadeiro desafio. Esforço era constantemente duplicado e havia pouco espaço para companhias menores e sem capital para tamanho investimento.
Em meados dos anos 80, um padrão surgiu na indústria, chamado PHIGS (sigla de Programmer’s Hierarchical, Graphics System) e começou a ser adotado por grandes fabricantes da época. Entretanto, embora tenha sido reconhecido por entidades como a ANSI e a ISO, o padrão começou a ser considerado complicado e desatualizado.
No final dos anos 80, a Silicon Graphics Inc. (SGI), criou um padrão chamado IRIS GL, que não só começou a chamar atenção da indústria, como também foi considerado o estado da arte de uma API gráfica. Consideravelmente mais fácil de usar, a API começou a tornar-se um padrão de facto na indústria.
Entretanto, grandes empresas produtoras da hardware, como a Sun Microsystems e a IBM, ainda eram capazes de fabricar hardware adotando o padrão PHIGS. Isso levou a SGI a tomar uma decisão para que a adoção de sua API fosse impulsionada: torna-la um padrão público, para que todos os fabricantes de hardware pudessem adota-lo.
A SGI considerou que a API Iris continha muito código proprietário e portanto não poderia ser aberta. Ela também lidava com questões não tão relacionadas ao desenho 2D e 3D, como gerenciamento de janelas, teclado e mouse. Ainda assim, era do interesse da Silicon Graphics manter os seus antigos clientes comprando seu hardware.
Como um resultado disso, o padrão OpenGL é criado. Desde 1992, o padrão é mantido pelo ARB (Architecture Review Board), um conselho formado por empresas como a 3DLabs, ATI, Dell, Evans&Sutherland, HP, IBM, Intel, Matrox, NVIDIA, Sun e, logicamente, a Silicon Graphics. O papel desse conselho é manter a especificação e indicar quais recursos serão adicionados a cada versão. A versão mais atual do OpenGL até hoje é a 2.1.
Os projetistas do OpenGL sabiam de duas coisas. A primeira é que fabricantes de hardware gostariam de adicionar recursos próprios, sem que tivessem que esperar para esses recursos estarem oficialmente aceitos no padrão. Para resolver esse problema, eles incluíram uma maneira de estender o OpenGL. Muitas vezes, essas extensões são interessantes o suficiente para que outros vendedores de hardware as adotem. Então, quando elas são consideradas suficientemente abrangentes, ou suficientemente importantes, a ARB pode ser promove-las para que façam parte do padrão oficial. Praticamente todas as modificações recentes do padrão começaram como extensões, a grande maioria devido ao mercado de jogos.
Em segundo lugar, os projetistas tambem sabiam que muitos hardwares não seriam poderosos o suficiente para abraçar todo o padrão. Por isso, também incluíram extensões de software, que permitiam emular essas funcionalidades. Isso resolvia um problema sério que ocorria com a Iris: O da aplicação simplesmente não rodar pela falta de um ou outro recurso.
[editar] Arquitetura do OpenGL
O OpenGL é um conjunto de algumas centenas de funções, que fornecem acesso a praticamente todos os recursos do hardware de vídeo. Internamente, ele age como uma máquina de estados, que de maneira bem específica dizem ao OpenGL o que fazer. Usando as funções da API, você pode ligar ou desligar vários aspectos dessa máquina, tais como a cor atual, se transparência será usada, se cálculos de iluminação devem ser feitos, se haverá ou não o efeito de neblina, e assim por diante. É importante conhecer cada um desses estados, pois não é incomum a obtenção de resultados indesejados simplesmente por deixar um ou outro estado definido de maneira incorreta.
O OpenGL também foi projetado para funcionar mesmo que a máquina que esteja exibindo os gráficos não seja a mesma que contém o programa gráfico. Pode ser o caso dos dois computadores estarem conectados em rede e, nesse caso, o computador que gera os comandos é chamado cliente, enquanto o que recebe e executa os comandos de pintura é chamado de servidor. O formato da transmissão desses comandos (chamado protocolo) também é padronizado, então é possível que duas máquinas com sistemas operacionais e hardwares diferentes se comuniquem dessa forma. Se o OpenGL não está sendo executado numa rede, o computador é considerado ao mesmo tempo cliente e servidor.
Essa decisão de design tem uma consequência muito importante: os comandos do OpenGL não são imediatamente jogados para o hardware. Eles são agrupados para serem enviados mais tarde - o que não só otimiza o uso da rede, mas também abre margem para outras otimizações. Por consequência, um erro comum de muitos programadores é tentar medir o tempo levado pelos comandos de pintura simplesmente adicionando funções antes e depois de um comando (ou conjunto de comandos) o que, nessa arquitetura, certamente gerará resultados inválidos.
Afinal, não há garantias de que os comandos serão imediatamente executados, e, o que acaba sendo medindo com essa estratégia, é a velocidade que o OpenGL armazena os comandos para futura execução. Forçar a execução dos comandos também é uma estratégia ruim, já que com isso muitas otimizações são simplesmente desprezadas. Nessa arquitetura, a forma mais confiável de se medir a performance é através de software especial, que pode ser baixado na própria página do OpenGL.
[editar] Rendering Pipeline
O núcleo do OpenGL é conhecido como “rendering pipeline”. É importante notar que o OpenGL lida tanto com o desenho na forma vetorial, definidas por vértices, como com mapas de bits, definidos pixel-a-pixel. Os principais elementos desse pipeline estão descritos abaixo:
- Display Lists: Todos os dados, sejam de os vértices de geometrias ou pixels, podem ser salvos numa display list para uso atual ou posterior;
- Avaliadores (evaluators): Todas as primitivas geométricas, no OpenGL são descrita por vértices. Curvas e superfícies paramétricas devem podem ser descritas por fórmulas, que devem ser derivadas, para recaírem nos vértices. Quem faz essa avaliação são os evaluators (avaliadores).
- Operações pré-vértices: Para os dados de vértices, as operações pré-vertice convertem os vértices em primitivas de desenho. Nessa etapa, cada vértice é convertido em matrizes 4×4, então cálculos são realizados para que sejam convertidos do espaço 3D para as coordenadas de tela. Essa etapa ainda realiza operações de cálculos de textura, iluminação, materiais, etc. de acordo com quais estados tenham sido habilitados;
- Montagem de primitivas (primitive assembly): A fase de montagem primitiva preocupa-se com a eliminação das partes da geometria que caiam fora do plano. Essa fase também aplica os cálculos de perspectiva, o que faz com que objetos distantes pareçam menores em relação a objetos próximos. Se cálculos de culling estiverem ativos, parte dos objetos também podem ser desprezadas durante essa fase. É aqui também que decide-se se um polígono deve ser desenhado através de pontos ou linhas;
- Operações com Pixels: Enquanto os dados geométricos seguem pelo rendering pipeline, os mapas pixels passam por diferentes tipos de transformação. Primeiramente, os pixels são descompactados de acordo com o seu número de componentes, então eles tem sua escala ajustada, seu formato final é calculado, parte de sua área é recortada e então são enviados para o passo chamado rasterization.
- Montagem de texturas (texture assembly): Permite a aplicação de imagens como texturas das geometrias, para que elas pareçam mais realistas. Algumas implementações do OpenGL podem ter recursos especiais para acelerar esse passo;
- Rasterization: Transforma todos os dados em fragmentos. Cada fragmento é um quadrado que corresponde a pixels no framebuffer. Padrões de linhas e polígonos, largura da linha, tamanho do ponto, shading, calculos de cobertura e anti-aliasing são todos levados em conta durante essa fase. Color e valores de profundidade são considerados para cada fragmento;
- Operações sobre fragmentos (Fragment Operations): Finalmente, operações finais são aplicadas aos fragmentos, tais como recortes, operações de máscaras de bits (como blending) são aplicadas. Então, os pixels são finalmente calculados e são encaminhados para desenho.
[editar] Outras bibliotecas relacionadas ao OpenGL
O OpenGL fornece um conjunto poderoso de comandos, mas restrito apenas ao desenho. Várias bibliotecas existem para facilitar a manipulação de outros aspectos da aplicação, como as seguintes:
- OpenGL Utility Library (GLU): Fornece diversas funções para auxiliar na montagem de matrizes de visualização e projeção, desenho de superfícies e imagens 3D. Essa biblioteca é fornecida juntamente com as implementações do OpenGL e todas as rotinas dessa biblioteca tem o prefixo glu.
- Cada ambiente de janelas tem uma biblioteca de extensão do OpenGL. Por exemplo, o sistema X possui o glx, enquanto o Windows fornece a extensão wgl;
- OpenGL Utility Toolkit (GLUT): É um toolkit que abstrai o sistema de janelas, fornecendo uma interface simples para a criação de uma aplicação OpenGL.
E é muito bom pra uso.
[editar] Outras características importantes
- O OpenGL trabalha com a medida de ângulos em graus e não em radianos, como ocorre com a maioria das linguagens;
- Cada componente de cor no OpenGL é definido por um número de ponto flutuante, que varia de 0 até 1, e não um número inteiro de 0 até 255;
- As coordenadas gráficas no OpenGL seguem o eixo cartesiano. Assim, o número da linha é decrescente, e não crescente, como em boa parte das implementações.
