FARIAS, Thiago. A2: um modelo de referência para

Transcrição

UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
THIAGO SOUTO MAIOR CORDEIRO DE FARIAS
[email protected]
“A2: UM MODELO DE REFERÊNCIA
PARA APLICAÇÕES DE REALIDADE AUMENTADA
EM REDES DE AMBIENTE”
DISSERTAÇÃO SUBMETIDA AO CENTRO DE INFORMÁTICA
DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO
REQUISITO PARCIAL PARA RECEBER O TÍTULO DE
MESTRE EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADORA: PROF. DR. JUDITH KELNER ([email protected])
CO-ORIENTADORA: PROF. DR. VERONICA TEICHRIEB ([email protected])
RECIFE - BRASIL, MARÇO 2007.
ABSTRACT
Two research areas have recently emerged capturing a great deal of interest from the
academic community. The first of these is Augmented Reality (AR) that still lacks some
important definitions due to its novelty and close relationship to correlated areas such as
Virtual Reality. Some of the challenges faced by AR include dealing with design issues such as
occlusion in the use of fiducial markers, symbolic pattern recognition, including gestures and
voice, and the use of markerless augmented reality. Several researchers have been dedicated
to these problems as well as the use of some interdisciplinary resources. A case in the point of
the latter is computational vision. This area has been the scene of many applications and has
shown a large concern with the use of low cost devices and its ability to represent a wide
range of applications such as medicine and digital entertainment.
A second area currently also receiving considerable interest is known as Ambient Networks
(AN). ANs define new concepts and architectures for wireless and mobile networks beyond
3G. They introduce the concept of network composition, a mechanism that allows networks
and devices to be formed and controlled dynamically while sharing connectivity and other
services. ANs are capable of creating scalable networks of low cost devices offering advanced
services resulting from their cooperation in an environment typically formed of
heterogeneous elements, devices, wireless technologies, ISPs and corporate networks.
Factors such as the relative recent emergence of the two areas, namely AR and AN, and new
hardware advances for mobile and wireless devices opened the door for the development of
applications and services that were never thought before. This work presents a reference
model in the context of ambient networks to be used for the development of sophisticated
services and interfaces, based on the use of AR. This MSc dissertation propose a new
architecture focusing on interaction issues faced when using wireless devices, cellular phones,
PDAs (Personal Digital Assistant) and wearable computers.
Keywords:
virtual
Ambient
reality,
Networks,
augmented
services,
interface,
reality,
interaction,
devices,
multiplatform development.
ii
RESUMO
Duas áreas de pesquisa têm despertado um grande interesse na comunidade acadêmica. A
primeira delas é a de Realidade Aumentada (AR) onde existem algumas definições que
continuam em aberto, pela novidade da área e/ou pelo pequeno limiar entre algumas áreas
correlatas, principalmente Realidade Virtual. Alguns dos desafios existentes em AR incluem
problemas existentes no projeto, tais como: a oclusão na utilização dos marcadores fiduciais,
o reconhecimento de padrões simbólicos, como gestos, fala, e utilização da realidade
aumentada sem marcadores. Muitos pesquisadores têm se dedicado a buscar soluções para
estes problemas assim como a utilização de alguns recursos interdisciplinares, como destaque
deste último os relacionados à visão computacional. A área de AR apresenta cenários para a
utilização de dispositivos de baixo custo e um vasto campo de atuação, que engloba aplicações
desde a medicina ao entretenimento digital.
A outra área que está despontando no momento são as Redes de Ambiente (AN). O
Ambient Networks Project propõe uma solução para redes de sistemas móveis e sem fio,
além do 3G (protocolos de terceira geração). Neste projeto é introduzido o conceito de
composição de redes, mecanismo que permite a junção de redes com dispositivos enquanto
compartilham conectividade e outros serviços. As AN permitem a criação de uma rede de
comunicação sem fio escalável e de baixo custo, oferecendo serviços avançado que são
resultantes da cooperação num ambiente tipicamente formado por elementos heterogêneos,
dispositivos, tecnologias sem fio, operadores de redes de comunicação e empresários.
Estas duas áreas (AR e AN) relativamente novas, mais o avanço, principalmente em
termos de hardware, dos dispositivos móveis, permitem o desenvolvimento de inúmeras
aplicações e serviços que somente podem existir mediante a inserção destes novos conceitos.
Este trabalho apresenta um modelo de referência utilizando redes de ambiente para o
desenvolvimento de interfaces e serviços sofisticados, baseados em AR. Esta dissertação
propõe uma nova arquitetura com foco na abordagem de problemas de interação quando
utilizando dispositivos móveis, como celulares, PDAs (Personal Digital Assistant) e wearable
computers.
Palavras
realidade
chaves:
virtual,
Redes
realidade
de
ambiente,
aumentada,
serviços,
interface,
dispositivos,
interação,
desenvolvimento
multiplataforma.
iii
AGRADECIMENTOS
Agradeço ao CNPq que financiou esta dissertação de mestrado e a todos que contribuiram
para que este trabalho pudesse ser realizado, especialmente a todos os companheiros do
GRVM/GPRT.
Um agradecimento mais especial ainda à minha orientadora Judith Kelner, e à coorientadora Veronica Teichrieb pela paciência e dedicação.
iv
ÍNDICE
CAPÍTULO 1
INTRODUÇÃO .................................................................................... 9
1.1
Definição do Problema ................................................................................................ 9
1.2
Objetivos .................................................................................................................... 10
1.3
Relevância ................................................................................................................... 11
1.4
Estrutura da dissertação ............................................................................................. 11
CAPÍTULO 2
REALIDADE AUMENTADA.................................................................. 13
2.1
Introdução ao Capítulo ............................................................................................... 13
2.2
Conceitos Básicos........................................................................................................ 13
2.3
Interfaces de Visualização .......................................................................................... 14
2.4
Interfaces de Interação ............................................................................................... 17
2.5
Dispositivos de Interação ...........................................................................................18
2.5.1
Dispositivos de Interação em Realidade Virtual ....................................................18
2.5.2
Dispositivos Móveis ............................................................................................... 19
2.6
Áreas de Aplicação ..................................................................................................... 20
2.6.1
Áreas de Aplicação Tradicionais ........................................................................... 20
2.6.2
Sistemas Móveis de Realidade Aumentada .......................................................... 22
2.6.3
Realidade Aumentada com Dispositivos Móveis .................................................. 23
2.7
Considerações Finais ................................................................................................. 23
CAPÍTULO 3
DESENVOLVIMENTO MULTIPLATAFORMA DE APLICAÇÕES DE REALIDADE
VIRTUAL E REALIDADE AUMENTADA ..................................................................... 25
3.1
Introdução ao Capítulo .............................................................................................. 25
3.2
Desenvolvimento na Plataforma Desktop ................................................................. 25
3.2.1
Interação com Dispositivos/Ambiente.................................................................. 27
3.2.1.1
3.2.2
3.3
CIDA ................................................................................................................ 28
Ferramentas .......................................................................................................... 29
3.2.2.1
OpenGL ........................................................................................................... 29
3.2.2.2
OGRE.............................................................................................................. 29
3.2.2.3
ARToolKit ........................................................................................................ 31
3.2.2.4
OgreAR ............................................................................................................ 31
Desenvolvimento na Plataforma Pocket PC .............................................................. 33
3.3.1
OGRE no Pocket PC .............................................................................................. 34
3.3.2
OpenGL ES............................................................................................................ 36
3.3.3
ARToolKitPlus ...................................................................................................... 37
3.4
Desenvolvimento na Plataforma Symbian OS........................................................... 37
v
3.4.1
Dificuldades Encontradas ..................................................................................... 38
3.4.1.1
API ARToolKit Portada para Symbian OS ...................................................... 38
3.4.1.2
Ambiente de Desenvolvimento ....................................................................... 40
3.5
CAPÍTULO 4
DESCRIÇÃO DO MODELO A2 ......................................................... 43
4.1
Introdução ao Capítulo .............................................................................................. 43
4.2
Redes Heterogêneas .................................................................................................. 43
4.3
Redes de Ambiente .................................................................................................... 44
4.4
O Modelo A2 .............................................................................................................. 45
4.5
Protocolo de Intercomunicação entre Serviços e AN XCSERVICES......................... 46
4.6
Serviços ...................................................................................................................... 47
4.7
Frameworks de Desenvolvimento para Classes de Dispositivos .............................. 48
4.8
Ambiente de AR ......................................................................................................... 49
4.9
CAPÍTULO 5
ESTUDO DE CASO: O PROJETO A2 ...................................................... 51
5.1
Introdução ao Capítulo ............................................................................................... 51
5.2
Descrição dos Equipamentos...................................................................................... 51
5.2.1
Plataformas............................................................................................................. 51
5.2.1.1
Plataforma Celular ........................................................................................... 51
5.2.1.2
Plataforma Pocket PC ...................................................................................... 51
5.2.1.3
Plataforma Mobile Desktop ............................................................................ 52
5.3
Estudo de Caso: O Museu Virtual .............................................................................. 52
5.3.1
Serviço de Visitação a uma Galeria de Arte ........................................................... 54
5.3.2
Serviço de Entrevista .............................................................................................57
5.3.3
Serviço de Leilão ................................................................................................... 58
5.3.4
Serviço de Chat ..................................................................................................... 59
5.4
CAPÍTULO 6
6.1
CONCLUSÃO ................................................................................... 62
Contribuições ............................................................................................................. 62
6.1.1
Desenvolvimento de software e do framework...................................................... 62
6.1.2
Publicações relevantes .......................................................................................... 63
6.2
Trabalhos Futuros ..................................................................................................... 64
Bibliografia ........................................................................................................................... 66
vi
LISTA DE FIGURAS
Figura 2.1. Representação simplificada da continuidade virtual (adaptado de [5]). ................ 13
Figura 2.2. Aplicação table-top em AR [8]. .............................................................................. 14
Figura 2.3. Diagrama conceitual (adaptado de [3]) e exemplo do optical see-through HMD. 15
Figura 2.4. Diagrama conceitual (adaptado de [3]) e exemplo do video see-through HMD. .. 16
Figura 2.5. Sistema monitor-based (adaptado de [3]).............................................................. 17
Figura 2.6. Tipos de luvas [11], [12]. ......................................................................................... 19
Figura 2.7. Tracker. ................................................................................................................... 19
Figura 2.8. Wearable computer tradicional para AR móvel (esquerda) e PDA (direita) [13]. 20
Figura 2.9. Imagem sobreposta ao paciente [15]. ..................................................................... 21
Figura 2.10. Visão do usuário jogando ARQuake [17].............................................................. 22
Figura 2.11. Workspace para planejamento urbano [19]. ........................................................ 22
Figura 3.1. Reconhecimento da face para posicionar óculos virtual. ...................................... 26
Figura 3.2. Projeção da cena virtual sobre o objeto real 3D.................................................... 26
Figura 3.3. Wearable Computer. ............................................................................................. 27
Figura 3.4. Usuário vestindo a plataforma miva. ..................................................................... 27
Figura 3.5. Teclado interpretado como dois joysticks. ............................................................ 29
Figura 3.6. Marcador fiducial utilizado pelo ARToolKit. .......................................................... 31
Figura 3.7. Arquitetura do OgreAR. ......................................................................................... 32
Figura 3.8. Aplicações de AR usando o ARToolKitPlus. .......................................................... 33
Figura 3.9. Screenshots de demos do OGRE no Pocket PC: a) SkeletalAnimation usando o
RenderSystem baseado em OpenGL ES; b) SkyBox usando o RenderSystem baseado
em OpenGL ES; c) SkeletalAnimation usando o RenderSystem baseado no Klimt. ..... 36
Figura 4.1. Diagrama do modelo A2. ........................................................................................ 46
Figura 5.1. Nokia 6600 utilizado no Projeto A2. ....................................................................... 51
Figura 5.2. Dell Axim x51v utilizado no Projeto A2. ................................................................ 52
Figura 5.3. Versão ppreliminar do Folder utilizado no estuudo de caso. ................................ 53
Figura 5.4. Nokia N93. ............................................................................................................. 54
Figura 5.5. Aplicação Mobile Desktop exibindo informação 2D sobre 2 marcadores. ............ 55
Figura 5.6. Conteúdo adicional em forma de vídeo sendo exibido na plataforma Mobile
Desktop. ............................................................................................................................ 55
Figura 5.7. Serviço de visualização na plataforma Pocket PC. ................................................. 56
Figura 5.8. Diferentes visões da utilização do 3DLive. .............................................................57
Figura 5.9. Cubo de marcadores em utilização. ....................................................................... 58
Figura 5.10. Interface do serviço do leilão na plataforma Pocket PC....................................... 59
Figura 5.11. Serviço de chat na plataforma Mobile Desktop. ................................................... 60
vii
Figura 5.12. Interface do serviço de chat na plataforma Pocket PC. ........................................ 60
viii
INTRODUÇÃO
CAPÍTULO 1
INTRODUÇÃO
A evolução e o crescimento na escala dos sistemas, das Redes de Computadores, da Internet,
da Web e dos recursos e soluções de Tecnologia da Informação (TI) como um todo,
associados ao alto custo em prover esses tipos de serviços, evidenciam a necessidade de
compartilhar recursos, disponibilizar serviços e cooperação entre redes – o que é realizado
através de acordos ou políticas. Os acordos realizados atualmente exigem extensiva
configuração manual, bem como um conhecimento prévio do comportamento das redes em
que vão atuar. Entretanto, a heterogeneidade dos dispositivos, a diversidade dos serviços
disponíveis, a dinamicidade, a mobilidade e a natureza assíncrona dos dispositivos e dos
serviços tornam inviável a complexa tarefa de gerenciamento centralizado e a predição
contínua de seu estado ou de seu contexto de operação [1].
Aplicações que utilizam as características descritas anteriormente, na maioria dos
casos, necessitam de um alto grau de imersão e mobilidade do usuário, que podem ser
alcançados através de interfaces avançadas que utilizam sofisticadas técnicas de interação,
permitindo a sobreposição de elementos virtuais no mundo real e, se necessário, em tempo
real. Esse tipo de interface explora metáforas que o usuário está acostumado a utilizar no seu
dia-a-dia, ou seja, o usuário continua vendo o mundo real e interagindo com a interface
sobreposta como se fosse parte do seu mundo [2].
Tais interfaces avançadas podem ser implementadas através da tecnologia de
Realidade Aumentada (Augmented Reality - AR), que lida com a sobreposição de elementos
virtuais no ambiente real, em tempo real (on-line). Atualmente, aplicações de AR são usadas
em diferentes domínios de conhecimento, tais como entretenimento, medicina, simulação,
propaganda visual, educação, manutenção, entre outras.
1.1 DEFINIÇÃO DO PROBLEMA
Nos últimos anos duas áreas têm despontado na comunidade tecnológica, mas ainda são
pouco exploradas comercialmente, despertando um maior interesse por parte da comunidade
acadêmica.
Uma dessas áreas é a de AR, que está sendo colocada como uma expansão da
Realidade Virtual (Virtual Reality - VR) [3]. Muito tem sido comentado sobre esta área, mas
ainda hoje algumas definições continuam em aberto, provavelmente pela novidade e pelo
pequeno limiar entre algumas áreas correlatas. Informalmente, AR permite que o usuário
veja o mundo real com alguns objetos virtuais inseridos nele, possibilitando com isso uma
9
INTRODUÇÃO
maior interatividade entre o usuário e o ambiente, assim como uma maior percepção do
mundo pelo usuário.
A outra área que está em ascensão é a de Redes de Ambiente (Ambient Networks AN) [4]. Estas são baseadas em um conjunto de múltiplas redes construídas com diferentes
tecnologias. O objetivo das AN é unir os diferentes tipos de redes, tais como Body Area
Networks (BANs), Vehicular Area Networks (VANs), Personal Area Networks (PANs),
Home Area Networks (HANs), redes de acesso sem fio, redes celulares, redes heterogêneas,
entre muitas outras.
Estas duas áreas relativamente novas, integradas ao avanço, principalmente em
termos de hardware, dos dispositivos móveis, permitem o desenvolvimento de inúmeras
aplicações nos mais diversos campos de atuação. Por outro lado, a intersecção da AR com as
AN amplia o número de problemas que já existem em cada uma per si. Alguns dos problemas
a serem considerados nesta intersecção são: mobilidade, percepção, adaptação de conteúdo,
interatividade, entre outros. Considerando que, em um futuro próximo, haverá uma
convergência para ambientes onde os usuários estarão potencialmente conectados em
qualquer lugar a qualquer momento, utilizando diferentes tipos de dispositivos, existe a
necessidade de viabilizar através de um estudo de caso a utilização deste novo tipo de
interface em serviços móveis e interativos.
1.2 OBJETIVOS
Esta dissertação de mestrado tem por objetivo principal propor um novo conceito de
interface para serviços, explorando a imersão e a mobilidade inerentes à tecnologia de AR e a
sua integração com as AN. O modelo Augmented Ambient, ou simplesmente A2, permitirá a
construção de novos serviços multimídia e a composição de um novo cenário de
comunicação, promovendo um nível de interatividade maior dos serviços com o ambiente
real.
O A2 propõe uma arquitetura para distribuição e validação de serviços, e adaptação de
conteúdo que será utilizada em várias classes de dispositivos (celulares, Personal Digital
Assistants (PDAs) e notebooks) para o acesso a serviços de comunicação avançados. Também
é proposto um framework para construção de serviços baseados em AR utilizando
dispositivos móveis.
Alguns serviços foram implementados para demonstrar os conceitos de AN, tendo
como estudo de caso um museu virtual. Este estudo de caso provê serviços como
intercomunicação dos visitantes do museu através de VoIP (Voice over IP), acesso a leilões
virtuais, entrevistas com fluxo de vídeo 3D e visualização de obras de arte. Utilizando
recursos da AR os visitantes poderão perceber obras que não estão fisicamente no ambiente
10
INTRODUÇÃO
do museu, sendo estas inseridas na realidade do visitante através de marcadores fiduciais
associados a um sistema que pode ser composto por um Head-Mounted Display (HMD),
uma câmera e um notebook, ou ainda por um PDA ou celular com câmera. No caso dos PDAs
e celulares, eles podem ainda simular uma “lupa virtual”, exibindo o conteúdo da AR em sua
tela à medida que o usuário direciona a câmera para o marcador desejado.
Diferentes tipos de mídia podem ser exibidos em dispositivos (PDAs, celulares,
notebooks, wearable computers, entre outros), dependendo apenas do seu poder de
processamento e exibição. Sendo assim, além de imagens, o usuário poderá assistir à exibição
de vídeos, ouvir trilhas de áudio, ou ver objetos virtuais que não existem “de fato” no
ambiente real.
1.3 RELEVÂNCIA
Este trabalho propõe o estudo de cenários interativos que exploram a utilização de
computação pervasiva. A computação pervasiva é uma tendência que envolve várias áreas,
como interface homem-máquina, para manter uma interface transparente e favorecer uma
interação rápida e simples com o usuário, realidade virtual e computação gráfica, para tornar
as interfaces mais imersivas e naturais para o usuário e redes de computadores, para facilitar
a intercomunicação entre as partes comunicantes, caso haja uma interação entre vários
usuários ou máquinas, colaborando para a realização de tarefas.
A computação ubiqua, como também pode ser chamada a computação pervasiva,
depende também de realização de tarefas e utilização de serviços a qualquer momento,
utilizando qualquer tipo de dispositivo, o que incentiva também o estudo e desenvolvimento
de tecnologias para implementação de interfaces de realidade virtual e aumentada em
múltiplas plataformas.
Para facilitar o desenvolvimento de aplicações e serviços e viabilizar a utilização de
redes heterogêneas e computação pervasiva, como casas inteligentes, shopping centers
interativos e museus virtuais, entre outros, é relevante a criação do modelo de referência,
chamado A2. O A2 foi concebido para tornar o desenvolvimento mais rápido e modular,
através de uma arquitetura com infra-estrutura de rede e frameworks para implementação de
serviços e interfaces multiplataforma.
1.4 ESTRUTURA DA DISSERTAÇÃO
Esta dissertação está dividida em 6 capítulos, incluindo este. O Capítulo 2 trata de conceitos
básicos da área de realidade virtual e aumentada, assim como algumas áreas de aplicação
semelhantes ao trabalho proposto. O Capítulo 3 ilustra o desenvolvimento multiplataforma,
necessário para a adequação de vários dispositivos ao acesso de serviços multimídia. Nele são
11
INTRODUÇÃO
apontadas
algumas
bibliotecas
utilizadas
e
outras
construídas
para
facilitar
o
desenvolvimento. Além disso, são apresentadas algumas dificuldades no desenvolvimento
para a plataforma Symbian, que se mostrou bastante problemática. No Capítulo 4, é
apresentada a proposta do modelo de implementação de serviços para dispositivos móveis,
detalhando as entidades presentes no modelo e ilustrando a arquitetura por completo. O
Capítulo 5 mostra o estudo de caso realizado, como prova de conceito, para o modelo
proposto no Capítulo 4. Nele são expostos os equipamentos escolhidos e os serviços
implementados de uma forma detalhada, deixando claro o modo de interação utilizado em
cada plataforma. Por fim, o Capítulo 6 apresenta a conclusão e alguns trabalhos futuros.
12
REALIDADE AUMENTADA
CAPÍTULO 2
REALIDADE AUMENTADA
2.1 INTRODUÇÃO
Este capítulo descreve os principais conceitos relacionados à área de realidade
aumentada, mostrando tanto dispositivos de visualização e de interação quanto as técnicas
envolvidas. Uma breve discussão sobre algumas áreas de aplicação é apresentada também
neste capítulo.
2.2 CONCEITOS BÁSICOS
Realidade Mista (Mixed Reality - MR) envolve a união do mundo real com o mundo virtual
em algum lugar na “continuidade virtual”, como pode ser visto na Figura 2.1. A continuidade
virtual representa uma taxonomia que conecta o ambiente real e o ambiente virtual [5].
Popularmente, MR é definida como sendo uma tecnologia que mistura o mundo virtual
(gráficos e/ou imagens geradas por computador) e o mundo real em tempo real.
Figura 2.1. Representação simplificada da continuidade virtual (adaptado de [5]).
Segundo [6], VR é uma interface homem-máquina de alto nível que envolve
simulações em tempo real e interações através de múltiplos canais sensoriais. Estas
modalidades sensoriais são a visão, a audição, o tato, o olfato e o paladar.
Como características inerentes ao conceito de VR tem-se a imersão, a interação e a
imaginação. A partir destes conceitos o usuário pode ter uma ampla experiência de uso em
um sistema de VR. A imersão pode ser favorecida pela utilização de óculos de realidade
virtual (Head Mounted Displays - HMDs), luvas de dados e fones de ouvido, entre outros
dispositivos.
Em AR o usuário vê o mundo real com objetos virtuais inseridos neste ou ainda
escondendo objetos reais, ou seja, AR complementa o mundo real ao invés de sobrepô-lo [3].
Assim como a VR, a AR pode explorar os sentidos da audição e tato aumentando a percepção
13
REALIDADE AUMENTADA
do usuário e a sua interação com o mundo real, através da superposição de informações, que
serão percebidas pelo usuário como parte da realidade onde este está imerso
Estas
informações, conduzidas através de objetos virtuais, ajudarão no desempenho das tarefas do
mundo real. A figura abaixo ilustra uma aplicação table-top em AR que exibe prédios virtuais
do centro de Augsburg - Alemanha projetados sobre o mapa real da cidade. Com esta
aplicação o usuário pode planejar a construção de novos prédios, otimizando o planejamento
de projetos de arquitetura e urbanismo, como também problemas mais complexos como
emissões de calor dependentes do tipo de material empregado em cada edificação e o impacto
ambiental. Ainda neste contexto pode-se citar o projeto Open Spaces in Megacities [7] em
desenvolvimento na UFPE.
Figura 2.2. Aplicação table-top em AR [8].
Bibliotecas de AR comumente fazem uso de marcadores fiduciais, que são aplicados
no cálculo da posição e orientação de objetos virtuais posicionados sobre a imagem adquirida
do mundo real. Tais marcadores podem ser classificados em dois tipos: baseados em
templates e baseados em identificadores. No primeiro tipo, uma figura ou padrão será
utilizada como identificação do marcador, sendo a esta associado um identificador único para
registro na aplicação. Já o segundo tipo de marcador possui uma codificação do identificador,
possibilitando uma correlação direta entre o marcador e o identificador, diminuindo erros de
registro. Entende-se por registro a ação de correlacionar a posição e a orientação fornecidas
por um marcador para um objeto virtual.
2.3 INTERFACES DE VISUALIZAÇÃO
Dentre os vários dispositivos utilizados para a visualização de ambientes virtuais, serão
14
REALIDADE AUMENTADA
enfocados nesta seção os HMDs ou Head-Worn Displays (HWDs). Existem dois tipos de
HMDs: o closed-view e o see-through. O primeiro não permite uma visão direta do mundo
real e é o mais usado em VR, enquanto que o segundo permite que o usuário enxergue o
mundo real com objetos virtuais sobrepostos nele.
Os HMDs do tipo see-through podem usar dois tipos de tecnologia, ótica ou de vídeo,
constituindo respectivamente dois tipos de HMDs, os optical see-through HMDs, que têm o
funcionamento ilustrado na Figura 2.3 e os video see-through HMDs, melhor detalhados na
Figura 2.4.
Figura 2.3. Diagrama conceitual (adaptado de [3]) e exemplo do optical see-through HMD.
Como citado em [3], as principais vantagens deste HMD são:
•
Simplicidade: só existe uma stream de vídeo para ser processada, pois o
mundo real já é exibido naturalmente;
•
Resolução: a resolução do mundo real não é limitada pela resolução dos
displays;
•
Segurança: se a energia for cortada o usuário continuará com a visão do
mundo real, apenas sendo descartada a parte virtual;
•
No eye offset: como não há câmeras envolvidas no dispositivo, não existe a
possibilidade de ocorrer uma diferença entre a posição das câmeras e a
distância entre os olhos do usuário.
15
REALIDADE AUMENTADA
Figura 2.4. Diagrama conceitual (adaptado de [3]) e exemplo do video see-through HMD.
Como citado em [3], as principais vantagens do video see-through são:
•
Neste HMD inexiste o problema dos objetos virtuais não ocludirem
completamente os objetos reais, devido à exposição a fontes de luzes apenas
virtuais;
•
Wide field-of-view: são descartadas as distorções que normalmente ocorrem
em sistemas ópticos;
•
As imagens do mundo real podem ser sincronizadas com as dos objetos
virtuais, o que não ocorre com os optical see-through HMDs.
Já no sistema monitor-based, ilustrado pela figura 2.5, podem ser utilizadas uma ou
duas câmeras, sendo estas estáticas ou móveis. Nele, as imagens sintetizadas pelo sistema de
VR são exibidas em um monitor comum posicionado à frente do usuário, e podem contar com
a ajuda de óculos do tipo estéreo para visualização explorando as técnicas estereoscópicas. O
vídeo do mundo real é então combinado com os objetos virtuais e exibido no sistema. Este
sistema tem como vantagem dispensar a utilização de quaisquer dispositivos externos, exceto
opcionalmente um simples óculos anaglifo quando se deseja visualizar a cena em 3D[3].
16
REALIDADE AUMENTADA
Figura 2.5. Sistema monitor-based (adaptado de [3]).
2.4 INTERFACES DE INTERAÇÃO
No contexto de interfaces homem-máquina, interação é a maneira com que o usuário se
comunica com a aplicação, podendo esta comunicação ocorrer através de dispositivos ou de
forma simbólica.
Segundo Bowman [9], “interação é um método que permite a um usuário realizar uma
tarefa através da interface do usuário. Uma técnica de interação inclui tanto componentes de
hardware (dispositivos de entrada/saída) quanto de software. As técnicas de interação
utilizadas nos componentes de software são responsáveis por mapear a informação de um
dispositivo de entrada em alguma ação dentro do sistema, e por mapear a saída do sistema de
forma que esta possa ser interpretada pelos dispositivos de saída”.
VR requer técnicas especiais de interação que lidam com o espaço tridimensional
(3D). A interação pode ocorrer no sentido usuário-aplicação ou no sentido aplicação-usuário.
Como exemplos desta última, cenários virtuais utilizados em VR podem dar retorno ao
usuário através de dispositivos chamados “hápticos”. Neste caso, o usuário recebe o retorno
do mundo virtual e pode reagir de forma diferente dependendo dos estímulos providos pela
VR.
Em VR, a interação pode ser subdividida em quatro tipos principais de tarefas:
•
Manipulação e seleção: são técnicas utilizadas para mover, transladando ou
rotacionando, e selecionar objetos virtuais da cena;
•
Navegação: agrupa as técnicas utilizadas para movimentação dentro do
ambiente virtual;
•
Controle de sistemas: são as técnicas que permitem enviar comandos ao
17
REALIDADE AUMENTADA
sistema, como por exemplo, menus;
•
Entrada simbólica: fazem parte deste grupo as técnicas que permitem
manipulação de entrada através de fala, gestos ou quaisquer outros símbolos.
Em AR não existe um padrão de taxonomia para técnicas de interação. Isto se dá pelo
fato de grande parte das técnicas de VR serem adaptáveis para as aplicações de AR. Desta
forma, pode-se utilizar os mesmos conceitos de manipulação, seleção, entre outros descritos
anteriormente.
No decorrer deste trabalho serão descritas algumas técnicas de interação para realizar
tarefas nos serviços implementados no A2. Apesar do A2 ter sido concebido e implementado
segundo os conceitos de AR, as técnicas de interação utilizadas são todas aplicadas em VR e
foram adaptadas para AR. Estas técnicas serão detalhadas no Capítulo 5, durante a descrição
dos serviços.
2.5 DISPOSITIVOS DE INTERAÇÃO
Nesta seção serão mostrados os diversos dispositivos usados para interagir em AR. Dentre
esses serão abordados os mais comuns (luvas e trackers) até os dispositivos móveis como
celulares e PDAs.
2.5.1 DISPOSITIVOS DE INTERAÇÃO EM REALIDADE VIRTUAL
Em VR, os dispositivos de interação são projetados de forma que aumentem
consideravelmente a imersão do usuário. Fazem parte deste grupo de dispositivos as luvas
(para manipulação de objetos virtuais), apontadores, rastreadores de movimento, etc. Estes
dispositivos podem, além de fornecer entrada para a aplicação, fornecer um retorno (táctil, de
força) ao usuário. Caso isto ocorra, estes são chamados dispositivos hápticos.
As luvas (data gloves), vide Figura 2.6, são equipadas com sensores que percebem os
movimentos da mão e fazem a interface desses movimentos com o computador, fazendo com
que o usuário possa manipular objetos e/ou realizar movimentos em um ambiente virtual.
Com as luvas, o usuário pode fazer gestos, segurar objetos virtuais e manipulá-los,
transmitindo os movimentos da mão para o computador através dos sensores presentes em
cada dedo. Caso a luva seja háptica, o computador também pode repassar ao usuário a
sensação de toque proporcionado pelos objetos virtuais segurados pelo avatar do usuário,
oferecendo assim, uma maior imersão.
18
REALIDADE AUMENTADA
Figura 2.6. Tipos de luvas [11], [12].
Em aplicações de VR também são utilizados rastreadores (trackers), que podem
captar alterações em sua posição e/ou orientação. Estes servem para a captura do
posicionamento das mãos, rotação da cabeça (caso a câmera para captura do mundo real
esteja explicitamente ligada à visão do usuário) ou até a captura de movimentos para a
animação de personagens. Um exemplo de tracker pode ser visto na Figura 2.7.
Figura 2.7. Tracker.
2.5.2 DISPOSITIVOS MÓVEIS
AR possibilita que o usuário possa ter contato com elementos virtuais enquanto continua
imerso no mundo real. A mobilidade faz parte do conjunto de tarefas de interação que o
indivíduo realiza no mundo real, o que significa que esta tarefa não deve ser subtraída
quando o contexto é o de ambientes de AR. Desta forma, vários dispositivos foram adaptados
para compor sistemas de AR, que podem utilizar notebooks, juntamente com HMDs, ou
dispositivos de pequeno porte, como celulares e PDAs.
Quando mencionam-se notebooks, deve-se agregar a eles equipamentos como
câmeras, trackers, luvas e HMDs, para que eles possam ser utilizados para executar
aplicações de AR. Para que estes se tornem móveis, esses elementos devem ser conectados e
19
REALIDADE AUMENTADA
carregados de forma confortável para o usuário. A este conjunto de equipamentos de
hardware dá-se o nome de “wearable computer”.
Uma alternativa ao uso dos wearable computers é a utilização de dispositivos
menores. Nesta categoria se encontram os celulares e PDAs. Estes devem ser equipados com
câmeras e ter um poder de processamento que atenda aos requisitos das aplicações de AR, já
que neste tipo de aplicação o hardware é bastante exigido no processamento de imagens. A
grande desvantagem destes dispositivos é que à medida que eles avançam, eles são
miniaturizados, diminuindo o espaço para visualização das aplicações, o que torna a
experiência do usuário mais pobre e menos imersiva. A interação com dispositivos menores
se dá normalmente através de uma tela sensível ao toque, ou através do próprio teclado, no
caso do celular. Estes dispositivos estão ilustrados na Figura 2.8.
Figura 2.8. Wearable computer tradicional para AR móvel (esquerda) e PDA (direita) [13].
2.6 ÁREAS DE APLICAÇÃO
Nesta seção serão mostradas algumas áreas de aplicação nas quais AR tem se destacado. As
aplicações em AR são inúmeras e abrangem diversas áreas, desde aplicações em
entretenimento, passando por aplicações médicas e, mais recentemente aplicações móveis e
comerciais.
2.6.1 ÁREAS DE APLICAÇÃO TRADICIONAIS
As áreas de aplicação tradicionais no uso de AR são as seguintes: medicina, manutenção,
visualização e explicação (anotação), entretenimento e planejamento urbano.
Na medicina, os médicos podem usar a tecnologia de AR para a visualização de
cirurgias, por exemplo. Com o conjunto dos dados coletados através de sensores nãoinvasivos, esses dados podem ser renderizados e combinados em tempo real com a imagem
real do paciente, dando ao médico uma espécie de visão de raio-X dos órgãos do paciente,
resultando com isso em uma visão interna sem a necessidade de grandes incisões [14] (vide
20
REALIDADE AUMENTADA
Figura 2.9).
Figura 2.9. Imagem sobreposta ao paciente [15].
A utilização de AR na área de manutenção facilita o entendimento das instruções
sobre o procedimento a ser realizado, ao invés da leitura de manuais e da observação de
figuras. Em contraponto a isto, são exibidos objetos 3D que se sobrepõem a um equipamento
qualquer mostrando passo a passo às tarefas que devem ser feitas e como fazê-las. Estes
objetos podem, ainda, ser animados para que as instruções sejam mostradas de uma maneira
mais explícita.
AR, também pode ser utilizada para inserir elementos virtuais a fim de ajudar na
localização e na navegação em ambientes desconhecidos, a partir de marcadores que
mostram informações armazenadas em bases de dados remotas [16].
Muitas aplicações podem ser encontradas também na área de entretenimento. Nesta
tem-se uma infinidade de jogos que utilizam sobreposição do mundo real com informações
virtuais. Um exemplo disto é o ARQuake [17], que possui uma estrutura parecida com o
Quake, um “First Person Shooter” (FPS) onde o jogador tem que atirar em inimigos que
surgem pelo caminho. No ARQuake os inimigos aparecem no mundo real enquanto o jogador
se desloca, como visto na Figura 2.10.
21
REALIDADE AUMENTADA
Figura 2.10. Visão do usuário jogando ARQuake [17].
Outros tipos de aplicações podem ser construídas utilizando os conceitos de AR,
principalmente na área de planejamento urbano. Aplicações nesta área podem utilizar-se de
AR, deixando a visualização e a simulação de ambientes por conta de modelos virtuais, que
podem ser facilmente manipulados e inseridos no mundo real, para que várias pessoas
possam interagir com o mesmo modelo ao mesmo tempo. Uma aplicação que possui estas
características é a Urp [18], que simula prédios e ventos em um ambiente virtual.
Figura 2.11. Workspace para planejamento urbano [19].
2.6.2 SISTEMAS MÓVEIS DE REALIDADE AUMENTADA
Entre as pesquisas que usam AR móvel merece destaque o trabalho [20], por ter
desenvolvido vários serviços/aplicações em um único projeto. Como descrito no Capítulo 1,
alguns serviços foram implementados no projeto, e existem experiências relevantes com
relação a eles. Em [21], existe um enfoque no uso de teleconferência baseada em AR, e o
trabalho discute a tecnologia usada para desenvolver esse sistema, assim como os objetivos
alcançados. Além disso, é apresentado o uso do ARToolKit neste tipo de pesquisa, abordando
o projeto 3D Live e explorando o conceito de colaboração em AR.
22
REALIDADE AUMENTADA
Outro trabalho em teleconferência baseado em AR é o [22], onde são usados alguns
marcadores para interagir com a aplicação, manipulando a posição e a orientação de objetos
virtuais e permitindo ao usuário uma visão ampla deles. Em [23], a captura do movimento de
um telefone celular, através da câmera, é usado para interagir com a aplicação.
Uma experiência real em que o usuário joga achando padrões que contêm planetas do
sistema solar pode ser encontrada em [24]. Quando o marcador é posicionado corretamente,
novas informações sobre os planetas são exibidas para o jogador.
2.6.3 REALIDADE AUMENTADA COM DISPOSITIVOS MÓVEIS
Sistemas de AR baseados em PDAs podem ser divididos em duas categorias principais:
sistemas distribuídos e sistemas standalone.
Em sistemas distribuídos, parte das tarefas necessárias para aumentar o ambiente é
executada por um servidor, que troca dados com os dispositivos através de uma rede sem fio.
Um exemplo disto é detalhado em [27], onde a detecção de marcadores fiduciais na imagem
capturada e a renderização de objetos 3D são feitas por um laptop, e o PDA é responsável
somente por capturar a imagem da câmera e desenhar o resultado final na tela. O servidor
normalmente tem um grande poder de processamento, assim como uma placa de vídeo com
aceleração gráfica em hardware (GPU – Graphics Processing Unit). Contudo, cada frame
capturado pelo dispositivo móvel é transferido para o servidor e os resultados são então
processados e enviados de volta para o PDA, causando um atraso que diminui a taxa de
renderização de quadros por segundo das aplicações. Outro problema está relacionado à
necessidade da presença de um servidor, que dificulta a mobilidade da solução.
Sistemas standalone não dependem de servidores para a geração da saída de AR.
Estes implementam, na própria aplicação, todos os requisitos e procedimentos para a
execução de tarefas de AR [28]. Este fator provê o desenvolvimento de soluções de AR
totalmente móveis. De outro lado, o baixo poder de processamento e a ausência de uma GPU
são características comuns de um PDA, o que implica na criação de aplicações que não devem
possuir um alto grau de complexidade, tanto no processamento, quanto na visualização.
2.7 CONSIDERAÇÕES FINAIS
Este capítulo apresentou uma breve descrição de alguns conceitos de AR. Foram detalhados
alguns tipos de dispositivos utilizados em aplicações de AR/VR, bem como algumas formas
de interação. Também foram descritas algumas áreas de aplicação de AR, dividindo-as em
áreas tradicionais e consolidando os conceitos de AR móvel, através de sistemas complexos
ou que utilizem dispositivos móveis.
A partir desses conceitos explicitados ao longo deste capítulo, pode-se construir um
23
REALIDADE AUMENTADA
maior embasamento para o projeto A2, principalmente através de várias características que já
foram introduzidas sobre o projeto quando comparadas com as aplicações existentes,
destaca-se que o A2 tem como um dos seus pilares a AR.
24
DESENVOLVIMENTO MULTIPLATAFORMA DE APLICAÇÕES DE REALIDADE VIRTUAL E REALIDADE AUMENTADA
CAPÍTULO 3
DESENVOLVIMENTO MULTIPLATAFORMA DE
APLICAÇÕES DE REALIDADE VIRTUAL E REALIDADE
AUMENTADA
3.1 INTRODUÇÃO
O desenvolvimento de aplicações de AR surgiu através de bibliotecas e ferramentas
direcionadas à plataforma desktop, tendo implementações específicas para os sistemas
operacionais Windows e Linux.
Devido à necessidade das aplicações terem maior mobilidade, houve um esforço para
que as bibliotecas de AR fossem portadas para plataformas móveis como Windows Mobile
(Pocket PC) e Symbian OS. Aplicações deste porte exigem um maior poder de processamento,
o que impulsiona a indústria a produzir dispositivos móveis cada vez mais rápidos e
adaptados à construção de aplicações com interação através de AR/VR. A mais recente
evolução se deu pela adição de aceleração gráfica nas plataformas Pocket PC e Symbian OS,
tendo como exemplos o Dell Axim x51 [29] e o Nokia N93 [30], que já possuem esta
característica e utilizam respectivamente o DirectX Mobile e o OpenGL ES para prover
comunicação entre o hardware acelerador e a aplicação.
Na seqüência, as Seções 3.2, 3.3 e 3.4 apresentam a situação atual e a experiência do
autor no desenvolvimento de aplicações para desktop, para Pocket PC e para Symbian OS,
respectivamente.
3.2 DESENVOLVIMENTO NA PLATAFORMA DESKTOP
Ao se criar aplicações de AR para desktops é possível aproveitar o grande poder de
processamento das máquinas atuais para criar aplicações mais sofisticadas e realistas.
Posicionar corretamente objetos virtuais em uma cena real é um requisito
imprescindível em aplicações de AR. O posicionamento incorreto é conhecido como erro de
registro (Registration Error) e tem demandado bastante estudo na área. Existem técnicas
que utilizam marcadores ou LEDs (Light Emitting Diode) para rastrear a posição da câmera
no mundo real e inserir os objetos virtuais no local correto da cena real. Estas técnicas
calculam rápida e corretamente a posição em que deve ser inserido o objeto virtual, mas têm
como problema a necessidade do uso destes marcadores ou LEDs na cena real, o que pode ser
25
inconveniente ou até mesmo impossível de ser utilizado em algumas situações [32]. Mais
recentemente, outras técnicas reconhecem objetos na cena real através de modelos 3D desses
objetos previamente conhecidos, como em [32], o que supre a necessidade dos marcadores
físicos (Figura 3.1).
Figura 3.1. Reconhecimento da face para posicionar óculos virtual.
As aplicações de AR para desktop podem utilizar diversos dispositivos de saída para a
exibição da cena real misturada com a cena virtual. São eles: HMDs see-through, HMDs
video-see-through e monitor convencional, como vistos na Seção 2.3, e projetores que
utilizam os objetos do mundo real como superfícies de projeção da cena virtual (Figura 3.2)
[33].
Figura 3.2. Projeção da cena virtual sobre o objeto real 3D.
Os laptops atuais possuem poder de processamento similar aos desktops, e quando
utilizados em conjunto com uma câmera e um capacete de VR podem oferecer ao usuário
mobilidade, como pode ser visto no projeto ARQuake [34] onde o jogador utiliza o ambiente
real como cenário para enfrentar os oponentes do jogo. A Figura 3.3 mostra os equipamentos
do Wearable Computer utilizado para jogar o ARQuake.
26
Figura 3.3. Wearable Computer.
Um outro exemplo de wearable computer é o utilizado no estudo de caso do projeto
A2, denominado miva e desenvolvido pelo Grupo de Pesquisa em Realidade Virtual e
Multimídia do Centro de Informática da UFPE, que pode ser visto na Figura 3.4.
Figura 3.4. Usuário vestindo a plataforma miva.
3.2.1 INTERAÇÃO COM DISPOSITIVOS/AMBIENTE
Aplicações de AR, além da interação clássica com marcadores, podem fazer uso de diversos
tipos de dispositivos de entrada. Estes últimos são utilizados para interagir com elementos
virtuais da cena, já que os marcadores oferecem limitações de interação que podem ser
supridas com a utilização de dispositivos como teclados, mouses ou joysticks.
À medida que são introduzidas formas de interação alternativas e mais modernas,
algumas mudanças na estrutura do programa original se tornam necessárias para permitir a
interação com o novo dispositivo, a não ser que este seja equivalente a algum utilizado
previamente. Tendo em vista que nem todos os dispositivos são similares e que geram
eventos de diferentes formas, o desenvolvedor normalmente precisa reescrever ou
complementar sua aplicação com um novo módulo de interação específico para o dispositivo
introduzido. Este processo deve ser repetido para cada dispositivo novo que a aplicação
deseje suportar.
27
O problema da introdução de novos dispositivos para controlar aplicações já
desenvolvidas pode ser resolvido através da utilização de uma plataforma de abstração de
dispositivos de entrada. Desta forma o mesmo programa pode receber ações de controle tanto
de um mouse quanto de uma luva, ou de um dispositivo de interação qualquer, sem que seja
necessária qualquer mudança em seu código fonte ou até mesmo uma recompilação.
Além da facilidade da adição de dispositivos, o uso da plataforma de abstração de
dispositivos oferece ainda o conceito de portabilidade. Isso significa que a aplicação tem a
capacidade de se adaptar a vários métodos de interação distintos, sem a necessidade de
qualquer mudança no código. Desta maneira, uma aplicação projetada para um ambiente
sofisticado, que faz uso de trackers, luvas e joysticks também funcionaria em um computador
que possuísse apenas um mouse, teclado ou outro dispositivo padrão, por exemplo. Isso pode
ser obtido através da identificação de perfis de interação, que possuem informações sobre os
dispositivos virtuais que a aplicação requisita e o mapeamento destes em dispositivos reais.
Este mapeamento permite que um mouse, por exemplo, assuma funções antes
desempenhadas por um tracker.
3.2.1.1 CIDA
CIDA (Chaotic Interaction Devices Abstraction) é uma plataforma de gerenciamento de
dispositivos de entrada desenvolvida pelo autor que tem como principal característica
fornecer uma camada de abstração entre sistemas interativos e os dispositivos de interação
[35]. A partir desta plataforma, podem ser disponibilizados para a aplicação, em tempo de
execução, todos os dispositivos que possuem as características necessárias para interagir com
a mesma, como botões, eixos, graus de liberdade, entre outros.
Em CIDA os dispositivos de entrada são agrupados em quatro classes distintas, de
acordo com as suas características funcionais: Keyboard, Joystick, Tracker e Pointer Device.
Para que novos dispositivos de entrada sejam suportados é necessário implementar plugins
específicos, os quais determinam as características de cada classe oferecidas pelo dispositivo.
Desta forma, a adição de novos dispositivos de interação a sistemas baseados na plataforma
torna-se bastante simples, pois o código fonte da aplicação não precisa ser modificado. Além
disso, um mesmo dispositivo pode ser enxergado de formas diferentes dependendo da
aplicação, uma vez que as suas capacidades estão especificadas em cada plugin. Como
exemplo, um teclado convencional poderia ser reconhecido pela aplicação como um
dispositivo da classe Keyboard ou como dois dispositivos da classe Joystick, dependendo da
implementação do plugin utilizado. Este exemplo é melhor ilustrado pela Figura 3.5.
28
Figura 3.5. Teclado interpretado como dois joysticks.
CIDA também dispõe de transparência de conectividade, pois os dispositivos podem
estar conectados a partir de computadores diferentes, e não diretamente acessados pelo PC
que executa a aplicação, como no caso de uso padrão. Isto pode ser feito através da
plataforma sem que o código fonte precise ser modificado ou recompilado. Em ambientes
complexos de VR essa característica é bastante útil, pois facilita consideravelmente o
gerenciamento de dispositivos de entrada, considerando que pode ser necessário o uso de
vários computadores para garantir o processamento em tempo real dos dados de entrada.
Uma das características de CIDA é que o desenvolvedor não precisa se preocupar com o uso
de device drivers específicos para determinados periféricos, pois a plataforma oferece à
aplicação uma visão uniforme das capacidades de cada dispositivo.
3.2.2 FERRAMENTAS
Como ferramentas para construção de aplicações de AR, podem ser utilizadas bibliotecas já
consolidadas de acesso direto ao pipeline gráfico, como OpenGL, a engines de renderização
que podem explorar abstrações de APIs gráficas, entre eles o OGRE. Para a manipulação de
marcadores e gerenciamento de posições e orientações, pode-se incluir também neste
ferramental o ARToolKit. Existe também uma versão do mesmo integrado com o engine
gráfico OGRE, chamada OgreAR. Estas ferramentas serão detalhadas nas seções a seguir.
3.2.2.1 OPENGL
O OpenGL é uma API (Application Programming Interface) para desenvolvimento de
aplicações gráficas que provê um conjunto de primitivas de renderização eficientes e
portáveis [36]. Existem implementações de OpenGL para as mais diversas plataformas, que
englobam suporte gráfico 2D e 3D e muitos efeitos que podem ser associados a estes gráficos.
OpenGL é implementada na linguagem C, e tem porte para várias linguagens existentes.
3.2.2.2 OGRE
O OGRE (Object-oriented Graphics Rendering Engine) é um engine gráfico de código aberto
29
que permite a criação de aplicações 3D renderizadas em tempo real [37]. A versão oficial
divulgada na página do OGRE oferece suporte para muitos sistemas operacionais, como
Windows, Linux e Mac OS. Além da versão oficial, existem projetos paralelos que dedicam
esforços para portar o OGRE para as mais diversas plataformas, incluindo FreeBSD e até
consoles de jogos como Xbox, Playstation, Playstation 2 e Dreamcast.
Existem algumas características presentes no OGRE que podem ser consideradas as
principais razões para sua larga utilização. Uma delas é o paradigma orientado a objetos, que
contribui para um desenvolvimento mais dinâmico e estruturado das aplicações 3D.
O OGRE é constituído de classes que se relacionam através de interfaces bem
definidas, e isto favorece a criação de um modelo de biblioteca de alto nível, por oferecer um
nível de abstração maior para o usuário. Não há dependências entre os módulos de
renderização nativa (OpenGL e DirectX) e as aplicações finais, permitindo uma maior
flexibilidade no uso destes módulos, e fortalecendo também a característica de independência
de plataforma, pois através de plugins, um novo módulo de renderização pode ser
implementado e anexado na aplicação sem nenhuma mudança no código fonte desta. Desta
forma, é possível portar o OGRE, e aplicações baseadas nele, para uma vasta gama de
ambientes.
O OGRE foi concebido para ser um engine gráfico flexível capaz de interagir com
ferramentas externas como engines de física e de inteligência artificial. Outra vantagem do
OGRE é a utilização de scripts escritos em formato texto que contêm as configurações da
aplicação. A partir destes scripts, o usuário pode modificar configurações como texturas de
objetos, materiais utilizados e até o modo de renderização dos shaders [38], sem a
necessidade de recompilar o programa.
Ao se utilizar no OGRE o CEGUI (Crazy Eddie's GUI System), que é uma biblioteca
que provê a construção de janelas e componentes gráficos, o desenvolvedor não perde tempo
em implementar um subsistema para criar uma interface com o usuário, agilizando o
desenvolvimento da aplicação final.
Outra vantagem da utilização do OGRE como plataforma de desenvolvimento de
aplicações gráficas é a fácil integração com ferramentas de modelagem 3D, que acelera a
criação de cenários e malhas exibidos pelo programa. Dentre as ferramentas que podem
exportar recursos utilizados pelo OGRE estão o 3D Studio MAX, Blender, Maya,
MilkShape3D, Wings3D e SOFTIMAGE|XSI. Juntamente com as malhas produzidas pela
ferramenta de modelagem, podem ser também exportados quaisquer tipos de animações
baseadas em bones (Skeletal Animations) e materiais utilizados nos modelos. Para conseguir
essa integração, a plataforma utiliza plugins de exportação especializados para cada
ferramenta de modelagem citada. Os plugins geram um formato intermediário descrito em
30
XML, que posteriormente é transformado no formato proprietário do OGRE.
3.2.2.3 ARTOOLKIT
O ARToolkit é uma biblioteca criada para dar suporte ao reconhecimento de padrões em
imagens, um dos passos do pipeline de AR. Maiores detalhes sobre o pipeline de AR em [39].
Ele é utilizado amplamente em aplicações de AR e possui componentes para criação de
marcadores, captura de vídeo, detecção de padrões e renderização de objetos.
Os padrões detectados pelo ARToolKit são marcadores fiduciais, compostos por um
quadrado de borda preta com algum símbolo na parte interna, como ilustrado na Figura 3.6.
Figura 3.6. Marcador fiducial utilizado pelo ARToolKit.
Além disso, os marcadores devem ser planos e monocromáticos para que sejam
detectados pela biblioteca. No momento em que um destes marcadores é identificado são
extraídas algumas de suas características (como orientação e posição em relação à câmera)
para que possam ser utilizadas nas aplicações. É oferecido um suporte adicional para
aplicações que sobrepõem os marcadores com objetos virtuais, através de um wrapper para a
biblioteca OpenGL, e do suporte à visualização de objetos em VRML (Virtual Reality
Modeling Language).
O ARToolkit é uma biblioteca portável que funciona tanto no Windows quanto em
algumas implementações do UNIX, o que torna mais flexível a escolha do sistema
operacional por parte do usuário.
3.2.2.4 OGREAR
A biblioteca OgreAR é uma das contribuições deste trabalho e foi desenvolvida para prover
uma interconexão entre aplicações baseadas no engine OGRE e elementos de AR, como
aquisição de vídeo em tempo real e detecção de marcadores [40]. Esta biblioteca oferece uma
interface para a utilização de recursos necessários às aplicações de AR, explorando as
31
vantagens de um componente de abstração de alto nível, tais como: facilidade de uso, rapidez
no desenvolvimento e aumento da legibilidade do código. O OgreAR também foi projetado
para deixar as aplicações portáveis, pois ele não depende das bibliotecas utilizadas para
prover as funcionalidades de AR.
A Figura 3.7 ilustra a arquitetura da biblioteca e a interface entre seus componentes. A
detecção de padrões no OgreAR é independente de biblioteca de detecção de marcadores
(ARToolkit, ARToolKitPlus, MXRToolkit, etc.), devido à criação de um nível de abstração na
detecção de marcadores a partir da interface PatternDetector que o usuário pode
implementar baseado em qualquer técnica de reconhecimento de padrões, desde que este
esteja encapsulado em uma classe que derive desta interface. A biblioteca possui uma
implementação padrão para detecção de marcadores baseados em templates (utilizando
ARToolKit, com o ARToolkitAdapter) e de marcadores baseados em identificadores
(utilizando
ARToolKitPlus,
com
o
ARToolkitPlusAdapter).
Além
destes
PatternDetectors, a biblioteca possui ainda um detector de padrões nulo, que é útil para
testes somente com captura de câmera sem detecção de padrões.
A captura de imagens também é abstraída pela interface FrameGrabber, que pode
ser implementada através de qualquer biblioteca de acesso a câmeras, como a DSVideoLib ou
o próprio SDK (Software Development Kit) da câmera em questão.
Figura 3.7. Arquitetura do OgreAR.
Um FrameListener, que é um elemento básico das aplicações baseadas no OGRE,
faz a captura e a exibição das imagens sem a intervenção do usuário, e pode ser ativado
apenas adicionando o ARFrameListener na aplicação. O ARFrameListener deve ser
32
associado a um PatternDetector, que pode ser modificado pelo usuário em qualquer
ponto da execução do programa.
A detecção de padrões do OgreAR é baseada em eventos, da mesma forma que o
sistema de interação do OGRE. Para que seja possível receber estes eventos e manipular os
dados provenientes dos marcadores, o usuário deve implementar uma interface chamada
DetectionListener. Ela tem apenas um método (itemDetected) que usa como
parâmetro um componente do tipo AREvent. Este serve para agregar características como
posição, orientação e informações de identificação dos marcadores detectados.
3.3 DESENVOLVIMENTO NA PLATAFORMA POCKET PC
O desenvolvimento de aplicações de AR para dispositivos embarcados vem despertando
bastante interesse, devido ao aumento da capacidade de processamento dos handhelds e
smartphones lançados no mercado nos últimos anos, aliado ao fato de tais dispositivos serem
compactos e móveis. Estas características fazem com que novas modalidades de aplicações de
AR possam ser exploradas, aproveitando as vantagens oferecidas por tais sistemas.
A plataforma Pocket PC vem sendo alvo de algumas experiências em AR. O ARToolKit
foi portado para funcionar nesta plataforma e algumas otimizações foram implementadas
para que a taxa de quadros fosse a maior possível [41]. Foi criada uma nova biblioteca, o
ARToolKitPlus, baseada no ARToolKit, para melhor explorar os recursos oferecidos pelo
Pocket PC [42]. Na Figura 3.8 são mostradas algumas aplicações que foram construídas
utilizando o ARToolKitPlus.
Figura 3.8. Aplicações de AR usando o ARToolKitPlus.
Com relação a bibliotecas de renderização 3D para a plataforma Pocket PC, a mais
popular para essa finalidade é o OpenGL ES, uma versão limitada do OpenGL direcionada
para sistemas embarcados [43], [44]. Existem basicamente duas versões sendo desenvolvidas
em paralelo: a versão 1.x, projetada para trabalhar com hardwares de função fixa, e a versão
2.x, especificada para hardwares programáveis. Entretanto, a maioria dos sistemas
operacionais não possui uma API de OpenGL ES que explore aceleração 3D feita por
hardware. Espera-se que esta situação mude com o lançamento de vários dispositivos móveis
33
com GPU integrada. Tanto OpenGL quanto OpenGL ES provêem uma programação de baixo
nível, o que diminui a produtividade do desenvolvedor.
Outra solução gráfica 3D bastante usada por desenvolvedores para dispositivos
móveis é o Klimt, que se propõe a prover uma interface similar a de OpenGL, cobrindo
algumas das funcionalidades não suportadas por OpenGL ES [45]. O Klimt também contém
algumas otimizações para os sistemas Pocket PC. A versão disponível é de código aberto e usa
um mecanismo de renderização próprio. Devido à similaridade com OpenGL, o nível de
programação é também muito baixo.
Especificamente para a plataforma Pocket PC, o sistema operacional Windows
Mobile 5.0 suporta Direct3D Mobile, que é baseado no Direct3D 8 para desktops [46].
Quando combinado com o .NET Compact Framework, pode ser utilizado em modo
gerenciado, provendo um desenvolvimento seguro e fácil. Por outro lado, o nível de abstração
é quase o mesmo de OpenGL e OpenGL ES.
Em relação ao desenvolvimento em Java, existe uma API para renderização 3D
chamada M3G (Mobile 3D Graphics API for J2ME) [47]. Ela é uma biblioteca gerenciada
orientada a objetos que possui dois modos de operação diferentes: o immediate mode, que
usa acesso de baixo nível semelhante ao de OpenGL e OpenGL ES, e o retained mode, que
usa um grafo de cena, uma estrutura de mais alto nível para renderização 3D que também é
utilizada no OGRE, tornando o processo de codificação muito mais intuitivo. A desvantagem
das aplicações Java é o baixo desempenho, que causa uma queda na taxa de quadros.
A existência de um engine gráfico aberto de alto nível para a plataforma Pocket PC
seria extremamente útil para a criação de aplicações de AR. Devido a isso, como contribuição
deste trabalho, foi portada a biblioteca gráfica OGRE para o sistema operacional embarcado
em questão, a qual é apresentada na próxima subseção.
3.3.1 OGRE NO POCKET PC
Com as diversas vantagens de implementação para Pocket PC usando o OGRE, uma versão
foi portada para essa plataforma como contribuição deste trabalho [48]. A versão do OGRE
portada foi baseada na 1.1.0 alpha (Dagon) do código fonte oficial do OGRE. A ferramenta de
desenvolvimento utilizada para o projeto foi o Microsoft Visual Studio .NET 2005
Professional Edition IDE (versão 8.0.50727.42 RTM.050727-4200).
A primeira tarefa realizada para disponibilizar o OGRE para a plataforma Pocket PC
foi portar todas as dependências do OGRE que não possuíam uma versão funcional para a
mesma, e estender algumas bibliotecas que suportavam o sistema operacional para fornecer
as funcionalidades necessárias, como, por exemplo, uma manipulação de arquivos mais
completa. Estas dependências são bibliotecas utilizadas pelo engine para tarefas específicas,
34
tais como carregamento de texturas e gerenciamento de arquivos. O segundo passo consistiu
em implementar um RenderSystem usando uma API gráfica disponível para Pocket PC,
neste caso OpenGL ES. Após isso, um PlatformManager para o sistema operacional teve
que ser escrito.
Com o objetivo de almejar melhor desempenho, o OGRE foi adaptado para trabalhar
com rotinas matemáticas de ponto fixo, visto que os dispositivos móveis não possuem uma
FPU (Floating Point Unit) e todas as operações matemáticas baseadas em hardware são
realizadas usando ponto fixo. Finalmente, foi implementado outro RenderSystem usando o
Klimt, numa tentativa de obter uma taxa de quadros maior.
A Figura 3.9 ilustra alguns screenshots das aplicações de exemplo SkyBox e
SkeletalAnimation, que fazem parte da distribuição oficial do OGRE, rodando no Pocket PC.
Os exemplos usaram as implementações do RenderSystem baseadas no OpenGL ES e no
Klimt.
O benchmark da biblioteca foi feito usando o demo SkeletalAnimation. As taxas de
quadros obtidas no Pocket PC foram comparadas com o desempenho da versão desktop. Os
valores foram obtidos de cenas com um número variado de triângulos, e diferentes versões do
RenderSystem foram utilizadas (OpenGL e Klimt no desktop, OpenGL ES e Klimt no
dispositivo móvel).
A taxa de quadros do demo usando OpenGL ES no Pocket PC variou entre 1,0 e 2,8 fps
(frames por segundo), o que é muito baixo para uma aplicação gráfica 3D em tempo real. A
principal razão para este resultado fraco é o fato que a renderização da biblioteca disponível
para a plataforma Pocket PC é emulada por software, enquanto que no desktop a GPU é
usada. O resultado obtido usando o RenderSystem baseado no Klimt, que variou entre 6,5 e
13,4 fps, é bem melhor que o do OpenGL ES, devido a otimizações presentes na biblioteca
gráfica. Entretanto, deixa muito a desejar quando comparada com a taxa de quadros obtida
nas configurações desktop, que variou entre 239,0 e 265,8 fps utilizando o RenderSystem
baseado em OpenGL e entre 81,5 e 195,8 fps utilizando o RenderSystem baseado no Klimt.
35
A
b
c
Figura 3.9. Screenshots de demos do OGRE no Pocket PC: a) SkeletalAnimation usando o
RenderSystem baseado em OpenGL ES; b) SkyBox usando o RenderSystem baseado em OpenGL
ES; c) SkeletalAnimation usando o RenderSystem baseado no Klimt.
A baixa resolução da tela do dispositivo causou um pouco de aliasing nos objetos
renderizados, embora seu aspecto tenha permanecido bastante aceitável.
Finalmente, existem algumas funcionalidades da versão desktop do OGRE ausentes
no ambiente Pocket PC, como overlays, que deveriam ser desenhados sobre a imagem
trazendo informações sobre a cena renderizada, como o número de polígonos renderizados, a
taxa de quadros, entre outras.
3.3.2 OPENGL ES
O OpenGL ES é uma API completa para renderização de gráficos 2D e 3D para sistemas
embarcados, incluindo consoles de jogos, celulares, dispositivos e veículos. Ele consiste de
um subconjunto bem definido do OpenGL, criando uma interface de baixo nível poderosa e
flexível entre aplicações e hardwares de aceleração gráfica. Foi escolhida por ser royalty-free
e possuir implementações diversas em muitas plataformas.
O OpenGL ES também inclui perfis para matemática de ponto flutuante e de ponto
fixo, além do EGL [49], que é uma especificação para escrever programas portáveis que
utilizem sistemas com janelas.
As versões 1.X do OpenGL ES funcionam com hardwares que fornecem um pipeline
gráfico fixo, suficiente na maioria dos casos. Já as versões 2.X habilitam gráficos 3D
totalmente programáveis através de shaders e outras técnicas disponibilizadas pelo
hardware.
36
3.3.3 ARTOOLKITPLUS
O ARToolKitPlus foi desenvolvido na Universidade de Tecnologia de Graz, na Áustria, e é
uma biblioteca de AR open source baseada no ARToolKit, que é descrito em [42]. Ele trata
exclusivamente de detecção de marcadores, sem oferecer funções de captura de vídeo ou
renderização de objetos 3D. Seu código fonte sofreu várias otimizações, como por exemplo,
utilização de aritmética de ponto fixo, com a intenção de gerar aplicações eficientes para
dispositivos móveis, que não possuem co-processadores de matemática de ponto flutuante.
Os marcadores utilizados nesta biblioteca são similares aos do ARToolKit (com bordas
quadradas e pretas), com a diferença que a parte interna do padrão é um identificador
codificado, como mostrado na Figura 3.6.
Esta codificação permite que o desenvolvedor utilize até 4096 marcadores diferentes.
Além do mais, reduz os problemas de detecção de marcadores. O ARToolKitPlus usa uma
técnica de threshold adaptativo, que consiste em perceber a alteração na iluminação do
ambiente capturado pela câmera, de uma forma que a detecção de marcadores não seja
afetada. Esta biblioteca oferece aos desenvolvedores a possibilidade de usar marcadores com
uma largura de borda variável. Desta maneira, a largura da borda pode diminuir, para dar
mais espaço para a codificação do identificador, de forma que marcadores pequenos possam
ser identificados. Outra característica é a capacidade de realizar compensação em imagens de
câmeras que geram uma degradação radial de luminância. Este fato ocorre em algumas
câmeras, onde imagens capturadas aparecem mais escuras na região das bordas, impedindo a
detecção de marcadores localizados nestas áreas.
3.4 DESENVOLVIMENTO NA PLATAFORMA SYMBIAN OS
Os dispositivos móveis vêm se popularizando muito nos últimos tempos, com o avanço tanto
do hardware que os compõe quanto das APIs desenvolvidas para utilizar este hardware.
Existe atualmente uma quantidade cada vez maior de aplicações nas mais diversas áreas para
estes tipos de dispositivos. No entanto, há áreas que ainda não foram amplamente
exploradas, como a área de AR. Até pouco tempo atrás, não havia hardware que
possibilitasse qualquer aplicação relacionada a essa área. Depois que o hardware passou a
existir, ainda faltava software para tornar as aplicações possíveis.
Recentemente, algumas aplicações muito importantes vêm sendo desenvolvidas e
apresentando bons resultados, possibilitando os primeiros passos da AR no mundo móvel.
O ARToolKit foi portado para funcionar nesta plataforma, porém o código fonte ainda
não foi disponibilizado na Internet [50].
A API do telefone foi utilizada para construir a interface do usuário, controlar o fluxo
37
de dados do programa e acessar a câmera. O porte do ARToolKit para Symbian OS foi
utilizado como base para a aplicação sendo desenvolvida neste trabalho [50]. O OpenGL ES
foi utilizado para realizar a renderização dos elementos 3D que são mostrados ao usuário.
Para o desenvolvimento foi utilizada a IDE Metrowerks Codewarrior e o Symbian SDK
para esta IDE. Existe também o Symbian SDK para o Visual Studio.NET, que pode ser usado
em conjunto com o Visual Studio Express gratuitamente, como alternativa ao Codewarrior,
mas a licença não é gratuita. Existem emuladores para auxiliar o desenvolvimento nas duas
IDEs.
O procedimento para o desenvolvimento da aplicação foi iniciado criando uma
pequena aplicação para manipular a câmera do celular, baseada no exemplo CameraApp que
integra o SDK do Symbian OS. As bibliotecas do ARToolKit para Symbian OS e do OpenGL
ES foram adicionadas ao projeto. Logo no construtor, criou-se uma instância do ARToolKit e
carregou-se os marcadores a serem utilizados usando o método correspondente (loadPatt).
Nesta aplicação, o marcador utilizado foi o Hiro (o mesmo da versão desktop).
A câmera foi criada para realizar a captura de frames numa resolução de 176x140
pixels. A cada frame capturado pela câmera, a imagem deve ser convertida para o formato
requerido pelo ARToolKit (os formatos de um e de outro são diferentes) e posteriormente os
métodos de detecção são acionados.
3.4.1 DIFICULDADES ENCONTRADAS
Como visto em [51] pode-se enumerar as dificuldades encontradas ao longo da adaptação do
porte do ARToolKit para a plataforma Symbian OS. Estas dificuldades foram classificadas
para facilitar a compreensão das mesmas. Na seqüência deste texto dissecam-se as
problemáticas encontradas.
3.4.1.1 API ARTOOLKIT PORTADA PARA SYMBIAN OS
Quanto ao porte do ARToolKit para a plataforma Symbian OS, as dificuldades principais são
relacionadas com suporte e documentação pobres sobre o assunto, a carência de uma
aplicação exemplo de código aberto, a baixa confiabilidade na detecção de marcadores da
biblioteca, a calibragem da câmera e o desenvolvimento da interface com o ARToolKit.
3.4.1.1.1
SUPORTE E DOCUMENTAÇÃO FRACOS
É, certamente, o fator que mais concorre para retardar a evolução do desenvolvimento do
projeto desde o princípio.
A versão portada para Symbian OS encontra-se disponível com o código fonte, mas
isto não é o bastante para torná-la usável. Os responsáveis por essa migração não apresentam
38
roteiro para auxiliar a construção de aplicações baseadas na API, tampouco respondem
quaisquer tentativas de contato.
Surgiu, assim, a necessidade de encontrar uma aplicação de exemplo com código
aberto que apresentasse a maneira apropriada de integrar aplicação e API.
3.4.1.1.2 CARÊNCIA DE APLICAÇÃO DE CÓDIGO ABERTO
Após exaustivas buscas, constatou-se a enorme carência de aplicações baseadas na API
migrada. A bem da verdade, apenas uma foi encontrada, mas não contava com o código fonte
para nortear o desenvolvimento. Tratava-se de uma aplicação de exemplo desenvolvida em
[52].
Realizou-se uma busca exaustiva antes do fechamento deste trabalho e não foi
possível localizá-la novamente, levando a crer que seus desenvolvedores resolveram ocultar
qualquer tipo de artefato ou meio que forneça, a outros interessados, condições de reproduzir
seus passos.
3.4.1.1.3 BAIXA CONFIABILIDADE NA DETECÇÃO
Apesar de haver-se determinado experimentalmente que a resolução apropriada para a
correta detecção de marcadores era 160x120 pixels, essa configuração acarretava abrupto
encerramento da aplicação quando o evento de detecção era disparado. Como medida
paliativa, adotou-se a resolução de 170x128 pixels, obtendo-se eficácia, mas não eficiência.
A aplicação apresentava o que se pode chamar de zonas de detecção, averiguando-se a
primeira quando o aparelho distava entre 10 cm e 20 cm do marcador sem zoom, enquanto a
segunda estendia-se desde cerca de 21 cm até 40 cm com zoom de fator multiplicativo igual a
2 (dois).
A existência de zonas disjuntas de detecção bastaria para qualificar esse processo
como pouco confiável, mas é preciso lembrar que ao reconhecer um marcador, a aplicação
exibe seu identificador e diversas vezes esta informação estava incorreta, variando
consideravelmente a confiabilidade da detecção.
3.4.1.1.4 CALIBRAGEM DA CÂMERA
Visando alcançar um nível aceitável de confiabilidade para o reconhecimento de marcadores
decidiu-se calibrar a câmera que até então carregava as configurações padrão a partir do
arquivo camera_para.dat. Para tal precisou-se de um software para simular a câmera do
celular como uma webcam, cuja comunicação com o PC fazia-se via Bluetooth.
A partir de então a calibragem seguiu exatamente o decurso definido em [53]. Apesar
de ser um processo lento e extenso nenhuma grande dificuldade foi enfrentada, obtendo-se o
39
arquivo de configuração em cerca de uma hora.
Os testes realizados em seguida comparando o funcionamento do ARToolKit na
plataforma Symbian OS e na plataforma PC, tanto com o novo arquivo quanto com o antigo,
demonstraram que, com a mudança, os marcadores tinham a confiabilidade de sua detecção
pouco alterada.
Com os resultados obtidos através dessa abordagem, decidiu-se abandonar tal idéia e
concentrar os esforços mais uma vez no problema do uso da resolução correta para o
reconhecimento dos marcadores, adotando novamente o padrão de captura de 160x120
pixels.
3.4.1.1.5 INTERFACE COM O ARTOOLKIT
A chamada a métodos do ARToolKit constituiu-se numa grande dificuldade durante um
longo período da evolução do projeto. Pelo fato de o código fonte estar disponível foi possível
depurá-lo em busca de uma solução e ao final das investigações foram encontradas algumas
soluções, dentre essas cita-se uma desaconselhável que é inserir todo o conteúdo da
biblioteca no código de uma classe do projeto.
Atualmente a aplicação encontra-se estável e o código está livre de tais técnicas de
programação não recomendáveis. Tais subterfúgios foram eliminados graças às apurações
realizadas na busca de soluções para outras dificuldades explicadas adiante. Os problemas
com o ambiente de desenvolvimento, uma vez resolvidos, permitiram à aplicação, retomar
sua elegância original.
3.4.1.2 AMBIENTE DE DESENVOLVIMENTO
3.4.1.2.1 EMULADOR
Utilizando o emulador distribuído com a SDK do Symbian OS v7.0s notou-se que certos
comportamentos esperados dele diferem daqueles aferidos, ocasionando falta de clareza,
consistência e confiabilidade em vários testes e na depuração de código ao longo do
desenvolvimento. Tais aspectos são detalhados a seguir.
3.4.1.2.2 CONFIGURAÇÕES
Durante o progresso do projeto, o emulador foi utilizado, por longo tempo, com suas
configurações iniciais. A partir do instante em que os resultados diferiram substancialmente
dependendo da aplicação ser executada no emulador (êxito na detecção) ou no dispositivo
(interrupção abrupta da aplicação) foi que se evidenciou a necessidade de determinar quais
configurações estavam incorretas e/ou imprecisas.
40
A leitura de [54] conduziu a investigação do problema, esclarecendo as dúvidas a
respeito da finalidade intrínseca de cada configuração. A partir de então, iniciou-se a busca
pelo(s) ajuste(s) necessário(s).
Analisando o arquivo epoc.ini, presente na sub-pasta do Symbian OS no PC,
descobriu-se que o decremento paulatino no valor de MegabytesOfFreeMemory -uma das
configurações disponíveis nesse arquivo originalmente valorada em 16 (dezesseis)- induzia o
emulador a comportar-se de maneira similar ao dispositivo justamente quando, em ambos, a
quantidade de memória disponível convergia.
3.4.1.2.3 CAMINHOS DE DIRETÓRIOS E NOMES DE ARQUIVOS
Conforme exposto em [55], no Symbian OS, arquivos são identificados por uma especificação
que consiste de: unidade do dispositivo (C:, D:, E:, etc.); um caminho contendo cada um dos
diretórios intermediários, separados entre si pelo símbolo de barra invertida (‘\’); seu nome
e, opcionalmente, uma extensão separada dele pelo símbolo de ponto (‘.’).
Há duas considerações importantes mencionadas nesta mesma referência. A primeira
diz respeito ao tamanho máximo de 256 caracteres para a especificação de um arquivo, cujo
único componente de tamanho e formato fixos é a unidade do dispositivo. A segunda
concerne à utilização de caracteres maiúsculos e minúsculos, pois é mencionado que todas as
operações sobre nomes são case-insensitivity, ou seja, independem do formato dos caracteres
usados.
Tais restrições foram consideradas e, apesar disto, enfrentaram-se problemas ligados
à maneira como as especificações haviam sido formadas durante as tentativas de acesso a
determinados arquivos.
Descobriu-se a impossibilidade de usar o caractere do tipo espaço, apesar de ser aceito
na composição de diretórios e de arquivos, nenhum deles que contivesse espaço em seu nome
pôde ser carregado, fazendo a aplicação apresentar erros ou mesmo encerrar abruptamente.
Ademais, contrariando a informação da referência, surgiu uma dificuldade com o uso
de letras maiúsculas e minúsculas, pois quando diz respeito à unidade do dispositivo, deve-se
usar letra maiúscula obrigatoriamente. Na verdade, ao tentar carregar um arquivo cuja
especificação contenha letra minúscula o telefone não indicará erro, enquanto no emulador o
arquivo é carregado normalmente, ou seja, apenas neste é que se percebe a característica de
case-insensitivity.
3.4.1.2.4 FORMATO DE PONTO FLUTUANTE
Uma inconsistência encontrada durante o processo de desenvolvimento, que demandou
bastante esforço e tempo para compreender e solucioná-lo envolve o modo do dispositivo e
41
do emulador interpretarem o formato de ponto flutuante.
No emulador, ao tentar carregar os parâmetros de câmera o êxito foi incontestável,
enquanto no dispositivo os valores carregados eram sempre iguais a zero quando se tratavam
de informações no formato de ponto flutuante.
Após minuciosa investigação chegou-se à conclusão de que tal comportamento deviase às limitações do Symbian OS no processamento de ponto flutuante, como também foi visto
posteriormente durante as tentativas de uso da projeção ortográfica através do OpenGL ES.
Ficando claro que o emulador não reflete este comportamento de maneira fiel.
Após a tentativa de salvar tais valores usando o emulador, que resultou num novo
arquivo com o mesmo problema, a solução foi criar uma estrutura de dados na aplicação que
continha às mesmas informações encontradas no arquivo de parâmetros da câmera,
indicando diretamente no código seus valores com o formato de ponto flutuante aceito pelo
Symbian OS. Ao fim da execução do programa salvaram-se tais configurações num novo
arquivo e a partir de então foi possível carregar os parâmetros da câmera corretamente.
O desenvolvimento de aplicações de AR está sendo amplamente difundido em diferentes
plataformas como desktops, Pocket PCs e também telefones celulares com sistema
operacional Symbian OS. Esta seção apresentou algumas experiências realizadas para
ampliar as possibilidades de desenvolvimento destas aplicações, bem como criar novas
alternativas.
Uma das principais motivações, que levou ao desenvolvimento do OgreAR e do porte
do OGRE para o Pocket PC, foi a possibilidade de desenvolver aplicações utilizando um
engine gráfico de alta abstração, o que favorece a implementação, bem como a possibilidade
de implementar aplicações que funcionarão em diferentes plataformas.
Cabe ressaltar que o desenvolvimento para o Symbian OS ainda é um tópico em
aberto, porém avanços têm sido obtidos no sentido de portar o ARToolKit para esta
plataforma.
42
DESCRIÇÃO DO MODELO A2
CAPÍTULO 4
4.1 INTRODUÇÃO
Este capítulo trata do modelo de referência A2, criado para possibilitar cenários de
computação pervasiva, utilizando AN e múltiplos dispositivos. Este modelo favorece tanto a
administração da rede dos serviços, por adotar uma tecnologia nova com possibilidade de
auto-gerenciamento [56] (AN), quanto o desenvolvimento de serviços e clientes
multiplataformas, por prover bibliotecas e frameworks juntamente com o modelo de
implementação de serviços.
Esse capítulo irá abordar redes heterogêneas, uma porta para computação ubíqua,
consolidar alguns conceitos de AN, e por fim, detalhar o modelo A2.
4.2 REDES HETEROGÊNEAS
Recentemente, vem aumentando a demanda por computadores portáteis, à medida que
também aumenta a capacidade de processamento destes dispositivos. Estes normalmente são
utilizados para organização pessoal e entretenimento. A tendência de miniaturizar
dispositivos e agrupar funcionalidades que antes eram presentes em aparelhos diversos, tais
como tocadores de mídia (áudio e vídeo), compartilhamento de arquivos, telefones, PDAs
com acesso à Internet, entre outros, fez com que aparelhos celulares e dispositivos
multifuncionais ganhassem mercado e oferecessem intercomunicação para acesso a serviços
e a outros dispositivos através de redes diversas.
Juntamente com estes dispositivos, nota-se a crescente utilização de redes móveis, sejam
estas ad-hoc ou estruturadas, como IEEE 802.15.1 (Bluetooth), a família IEEE 802.11 (WiFi), e GPRS (EDGE)/WCDMA (utilizados nas redes celulares 3G), formando PANs, WLANs e
até WANs, respectivamente.
A intercomunicação destas redes normalmente é feita através de gateways de
operadoras, que integram tais redes, chamadas redes heterogêneas, por se tratarem de redes
que utilizam protocolos, alcances e objetivos diferentes.
Muitos serviços vêm sendo oferecidos através da Internet, ou das próprias operadoras de
acesso à rede, com conteúdo específico para cada tipo de dispositivo e/ou rede. A integração
destes serviços através de uma tecnologia de multi-acesso tornaria otimizada a construção e
implementação de serviços para quaisquer dispositivos.
Com o objetivo de tornar transparente a atribuição de políticas de acesso e oferta de
43
serviços, além de muitas outras funcionalidades que envolvem desde roteamento de redes
heterogêneas à escolha da melhor rede em dispositivos com multi-acesso e adaptação de
conteúdo em tempo real, foi proposto o conceito de Redes de Ambiente ou AN, que será
melhor descrito na Seção 4.3.
4.3 REDES DE AMBIENTE
AN reúne muitos conceitos da área de Redes de Computadores [57], que têm sido validados
através de soluções técnicas desenvolvidas por provas de conceitos [58]. Como o modelo A2 é
uma destas provas de conceito, ele tem algumas características relacionadas a áreas que estão
sendo estudadas para oferecer uma arquitetura flexível e integrada ao projeto AN. Estas áreas
são as redes multi-acesso, adaptação de conteúdo, composição de redes e gerenciamento
baseado em políticas.
A Internet foi projetada para interligar dispositivos fixos utilizando enlaces cabeados,
porém o aumento do uso de dispositivos móveis e a crescente popularização das redes sem fio
levaram até as redes heterogêneas com diferentes soluções de acesso. Estas tecnologias
caracterizadas pela variação das condições do enlace, e por serem utilizadas por dispositivos
com diferentes capacidades de processamento e exibição de conteúdo afetam tanto a infraestrutura de rede quanto os serviços oferecidos, além de introduzir novos desafios para serem
resolvidos [60]. Por outro lado, as tecnologias sem fio permitem que os serviços sejam
amplamente ofertados, o que justifica a utilização de redes sem fio no projeto A2, tais como
Bluetooth e WLANs.
Para realizar um serviço capaz de receber múltiplos tipos de conexão com dispositivos
diversos, a adaptação de mídia é imprescindível para permitir que o conteúdo seja
apresentado de forma otimizada e correta em todas as classes de dispositivos móveis. Existem
alternativas diferentes de soluções para adaptação de conteúdo, algumas delas serão
ilustradas a seguir. A aplicação pode detectar mudanças nas características da rede e/ou
capacidades do dispositivo e requisitar uma adaptação de conteúdo ao servidor da aplicação,
ou o terminal pode prover informação sobre o tipo de acesso à rede e do dispositivo, tanto
para a aplicação local quanto para o servidor. Uma terceira abordagem é deixar a rede de
acesso prover informação para o servidor da aplicação e/ou para o dispositivo a respeito das
características da rede [60]. Os clientes dos serviços do A2 são responsáveis pela detecção das
capacidades da rede e do dispositivo onde eles estão sendo executados. Desta forma, estas
informações são repassadas ao servidor de aplicação para que este possa adaptar a mídia de
forma correta.
A composição de redes é um conceito chave no projeto AN, que se destina a habilitar
um plano de controle para integrar e compartilhar funções e serviços entre redes. A
44
composição pode ser vista como um mecanismo automático de negociação de roaming e/ou
SLAs (Service Level Agreements), que hoje são feitos manualmente. No projeto A2, é
aplicado o conceito de composição de redes, de forma que os usuários de uma rede podem
acessar serviços de outras redes de forma transparente, melhorando a eficiência das redes e
dos serviços [61].
O gerenciamento baseado em políticas (PBM - Police-Based Management) é utilizado
para resolver o problema de administração de infra-estrutura de redes complexas de uma
maneira automática. Políticas podem ser utilizadas, por exemplo, para gerenciar e controlar o
acesso a recursos de redes através de regras e decisões descritas de uma forma abstrata e de
alto nível. Como o A2 foi desenvolvido utilizando o arcabouço do protótipo X-PBMAN
(Policy-Based Management for Ambient Networks), ele utiliza a implementação do modelo
de infra-estrutura de gerenciamento de políticas P2P (Peer-to-Peer) P4MI (Peer-to-Peer
Policy Management Infrastructure) [62], uma versão aprimorada do arcabouço de PBM
desenvolvido pela IETF (Internet Engineering Task Force) [63].
O X-PBMAN é um projeto desenvolvido pelo GPRT (Grupo de Pesquisa em Redes e
Telecomunicações) do Centro de Informática da UFPE, e sua implementação utiliza como
base o middleware X-PEER [64], que lida com os conceitos de distribuição de dados,
replicação e comunicação P2P. Através dele os serviços podem se comunicar com a interface
de gerenciamento de políticas e realizar composições, além de prover uma base de dados para
serviços específicos. Tanto o X-PEER quanto o X-PBMAN foram implementados na
linguagem Java, visando uma heterogeneidade de sistemas onde possam ser executadas as
composições de redes.
Outro conceito que faz parte do projeto AN é o de roteamento transparente entre
redes heterogêneas, que é bastante útil quando se têm dispositivos de diversas classes que
utilizam múltiplas redes de acesso, como é o objetivo do A2.
4.4 O MODELO A2
O modelo A2, apresentado no diagrama da Figura 4.1, é composto pelas redes de acesso (na
base do diagrama), que são integradas pela AN (Redes de Ambiente), na camada
imediatamente acima. Ainda fazendo parte da AN, a camada de gerenciamento de políticas
para acesso a serviços pode ser representada pelo PBMAN, onde um PEP (Policy
Enforcement Point) é utilizado. Para realizar composições e disponibilizar serviços, estes se
comunicam com o PBMAN, e no caso dos serviços implementados em C, estes fazem uso da
camada XCSERVICES para ter acesso ao PBMAN que é escrito em Java e utiliza em sua base
o X-PEER. Mais acima, estão as plataformas de desenvolvimento, onde estão representadas
algumas bibliotecas já existentes e outras implementadas para prover um desenvolvimento
45
mais rápido e unificado de interfaces. Estas interfaces serão construídas para que os clientes
consigam usufruir melhor dos serviços prestados pela AN. Acima das plataformas de
desenvolvimento estão os dispositivos móveis que podem ser utilizados para a execução dos
serviços e visualização de dados, bem como o ambiente aumentado, que é composto pelo
mundo real, marcadores e objetos virtuais, sejam estes 2D ou 3D.
Figura 4.1. Diagrama do modelo A2.
4.5 PROTOCOLO
DE
INTERCOMUNICAÇÃO
ENTRE
SERVIÇOS
E
AN
XCSERVICES
Para integrar os serviços disponíveis com o sistema de gerenciamento de políticas utilizado
pela AN, juntamente com o processo de composição, foi desenvolvido o XCSERVICES, uma
camada de infra-estrutura de comunicação para se comunicar com a interface do X-PEER.
46
Esta camada tem como objetivo deixar que as aplicações escritas em C/C++ tenham acesso às
funções do X-PEER, e possam integrar redes e requisitar serviços de forma transparente,
utilizando apenas uma interface cliente para o middleware Java.
Além da interface cliente também foi implementado um proxy, que é utilizado para
intermediar as conexões entre o middleware e os servidores de aplicação, que compõem os
serviços. O proxy, implementado em linguagem Java, é utilizado para facilitar a integração e
a comunicação entre as aplicações que fazem uso da biblioteca XCSERVICES e o PBMAN.
Este recebe as requisições enviadas pelos clientes e as repassa à AN. Como o protocolo de
comunicação usado pelo PBMAN é derivado do que é usado no middleware X-PEER, ele
engloba muitas funcionalidades não utilizadas nos serviços oferecidos pelo A2. Através do
proxy, o protocolo que deve ser usado pelo cliente torna-se mais simples, diminuindo a
possibilidade de erros de sincronização, já que a maior parte da complexidade fica a cargo do
Proxy.
4.6 SERVIÇOS
Os serviços são aplicações que podem ser oferecidas pela própria rede do cliente ou por
outras redes externas. No caso de redes externas, o acesso a estes é feito através de uma
composição de redes que, através de políticas, pode permitir a utilização do serviço ou impor
algumas restrições.
Os serviços podem ser distribuídos em hosts e redes diferentes, dependendo da
quantidade de processamento e largura de banda utilizada. Os hosts utilizados para executar
os serviços são denominados servidores de backend. A arquitetura do A2 utiliza a distribuição
do processamento de serviços utilizando servidores de backend, para que dispositivos com
capacidade de processamento reduzida e que necessitam de um baixo consumo de energia
possam ser utilizados apenas para acesso aos dados e visualização. Este fato permite que os
serviços sejam realizados em tempo real, já que alguns processamentos seriam inviáveis de
serem feitos localmente, em tempo hábil, para sua exibição sem a percepção de falha pelo
usuário.
Normalmente serviços multimídia exigem um maior processamento para codificação
e decodificação, tanto de imagem como de som, e adaptação de conteúdo. Para tornar a
execução com tempo uniforme em qualquer dispositivo, o padrão adotado foi que todo
processamento e adaptação de conteúdo fosse realizado pelo servidor de backend, que é
informado sobre as características do dispositivo através de políticas aplicadas no momento
da composição com a rede e do registro no serviço.
Serviços mais complexos podem exigir uma rede completa para distribuição de
processamento e/ou dados para acesso otimizado. Neste caso, um host fica responsável pela
47
conexão dos usuários e redirecionamento para outros servidores, funcionando como uma
porta de entrada para o serviço. Outros computadores podem ser utilizados para tarefas
específicas como será ilustrado na Seção 5.3.2 do capítulo Estudo de Caso.
Alguns serviços podem não envolver processamento de dados, nem prover informação
específica ao usuário. Como exemplo destes serviços pode-se citar um possível serviço de
roteamento Bluetooth. Este pode prover acesso de um dispositivo Bluetooth à rede local,
servindo de gateway para este dispositivo. Além do serviço de gateway algumas
simplificações nos dados transmitidos e no protocolo podem ser feitas para deixar a aplicação
nativa do dispositivo mais simples e facilitar a implementação de novos serviços, utilizando
esta nova camada de abstração de rede.
Alguns exemplos de serviços que foram implementados neste trabalho serão
detalhados no próximo capítulo.
4.7 FRAMEWORKS
DE
DESENVOLVIMENTO
PARA
CLASSES
DE
DISPOSITIVOS
Um dos objetivos deste trabalho é prover uma interface baseada em AR para serviços
utilizando dispositivos móveis, capaz de se comunicar com uma AN e usufruir dos seus
serviços, levando em conta não só a simplificação nos protocolos de comunicação, mas
também na visualização dos dados e exibição, seja qual for o dispositivo móvel.
Para isto, cada classe de dispositivo deve ter um framework de desenvolvimento
associado. Estes foram construídos com base em ferramentas e bibliotecas descritas no
Capítulo 3, algumas implementadas especificamente para o modelo A2.
Cada framework proposto é específico para uma plataforma de desenvolvimento, que
é caracterizada pela classe de dispositivos que fará uso dele. As classes de dispositivos,
inicialmente, escolhidas foram: Mobile Desktop (notebooks, tablets, wearable computers,
etc. que utilizem a plataforma Windows), Pocket PC e Smart Phone (que utiliza Windows CE
ou Windows Mobile) e Celular (que utiliza Simbian OS).
Os frameworks têm uma camada de acesso à AN implementada através da biblioteca
XCSERVICES, construída em linguagem C, utilizando recursos de retrocompatibilidade.
Apenas a plataforma Celular não utiliza diretamente o XCSERVICES pois a comunicação é
feita através de Bluetooth e necessita de um serviço de gateway.
Acima da camada de comunicação, a exibição das informações trocadas com os
serviços é feita utilizando recursos específicos de cada platafoma.
A plataforma Mobile Desktop dispõe de um framework de exibição composto pelas
bibliotecas OGRE (para exibição de conteúdo e renderização), OgreAR (para utilização de
48
AR), e CIDA (para gerenciamento de dispositivos de entrada e hápticos), todos descritos no
capítulo de Desenvolvimento Multiplataforma.
Para a plataforma Pocket PC, foi feito um porte da biblioteca OGRE, com o objetivo de
unificar o desenvolvimento de interfaces tanto para a plataforma Mobile Desktop quanto
para a plataforma Pocket PC. Desta forma a exibição é implementada de uma maneira única e
o processamento é feito de forma específica, acelerando o desenvolvimento multiplataforma.
Esta plataforma também conta com a utilização da biblioteca OgreAR, desenvolvida
utilizando o OGRE e o ARToolKitPlus, com otimizações específicas para o Pocket PC.
Na plataforma Celular, alguns recursos do sistema operacional Symbian OS foram
utilizados para a aquisição de dados e organização da arquitetura. Um porte da biblioteca
ARToolKit está sendo implementado para utilizar AR no celular. A exibição fica por conta da
biblioteca OpenGL ES, utilizada em alguns sistemas embarcados e consoles de jogos.
A comunicação não foi explorada nos serviços da plataforma Celular, pois a
comunicação Bluetooth não pôde ser testada junto com o resto do sistema, devido a
problemas com o roteamento, que não está disponível ainda na versão corrente da
implementação do modelo AN.
4.8 AMBIENTE DE AR
O ambiente de AR em questão deve ser composto pelo própio mundo real, podendo ser
utilizado em ambientes fechados (indoor) ou abertos (outdoor), dependendo apenas de
restrições de iluminação impostas pelas ferramentas de AR. Também baseado nas
ferramentas de AR utilizadas, o ambiente AR deve ser composto por alguns marcadores. O
formato destes marcadores depende unicamente das ferramentas utilizadas, pois cada uma
possui características diferentes, marcadores template-based ou ID-based são usados no
ARToolKit e no ARToolKitPlus, respectivamente.
Para interagir com o ambiente são utilizadas algumas metáforas de interação
baseadas em gestos e interfaces tangíveis. Alguns dispositivos são utilizados para possibilitar
a captura de gestos e a interação, como luvas de dados e trackers. A mistura dos elementos
virtuais com o mundo real é feita através de um capacete de VR no caso da plataforma Mobile
Desktop e da própria tela dos dispositivos, nos casos restantes.
Cada serviço pode ter características diferentes e necessitar de alguns recursos
especiais, como captura de som, imagem com diversos fluxos de vídeo para ângulos
diferentes, entre outros que dependam da observação e/ou captura de eventos do ambiente.
Para isso devem ser inseridos mais dispositivos a fim de que estes eventos sejam fielmente
capturados e a interação ocorra de forma natural e imersiva.
49
Foi apresentado neste capítulo o modelo de referência A2, que visa facilitar o
desenvolvimento de serviços e aplicações em múltiplas plataformas. Ele utiliza conceitos de
AR em suas interfaces e se apoia na tecnologia das AN para prover uma intercomunicação
transparente para a oferta de serviços. Também é dada uma breve motivação para a criação
de um modelo de referência, baseando-se no conceito de redes heterogêneas e na solução
utilizando redes AN.
50
ESTUDO DE CASO: O PROJETO A2
CAPÍTULO 5
5.1 INTRODUÇÃO
O presente capítulo valida o modelo de referência A2 através de um estudo de caso onde um
museu virtual é utilizado como cenário. São detalhados os dispositivos utilizados no cenário,
os serviços fornecidos, as bibliotecas utilizadas por cada dispositivo, compondo os
frameworks específicos para desenvolvimento multiplataforma.
5.2 DESCRIÇÃO DOS EQUIPAMENTOS
Para que o estudo de caso pudesse retratar plataformas diferentes e utilizar os conceitos de
mobilidade e de redes heterogêneas, foram escolhidos alguns equipamentos, nas diversas
categorias. Estes equipamentos serão detalhados para cada plataforma.
5.2.1 PLATAFORMAS
5.2.1.1 PLATAFORMA CELULAR
Esta plataforma faz uso de um celular Nokia 6600, como visto na Figura 5.1, com processador
ARM de 104 MHz, câmera embutida com suporte a gravação em até 176x144 pixels, rodando
o Symbian OS v7.0s, Series 60 v2.0 UI.
Figura 5.1. Nokia 6600 utilizado no Projeto A2.
5.2.1.2 PLATAFORMA POCKET PC
O dispositivo móvel usado para testar as aplicações OGRE foi o PDA Dell Axim X51v. Este
possui um processador 624 MHz Intel PXA270 XScale, 64 MB de RAM, 256 MB de ROM e
um display LCD com 16 bit color depth e 640x480 pixels. O sistema operacional é o
Microsoft Windows Mobile 2005 (versão 5.1.70 build 14402.1.1.0). Também é utilizada uma
câmera SD acoplada ao Pocket PC. O modelo da câmera utilizada foi o Spectec SD (Secure
Digital) Camera SDC-001A, com resolução de 320x240 pixels e uma taxa de captura de 15 fps
(frames por segundo). A configuração final é ilustrada pela Figura 5.2.
51
Figura 5.2. Dell Axim x51v utilizado no Projeto A2.
5.2.1.3 PLATAFORMA MOBILE DESKTOP
A plataforma desktop utiliza um computador móvel, que pode ser tanto um notebook, quanto
um wearable computer, em conjunto com outros dispositivos de entrada e saída que são
listados a seguir:
•
Luva: Data Glove 5DT, conectada via USB com a plataforma desktop.
•
Tracker: InterSense InterTrax2, conectado via USB com a plataforma.
•
Câmera: A4Tech PK635, conectada via USB com a plataforma.
•
HMD: i-glasses PC/SVGA, onde foi integrada a câmera descrita acima. (ver Figura
2.4)
Os equipamentos que compõem a plataforma Mobile Desktop podem ser vistos
totalmente integrados na Figura 3.4.
5.3 ESTUDO DE CASO: O MUSEU VIRTUAL
O estudo de caso deste trabalho aplica o modelo A2 em um cenário representado por um
museu virtual. Neste museu as obras de arte podem ser rotativas, e exposições podem mudar
de sala em segundos. As obras de arte podem ser quadros e/ou esculturas, sendo seu
conteúdo representado tanto em 2D quanto em 3D. As peças expostas não precisam de
sistemas de segurança e irão conter informações nelas mesmas que se tornam disponíveis a
um simples gesto do usuário. Estas informações podem variar de textos a vídeos, passando
por imagens e áudio, dependendo da informação associada à obra.
Além do serviço de visualização da galeria de arte, existem outros serviços disponíveis
no museu. O usuário pode, a partir de seu equipamento, conversar com outros usuários que
também estão no museu para trocar experiências e indicar obras, participar de entrevistas ou
leilões que estejam ocorrendo, ao mesmo tempo, em outras salas do museu.
Como todos os artefatos do museu são virtuais, o usuário deve utilizar um sistema
construído para integrar o ambiente do museu, e obter um material para auxílio a interação
com o ambiente na entrada do museu Este material está contido, neste museu, em um folder,
52
que possui informações sobre as seções de entrevista, leilões, artistas que terão seus trabalhos
expostos, e além de tudo os marcadores necessários para interagir com os serviços do museu,
que fazem do folder parte essencial da interação. Este material também deve conter uma
senha, que vai identificar cada usuário de forma única, em forma de marcador. Este é
reconhecido e transformado em um número pelo software do cliente. Uma versão preliminar
do folder pode ser vista na Figura 5.3.
Figura 5.3. Versão preliminar do folder utilizado no estudo de caso.
Ao identificar a senha no folder, o cliente utiliza esta informação para se compor com
a rede do museu, onde vai trocar informações e um acordo temporário vai ser criado. Durante
o registro do usuário, o cliente envia informações como a plataforma e o protocolo utilizado.
Com isto a rede do museu pode inferir o poder de processamento e de visualização do
dispositivo, e na ocasião do envio de mídias, serão utilizadas versões otimizadas e adaptadas
para um melhor funcionamento específico para o dispositivo em questão.
Para compor a AN do museu, foram utilizados hotspots (pontos de rede sem fio IEEE
802.11g) para a conexão de laptops, wearable computers e pocket pcs. Conectados à rede do
museu estão servidores responsáveis pela execução de alguns serviços (servidores de
backend) e também pela administração da rede (PEPs - Pontos de Imposição de Políticas, nós
de borda da AN e o anel de servidores do X-PEER). Devido a restrições de infra-estrutura e
espaço físico, algumas tarefas foram condensadas em um único servidor, como o PEP, o nó de
borda da AN e o proxy do XCSERVICES.
Para a intercomunicação dos clientes e dos serviços foi utilizado o X-PEER,
adicionando a ele outra camada de abstração desenvolvida para o estudo de caso, o
XCSERVICES. A camada serve para prover compatibilidade de comunicação entre módulos
do sistema escritos em Java (X-PEER e PEPs) e os clientes, escritos em C/C++.
Cabe ressaltar que os serviços não foram implementados na plataforma Celular,
devido às dificuldades encontradas detalhadamente descritas na Seção 3.4. Porém, este fato
53
não invalida a aplicação do modelo A2 nesta plataforma, uma vez que já existem versões do
Symbian OS que provêem aceleração gráfica nativa através de OpenGL ES, e que resolvem
alguns problemas de segurança encontrados na versão utilizada neste projeto. Um exemplo
de aparelho que já possui uma das versões do Symbian com estes recursos disponíveis é o
Nokia N93, ilustrado na Figura 5.4.
Figura 5.4. Nokia N93.
Os equipamentos e o ambiente configurado para a execução dos serviços serão
detalhados nas seções a seguir.
5.3.1 SERVIÇO DE VISITAÇÃO A UMA GALERIA DE ARTE
Neste serviço, marcadores espalhados pelas instalações do museu indicam onde as obras
devem ser exibidas. Podem ser exibidos tanto quadros como esculturas ou obras em terceira
dimensão. A interação e o modo de utilização depende da plataforma que o usuário está
utilizando para acessar o sistema do museu.
Este serviço está disponível na rede do museu a partir da composição do usuário com
a rede. Sua utilização não está sujeita a restrições de tempo, pois a galeria estará exposta
enquanto o usuário estiver no museu.
Caso o usuário esteja utilizando a plataforma Mobile Desktop, o ambiente aumentado
será exibido no HMD, que possui uma câmera acoplada, permitindo que o usuário veja
sempre o que está à sua frente. Caso um ou mais marcadores estejam na linha de visão da
câmera, estes serão detectados e seus códigos identificadores serão requisitados ao serviço de
visualização. O serviço, por sua vez, retornará o conteúdo numa resolução maior, caso seja
uma imagem 2D, ou uma malha mais detalhada, caso seja um objeto 3D. O resultado desta
tarefa pode ser visualizado na Figura 5.5. O conteúdo será armazenado numa cache interna
do cliente para que novas requisições para estes objetos não precisem ser feitas novamente.
54
Figura 5.5. Aplicação Mobile Desktop exibindo informação 2D sobre 2 marcadores.
Após a exibição dos objetos, as informações sobre eles também podem ser
requisitadas a partir de gestos capturados pela luva. No caso do serviço de visualização, o
conteúdo adicional vai ser requisitado se o usuário apontar para o quadro com o dedo
indicador e abaixá-lo como se fosse um “click”. A partir deste momento a requisição é feita ao
servidor que lhe envia um vídeo sobre a obra em questão. Este vídeo será exibido no mesmo
espaço pertencente à respectiva obra de arte. O vídeo pode ser parado, conforme a vontade do
usuário, através de um outro “click” com a luva, ou se o marcador da obra que estava sendo
visualizada sair do campo de vista do usuário, considerando que o mesmo deixou a obra e for
visitar outras. Para que o conteúdo adicional seja exibido, apenas o marcador correspondente
ao conteúdo deve estar visível, como mostra a Figura 5.6.
Figura 5.6. Conteúdo adicional em forma de vídeo sendo exibido na plataforma Mobile Desktop.
55
No caso da plataforma Pocket PC, o dispositivo vai atuar como se fosse uma lupa
virtual, portando uma câmera que deve ser apontada para onde o usuário quer visualizar o
conteúdo. As obras aparecerão na tela do PDA, compondo um ambiente de AR. Da mesma
forma que na versão da plataforma citada anteriormante, serão feitas requisições para a
exibição do conteúdo e uma cache mais limitada também será criada. A diferença entre os
serviços está apenas na identificação do dispositivo no servidor de visualização. Este enviará
ao PDA uma versão menos detalhada dos dados a serem exibidos, e otimizada para a exibição
na resolução e processamento do mesmo. Esta adaptação de conteúdo é feita no servidor de
backend, e não no cliente, para que não seja gasto nenhum tempo ou processamento
adicional.
O mesmo ocorre com o conteúdo adicional, que na versão do Pocket PC é acessado
mediante um “click” na tela, aproveitando o recurso de touchscreen. Este “click” dispara uma
requisição ao servidor que também envia de volta um conteúdo já adaptado para ser exibido
no Pocket. Este conteúdo é mostrado em tela cheia e pode ser composto de texto e/ou
imagens. Novamente, um outro “click” desabilita a visualização do conteúdo adicional,
diferentemente da versão Mobile Desktop. O serviço de visualização na plataforma Pocket PC
é ilustrado na Figura 5.7.
Figura 5.7. Serviço de visualização na plataforma Pocket PC.
Os frameworks utilizados nas duas plataformas são bastante semelhantes e utilizam
como base o OGRE e o OgreAR para exibição de objetos e construção de interfaces. Para a
comunicação com dispositivos como a luva e o tracker da luva é utilizada a biblioteca CIDA
(apenas na versão Mobile Desktop), e para a comunicação com o serviço é utilizada a
plataforma XCSERVICES.
56
5.3.2 SERVIÇO DE ENTREVISTA
Este serviço fornece ao usuário a possibilidade de ver uma entrevista online, que pode ser
exibida de uma maneira diferente da convencional. Ela ocorre pela transmissão de um fluxo
de vídeo 3D, capaz de ser interpolado, gerando imagens em qualquer ângulo de visão. Este
serviço foi baseado no trabalho do 3DLive[65], sendo diferenciado pelo tipo de câmeras
utilizado e pela abordagem tecnológica dos formatos contidos no fluxo 3D. Este serviço ainda
está sendo aperfeiçoado no escopo de uma dissertação de mestrado ainda em
desenvolvimento. O projeto 3DLive é ilustrado na Figura 5.8 abaixo.
Figura 5.8. Diferentes visões da utilização do 3DLive.
O serviço de entrevista conta com uma infra-estrutura bastante peculiar para que
possa ser realizada. Uma sala equipada com várias câmeras de vídeo (a partir de 5 câmeras)
posicionadas e devidamente calibradas deve ser montada para originar a entrevista. Junto às
câmeras devem haver servidores para a captura dos vídeos, sincronização dos fluxos e
montagem do fluxo de imagem 3D. A rede que interliga estes equipamentos deve ter uma
banda de 1Gbps para um resultado satisfatório, como visto em [65].
Para que o usuário possa participar do serviço de entrevista, um convite é enviado ao
cliente quando a entrevista estiver prestes a começar, podendo o mesmo aceitar ou desejar
não assistí-la. Caso aceite, o fluxo 3D poderá ser exibido em um marcador existente no folder
entregue na entrada do museu. Este serviço está disponível apenas na plataforma Mobile
Desktop, por exigir um processamento de imagem adicional em cada cliente, tornando a
experiência de exibição num dispositivo com um poder de processamento menor bastante
precária. Durante a entrevista o áudio também é enviado e pode ser ouvido mesmo sem a
exibição do fluxo 3D no marcador, caso este não esteja no campo de visão do usuário. O
serviço é finalizado quando a entrevista acaba.
O software utilizado para dar suporte a este serviço é uma versão modificada da
biblioteca 3DLive, e ainda não está disponível para distribuição (como já mencionado
anteriormente).
57
5.3.3 SERVIÇO DE LEILÃO
O leilão também é um serviço que ocorre apenas num determinado espaço de tempo. Desta
forma, os usuários são alertados para o início do leilão. Se desejarem participar, o serviço será
ativado e a partir deste momento começa a troca de informações.
O leilão foi projetado como um serviço externo, presente numa rede diferente da rede
do museu. Isto foi feito para provar o conceito de composição de redes, que ocorre quando o
cliente requisita um serviço que não está presente na própria rede em que ele se encontra. O
processo de composição cria algumas políticas e acordos temporários que são seguidos até
que o usuário se desconecte ou que o serviço não esteja mais disponível.
Quando o usuário aceita participar do leilão, é mostrada uma tela com os lotes do
leilão. Sucessivamente, os lotes serão liberados e o leilão ocorre. O usuário pode dar seu lance
através de gestos com a luva, apontando para uma determinada área da tela com um botão e
clicando com seu dedo indicador. Numa outra área da tela são mostradas informações como
o último lance, o valor do próximo lance (fixo pelo programa), e o objeto que está sendo
leiloado pode ser exibido num dos marcadores fornecidos no folder do museu. Juntamente
com os marcadores de exibição é dado também um cubo de marcadores, que serve como uma
interface tangível para a visualização dos objetos que estão sendo leiloados no lote. Este cubo
pode ser visualizado na Figura 5.9, onde o usuário interage na plataforma Pocket PC.
Figura 5.9. Cubo de marcadores em utilização.
No cubo de marcadores, algumas faces, quando viradas para cima, têm funções
específicas, como exibição, escala e visualização do próximo objeto do lote. Com uma destas
faces ativas, ou seja, direcionadas para cima, para efetuar uma mudança na função específica,
basta que o usuário gire o cubo.
A interação é praticamente igual, nas versões Mobile Desktop e Pocket PC, diferindo
apenas na utilização da luva com um tracker, na versão Mobile Desktop, substituída por
58
gestos e clicks com a caneta, no caso do Pocket PC. A interface no Pocket PC é bem mais
simples e não é integrada à visualização do mundo real, pois a interface gráfica ocupa muito
espaço na pequena tela do dispositivo, como visto na Figura 5.10.
Figura 5.10. Interface do serviço do leilão na plataforma Pocket PC.
O usuário pode sair do leilão no momento que desejar. O leilão também é
implementado utilizando as ferramentas OGRE e OgreAR, bem como bibliotecas específicas
de construção de interfaces gráficas como a API do Windows Mobile e a biblioteca CEGUI.
5.3.4 SERVIÇO DE CHAT
O serviço de chat é bem simples e serve para integrar os usuários dentro do museu. O chat
funciona somente via voz, para evitar interação textual do usuário com a interface. O chat
também é um serviço sempre disponível na rede do museu, assim como o de visualização. O
usuário pode ver todos os clientes conectados e se comunicar com eles através da voz. A
Figura 5.11 ilustra a versão do serviço de chat para a plataforma Mobile Desktop.
59
Figura 5.11. Serviço de chat na plataforma Mobile Desktop.
O serviço foi implementado nas plataformas Mobile Desktop e Pocket PC utilizando o
protocolo H323, através da biblioteca OpenH323 [66]. Na versão atual do serviço, o usuário
pode falar apenas com um cliente de cada vez, podendo trocar de usuário quando quiser,
assim como desativar o serviço. O serviço também não depende de nenhum recurso de
visualização, salvo os menus de escolha dos interlocutores, como ilustrado na Figura 5.12.
Figura 5.12. Interface do serviço de chat na plataforma Pocket PC.
Este capítulo apresentou o estudo de caso A2, que utiliza o modelo de referência homônimo.
Foram detalhados os serviços implementados em duas plataformas, sendo elas Mobile
Desktop e Pocket PC, já que a plataforma Celular ainda está em desenvolvimento por ter
apresentado algumas dificuldades na implementação, como visto no Capítulo 3.
60
Verificou-se a viabilidade de utilização de aplicações de AR neste cenário, bem como a
aplicação adequada dos conceitos de AN. Estas tecnologias simplificaram a implementação
dos serviços e a modularização dos mesmos, através de uma arquitetura bem estruturada.
61
CONCLUSÃO
CAPÍTULO 6
CONCLUSÃO
Esta dissertação apresentou o modelo de referência A2 para o desenvolvimento de aplicações
e serviços multiplataforma. Foi demonstrada a interdisciplinaridade da pesquisa
desenvolvida, principalmente a integração de duas áreas relevantes que utilizam tecnologia
de ponta, como AN e AR.
Na área de AN, foram explorados os principais conceitos, entre eles: composição de
redes, adaptação de conteúdo para exibir informação de acordo com o dispositivo, aplicação
de políticas para criação automática de acordos entre redes, e o futuro, que é permitir a
intercomunicação de redes móveis heterogêneas.
A área de AR, que é o foco principal desta dissertação, motivou a pesquisa de alguns
tópicos relevantes para o desenvolvimento do A2, como: interação e metáforas, onde foram
estudadas diversas formas e técnicas de interação e adotadas algumas metáforas para compor
o projeto A2. Estas metáforas foram utilizadas para cumprir as tarefas de manipulação,
navegação, controle de sistemas e entrada simbólica, presentes no projeto. Foram utilizadas
interfaces tangíveis para permitir ao usuário visualizar os dados e interagir naturalmente
com a aplicação. Também foi explorada a adaptação de RA com fluxo 3D para utilização com
câmeras de vídeo de baixo custo, baseado no projeto 3DLive. Outro ponto de destaque na
área é a reinterpretação de dispositivos de entrada através da plataforma CIDA, construída
como uma camada de abstração de dispositivos de interação como parte deste projeto.
Finalmente foi proposto um framework de alto nível para construção de aplicações de
AR num ambiente de redes AN, o projeto A2. Este framework foi validado através da
implementação do cenário “Museu Virtual”, descrito no Capítulo 5.
6.1 CONTRIBUIÇÕES
A concepção e o desenvolvimento desta dissertação trouxeram algumas contribuições
relevantes para a área de AR. A seguir, serão destacadas em dois grupos distintos, o primeiro
apresenta a lista de contribuições no âmbito de desenvolvimento de software e do
framework e o segundo grupo destaca as publicações geradas pelo trabalho desenvolvido
nesta dissertação.
6.1.1 DESENVOLVIMENTO DE SOFTWARE E DO FRAMEWORK
•
Construção de casos de uso para avaliação de metáforas de interação e estudos de
técnicas de interação já existentes;
•
Reescrita do 3DLive para suporte de câmeras de baixo custo com suporte a fluxo
RGB/Bayer;
•
Desenvolvimento da biblioteca de abstração de dispositivos de entrada CIDA e alguns
de seus plugins;
•
Desenvolvimento da biblioteca OgreAR;
•
Concepção e descrição do modelo de aplicação de alto nível para AR, modelo A2;
•
Porte do engine gráfico OGRE para o Pocket PC, que favorece o reaproveitamento de
código para aplicações multiplataforma;
•
Avanços no porte do ARToolkit para o Symbian OS, assim como um modelo de
arquitetura de aplicação no mesmo;
•
Construção
de
interface
nativa
multiplataforma
em
linguagem
C
para
intercomunicação com o X-PEER e construção de alguns serviços para o estudo de
caso apresentado nesta dissertação.
6.1.2 PUBLICAÇÕES RELEVANTES
•
Escrita do capítulo de livro “O engine gráfico OGRE 3D”, publicado nos tutoriais do
SBGames 2005, com apresentação de minicurso.
–
FARIAS, Thiago; PESSOA, Saulo; TEICHRIEB, Veronica; KELNER, Judith. O
engine gráfico OGRE 3D. Esteban W. Gonzalez Clua; Sérgio Scheer (Org.).
Tutoriais do SBGames 2005. 2005, p. 1-33. ISBN 8576690586.
•
Artigos completos com apresentação oral.
–
FARIAS, Thiago; SILVA, Daliton; MOURA, Guilherme; TEIXEIRA, João
Marcelo; COSTA, Luiz Henrique; DIAS, Guilherme; TEICHRIEB, Veronica;
KELNER, Judith. Um estudo de caso sobre a construção e a integração de
dispositivos hápticos com aplicações interativas. In: Brazilian Symposium on
Computer Games and Digital Entertainment, 2006, Recife.
–
TEIXEIRA, João Marcelo; FARIAS, Thiago; MOURA, Guilherme; LIMA, João
Paulo; PESSOA, Saulo; TEICHRIEB, Veronica. GeFighters: an experiment for
gesture-based interaction analysis in a fighting game. In: Brazilian
Symposium on Computer Games and Digital Entertainment, 2006, Recife.
–
FARIAS, Thiago; TEIXEIRA, João Marcelo; RODRIGUES, Carlos Eduardo;
PESSOA, Saulo; COSTA, Nacha; TEICHRIEB, Veronica; KELNER, Judith.
63
CIDA: an interaction devices management platform. In: Symposium on
Virtual Reality, 2006, Belém. Porto Alegre: SBC, 2006. p. 271-284.
–
LIMA, João Paulo; FARIAS, Thiago; TEICHRIEB, Veronica; KELNER, Judith.
Port of the OGRE 3D engine to the pocket pc platform. In: Symposium on
–
TEICHRIEB, V. et al. Augmented Ambient. HCI International, 2007 (To be
published).
•
Resumos Expandidos com apresentação oral.
–
GOMES NETO, Severino; FARIAS, Thiago; TEICHRIEB, Veronica; KELNER,
Judith. Criação de aplicações de realidade aumentada em dispositivos móveis
baseados em Symbian OS. In: Workshop de Realidade Aumentada, 2006, Rio
de Janeiro. p. 16-19.
–
TEIXEIRA, João Marcelo; FARIAS, Thiago; PESSOA, Saulo; RODRIGUES,
Carlos Eduardo; COSTA, Nacha; CANANÉA, Igor; TEICHRIEB, Veronica;
KELNER, Judith. GeFighters: usando gestos para interação com um jogo de
luta. In: Symposium on Virtual Reality, 2006, Belém. p. 1-5.
–
FARIAS, T. S.; LIMA, J. P.; TEICHRIEB, V.; KELNER, J. OgreAR: construção
de aplicações de realidade aumentada utilizando bibliotecas de alto nível.
Workshop de Aplicações de Realidade Virtual, Sociedade Brasileira de
Computação, Recife, 21-24 de Novembro, 2006.
•
Resumo com apresentação de pôster.
–
FARIAS, Thiago; TEIXEIRA, João Marcelo; RODRIGUES, Carlos Eduardo;
PESSOA, Saulo; TEICHRIEB, Veronica; KELNER, Judith. CIDA: uma
plataforma
de gerenciamento de dispositivos para interação. In: Simpósio
Brasileiro de Jogos para Computador e Entretenimento Digital, 2005, São
Paulo. p. 1-4.
6.2 TRABALHOS FUTUROS
Tendo em vista que esta dissertação focou a pesquisa em duas áreas relativamente
novas e com diversos problemas para serem solucionados, vários pontos deste projeto podem
ser destacados como trabalhos futuros, os mais relevantes serão enumerados a seguir:
•
Implementação da interface baseada em comportamento de simulação física, como
foi estudada durante o desenvolvimento do projeto.
•
Implementação e testes de todos os serviços na plataforma Symbian OS, para validar
64
o estudo de caso do museu virtual.
•
Estudar a viabilidade de inserir um módulo de roteamento para redes heterogêneas
compatível com a tecnologia e o protocolo de comunicação Bluetooth em redes de
ambiente.
•
Efetuar testes de usabilidade nas interfaces propostas e adaptá-las de acordo com os
resultados obtidos.
•
Melhorar o desempenho do núcleo das redes de ambientes, no âmbito do projeto XPEER e viabilizar uma implementação dos conceitos básicos de AN em linguagem
nativa (C/C++).
•
Finalizar o projeto de adaptação do 3DLive para câmeras de baixo custo, permitindo
um completo fluxo de vídeo 3D.
65
REFERÊNCIAS
REFERÊNCIAS
BIBLIOGRAFIA
[1] TEICHRIEB, V. et al. Augmented Ambient. HCI International, 2007 (To be published).
[2] BIMBER, O.; RASKAR, R. Spatial Augmented Reality. A. K. Peters, 2005.
[3] AZUMA, R. T. A Survey of Augmented Reality. Presence: Teleoperators and Virtual
Environments, v. 6, n. 4, p. 355-385, ago. 1997
[4] Ambient Networks Project. Disponível: Ambient Networks
http://www.ambient-networks.org. Consultado em 15 jan. 2006.
Project
site.
URL:
[5] MILGRAM, P.; KISHINO, F. A Taxonomy of Mixed Reality Visual Displays. IEICE
Transactions on Information Systems, v. E77-D, n. 12, p. 1321-1329, dez. 1994. Special Issue
on Networked Reality.
[6] BURDEA, G. C.; COIFFET, P. Virtual Reality Technology. IEEE Press Wiley-Interscience,
2003.
[7] Open Spaces in Megacities. Disponível: Open Spaces Home site.
http://www.ufpe.br/nordest/megacities/index.htm. Consultado em 10 fev. 2007.
URL:
[8] A Table-Top Augmented Reality Application. Disponível: Multimedia Concepts and
Applications
site.
URL:
http://mm-werkstatt.informatik.uniaugsburg.de/project_details.php?id=1. Consultado em 26 dez. 2005.
[9] BOWMAN, D. A.; KRUIJFF, E.; LAVIOLA, JR, J. J.; POUPYREV, I. 3D User Interfaces:
Theory and Practice. USA: Addison-Wesley, 2004. 512 p.
[10] HÖLLERER, T. H. and FEINER, S. K. “Chapter Nine”, Mobile Augmented Reality, H.
Karimi and A. Hammad (eds.), Taylor & Francis Books Ltd., January 2004.
[11] Input
Devices.
Disponível:
ICS
online
site.
http://www.ics.uci.edu/~kobsa/courses/ICS104/course-notes/input-devices.htm.
Consultado em 17 jan. 2006.
URL:
[12] Virtual
Reality
Experience.
Disponível:
Cursus
Fotografie
site.
URL:
http://www.fotobeurs.com/cursus/stereografie/?id=95&nm=HMD%203D-bril. Consultado
em 17 jan. 2006.
[13] WAGNER, D.; PINTARIC, T.; LEDERMANN, F.; SCHMALSTIEG, D. Towards Massively
Multi-User Augmented Reality on Handheld Devices. In: INTERNATIONAL
CONFERENCE ON PERVASIVE COMPUTING, 3., 2005, Germany, Proceedings... 2005. p.
208-219.
[14] AZUMA, R. T.; BAILLOT, Y.; BEHRINGER, R.; FEINER, S.; JULIER, S.; MACINTYRE, B.
Recent Advances in Augmented Reality. IEEE Computer Graphics and Applications, v. 21,
n. 6, p. 34-47, nov./dez. 2001.
66
REFERÊNCIAS
[15] Introduction to Augmented Reality. Disponível: Jim Vallino’s RIT SE Department Home
Page site. URL: http://www.se.rit.edu/~jrv/. Consultado em 11 jan. 2006.
[16] WAGNER, D.; SCHMALSTIEG, D. First Steps Towards Handheld Augmented Reality. In:
INTERNATIONAL SYMPOSIUM ON WEARABLE COMPUTERS (ISWC), 7., 2003, USA,
Proceedings... Washington: IEEE Computer Society, 2003. p. 127-137.
[17] PIEKARSKI, W.; THOMAS, B. ARQuake: The Outdoor Augmented Reality Gaming
System. Communications of the ACM, v. 45, n. 1, p. 36-38, jan. 2002.
[18] ULLMER, B.; ISHII, H. Emerging Frameworks for Tangible User Interfaces. IBM Systems
Journal, v. 39, n. 3/4, p. 915-931, 2000.
[19] BUCHMANN, V.; VIOLICH, S.; BILLINGHURST, M.; COCKBURN, A. FingARtips –
Gesture Based Direct Manipulation in Augmented Reality. In: INTERNATIONAL
CONFERENCE ON COMPUTER GRAPHICS AND INTERACTIVE TECHNIQUES
(GRAPHITE), 2., 2004, Singapore, Proceedings... New York: ACM Press, 2004. p. 212-221.
[20] REITMAYR, G. and SCHMALSTIEG, D. “Data Management Strategies for Mobile
Augmented Reality”, in STARS, 2003.
[21] BILLINGHURST, M.; CHEOK, A.; KATO, H. and PRINCE, S. “Real World
Teleconferencing”, in Computer Graphics and Applications, IEEE, 2002.
[22] HAUBER, J.; BILLINGHURST, M. and REGENBRECHT H. “Tangible Teleconferencing”,
in Lecture Notes in Computer Science, Springer Berlin / Heidelberg, 2004.
[23] BUCOLO, S.; BILLINGHURST, M. and SICKINGER, D. “User Experiences with Mobile
Phone Camera Game Interfaces”, in Proceedings of the 4th International Conference on
Mobile and Ubiquitous Multimedia, Christchurch, New Zealand, 2005.
[24] WOODS, E.; BILLINGHURST, M.; ALDRIDGE, G.; GARRIE B.; LOOSER, J.; BROWN, D.
and NELLES, C., “Augmenting the Science Centre and Museum Experience”, in
Proceedings of the 2nd international conference on Computer graphics and interactive
techniques in Australasia and South East Asia, Singapore, 2004.
[25] HENRYSSON, A.; BILLINGHURST, M. and OLLILA, M. “Face to Face Collaborative AR
on Mobile Phones”, in Proceedings of ISMAR 2005, Vienna, Austria, 2005.
[26] HENRYSSON, A. and OLLILA, M. “UMAR – Ubiquitous Mobile Augmented Reality”, in
Proceedings of ACM International Conference on MUM, pp. 41-45, 2004.
[27] PASMAN, W.; WOODWARD, C.; HAKKARAINEN, M.;
HYVÄKKÄ, J. “Augmented reality with large 3D models on
performance and use experiences”. In Proceedings of the
international Conference on Virtual Reality Continuum and Its
ACM Press, Singapore, June 16- 18, 2004.
HONKAMAA, P. and
a PDA: implementation,
2004 ACM SIGGRAPH
Applications in industry,
[28] WAGNER, D. and SCHMALSTIEG, D. "First Steps Towards Handheld Augmented
Reality," In Seventh IEEE International Symposium on Wearable Computers, IEEE Press,
New York, (ISWC'03), 2003.
67
REFERÊNCIAS
[29] Detalhes do Dell Axim x51v de 624MHz. Disponívem em: Dell site. URL:
http://www1.la.dell.com/content/products/productdetails.aspx/axim_x51v?c=br&l=pt&s=d
hs. Consultado em 10 fev. 2007.
[30] Nokia
Nokia
N93.
Disponivem
em:
Nokia
site.
http://www.nokia.com.br/nokia/0,,95498,00.html. Consultado em 10 fev. 2007.
URL:
[31] LEPETIT, V.; VACCHETTI, L.; THALMANN, D. and FUA, P. “Fully Automated and
Stable Registration for Augmented Reality Applications”, International Symposium on
Mixed and Augmented Reality, 2003.
[32] Computer
Vision
Laboratory.
Disponível:
CVLAB
site.
http://cvlab.epfl.ch/research/augm/augmented.html, consultado em 10 fev. 2006.
URL:
[33] RASKAR, R.; WELCH, G.; LOW, K.; BANDYOPADHYAY, D. “Shader Lamps: Animating
Real Objects With Image-Based Illumination”, Eurographics Workshop on Rendering
Techniques, London, UK, 2001.
[34] PIEKARSKI, W. and THOMAS, B. “ARQuake: The Outdoor Augmented Reality Gaming
System”. ACM Communications, 45(1), 2002, pp 36-38.
[35] FARIAS, T.; TEIXEIRA, J. M.; RODRIGUES, C. E.; PESSOA, S.; COSTA, N.; TEICHRIEB,
V.; KELNER, J. CIDA: an interaction devices management platform. In: Symposium on
[36] OpenGL - The Industry Standard for High Performance Graphics. Disponívem em:
OpenGL site. URL: http://www.opengl.org. Consultado em 10 fev. 2007.
[37] Ogre3D: Open source graphics engine. Disponívem
http://www.ogre3d.org. Consultado em 10 fev. 2007.
em:
Ogre3D
site.
URL:
[38] Shader. Disponível em: Wikipedia site. URL: http://en.wikipedia.org/wiki/Shader.
Consultado em: 10 fev. 2007.
[39] ARToolKit Documentation. Disponível: Human Interface Technology Laboratory site.
URL: http://www.hitl.washington.edu/artoolkit/documentation/. Consultado em 25 dez.
2005.
[40] FARIAS, T., LIMA, J.; TEICHRIEB, V. and KELNER, J. “OgreAR: construção de aplicações
de realidade aumentada utilizando bibliotecas de alto nível”, Workshop de Aplicações de
Realidade Virtual, Sociedade Brasileira de Computação, Recife, 21-24 de Novembro, 2006.
[41] WAGNER, D. and SCHMALSTIEG, D. “ARToolkit on the PocketPC Platform”,
International Augmented Reality Toolkit Workshop, IEEE Computer Society, USA, 2003.
[42] ARToolKitPlus. Disponível em: Handheld Augmented Reality site. URL:
http://studierstube.icg.tu-graz.ac.at/handheld_ar/artoolkitplus.php. Consultada em 10 fev.
2007.
[43] Vincent, the 3-D Rendering Library for Pocket PCs and Smartphones based on the
Published OpenGL. Disponível: SourceForge site. URL: http://ogl-es.sourceforge.net,
consultado em Fevereiro 2006.
68
REFERÊNCIAS
[44] Hybrid Graphics Ltd – Developer Tools. Disponível: Hybrid Graphics site. URL:
http://www.hybrid.fi/main/products/devtools.php, consultado em Fevereiro 2006.
[45] Klimt – the Open Source 3D Graphics Library for Mobile Devices. Disponível: Graz
University of Technology site. URL: http://studierstube.icg.tu-graz.ac.at/klimt, consultado
em Janeiro 2006.
[46] Direct3D
Mobile.
Disponível:
Microsoft
Developer
Network
site.
URL:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/wcemultimedia5/html/wce50oriDirect3DMobile.asp, consultado em Fevereiro 2006.
[47] Q.H. Mahmoud. Getting Started with the Mobile 3D Graphics API for J2ME. Disponível:
Sun
MicroSystems,
Inc.
site.
URL:
http://developers.sun.com/techtopics/mobility/apis/articles/3dgraphics/index.html,
consultado em 2006.
[48] LIMA, J. P.; FARIAS, T.; TEICHRIEB, V. and KELNER, J. Port of the OGRE 3D engine to
the pocket pc platform. In: Symposium on Virtual Reality, 2006, Belém. Porto Alegre: SBC,
2006. p. 65-76.
[49] EGL. Disponível em: Khronos Group site. URL: http://www.khronos.org/opengles/.
Consultado em 10 fev. 2007.
[50] HENRYSSON, A. and OLLILA, M. “UMAR - Ubiquitous Mobile Augmented Reality”,
Mobile Ubiquitous Multimedia, 2004.
[51] GOMES NETO, S.; FARIAS, T.; TEICHRIEB, V. and KELNER, J. Criação de aplicações de
realidade aumentada em dispositivos móveis baseados em Symbian OS. In: Workshop de
Realidade Aumentada, 2006, Rio de Janeiro. p. 16-19.
[52] Ubiquitous
Mobile
Augmented
Reality.
Disponível:
NVIS
http://staffwww.itn.liu.se/~andhe/UMAR/ Consultado em 03 ago. 2006.
site.
URL:
[53] KATO, H.; BILLINGHURST, M. and POUPYREV, I. "ARToolKitVersion 2.33", 2000, pp. 2229, Manual Técnico.
[54] Series 60 Developer Platform: Emulator Configuration. Version 1.1. 2004, 16p. Manual
Técnico.
[55] HARRISON, R. Symbian OS C++ for Mobile Phones, John Wiley & Sons, vol. 2, pp. 207208, 2004.
[56] BRUNNER M. “Ambient Network Management – Solution Design and Functions”,
Deliverable D8.2, WWI Ambient Network Project, July 2005.
[57] WWI Ambient Networks. Disponível: Ambient Network site. URL: http://www.ambientnetworks.org/, Consultado em 8 set.2006.
[58] Technical objectives of the Ambient Networks Project. Disponível: Ambient Network site.
URL: http://www.ambient-networks.org/main/technical_objectives.html. Consultado em
30 ago. 2006.
69
REFERÊNCIAS
[59] HARTUNG, F.; HERBORN, S.; KAMPMANN, M. and SCHMID, S. "Smart Multimedia
Routing and Adaptation using Service Specific Overlay Networks in the Ambient
Networks Framework“, Proceedings 12. Wireless World Research Forum (WWRF)
Meeting, November 2004, Toronto/Canada.
[60] GUSTAFSSON, E. and JONSSON, A.
Communications, 10(1):49–55, Feb 2003.
Always
best connected.
IEEE
Wireless
[61] NIEBERT N. et al. “Ambient Networks: An Architecture for Communication Networks
Beyond 3G”, IEEE Wireless Communications, April 2004.
[62] KAMIENSKI, C., et al. "PBMAN: A Policy-based Management Framework for Ambient
Networks", 7th IEEE Workshop on Policies for Distributed Systems and Networks, June
2006
[63] KAMIENSKI, C., et al. “On the Use of Peer-to-Peer Architectures for the Management of
Highly Dynamic Environments”, 3rd Workshop on Mobile Peer-to-Peer Systems
(MP2P’06), March 2006.
[64] ROCHA JR., J., et al. “X-Peer: A Middleware for Peer-to-Peer Applications”, 1st Brazilian
Workshop on Peer-to-Peer, May 2005.
[65] NGUYEN T. H. D. et al. "Real-Time 3D Human Capture System for Mixed-Reality Art and
Entertainment". In: IEEE TRANSACTIONS ON VISUALIZATION AND COMPUTER
GRAPHICS, VOL. 11, NO. 6, NOVEMBER/DECEMBER 2005. p. 706-721.
[66] OpenH323 Project. Disponível:
Consultado em 10 fev. 2007.
OpenH323
site.
URL:
http://www.openh323.org/.
70

FARIAS, Thiago. A2: um modelo de referência para

Transcrição

Documentos relacionados

Curriculum Vitae

Já imaginou ler e enviar seus e-mails a qualquer hora e em

Omni Marker

Ficha de Protótipo Gamerama Qual o nome do jogo? Ilha do

Realidade Aumentada Aplicada a Medicina

Higiene €20,78 Higiene

estudo piloto. 2006.2.

Novo estilo de vida: mobile life

NEXUS POCKET PC

Grupo Vila com versão mobile de seu site Acessando de qualquer