

\documentclass[10pt, conference, compsocconf]{IEEEtran}

\usepackage[latin1]{inputenc}
\usepackage{color}
\usepackage{listings}
\usepackage[brazil]{babel}
\usepackage{cite}
\usepackage{fancyvrb}
\usepackage[pdftex]{graphicx}
\usepackage{amssymb}
\usepackage{amstext}
\usepackage[cmex10]{amsmath}
\interdisplaylinepenalty=2500
\usepackage{algorithmic}
\usepackage{array}
\usepackage[tight,footnotesize]{subfigure}
\usepackage{url}

% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}
\renewcommand\lstlistingname{Listagem}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{LVRL: Um Framework para RV}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations

\author{\IEEEauthorblockN{Authors Name/s per 1st Affiliation (Author)}
\IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\
line 2: name of organization, acronyms acceptable\\
line 3: City, Country\\
line 4: Email: name@xyz.com}
\and
\IEEEauthorblockN{Authors Name/s per 2nd Affiliation (Author)}
\IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\
line 2: name of organization, acronyms acceptable\\
line 3: City, Country\\
line 4: Email: name@xyz.com}
}

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
%Homer Simpson\IEEEauthorrefmark{2},
%James Kirk\IEEEauthorrefmark{3}, 
%Montgomery Scott\IEEEauthorrefmark{3} and
%Eldon Tyrell\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: homer@thesimpsons.com}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}


% make the title area
\maketitle

\begin{abstract}
Com o barateamento dos hardwares para ambientes imersivos, o interesse por 
aplicações de Realidade Virtual (RV) vem aumentando consideravelmente. Entretanto
os frameworks atualmente disponíveis exigem que as aplicações do usuário sejam desenvolvidas especificamente para elas. Isso faz com que o custo de se portar uma aplicação legada para ambientes RV seja alto, na maioria das vezes até proibitivo. Este artigo propõe um novo framework, o LVRL (\emph{Lightweight
Virtual Reality Libraries}), que permite a criação ou conversão de aplicações existentes 
para RV sem alteração na estrutura da aplicação. O principal objetivo do LVRL é fornecer uma interface de programação (API, aplication program interface) minimalista e não intrusiva permitindo o desenvolvimento de aplicações RV por desenvolvedores sem conhecimento específico em RV. 
Este artigo descreve a arquitetura do LVRL,suas funcionalidades, forma de usar e os benefícios obtidos pelas aplicações que o utilizam.
\end{abstract}

\begin{IEEEkeywords}
component; formatting; style; styling;
\end{IEEEkeywords}


 \ifCLASSOPTIONpeerreview
 \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
 \fi

\IEEEpeerreviewmaketitle

\section{Introdução}
Nos ultimos anos a RV vem se popularizando devido a redução dos custos de hardware e consequentemente dos sistemas imersivos. No passado tais ambientes eram extremamente caros, chegando a custar alguns milhões de dólares no caso de CAVEs \cite{Cruz-Neira:1992:CAV:129888.129892}.
Com o advento das televisões 3D de alta definicao a preços acessíveis, 
ambientes imersivos como a NexCAVE
\cite{springerlink:10.2478/s13531-010-0002-5}.
estão ao alcance da maioria das empresas de engenharia, design, jogos e outras
que trabalham com 3D no dia a dia. A NexCave utiliza de 9 a 21 televisões
afixadas num suporte com a forma de um poliedro de "n" lados inscrito numa a seção de esfera suficiente para cobrir ao maximo o campo de visão do usuário. 

Apesar da redução dos custos do hw a produção de sw para ambientes imersivos ainda é uma 
atividade custosa. Isto se deve ao pequeno numero de ferramentas de baixo custo para a produção de tais sistemas, limitando dessa forma o numero de aplicações que estejam aptas a executar nesses ambientes. Um outro aspecto que dificulta a criação de novas aplicações é a complexidade para
transformar uma aplicação desktop funcional em uma aplicação RV.
Além das peculiaridades desse tipo de ambiente, pesa ainda o fato que
praticamente todos os SDKs para RV modernos estarem amarrados a algum tipo de
renderizador, como é o caso do VrJuggler\cite{Bierbaum:2001:VJV:580521.835847},
BlenderCave\cite{GBEO11}, Eon Studio\cite{Wang:2010:RVR:1955599.1955819}, Avango
NG\cite{37865698}, 3DVIA Virtools\cite{WEB:Virtools} e
INVRS\cite{anthes09space}. Por consequência as aplicações 
imersivas precisão ser inteiramente refeitas para se adequar a uma dessas
plataformas.

Hoje em dia já existem muitas aplicações 3D baseadas em renderizadores
específicos como os visualizadores de modelos massivos
\cite{DBLP:journals/cga/RaposoSSWCG09}, de modelos de elementos finitos
\cite{Zhou:2004:PRS:1032664.1034476}, de nuvens de pontos
\cite{Rusinkiewicz:2000:QMP:344779.344940}, de dados sísmicos \cite{silva20033d}
e de dados visuais resultantes de simuladores científicos em geral. O custo de
reescrevê-los dentro de plataformas especificas seria demasiadamente alto e as
vezes impossível, dado o nível de especificidade do renderizador ou a plataforma
ser fechada como no caso do EON Studio e do Virtools.

No entanto isso não é necessário pois os componentes necessários para a criação de uma aplicação RV podem ser construídos de forma que possam ser utilizados pela aplicação já existente. Uma aplicação
imersiva se diferencia de uma aplicação desktop pelo fato de ter de suportar
múltiplas saídas de vídeo de pontos de vista diferentes. Ainda, o usuário não
pode usar mouse e teclado por estar em pé em frente ao ambiente imersivo, como
pode ser visto na figura \ref{fig:lshape}. 

Nesse trabalho propomos um framework não intrusivo que possibilita a conversão 
de aplicações desktop em aplicações imersivas por um desenvolver não especializado em RV. 
O framework permite que o desenvolvimento da aplicação seja feito 
exclusivamente em desktop e garante que ao mudar para o modo RV os dados serão
visualizados considerando o formato do ambiente imersivo e a navegação terá as a
mesmas funcionalidades adaptadas para dispositivos RV.

Na seção \ref{sec:relacionados} apresentamos as ferramentas existentes hoje e
as razões que dificultam a conversão dos software 3D desktop para
ambientes imersivos. Em seguida, na seção \ref{sec:Framework} explicamos cada
um dos componentes que compõem nosso framework e mostramos como cada um deixa
transparente para o usuário o fato da aplicação estar sendo executada em
ambientes desktop ou imersivos. Na seção \ref{sec:disc} discutimos as
características e contribuições que o nosso framework propõe. Por fim, algumas
conclusões e trabalhos futuros swão apresentados na seção \ref{sec:concl}.

\section{Trabalhos Relacionados}
\label{sec:relacionados}
Os frameworks para RV existentes tentam assumir algumas funções. São elas: 
renderização de múltiplos pontos de vista, captura de eventos de dispositivos de interação de RV
e distribuição da renderização em diferentes maquinas da rede. Como já citado, ao mesmo tempo em que tentam resolver esses problemas, também requerem, em contrapartida, que o desenvolvimento seja 
orientado para suas plataformas específicas.

BlenderCave\cite{GBEO11}, Virtools\cite{WEB:Virtools} e EON
Studio\cite{Wang:2010:RVR:1955599.1955819} são ferramentas de autoria para
desenvolvimento de aplicações 3D interativas. Elas tem um sistema de
renderização interno o qual o desenvolvedor da aplicação não tem acesso. Os
dados são modelados em ferramentas de terceiros como o 3DStudio Max e importados
para dentro da ferramenta. Nesse tipo de software não é possível fazer uma
renderização específica, como por exemplo técnicas de renderização baseadas em
pontos. Quanto a interação, esses frameworks são capazes de ler os dispositivos
de RV, mas o desenvolvedor precisa desenvolver o suporte e o mecanismo de interação
necessário para o dispositivo que deseja suportar.

Frameworks programáticos de mais baixo nível, como o 
VrJuggler\cite{Bierbaum:2001:VJV:580521.835847}, Avango NG\cite{37865698} e
INVRS\cite{anthes09space} em geral são baseadas em grafos de cena desenvolvidos por terceiros
para fazer a renderização. Grafos de cena bastante comuns são o
OpenSceneGraph\cite{WEB:OSG}, OpenSG\cite{WEB:openSG} e SGI OpenGL
Performer\cite{WEB:Performer}. Caso a aplicação a ser convertida já use um
desses grafos de cena, provavelmente a parte do render será mais facilmente
convertida para ambientes imersivos usando esses frameworks, uma vez que eles
já resolvem, ou podem ser facilmente adaptados para resolver, questões como a renderização de múltiplos pontos de vista e a distribuição do rendering por diferentes maquinas da rede. No entanto, em geral, é necessário se manter duas versões do software, uma desktop e outra para ambientes imersivos. Isso acontece pois essas componentes
precisam controlar o laço principal de controle da aplicação para ser possível
fazer o desenho sincronizado em todas as telas. Já com relação a interação 3D
elas tem o mesmo problema das ferramentas de autoria, isto é, elas passam o dado cru
dos dispositivos e o desenvolvedor é o responsável por tratar cada tipo de
dispositivo para o qual queira usar na aplicação.

A Cavelib\cite{Cruz-Neira:1995} foi a primeira componente para ambientes
imersivos e foi criada junto com a primeira CAVE. Ela até hoje é mantida e
vendida. A única diferença dela para componentes programáticas citadas a cima é
que ela não está amarrada a um grafo de cena. Sua estratégia é assumir que toda a
informação dinâmica de desenho precisa estar numa área de memória protegida.
Essa memória é compartilhada e pode ser distribuída entre os computadores. No
entanto, mesmo não amarrada a um grafo de cena específico, ela ainda exige que o
desenvolvimento seja orientado a ela. 
Adicionalmente, ela também precisa que os
manipuladores de câmera sejam feitos da mesma forma que as outras componentes,
só que usando uma camada de entrada de dispositivos que tem uma interface
parecida com o VRPN\cite{Taylor:2001:VDN:505008.505019}. Essa amarração com
grafos de cena ou estratégias de uso de memória em todas as soluções citadas
está intimamente ligada com a distribuição da renderização por várias máquinas.
O componente gestor dessa distribuição precisa saber o que distribuir e assim,
poder sincronizar o desenho nas diferentes maquinas. No entanto, assim como fornece uma
importante funcionalidade, ele adiciona uma restrição muito forte ao framework. Ao mesmo tempo, existem outras soluções de renderização distribuída
genéricas\cite{Humphreys:1999:DGS:319351.319377,
Eilemann:2009:ESP:1515609.1515684,Gropp:1994:UMP:207387}, que não tem o cálculo
dos múltiplos pontos de vista nativo, mas fornecem a mesma funcionalidade se a
aplicação for capaz de calcular internamente os múltiplos pontos de vista. 

O framework proposto fornece toda a parte de manipulação de câmera e os cálculos dos
múltiplos pontos de vista. Supomos que os métodos de interação de câmera
devem convergir a formatos já sedimentados e testados. Imbutindo-se esses componentes 
também em uma componente, acreditamos que pode-se reduzir o esforço da grande
maioria dos desenvolvedores na criação de aplicações que são ao mesmo tempo
desktop e imersivas. Sendo assim, ao invés de eventos de dispositivos de
entrada, o framework já fornece uma posição e orientação 3d.

\begin{figure}[!t]
  \begin{center}
		\includegraphics[width=0.47\textwidth]{figures/lshape.pdf}
  \end{center}
  \caption{Sistema Imersivo em formato de L. fonte Fraunhofer IAIS}
  \label{fig:lshape}
\end{figure}


\section{Framework}
\label{sec:Framework}
O framework provê ferramentas para o programador leigo em algoritmos 
de RV converter um programa desktop em um programa multimodal que funcione em
ambientes desktop e RV apenas trocando a configuração do ambiente em tempo de
execução. Para isso foram criados componentes não intrusivas que realizam as
seguintes tarefas: auxiliar o sistema de renderização já existente a criar as
câmeras virtuais para os múltiplos pontos de vista; fornecer manipuladores de
câmera já projetados para funcionar nos dois tipos de ambiente de forma idêntica
apenas mudando o tipo de dispositivo utilizado; fornecer uma interface de
\emph{Wand}, como uma generalização do mouse para interação 3D. Abaixo segue
a descrição da arquitetura geral do framework e cada um dos componentes que o
integram.


\subsection{Arquitetura}

O framework é formado por 7 componentes. O diagrama de dependência pode ser visto na figura \ref{fig:arquitetura}.
 Três dessas, são componentes
matemáticas sem dependência nenhuma, que inclusive podem ser usadas em outros
frameworks de RV. São eles o \emph{VrFrustum}, \emph{VrManipulators} e
\emph{VrTransitions}. As outras quatro são de mais alto nível e fazem todo
o tratamento de eventos e interação para câmera. Eles também podem ser usadas
com outros frameworks, mas é necessario usar o componente de leitura de
eventos de dispositivos, \emph{VrInput}, ao ínves do fornecido pelos outros frameworks.

\begin{figure}[!t]
  \begin{center}
		\includegraphics[width=0.47\textwidth]{figures/arquitetura.pdf}
  \end{center}
  \caption{Diagrama de componentes com as dependências entre as componentes}
  \label{fig:arquiterura}
\end{figure}


O \emph{VrFrustum} é responsável por gerar as câmeras dos diferentes pontos de
vistas correspondentes a cada tela do sistema imersivo dada a configuração
física das telas e a posição da cabeça do usuário. No modo desktop ela gera uma
única câmera correspondente ao monitor. 

O \emph{VrManipulator} contêm um conjunto de manipuladores de câmera que foram
projetados para funcionar com dados de entrada de mouse e teclado da mesma forma
que com dados de entrada de dispositivos de RV. Esses manipuladores também são
projetados para funcionar tanto em ambientes imersivos quanto em desktop. 

O \emph{VrTransition} é um componente que faz a interpolação entre duas poses
de câmera de forma suave para evitar desorientação dentro do ambiente imersivo e
em desktop.

Os outros quatro componentes são ligados a captura e interpretação dos 
dispositivos de entrada. Elas são \emph{VrInput}, \emph{VrInteraction}, 
\emph{VrHeadTracking} e \emph{VrWand}.

O componente \emph{VrInput} é responsável pelo gerenciamento dos dispositivos
de entrada, criando uma camada de abstração para os outros componentes. Todo o 
gerenciamento dos dispositivos, controle do ciclo de vida dos drivers proprietários e 
demais dependencias são controlados pelo \emph{VrInput}. O \emph{VrHeadTracking} 
monitora os eventos do sensor que lê
a posição da cabeça do usuário e alimenta o \emph{VrFrunstum} que precisa
conhecer essa posição para calcular as múltiplas câmeras. A \emph{VrWand} 
informa a direção para onde o usuário esta apontando o dispositivo de entrada.
No modo RV os dispositivos geralmente fornecem a posição absoluta dentro do
ambiente imersivo, assim como a orientação do dispositivo. Usando a componente
\emph{VrFrunstum} para transformar a posição do dispositivo de entrada de
coordenadas do ambiente imersivo para coordenadas do mundo, a componente é capaz
de calcular um vetor direção e uma posição para o raio. Já no modo desktop o
processo é semelhante. No entanto o mouse só fornece uma posição 2D do cursor na
tela. Para transformar isso num raio calculamos o vetor que sai da posição da
câmera no mundo e passa por aquela posição no plano de projeção da câmera (o
plano near).

Por fim o componente \emph{VrInteraction} é responsável por interpretar os
eventos de entrada e transformá-los em operações de manipulação da câmera. Essa componente
fornece uma matriz de view que posiciona e orienta a câmera no mundo. Quando o
\emph{Vrinput} gera um evento de um dos dispositivos de entrada suportados pelo
\emph{VrIntecation}, esse interpreta o evento segundo um mapeamento e chama o
\emph{VrManipulator} para efetuar os cálculos matemáticos que atualizam a matriz
de view corrente. Outra responsabilidade do \emph{VrInteraction} é o
gerenciamento das transições. Quando o usuário muda de manipulador ativo o
\emph{VrInteraction} verifica se existe algum pulo da última pose do manipulador
que está sendo desativado para a posição inicial do manipulador que está sendo
ativado. A seguir são apresentados maiores detalhes de cada um desses componentes nas
próximas seções.

\subsection{VrInput}
\label{sec:VrInput}
O \emph{VrInput} é o módulo responsável pelo acesso de dispositivos de entrada
como mouse, teclado, joysticks e trackers. Nele, cada dispositivo é mapeado
para um \emph{leitor}, que faz o acesso direto ao dispositivo usando sua
api nativa. Atualmente, existe suporte para os seguintes dispositivos:

\begin{itemize}
 \item Teclado e mouse;
 \item Controle wii;
 \item Tablet Ipad;
 \item Celulares e tablets Android;
 \item Controle Flystick2; 
 \item Tracker BraTrack;
 \item SpaceBall;
 \item Joysticks (somente Windows);
 \item Kinect (somente Windows);
\end{itemize}

Além dos dispositivos listados também há leitores de acesso às interfaces de
entrada analógica, de botões e trackers presentes na componente 
VRPN\cite{Taylor:2001:VDN:505008.505019}. Dessa forma, é possível acessar também
dados para os dispositivos suportados por essa componente.

A definição de um \emph{leitor} consiste em implementar um único método, chamado
\emph{poll}. Nesse método, é acessado o estado do dispositivo e são criados
\emph{eventos}, os quais serão repassados para a aplicação através do
\emph{gerenciador de eventos}. 

Um \emph{evento} é uma mensagem que possui um identicador, informando seu tipo,
e pode ou não conter dados associados. Por exemplo, o identificador
\emph{wii\_btn\_left\_press} indica que a tecla esquerda do direcional do
controle wii foi apertada. Nesse caso, não há nenhum dado associado ao evento.
Já um evento de tracker contém um vetor e um quatérnio que indicam
respectivamente sua posição e orientação.

O uso do \emph{VrInput} é feito através da interface \emph{InputController}, que é
responsável por criar os leitores, além de permitir ativá-los ou desativá-los. Para garantir 
a estabilidade e o controle eficiente do ciclo de vida dos diversos leitores usados pela 
aplicação todo o gerenciamento fica a cargo do \emph{VrInput}, sendo portanto vedada
à aplicação instanciação direta de um leitor. 

A criação de um leitor é feita através do método \emph{createReader}. Como
parâmetros de entrada devem ser fornecidos um identicador para o leitor, seu
tipo e qual o canal de comunicação a ser usado. O identicador é uma
string que permite à aplicação ativar ou desativar o leitor depois que esse
últmo foi criado, assim como verificar seu status (se o mesmo se encontra ativo
ou não).

O canal de comunicação define de que forma o \emph{InputController} se
comunicará com o leitor. Atualmente, há dois tipos de canais de comunicação:
\emph{bypass} e \emph{ipc}. No primeiro o leitor é criado no mesmo processo da
aplicação e a comunicação se dá por meio de chamadas diretas aos métodos do
leitor. No segundo, o leitor é criado por um processo secundário e fica fora do
contexto de execução da aplicação. A comunicação entre o \emph{InputController}
e esse processo secundário se dá através de chamadas entre processos com uso de
memória compartilhada. O canal ipc tem a vantagem de isolar os dispositivos da
aplicação. Dessa forma, uma falha no acesso ao dispositivo não derruba a
aplicação principal, mas apenas o processo secundário do \emph{VrInput}. 


Só é permitida uma instância do \emph{VrInput} por aplicação. Isso impede que
haja acesso concorrente aos dispositivos entre diferentes instâncias que poderiam
ter sido criadas pela aplicação. Por esse motivo, antes de se chamar qualquer
método de \emph{InputController}, deve-se chamar o método \emph{initialize}. Ao
ser chamado, esse cria a instância do \emph{VrInput} e dispara o processo
secundário responsável por se comunicar com os leitores quando o canal de
comunicação ipc é usado.

Para receber os eventos gerados por um leitor, a aplicação deve implementar uma 
classe que extenda \emph{EventObserver} e nessa registrar os eventos que
deseja monitorar através do método \emph{listenEvent} da interface
\emph{EventManager}. A listagem \ref{cod:escutar}, apresenta um exemplo de
implementação de um \emph{EventObserver}. Nele, a aplicação recebe
notificações da ocorrência de 3 eventos, sendo 2 desses relacionados ao leitor
de identificador 'wii0' e 1 relacionado ao leitor 'fly0'.

{\scriptsize
  \begin{lstlisting}[captionpos=b,caption=Exemplo de observador de eventos
,frame=tlrb , language=C, label = cod:escutar]
Contrutor()
{
  listenEvent( "wii0", "wii_btn_left_press" );
  listenEvent( "wii0", "wii_btn_left_release" );
  listenEvent( "fly0", "flystick_btn_0_press" );
}

EventHandler( string id_leitor, id_evento )
{
  if( id_leitor == "wii0" )
    if( id_evento == "wii_btn_left_press" )
      AndeParaEsquerda(); // função da aplicação
    else
      Parar(); // função da aplicação
  else
      LigarRaio(); // função da aplicação
}
  \end{lstlisting}
}

O método \emph{EventHandler} deve ser implementado por todo
\emph{EventObserver}. Esse método é chamado pelo \emph{EventManager}
sempre que há ocorrência de um dos eventos que foram registrados através de
\emph{listenEvent}. Um \emph{EventObserver} recebe apenas os eventos para
os quais ele se registrou. No exemplo acima, quando o botão esquerdo do
controle wii identicado por 'wii0' é pressionado, a ação \emph{AndeParaEsquerda}
é executada. Quando o botão é solto, é realizada a ação \emph{Parar}. Da mesma
forma, quando o botão 0 do controle flystick 'fly0' é pressionado, a ação
\emph{LigarRaio} é disparada.

Uma vez criados os leitores e \emph{EventObservers}, deve-se executar o método
\emph{ProcessEvents} de \emph{InputController} sempre que um novo frame estiver
para ser desenhado. É nesse momento que o \emph{VrInput} chama os métodos
\emph{poll} de todos os leitores ativos e processa os eventos gerados, os
enviando para os \emph{EventObservers} registrados. Também nesse momento é
verificado se houve erros de desconexão de dispositivos ou queda do
processo secundário. No primeiro caso, é gerado um evento especial que indica
a desconexão do dispositivo, o qual pode ser usado pela aplicação para tratar
esse tipo de erro. No segundo caso, o \emph{VrInput} tenta reiniciar o processo
secundário e reativar os leitores. Esse processo é repetido por 3 vezes e caso não
tenha sucesso o \emph{VrInput} reporta o erro para a aplicação. Esse desacoplamento
impede que a aplicação tenha que ser reiniciada no caso de falha em algum
dispositivo.

\subsection{VrFrustum}
\label{sec:VrFrustum}
O \emph{VrFrustum} é responsavel por criar as múltiplas câmeras que são
necessárias para o ambiente imersivo a partir de uma câmera principal. 
Essa funcionalidade é comum nos frameworks de RV, no entanto o principal 
diferencial do \emph{LVRL} é que o componente \emph{VrFrustum} não precisa 
ter acesso a câmera principal, bastando conhecer a configuração que define 
a geometria do sistema de projeção e receber a pose da cabeça do usuário a cada quadro. 

No caso de um ambiente desktop com um monitor o cálculo fica restrito a uma
única tela. Porém, no caso de uma CAVE ou  NexCAVE, comumente composta por mais
de 3 telas, terão que ser calculados "N" pontos de vista correspondente as "N"
telas do sistema. No caso de um sistema com suporte a estereoscopia serão "2 x
N". Abaixo descrevemos como configurar e e usar o \emph{VrFrustum} de forma a
ser transparente a mudança do modo desktop para o modo RV.

O arquivo de configuração agrega os parâmetros que são inerentes ao ambiente
imersivo. Esse arquivo é comum a todas aplicações que usem o \emph{VrFrustum}
para um determinado ambiente imersivo. Na listagem \ref{configfile} é mostrado um
exemplo de um arquivo de configuração para um ambiente imersivo em formato L,
como na figura \ref{fig:lshape}. O exemplo funciona com projetores de estéreo
passivo lado a lado. Cada uma das duas telas é desenhada por uma maquina
diferente.

O arquivo é escrito no formato XML. O marcador \emph{ScreenSet} agrega o
conjunto de telas (\emph{screens}). Um tela pode ser um monitor, um projetor ou
dois projetores (no caso de projeção com estéreo passivo). Para cada tela é
informado a posição 3D dos 4 cantos (\emph{corners}) da tela. Essa informação é
suficiente para o cálculo do \emph{frustum}. 

O arquivo de configuração também contém informações sobre o mapeamento 
entre as diferentes saídas de vídeo dos projetores e as respectivas regiões (ou telas) do
sistema de projeção (mapeamento de viewports). A viewport do olho direito é opcional,
dado que se o sistema de projeção usar estéreo ativo ou não suportar
estereoscopia só é necessário uma viewport. No caso do sistema imersivo
funcionar distribuído, além da viewport, é necessario um identificador
(\emph{Machine}) que diz qual maquina é responsável por ela.

A última propriedade que uma tela pode ter é se ela é a \emph{referência} (no
caso do nosso exemplo é a primeira tela). Essa propriedade existe porque os
planos de clipping \emph{near} e \emph{far} só podem ser definidos quanto a uma
tela. As outras telas precisam ser calculadas em função da tela de referência
para que os planos de clipping se encaixem sem descontinuidades.

Outras informações importantes para a criação de uma cena 3D em ambientes imersivos
são o \emph{Pivot} e o \emph{OffsetTracking}. O \emph{Pivot} é uma posição 3D na cena 
e tem duas funcões. A primeira é ser usada como a posicão padrão da cabeça do 
usuário no caso em que o sistema não tenha rastreamento de cabeça. A segunda é ser a 
origem do sistema de coordenadas da matriz de modelview fornecida pela componente para o
posicionamento das câmeras no ambientes imersivo.
 
O \emph{OffsetTracking} é uma posiçao 3D que representa a origem do sistema de
coordenada do equipamento de rastreamento. Consideramos que todos sistemas de
coordenada tem a mesma orientação e que a descrisão dos cantos da cave estão na
mesma unidade fornecida pelo equipamento de rastreamento, em geral metros.

Na figura \ref{fig:caveL} é mostrada uma visualização simulada do que cada tela 
da cave exibe, no caso ela está sobre um navio plataforma de produção de
petróleo.

%FALTA VALORES REAIS.
%FALTA TRADUZIR O NOME DO LISTING

{
\begin{lstlisting}[captionpos=b,caption=Arquivo de configuração do
VrFrustum.,frame=tlrb ,language=xml,label=configfile,basicstyle=\scriptsize,float = ht]
<ScreenSet>
 <Screen reference="true">
  <LowerLeftCorner X="0" Y="-3" Z="0"/>
  <LowerRightCorner X="3" Y="-3" Z="0"/>
  <UpperRightCorner X="3" Y="0" Z="0"/>
  <UpperLeftCorner X="0" Y="0" Z="0"/>
  <ViewportLeftEye X="0.0" Y="0.0" W="0.5" H="1.0"/>
  <ViewportRightEye X="0.5" Y="0.0" W="0.5" H="1.0"/>
  <Machine IP="10.0.0.1">
 </Screen>
  <Screen >
  <LowerLeftCorner X="0" Y="-3" Z="3"/>
  <LowerRightCorner X="3" Y="-3" Z="3"/>
  <UpperRightCorner X="0" Y="-3" Z="0"/>
  <UpperLeftCorner X="3" Y="-3" Z="0"/>
  <ViewportLeftEye X="0.0" Y="0.0" W="0.5" H="1.0"/>
  <ViewportRightEye X="0.5" Y="0.0" W="0.5" H="1.0"/>
  <Machine IP="10.0.0.2">
 </Screen>
</ScreenSet>
<Pivot  X="1.5" Y="-1.2" Z="1.5">
<OffsetTracking X="1.5" Y="-0.5" Z="1.5">
\end{lstlisting}  
}

\begin{figure}[!t]
  \begin{center}
		\includegraphics[width=0.47\textwidth]{figures/cave_L.pdf}
  \end{center}
  \caption{Visualização do sistema imersivo do arquivo de exemplo.}
  \label{fig:caveL}
\end{figure}


A listagem \ref{apiFrustum} apresenta a simplicidade da interface de
programação dessa componente e como ela é transparente quanto aos ambientes
imersivos. Na função de desenho da aplicação principal basta pegar o número de
telas e fazer um laço. Em cada iteração obtem-se as matrizes da tela e
atritui-se essas nas matrizes correntes da engine de desenho usada antes de
chamar a função de renderização.



\begin{lstlisting}[captionpos=b,caption=Interface de programação do
VrFrustum,frame=tlrb,label=apiFrustum , language=C++,basicstyle=\scriptsize,float = ht ]{Name}

  //funções de configuração dependentes do ambiente RV
  void loadConfigFile( string filename );

  void setHeadPose( double[3] position
                       ,double[16] orientation );
  
//funções condiguração dependentes do conteudo desenhado
  void setNearPlane( double value );
  void setFarPlane( double value );
  void setScale( double value );
  void setInterEyeDistance( double value );
  void enableDesktopMode( double fov, double aspect );
  void disableDesktopMode();

  //funções para o desenho
  int getNumberOfScreens();

  void getScreenMatrixs( int screen_index, 
			 double* projection_esq,
			 double* modelview_esq,
			 double* viewport_esq,
			 double* projection_dir,
			 double* view_dir,
			 double* viewport_dir,
			 string* ip_machine );
\end{lstlisting}



\subsection{VrHeadTracking}

O \emph{VrHeadtracking} é uma componente cuja função é gerenciar os dados 
recebidos sobre o monitoramento da posição e orientação da cabeça de um usuário,
e repassar esses dados para o \emph{VrFrustum} realizar os cálculos dos
novos pontos de vista do usuário em relação a cada uma das telas que compõe o
sistema de visualização 3D. No modo de desktop, a posição do rastreamento de
cabeça não tem efeito nenhum.

Internamente, o \emph{VrHeadtracking} se conecta e recebe os dados do
rastreamento da posição e orientação da cabeça do usuário usando a componente
\emph{VrInput}. 
Com esses dados o \emph{VrHeadtracking} se conecta a uma instancia do
\emph{VrFrustrum} na qual já se encontram definidas um número de câmeras
virtuais correspondentes ao numero de telas do sistema de visualização 3D. 
A cada quadro o sistema verifica a posição e orientação da cabeça do usuário
dentro do sistema de visualização 3D, e as posições das câmeras virtuais são
recalculadas. 
Esses dados são repassados para o sistema de renderização da aplicação, permitindo
que cada tela do sistema imersivo tenha uma projeção do cenário virtual
corretamente alinhada em relação ao ponto de vista corrente do usuário.

\subsection{VrWand}

A componente \emph{VrWand} fornece um apontador virtual 3D. Este tipo de
recurso é usado em ambientes virtuais imersivos para que o usuário interaja com
os objetos do cenário virtual, realizando operações de seleção e manipulação de
objetos. É uma generalização do conceito de mouse para 3D. Esse apontador é
comumente chamado de \emph{raio} por ser um vetor no espaço 3D. No \emph{LVRL}, 
o componente \emph{VrInput} fornece os dados de movimentação e
direção obtidos dos dispositivos de rastreamento que ela suporta. Esses dados
são usados para controlar a posição e orientação do raio. 

O \emph{VrWand} armazena e processa os dados vindos do tracker e fornece ao final
um vetor posição e uma orientação já em coordenadas do sistema definido pelo
cenário virtual. Isso é possivel usando as matrizes do \emph{VrFrustrum} e do
\emph{VrInteraction} para transformar as coordendas do sistema do rastreador
para o do cenario virtual.
 
No modo desktop, o raio virtual sai da câmera e passa pela posição do mouse no
plano \emph{near}. Já no caso do modo RV a posição é definida pelo sistema de
rastreamento convertida para o sistema de coordenadas do cenário virtual,
preservando detalhes de escala entre as unidades do sistema de rastreamento
(metros) e a unidade de medida no cenário virtual. 

\subsection{VrManipulators}
\label{sec:VrManipulators}

O \emph{VrManipulators} contém as implementações dos manipuladores
disponíveis no framework. Um manipulador é um objeto capaz de modificar a
matriz de transformação da câmera de modo a produzir um tipo específico de
interação. Atualmente existem quatro tipos de manipuladores:

\begin{itemize}
%fly
 \item \emph{Fly}: produz na câmera o comportamento de um voo livre. Dentre os 
manipuladores atuais é o menos restritivo. É possível apontar a
câmera em todas as direções. A partir dessa direção de referência, movimentasse 
a câmera para frente, para tras, para os lados, para cima e para baixo.
%examine
 \item \emph{Examine}: a câmera realiza movimentos de rotação em torno de um
ponto, o \emph{pivot}. O posicionamento do \emph{pivot} em um ponto específico
de um objeto do cenário virtual, por exemplo no centro desse último, permite simular a inspeção em
torno do objeto escolhido para \emph{Pivot}
%walk
 \item \emph{Walk}: tem um comportamento similar ao do manipulador \emph{fly},
mas com a restrição de que a câmera se movimenta sempre no nível do plano do
chão, mesmo quando a câmera é apontada para cima. A referência de onde é o chão
em um dado momento deve ser fornecida pela aplicação. Como resultado, tem-se a
sensação de se estar caminhando pela cena.
%trilho
 \item \emph{Rail}: nesse manipulador o movimento de translação da câmera
somente pode ser feito em cima de um caminho específico atribuido previamente
pela aplicação, o \emph{trilho}. É possível movimentar a câmera nos dois
sentidos do \emph{trilho}, ao mesmo tempo em que se pode apontar a câmera em
todas as direções.
\end{itemize}

Os manipuladores possuem uma interface padrão composta basicamente po 3
métodos, que devem obrigatoriamente ser implementados:

\begin{itemize}
 \item \emph{setViewMatrix()}: Usado para atribuir a posição e orientação
atual da câmera. Esse método deve ser chamado preferêncialmente uma vez, sempre
que o manipulador começar a ser usado.
 \item \emph{update( dt )}: Nesse método fica a implementação do comportamento
do manipulador. Nele são feitos os cálculos necessários para produzir a mudança 
na câmera de acordo com chamadas realizadas pelos dispositivos de
entrada. Por exemplo, apertar a tecla 'w' provoca a chamada do método
\emph{goForward} no manipulador \emph{fly}. Esse último método tem como
efeito empilhar a \emph{requisição da ação} ``mover a câmera para frente``. Ao
ser executado, \emph{update} verifica a existência dessa requisição e calcula a
modificação necessária na câmera. O parâmetro \emph{dt} é o intervalo de tempo
entre a renderização do frame atual para o anterior e é usado no cálculo do
movimento. O método \emph{update} deve ser chamado sempre que um novo frame
estiver para ser desenhado.
 \item \emph{getViewMatrix()}: Usado para obter a matriz que deverá ser
atribuida à câmera. Deve ser chamado sempre após o método \emph{update}.
\end{itemize}

Além dos métodos descritos acima, um manipulador implementa também \emph{métodos
de requisição de ações}. Esses são específicos de cada manipulador e são
chamados geralmente quando um novo evento de dispositivo chega. Por exemplo, o
manipulador \emph{fly} possui os métodos \emph{goForward},
\emph{goBackward}, \emph{goLeft}, \emph{goRight} e
\emph{Rotate} que provocam requisições, respectivamente, de mudanças na
translação e orientação da câmera. Da mesma forma, o manipulador \emph{examine}
possui os métodos \emph{zoomIn}, \emph{zoomOut} e \emph{Rotacionar}. Como
mencionando antes, as ações desses métodos são realizadas no método
\emph{update}, quando este é chamado.

Cada manipulador possui acesso a uma estrutura chamada de
\emph{ManipulatorState}. Um ponteiro dessa estrutura é passado ao manipulador
através de seu construtor. É através do \emph{ManipulatorState} que os
parâmetros de configuração dos manipuladores podem ser alterados. Atualmente
estão disponíveis os seguintes parâmetros:

\begin{itemize}
 \item \emph{Velocidade de navegação}: Usado no cálculo do movimento de
translação da câmera.
 \item \emph{Velocidade da rotação}: Usado no cálculo de uma rotação realizada
na câmera.
 \item \emph{Vetor Up do mundo}: Estabelece qual o vetor UP do mundo. Em nossa
implementação todos os manipuladores podem realizar rotações apenas em torno de
dois eixos: o eixo UP do mundo e o eixo RIGHT da câmera. Com essa restrição,
garante-se que a câmera sempre fique alinha com o UP do mundo, o que se revelou
ser um requisito importante em ambientes imersivos.
 \item \emph{Ponto de pivot}: É o ponto em torno do qual a câmera fará
rotações. Atualmente é usado apenas pelo \emph{examine}.
 \item \emph{Ponto no chão}: Em conjunto com o vetor UP do mundo, esse ponto
estabelece qual o plano do chão usado pelo manipulador \emph{andar}.
 \item \emph{Caminho do trilho}: Estabelece qual o caminho que o manipulador
\emph{trilho} deve seguir.
 \item \emph{Permitir rotação em torno do vetor RIGHT}: Em testes realizados,
percebeu-se que em alguns momentos é conveniente limitar a liberdade de
rotação da câmera afim de facilitar a conclusão de algumas tarefas de
interação. Além disso, em alguns tipos de ambientes de visuaização, algumas
rotações podem provocar desorientação ao usuário. Esse é caso por exemplo
quando se permite em uma CAVE rotações em torno do vetor RIGHT. Isso tem o
efeito de fazer que o usuário tenha a impressão de que a cena está ''torta``
para algumas das telas. Pensando nisso, esse parâmetro permite travar a rotação
em torno do eixo RIGHT. 
 \item \emph{Permitir rotação em torno do vetor UP}: Tem o mesmo efeito do
parâmetro descrito no tópico anterior, só que atua nas rotações em torno do
vetor UP do mundo.
\end{itemize}

Os manipuladores descritos acima fornecem o suporte básico para tarefas de
navegação e inspeção em aplicações 3D e foram desenvolvidas para funcionar em
ambientes que vão desde o desktop padrão até ambientes imersivos como CAVEs,
NEXCAVE. Há planos para a criação de novos manipuladores, alguns desses sendo
apenas extensões dos já existentes.

\subsection{Transições}
Uma transição é uma interpolação entre duas poses diferentes de câmera. Seu
objetivo é impedir que o usuário fique desorientado ao trocar entre
manipuladores. Por exemplo, ao selecionar o manipulador \emph{rail}, dependendo
da posição corrente da câmera, a transição fará com que ela seja automaticamente
posicionada para o início do caminho de câmera definido no manipulador
\emph{rail}. Isso é feito através de uma animação suave que leva da pose atual
para a definida pelo manipulador \emph{rail}. Caso a câmera fosse simplesmente
transladada para a nova posição, isto é, sem a transição, o usuário poderia
ficar desorientado, especialmente em ambientes imersivos como a CAVE.

Internamente, a transição é implementada como uma interpolação entre a
\emph{pose} inicial e final da câmera quando da troca entre manipuladores.
Uma transição possui como parâmetros de controle sua duração e o tipo de
interpolação usado. São fornecidos dois tipos:

\begin{itemize}
 \item \emph{Linear}: Consiste em uma interpolação linear da posição e
orientação corrente da câmera para a nova posição requerida pelo
manipulador selecionado. Ideal para transiçês de curta duração.
 \item \emph{Slow Fast Slow}: Consiste em uma composição de interpolação não
linear da posição e interpolação esférica (\emph{Slerp}) da orientação corrente
da câmera para a nova posição requerida pelo manipulador selecionado. A
interpolação é dividida em três etapas: uma inicial e uma final que equivalem a
30\% do tempo de duração da transição, e uma etapa intermédia equivalente a 70\%
do tempo restante. O comportamento é baseado em movimento uniformemente
acelerado. A câmera acelera na etapa inicial até uma certa velocidade, se
mantém constante na segunda etapa e, na etapa final, desacelera até que a
câmera pare.
\end{itemize}

Para garantir que os modos propostos cumpram a tarefa de diminuir a 
desorientação do usuário, é recomendável avaliar o tempo de duração da transição
em relação ao tipo de ambiente onde o usuário vai interagir. Por exemplo, num
ambiente imersivo como uma CAVE é recomendável definir um tempo de transição que
não seja pequeno (por exemplo $\geq$ 5 segundos). Caso o tempo seja pequeno
demais, o efeito da transição será equivalente a um corte seco, aumentando o
grau de desorientação do usuário. Já num ambiente desktop sem imersão, o tempo
de transição alto pode ser desconfortável ao usuário, principalmente por causa
da espera para o término da transição. 


\subsection{VrInteraction}


O \emph{VrInteraction} é o gerenciador da interação. Ele controla a forma como
os dispositivos de entrada fazem uso dos manipuladores, assim como o processo de
troca entre eles. Para isso ele faz uso dos módulos \emph{VrInput},
\emph{VrManipulators}, \emph{VrTransitions} e de conjuntos de
\emph{mapeamentos} associados aos manipuladores.

Um \emph{mapeamento} define a relação entre um dispositivo de entrada e
um manipulador. Por exemplo, um mapeamento pode especificar que o movimento de
arraste do mouse causa uma rotação proporcional no manipulador \emph{examine}.
Um mapeamento é implementado através de um \emph{EventObserver}, projetado
para escutar eventos de um dispositivo e mapeá-los em ações em um manipulador
específico. Diferente dos \emph{EventObservers} criados pela aplicação, um
mapeamento no \emph{VrInteraction} não é capaz de fazer chamadas diretas a
métodos da aplicação, mas apenas àqueles definidos no manipulador envolvido no
mapeamento.

Atualmente existem mapeamentos para teclado e mouse, e os controles wii
e flystick (figura \ref{fig:fotofelipe}). Especificamente, os dispositivos 
teclado e mouse são usados em conjunto, formando os mapeamentos usados no
desktop padrão, onde é garantido que eles estarão presentes. Esses mapeamentos
foram feitos para os 4 manipuladores descritos na seção
\ref{sec:VrManipulators}. Dessa forma, hoje há um total de 12 mapeamentos no
\emph{VrInteraction}: 4 para teclado e mouse, 4 para o wii e 4 para o flystick.
Novos mapeamentos envolvendo dispositivos como kinect, celulares android e ipads
estão sendo desenvolvidos. Além disso, como a criação de um mapeamento consiste
apenas na criação de um novo \emph{EventObserver}, a inclusão de suporte a novos
dispositivos no futuro é uma tarefa simples.

\begin{figure}[!t]
  \begin{center}
		\includegraphics[width=0.47\textwidth]{figures/fotofelipe.pdf}
  \end{center}
  \caption{LVRL sendo usado em uma CAVE com suporte a Flystick.}
  \label{fig:fotofelipe}
\end{figure}

Os recursos usados por esses mapeamentos não devem ser acessados diretamente
pela aplicação, pois isso pode gerar uma situação de conflito em que o
recurso seria usado para duas tarefas distintas simultaneamente. Por esse
motivo, cada mapeamento foi desenvolvido para aproveitar as funcionalidades
do dispositivo da melhor forma possível usando o mínimo de recursos do mesmo.
Por exemplo, o flystick possui 6 botões e no máximo 2 são usados no
\emph{VrInteraction}. Os botões restantes são deixados para que o desenvolvedor
possa, através da criação de um \emph{EventObserver} próprio, usá-los para
realizar tarefas especificas da aplicação. Por exemplo, um dos botões restantes
pode ser usado para iniciar a visualização de uma simulação.

A presença de mapeamentos pré-definidos tem como vantagem minimizar o
trabalho do desenvolvedor que deseja criar uma aplicação RV de forma expedita. 
Não é preciso se preocupar com a criação de código relacionado a interação pois ele já está
imbutido no \emph{VrInteraction}. Também não é preciso pensar em um tratamento
específico para diferentes ambientes RV uma vez que os manipuladores e
mapeamentos foram criados para funcionar tanto em desktop quanto em ambientes
imersivos. Por último, o \emph{VrInteraction} padroniza a interação nas
aplicações que o utilizam. Do ponto de vista do usuário, isso simplifica o aprendizado 
tornando-o mais rápido e eficaz uma vez que ele não terá que aprender um novo sistema de
interação ao usar uma aplicação diferente.

As funcionalidades do \emph{VrInteraction} são fornecidas através da interface
\emph{InteractionController}, cuja api é brevemente descrita abaixo:

\begin{itemize}
 \item \emph{setDeviceReader( deviceType, readerId )}: Esse método informa ao
\emph{VrInteraction} qual é o leitor que será usado para acessar um dispositivo.
O parâmetro \emph{deviceType} é uma string pré-definida no \emph{VrInteraction}
que identifica um tipo de dispositivo. Por exemplo, as strings VRINT\_DESKTOP,
VRINT\_WII e VRINT\_FLYSTICK referem-se respectivamente aos dispositivos teclado
e mouse, wii e flystick. O parâmetro \emph{readerId} é um identicador de um
leitor previamente criado através do \emph{VrInput}. Como exemplo, assumindo que
um leitor para controles wii foi criado com o identicador ''wii0``, a chamada
\emph{setDeviceReader( VRINT\_WII, ''wii0`` )} faz com que esse leitor seja
usado por todos os mapeamentos para o controle wii.
 \item \emph{setMode( mode )}: Através desse método a aplicação escolhe qual
manipulador será usado no momento. O parâmetro \emph{mode} é uma string que
identifia um manipulador. Por exemplo, \emph{setMode( VRINT\_FLY )} faz com o
manipulador \emph{fly} seja ativado. Quando chamado, esse método verifica se é
preciso realizar uma transição entre o manipulador anterior e o atual. Por
exemplo, se o manipulador \emph{rail} for escolhido, o \emph{VrInteraction} cria
uma transição que leva a câmera até a posição inicial do trilho. Depois dessa
etapa, procura-se por um mapeamento entre o manipulador que se quer usar e o
dispositivo que está ativo no momento. Caso não seja encontrado nenhum
compatível, é escolhido um mapeamento nulo que não produz efeito na câmera. Por
fim, a matriz de câmera resultante do manipulador anterior é atribuida ao atual.
Isso garante, junto com as transições, que haja continuidade e fluidez na
interação.
 \item \emph{setDevice( deviceType )}: Esse método permite escolher qual 
dispositivo usar. O parâmetro \emph{deviceType} é uma string que identifica o
tipo de dispositivo. Por exemplo, \emph{setDevice( VRINT\_DESKTOP )} faz com
que o teclado e o mouse sejam usados. Assim como acontece no método
\emph{setMode}, quando \emph{setDevice} é chamado, o \emph{VrInteraction}
procura por um mapeamento compatível com o tipo de dispositivo escolhido e o
manipulador atual. Caso não seja encontrado, um mapeamento nulo é escolhido.
 \item \emph{setViewMatrix( m )}: O \emph{VrInteraction} encapsula o uso do
módulo \emph{VrManipulators}. Dessa forma, a aplicação não tem acesso direto aos
manipuladores. Como mencionado antes, é o \emph{VrInteraction} o responsável por
gerenciar o acesso aos manipuladores. Esse método tem como objetivo permitir
atribuir a posição e orientação inicial da câmera nos manipuladores.
 \item \emph{getViewMatrix()}: Esse método retorna a matriz de view do
manipulador atual para que essa possa ser aplicada na câmera pela aplicação.
 \item \emph{update( dt )}: Caso uma transição não esteja ocorrendo, esse
método tem como efeito chamar o \emph{update} do manipulador em uso. O
parâmetro $dt$ é um intervalo de tempo e tem o mesmo significado daquele passado
para o método \emph{update} do manipulador. 
\end{itemize}

Para configurar os parâmetros de configuração descritos na seção
\ref{sec:VrManipulators}, o \emph{VrInteraction} cria uma instância de
\emph{ManipulatorState} e a repassa para todos os manipuladores. Como a
instância é única, garante-se uma uniformidade entre os comportamentos dos diferentes
manipuladores. Para permitir que a aplicação mude esses parâmetros, é fornecida
uma api na interface \emph{InteractionController}.

Apesar de depender do módulo \emph{VrInput}, o \emph{VrInteraction} pode ter
várias instâncias em uma mesma aplicação. Com isso é possível controlar mais de
uma câmera. Isso é uma característica que pode ser usada em aplicações RV
colaborativas, onde cada usuário teria controle de sua câmera. É importante
mencionar também que o \emph{VrInteraction} não realiza nenhuma chamada aos
métodos da interface \emph{InputController}. Ele apenas escuta os eventos
gerados pelo \emph{VrInput}. Logo, a criação dos leitores, assim como a chamada
ao método \emph{ProcessEvents} deve ser feita pela aplicação, como exposto na
seção \ref{sec:VrInput}. Caso isso não seja feito, não haverá geração de eventos
nos dispositivos de entrada e, por consequência, o \emph{VrInteraction} não será
capaz de gerar uma matriz de transformação para a câmera. 

Como mencionado antes, o uso do \emph{VrInteraction} fornece formas de interação
pré-definidas que permitem realizar as tarefas básicas de navegação e inspeção
em novas aplicações 3D. Apesar disso criar certa rigidez, uma vez que os mapeamentos
estão pré-definidos, isso contribui para minimizar o custo de criação de novas
aplicações 3D, ou a transformação de aplicações legadas em aplicações imersivas. Além disso, espera-se que com a execução de testes de usabilidade
e a opinião dos usuários dos sistemas que fazem uso do \emph{VrInteraction},
os mapeamentos convirjam para formas ideias de interação.

\section{Discussão}
Nesta seção discutimos as principais caracteristicas e contribuições do framework \emph{LVRL}.

\label{sec:disc}
\subsection{Interface de programação transparente}
Utilizando o framework por completo, a aplicação só tem contato com os módulos  
\emph{VrInteraction}, \emph{VrWand}, \emph{VrInput} e \emph{VrFrustum}. Na seção
anterior foi demostrado que todos esses componentes tem os mesmos resultados
estando em modo desktop e RV. Dessa forma, o desenvolvedor pode programar sua
aplicação sem se preocupar com detalhes inerentes ao tipo de ambiente de
visuaização.

\subsection{Mudança de desktop para imersivo em tempo de execução}
Com o design do \emph{VrInteraction} e do \emph{VrFrustum} é possivel mudar de
desktop para formato imersivo e vice-versa em tempo de execuçao apenas fazendo
chamadas de métodos. Para reconfigurar as telas, basta carregar um novo arquivo
de configuração no \emph{VrFrustum}. Para usar um dispositivo de RV ao invés
dos tradicionais mouse e teclado, é preciso somente dizer ao
\emph{VrInteraction} qual dispositivo usar. 

\subsection{Não intrusivo}
Todas as componentes descritas não tomam conta da aplicação. São componentes 
que podem ser consultadas sempre que a aplicação principal precisar. O
desenvolvedor pode usar a engine gráfica que quiser e não é exigido que sua
aplicação seja reescrita em torno do LVRL. O controle de execução continua
pertencendo a aplicação e não ao LVRL.

\subsection{Multiplataforma}
Todas as componentes não tem nenhuma dependência do sistema e foram
desenvolvidas com o objetivo de rodar em vários sistemas operacionais.
Atualmente há suporte para Windows e Linux. A exceção reside apenas no 
\emph{VrInput}, que depende dos drives do dispositivo. Dessa forma, alguns
dispositivos não são suportados em todas as plataformas. Apesar dessa
dependência, o design baseado em um gerenciador central e vários
leitores cujo o acoplamento são eventos baseados apenas em
texto, permite que o \emph{VrInput} seja usado em várias plataformas, mesmo
quando um determinado dispositivo não possui driver para a plataforma.

\subsection{Independência do Hardware}
Com o uso do \emph{VrInput} a presença ou não de um driver de dispositivos não
influência no uso da componente. Apenas o leitor daquele dispositivo não estará
disponível.

\subsection{Portável}
A implementação do framework usa apenas tipos nativos do C++. Dessa forma,
conseguimos portá-lo facilmente para C e Unity3D, mostrando assim que a
arquitetura do framework não impõe nenhuma restrição a portabilidade entre as
linguagens.

\subsection{Compatível com renderização distribuida}
Apesar da componente não ter internamente primitivas de renderização
distribuída, a configuração do VrFrustum fornece as ferramentas necessárias
para se atingir esse objetivo. 

\section{Conclusoes e trabalhos futuros}
\label{sec:concl}
O LVRL, com sua abordagem minimalista e não intrusiva, demostrou ser um framework com as características necessárias para ser usado na maioria das aplicações de visualizacao científica do grupo.
Por esse motivo, acreditamos que isso possa ser extendido a várias
outras aplicações existentes. O Design não intrusivo e a interface
de programação transparente são as principais caracteristicas que permitem que
programadores fora do universo de Realidade Virtual convertam ou desenvolvam
novas aplicações para ambientes imersivos. 

O principal trabalho futuro a ser feito é um estudo de ergonomia e de
usabilidade para alcançar a melhor forma de interação para os mapeamentos
presentes no \emph{VrInteraction}. Além disso, há estudos em andamento sobre
novas formas de interação envolvendo dispositivos como kinect, smartphones e
pads.

% use section* for acknowledgement
\section*{Acknowledgment}
omitido para revisão

\bibliographystyle{IEEEtran}
\bibliography{vrintbib}

% that's all folks
\end{document}


