
\documentclass[oneside,12pt]{article} 
\usepackage{times} 
\usepackage[pdftex]{graphicx}
\usepackage[text={22.94cm,17.59cm},centering,top=2cm,left=2cm,right=2cm,bottom=3cm,noheadfoot]{geometry} 
\usepackage{textcomp}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[english,portuguese]{babel}
\usepackage{titlesec}
\usepackage{sibgrapi}

\begin{document}

\title{
  Experiência de Portais em Ambientes Arquitetônicos Virtuais
}
\shorttitle{Portais em Ambientes Virtual}

\author{ {\small
  Romano J. M. Silva\authortag{1}, 
  Gustavo N. Wagner\authortag{2}, 
  Alberto B. Raposo\authortag{3},
  Marcelo Gattass\authortag{4} 
  }
}
\shortauthor{R. Silva, G. Wagner, A. Raposo, M. Gattass}

\address{
  TeCGraf - Grupo de Tecnologia em Computação Gráfica / PUC-Rio\\
  {\authortag{1} Mestrando em Computação Gráfica na PUC/RJ}\\
  {\authortag{2} Graduando em Engenharia de Computação na PUC/RJ}\\
  {\authortag{3} Pesquisador, bolsista de produtividade em pesquisa do CNPq, processo no 305015/02-8}\\
  {\authortag{4} Professor titular do Departamento de Informática da PUC/RJ}\\
  {\footnotesize\tt\{romano,gustavow,abraposo,gattass\}@tecgraf.puc-rio.br}
}

\resumo{ Este artigo apresenta uma implementação de um algoritmo de portais para melhorar o desempenho da navegação em tempo real em ambientes arquitetônicos virtuais com alto realismo gráfico. O algoritmo foi implementado sobre a biblioteca OpenSceneGraph, permitindo seu uso com várias ferramentas de realidade virtual e modelos provenientes de aplicações comerciais.}

\abstract{ This paper presents an implementation of a portal algorithm to improve the perfomance of real time walkthroughs in architectural virtual environments with high graphical realism. The algorithm was implemented with the OpenSceneGraph library, allowing its use with several virtual reality tools and models exported from commercial applications.}

\maketitle

\section{Introdução}

Mesmo com o crescente progresso nas áreas de aplicação de ambientes virtuais, a navegação em modelos arquitetônicos utilizando as tecnologias de realidade virtual continua sendo uma tarefa constantemente aprimorada. Seu emprego permite, por exemplo, que arquitetos, engenheiros e usuários possam prever e verificar o interior de um apartamento antes da sua conclusão. Decoradores e projetistas podem, ainda,  analisar a iluminação do ambiente e o posicionamento de objetos levando em consideração critérios de ergonometria.

A fim de aprimorar o resultado das análises, os usuários têm exigido maior realismo gráfico em tempo real. Maior realismo gráfico significa aumento do número de primitivas do modelo. Além disso, efeitos de iluminação, como sombras e radiosidade, devem ser exibidos no ambiente virtual. 

As placas gráficas atuais têm aumentado seu poder de processamento de forma exponencial, porém, o problema também tem se tornado mais complexo. Embora algumas placas já permitam ótimas otimizações no cálculo de sombras, nenhuma delas é capaz de processar dados de radiosidade ou sombras de muitas fontes de luz em tempo real. O número de primitivas agrava ainda mais o problema: a utilização de texturas e {\it shaders} (como {\it bump-mapping}, por exemplo), são necessidades típicas no modelo. Se as imagens não forem bem organizadas, um número muito grande de texturas pode resultar numa degradação de desempenho da cena. Outro fator complicante é que o usuário ou projetista quer ver o resultado de uma mudança feita no projeto imediatamente, ou no menor tempo possível, ou seja, a etapa de pré-processamento do modelo deve ser curta.

Diversas são as técnicas de otimização existentes em computação gráfica a fim de evitar o envio de primitivas desnecessárias para a placa gráfica. A principal delas é a técnica de descarte por campo de visão ({\it view-frustum culling}): objetos que estejam fora do campo de visão não são enviados para a placa gráfica, pois os mesmos não contribuirão para a imagem final. 

Outra otimização existente é o descarte por oclusão ({\it occlusion culling}). A idéia básica desses algoritmos é o descarte de objetos que estão ocultos por outros objetos da cena. Dentro dessa categoria de algoritmos, existe uma solução adequada para ambientes fechados: o algoritmo de célula/portal. 

O algoritmo de célula/portal trabalha sobre um cena organizada em salas (células), onde cada célula possui um conjunto de objetos renderizáveis e uma lista de portais, que são portas, janelas ou outras conexões com células vizinhas. O algoritmo encontra a célula onde o observador se localiza e renderiza os objetos dessa célula usando descarte por campo de visão. Após isso, ele procura todos os portais visíveis dessa célula e renderiza suas células adjacentes recursivamente, reduzindo o tamanho do campo de visão à medida que atravessa cada portal.

Os primeiros algoritmos de célula/portal foram propostos por Airey~\cite{airey90towards}, e Teller e Séquin~\cite{teller91visibility}. As duas implementações exigem uma demorada etapa de pré-processamento e são restritos a ambientes 2-D ou 2.5-D (mapa de alturas). Luebke e Georges~\cite{luebke95portal} inovaram ao criar um algoritmo rápido para o cálculo de oclusão dos portais. 

A implementação de Luebke e Georges executa um rápido pré-processamento para montagem da estrutura de dados de portais. Essa estrutura é inserida em um grafo de cena. Durante o percorrimento do grafo, os portais, ao serem atravessados, diminuem o campo de visão. O teste de oclusão se reduz, portanto, a um simples teste de descarte com base no novo campo de visão do portal. 

No presente trabalho foi feita a implementação do algoritmo de Luebke e Georges~\cite{luebke95portal} estendendo a biblioteca de grafo de cena OpenSceneGraph~\cite{osg}. O OpenSceneGraph (OSG) é uma biblioteca com código aberto, independente de plataforma, escrita na linguagem de programação C++ e sobre a biblioteca gráfica OpenGL~\cite{opengl2003}. Entre os seus usos, estão a simulação visual, a modelagem científica, realidade virtual e jogos. Para realização da navegação no ambiente virtual foi utilizada a biblioteca de realidade virtual VR~Juggler~\cite{bier00vrjuggler,bier00vrjuggler2}.

O trabalho está organizado da seguinte maneira: as ferramentas utilizadas serão descritas na seção 2. Na seção 3, será detalhada a implementação do algoritmo de portais no OpenSceneGraph. Na seção 4, serão mostrados os resultados obtidos seguidos da conclusão, na seção 5.

\section{Ferramentas utilizadas: OpenSceneGraph e VRJuggler}

O OpenSceneGraph (OSG) é uma biblioteca que implementa várias funções de um grafo de cena: descarte por campo de visão, plano de oclusão (utilizando o algoritmo de {\it Shadow Frusta}~\cite{hudson97frusta}), descarte de pequenos objetos, suporte a níveis de detalhe discretos, ordenação por estado (um estado define as características de um objeto: material, textura, iluminação, etc.), suporte a diversos tipos de arquivos, {\it vertex arrays} e {\it display lists}, sendo os dois últimos otimizações específicas do OpenGL. 

Nesse projeto, dois fatores foram fundamentais para a escolha da biblioteca OSG. De imediato, a navegação que funcionava diretamente sobre o OpenGL, no OSG teve um ganho de desempenho considerável. A extensibilidade da biblioteca permitiu que funcionalidades não existentes, como o sistema de portais, fossem implementadas sem que nenhuma linha de código fosse adicionada ou modificada no núcleo da biblioteca. 

A favor do OSG também temos o fato dele ser independente de plataforma, ter código aberto e ser gratuito. Apesar da inexistência de publicações, vários projetos comerciais e acadêmicos já o utilizam. As bibliotecas de realidade virtual VR~Juggler~\cite{vrjuggler2003} e Vess~\cite{vess2003}, o motor de física da CM Labs~\cite{cmlabs2003} e a biblioteca de animação de personagens Cal3D~\cite{cal3d2003} são alguns dos exemplos de contribuição da sua comunidade de usuários. Junto a biblioteca existem exemplos para demonstrar toda a sua funcionalidade, o que compensa a falta de documentação adequada. Essa pequena falha, junto à necessidade de conhecimentos avançados de orientação a objetos, torna o aprendizado demorado.

O OSG divide a tarefa de renderização em três etapas: a etapa de atualização (UPDATE), de descarte (CULL) e a de desenho propriamente dita (DRAW). Na etapa de atualização são executadas, por exemplo, simulações ou atualizações da aplicação e do grafo de cena quando o mesmo tem objetos dinâmicos. Durante o descarte, os objetos que estão fora do campo de visão ou que pouco contribuam para a cena (ocupam menos que 1 {\it pixel}, por exemplo) são eliminados. Os objetos restantes formam uma lista de objetos renderizáveis.

A lista de objetos renderizáveis pode ser ordenada da maneira que o desenvolvedor definir. O OSG pré-define duas maneiras  de ordenar essa lista. Quando os objetos são opacos, eles são ordenados por estado e colocados na frente da lista. Dessa forma, minimiza-se a troca de estado do OpenGL, já que objetos com o mesmo estado serão renderizados em sequência. Quando os objetos são transparentes, os mesmos são ordenados de trás para frente e colocados no final da lista de renderização. Assim, todos os objetos opacos são renderizados primeiro, seguidos dos objetos transparentes, evitando que o teste de {\it Z-Buffer} feito pela placa gráfica descarte objetos que estejam atrás dos objetos transparentes. O OSG fornece ainda um sistema de {\it callbacks} para o desenvolvedor implementar o seu próprio algoritmo de ordenação.

O OSG possui uma classe que percorre o grafo de cena removendo os nós vazios, pré-calculando as transformações realizadas em objetos estáticos e agregando estados semelhantes, aumentando o desempenho da aplicação em termos de quadros por segundo.

Ele utiliza vários conceitos de orientação a objeto e padrões de projeto~\cite{gammadesign}. Entre os diversos padrões de projeto que o OSG implementa estão a cadeia de responsabilidade ({\it chain of responsability}), a composição ({\it composite}) e o visitador ({\it visitor}).

A cadeia de responsabilidade é empregada na criação de leitores dos arquivos de modelo e imagem que compõem a cena. Os leitores são criados como {\it plug-ins} dinâmicos. Essa técnica foi utilizada para criação do leitor para um novo tipo de arquivo utilizado neste trabalho, sem que houvesse necessidade de recompilar toda a biblioteca.

\begin{figure}[htb]
  \begin{center}
     \includegraphics{images/visitors.pdf}
  \end{center}
  \caption{Classes do OpenSceneGraph: utilização de padrões de projeto.}
  \label{fig:visitors}
\end{figure}

No OSG, qualquer percorrimento do grafo é feito através do padrão visitador. A figura~\ref{fig:visitors} ilustra as classes abstratas que compõem este padrão. A classe {\it Node} é a classe raiz de todos os objetos que podem ser inseridos no grafo de cena. Dela herda a classe {\it Group}, empregando o padrão composição. Um grupo contém uma lista de nós filhos. E cada nó mantém sua lista de pais. No OSG é permitido que um nó tenha vários pais a fim de haver compartilhamento de nós em locais diferente do grafo. 

A classe {\it NodeVisitor} é a classe mãe de todos os visitadores. Ela permite percorrer o grafo de cima para baixo, de baixo para cima ou em percurso redefinido pelo método virtual {\it traverse} das subclasses de {\it Node}. Alguns grafos de cena, como o Performer~\cite{performer2003}, somente permitem o percurso de cima para baixo ou vice-versa. Uma das vantagens do OSG é facilitar a redefinição do percurso que, apesar de não ser necessária para o algoritmo de célula/portal, facilita a sua implementação.

Outra ferramenta utilizada neste trabalho foi o VR~Juggler. Em particular, o VR~Juggler corresponde a uma biblioteca de realidade virtual, de código aberto, multi-plataforma e independente de dispositivo~\cite{bier00vrjuggler}. Ela fornece uma abstração dos dispositivos de entrada e saída. Junto a ela, qualquer biblioteca de grafo de cena (OpenGL Performer, OpenSceneGraph, OpenSG) pode ser usada para renderizar a cena.

O desenvolvedor não precisa se preocupar com o dispositivo de entrada que o usuário irá utilizar para interagir com a aplicação, ou como ele irá visualizá-la. A escolha dos dispositivos é feita através de arquivos de configuração. Baseado nesses arquivos, a biblioteca carrega os {\it drivers} adequados. A grande vantagem dos arquivos de configuração é permitir que diferentes dispositivos sejam combinados de várias maneiras sem necessidade de recompilar a aplicação. Por exemplo, o usuário pode configurar a aplicação para rodar com um joystick em uma CAVE ou, apenas mudando alguns parâmetros do arquivo, utilizar um mouse 3-D imerso em um capacete de realidade virtual.

A biblioteca VR~Juggler foi escolhida devido a sua facilidade de extensão, dado que a mesma fornece seu código fonte. Durante o nosso trabalho, a biblioteca foi estendida para suportar alguns dispositivos extras, como o projetor de imagem estéreo por coluna da VRex~\cite{vrex}, o mouse 3-D SpaceBall 4000 FLX~\cite{mouse3d} da Logitech, o sensor de movimento InterTrax$^{2}$ da Intersense~\cite{intersense} e dois joysticks padrão Microsoft Windows~\texttrademark.

A fim de permitir a visualização estéreo por coluna, um pedaço do núcleo do VR~Juggler foi alterado. Este tipo de estéreo é feito renderizando a imagem do olho esquerdo nas colunas ímpares da tela e a do olho direito nas colunas pares. A sua implementação utiliza os recursos de {\it stencil buffer} do OpenGL para alternar a renderização da imagem entre as colunas pares e ímpares. O projetor VRex reduz a resolução horizontal da imagem e se encarrega de alternar os quadros entre os olhos esquerdo e direito. Durante a renderização, o VR~Juggler verifica o modo de visualização (olho esquerdo, olho direito, estéreo {\it quad-buffer} ou estéreo por coluna) e chama a função de desenho da aplicação. 

Os {\it drivers} para os dispositivos de entrada citados foram criados através da interface de extensão do VR~Juggler e integrados à biblioteca. A interface de extensão define uma série de métodos que devem ser implementados pelos {\it drivers} facilitando bastante o trabalho do desenvolvedor. 

Os dispositivos de entrada podem ser digitais ou posicionais. Os digitais retornam verdadeiro ou falso caso um evento digital tenha ocorrido. Um exemplo de evento digital é o botão do joystick. Os dispositivos posicionais retornam uma matriz que representa a posição e a orientação do observador no mundo. Esses dados são utilizados pela classe que implementa a aplicação.

\section{Portais}

Os modelos arquitetônicos são compostos, de maneira geral, por salas, paredes, portas e janelas. Analisando a figura~\ref{fig:portal}, percebe-se que muitos objetos da cena estão ocultos pelas paredes, ou seja, somente os objetos vistos através das portas deveriam ser enviados para a placa gráfica.

\begin{figure}[htb]
  \begin{center}
     \includegraphics{images/portal.pdf}
  \end{center}
  \caption{Modelo célula/portal: somentes os retângulos preenchidos são enviados para a placa gráfica.}
  \label{fig:portal}
\end{figure}

Ao dividir o modelo em células (salas) e portais (portas e janelas), é possível determinar, em cada quadro, quais os objetos visíveis ao observador. Como cada célula conecta-se a outra através de um portal, o conjunto potencialmente visível é aquele composto pela célula inicial, onde encontra-se o observador, e pelas células adjacentes, conectadas por um portal.

Luebke e Georges~\cite{luebke95portal} criaram um solução dinâmica que executa em tempo linear no número de células, para determinar quais estão visíveis em uma cena. Seu algoritmo é integrável a sistemas de grafos de cena existentes, como OpenGL Performer ou OpenSceneGraph. O único pré-processamento necessário é para a construção da estrutura de dados de cada célula (geralmente feito durante a leitura do arquivo do modelo).

Existem diversos motores de jogos que fazem uso de portais, porém são restritos a modelos criados em ferramentas desenvolvidas especificamente para eles. A maioria desses motores não possui suporte a dispositivos de realidade virtual, como sensores de movimento, multi-projeção ou visão estereoscópica. Um dos objetivos desse trabalho é a incorporação do algoritmo de portais de Luebke ao grafo de cena da biblioteca OpenSceneGraph, que é capaz de ser integrada ao VR~Juggler. 

\subsection{Integração com o OpenSceneGraph}

Como foi mencionado anteriormente, o OpenSceneGraph percorre o grafo de cena e durante a etapa de CULL, descarta os objetos fora do campo de visão. A fim de estender esse processo de descarte, foram criadas três novas classes de objetos dentro do OpenSceneGraph: {\em Localizador}, {\em Célula} e {\em Portal}. A figura~\ref{fig:modelo} mostra a organização dessas classes.

\begin{figure}[htb]
  \begin{center}
     \includegraphics{images/modelo.pdf}
  \end{center}
  \caption{Organização das classes {\em Localizador}, {\em Célula} e {\em Portal} no OSG.}
  \label{fig:modelo}
\end{figure}

A classe {\em Localizador} é responsável pela inserção de células e portais no grafo de cena. Ela sobrecarrega o método {\it traverse} de {\it Group}. Nesse método, a classe localiza a célula onde se encontra o observador utilizando o método {\it localizaCélula}. Se o observador estiver dentro de alguma célula, o visitador continua seu percurso a partir dela, senão ele deve visitar todas as células da cena, como se faria em uma cena tradicional, sem portais. 

A classe {\em Célula} também herda de {\it Group} e sobrecarrega seu método {\it traverse}. Quando um visitador passa por uma célula, seus objetos são renderizados e o visitador continua seu percurso pelas célula adjacentes através da sua lista de portais. O método {\it contém} de célula é um método abstrato chamado pela classe {\em Localizador} para teste de pertinência. Ele é implementado nas suas subclasses {\em CélulaAlinhada} e {\em CélulaConvexa}. Na {\em CélulaAlinhada}, o método faz um teste de pertinência entre a posição do obsevador e a caixa alinhada com os eixos que define o volume da célula. Esse teste é muito rápido e pouco influencia no desempenho da etapa de CULL. Porém ele só pode ser aplicado se a célula for definida por caixas alinhadas com os eixos principais. Caso o limite da célula não seja alinhado com os eixos, a classe {\em CélulaConvexa} deve ser utilizada. Essas células são limitadas por planos que definem um volume convexo. A classe ainda contém um atributo que é a caixa alinhada que envolve a célula (figura~\ref{fig:convexo}). Essa caixa alinhada permite que seja feito um teste inicial para detectar a possibilidade do observador não estar dentro do volume convexo. Se ele estiver fora dessa caixa envolvente, logo ele estará fora da célula. Se ele estiver dentro da caixa envolvente, devem ser feitos testes com todos os planos para saber se o observador está no interior do volume convexo da célula.

\begin{figure}[htb]
  \begin{center}
     \includegraphics{images/convexo.pdf}
  \end{center}
  \caption{Visão plana das células: (i) os limites são alinhados com os eixos; (ii) os planos formam um volume convexo.}
  \label{fig:convexo}
\end{figure}

Quando o visitador atravessa alguma célula, ela deve determinar por quais portais o visitador deve continuar. Para isso, o método {\it traverse} da classe {\em Célula} executa os seguintes passsos:

\begin{enumerate}
	\item{Caso a célula $C$ não tenha sido visitada anteriormente, marcá-la como visitada}
	\label{item:mark}
	\item{Renderizar os objetos de $C$ usando descarte por campo de visão}
	\item{Para cada portal $P$ de $C$ dentro do campo de visão, faça}
	\begin{enumerate}
		\item{Se $P$ estiver de frente para o observador, faça}
		\begin{enumerate}
			\item{Encontrar a interseção $I$ do campo de visão com $P$}
			\item{Percorrer a célula adjacente a $P$ usando $I$ como novo campo de visão}
			\item{Recursivamente, voltar ao passo~\ref{item:mark}}
		\end{enumerate}
	\end{enumerate}
\end{enumerate}

A interseção do portal com o campo de visão é calculada da seguinte maneira: o portal é projetado na tela e o retângulo envolvente dessa projeção é calculado. A interseção é feita entre esse retângulo e a projeção do campo de visão atual, sendo o campo de visão inicial a própria tela. Esse procedimento faz com que o tamanho do campo de visão calculado seja um pouco maior do que o real, porém, isso não é problema, pois o que se deseja é apenas uma estimativa aproximada dos objetos visíveis.

A figura~\ref{fig:organizacao} mostra como os objetos das classes {\em Localizador}, {\em Célula} e {\em Portal} são inseridos dentro de um grafo de cena. O cenário externo é renderizado sem portais, enquanto o restante da cena, que está abaixo de Localizador, utilizará os recursos de portais.

\begin{figure}[htb]
  \begin{center}
     \includegraphics{images/organizacao.pdf}
  \end{center}
  \caption{Objetos das classes {\em Localizador}, {\em Célula} e {\em Portal}.}
  \label{fig:organizacao}
\end{figure}

\subsection{Exportação do modelo com portais}

Os modelos arquitetônicos criados para esse trabalho foram feitos no 3D Studio Max 5.1. As definições de células e portais ficam codificadas no nome dos objetos criados no programa de edição, logo o projetista terá que seguir algumas convenções para definir as células e os portais. Os objetos contidos nas células devem estar ligados a elas como filhos. Essa codificação, usando apenas nomes e relações hierárquicas, permite que modelos com portais sejam lidos de outros formatos além dos exportados pelo 3D Studio.

Quando o modelo é lido pela aplicação, as informações contidas no nome dos objetos são decodificadas e as células e os portais são criados. Para isso, um visitador percorre todo o grafo de cena extraindo essa informação e retornando, ao fim, um objeto {\em Localizador}. 

Uma próxima etapa do trabalho é o cálculo automático das células e portais a partir das informações contidas no modelo. A partir da estrutura de uma casa, por exemplo, será possível detectar as paredes, portas e janelas automaticamente e, com essa informação, montar a estrutura de dados para o algoritmo de célula/portal.

\section{Resultados}

O algoritmo de portais foi implementado em C++ utilizando a versão 0.9.3 do OpenSceneGraph. Os testes foram feitos com as seguintes configurações: resolução de tela de 1280x1024, amostragem de textura bilinear, sem filtragem anisotrópica, sem recursos de {\it anti-aliasing}, sincronismo vertical desabilitado e uma fonte de luz. O computador utilizado foi um Pentium 4, 2.53 GHz, com 3GB de memória equipado com uma placa de vídeo NVIDIA QuadroFX 1000 com 128MB.

O modelo utlizado para teste foi um apartamento com cerca de 1 milhão de faces. O apartamento foi dividido em 7 células, uma para cada cômodo mais a célula externa. Foram utilizados 16 portais, sendo uma média de 2,28 portais por célula.

%Não foram usadas luzes do OpenGL na cena, a iluminação foi toda pré-calculada e armazenada em mapas de iluminação. Os mapas de iluminação foram combinados com as texturas em tempo real usando recursos de multi-textura.

O desempenho de visualização foi medido em quadros por segundo (figura~\ref{fig:resultados}ii) em um percurso pré-definido (figura~\ref{fig:resultados}i). A tabela~\ref{tab:result} apresenta em detalhes os valores para os pontos destacados do percurso.

\begin{figure}[p]
  \begin{center}
     \includegraphics{images/resultados.pdf}
  \end{center}
  \caption{(i) Pontos principais do percurso e o (ii) Desempenho em quadros por segundo.}
  \label{fig:resultados}
\end{figure}

\begin{table*}[htb]
	\tcaption{Resultados obtidos para os valores dos pontos destacados no percurso.}
	\label{tab:result}
\begin{center}
	\begin{tabular}{ | c | r | r || c | r | r | }
	\hline
	Ponto & QPS sem portal & QPS com portal & Ponto & QPS sem portal & QPS com portal \\ 
	\hline
	1 & 27,56 & 44.33 & 6 & 125,98 & 162,40\\
	\hline
	2 & 18,15 & 36,42 & 7 & 55,12 & 59,11\\
	\hline
	3 & 60,10 & 158,62 & 8 & 246,31 & 250,25\\
	\hline
	4 & 48,23 & 66,93 & 9 & 24,83 & 106,30\\
	\hline
	5 & 41,71 & 122,05 &  &  & \\
	\hline
	\end{tabular}
\end{center}
\end{table*}

No primeiro ponto destacado, o observador está voltado para a sala. No seu campo de visão, existe apenas um portal que conecta a sala a varanda, dessa forma o desempenho utilizando portal é bem maior. A sala possui vários objetos complexos e a varanda possui um vaso de planta bastante detalhado. Isso fez com que o desempenho, mesmo com portal, não passasse de 45 quadros por segundo (qps).

No segundo ponto, o observador acabou de retornar e, posicionado na varanda, olha para o interior do apartamento. Nesse ponto, temos o portal que liga a varanda à sala e o que liga a sala ao corredor. O portal do corredor leva ao quarto superior a direita. O desempenho é semelhante ao caso anterior devido aos objetos complexos da sala. Sem a utilização do portal, quase todo o interior da cozinha e do quarto é renderizado sem necessidade, reduzindo à metade o desempenho.

No terceiro ponto, o observador está no corredor voltado para os dois quartos na parte inferior da planta. Como o algoritmo reduz o campo de visão, a cama do quarto à esquerda não é renderizada. Por ser bastante complexa, ela influencia substancialmente no desempenho, saltando de 60 qps para 160 qps com o uso de portais.

No ponto quatro, o observador está no quarto mais à direita, ligeiramente voltado para a parede. O algoritmo de portais evita que objetos do quarto ao lado sejam renderizados. No quinto ponto, o observador está no corredor, voltado para o quarto de cima. Com o algoritmo de portais, as camas não são renderizadas e, pelo mesmo motivo do terceiro ponto, o desempenho passa de 40 qps para 120 qps. 

No sexto ponto, após fazer o retorno no quarto de cima, o observador vira-se para a porta. Sem o algoritmo de portais, quase toda a sala foi renderizada, por isso o desempenho de 125 qps contra os 160 qps com o uso de portais. 

Nos sétimo e oitavo pontos observa-se pouco ganho com a utilização de portais. O mesmo se deve ao fato do observador estar voltado para o interior da cozinha. Na direção de visualização não há nenhum portal que reduza o número de objetos da cena.

No nono ponto, o algoritmo de portais evita a renderização do conteúdo da sala, por isso o ganho de desempenho foi substancial, saltando de 25 qps para 106 qps.

Através dos resultados apresentados, comprovamos que houve ganho de desempenho com o algoritmo de portais para o modelo utilizado. Observamos que em alguns pontos, o desempenho com e sem portais foram equivalentes. Esse fato ocorre por dois motivos: objetos muito complexos localizados em uma única célula ou células que foram mal divididas.

As camas, as almofadas da sala, as frutas da cozinha e os vasos de planta das varandas eram objetos muito detalhados que prejudicavam o desempenho da cena, mesmo com portais. A sala e a cozinha poderiam ser subdivididas para formar células menores, cujos portais diminuiriam ainda mais o volume de visão do observador.

O processamento extra necessário para escolha dos portais e células a serem percorridos pouco influenciou no desempenho total da aplicação. Podemos observar esse fato, notando que o desempenho sem portais não ultrapassa, em nenhum momento, o desempenho com portais.

A figura~\ref{fig:apto} mostra a visão da sala. Vale ressaltar que o modelo testado é relativamente pequeno. Ganhos muito mais expressivos poderiam ser obtidos com um modelo mais complexo.

\begin{figure}[htb]
  \begin{center}
     \includegraphics{images/sala2.pdf}
  \end{center}
  \caption{Visualização da sala do modelo do apartamento usado nos testes.}
  \label{fig:apto}
\end{figure}

\section{Conclusão}

Este trabalho apresentou uma implementação do algoritmo de portais~\cite{luebke95portal} no OpenSceneGraph como ferramenta para navegação em ambientes virtuais arquitetônicos. 

Como o OSG é uma biblioteca de código aberto, sendo utilizada por muitas ferramentas de RV, como o VR~Juggler, a implementação deste trabalho é mais abrangente do que as de motores de jogos 3D. Essa característica permite que modelos sejam criados em ferramentas comerciais, como o 3DStudio Max, e visualizados de forma eficiente em tempo real. Além disso, a facilidade de extensão do OSG contribuiu para o rápido desenvolvimento do trabalho e sua integração com o VR~Juggler.

O VR~Juggler atendeu diversos requisitos do projeto, como a simplicidade da interface e o desempenho. Mesmo com essas características, a equipe de desenvolvimento encontrou alguns problemas, dentre os quais, a dificuldade de implementação de algoritmos de detecção de colisão e uma comunicação limitada entre a aplicação e os dispositivos de entrada. Algumas informações de configuração dos dispositivos de entrada eram necessárias para a aplicação, mas inacessíveis pela {\it interface} do VR~Juggler. Por esta razão, pretende-se, como trabalho futuro, resolver este problema através da substituição da ferramenta de abstração de dispositivos de realidade virtual.

\section*{Agradecimentos}

A pesquisa em Realidade Virtual do Tecgraf/PUC-Rio é apoiada primordialmente pelo projeto AmbVirt patrocinado pela FINEP/PETROBRAS. Agradecemos a Sergio Klein, Sérgio Gattáss e a GAFISA pelo modelo do apartamento cedido para esse trabalho.

\begin{thebibliography}{500}

{\small

\bibitem{airey90towards} J. Airey, J. Rohlf, F. Brooks, {\em Towards image realism with interactive update rates in complex virtual building environments}, Symposium on Interactive 3D Graphics, 24(2):41-50, March 1990.

\bibitem{teller91visibility} S. Teller, C. Séquin, {\em Visibility preprocessing for
interactive walkthroughs}, Computer Graphics (Proceedings of SIGGRAPH 91), 25(4):61-69, 1991.

\bibitem{luebke95portal} D. Luebke, C. Georges, {\em Portals and mirrors: Simple, fast evaluation of potentially visible sets}, ACM Interactive 3D Graphics Conference, Monterey, CA, 1995.

\bibitem{osg} R. Osfield, D. Burns, {\em OpenSceneGraph}, http://www.openscenegraph.org.

\bibitem{opengl2003} {\em OpenGL - High Performance 2D/3D Graphics}, http://www.opengl.org

\bibitem{bier00vrjuggler} A. Bierbaum, {\em VR~Juggler: A Virtual Platform for Virtual Reality Application Development}, Master Thesis, Iowa State University, 2000.

\bibitem{bier00vrjuggler2} A. Bierbaum, C. Just, P. Hartling, C. Cruz-Neira, {\em Flexible Application Design Using VR~Juggler}, SIGGRAPH, 2000.

\bibitem{vrjuggler2003} {\em VR Juggler Homepage}, http://www.vrjuggler.org

\bibitem{vess2003} {\em Virtual Environment Software Sandbox}, http://vess.ist.ucf.edu

\bibitem{cmlabs2003} {\em CMLabs Simulations}, http://www.cm-labs.com

\bibitem{cal3d2003} {\em Cal3d - Character Animation Library}, http://cal3d.sourceforge.net

\bibitem{performer2003} {\em SGI - OpenGL Performer}, http://www.sgi.com/software/performer

\bibitem{hudson97frusta} T. Hudson, D. Manocha, J. Cohen, M. Lin, K. Hoff, H. Zhang, {\em Accelerated Occlusion Culling using Shadow Frusta}, Symposium on Computational Geometry, pp. 1-10, 1997

\bibitem{gammadesign} E. Gamma, R. Helm, R. Johnson, J. Vlissides, {\em Design Patterns - elements of reusable object-oriented software}, Addison-Wesle Longman, Inc., 1995.

\bibitem{vrex} VRex, Inc., {\em 3D Stereoscopic imaging products and services}, http://www.vrex.com.

\bibitem{mouse3d} 3Dconnexion, {\em A Logitech Company}, http://www.3dconnexion.com.

\bibitem{intersense} InterSense, Inc., {\em The New Standard in Motion Tracking} http://www.intersense.com.

}

\end{thebibliography}

\end{document}
