Representação de Cenas Tridimensionais: Grafo de Cenas Instituto de Computação - Universidade Federal Fluminense lvalente@ic.uff.br Março, 2004 Resumo Jogos de computador e outros tipos de aplicações visuais interativas frequentemente utilizam cenários tridimensionais como parte de seus ambientes virtuais. Usualmente, os cenários retratados são grandes demais para serem processados em tempo real pelos componentes de hardware existentes atualmente. Pode ser observado que nesses tipos de aplicações, o usuário visualiza apenas uma parte do cenário (aquela que está dentro de seu campo de visão). Desta forma, algoritmos e estruturas de dados que modelam os cenários devem levar esse aspecto em consideração na sua implementação, para que a visualização seja possível em tempo real. O objetivo deste trabalho é analisar um tipo específico de estrutura de dados para esse fim conhecido como grafo de cenas (scene graph). Abstract Computer games and other types of visual simulations often employ tridimensional scenes as a component of its virtual environments. Commonly, the depicted scenes are too broad to be processed in real-time by currently available hardware. In these kind of applications, the user can only see a fraction of the scene (the one which is inside his/her field of view). Hence, the algorithms and data structures modeled to represent those scenes must take that into account in implementation, so as the visualization can occur in real-time. This paper analyses one type of data structure designed to this purpose, known as the scene graph.
1. Introdução Este trabalho tem como objetivo descrever uma alternativa para representação de cenas tridimensionais em jogos para computador, conhecida como scene graph (grafo de cena). Jogos de computador e outros tipos de aplicações visuais interativas frequentemente utilizam cenários tridimensionais como parte de seus ambientes virtuais. Usualmente, os cenários retratados são grandes demais para serem processados em tempo real pelos componentes de hardware existentes atualmente. A questão é que tipo de política utilizar para a renderização 1 da cena. 2. Fundamentos A política mais trivial de ser implementada seria simplesmente desenhar todos os objetos e polígonos 2 que compõem a cena. Essa política é ineficiente porque, conforme pode ser observado nesses tipos de aplicações, o usuário visualiza apenas uma parte do cenário (aquela que está dentro de seu campo de visão). Desta forma, uma grande parte do esforço computacional aplicado é desperdiçado. Tal esforço poderia ser aplicado em outras partes da aplicação, como detecção de colisões e cálculos para simulação da Física, por exemplo. 2.1. APIs 3 Gráficas Existem duas APIs diferentes comumente utilizadas para implementação de gráficos tridimensionais em jogos de computador: OpenGL e Direct3D. OpenGL foi desenvolvida inicialmente por Silicon Graphics Inc. (SGI) e atualmente é mantida pela ARB 4. A ARB congrega vários representantes da indústria de hardware para gráficos tridimensionais. O Direct3D é desenvolvido pela Microsoft Corporation. Essas APIs oferecem algumas primitivas básicas (como pontos, linhas, triângulos, quadriláteros e polígonos), operações para manipulação do sistema de coordenadas e operações com matrizes (translação, rotação e escala) e efeitos como mapeamento de textura, entre outros comandos. Outra característica comum entre essas duas APIs é que elas são de modo imediato (immediate mode). Em APIs de modo imediato, os comandos submetidos alteram o estado do hardware gráfico assim que são recebidos. Ambas são, portanto, de baixo nível. Essas APIs oferecem apenas os comandos para acessar o hardware, não oferecendo nenhum tipo de ferramenta global em termos de cena.. Por exemplo, todos os polígonos especificados são processados, mesmo que estejam fora campo de visão do usuário. Esses polígonos são detectados apenas ao final do pipeline responsável pela renderização da imagem, quando já é muito tarde. 2.2. Pipeline Gráfico O pipeline gráfico é um conjunto de etapas realizadas pelo hardware para renderizar uma imagem, a partir dos parâmetros da cena. Os parâmetros da cena incluem os vértices, polígonos, dados sobre iluminação (fontes de luz, vetores normais das superfícies), transformações geométricas, entre outros. Um pipeline típico é descrito na figura 1: 1 Existem outras operações relacionadas, como detecção de colisão entre objetos que fazem parte do mundo virtual. 2 Supondo que a cena seja modelada com polígonos, o que é o usual. 3 Application Programming Interface 4 Architecture Review Board 2
Figura 1: Pipeline gráfico típico 2.2.1. Estados do hardware gráfico O estado do hardware gráfico representa uma configuração que está em uso em alguma parte do pipeline. Por exemplo, uma aplicação pode utilizar iluminação em uma cena. Desta forma, diz-se que o estado de iluminação está ligado. Embora essa afirmação possa não aparentar nenhuma complexidade, quando se determina que o hardware deve utilizar iluminação este é configurado para realizar uma série de operações especiais. O pipeline gráfico é projetado para realizar uma tarefa da melhor forma possível, de acordo com a sua configuração ( estados ). Ao se alterar um estado ( configuração ) talvez seja necessário interromper o pipeline para que este se ajuste aos novos parâmetros. É possível perceber que, dependendo do estado que for alterado, o pipeline pode ter que descartar todo o trabalho feito anteriormente, para poder se reconfigurar e retomar o trabalho com a nova configuração. Um exemplo de um estado que poderia causar esse efeito é o estado da iluminação. Além da iluminação, existem vários outros tipos de estados, como configurações de materiais (textura, cores) e configuração do sistema de coordenadas. 2.3. Culling Culling é o processo de eliminação de dados que não contribuem para a imagem final. Esses dados incluem objetos que não podem ser vistos pelo observador. O culling pode ser feito em diversas etapas no processo de renderização. Três tipos interessantes de culling são o backface culling, frustum culling e o occlusion cullling. 2.3.1. Backface Culling Este tipo de culling é feito no nível de polígono. Um polígono possui dois lados: o lado da frente e o lado de trás. Normalmente, o observador visualiza apenas um desses lados. O hardware gráfico, entretanto, renderiza os dois lados por padrão. Atualmente, o processo de backface culling é implementado em hardware, sendo necessário apenas habilitá-lo. Desta forma, ao utilizar o backface culling, a complexidade da cena é reduzida pela metade. 2.3.2. Frustum Culling Ao contrário do backface culling, o frustum culling pode eliminar objetos inteiros (compostos por vários polígonos) do volume de visão. O processo baseia-se em comparar as dimensões de um determinado objeto com as dimensões do frustum. O frustum é um volume tridimensional (volume de visão), relacionado com uma determinada projeção (perspectiva ou ortográfica). Em uma projeção em perspectiva, esse volume corresponde a uma pirâmide imaginária limitada pelos planos delimitadores near e far 5, que correspondem a distâncias relativas ao observador, na direção de sua linha de visão. Este esquema é ilustrado na figura 2. 5 Planos próximo e distante. 3
Figura 2: Volume de visão e definição Normalmente, os objetos possuem geometrias arbitrárias e complexas. Desta forma, para se decidir se um objeto é visível ou não, são utilizadas formas geométricas mais simples para aproximar o volume ocupado pelo objeto. O objetivo de se utilizar formas geométricas mais simples é padronizar e facilitar o cálculo da interseção. Essas formas geométricas, que são conhecidas como volumes delimitadores, são usualmente de dois tipos: esferas (bounding sphere, menor esfera que envolve o objeto) e paralelepípedos (bounding box, menor paralelepípedo que envolve o modelo). A figura 3 ilustra um esquema para o frustum culling: Figura 3: Esquema 2D de frustum culling Todos os objetos que encontram-se no interior do volume são visíveis. A vantagem de se usar o frustum culling é que uma grande quantidade de dados (polígonos) pode ser excluída do processo de renderização, antes de serem enviados ao hardware. Se um objeto está totalmente incluído no frustum, ele é enviado (i.e. seus polígonos) para o hardware. Se um objeto está parcialmente dentro do frustum, diversas estratégias podem ser aplicadas. Por exemplo, pode-se optar por enviar o objeto completo para o hardware ou particioná-lo e enviar apenas a parte que se encontra no interior do frustum. Os objetos que se encontram fora do frustum são descartados imediatamente. 2.3.3. Occlusion Culling O occlusion culling é uma variação mais sofisticada de culling onde objetos que são encobertos por outros são eliminados do pipeline gráfico. Como um exemplo, um observador está em frente a 4
um muro. Atrás do muro, existem diversos objetos complexos. Nesse exemplo, uma grande quantidade de processamento computacional pode ser poupada ao se descartar inicialmente todos os objetos que se encontram por trás do muro, já que estes não podem ser visualizados de maneira nenhuma. 3. Grafos de Cena (Scene Graphs) Um grafo de cena é uma estrutura de dados que utiliza uma abordagem de alto nível para modelagem e gestão de cenas, ao contrário das APIs gráficas básicas (OpenGL e Direct3D). Os usuários desse tipo de estrutura de dados não necessariamente precisam conhecer os detalhes de implementação de baixo nível para utilizá-la. Um dos conceitos centrais a respeito de um grafo de cenas é que este implementa uma estrutura hierárquica. 3.1. Descrição do Grafo de Cena Um grafo é uma estrutura matemática que armazena uma coleção de objetos de maneira organizada. Um grafo é formado por nós, que são conectados por arcos. Um arco conecta dois nós quaisquer. Comumente, um grafo de cenas é implementado como um DAG 6. É interessante formalizar algumas definições relacionadas com um DAG: Arco Representa uma conexão entre dois nós. Arco dirigido Nó Nó pai Nó filho Representa um arco que possui uma única direção, ou seja, estabelece uma relação unidirecional, como pai para filho. Representa uma estrutura que representa algum dado ou uma coleção de dados. Representa um nó que é o ponto de origem de um arco dirigido, ou seja, que inicia uma relação. Representa um nó que é o ponto de destino de um arco dirigido, ou seja, representa o término da relação. Nó descendente Se um nó B é filho de um nó A, então B é dito descendente de A. Todos os descendentes de B também são descendentes (ou sucessores) de A, e assim por diante, recursivamente. Nó ancestral Se um nó A é pai de um nó B, então A é dito ancestral de B. Todos os ancestrais de A (ou antecessores) também são ancentrais de B, e assim por diante, recursivamente. 6 Directed acyclic graph 5
Nó raiz Nó folha Representa um nó que não possui pai. Um grafo possui um único nó raiz, que representa o pai de todos os outros nós. Nó interior Caminho Travessia Branch Representa um nó que não possui filhos. Representa um nó que não é nó raiz nem nó folha. Representa uma sequência de nós conectados por arcos, iniciada em algum nó e terminada em um outro nó. Um tipo comum de caminho é aquele que se inicia no nó raiz e termina em algum nó folha. Representa a operação em que um caminho é percorrido. Um nó do tipo branch é um nó qualquer que possui vários filhos. Pode ser usado para agrupar outros nós, e está relacionado com a noção de subgrafo. Subgrafo ou branch graph Representa o conjunto de um nó qualquer do grafo e todos os seus filhos e descendentes. O nó qualquer escolhido é dito como um nó branch ou raiz do subgrafo. Directed Acyclic Graph (DAG) Árvore Representa um grafo que possui arcos dirigidos, sendo que nenhum caminho forma um ciclo. Desta forma, nenhum nó pode ser ao mesmo tempo filho e pai de um ancestral. Representa um caso especial de um DAG onde todos os nós filhos possuem um único nó pai. O conjunto de nós e arcos determina a organização do grafo, que pode ser estática ou dinâmica. Uma imagem é renderizada ao se aplicar algum algoritmo de travessia no grafo. Alteração de dados ou estrutura do grafo, assim como a especificação de algoritmos de travessia diversos, podem produzir imagens diferentes ao final do processo. A utilização de um DAG é útil porque permite que informações comuns em partes diversas da aplicação sejam divididas, em vez de replicadas. Como um exemplo, têm-se a figura 4, para um robô simples e um DAG (incompleto) que o representa: 6
Figura 4: Exemplo de um DAG para um robô simples Em contrapartida, uma árvore (incompleta) para representar o mesmo robô poderia ser construída da seguinte forma, como ilustrado na figura 5: Figura 5: Árvore para o robô da figura 4 Uma estrutura hierárquica de objetos é importante porque esta pode ser utilizada para otimizar vários procedimentos da aplicação, como por exemplo a renderização e a detecção de colisões. É possível aplicar a técnica do frustum culling em hierarquias de maneira eficiente. Por exemplo, têm-se uma cena que contém vários edifícios. Cada edifício pode conter vários quartos. Cada objeto (por exemplo um quarto) possui um volume delimitador cobrindo todas as suas extensões. Por sua vez, o objeto pai (o edifício) possui um volume delimitador que envolve todos os seus filhos (quartos). Ao se determinar que um edifício está fora do campo de visão, automaticamente está determinado que todos os seus filhos também estão fora do campo de visão. Isto representa uma vantagem significativa, pois é possível excluir grandes partes da cena que não contribuem para o resultado final (a imagem). Uma outra característica importante de hierarquias é a facilidade para manipulação. Por exemplo, um carro é constuído de várias partes como chassi e rodas. As rodas, por sua vez, são compostas de outros objetos como pneus. Uma possível hierarquia a ser modelada seria estabelecer um objeto carro como pai, e os outros objetos como seus filhos. É importante notar que podem existir outras sub-hierarquias, como no caso da roda. Para mover o carro, seria necessário apenas mover o objeto raiz da hierarquia. Todos os outros objetos, como estão organizados em relação ao objeto principal, seriam movidos automaticamente. Caso uma hierarquia não fosse utilizada, seria necessário mover cada objeto individualmente. Esta última possibilidade é ineficiente e sujeita a erros. 7
As APIs que implementam um grafo de cena (ou estrutura similar) são ditas APIs de modo de retenção (retained mode), pois os comandos enviados pelo desenvolvedor são armazenados para processamento em outras etapas. 3.2. Organização da Hierarquia Usualmente, as hierarquias representam relações espaciais entre seus elementos. Entretanto, como um grafo de cena é uma estrutura de modo de retenção, é possível organizar a cena de maneira a otimizar a utilização do hardware gráfico. Uma importante otimização a ser feita é ordenação por estados de hardware gráfico. O conjunto de estados do hardware gráfico representa uma configuração pipeline de processamento. Alterações de estado podem ser custosas porque podem provocar a paralização do pipeline gráfico, para reconfiguração com novos parâmetros. Como um exemplo, o estado atual de iluminação. Quando se requisita ao hardware que utilize iluminação na cena, este é configurado para realizar uma série de operações especiais. Existem várias variáveis envolvidas na configuração da iluminação, como tipos de fontes de luz (direcional, posicional), posição da fonte de luz na cena, cores relacionadas às diversas componentes da fonte de luz (cor difusa, cor de luz especular), entre outras. É possível perceber que quando se requisita que a iluminação seja ligada ou desligada, todo o processamento feito anteriormente terá que ser descartado, e o pipeline, terá que ser reiniciado. O custo (overhead) associado com essa reconfiguração (e com a perda do trabalho feito anteriormente) pode ser muito alto para a aplicação. Em um outro exemplo, têm-se uma cena que possui cem esferas metálicas (estado 1), cem esferas de madeira (estado 2) e cem esferas de mármore (estado 3). Supondo que o estado em consideração seja apenas o material em questão, podem existir três mudanças de estado (se a cena for organizada por estado) ou trezentas (se a cena for organizada espacialmente). Os grafos de cena podem organizar a cena hierarquicamente utilizando os estados do hardware para tentar maximizar o desempenho. Por exemplo, se para um determinado hardware a mudança da textura atual é muito custosa, pode ser interessante classificar a hierarquia por textura (para esse hardware). Entretanto, essa configuração pode não ser ideal para outros ambientes. É preciso ressaltar que existe um dilema entre organização por subdivisão espacial e organização por estados do hardware. Frequentemente, a organização por um critério implica na desorganização do outro. Ao se ordenar uma cena por estado, perde-se a relação espacial entre os elementos. Como um exemplo, um carro pode ser formado por peças que utilizam diversos materiais, como vidro, metal, plástico e borracha. Uma possível cena poderia ser formada por dezenas de carros desse tipo. Ao se organizar a cena espacialmente, é possível aplicar o culling e eliminar carros inteiros do pipeline. Entretanto, talvez possa ser necessário alterar o estado do material diversas vezes. De outra forma, ao se organizar o grafo de cenas por estado, a alteração de estados será minimizada. Entretanto, será poderá ser necessário aplicar o culling mais de uma vez para um mesmo objeto (i.e. aplicar em cada parte que compõe o objeto). A melhor abordagem dependerá de critérios como o custo de mudanças do estado do hardware gráfico e complexidade espacial da cena. 8
3.3. Nós do Grafo de Cena Existem vários tipos diferentes de nós em um grafo de cena. Cada tipo de nó armazena algum tipo de dados ou possui uma determinada responsabilidade no grafo. Esta seção descreve alguns tipos comuns de nós. 3.3.1. Agrupamento Os nós de agrupamento possuem um papel importante porque eles são responsáveis por estabelecer subhierarquias dentro do grafo. Os nós de agrupamento podem ter um número variável de filhos. Em grafos de cena que utilizam o paradigma de orientação a objetos, é comum estabelecer tipo genérico de grupo como a base para todos os demais. Existem algumas variações de nós de agrupamento utilizadas em grafos de cena, como descritas a seguir. 3.3.1.1. Transformações geométricas Tecnicamente, um nó de transformação geométrica também pode ser considerado um nó de agrupamento. Um nó deste tipo estabelece um posicionamento (translação, rotação) ou dimensionamento (escala) para todos os seus filhos. Desta forma, todos os descendentes são afetados pela transformação geométrica definida. Existem dois tipos de nós de transformação geométrica: nós de transformações geométricas estáticas e nós de transformações geométricas dinâmicas. Um nó de transformação geométrica estática define um sistema de coordenadas estático (SCS) 7. Em um sistema de coordenadas estático, os valores para a transformação, uma vez estabelecidos, não são alterados. Este tipo de nó pode ser usado para especificar, por exemplo, o posicionamento de objetos que não se movem no cenário. Por ser estático, esse tipo de nó também pode ser utilizado para pré-computar informações importantes como volumes delimitadores e informações para cálculo de colisões. Um nó de transformação geométrica dinâmica define um sistema de coordenadas dinâmico (DCS) 8. Em um sistema de coordenadas dinâmico, os valores da transformação são continuamente alterados. Por exemplo, um nó deste tipo poderia ser utilizado para armazenar o posicionamento de um objeto animado do cenário, como descrito na figura 6. Nesta figura, o modelo de um carro utiliza nós do tipo DCS para simular a animação das rodas. As rodas, ao girarem, possuem uma rotação em relação ao carro. Existem, portanto, quatro nós do tipo DCS, um para cada roda. 7 Static Coordinate System 8 Dynamic Coordinate System 9
Figura 6: Exemplo de uso de um nó de transformação geométrica dinâmica É interessante notar que o carro possui um nó DCS como pai, que pode ser usado para determinar o seu posicionamento na cena. Como as rodas possuem sistemas de coordenadas definidos em relação a seu pai (o carro, que por sua vez possui como pai o nó DCS), o posicionamento delas na cena é feito automaticamente ao se aplicar a transformação definida pelo primeiro nó DCS. 3.3.1.2. LOD 9 A técnica de LOD é utilizada como uma otimização para a renderização. Em projeções em perspectiva, quanto maior é a distância de um objeto em relação ao observador, menor é o seu tamanho (esse efeito é conhecido como perspective foreshortening) e, consequentemente, menor é o seu nível de detalhe. Entretanto, sem utilizar nenhum tipo de otimização, ao se enviar um objeto que contenha mil polígonos para o hardware, esses mil polígonos serão processados independentemente do nível de detalhe real do objeto (aquele que é percebido pelo observador). Isto ocorre frequentemente em APIs de baixo nível porque essas APIs não possuem noção de objetos e modelos, mas apenas de vértices e polígonos. A técnica de LOD, então, cria simplificações diversas para a geometria de um dado objeto baseada em alguns parâmetros pré-definidos (como distância em relação ao observador). Como um exemplo, têm-se a figura 7: 9 Level of Detail 10
Figura 7: Exemplo de LOD para representação de um objeto Um nó do tipo LOD pode ser utilizado para se selecionar automaticamente uma simplificação, conforme a figura abaixo. Cada filho do nó representa o mesmo objeto em resoluções diferentes. Figura 8: Nó do tipo LOD 3.3.1.3. Switch Os nós do tipo switch possuem função semelhante ao comando switch encontrado em diversas linguagens de programação: dada uma chave, selecionar uma das alternativas. As alternativas possíveis são representadas como filhos do nó. 3.3.1.4. Sequenciamento Um nó de sequenciamento é um tipo especial de switch. Cada filho desse tipo de nó representa um quadro de uma animação. O nó pai é utilizado, então, para controlar automaticamente o fluxo da animação. 3.3.1.5. Grupo Ordenado Um nó de grupo ordenado representa um grupo onde a ordem de travessia é fixa. Por exemplo, pode ser utilizado para se aplicar um adesivo ( decal ) em uma parte da cena. Neste caso, o adesivo (ou outro detalhe qualquer) precisa, necessariamente, ser renderizado após todos os outros irmãos para que seja visível. 11
3.3.2. Geometria Os nós de geometrica armazenam dados necessários para descrever a forma de um objeto qualquer. Esses nós podem ser diversos subtipos. 3.3.2.1. Geometry Armazenam informações como coordenadas de vértices e valores para vetores normais. Adicionalmente, pode ser especificado o tipo de primitiva a ser usada para renderizar a geometria (como pontos, linhas, triângulos ou quadriláteros). Também podem ser utilizados para armazenar a representação de textos (2D ou 3D). 3.3.2.2. Shape Uma primitiva pode ser também um objeto tridimensional, como cubos, esferas ou pirâmides. É comum, também, encontrar tipos de nós que representem essas figuras. 3.3.2.3. Billboard A técnica de billboards é utilizada para simular a geometria de alguma figura tridimensional em duas dimensões. É bastante utilizada em jogos, porque simula uma geometria complexa utilizando apenas um polígono (quadrilátero). Um dos objetos que é mais simulado com essa técnica são árvores. Uma árvore qualquer possui uma geometria complexa. Em aplicações como jogos, normalmente o usuário não está interessado em apreciar todos os detalhes da árvore. Utiliza-se então um quadrilátero e uma textura para simular a geometria da árvore. A textura contém uma projeção bidimensional da árvore. A textura, então, é aplicada ao quadrilátero, que é exibido de forma a sempre estar de frente para o observador. Desta forma, o observador é iludido a acreditar que está visualizando uma figura complexa. Essa técnica também é conhecida como sprite. Algumas implementações de grafos de cena oferecem nós para representar esse efeito. 3.3.3. Aparência Os nós de aparência são independentes da geometria porque representam, basicamente, materiais. Entre os dados armazenados, encontram-se definições de propriedades de materiais (cor ambiente, cor difusa, cor especular, brilho, rugosidade, etc) e informações sobre mapeamento de texturas (tipo de textura, dados da textura). Estes tipos de nó determinam vários estados do hardware gráfico. 3.3.4. Outros tipos de nós Esta seção lista alguns outros tipos comuns de nós, que não se enquadram nas categorias anteriores. 3.3.4.1. Fontes de Luz As fontes de luz podem afetar a cena globalmente ou localmente. Uma fonte de luz global poderia ser considerada como uma luz ambiente. Um nó do tipo fonte de luz pode ser, também, considerado como um nó de grupo. Nesse 12
contexto, poderia ser considerado que apenas os objetos definidos como descendentes do nó de fonte de luz seriam iluminados. Várias informações podem ser armazenadas, como intensidade, cor (componente de luz difusa, componente de luz ambiente, componente de luz especular), estado (ligado ou desligado), atenuação, formato (para fontes do tipo spotlight), entre outros. Os tipos de fonte de luz podem variar, como fontes direcionais ou spotlights. As fontes de luz podem ser afetadas por nós que representem transformações geométricas. Nesse caso, a posição e orientação da fonte de luz será determinada pela transformação. 3.3.4.2. Câmeras Uma câmera representa uma abstração para o ponto de vista do observador. O ponto de vista inclui a posição e orientação do observador em relação à cena. É incluída também a projeção utilizada para formar o volume de visão (e para a conversão para 2D). Algumas implementações, como Java3D, separam as informações sobre câmeras e conteúdo do grafo de cena, como na figura 10. Figura 9: Separação das informações de câmera e cena no grafo Desta forma, em Java3D, existem dois ramos principais: o ContentBranch e o ViewBranch. O ContentBranch é iniciado por um nó de agrupamento genérico (BG) 10. Existem outras variações sobre a definição de câmera. Em OpenSceneGraph não é definido um tipo de nó para câmeras sendo necessário que o desenvolvedor a especifique através de transformações matriciais. Em OpenSG, é definido um tipo de nó para câmera que faz parte do grafo. Na prática, o efeito final é o mesmo porque a transformação que a câmera define deve ser a primeira a ser aplicada na fase de renderização. 10 Branch Group 13
3.3.4.3. Som O grafo de cena pode ser utilizado também para armazenar informações não visuais como sons. Um nó pode descrever o tipo de fonte sonora (pontual, ambiente) e o seu conteúdo. Esses nós também podem armazenar outros dados como posição e direção da fonte sonora, quando for aplicável. 4. Utilização de Grafos de Cena A utilização de um grafo de cena em uma aplicação envolve basicamente dois passos, ambos descritos a seguir. 4.1. Construção O primeiro passo é a construção do grafo. A construção consiste em criar instâncias dos nós, determinar os valores que os nós representam e determinar as conexões (hierarquia) entre os nós. Um dos nós é escolhido para ser o nó raiz, que é o ponto de entrada no grafo. A determinação dos valores dos nós e suas conexões podem ser feitos de duas maneiras: Procedural Uma aplicação que utiliza o modo procedural utiliza funções da API de grafo de cena para criar instâncias de nós, determinar os valores de seus dados e criar os relacionamentos entre eles. Os valores dos dados dos nós, nesse caso, poderiam ser gerados por algum tipo de algoritmo. É importante notar que esse tipo de abordagem é pouco flexível em relação ao conteúdo do grafo de cena. Se o conteúdo do grafo é alterado com frequência, pode ser necessário recompilar a aplicação para que o efeito dos novos dados seja efetivamente visualizado. Por arquivos Essa é a maneira mais flexível no que se refere ao conteúdo. O desenvolvedor pode criar uma cena em programas de modelagem tridimensional, exportá-la para algum formato de arquivo e a seguir, importá-la para a aplicação. Dependendo da complexidade da cena, esse método pode ser mais conveniente por permitir que a cena seja modelada e testada antes de ser incorporada à aplicação (como em um jogo de computador). Entretanto, existem outros problemas, como a necessidade de estabelecer um formato de arquivos padrão e ferramentas para interpretar o conteúdo do arquivo e construir o grafo. Não se pode dizer que um método é melhor do que o outro. Pode-se dizer que um método é mais adequado ou menos adequado para uma aplicação, dependendo dos requisitos desta aplicação. 4.2. Travessia A travessia do grafo começa pela raiz e termina em nós folha. Após a travessia do grafo, obtêmse uma imagem renderizada. 14
A travessia do grafo é um passo importante e está diretamente relacionada com o desempenho da aplicação. Uma travessia completa percorre todos os caminhos possíveis do nó raiz até os nós folhas mas, geralmente, isso não é necessário. Uma travessia eficiente deve explorar a estrutura hierárquica do grafo para realizar operações de culing. Operações de culling permitem que partes do grafo sejam podadas (pruned), eliminando dados (que podem ser muitos) que não contribuem para o resultado final da imagem. A operação de culling pode ser aplicada comparando-se o volume delimitador de um determinado nó com o volume definido pelo frustum de uma câmera, por exemplo. Se não existe interseção entre os dois volumes, não será necessário realizar a travessia nesse nó, pois não é possível visualizar os dados representados por ele a partir do ponto de vista atual. Outra questão importante relacionada com travessias é a alteração do estado do hardware gráfico. No início da travessia, o estado é reiniciado com valores padrão. Conforme a travessia é realizada, os estados podem vir a ser alterados por causa dos valores contidos nos nós. Os grafos de cena podem utilizar algum esquema de cache para armazenar o estado atual antes de realizar a travessia de algum filho de um nó qualquer. Esse cache é utilizado para restaurar o estado do hardware quando a travessia pelo filho terminar. Desta forma, para realizar a travessia pelo próximo filho, não será necessário percorrer o grafo desde a raiz novamente para decidir qual é o estado do hardware inicial para aquele nó. Um exemplo simples é a matriz utilizada para se determinar o sistema de coordenadas atual. Inicialmente, a matriz corresponde à matriz identidade. Conforme a travessia é realizada, nós que representam transformações geométricas alteram o valor da matriz atual (os valores são concatenados). Por exemplo, um grafo de cenas modela um carro que possui um chassi e quatro rodas. O grafo possui um nó que determina o posicionamento do carro na cena. O filho desse nó é o subgrafo que representa o carro. Inicialmente, a matriz inicial é a indentidade. Ao percorrer o nó que determina a posição do carro, a matriz atual é concatenada com a matriz definida pelo nó. A seguir, a travessia é feita pelo nó que agrupa a hierarquia definida para o carro. Cada roda possui um deslocamento em relação ao chassi do carro. Desta forma, para renderizar uma roda, é necessário concatenar a matriz atual com a matriz que define o posicionamento da roda. Após a renderização da roda, é necessário restaurar a matriz anterior, para que todas as rodas sejam renderizadas na posição correta. Com a utilização do cache, a matriz pode ser restaurada facilmente. Caso contrário, seria necessário percorrer novamente o grafo desde a raiz até a outra roda, e assim sucessivamente, até renderizar todas elas. 4.3. Otimizações Como foi descrito anteriormente, a alteração de estados do hardware geralmente é uma operação custosa. Algumas APIs de grafos de cena, como o Java3D, oferecem uma operação definida como compilação do grafo de cena. A compilação do grafo de cena pode realizar duas tarefas: Reordenação dos nós A operação de reordenação dos nós tem como objetivo reagrupar os nós de modo a minimizar o número de alterações de estados do hardware gráfico feitas durante a travessia. É importante ressaltar que a reordenação é feita de modo a não alterar os resultados finais da renderização. 15
Otimização do grafo A operação de otimização do grafo tem como objetivo produzir um grafo de funcionalidade equivalente com um menor número de nós. Por exemplo, vários nós que definem operações com matrizes podem ser concatenados em um único nó, que armazenará o resultado do cálculo. A compilação do grafo é um tipo de operação que é executada, geralmente, uma única vez, no início da aplicação. Entretanto, se durante a execução alguma parte do grafo é alterada, pode ser necessário realizar uma nova compilação, o que pode prejudicar o desempenho. 5. Vantagens Em resumo, algumas vantagens de se usar um grafo de cenas são: Desempenho Os grafos de cena oferecem um framework de alto desempenho para aplicações que utilizam gráficos tridimensionais. Isto ocorre porque os grafos de cena exploram duas técnicas importantes: eliminação de objetos que não contribuem para o resultado final da imagem (culling) e ordenação por estados de hardware como texturas e materiais. Produtividade Os grafos de cena implementam grande parte dos requisitos necessários para se desenvolver uma aplicação que utilize gráficos tridimensionais. Desta forma, o desenvolvedor pode se concentrar no conteúdo de sua aplicação. Um grafo de cenas possibilita a aplicação de paradigmas como orientação a objetos, permitindo a reutilização de projetos. Portabilidade A interface oferecida pela estrutura de dados encobre detalhes como a API de baixo nível utilizada para enviar comandos para o hardware e leitura e escrita de arquivos relacionados (imagens, modelos tridimensionais). Desta forma, é possível em algum momento alterar a API utilizada sem afetar as aplicações clientes diretamente, por exemplo. Traduções da aplicação para execução em outros ambientes de hardware podem necessitar apenas de recompilação de código fonte. Escalabilidade A estrutura oferecida pelos grafos de cena faz com que seja possível aumentar a complexidade da simulação de maneira controlada. Por exemplo, cenários mais extensos podem ser incorporados sem afetar significativamente o desempenho porque o grafo de cena utiliza culling para determinar os objetos que podem ser visualizados. Um grafo de cena pode controlar configurações de hardware gráfico diversas (como sistemas com vários processadores), sem interferência direta do desenvolvedor. 6. Desvantagens A principal desvantagem está em relação ao overhead (custo) relacionado com a travessia do grafo. Travessias mal implementadas podem acarretar degradação de desempenho. 16
7. Considerações Finais Neste trabalho, foi descrita uma alternativa para representação de cenas conhecida como scene graph (grafo de cenas). Foram apresentados alguns conceitos básicos relacionados com gestão de cenas em geral, como pipeline gráfico, estados do hardware gráfico e culling. A organização e os componentes do scene graph foram descritos nas seções posteriores, assim como modos de utilização. Os nós do scene graph possuem um bom grau de abstração, representando entidades como agrupamentos diverso, formas e transformações geométricas, câmeras, fontes de luz, entre outros. A organização hierárquica dos nós torna mais intuitiva a construção de cenas (para efeitos de comparação, imaginar um objeto, como um carro, representado usando um scene graph e representado diretamente por vértices e polígonos). Um scene graph é uma estrutura de representação de cenas genérica, não sendo otimizada (a princípio) para um determinado tipo de cena (como cenas de interiores ou cenas a céu aberto). Desta forma, sua generalidade talvez não seja adequada para todos os tipos de aplicações. 8. Glossário API (Application Programming Interface) Conjunto de rotinas utilizadas por uma aplicação para acessar serviços de um Sistema Operacional ou hardware. Como um exemplo, a API do Windows oferece funções para a gestão de janelas, ícones, menus, arquivos, entre várias outras. ARB Architecture Review Board. Representa um consórcio de fabricantes de hardware para gráficos tridimensionais, que controla a especificação do OpenGL e promove este padrão. Bounding Box Menor paralelepípedo que envolve um grupo de objetos. Bounding Sphere Menor esfera que envolve um grupo de objetos. Culling Processo de eliminação do pipeline de dados do que não contribuem para a imagem final. Direct3D É uma API desenvolvida por Microsoft Corporation, para renderização de imagens em duas ou três dimensões. Framework Estrutura reusável para desenvolvimento de software. Esta estrutura implementa características ou funcionalidades comuns a todas as aplicações de um determinado gênero, de modo que é possível iniciar o desenvolvimento a partir de etapas mais avançadas. 17
Frustum O frustum é um volume tridimensional (volume de visão), relacionado com uma determinada projeção (perspectiva ou ortográfica). Em uma projeção em perspectiva, esse volume corresponde a uma pirâmide imaginária limitada pelos planos delimitadores próximo (near plane) e distante (far plane). GPU Graphics Processing Unit, ou Unidade de Processamento Gráfico. São os processadores encontrados nas placas gráficas atuais. OpenGL É uma API utilizada para Computação Gráfica em duas ou três dimensões. Desenvolvida inicialmente por Silicon Graphics Inc. (SGI), possui alto desempenho e portabilidade, sendo implementada para trabalhar junto com hardware que seja otimizado e projetado para a exibição de gráficos tridimensionais. Atualmente, é mantida pela ARB. Pipeline Representa as etapas a serem realizadas para criar uma imagem a partir de uma especificação (como vértices e polígonos). O processo de execução do pipeline corresponde à renderização. Plano Delimitador Distante (far plane) Limite superior do volume de visão (viewing frustum), além do qual objetos não são renderizados. Plano Delimitador Próximo (near plane) Limite inferior do volume de visão (viewing frustum), antes do qual objetos não são renderizados. Spotlight Fonte de luz que emite um cone de luz. Objetos que encontram-se fora do volume definido pelo cone não são iluminados. Renderização Processo de conversão de primitivas em uma imagem na área de memória relacionada ao vídeo. 18
9. Referências Bibliográficas OSG03 OpenSceneGraph: http://www.openscenegraph.org, 2003 OpenSG03 OpenSG: http://www.opensg.org, 2003 ORM03 OpenRM Scene Graph: http://www.openrm.org, 2003 J3DTut03 Sun Microsystems Java3D API Tutorial, Version 1.2, http://java.sun.com/products/java-media/3d/collateral/, 2002 J3DSpec03 SgiOP03 SgiOI03 Walsh03 Sun Microsystems Java 3D API Specification, The, http://java.sun.com/products/java-media/3d/releases.html, 2003 SGI Open Performer: http://oss.sgi.com/projects/performer/ SGI Open Inventor: http://oss.sgi.com/projects/inventor/ Walsh, Peter Advanced 3D Game Programming with DirectX 9.0, Wordware Publishing, 2003 Selman02 Selman, Daniel Java3D Programming, Manning, 2002 Wright99 Foley90 BarZeev03 Hitcher00 Bethel00 Lod97 Wright, Richard S.; Sweet, Michael OpenGL SuperBible Second Edition, Waite Group Press, 1999 Foley, James et al Computer Graphics Principles and Practice, Second Edition, Addison-Wesley, 1990 Bar-Zeev, Avi Scene Graphs Past, Present and Future, Online: http://www.realityprime.com/scenegraph.php, 2003 Hitchner, Lewis Scene Description and Management The Scene Graph, Online: http://www.csc.calpoly.edu/~hitchner/csc471.w2003/titlepage.html, 2000 Bethel, Wes Scene Graphs Explained, Online: http://www.tomshardware.com/column/20000110/index.html, 2000 Garland, Michael; Heckbert, Paul Surface Simplification Using Quadric Error Metrics, SIGGRAPH 97, Online: http://graphics.cs.uiuc.edu/~garland/research/quadrics.html 19