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).

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

a) RV imersiva b) RV não imersiva

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.

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.

a) Ambiente aumentado b) Estrutura de dados c) Pastas do desenvolvedor

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.

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;

Ambiente físico

- 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).

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).

Figura 10. Recurso físicos e virtuais do jogo

a) Estrutura física b) Estrutura virtual

a) Recursos físicos móveis b) Elementos de interação

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.

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.

a) Ambiente do jogo com RA b) Interação entre pontos físicos e virtuais

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 Video-

based 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 Non-

programmers”, 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-up-

guide/, 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, UCAM-

CL-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.