Prototipagem Rápida de Aplicações Interativas de

KIRNER, C. Prototipagem Rápida de Aplicações Interativas de Realidade
Aumentada. Tendências e Técnicas em Realidade Virtual e Aumentada, SBC, Porto
Alegre, V. 1, N. 1, 2011, p. 29-54.
Prototipagem Rápida de Aplicações Interativas
de Realidade Aumentada
Claudio Kirner
Abstract
Augmented reality applications are interesting, but they are difficult to develop and
customize, mainly by non-expert people. However, there are authoring tools which make
easy this development. This chapter focuses on the augmented reality authoring
problem, related to the development and use of applications. It describes an authoring
tool, showing how to use it on rapid prototyping of augmented reality interactive
applications, without the need of programming skills. A developed example using this
tool is described and the impact of this approach is discussed, considering different
types of potential authors and applications.
Resumo
As aplicações de realidade aumentada são interessantes, mas difíceis de serem
desenvolvidas e personalizadas, principalmente por não especialistas em computação.
No entanto, existem ferramentas de autoria que facilitam esse desenvolvimento. Este
texto aborda o problema da autoria de aplicações de realidade aumentada, relacionado
com o desenvolvimento e uso das aplicações, em diversos níveis. É descrita uma
ferramenta de autoria e seu uso na prototipagem rápida de aplicações interativas de
realidade aumentada por não programadores. Também é mostrado um exemplo
desenvolvido com esta técnica e as repercussões dessa abordagem são discutidas,
levando em conta os diversos tipos de autores e aplicações em potencial.
1. Introdução
As aplicações espaciais mediadas por computador, incluindo navegação, busca de pontos
de interesse, jogos tridimensionais, ferramentas educacionais tridimensionais, etc., estão
aumentando com o uso de Realidade Aumentada.
Atualmente, a convergência tecnológica permite o desenvolvimento de aplicações
que envolvem diferentes recursos funcionando juntos, como: GPS, acelerômetros,
câmeras, telefones celulares, notebooks, ipads, etc. A criação dessas aplicações depende
fortemente de programadores e técnicos.
Entretanto, há muitas pessoas sem conhecimento de programação, interessadas
em desenvolver aplicações de realidade aumentada. Para contornar esse problema,
algumas ferramentas de autoria de aplicações estão fornecendo recursos para não
programadores, a fim de que eles possam criar suas próprias aplicações [Seitchter,
Looser e Billinghurst 2008]. É importante mencionar que essas aplicações devem ser
independentes de compiladores, usando, no entanto, edição de texto, procedimentos de
configuração, interface visual e ações tangíveis.
Portanto, a principal questão deste trabalho é: como não programadores
poderiam desenvolver suas próprias aplicações de realidade aumentada, usando recursos
de edição e configuração de parâmetros textuais e manipulação de elementos espaciais?
Para responder essa questão, será feita, inicialmente, uma contextualização dos conceitos
envolvidos, levando em conta o estado da arte da tecnologia. Depois, será realizada uma
análise das ferramentas de autoria de aplicações de realidade aumentada, enfatizando
suas características relacionadas com independência de programação e/ou conhecimentos
técnicos. Em seguida, a ferramenta “Sistema de Autoria Colaborativa com Realidade
Aumentada” (SACRA) será descrita e discutida, sob o ponto de vista da geração de
aplicações. Os recursos de suporte à ferramenta SACRA serão analisados e descritos e
um exemplo de aplicação será detalhado. Finalmente, serão apresentadas as tendências
da área de realidade aumentada e suas aplicações, procurando destacar características
como custo, disponibilidade, adaptação, customização e personalização.
2. Conceitos de Realidade Virtual e Aumentada
Realidade Virtual (RV) e a Realidade Aumentada (RA) tiveram seus conceitos
originados na década de 1960, com os trabalhos de Ivan Sutherland [Sutherland 1963,
1965, 1968]. De lá para cá, muita coisa mudou e a tecnologia evoluiu, exigindo, em
certos casos, uma atualização dos conceitos.
2.1. Realidade Virtual
A RV surgiu como uma primeira opção de interface tridimensional, propiciando ao
usuário interações naturais, com o uso das mãos, em ambientes virtuais renderizados na
tela do monitor, em projeções em tela, ou em projeções nos olhos, através de capacetes
de RV (Head Mounted Display – HMD). Para a interação com os elementos virtuais, são
necessários dispositivos especiais multisensoriais, como luvas com sensores e
rastreadores, dispositivos de tato e força, mouses 3D, óculos estereoscópicos, emissores
de sons espaciais, etc.
Uma definição de RV é: “realidade virtual é uma interface computacional
avançada que envolve simulação em tempo real e interações, através de canais
multisensoriais” (Burdea e Coiffet 2003).
Outra definição, mais específica, é: realidade virtual é uma interface
computacional que permite ao usuário interagir, em tempo real, em um espaço
tridimensional gerado por computador, usando seus sentidos, através de dispositivos
especiais.
O usuário pode perceber o mundo virtual, através de uma janela constituída pela
tela do monitor ou pela tela de projeção, ou ser inserido no mundo virtual, através de
HDM ou de salas com multiprojeção (cavernas) e dispositivos de interação.
Quando o usuário é transportado totalmente para mundo virtual, através de
dispositivos multisensoriais como HDM e salas de multiprojeção, a realidade virtual é
denominada “Imersiva” (Figura 1a). Quando o usuário é transportado parcialmente,
percebendo o mundo virtual através de uma janela, como a tela do monitor ou
equivalente, a realidade virtual é denominada “Não Imersiva” (Figura 1b).
a)
RV imersiva
b) RV não imersiva
Figura 1. Realidade virtual imersiva e não imersiva
2.2. Realidade Aumentada
A definição de RA tem sido atualizada, em função da evolução tecnológica. Inicialmente,
o aumento do ambiente real ocorria através de elementos visuais; mas, com o
desenvolvimento de interações sonoras e hápticas associadas a posições espaciais,
ocorrendo em tempo real, houve uma expansão no conceito.
Neste contexto, uma definição mais abrangente é que realidade aumentada
consiste no enriquecimento do mundo físico com objetos virtuais devidamente
posicionados em tempo real, através de algum dispositivo tecnológico. A Figura 2 ilustra
o resultado do enriquecimento do mundo físico com elementos virtuais.
Figura 2. Ambiente de realidade aumentada
Uma definição mais atualizada é: realidade aumentada é uma interface baseada na
sobreposição de informações virtuais geradas por computador (envolvendo imagens
estáticas e dinâmicas, sons espaciais e sensações hápticas) com o ambiente físico do
usuário, percebida através de dispositivos tecnológicos e usando as interações naturais
do usuário, no mundo físico.
Uma maneira de trazer as informações virtuais para o espaço físico do usuário é
usando uma webcam, que captura dinamicamente as imagens do ambiente físico e
rastreia determinadas posições, permitindo que o computador introduza ou acione
informações virtuais associadas com as posições. O resultado pode ser visto, ouvido e
sentido em monitores, projeções, capacetes e dispositivos hápticos, dando sensação de
realismo ao ambiente híbrido.
3. Trabalhos Relacionados
Durante os últimos dez anos, surgiram várias ferramentas de autoria de aplicações de
realidade aumentada, voltadas para o desenvolvimento de aplicações especiais mediadas
por computador.
Essas ferramentas podem ser classificadas, de acordo com suas características de
programação e de projeto de conteúdo em baixo nível e alto nível, apresentando
diferentes abstrações de conceito e complexidade de interface [Hampshire et al. 2006],
[Seitchter, Looser e Billinghurst 2008].
Programação é, geralmente, mais complexa, apresentando mais flexibilidade e
possuindo menor nível de abstração de conceito do que projeto de conteúdo. Projeto de
conteúdo tende a ser menos complexo e flexível, apresentando maior nível de abstração
de conceito. Portanto, conforme a abstração de conceito aumenta, a interface fica mais
simples e menos flexível.
Ferramentas de programação são baseadas em APIs básicas ou avançadas,
contendo bibliotecas, envolvendo tarefas como: visão computacional, ajustes de imagem,
renderização tridimensional, sons, entrada e saída e outras funções. ARToolKit [Kato e
Billinghurst 1999], MR [Uchiyama et al. 2002] em MX [Dias et al. 2003] são exemplos
de ferramentas de programação de baixo nível, enquanto que Studierstube [Schmalstieg
et al. 2002], OrgArt [Looser 2006] e DWARF [Bauer et al. 2001] são ferramentas de
programação de alto nível.
ARToolKit é uma das primeiras ferramentas de realidade aumentada que usam
marcadores e visão computacional. Para utilizá-la criar aplicações de realidade
aumentada, os desenvolvedores precisam ter habilidades com programação em C/C++.
Ferramentas de projeto de conteúdo eliminam a dependência da linguagem de
programação, substituindo-a pela descrição dos objetos virtuais e de seus
relacionamentos com o ambiente real.
APRIL [Ledermann e Schmalstieg 2005] é um exemplo de baixo nível desse tipo
de ferramenta, que requer descrições em XML. Ferramentas de projeto de conteúdo de
alto nível usam interfaces gráficas de usuários (GUI) para representar as descrições e
interações, como ocorre com: DART [MacIntyre et al. 2004], AMIRE [Grimm 2002],
ECT [Hampshire et al, 2006], ComposAR [Seitchter, Looser e Billinghurst 2008] e
ARSFG [Di Wu e Liu 2009].
DART é uma ferramenta implementada sobre o Macromedia Director, usando
um modelo de autoria visual do tipo “pegar-arrastar-soltar” e uma linguagem de script
(descrições textuais) interpretada.
AMIRE baseia-se em uma estrutura que usa a tecnologia orientada a
componentes, apresentando: um conjunto mínimo de componentes para demonstração,
uma coleção de recursos reusáveis e uma ferramenta de autoria visual.
ECT é uma ferramenta de software orientada a componentes, com uma interface
de programação visual projetada para facilitar o desenvolvimento de aplicações de
realidade aumentada, por usuários com pouca ou nenhuma experiência em programação.
ComposAR é uma ferramenta extensível, para autoria de aplicações de realidade
aumentada por usuários não programadores. Ela suporta script e interface do tipo
“pegar-arrastar-soltar”, além de entrada interpretada em tempo real e funcionalidades
adicionadas por usuários.
ARSFG é uma ferramenta de software para prototipagem rápida de aplicações de
realidade aumentada, baseada em grafos de cena, que permite colaboração remota
através de protocolo baseado em XML.
Um projeto de conteúdo em alto nível deve ser mais intuitivo e adequado para
não programadores. Por isso, exige que suas ferramentas suportem script e/ou interface
visual, novas funcionalidades adicionadas pelos usuários e interpretação em tempo real.
A ferramenta SACRA, enfocada nesse trabalho, difere das demais aqui indicadas,
uma vez que possui as seguintes características:
- A ferramenta foi implementada sobre o ARToolKit;
- A autoria de aplicações depende da edição de arquivos de configuração e/ou de
operações tangíveis;
- Há diferentes níveis de autoria, que podem ser usados, dependendo das habilidades
dos desenvolvedores, que não precisam ser programadores;
- Há um suporte colaborativo que permite múltiplos usuários remotos atuando no
ambiente compartilhado de realidade aumentada, usando ações tangíveis.
- O desenvolvedor das aplicações pode usar ações tangíveis, edição de arquivos de
configuração, e mouse e teclado, mas o usuário final poderá interagir com a
aplicação de realidade aumentada, usando somente um ou dois marcadores.
4. Descrição da Ferramenta SACRA
O desenvolvimento de aplicações de realidade aumentada depende de: estrutura de dados
e pastas que suportam a ferramenta de autoria; interface de autoria, incluindo tarefas de
configuração e comandos; e procedimentos de utilização que permitem ao usuário final
navegar ambiente aumentado e interagir com ele.
Para facilitar o desenvolvimento de aplicações de realidade aumentada, foi criada
a ferramenta de autoria SACRA - Sistema de Autoria Colaborativa com Realidade
Aumentada [Kirner e Santin 2009]. Essa ferramenta apresenta características próprias de
autoria e de uso, além de possibilitar a colaboração remota compartilhada.
A ferramenta SACRA foi construída sobre o ARToolKit, incluindo também
funcionalidades adicionais programadas em C/C++. Manuais e exemplos de aplicação do
SACRA são distribuídas livremente pelos autores [Kirner 2011].
4.1. Estrutura do Ambiente de Realidade Aumentada
RA envolve muito mais do que sobrepor objetos virtuais com o mundo físico. Neste
trabalho, o ambiente aumentado (Figura 3a) contém: objetos reais; objetos virtuais
interativos, que são alterados em certas situações; objetos virtuais animados, que podem
ser ativados ou desativados; objetos virtuais visíveis ou invisíveis, que desaparecem e
aparecem em certos casos; pontos virtuais visíveis ou invisíveis, que podem ser ativados
ou desativados; sons associados aos objetos; e pontos, que podem ser acionados ou
desacionados, etc.
Além disso, o ambiente de realidade aumentada pode ser modificado, depois de
ser elaborado, usando criação, alteração e eliminação de pontos virtuais, objetos virtuais
e sons associados.
a) Ambiente aumentado
b) Estrutura de dados
c) Pastas do desenvolvedor
Figura 3. Organização do ambiente de RA
4.2. Estrutura de Dados e Pastas
A estrutura de dados do ambiente de RA (Figura 3b) a ser elaborado, tem como raiz os
marcadores de referência. Um marcador de referência possui uma base virtual associada,
contendo pontos virtuais, objetos virtuais e sons que aparecem ou são adicionados na
base, de acordo com a Figura 3a. Esses elementos devem ser colocados em pastas
(Figura 3c), que o desenvolvedor deverá manipular para criar o ambiente de RA.
A ferramenta tem cinco tipos de pastas, configuráveis pelo desenvolvedor, sendo
que algumas delas podem conter arquivos também configuráveis. Essas pastas referem-se
a: posição dos pontos virtuais; posição dos objetos virtuais; objetos virtuais; texturas e
sons. Os sons podem ser associados aos objetos virtuais ou, na falta deles, às posições
dos pontos virtuais (Figura 3c). Dependendo do tipo de aplicação e do nível de autoria, o
desenvolvedor poderá manipular um conjunto menor de pastas, envolvendo somente
texturas e sons, por exemplo. Neste caso, a autoria fica extremamente simplificada,
embora restrita, permitindo que pessoas com pouco conhecimento de informática
possam ser autores de ambientes de realidade aumentada.
Nas seções seguintes, serão apresentados exemplos desse tipo de autoria, que é
muito útil para a área educacional, permitindo que professores do ensino fundamental e
médio, com poucos recursos e conhecimento na área de informática, possam desenvolver
aplicações educacionais específicas.
4.3. Interfaces de Autoria
Na fase de autoria, a aplicação de RA pode ser desenvolvida por meio de edição de
pastas e arquivos e/ou ações tangíveis realizadas no campo de visão da webcam. Os
recursos necessários para criar pontos virtuais, associando a eles objetos virtuais e sons,
são: marcadores de ações; botões do teclado; botões do mouse; e pastas e arquivos de
configurações.

Marcadores de Ações
Marcadores de ações permitem a execução de ações tangíveis capazes de manipular
pontos e objetos virtuais associados à base virtual, conforme a Figura 4.
Ambiente físico
Figura 4. Ambiente de RA e seus marcadores
Nesse ambiente, pontos e objetos virtuais, ligados a um marcador de referência,
possuem pequenas esferas virtuais visíveis ou invisíveis com eles associadas. Cada
marcador de ação também tem uma pequena esfera, virtual que pode ser manipulada pelo
usuário, visando colidí-la com alguma esfera associada ao marcador de referência.
Quando o marcador de ação é movimentado no ambiente de realidade
aumentada, sua esfera virtual serve como um ponteiro capaz de tocar as esferas virtuais
associadas ao marcador de referência, executando ações nos pontos ou objetos virtuais
correspondentes. As colisões, que selecionam os pontos ou objetos virtuais, dependem
de certas situações do marcador de ação, para que as ações sejam executadas. No
SACRA, a colisão mantida por alguns milissegundos é que seleciona o objeto, mas
gestos como inclinação ou oclusão do marcador também podem ser usados em certas
situações.
Os marcadores de ações usados no SACRA são:
- Inspeção: mostra o objeto virtual associado ao ponto virtual;
- Controle: mostra o próximo objeto virtual de uma lista de objetos associados ao
ponto virtual;
- Transporte: leva um objeto virtual de uma posição para outra;
- Apagamento: apaga um ponto virtual e seu objeto ou lista de objetos;
- Status: mostra uma placa virtual com informações sobre o sistema;
- Trava: trava ou destrava ações remotas em objetos associados a um ponto virtual;
- Cópia: replica o objeto virtual a ser colocado em outra posição de outro marcador
de referência;
- Trajetória: permite criação e visualização de uma trajetória visual feita de uma
posição a outra.

Teclado e Mouse
Algumas teclas do teclado e botões do mouse podem ativar ações complementares no
ambiente de RA, atuando sozinhos ou em conjunto com os marcadores de ações.
Essas teclas e botões podem ativar ou desativar: visualização de pontos e objetos
virtuais; operações remotas; criação de trajetórias; visualização de status; persistência de
objetos virtuais; etc. Eles também podem controlar a posição e o raio das esferas virtuais
associadas com os marcadores, para melhorar a precisão e desempenho no processo de
seleção de pontos e objetos virtuais. Quanto menor for o raio das esferas virtuais, maior
será a dificuldade de seleção; mas, em alguns casos, quando houver pontos próximos,
será necessário obter melhor precisão, para ser bem sucedido na operação.
O botão do mouse, atuando conjuntamente com o marcador de inspeção,
permitirá a criação visual de pontos virtuais no ambiente de realidade aumentada,
possibilitando uma reconfiguração posterior através da edição de arquivos de
configuração.
A lista de teclas e ações do mouse que são considerados no SACRA pode ser
obtida no site da ferramenta [Kirner 2011].

Arquivos de Configuração
Os arquivos de configuração do SACRA podem ser criados pelo usuário ou editados, a
partir dos arquivos contidos na versão de distribuição (Figura 5). Além disso, também é
possível editar os arquivos gerados no processo de criação visual de pontos virtuais.
Esses arquivos contêm informações de autoria fornecidas pelo usuário, de forma
a preparar o sistema para uso ou para configurações visuais complementares.
Os arquivos de configuração editáveis são:
a) Arquivo do Marcador de Referência (refi.dat), contendo:
- indicação da base virtual associada com o marcador;
- posição, orientação e escala da base virtual;
- indicação do som associado com a base virtual, se existir;
- indicação da lista de pontos virtuais;
- indicação do ponto virtual de ativação da lista.
Figura 5. Pastas e arquivos da versão de distribuição do SACRA
Esse arquivo encontra-se na pasta <SACRA\Wrl\reference>, na versão de
distribuição, tendo a aparência mostrada na Figura 6a.
Figura 6. Arquivos de configuração do SACRA
b) Arquivo da Lista de Pontos de um Marcador de Referência (prefi.dat), contendo:
- posição e orientação do ponto que irá receber a lista de objetos virtuais e sons;
- endereço da lista de objetos virtuais com seus sons.
Esse arquivo encontra-se na pasta <SACRA\position>, na versão de distribuição
(Figuras 6b1 e 6b2).
O arquivo da Figura 6b1 foi criado por meio de edição e mostra um ponto virtual
com uma lista de objetos.
O arquivo da Figura 6b2 mostra três pontos virtuais, cada um com uma lista
diferente de objetos. Esses pontos virtuais foram criados por autoria visual, motivo pelo
qual possuem parâmetros não exatos.
c) Arquivo de uma Lista de Objetos Virtuais de um Ponto (ex. animais.dat), contendo:
- objeto virtual 1:
- indicação do modelo 3D do objeto virtual 1;
- posição, orientação e escala do objeto virtual 1;
- indicação do som associado com o objeto virtual 1.
- objeto virtual m;
- informações similares no objeto virtual 1.
Um editor de texto simples, como o bloco de notas, pode ser usado para criar ou
editar os arquivos de configuração.
Esse arquivo encontra-se na posição <SACRA\animais>, na versão de
distribuição (Figura 6c).

Pastas
As pastas mencionadas aqui são recursos preenchidos pelo desenvolvedor não
programador, contendo informações úteis para a criação do ambiente de RA aumentada.
Há quatro pastas no sistema SACRA, contendo: informações de configuração de
posição de pontos (position); lista de objetos virtuais, contendo informações de
configuração de posições dos objetos virtuais e sons e os próprios objetos virtuais (ex.
animais); sons (audio); e texturas (textura), conforme a Figura 7.
Figura 7. Hierarquia de recursos do SACRA
A pasta de informações de posição de pontos (position) contém arquivos de
configuração relativos aos marcadores de referência, indicando seus pontos e listas de
objetos virtuais. A pasta com uma lista de objetos virtuais (ex. animais) contém o
arquivo de configuração dos objetos da lista, indicando suas posições e os sons
associados, e os próprios objetos virtuais. A pasta de sons contém todos os sons usados
no sistema, incluindo as narrações. A pasta de texturas (textura) contém imagens usadas
nos objetos virtuais para dar mais realismo ou passar informações.
Os conteúdos das pastas devem ser ali colocados antes de serem usados, mas
alguns deles podem ser modificados durante a fase de utilização, principalmente os
arquivos de configuração.
O SACRA também tem comandos para salvar e restaurar o ambiente de RA, de
forma que a autoria possa ser interrompida e continuada depois.

Procedimentos de Utilização
Na fase de utilização, o usuário final deverá manipular o ambiente de realidade
aumentada, usando ações tangíveis com marcadores específicos.
Os marcadores mais usados são os de Inspeção e Controle, que permitem a
exploração do ambiente, mostrando os objetos virtuais e os sons associados em cada
ponto.
Entretanto, visando deixar o sistema mais potente, é possível reconfigurar o
ambiente durante a fase de utilização, alterando o ambiente de RA inicialmente
projetado. Esse procedimento permite uma personalização do ambiente. O usuário,
poderá então mudar a visibilidade dos pontos e objetos virtuais, trocar alguns objetos
virtuais por outros, fazer cópia e movimentar objetos virtuais, eliminar pontos e objetos
virtuais, etc. Essas ações são simples e requerem menor esforço, em comparação com a
autoria inicial.
Assim, a reconfiguração estática do ambiente de realidade aumentada, obtida
através de edição de arquivos de configuração, juntamente com a reconfiguração
dinâmica, obtida por meio de alteração de elementos do ambiente e de ações tangíveis
importantes para a personalização da aplicação, são muito úteis em jogos e em
aplicações educacionais.
Além disso, o sistema tem um marcador de referência especial (Ref1), que
permite interligar vários usuários em rede, atuando sobre o mesmo ambiente de Ra e
proporcionando trabalhos colaborativos remotos. Quando o usuário coloca o marcador
de referência colaborativo (Ref1), ele é conectado à rede e passa a interagir em um
ambiente compartilhado de RA, explorando e alterando os elementos local e
remotamente. Esta característica é muito útil em jogos e aplicações educacionais,
permitindo o trabalho em grupo de usuários remotos.
5. Recursos para o Desenvolvimento de Aplicações de RA
Além da ferramenta de autoria SACRA, o desenvolvedor precisará conhecer e usar
alguns softwares para ter sucesso na elaboração do ambiente de RA. Ele deverá ser
capaz de capturar, produzir e editar imagens, sons e objetos virtuais estáticos e
animados.
5.1. Preparação de Imagens
As imagens, no ambiente de realidade aumentada, são utilizadas como texturas para os
objetos virtuais, visando fornecer maior realismo ou renderizar informações (figuras e
anotações) para os usuários.
Essas texturas podem ser feitas à mão e escaneadas, capturadas de bibliotecas em
repositórios multimídia ou produzidas com o uso de editores de texto e de imagens.
Qualquer editor de texto ou de texto e imagem, como Bloco de Notas, Word,
PowerPoint ou recursos do OpenOffice, pode ser útil na elaboração da textura.
Para capt urar texturas da tela do computador, no formato jpg, usa-se
capturadores de imagem como o Free Screen Hunter, por exemplo. Deve-se ter um
cuidado especial para que os arquivos das texturas capturadas, produzidas ou editadas
sejam leves, mas mantendo boa qualidade de imagem, para que a aplicação, envolvendo
um grande número de texturas, não dificulte o processo de distribuição pela Internet.
5.2. Preparação de Sons e Narrações
Os sons, acionados quando os objetos virtuais são ativados, podem ser ruídos ou
narrações. Eles podem ser obtidos de repositórios ou gravados. No caso de narrações, a
gravação é mais apropriada, uma vez que dificilmente será encontrada uma narração
específica.
Qualquer software de gravação de som pode ser usado, desde que o arquivo
resultante seja leve e do tipo wav, pelos mesmos motivos já explicados para imagens.
Um software de gravação de sons interessante é o Free Sound Recorder, que é
bem intuitivo e permite a seleção de qualidade do som. Para narrações, pode-se usar uma
qualidade baixa, pois o interesse está na informação narrada.
5.3. Preparação de Objetos 3D e Animações
Como o SACRA é baseado em objetos virtuais do tipo VRML, é necessário que a
captura, produção e edição desses objetos tenha capacidade para tratar esse formato.
A captura de objetos 3D de repositórios VRML está ficando difícil, uma vez que
esse formato é um pouco antigo. No entanto, é possível usar editores de modelos 3D que
convertem outros formatos para VRML, utilizando-se assim outros repositórios mais
recentes, como o Armazém 3D do Google.
Outra maneira de se obter os objetos virtuais VRML é produzí-los diretamente,
usando textos, ou visualmente usando ferramentas como Vivaty, Blender, SketchUp,
3DS Max, etc., que possuem recursos para exportação dos modelos em VRML.
Além do modelo estático, é muito útil dispor-se de modelos animados. Os
softwares de modelagem já citados fazem bem essa tarefa, com destaque para o Vivaty,
pela sua leveza e simplicidade.
Da mesma maneira que as imagens e sons, recomenda-se produzir arquivos leves
para o bom desempenho do SACRA, bem como para facilitar a distribuição da aplicação
de RA.
5.4. Outras considerações
Embora o uso de vídeo e de Gif animado seja interessante no ambiente de realidade
aumentada, o SACRA não permite esse tipo de recurso. No entanto, novas versões do
SACRA, como a que estamos desenvolvendo com FlartoolKit [Saquoosha 2011],
deverão permitir formatos de objetos 3D mais modernos, como COLLADA, e o uso de
vídeo e GIF animado, aplicados como texturas.
6. Prototipagem Rápida de uma Aplicação de Multimídia Espacial com RA
Embora o SACRA e outras ferramentas de autoria de aplicações de RA sejam potentes,
muitas vezes usa-se muito pouco de suas potencialidades para desenvolvimento de
aplicações mais simples. É o caso de aplicações de multimídia espacial com realidade
aumentada, que permite o acionamento de pontos no espaço para mostrar informações
interativas visuais e sonoras. Embora simples, essas aplicações atendem a maioria das
necessidades dos usuários em certos campos do conhecimento, além de serem mais
acessíveis e fáceis de serem personalizadas, por possuírem interfaces mais simples e
amigáveis. Por outro lado, essas aplicações não exploram todo potencial da renderização
tridimensional, mas este é o preço da simplicidade de elaboração e de uso da aplicação
de RA, usando multimídia espacial.
Para ilustrar o processo de prototipagem rápida de aplicações multimídia com
RA, será utilizado o desenvolvimento do jogo de perguntas e respostas P&R-RA (ou
Q&A-AR, em inglês).
O desenvolvimento do jogo pode ocorrer em dois níveis: 1º) desenvolvimento da
estrutura do jogo; 2º) desenvolvimento do conteúdo do jogo (Figura 8).
Figura 8. Diagrama de camadas de uma aplicação de RA com SACRA
Esses dois níveis de desenvolvimento podem ser obtidos por prototipagem
rápida, sendo que o primeiro, usando o SACRA, exige algum conhecimento de
modelagem 3D e posicionamento espacial, além de um certo domínio da linguagem
VRML e de suas ferramentas. O segundo nível limita-se ao desenvolvimento de
conteúdo (texturas e sons), permitindo que usuários sem conhecimento de programação
e com o mínimo conhecimento de informática, possam produzir suas próprias aplicações
com pouco esforço e rapidez. Essa situação encaixa-se perfeitamente no perfil dos
professores de ensino fundamental e médio, interessados em produzir aplicações
personalizadas para as suas salas de aula.
6.1. Descrição do Jogo Educacional de Perguntas e Respostas
O jogo educacional de perguntas e respostas suportado por RA foi elaborado como um
artefato formado por dois planos perpendiculares, contendo um plano vertical para
mostrar de perguntas e respostas e um plano horizontal para interação e
complementação de informações (Figura 9a).
a) Estrutura física
b) Estrutura virtual
Figura 9. Estrutura física e virtual do jogo
O jogo é baseado em uma corrida de carros, em que o sistema faz perguntas e os
usuários respondem e verificam se as respostas estão certas ou erradas. Se um usuário
acertar, ele ganhará pontos e receberá instruções para mover seu carro para frente, no
trajeto. Se errar, ele não ganhará pontos e receberá instruções para recuar seu carro no
trajeto. O conjunto de perguntas e respostas deverá ser focado em um determinado tema
ou poderá ser de conhecimentos gerais.
O jogo tem uma série de pontos físicos coloridos nos planos e sobre os carros,
além de pontos virtuais coincidentes com os pontos físicos (Figura 9b). Um ponteiro
físico com um marcador associado será o responsável pelas interações, de forma que a
ponta do marcador tenha um ponto virtual que fará colisão com os pontos virtuais dos
planos e dos carros (Figura 10a).
a) Recursos físicos móveis
b) Elementos de interação
Figura 10. Recurso físicos e virtuais do jogo
O ponto virtual de um carro só será ativável, quando o carro estiver sobre uma
célula da trajetória (Figura 10b), fazendo com que seu ponto físico coincida com o ponto
espacial da célula do trajeto.
a) Ambiente do jogo com RA
b) Interação entre pontos físicos e virtuais
Figura 11. Ambiente de RA e detalhes da interação
Para o jogo funcionar, o artefato deverá ser colocado no campo de visão da
webcam e seu aplicativo deverá ser executado. A visualização ocorrerá na tela do
monitor e o computador emitirá sons em resposta às interações (Figura 11a).
No primeiro toque no ponto da célula sobre o carro (Figura 12), o sistema
apresentará a pergunta ilustrada no plano vertical com as opções de resposta e
informações complementares no plano horizontal.
Figura 12. Ativação da pergunta
Além disso, o usuário deverá marcar, no plano horizontal, a opção que ele
acredita estar correta (Figura 13). Para isto ele deverá aproximar o ponteiro com o
marcador de Controle (C) do botão impresso, correspondente à opção que ele julga estar
correta, ativando-o, de forma a ficar na cor azul. Se o usuário decidir mudar a opção, ele
poderá desativar o botão ativado, usando novamente o ponteiro e ativar outro botão de
sua preferência.
Figura 13. Ativação da opção correta
O segundo toque no mesmo local (Figura 14) mostrará a resposta no plano
vertical e marcará a opção correta no plano horizontal. Se a opção marcada pelo sistema
coincidir ou não com a opção do usuário, ele identificará seu acerto ou erro e verá as
instruções sobre o que fazer, avançando ou recuando seu carro e anotando seus pontos.
Figura 14. Ativação da resposta
Finalmente, o usuário desativará os pontos ativos, preparando o jogo para o
próximo usuário, e moverá o seu carro para a nova posição, de acordo com as instruções
(Figura 15).
Figura 15. Desativando os pontos e movendo o carro
6.2. Implementação da Estrutura do Jogo
A estrutura física do jogo educacional foi construída com dois planos perpendiculares
feitos de isopor, mas poderiam ter sido usados outros materiais como madeira, plástico,
etc. O marcador, os pontos físicos (botões) e a trajetória com as células do jogo foram
impressos e colados. Os acessórios, como ponteiros com marcadores, dados e carros,
também foram construídos com isopor (Figura 9a).
A estrutura virtual foi constituída de planos e botões virtuais coincidentes com
seus equivalentes físicos (Figura 9b), para permitir a colocação de informações e
interação eficiente baseados nos elementos físicos. Ao interagir com elementos físicos, os
elementos virtuais serão acionados mostrando imagens e emitindo sons (Figuras 12 a
14).
O SACRA foi usado para o estabelecimento das posições dos pontos, objetos
virtuais e sons. O Vivaty foi usado para a modelagem dos objetos virtuais (VRML) e
vinculação com as texturas, contendo informações (perguntas, respostas e instruções)
para o usuário.
Os formatos do arquivo de posicionamento dos pontos, referente à estrutura
(pref2.txt), e dos arquivos com as listas de objetos virtuais de um ponto (path1.dat)
podem ser vistos na Figura 16. O jogo educacional poderá ser baixado para uso ou
alteração, a partir do site da ferramenta SACRA [Kirner 2011 ].
Figura 16. Arquivos da estrutura do jogo (pref2 e path1)
6.3. Desenvolvimento de Conteúdo e Personalização
Para permitir o desenvolvimento rápido de conteúdo, o jogo foi baseado em texturas e
sons (Figura 17) que podem ser preparados por usuários com poucos conhecimentos de
informática. Embora haja outras pastas de texturas (imagens que irão aparecer no
artefato), o desenvolvedor de conteúdo precisará acessar somente as pastas de perguntas
e respostas, utilizando os nomes dos arquivos, conforme a definição dada pelo sistema
como (qv1-1, qv1-2, qv1-n), (av1-1, av1-2, av1-n), (qh1-1, qh1-2, qh1-n) e (ah1-1, ah1-
2, ah1-n), para n perguntas no ponto 1, e assim por diante para os outros pontos da
trajetória, podendo variar o número de perguntas em cada ponto.
Figura 17. Conteúdo do jogo (texturas e sons) para uma pergunta e resposta
Essas texturas podem ser preparadas manualmente e escaneadas por usuários
com pouco conhecimento de informática, de forma a viabilizar o uso do artefato por
todos os interessados, mesmo que não possuam experiência no uso de recursos
computacionais. A Figura 18 mostra um conjunto de perguntas preparado por
professores do ensino de ciências do ensino fundamental e médio, simulando o trabalho
de usuário leigo em informática. Esse conteúdo foi preparado com escrita manual e
colagem de figuras e, em seguida, escaneado para uso no artefato.
Figura 18. Conteúdo feito à mão
Para os usuários com conhecimentos de informática suficientes para manipular
editores de textos e imagens, a montagem das perguntas e respostas fica mais simples
rápida, usando os recursos computacionais (Figura 19). Algum capturador de imagem da
tela do computador, como o Free Screen Hunter, será útil para a preparação das imagens
que serão usadas como texturas.
Figura 19. Conteúdo preparado com editores
Os sons (ruídos, músicas, narrações) poderão ser capturados de repositórios ou
gravados com algum software, como o Free Sound Recorder.
Assim, o conteúdo do jogo pode ser criado, editado ou reformulado, através da
montagem de texturas e gravação ou captura de sons. Essa facilidade permite a
personalização do jogo educacional para uso em turmas ou grupos de pessoas ou alunos.
Para personalizar o jogo educacional, o professor ou supervisor deverá executar
os seguintes procedimentos:
a) Verificar as pastas de texturas relativas a perguntas e respostas para ver quantas
texturas existem em cada uma.
b) Preparar o mesmo número de perguntas ilustradas (para o plano vertical),
perguntas textuais (para o plano horizontal), respostas ilustradas (para o plano
vertical) e ações de resposta (para o plano horizontal), usando um editor de textos e
os gabaritos (templates) para cada caso;
c) Capturar as partes das telas das questões, respostas e ações como arquivos de
imagem do tipo JPG, por exemplo, renomeando-os com os mesmos nomes dos
arquivos equivalentes existentes em cada pasta.
d) Substituir as texturas antigas pelas novas.
e) Gravar novos sons e/ou narrações associados com cada pergunta e resposta,
mantendo os mesmos nomes de arquivos correspondentes aos anteriores.
f) Substituir os sons e/ou narrações antigos pelos novos.
Se o professor/supervisor quiser aumentar a quantidade de perguntas e respostas
associadas com um ponto específico da trajetória, ele precisará: preparar novas texturas
e novos sons e/ou narrações, colocá-los nas respectivas pastas e editar o arquivo de
configuração de objetos no ponto (path(i).dat contido na pasta wrl). Além disso, novas
estruturas de perguntas e respostas (modelos VRML) deverão ser criadas por replicação
e editadas para ajustar os endereços das respectivas texturas.
No caso de diminuir a quantidade de perguntas e respostas, será necessário editar
o arquivo de configuração path(i).dat, eliminando as referências aos blocos das
perguntas e respostas a serem descartadas.
Com esse processo, o professor/supervisor poderá personalizar o jogo
educacional de forma a explorar temas específicos e diferentes quantidades de perguntas,
respostas e ações, melhorando a qualidade do jogo.
Se o desenvolvedor quiser ilustrar as perguntas e respostas com modelo 3D
estáticos ou animados, ele poderá criar um ponto no espaço para a renderização do
objeto virtual e um ponto em algum lugar de um dos planos para servir como ativador.
Para isto, basta replicar um dos pontos da trajetória e editá-lo para exibir o objeto
virtual, além de inserí-lo no arquivo de pontos do marcador de referência.
7. Conclusões
Este trabalho discutiu a autoria de aplicações de realidade aumentada e mostrou como a
ferramenta SACRA pode ser usada para facilitar o trabalho de desenvolvimento. Além
disso, foi mostrado que, mediante certas estratégias, pode-se acelerar o desenvolvimento
de aplicações obtendo-se um processo de prototipagem rápida.
Apesar da ferramenta SACRA ser baseada no ARToolKit e em VRML, esses
recursos ficam confinados e transparentes, quando se faz desenvolvimento de conteúdo,
de forma que, para o desenvolvedor final ou usuário, não interessa o que está por baixo
da aplicação, mas sim seu funcionamento e desempenho.
Mesmo assim, encontra-se em desenvolvimento uma ferramenta com o potencial
do SACRA, usando FlarToolKit, para atualizar o software e superar as restrições
relacionadas com o uso de vídeo. Além disso, serão incorporados módulos de
inteligência, que poderão ser associados aos objetos virtuais, visando fazer com que a
nova ferramenta seja um sistema de autoria de aplicações de hiper-realidade.
O desenvolvimento do conteúdo do jogo educacional, para ajustar-se aos temas
de interesse do professor/supervisor, mostrou-se bastante simples e rápido. Espera-se
que este seja um dos vários artefatos interativos com realidade aumentada a serem
disponibilizados para professores, visando elevar o nível do ensino e aprendizagem,
principalmente na educação básica.
Com isto, espera-se contribuir para que a alta tecnologia possa ser usada por
todos os cidadãos, incluindo aqueles de classes menos favorecidas, através de aplicações
com realidade aumentada gratuitas, simples de aprender e de usar, com alta
disponibilidade e personalizável.
Agradecimentos
Agradeço ao Rafael Santin, que desenvolveu o software SACRA como trabalho de
mestrado, sob minha orientação; aos alunos Eduardo Shiwaku Okawa e Hipólito
Douglas Moreira, que me ajudaram na digitação; às professoras Gisele Maria P. Garcia
e Marília L. Paiva e Silva, pelas amostras de perguntas feitas à mão; e ao CNPq e
FAPEMIG pelo financiamento a projetos, em cujo contexto foram realizados
experimentos de artefatos interativos com realidade aumentada.
Referências
Bauer, M., Bruegge, B., Klinker, G., MacWilliams, A., Reicher, T., Riss, S., Sandor, C.
e Wagner, M. (2001) “Design of a Component-based Augmented Reality
Framework” In ISAR’01, IEEE and ACM International Symposium on Augmented
Reality, New York, USA, pp. 45-54.
Burdea, G.C. e Coiffet,P., Virtual Reality Technology, Wiley-Interscience, 2nd edition,
2003.
Di Wu, Y.Y. e Liu, Y. (2009) “Collaborative Education UI in Augmented Reality” In
ETCS’09, First International Workshop on Education Technology and Computer
Science, Wuhan, China, pp. 670-673.
Dias, J.M.S. Santos, P., Bastos, R., Monteiro, L. e Silvestre, R. (2003) “Developing and
Authoring Mixed Reality with MX Toolkit”, In ART 2003, 2nd IEEE International
Augmented Reality Toolkit Workshop, Tokyo, Japan, pp. 18-26.
Grimm, P., Haller, M., Paelke, V., Reinhold, S., Reimann, C. e Zauner, J. (2002) “Amire
- Authoring Mixed Reality”, In The First IEEE International Workshop on
Augmented Reality Toolkit, Darmstadt, Germany, 2 pp.
Hampshire A., Seitcher, H., Grasset, R. e Billinghurst, M. (2006) “Augmented Reality
Authoring: Generic Context from Programmer to Designer”, In OzCHI’06, 18th
Australia conference on Computer-Human Interaction: Design: Activities, Artefacts
and Environments, Sydney, Australia, pp. 409-412.
Irawati, S., Green, S., Billinghurst, M., Duenser, A. e Ko, H. (2006) “An Evaluation of
an Augmented Reality Multimodal Interface Using Speech and Paddle Gestures”, In
Lecture Notes in Computer Science, 4282, pp. 272-283.
Kato, H. e Billinghurst, M. (1999) “Marker Tracking and HMD Calibration for a Videobased Augmented Reality Conferencing System”, In IWAR’99, The 2nd Int.
Workshop on Augmented Reality, San Francisco, USA, pp. 85–94.
Kaufmann, H. e Dunser, A. (2007) “Summary of Usability Evaluations of an Educational
Augmented Reality Application”, In Lecture Notes in Computer Science, 4563, pp.
660-669.
Kirner, C. e Santin, R. (2009) “Interaction, Collaboration and Authoring in Augmented
Reality Environments” In SVR’09. XI Symposium on Virtual and Augmented Reality,
Porto Alegre, Brazil, 2009, pp. 210-220.
Kirner, C. e Kirner, T.G. (2010) “Authoring Spatial Applications by non-Programmers
with an Augmented Reality Tool” In Web3DW 2010, IADIS Web Virtual Reality and
Three-Dimensional Worlds Conference, Freiburg, Germany, pp. 293-300.
Kirner, C. (2011) “ARAS-NP: Augmented Reality Authoring System for Nonprogrammers”, http://www.ckirner.com/sacra/, abril.
Kirner, C., (2011) “Q&A-AR: augmented reality racing game based on questions and
answers”, http://www.ckirner.com/educa/, abril.
Ledermann, F. e Schmalstieg, D. (2005) “APRIL: A High-level Framework for Creating
Augmented Reality Presentations”, In VR’05, IEEE Virtual Reality 2005, Bonn,
Germany, pp. 187–194.
Looser, L., Grasset, R., Seichter, H. e Billinghurst, M. (2006) “OSGART – A Pragmatic
Approach to MR”, In ISMAR’06, 5th IEEE and ACM International Symposium on
Mixed and Augmented Reality, Santa Barbara, USA, 2 pp.
MacIntyre, B., Gandy, M., Dow, S. e Bolter, J.D. (2004) “DART: A Toolkit for Rapid
Design Exploration of Augmented Reality Experiences”, In UIST’04, 17th Annual
ACM Symposium on User Interface Software and Technology, Santa Fe, USA, pp.
197–206.
Saquoosha, T.K.A. (2011) “FlarToolKit”, http://saqoosha.net/en/flartoolkit/start-upguide/, março.
Schmalstieg, D., Fuhrmann, A., Hesina, G., Szalavari, Z., Encarnação, L.M., Gervautz,
M. e Purgathofer, W. (2002) “The Studierstube Augmented Reality Project”,
Presence: Teleoperators and Virtual Environments, 11(1), 33–54.
Seitchter, H., Looser, J. e Billinghurst, M. (2008) “ComposAR: An Intuitive Tool for
Authoring AR Applications”, In ISMAR’08, 7th IEEE and ACM International Symp.
on Mixed and Augmented Reality, Cambridge, UK, pp. 177-178.
Sutherland, I.E. Sketchpad: A Man-Machine Graphical Communication System, PhD
Thesis, MIT, January, Technical Report No. 574, University of Cambridge, UCAMCL-TR-574, 1963.
Sutherland, I.E. (1965) “The ultimate display”, In Proceedings of IFIPS Congress, New
York City, NY, vol. 2, May, pp. 506-508.
Sutherland, I.E. (1968) "A Head-mounted Three-dimensional Display," In 1968 Fall
Joint Computer Conference, AFIPS Conference Proceedings, vol. 33, pp. 757-764.
Uchiyama, S., Takemoto, K., Satoh, K., Yamamoto, H. e Tamura, H. (2002) “MR
Platform: A Basic Body on which Mixed Reality Applications are Built”, In
ISMAR’02, The First IEEE and ACM International Symposium on Mixed and
Augmented Reality, Darmstadt, Germany, pp. 246.