Book 1.indb

Transcrição

Book 1.indb

Tendências e Técnicas em
Realidade Virtual e Aumentada
Av. Bento Gonçalves, 9500 - Setor 4 - Prédio 43.412 - Sala 219 - Bairro Agronomia
CEP 91.509-900 - Porto Alegre - RS - Tel. (51) 3308-6835 - Fax (51) 3308-7142
Home: www.sbc.org.br - E-mail: [email protected]
Paulo Roberto Freire Cunha (UFPE)
Presidente
Lisandro Zambenedetti Granville (UFRGS)
Vice-Presidente
Luciano Paschoal Gaspary (UFRGS)
Diretor Administrativo
Luci Pirmez (UFRJ)
Diretor de Finanças
Altigran Soares da Silva (UFAM)
Diretor de Eventos e Comissões Especiais
Mirella Moura Moro (UFMG)
Diretora de Educação
Karin Koogan Breitman (PUC-Rio)
Diretora de Publicações
Ana Carolina Brandão Salgado (UFPE)
Diretora de Planejamento e Programas Especiais
Thais Vasconcelos Batista (UFRN)
Diretora de Secretarias Regionais
Edson Norberto Cáceres (UFMS)
Diretor de Divulgação e Marketing
Roberto da Silva Bigonha (UFMG)
Diretor de Relações Profissionais
Ricardo de Oliveira Anido (UNICAMP)
Diretor de Competições Científicas
Raimundo José de Araújo Macêdo (UFBA)
Diretor de Cooperação com Sociedades Científicas
Sergio Vanderlei Cavalcante
Diretor de Articulação de Empresas
Tendências e Técnicas em
Realidade Virtual e Aumentada
Publicação anual | Cuiabá | v. 3 | p. 1-278 | 2013
EDITORES
Alexandre Cardoso
Ezequiel Zorzal
Marcelo de Paiva Guimarães
Márcio Pinho
CONSELHO EDITORIAL
Alexandre Cardoso
Ezequiel Zorzal
Fátima L. S. Nunes
Liliane dos Santos Machado
Luciano P. Soares
Márcio Pinho
Selan Rodrigues
PRODUÇÃO GRÁFICA
Canal 6 Projetos Editoriais - www.canal6.com.br
Dados Internacionais de Catalogação na Publicação (CIP)
Tendências e Técnicas em Realidade Virtual e Aumentada.
Sociedade Brasileira de Computação - SBC. -- (2011 --) - .
Porto Alegre, RS: a Instituição, 2011-
.
v. 3
Anual
ISSN 2177-6776
1. Realidade Virtual, Realidade Aumentada. I. Cardoso,
Alexandre. II. Zorzal, Ezequiel III. Guimarães, Marcelo de Paiva.
IV. Pinho, Márcio.
CDD 006
Este periódico foi especialmente editado, em
tiragem limitada, a partir de conteúdos desenvolvidos para os minicursos apresentados
durante o XV Simpósio de Realidade Virtual
e Aumentada, realizado em Cuiabá, de 27 a
30 de Maio de 2013, promovido pela Sociedade Brasileira de Computação e organizado
pelo Instituto de Computação da Universidade Federal de Mato Grosso (UFMT) e
apoiado pelo Instituto Federal de Ciência e
Tecnologia de Mato Grosso (IFMT).
Cuiabá, MT
2013
Índice para catálogo sistemático:
1. Realidade Virtual e Aumentada: Ciência da Computação 006
TODOS OS DIREITOS RESERVADOS: Permitida a reprodução total ou parcial desde que citada a fonte (Tendências e Técnicas em
Realidade Virtual e Aumentada, Porto Alegre-RS, Brasil). Na ausência da indicação da fonte ou expressa autorização da Instituição,
é proibida a sua reprodução total ou parcial, por qualquer meio ou processo, especialmente por sistemas gráficos, microfílmicos,
fotográficos, reprográficos, fonográficos ou videográficos. Vedada a memorização e/ou recuperação total ou parcial, bem como a
inclusão de quaisquer partes desta obra em qualquer sistema de processamento de dados. Essas proibições aplicam-se também às
características da obra e à sua editoração. A violação dos direitos autorais é punível como crime (art. 184 e §§, do Código Penal, cf.
Lei no. 6.895, de 17-12-1980) com pena de prisão e multa, conjuntamente com busca e apreensão e indenizações diversas (arts. 122,
123, 124 e 126, da Lei no. 5.988 de 14-12-1973, Lei dos Direitos Autorais).
Sumário
Prefácio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Desenvolvimento de Aplicações Educacionais Adaptáveis Online com
Realidade Aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Claudio Kirner
Visualização e Interação em Arquitetura via RV e RA . . . . . . . . . . . . . . . . . . . . . . . . . 26
Luciano Silva
Realidade Virtual e Aumentada Aplicada na Área de Negócios: casos na
área de Marketing e de Projeto e Desenvolvimento de Produtos . . . . . . . . . . . . . . . . 43
Ildeberto A. Rodello, Marize Minakawa, Thais F. da Paz e José R. F. Brega
Realidade Aumentada Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Gesmar de Paula Santos Júnior, Luciene Chagas de Oliveira, Alexandre Cardoso, Edgard Lamounier Júnior, Marcos Wagner de Souza Ribeiro e Thamer Horbylon Nascimento
Utilização de Dispositivos de Interfaces Naturais de Usuário em Aplicações
de Realidade Aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
André Luiz Satoshi Kawamoto e Flávio Soares Correa da Silva
Desenvolvimento de Aplicações com Interface Natural de Usuário e
Dispositivos PrimeSense como Meio de Interação para Ambientes Virtuais . . . . . . . 89
Diego Roberto Colombo Dias, Gustavo Jordan Castro Brasil, Bruno Barberi Gnecco,
Mário Popolin Neto, Isabele Andreoli Agostinho, Richard Valdívia, José Remo Ferreira
Brega e Luis Carlos Trevelin
5
Estratégias mistas de mecanismos para imersão em modelos de interação
em ambientes virtuais de treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Bruno Barberi Gnecco, Rodrigo de Godoy Domingues, Gustavo Jordan Castro Brasil,
Diego Roberto Colombo Dias e Luis Carlos Trevelin
Avatares baseados em vídeo e suas aplicações em sistemas virtuais imersivos . . . 121
Cléber Gimenez Corrêa, Silvio Ricardo Rodrigues Sanches, Daniel de Andrade Lemeszenski, Daniel Makoto Tokunaga e Romero Tori
Avaliação de Usabilidade para Aplicações de Realidade Aumentada . . . . . . . . . . . . 138
Valéria Farinazzo Martins, Ana Grasielle Dionísio Corrêa e Marcelo de Paiva Guimarães
Percepção Natural de Profundidade: Uma Análise do Fish Tank Virtual Reality . . . . 157
Ermano Ardiles Arruda, Lucas Silva Figueiredo e Veronica Teichrieb
Desenvolvimento de websites com ambientes virtuais 3D interativos . . . . . . . . . . . . 185
Maria Amelia Eliseo, Beatriz de Almeida Pacheco e Darlan Silva Alves Delmondes
Simulações Físicas para Ambientes de RV e RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Luciano Silva
Desenvolvimento de Aplicações de RV e RA para Smart TVs . . . . . . . . . . . . . . . . . . 227
Luciano Silva
Introdução à utilização de openFrameworks para o desenvolvimento de
aplicações de RVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Christopher Shneider Cerqueira e Claudio Kirner
6
Prefácio
O Simpósio de Realidade Virtual e Aumentada (SVR) é a principal conferência em Realidade
Virtual e Realidade Aumentada (RVA) no Brasil, promovido pela SBC (Sociedade Brasileira de Computação), com periodicidade anual, desde 1997. O SVR reúne pesquisadores, estudantes e diversos
profissionais das áreas acadêmica, industrial e comercial interessados nos avanços e nas aplicações da
RV e RA.
Tradicionalmente, o SVR oferece minicursos, que visam promover as habilidades de especialização, bem como ampliar a formação específica dos participantes, com perspectivas de aprimoramento
de suas pesquisas; e além disso, conta com o pré-simpósio, que apresenta um conjunto de tutoriais, de
curta duração, e de conteúdo introdutório. Tais ações criam um repertório de conhecimento básico,
intermediário e avançado capaz de melhorar as condições de aproveitamento dos temas que serão exibidos e discutidos ao longo do simpósio principal.
Com o intuito de continuar a democratização e a disseminação do conhecimento sobre RVA, neste
ano de 2013, o conteúdo dos Minicursos e do Pré-simpósio foram compilados nesta revista e apresenta o resultado do trabalho de autores da comunidade brasileira, previamente avaliado pelo conselho
editorial.
Pretende-se que esta revista seja uma referência para atualizações, tanto por profissionais quanto
por pesquisadores ávidos pelo conhecimento e aprimoramento do domínio de tendências e técnicas
de RVA. Agremiando distintos perfis de conteúdos, torna-se ainda ponto de partida para iniciantes
e profissionais de outras áreas do conhecimento interessados em ingressar no fascinante mundo da
tecnologia de Realidade Virtual e Aumentada.
Agradecemos a todos que colaboraram. Desejamos a todos uma excelente leitura!
Os organizadores
Alexandre Cardoso
Ezequiel Zorzal
Márcio Pinho
7
9
Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 9-25, maio/2013.
KIRNER, Claudio. Desenvolvimento de Aplicações Educacionais Adaptáveis Online com Realidade Aumentada.
Desenvolvimento de Aplicações Educacionais
Adaptáveis Online com Realidade Aumentada
Claudio Kirner
Abstract
Augmented reality has strong appeal for educational usage due to its features involving: intuitive interactions, high levels of motivation and involvement, autonomy, special devices independence, etc. Furthermore, some factors is still lacking to be solved in order to the augmented reality can be intensively
used by teachers and students, such as: necessity to have technical knowledge, non availability of free
online applications really useful in Education, difficulty to adapt the applications, changing content and
structure, difficulty to find suitable authoring tools for teachers and students. This paper promotes a
discussion about the use of augmented reality in Education, presenting the free authoring tool FLARAS
and its using on creating the educational online game with augmented reality capable to be adaptable.
Resumo
A realidade aumentada, em função das suas características, envolvendo interatividade intuitiva, alto
grau de motivação e envolvimento, autonomia, independência de dispositivos especiais, etc., tem forte
apelo para uso na área de Educação. No entanto, ainda resta resolver alguns problemas para que professores e alunos possam utilizar intensivamente essa tecnologia, como a necessidade de conhecimentos técnicos, pouca disponibilização de aplicações gratuitas online realmente úteis à Educação, falta de
adaptabilidade das aplicações, poucas ferramentas gratuitas simples de serem usadas. Este artigo aborda
uma discussão sobre o uso da realidade aumentada na Educação, apresentando a ferramenta de autoria
livre de aplicações de realidade aumentada FLARAS e o seu uso na produção de um jogo educacional
online adaptável com realidade aumentada.
9
1. Introdução
A realidade aumentada, definida como o enriquecimento do mundo físico com elementos virtuais
interativos, visualizados em tempo real com o auxílio de algum dispositivo tecnológico, apresenta
características bastante favoráveis ao seu uso na área educacional, como:
• Interatividade intuitiva no ambiente do usuário, envolvendo textos, imagens, objetos 3D, vídeos, etc., exigindo participação ativa do estudante;
• Alto grau de motivação e envolvimento, decorrente dos elementos interativos inovadores utilizados;
• Independência de dispositivos especiais, uma vez que pode usar somente um computador
com webcam ou mesmo um tablet;
• Autonomia na exploração da aplicação;
• Adequação a diversos tipos de estilos de aprendizagem, apresentando o assunto através de
conteúdo rico em múltiplas mídias;
• Alto potencial de uso em trabalhos colaborativos.
No entanto, para que a realidade aumentada seja efetivamente usada em Educação, ainda restam
algumas questões a serem resolvidas, como:
• Disponibilidade de aplicações educacionais gratuitas online, realmente úteis em ensino e
aprendizagem, nas várias áreas do conhecimento;
• Criação de aplicações abertas adaptáveis, que possam atender as necessidades dos professores, de forma que eles possam apropriar-se das aplicações, alterando-as e utilizando-as de
fato;
• Desenvolvimento de ferramentas livres para autoria de aplicações, que permitam o desenvolvimento e adaptação de aplicações educacionais de realidade aumentada online, por parte de
usuários, sem conhecimentos técnicos profundos, utilizando estruturas pré-montadas e os
conteúdos fornecidos pelos professores;
• Elaboração de cursos de capacitação abertos, para que professores e estudantes aprendam
como explorar melhor a tecnologia de realidade aumentada, utilizando material existente em
repositórios na Internet ou desenvolvendo seu próprio material didático.
Este artigo tem por objetivo mostrar algumas iniciativas, que estão em andamento, visando encontrar soluções para as questões apresentadas, de forma a possibilitar o uso da realidade aumentada
na Educação, fazendo com que professores e estudantes possam produzir seu próprio material educacional.
Nesse sentido, a seção 2 apresenta uma discussão sobre o uso da realidade aumentada na educação; a seção 3 descreve a ferramenta de autoria de aplicações de realidade aumentada online, denominada FLARAS; a seção 4 apresenta um jogo educacional desenvolvido com a ferramenta FLARAS; e a
seção 5 apresenta as conclusões do trabalho.
10
2. Requisitos das Aplicações Educacionais com Realidade Aumentada
A publicação Horizon Report [NMC 2013] anualmente aponta as áreas e tecnologias emergentes,
que deverão apresentar impactos significativos na Educação, nos próximos anos.
Em 2011 e 2012, a publicação preconizou grande impacto da realidade aumentada e de aprendizagem baseada em jogos, na Educação, para os próximos dois a três anos [Johnson et. Al. 2011, Johnson
et. al. 2012]. Em função da exigência de interação e envolvimento do usuário com a aplicação, além de
outras propriedades comuns, essas duas áreas podem atuar de forma conjugada.
Em 2013, dentre as 12 tecnologias listadas, ainda persistiram realidade aumentada e aprendizagem
baseada em jogos, ao lado de cursos online abertos e massivos, aplicações móveis, computação para
tablets e tecnologia vestível, entre outras [NMC 2012]. Cabe salientar que a tecnologia vestível tem ligação muito forte com o projeto Google Glass, que está em fase de desenvolvimento e é baseado em realidade aumentada, prometendo mudar as formas de interação do usuário com a Internet e com o mundo.
O uso da realidade aumentada na Educação pode ser visto de várias maneiras:
• Em relação ao usuário;
• Em relação à interação com as aplicações
• Em relação à execução das aplicações;
• Em relação ao custo;
• Em relação à abertura do código da aplicação;
• Em relação à capacidade de adaptação da aplicação;
• Em relação à quantidade de marcadores necessários para a aplicação;
• Em relação aos recursos da interface da aplicação;
• Em relação ao tipo da interface da ferramenta de autoria;
• Em relação à edição proporcionada pela ferramenta de autoria;
• Em relação às plataformas de execução das aplicações e ferramentas de autoria.
•
Em seguida, cada item citado será discutido.
2.1. Em Relação ao Usuário
O usuário (professor ou estudante) pode ser consumidor ou produtor de aplicações educacionais
com realidade aumentada. Na maioria das vezes, ele assume o papel de consumidor, uma vez que produzir tais aplicações, geralmente, exige conhecimentos técnicos profundos.
Por conta disso, as aplicações educacionais acabam sendo desenvolvidas por técnicos e podem não
satisfazer adequadamente as necessidades dos professores e estudantes, que, na falta de outras opções,
ou não usam as aplicações ou não as exploram com todo potencial.
11
2.2. Em Relação à Interação com as Aplicações
As aplicações podem apresentar interação com o usuário em níveis baixo, médio e alto.
As primeiras aplicações educacionais com realidade aumentada, em função da novidade, foram
contemplativas, resumindo-se a apresentar objetos virtuais 3D sobre os marcadores colocados em frente a webcam.
Em seguida, apareceram aplicações mais sofisticadas com interações que promoviam alterações
no cenário virtual ou disparo de animações.
As aplicações mais recentes envolvem comportamento e inteligência, funcionando como jogos,
usando interações mais variadas e intensivas. Nesse caso, usuário tem que interagir com o conteúdo da aplicação, usando sua habilidade e conhecimento, melhorando-os, no decorrer do processo, e
estimulando-o a estudar o tema abordado. Enquadram-se aqui os jogos educacionais com realidade
aumentada, integrando as duas tendências educacionais dos últimos três anos.
2.3. Em relação à Execução das Aplicações
A execução das aplicações de realidade aumentada pode ser local ou online. A execução local exige
que a aplicação, normalmente, seja baixada e eventualmente instalada no computador do usuário, dificultando a utilização e desestimulando o usuário. Muitos usuários desistem da aplicação, antes mesmo
de baixá-la. No entanto, depois de baixada ou instalada, a execução da aplicação dependerá somente da
potência do computador, o que normalmente é rápido. Esse inconveniente se agrava, se for necessário
fazer instalações múltiplas, na sala de aula, em casa, etc.
A execução online de aplicações tem a vantagem de não necessitar de download e instalação, mas
depende de uma conexão de Internet com boa velocidade, limitando a utilização dos usuários que não
dispõem de bons recursos de conexão. As aplicações com execução online podem ser usadas em sala de
aula, em casa e em ambientes de educação à distância, bastando acessá-las de qualquer lugar.
2.4. Em Relação ao Custo
Existem aplicações comerciais (com custo) e aplicações gratuitas (sem custo). Normalmente, as
aplicações comerciais tendem a ser de melhor qualidade, por serem desenvolvidas por equipes de profissionais comprometidos com o produto, mas, recentemente, com o crescimento da filosofia de abertura [Okada 2012], estão surgindo boas aplicações de realidade aumentada gratuitas.
2.5. Em Relação à Abertura do Código da Aplicação
Existem aplicações de código fechado e de código aberto.
As aplicações de código fechado são aquelas, em que os autores não disponibilizam o código das
aplicações, produzidas por eles próprios ou compradas. Estão aqui as aplicações comerciais.
12
As aplicações de código aberto, ou usaram ferramentas abertas ou foram abertas pelos próprios
autores. Nessa situação estão várias aplicações educacionais elaboradas com ARToolKit [Kato, H. e
Billinghurst 1999], FlartoolKit [Saquosha 2008], SACRA [Kirner e Santin 2009], FLARAS [Souza et. al.
2013], basAR [Cerqueira e Kirner 2011, Cerqueira e Kirner 2012] e outras [Kirner et. al.2012].
2.6. Em Relação à Capacidade de Adaptação da Aplicação
Algumas aplicações são elaboradas, de forma a não separar estrutura da aplicação e conteúdo,
enquanto outras fazem essa separação.
Quando não há separação de estrutura e conteúdo, a aplicação impõe dificuldades de alteração de
conteúdo, sendo inflexível.
Quando há a separação de estrutura e conteúdo, como ocorre na família de ferramentas SACRA,
FLARAS e basAR, o usuário pode ter certa facilidade em trocar o conteúdo, sendo possível realizar-se
adaptação de aplicações. Em alguns casos, também é possível adaptar-se a estrutura da aplicação, com
certa facilidade, como ocorre com as aplicações desenvolvidas com a ferramenta FLARAS.
A adaptação tem alto potencial de criação de aplicações derivadas com facilidade, sendo adequadas
para uso educacional, tanto em ensino, pelos professores, como em aprendizagem, pelos estudantes.
2.7. Em Relação à Quantidade de Marcadores Necessários para a Aplicação
Há aplicações com muitos marcadores, com poucos marcadores e com nenhum marcador.
A quantidade exagerada de marcadores pode confundir o usuário, além de gerar dificuldade em ser
acomodada no campo de visão da webcam. As ferramentas SACRA e basAR estão aqui enquadradas.
A quantidade pequena de marcadores (um ou dois) permite manipulação mais fácil das aplicações,
exigindo, no entanto, outras formas de inserção de elementos no cenário, como pontos e cenas, e outras
formas de seleção de funções, como funções selecionadas pelo mouse ou teclado. A ferramenta FLARAS enquadra-se aqui, usando dois marcadores.
A ausência de marcador facilita a manipulação da aplicação, mas deve ser precedida de um cadastramento de elementos do cenário, que funcionarão como os marcadores.
2.8. Em Relação aos Recursos da Interface da Aplicação
Há interfaces de aplicações exclusivamente visuais, enquanto outras exploram sons e animações.
A complexidade do projeto tende a crescer com a melhoria da interface, mas, em alguns casos,
como a ferramenta FLARAS, a complexidade das funções já está embutida na ferramenta, permitindo
o uso de recursos avançados com certa facilidade.
13
2.9. Em Relação ao Tipo da Interface da Ferramenta de Autoria
Considerando-se a interface de autoria das aplicações de realidade aumentada, pode-se encontrar
quatro tipos de ferramentas: exclusivamente visuais, parcialmente visuais, configuráveis e programáveis.
As ferramentas de autoria exclusivamente visuais apresentam interfaces com manipulação visual,
nas quais o usuário, movimentando o mouse, consegue elaborar uma aplicação, a partir de objetos virtuais disponíveis na biblioteca da ferramenta ou no computador do usuário. Todas as ações são visuais
e pode haver pouca precisão em posicionamento, inclinação e escala. No entanto as interações podem
ser rápidas e intuitivas.
As ferramentas de autoria parcialmente visuais buscam objetos virtuais na biblioteca ou computador do usuário, a partir de ações visuais, e solicitam a digitação de parâmetros como posição, inclinação e escala dos objetos virtuais, assegurando precisão e rapidez. O software FLARAS é um exemplo
desse tipo de ferramenta.
As ferramentas de autoria configuráveis utilizam pastas, onde são inseridos objetos virtuais e arquivos de texto, descrevendo a configuração da aplicação. Embora não sejam visuais, essas ferramentas
também não dependem de programação, facilitando o desenvolvimento de aplicações, mas exigem
algum conhecimento de manipulação das pastas e edição dos arquivos de texto. Enquadram-se aqui as
ferramentas SACRA e basAR.
As ferramentas de autoria baseadas em programação necessitam da atuação de especialistas em
programação e geram aplicações na forma de código, mais difíceis de serem alteradas. Nessa situação
estão ARToolKit, FlarToolKit, Metaio SDK [Metaio 2013], etc.
2.10. Em Relação à Edição Proporcionada pela Ferramenta de Autoria
Há ferramentas que permitem quatro tipos de edições das aplicações: difíceis, meio fáceis, fáceis
e muito fáceis.
As ferramentas com edições difíceis são aquelas, cujas aplicações foram geradas, a partir de programação, exigindo conhecimentos técnicos e visão muito detalhada da aplicação.
As ferramentas com edições de facilidade média são aquelas baseadas em configurações de pastas
e edição de arquivos de texto, que podem ser realizadas por usuários com poucos conhecimentos de
informática. Nesse caso, encontram-se as ferramentas SACRA e basAR.
As ferramentas com edições fáceis são aquelas, cujas aplicações são criadas através de ações visuais
e alguma digitação de parâmetros. Nesse caso, está a ferramenta FLARAS.
As ferramentas com edição muito fácil são aquelas, cujas aplicações são criadas com ações puramente visuais.
A menos das ferramentas que manipulam programação, todas as outras oferecem condições de
desenvolvimento e adaptação de aplicações, por parte de professores e estudantes, apresentado maior
ou menor simplicidade nesse processo.
14
2.11. Em Relação às Plataformas de Execução das Aplicações e Ferramentas de Autoria
Existem aplicações voltadas para desktops e notebooks e outras voltadas para tablets e celulares.
As aplicações educacionais com realidade aumentada que são executadas em desktops e notebooks
tendem a usar os sistemas operacionais dessas plataformas computacionais, sendo os mais comuns:
Windows, Linux e MacOS. Nesses casos, encontram-se aplicações com execução local ou online.
As aplicações executadas em tablets e celulares também precisam ser desenvolvidas para os sistemas operacionais das plataformas específicas, sendo os mais comuns: Android, IOS e Windows.
Nesses casos, a maioria das aplicações é executada localmente, depois de ser instalada, a partir das lojas
(application store) disponíveis.
As aplicações criadas com a família de ferramentas SACRA, basAR e FLARAS são voltadas para
desktops e notebooks.
Assim, levando em conta os requisitos de aplicações educacionais com realidade aumentada e as
várias maneiras delas serem vistas, seria desejável que essas aplicações tivessem as seguintes características:
• Sejam voltadas para usuários consumidores e produtores de aplicações educacionais;
• Tenham capacidade de adaptação;
• Possuam interface de utilização visual e sonora amigável;
• Apresentem alto grau de interação do usuário com a aplicação;
• Permitam acesso local e online;
• Sejam gratuitas;
• Tenham código aberto;
• Tenham interface de autoria visual;
• Sejam baseadas no uso de poucos marcadores ou não usem marcadores;
• Usem ferramentas, que facilitem a adaptação das aplicações;
• Possam ser executadas em plataformas de computadores e/ou tablets;
Encontrar uma aplicação e a ferramenta de autoria usada para produzí-la, que contemplem a
maioria dessas características, não é fácil, mas a ferramenta FLARAS e suas aplicações estão bem próximas disso.
O problema mais crítico da ferramenta FLARAS está em não produzir aplicações que possam ser
executadas na maioria dos tablets e celulares (com sistemas Androide e IOS), uma vez que o FLARAS
é baseado em FLASH . No entanto, já está sendo estudada uma forma de reescrever o código do FLARAS, de forma que suas aplicações sejam executadas em todos os tablets e celulares.
Portanto, o software FLARAS tem boas condições de ser usado na criação de aplicações educacionais de realidade aumentada, que possam ser úteis a professores e estudantes, no processo de ensino e
aprendizagem.
Já foram desenvolvidas várias aplicações educacionais [Kirner et. al. 2012, Souza et. al. 2013],
usando a ferramenta de autoria FLARAS, que podem ser vistas e exercitadas na Internet, a partir de
seus links.
15
3. Ferramenta FLARAS para Autoria de Aplicações de Realidade Aumentada
3.1. Visão Geral do Software FLARAS
O software FLARAS (Flash Augmented Reality Authoring System) [Souza et. al. 2013] é uma ferramenta de autoria visual de aplicações interativas de realidade aumentada, desenvolvido por Raryel
Costa Souza, Hipólito Douglas França Moreira e Claudio Kirner .
O FLARAS foi desenvolvido com a biblioteca FlarToolKit [Saquosha 2008] e sua estrutura foi herdada da ferramenta SACRA [Kirner e Santin 2009], a qual foi construída com a biblioteca ARToolKit
[Kato 1999].
As aplicações elaboradas com FLARAS podem ser executadas online, diretamente do navegador
da Internet, bastando acionar um link para a aplicação, ou localmente, devendo ser precedida pelo
download da aplicação para o computador do usuário.
A principal característica do FLARAS é permitir o desenvolvimento rápido de aplicações simples
ou sofisticadas, ricas em interação, por pessoas com poucos conhecimentos técnicos e sem necessidade
de programação ou modelagem 3D. Com isto, professores e estudantes podem usar a ferramenta para
desenvolver trabalhos inovadores úteis para ensino e aprendizagem.
Os recursos usados no processo de autoria das aplicações educacionais de realidade aumentada,
envolvendo textos, imagens, sons, narrações, vídeos e objetos 3D, podem ser obtidos em repositórios
na Internet ou desenvolvidos pelo usuário.
A aplicação, resultante do processo de autoria, pode ser salva pelo ambiente do FLARAS, que também pode gerar arquivos para disponibilização em servidores ou repositórios de arquivos na Internet,
permitindo o seu uso online, sem necessidade de instalação.
O FLARAS é um software livre de código aberto, disponível na Internet, em um site [Souza et. al.
2013] com vasto material de apoio, incluindo: versões da ferramenta para download; tutoriais em textos e em vídeos; perguntas frequentes; e-book; repositório de aplicações com várias aplicações online
para uso imediato, com seus projetos para adaptação; além de informações sobre os desenvolvedores.
Para usar o FLARAS, basta imprimir um único marcador, denominado Marcador de Referência
[Souza e Kirner 2013], acionar a aplicação na Internet, mostrar o marcador para a webcam, fazendo
aparecer o ambiente 3D da aplicação no monitor, e interagir com a aplicação, seguindo as instruções
visuais e narradas.
3.2. Descrição do FLARAS
O FLARAS pode ser visto sob dois pontos de vista: um do ponto de vista do usuário das aplicações
e outro do ponto de vista do desenvolvedor das aplicações, uma vez que a janela de visualização é a
mesma para o usuário e para o desenvolvedor.
16
3.2.1. Estruturas das Aplicações Elaboradas com FLARAS
As aplicações elaboradas com FLARAS utilizam o conceito de ambiente 3D composto por pontos
dispostos no espaço, cada um mostrando uma cena, conforme a Fig. 1a.
a)Estrutura física
b)Estrutura lógica
Figura 1. Estrutura das aplicações elaboradas com FLARAS
Para dar maior potencial de aplicação, cada ponto pode conter uma ou mais cenas, selecionáveis
pelo usuário, em tempo de execução, conforme a Fig. 1b.
Cada cena pode ser formada por imagens, vídeos ou objetos 3D e pode ser habilitada ou desabilitada pelo usuário, durante o uso da aplicação.
Para contornar o problema da modelagem 3D, o FLARAS permite a utilização da maioria dos
milhares de objetos prontos do Armazém 3D do Trimble/Google [Timble/Google 2013], no formato
Collada (*.dae) ou KMZ.
3.2.2. Interface das Aplicações
Quando o usuário aciona a aplicação educacional de realidade aumentada. Ele recebe uma interface composta por uma área de visualização retangular e uma barra de funções localizada na sua parte
inferior, conforme a Fig. 2.
Figura 2. Interface da aplicação de realidade aumentada com FLARAS
17
Inicialmente, a aplicação deve ser autorizada (Fig. 2a). Em seguida, o marcador de referência deve
ser mostrado para a webcam (Fig. 2b), fazendo aparecer o ambiente 3D da aplicação (Fig. 2c).
Para usar a aplicação, algumas funções da barra de funções deverão ser acionadas com o mouse,
que é o elemento de interação principal do usuário com a aplicação. Também há possibilidade de uso
do marcador de interação, com a ajuda do mouse alterando sua função.
3.2.3. Interface da Ferramenta FLARAS
A interface da ferramenta FLARAS, usada na fase de desenvolvimento das aplicações, possui quatro áreas bem distintas, conforma a Fig. 3.
Figura 3. Áreas da interface da ferramenta FLARAS
A área maior serve para visualização da aplicação, enquanto ela estiver em desenvolvimento.
A área da parte superior direita serve para mostrar o grafo de cena da aplicação, onde podem ser
vistos: a estrutura de pontos, as cenas e os conteúdos.
A área da parte inferior direita serve para mostrar os parâmetros de cada elemento do grafo de
cena e outros detalhes.
A barra inferior da interface mostra as funções, que o mouse ou marcador de interação podem
assumir, e outras funções especiais da ferramenta.
Além disso, há um menu, na parte superior da área de visualização, cujas opções permitem salvar
o projeto, publicar a aplicação, ajustar a webcam, etc.
18
3.2.4. Funções da Ferramenta FLARAS
As funções da ferramenta FLARAS são mostradas tanto para o usuário consumidor quanto para
o desenvolvedor da aplicação, através de ícones, na barra inferior de funções e na área inferior direita,
onde aparecem os parâmetros e outras funções.
A barra inferior de funções (Fig. 3) apresenta as funcionalidades, que o mouse ou marcador de
interação podem assumir, incluindo: ativação individual e coletiva de pontos, navegação nas cenas,
movimentação das cenas no ambiente. Além disso, há também: espelhamento de webcam, ativação de
persistência do marcador, visibilidade de pontos de atração, etc.
As funções disponíveis na área de parâmetros incluem: criação, apagamento e posicionamento de pontos e cenas, ajuste de escala, inserção de objetos (imagens, objetos 3D e vídeos), inserção
de sons e animações, além de inserção de pontos de atração, conforme a Fig. 4.
Figura 4. Funções da área de parâmetros do FLARAS
Além disso, há funções de produtividade, que permitem mudar a ordem das cenas, duplicar cenas,
etc., que facilitam e aceleram o processo de desenvolvimento das aplicações.
4. Exemplo de um Jogo Educacional Elaborado com FLARAS
Existem várias iniciativas de desenvolvimento de aplicações educacionais com realidade aumentada [Ucelli 2005, Jochim 2010, Hamilton 2013], mas a maioria delas envolve especialistas, fazendo dos
professores e estudantes meros consumidores das aplicações. Outras iniciativas [Kirner 2011, Reis e
Kirner 2011, Cerqueira e Kirner 2012, Kirner et. al. 2012] procuraram separar o conteúdo da estrutura
de aplicações educacionais com realidade aumentada, permitindo autoria e adaptação, sem a necessidade de programação.
Assim, em função das duas principais tendências tecnológicas, na área de educação, envolvendo
realidade aumentada e jogos, conforme foi discutido, no início deste artigo, será apresentada uma
19
aplicação educacional online com realidade aumentada, abordando o jogo de geometria – sólidos geométricos gerados por revolução de figuras planas (GeomAR-Revolução)[Kirner 2013a, Kirner 2013b].
Essa aplicação apresenta um alto grau de interatividade, aspectos lúdicos, exigência de habilidades
e conhecimentos, desafios para os estudantes e outras propriedades de jogos, constituindo assim um
jogo educacional online com realidade aumentada.
4.1. Descrição do Jogo
O jogo GeomAR-Revolução consiste em descobrir figuras planas, que geram os sólidos geométricos apresentados, movimentando-as para perto de seus respectivos sólidos, usando o mouse ou o
marcador de interação.
O objetivo é usar o conhecimento do usuário sobre geometria, estimulando-o a experimentar o
jogo e estudar o assunto para vencer os desafios apresentados no espaço lúdico interativo, promovendo
a aprendizagem, com a manipulação de elementos exploratórios 3D, exercícios e diversão.
Espera-se que o jogo utilize e melhore os conhecimentos dos estudantes sobre o tema, além de
utilizar também a coordenação motora da movimentação dos elementos, aumentando a motivação.
Os sólidos abordados são: esfera, gerada por revolução de círculo; cilindro, gerado por revolução
de retângulo; cone, gerado por revolução de triângulo; e toróide, gerado por revolução de círculo deslocado do eixo de rotação, que fazem parte do ambiente do jogo (Fig. 5).
Figura 5. Ambiente do jogo GeomAR-Revolução
A área central da aplicação permite explorar os sólidos geométricos e o processo de geração baseado nas revoluções das figuras planas.
A área de figuras, mais abaixo, permite explorar as figuras, identificando aquelas que serão associadas com os sólidos correspondentes.
A fase de aprendizagem consiste em explorar todo o ambiente, analisando os sólidos, as figuras e
o processo de geração de sólidos por revolução de figuras planares.
20
A fase de fixação de aprendizagem, baseada em exercícios, constitui-se no próprio jogo, em que o
usuário, usando seus conhecimentos, procurará vencer os desafios. Em caso de dificuldade, ele poderá
passar para a fase de aprendizagem e depois voltar para a etapa do jogo.
O primeiro desafio é identificar um sólido geométrico e descobrir a figura que o gera, através de
revolução. Depois disso, o usuário deverá comutar a função do mouse para movimentação de objeto,
levando a figura identificada, para perto do sólido correspondentes, que fará sua atração. Se a associação de sólido com figura estiver correta, a figura será atraída para perto do sólido e será emitido um
feedback sonoro, caso contrário, a figura será repelida para sua posição original, emitindo outro tipo
de feedback sonoro.
Quando o usuário conseguir encaixar a figura nas proximidades do objeto correspondente, ele
ganhará pontos, senão ele perderá pontos. Vencerá o usuário que completar a associação dos quatro
sólidos com suas figuras, em menor tempo e com mais pontos.
Poderá acontecer que trajetórias indevidas, na movimentação das figuras, levem a repulsões acidentais, fazendo o usuário perder pontos. Assim, a coordenação motora do usuário também poderá
influenciar o resultado.
O jogo está disponível para ser usado online [Kirner 2013a, Kirner 2013b], bastando que o usuário
tenha o marcador de referência do FLARAS para mostrá-lo à webcam. Se a velocidade da Internet for
muito baixa, a aplicação poderá ser baixada para uso local, sem necessidade de instalação, executando-se o arquivo “index-local-running.html”.
4.2. Ambiente do Jogo
O jogo tem quatro pontos ao redor do marcador, que mostram os sólidos geométricos e suas animações de revolução, conforme a Fig. 5.
Ao lado de cada sólido geométrico, existe uma barra que atrai a figura correspondente e repele as
restantes.
Na parte de baixo, existem quatro botões coloridos, com figuras empilhadas, que vão sendo mostradas, conforme o usuário vai nelas clicando com o mouse ou tocando com o marcador de interação.
Mais abaixo dos quatro botões, existe um rótulo, com outros empilhados, cuja navegação seqüencial vai explicando o jogo, passo a passo para iniciantes. A ativação do rótulo é opcional, podendo ser
ignorada por usuários que já conheçam o jogo.
No meio do marcador, existe outro rótulo que, quando clicado ou tocado, explica o conceito de
revolução e mostra a licença “Creative Commons” da aplicação.
4.3. Exercitando o Jogo
O jogo concede autonomia ao usuário para estabelecer sua própria abordagem vencer os desafios.
É possível resolvê-lo, de forma separada ou de forma conjunta, ou seja, identificando-se uma figura e encaixando-a no sólido correspondente, repetindo o processo até acabar, ou identificando-se
primeiramente todas as figuras, para depois fazer todos os encaixes.
21
A abordagem explicada, em seguida, é a individual. Primeiramente, ativa-se o jogo, acionando-se o seu link e autorizando o uso da webcam, fazendo aparecer a interface da aplicação, no monitor.
Em seguida, usando a barra inferior de funções, espelha-se a webcam e dá-se persistência ao marcador.
Coloca-se o marcador em frente à webcam, fazendo aparecer o ambiente do jogo. O marcador
pode ser retirado, mantendo o ambiente do jogo visível.
Nesse ponto, o jogo poderá ser iniciado, passando pelas seguintes etapas:
Escolhe-se o sólido geométrico “esfera” e clica-se nos botões inferiores até selecionar-se o círculo.
Muda-se a função do mouse para “transporte”, clicando-se no ícone da cruz azul, na barra inferior
de funções, e em seguida, clica-se na figura selecionada, arrastando-a para as proximidades do sólido
escolhido, esperando que ela seja atraída.
Muda-se a função do mouse para “navegação nas cenas”, clicando-se no ícone da seta verde apontando para a direita, e em seguida escolhe-se outro sólido. Clica-se nos botões ou nas figuras, até achar
a figura correspondente.
Repete-se o item b, até completar-se todos os sólidos.
No final, clica-se no ícone circular azul, na barra inferior de funções, para reposicionar todas as
figuras nas suas posições originais.
Para os botões voltarem a aparecer, muda-se a função do mouse para “navegação nas cenas” e
clica-se sucessivamente nas figuras, até aparecerem os botões. O jogo estará na sua situação inicial
para ser usado por outro estudante. É possível deixar a situação inicial diferente, mostrando as figuras
embaralhadas.
A qualquer momento, o jogador poderá entrar com o marcador de referência, em frente à
webcam, e movimentá-lo através de aproximação, afastamento e rotação, de forma a inspecionar os
elementos do jogo e conseguir melhor posicionamento para realizar suas interações, conforme a Fig. 6.
Figura 6. Reposicionamento do jogo usando o marcador de referência
Uma demonstração do jogo pode ser vista em vídeo [Kirner 2013b] e a execução online da aplicação pode acionada por um link [Kirner 2013a]. Além disso, o projeto do jogo está disponível para
download, permitindo a execução local, caso a Internet não tenha bom desempenho.
22
4.4. Adaptação do Jogo
O projeto do jogo também permite que os usuários possam estudá-lo e modificá-lo, gerando aplicações derivadas.
É possível trocar cada som e narração, com um clique do mouse, desde que os novos arquivos já
estejam preparados no computador do usuário. É possível também trocar as imagens, objetos 3D e
vídeos, além de alterar as animações elaboradas com o FLARAS.
Assim, depois de fazer várias alterações no projeto, cria-se um novo projeto derivado do original,
que deve ser disponibilizado, de acordo com a licença original da aplicação “Creative Commons”.
Essa facilidade de alteração permite que professores e estudantes usem a estrutura do jogo, alterem
o conteúdo, mudando ou não o tema, criando novos jogos mais apropriados para as suas necessidades
educacionais. Com um pouco mais de prática, os usuários poderão também alterar a estrutura do jogo.
Essas características facilitam a criação de novas aplicações, ajudando a disseminar a produção e
o uso de jogos educacionais com realidade aumentada.
5. Conclusões
Este artigo discutiu o uso da realidade aumentada em aplicações educacionais, levando em conta
as peculiaridades da realidade aumentada e os requisitos das aplicações educacionais.
Nesse contexto, foi identificada uma forte tendência do uso da realidade aumentada e de jogos na
educação, fazendo com que jogos educacionais com realidade aumentada apresentem uma inserção
significativa nos processos de ensino e aprendizagem, nos próximos anos.
A ferramenta de autoria de aplicações de realidade aumentada FLARAS, por ser apropriada para
elaboração de jogos educacionais com realidade aumentada, foi apresentada, discutida e utilizada na
criação do jogo educacional com realidade aumentada sobre geometria - GeomAR-Revolução, cujo
funcionamento e desenvolvimento foram detalhados neste artigo.
O jogo apresenta elementos 3D, interação tangível, visualização flexível, desafios bem definidos,
aspectos lúdicos, exigência de conhecimentos de geometria, espaços de aprendizagem, flexibilidade de
execução de ações, instruções narradas e visuais integradas, capacidade de execução online e localmente, etc.
Essas características fazem com que o jogo seja apropriado para uso em ensino e aprendizagem,
uma vez que motiva os estudantes a aprenderem e auxilia o professor.
Além disso, a ferramenta FLARAS possibilita desenvolvimento rápido de aplicações de realidade
aumentada, usando recursos disponíveis na Internet ou criados pelos próprios usuários. Outra característica importante é a alta capacidade de adaptação das aplicações desenvolvidas com FLARAS, permitindo a criação de aplicações derivadas, mais apropriadas às necessidades de professores e estudantes.
Vários jogos educacionais com realidade aumentada, baseados no FLARAS, estão sendo desenvolvidos, abrangendo: quebra-cabeças, jogos de palavras, jogos de associação, jogos espaciais, etc. com
temas em diversas áreas do conhecimento como: Física, Química, Biologia, Matemática, Línguas, etc.
Esses jogos estão em fase de avaliação, cujos resultados servirão para sua melhoria.
23
Espera-se que a facilidade de produção e de adaptação desses jogos, aliada a sua inerente capacidade de motivação nos professores e estudantes, possa dar uma contribuição efetiva à Educação,
melhorando sua qualidade e resultando em maior satisfação nas atividades de ensino e aprendizagem.
Agradecimentos
O autor agradece ao CNPQ pelo financiamento ao Projeto “AIPRA - Ambiente na Internet para
Professores desenvolverem Aplicações Educacionais com Realidade Aumentada” (Processo CNPq
559912/2010-2), que viabilizou o desenvolvimento deste trabalho.
Referências
CERQUEIRA, C. S. e Kirner, C. (2011) “basAR: Ferramenta de Autoria de Realidade Aumentada com
Comportamento”, In VIII Workshop de Realidade Virtual e Aumentada, Uberaba, SBC, v. 1, p. 1-6.
CERQUEIRA, C.; KIRNER, C. (2012) “Developing Educational Applications with a Non-Programming
Augmented Reality Authoring Tool”, In Proceedings of World Conference on Educational Multimedia,
Hypermedia and Telecommunications 2012, Chesapeake, VA: AACE, p. 2816-2825, , http://www.editlib.
org/p/41166.
HAMILTON, K. E. (2013) “Augmented reality in education”, http://wik.ed.uiuc.edu/articles/a/u/g/
Augmented_Reality_in_Education_51fa.html
JOCHIM, S. (2010) “Augmented Reality in Modern Education”, http://augmentedrealitydevelopmentlab.
com/wp-content/uploads/2010/08/ARDLArticle8.5-11Small.pdf.
JOHNSON, L.; ADAMS, S.; CUMMINS, M. (2012) “NMC Horizon Report: 2012 K-12 Edition”, Austin,
Texas, The New Media Consortium, http://www.nmc.org/pdf/2012-horizon-report-K12.pdf.
JOHNSON, L.; SMITH, R.; WILLIS, H.; LEVINE, A.; HAYWOOD, K. (2011) “The 2011 Horizon Report”,
Austin, Texas, The New Media Consortium, http://net.educause.edu/ir/library/pdf/HR2011.pdf.
KATO, H. ; BILLINGHURST, M. (1999) “Marker Tracking and HMD Calibration for a Video-based
Augmented Reality”, In Conferencing System IWAR’99, The 2nd Int. Workshop on Augmented Reality,
San Francisco, USA, p. 85-94.
KIRNER, C. (2011) “Prototipagem Rápida de Aplicações Interativas de Realidade Aumentada”, In
Siscoutto, R.A. e Brega, J.R.F . ed. Tendências e Técnicas em Realidade Virtual e Aumentada, SBC, p. 29-54.
KIRNER, C. (2013a) “Projeto AIPRA – Ambiente na Internet para os Professores Desenvolverem
Aplicações Educacionais com Realidade Aumentada”, http://www.ckirner.com/aipra.
KIRNER, C. (2013b) “GeomAR-Revolução – Jogo Educacional de Geometria s envolvendo Geração de
Sólidos por Revolução de Figuras Planas”, http://www.youtube.com/watch?v=JZsEHL32QNA.
24
KIRNER, C.; CERQUEIRA, C.; KIRNER, T.G. (2012) “Using Augmented Reality in Education and
Cognitive Rehabilitation”, In Eichenberg, C. ed, Virtual Reality in Psychological, Medical and Pedagogical
Applications, Intech, p. 247-270, http://www.intechopen.com.
KIRNER, C.; KIRNER, T. G. (2011) “Development of an Educational Spatial Game using an Augmented
Reality Authoring Tool”, International Journal of Computer Information Systems and Industrial
Management Applications. N.3, Vienna: MIR Labs, p. 602-611.
KIRNER, C.; KIRNER, T. G.; REZENDE JUNIOR, M. F.; SOUZA. R. C. (2012) “Realidade Aumentada
Online na Educação Aberta”, In Okada, A. ed, Open Educational Resources and Social Networks: CoLearning and Professional Development, 1st ed. Scholio Educational Research & Publishing, p.1-19,
http://oer.kmi.open.ac.uk.
KIRNER, C.; SANTIN, R. (2009) “Interaction, Collaboration and Authoring in Augmented Reality
Environments”. Proceedings of XI Symposium on Virtual and Augmented Reality. Porto Alegre, SBC, p.
210-220.
METAIO (2013) “Augmented Reality SDK for App Development” http://www.metaio.com/products/sdk.
NMC (2012) “NMC Horizon Project Short List: 2013 Higher Education Edition”, Austin, Texas, The New
Media Consortium, http://www.nmc.org/pdf/2013-horizon-higher-ed-shortlist.pdf.
NMC (2013) “NMC Horizon Reports”, Austin, Texas, The New Media Consortium, http://www.nmc.org/
horizon-project/horizon-reports.
OKADA, A. ed. (2012) Open Educational Resources and Social Networks: Co-Learning and Professional
Development, 1st ed. Scholio Educational Research & Publishing. http://oer.kmi.open.ac.uk.
REIS, F. M. V.; KIRNER, T. G. (2011) “Desenvolvimento de um livro com realidade aumentada para o
ensino de geometria”, Anais do VIII Workshop de Realidade Virtual e Aumentada - WRVA 2011, Uberaba,
MG, p. 1-6.
SAQUOSHA (2008) “FlarToolKit”, http://saqoo.sh/a/flartoolkit/start-up-guide.
SOUZA, R .C.; KIRNER, C. (2013) “Marcador de Referência do FLARAS”, http://ckirner.com/FLARAS2/
wp-content/uploads/2012/09/ref-marker.pdf.
SOUZA, R. C.; MOREIRA, H. D. F.; KIRNER, C. (2013) “FLARAS - Flash Augmented Reality Authoring
System”, http://ckirner.com/FLARAS2.
Trimble/Google (2013) “Trimble/Google Armazém 3D”, http://sketchup.google.com/3dwarehouse.
UCELLI, G.; CONTI, G.; AMICIS, R. D.; SERVIDIO, R. (2005) “Learning using augmented reality
technology: multiple means of interaction for teaching children the theory of colours”, Lecture Notes in
Computer Science, 2005, vol. 3814/2005, p. 193-202.
25
26
SILVA, Luciano. Visualização e Interação em Arquitetura via RV e RA.
Visualização e Interação
em Arquitetura via RV e RA
Luciano Silva
Abstract
Both physical and virtual architectural designs are suitable environments for applying VR and AR techniques. Collaborative design, design visualization, virtual tours, virtual environments evaluation and
decoration are some possible examples on using of these techniques. Within this context, this chapter
introduces the use of VR and AR to various demands in architecture and additionally features an integrated result in the TICHIS project, aimed at RV-based architectural designs for social concerned housing.
Resumo
Projetos arquitetônicos físicos e virtuais são ambientes adequados para uso de técnicas de RV e RA. Projeto
colaborativo, visualização de projetos, tours virtuais, avaliação de ambientes e decoração virtual são alguns
exemplos possíveis de utilização destas técnicas. Dentro deste contexto, este capítulo apresenta o uso de RV e
RA para diversas demandas em arquitetura e, adicionalmente, apresenta um resultado integrado no projeto
TICHIS, direcionado a projetos arquitetônicos baseados em RV para habitações de interesse social.
1. Introdução
A área de Arquitetura, como qualquer outra área de projeto que explora produção de ambientes
físicos como a Engenharia Civil, oferece grandes desafios como projeto colaborativo, visualização,
produção de protótipos e manutenção, que podem ser abordados de forma bastante adequada por
técnicas de RV e RA.
Os processos disponibilizados por RV e RA permitem visualizações com alto grau de aderência
aos modelos físicos reais, além de um grande suporte à colaboração na definição e discussão de projetos, integração com ambientes de fabricação digital, interação com usuários para visualização de projetos e alta portabilidade entre diversas plataformas de acesso como Web, computadores e notebooks,
tablets e celulares, facilitando a mobilidade no acesso aos projetos.
26
Dentro deste contexto, este capítulo apresenta os principais problemas em Arquitetura que podem
ser abordados por processos de RV e RA. Para cada um deles, são apresentadas alternativas e possibilidades de uso destes processos. Além disto, é apresentado um caso real - Projeto TICHIS - , onde
técnicas de RV e RA têm sido utilizadas com sucesso no projeto e construção de habitações de interesse
social (HIS).
O texto está organizado da seguinte forma:
• a Seção 1.2 apresenta os principais problemas em projeto, produção e manutenção em Arquitetura;
• a Seção 1.3 apresenta alternativas de RV e RA para o problema de projeto;
• a Seção 1.4 apresenta alternativas de RV e RA para o problema de fabricação digital;
• a Seção 1.5 apresenta alternativas de RV e RA para o problema de manutenção e reparo;
• a Seção 1.6 apresenta o projeto TICHIS e os seus resultados;
• a Seção 1.7 apresenta os comentários finais deste capítulo e
• finalmente, a Seção 1.8 apresenta um conjunto de referências bibliográficas aos interessados
em iniciar desenvolvimentos nesta importante área de pesquisa.
2. Problemas de Projeto, Produção e Manutenção em Arquitetura
Um problema central em Arquitetura refere-se à lacuna entre a representação do espaço arquitetônico e o entendimento real de como o espaço se distribui em uma edificação, segundo Zevi (1994), dado
que plantas, fachadas e elevações de um edifício correspondem a projeções abstratas, utilizadas muitas
vezes somente para se medir as distâncias entre os diversos elementos que permitam a execução da obra.
Isto leva a uma distância cognitiva entre o objeto real e sua representação em um planta, conforme
mostra a Figura 1:
Figura 1: Um objeto arquitetônico e sua representação por planta.
Fonte: www.totalcad.com.br
27
É comum, devido a processos de projeto em Arquitetura, as plantas ficarem limitadas a projeções
bidimensionais, que aumentam ainda mais as distâncias cognitivas para geração “mental” de um modelo tridimensional do objeto a ser construído. Assim, novas técnicas de projeto que permitam aos
arquitetos explorar consistentemente seus projetos diretamente no ambiente 3D é de grande interesse
em Arquitetura.
Sem o uso de um ambiente computacional adequado, a Arquitetura muitas vezes recorreu ao uso
de maquetes físicas (Ching, 2007), conforme mostra a Figura 2:
Figura 2: Produção de maquetes físicas a partir de plantas arquitetônicas.
Mesmo que as maquetes consigam transpor a limitação da representação bidimensional das plantas, elas exibem alguns complicadores no seu uso extensivo: custo, velocidade de produção e alteração,
mobilidade.
Uma vez que o projeto estrutural de ambiente arquitetônico esteja definido, quer seja por uma
planta ou por uma maquete, surge outro problema interessante: a decoração interior (Tangaz, 2006). A
Figura 3 exibe dois exemplos de projeto de decoração de interiores:
28
Figura 3: Representações arquitetônicas para decoração de interiores.
Novamente, aqui se apresentam as dificuldades de se imaginar como será o ambiente real a ser
produzido por esta decoração e, caso o cliente necessite realizar alterações, novas plantas (ou maquetes) deverão ser produzidas.
Muitas vezes, após o projeto, são construídos modelos em escala através de técnicas de prototipação, conforme mostra a Figura 4:
Figura 4: Protótipo em escala produzido por máquina de corte computadorizada.
Fonte: tatapress.blogspot.com.br/p/fabricacao-digital.html
29
Neste exemplo, foi aplicada a técnica de fabricação digital (Dunn, 2012), que permite que dados
de uma planta arquitetônica possa ser passada diretamente a sistemas de CAM (Computer Aided Manufacturing) para produção dos modelos em escala, objetivando-se uma visualização mais realista do
projeto ou mesmo para testes estruturais reais. Aqui, o problema é como passar de forma transparente
do ambiente de projeto para o de prototipação.
Finalmente, outro problema bastante comum em Arquitetura refere-se à manutenção e reforma de
ambientes já construídos (Maciha, 2005), conforme mostra a Figura 5:
Figura 5: Processo de reforma em Arquitetura.
Fonte: blog-br.com/multpredial#.UU-fzByTjSg
Na área de manutenção, existem inúmeros problemas como, por exemplo:
• como prever os impactos da manutenção e gerar cenários possíveis de avaliação destes impactos ?
• como disponibilizar um ambiente de visualização aos usuários de tal forma que possibilidades de alteração de projeto possam ser discutidas ?
• como integrar o processo de reforma com sistemas de predição de custos e acompanhamento
da obra ?
Especialmente para os dois primeiros problemas, existem várias alternativas tanto em RV quanto
em RA para abordá-los.
30
3. Aplicações de RV e RA em Projeto Arquitetônico
A fase de projeto arquitetônico evoluiu muito nos últimos anos com o uso das maquetes virtuais
(Kolarevic, 2005), que traz projetistas e clientes para um ambiente comum de projeto e discussão de
alternativas e alterações. A Figura 6 mostra um exemplo de maquete virtual para arquitetura:
Figura 6: Maquete virtual produzida no ambiente Sketchup.
Fonte: blog.3dm.com.br/tapa-maquete-eletronica-realista-para-sketchup-e-revit/
Existem diversos ambientes e softwares que podem produzir maquetes virtuais como, por exemplo, o Google Sketchup (www.sketchup.com) e o Revit (www.autodesk.com/revitarchitecture). O Google
Sketchup, em particular, permite que maquetes virtuais sejam posicionadas sobre ambientes reais no
Google Maps, conforme mostrado na Figura 7:
Figura 7: Maquetes virtuais posicionadas sobre um suporte geográfico (Google Maps).
Fonte: maps.google.com
31
Na linha específica de RV, maquetes arquitetônicas podem ser visualizadas em displays que permitem experimentar a sensação de tamanho natural dentro de cavernas digitais, assim como interagir
com os elementos do cenário (Figura 8):
Figura 8: Visualização de maquetes virtuais em cavernas digitais.
Fonte: www.iff.fraunhofer.de
Na linha de RA, é possível se utilizar marcadores específicos em plantas bidimensionais, que podem ser substituídos por maquetes virtuais, conforme mostra a Figura 9:
Figura 9: Substituição de marcadores de RA por maquetes em plantas arquitetônicas.
Fonte: www.db-rep.net
32
4. Aplicações de RV e RA em Fabricação Digital
Assim como o projeto arquitetônico, a fabricação de modelos em escala reduzida ou natural já
utiliza recursos digitais de fabricação direta (Agkathidis, 2011). A partir de maquetes virtuais, impressoras 3D produzem o modelo na escala desejada, conforme mostra a Figura 10:
Fonte: www.futureconverged.com
Fonte: cloudtimes.org
Figura 10: Modelo digital impresso digitalmente e impressora 3D baseada em resina.
Grande parte dos softwares para impressoras 3D e sistemas de fabricação digital 3D já possuem
ambientes de RV integrados para visualização, conforme ilustra a Figura 11:
Figura 11: Ambiente baseado em RV para impressão 3D.
Fonte: www.virtualrobotix.com
33
Uma vez que o modelo arquitetônico esteja impresso, sistemas de RA podem expandir a visualização do modelo acrescentando novos detalhes que seriam difíceis de serem impressos como, por
exemplo, a vegetação mostrada na Figura 12:
Figura 12: Expansão da visualização de modelo 3D impresso via RA móvel.
Fonte: www.dezeen.com
Sistemas de RA também disponibilizam a facilidade de discussão de objetos diretamente da sala
de impressão, através de marcadores que podem ser colocados diretamente nas mãos dos operadores
das impressoras 3D, conforme mostra a Figura 13:
Figura 13: Apresentação, via RA, de objeto arquitetônico a ser impresso.
Fonte: 3dprintineducation.wordpress.com
34
5 Aplicações de RV e RA em Manutenção Arquitetônica
Na linha de manutenção e reparos em Arquitetura, há um grande nicho de aplicações tanto para
sistemas de RV quanto RA. Porém, ambos os sistemas dependem que haja uma versão digital do ambiente a ser vistoriado e reparado.
Neste sentido, para um ambiente devidamente sensorizado, um sistema de RV permite a um arquiteto vistoriar e decidir por reparos diretamente no modelo virtual, através de um tour virtual ilustrado na Figura 14:
Figura 14: Tour virtual de um arquiteto para fins de inspeção e decisão de reparos.
Fonte: www.sciencedirect.com/science/article/pii/S0965997812001299
Em RA móvel (Madden, 2011), por exemplo, a visita técnica para manutenção e reparo não necessita mais que o arquiteto leve consigo uma planta. Utilizando um dispositivo como um celular ou um
tablet, a imagem real pode ser fundida com elementos técnicos de número de equipamentos e seus status de funcionamento, como ilustra a Figura 15, onde os dados de um sistema de proteção a incêndios
são exibidos ao arquiteto na tela de um celular:
35
Figura 15: Sistema de RA para manutenção arquitetônica.
Fonte: www.igd.fraunhofer.de
Em um processo de registro mais complicado, é possível via RA se sobrepor todos os detalhes de
uma planta arquitetônica sobre o ambiente que está sendo vistoriado, conforme ilustra a Figura 16:
Figura 16: Registro de plantas arquitetônicas diretamente sobre cenas reais.
Fonte: www.eonreality.com
Um dos complicadores atuais neste registro ainda é a dependência de equipamentos desconfortáveis como óculos misturadores, em processos longos de vistoria e reparo. Porém, com tecnologias que
estão surgindo no mercado como o Google Glass (Figura 17), existe uma tendência que estas soluções
sejam cada vez mais comuns.
36
Figura 17: Google Glass como elemento mínimo para mistura de imagens em RA.
Fonte: www.google.com/glass
6 Projeto TICHIS
O Projeto TICHIS (Tecnologias de Informação e Comunicação para Habitações de Interesse Social)
é um grande projeto financiado pela FINEP e que congrega diversas universidades no país: USP, Mackenzie, URGS, UFPR, UNICAMP e UFPR. O objetivo principal deste projeto é explorar as diversas
tecnologias da informações para projeto e produção de habitações de interesse social como, por exemplo, as casas desenvolvidas por projetos governamentais na área de habitação.
A Meta 53 deste projeto, de responsabilidade do autor deste capítulo, tem como objetivo desenvolver uma metodologia para uso de ambientes baseados em Realidade Virtual e Aumentada em projetos
colaborativos de habitações de interesse social. A partir desta metodologia, será produzido um sistema
colaborativo onde diversos usuários (arquitetos, engenheiros e moradores) possam discutir suas idéias
dentro um ambiente imersivo comum, conforme mostrado na Figura 18:
Figura 18: Três usuários [engenheiros, arquitetos e moradores] com um objeto comum (habitação) em
discussão.
37
Moradores podem, por exemplo, visitar virtualmente a habitação antes dela ser construída. Arquitetos e engenheiros podem discutir detalhes de projeto dentro de um ambiente comum.
A metodologia para consecução desta meta foi formada pelos seguintes passos:
1. Levantamento do estado-da-arte em interfaces para sistemas colaborativos em arquitetura
2. Levantamento do estado-da-arte em visualização de projetos em arquitetura, com ênfase em
BIM (Building Information Modeling)
3. Definição do projeto de interface do sistema colaborativo para o projeto TICHIS
4. Definição de contextos de navegação dentro do sistema colaborativo
5. Implementação do projeto de interface e contexto de navegação
6. Testes com usuários.
Após análise das diversas alternativas existentes na literatura técnica, optou-se pelo uso de uma
interface bastante limpa, formada por um cubo de imersão (CAVE), um sistema de tracking (Microsoft
Kinect) e um óculos 3D (ativo ou passivo) para aumentar a imersão, conforme mostra a Figura 19:
Figura 19: Componentes da interface de imersão do TICHIS (CAVE, óculos e Kinect).
Para os processos de visualização, foi escolhida a ferramenta Quest3D (www.quest3d.com), que
permite uma integração muito simples com diversos dispositivos de Realidade Virtual e Aumentada.
Dentro desta ferramenta, modelos arquitetônicos BIM são convertidos para o formato do Quest3D,
como mostrado na Figura 20:
38
Figura 20: Modelo BIM carregado na ferramenta Quest3D.
Além das funcionalidades de interação da ferramenta Quest3D, ela permite trabalhar de maneira
bastante simplificada com projeções em diversos projetores acoplados, inclusive com separação automática de imagens entre os projetores. Cada etapa de controle do sistema de sistema de visualização do
TICHIS é efetuada em um nós especifico do grafo de cena definido no Quest3D, conforme mostrado
na Figura 21:
Figura 21: Nós do grafo de cena do Quest3D.
39
Além disto, foi implementada a integração entre o Kinect e o Quest3D para navegação básica dentro das cenas, permitindo o uso de até 03 (três) Kinects simultâneos, o que pode rastrear até 12 (doze)
usuários, conforme mostra a Figura 22:
Figura 22: Mapas de profundidade de três Kinect, com sete usuários identificados.
Pela estrutura atual do sistema, é possível a inclusão mais Kinects. Porém, a queda de desempenho
devido às velocidades de comunicação USB (que liga o Kinect aos computadores) não recomenda um
aumento destes equipamentos. Além disto, pelo tamanho da CAVE (3 m x 3m x 3m), mais do que doze
pessoas poderia comprometer a mobilidade dentro do cubo de interação. Na linha de otimização das
operações gráficas, foram estudadas e estendidas diversas técnicas para CUDA, a linguagem de programação das placas gráficas do projeto. Além disto, foram estudadas técnicas baseadas em nuvens de
pontos (Point Based Graphics) para acelerar os processos de renderização e de Física.
Este trabalho também se concentrou no projeto de modelos de contexto de navegação para os
diversos usuários do sistema. Estes modelos são baseados em Redes de Petri, que permitem definir
lugares e regras de transição entre estes lugares, conforme mostra a Figura 23:
Figura 23: Rede de Petri, com indicação de lugares (P1…P4) e transições (T1 e T2).
40
As Redes de Petri foram aplicadas da seguinte maneira nos modelos de arquitetura: partes da
construção são os lugares e, a passagem entre os lugares, como transições, conforme mostrado na
Figura 24:
Figura 24: Lugares e transições em uma construção.
Os contextos de navegação (elementos que poderão ser exibidos a cada usuário) são definidos
dentro de zonas. Cada zona é associada a um lugar na Rede de Petri. Assim, cada modelo que for carregado no Quest3D precisa ser zoneado e todas as informações que podem ser visualizadas devem estar
associadas a sua respectiva zona.
A Figura 25 mostra uma construção e seu zoneamento:
Figura 25: Um exemplo de construção e suas zonas(2 – verde e vermelha).
41
O sistema já foi testado com exibição de informações fictícias (não-reais) apenas para fins de verificação da implementação. Quando o modelo real do projeto TICHIS for definido, testes mais efetivos
deverão ser realizados.
7 Considerações Finais
A área de Arquitetura oferece problemas e demandas que são muito aderentes aos desafios procurados no projeto e desenvolvimento de sistemas de RV e RA. Assim, trata-se de uma área com enorme
potencial para pesquisa e desenvolvimento de produtos, tanto na linha teórica quanto prática. Assim,
o autor espera que esta pequena introdução ao tema tenha mostrado os principais problemas da área,
discutido algumas alternativas para abordar estes problemas e, principalmente, que ela possa despertar
o interesse de alunos e pesquisadores para estes problemas.
8 Referências
AGKATHIDIS, A.(2011) “Digital Manufacturing: In Design and Architecture”. New York: BIS Publishers.
CHING, F.D.K. (2007) “Architecture: Form, Space and Order”. New York: John Wiley & Sons.
CRAIG, A.B. (2009) “Developing Virtual Reality Applications: Foundations on Effective Design”. New
York: Morgan Kaufmann.
DUNN, N. (2012) “Digital Fabrication in Architecture”. New York: Laurence King Publishers.
KOLAREVIC, B. (2005) “Architecture in the Digital Age: Design and Manufacturing”. New York: Taylor
& Francis.
MACIHA, J.C. (2005) “Preventive Maintenance for Multi-Family Housing”. New York: RSMeans.
MADDEN, L. (2011) “Professional Augmented Reality Browsers for Smartphones”. New York: Wrox.
TANGAZ, T. (2006) “Interior Design Course: Principles, Practices and Techniques for the Aspiring
Designer”. New York: Barron.
ZEVI, B. (1994) “Saber ver a Arquitetura”. São Paulo: Martins Fontes.
42
43
RODELLO, Ildeberto A., et al. Realidade Virtual e Aumentada Aplicada na Área de Negócios:
casos na área de Marketing e de Projeto e Desenvolvimento de Produtos.
Realidade Virtual e Aumentada Aplicada na Área de
Negócios: casos na área de Marketing e de Projeto e
Desenvolvimento de Produtos
Ildeberto A. Rodello
Marize Minakawa
Thais F. da Paz
José R. F. Brega
Abstract
It is increasingly the use of Virtual and Augmented Reality by Organizations. Nowadays, it is possible to
highlight a set of initiatives based on Virtual and Augmented Reality already used by Organizations, with
diverse objectives, as: prototyping and product’s presentation, reducing time and costs of development,
better understand and improve the relationship with customers, branding valorization, among others. In
this context, this Chapter aims at presenting examples of Virtual and Augmented Reality used by Organizations in Marketing and products project and development areas.
Resumo
Cada vez mais as Organizações estão utilizando a tecnologia de Realidade Virtual e Aumentada nas
suas ações. Atualmente é possível elencar uma série de iniciativas com Realidade Virtual e Aumentada
que já estão em produção nas Organizações, com diversos objetivos, tais como: facilidades para prototipagem e apresentação de produtos, diminuição no tempo de desenvolvimento e nos custos envolvidos,
melhor relacionamento com clientes, valorização de marca, dentre outros. Nesse contexto, este Capítulo
tem como objetivo apresentar exemplos de ações reais que as Organizações estão utilizando nas áreas de
Marketing e de projeto e desenvolvimento de produtos.
1. Contextualização
São vários os objetivos que levam as Organizações a utilizarem a Tecnologia de Informação e
Comunicação (TIC) em suas atividades. Laudon e Laudon (2010) enumeram i) proporcionar excelência operacional; ii) apoiar a criação de novos produtos, serviços e modelos de negócio; iii) estreitar
o relacionamento com clientes e fornecedores; iv) melhorar a tomada de decisão; v) obter vantagem
competitiva e, em alguns casos vi) sobreviver.
43
Com o notável barateamento e popularização dos dispositivos de TIC (computadores e periféricos) e a consequente facilidade de acesso aos recursos proporcionados (Sistemas de Informação e
aplicativos), simplesmente ter o uso por questões operacionais ou mesmo gerenciais/táticas, pode não
proporcionar efetivamente para as Organizações um diferencial competitivo. Dessa forma, buscar a
inovação em termos do uso da TIC e seus recursos passou a ser primordial em alguns segmentos.
Não obstante a utilização mais notável da Realidade Virtual e Aumentada (RVA) em diversas áreas
do conhecimento tais como Saúde, Engenharia e Educação, entre outros, com mais diversas finalidades, a área de Negócios também direciona atenções para sua aplicação principalmente na tentativa de
agregar valor a seus produtos e buscar um diferencial competitivo nas suas ações estratégicas, ou seja,
em potencializar os objetivos mencionados anteriormente.
Quando se menciona a área de Negócios, entende-se aquela que envolve principalmente Empresas
e suas ações para alcançar determinadas metas estratégicas e competitivas. Observa-se que a RVA
tem ganhado espaço em diversas vertentes organizacionais, tais como: peça em ações de Marketing,
instrumento de apoio no projeto e desenvolvimento de produtos, fonte de aproximação com potenciais
clientes, treinamento, dentre outros.
Nesse contexto, o principal objetivo desse Capítulo é apresentar e discutir como a RVA tem sido
aplicada em ações de Marketing e no projeto e desenvolvimento de produtos, procurando-se discutir
e estabelecer vantagens e desvantagens nos cenários apresentados. Procurou-se mesclar tanto casos
utilizados no Brasil quanto no exterior, não objetivando uma discussão exaustiva do assunto, mas sim,
instigar o leitor em elaborar soluções derivadas e que possam resultar em trabalhos futuros.
Destaca-se que há outras formas de utilização da RVA para outros escopos dentro de uma Organização. No entanto, por conveniência de estudo, este Capítulo tem foco tão somente nas duas áreas
organizacionais supracitadas.
Para a exposição do assunto, a seção 1.2 apresenta um cenário de evolução do conceito de RV, com
o aparecimento do termo RM e suas derivações. Na seção 1.3 é apresentado o conceito de empresa. O
escopo do Marketing, envolvendo definição e sua inserção dentro de uma organização, é apresentado
na seção 1.4, bem como as vantagens e desvantagens da utilização da RVA no Marketing. A seção 1.5
apresenta alguns exemplos de uso da RVA em Marketing. Os conceitos relacionados ao processo e desenvolvimento de produtos são descritos na seção 1.6 e, em seguida, (seção 1.7) são apresentados alguns
exemplos de uso da RVA em dois setores específicos: automobilístico e aeronáutica. Todo esse contexto
embasa as considerações finais na seção 1.8.
2. A Evolução do Conceito “Realidade Virtual”
Concomitantemente ao processo evolutivo dos equipamentos e dispositivos de RV, o termo também “evoluiu”. Historicamente atribui-se o termo “Realidade Virtual” a Jaron Lanier, cientista da computação, artista visual e compositor, que no final da década de 80 sugeriu a junção de dois conceitos
antagônicos para a criação dessa emergente área de pesquisas que busca unir o real com o virtual.
A RV pode ser interpretada como a interface mais natural, poderosa e avançada de interação entre
homem-máquina, que permite interação, navegação e imersão em um ambiente sintético tridimensio-
44
nal de forma natural e intuitiva, em tempo real, utilizando canais multisensoriais tais como a visão, a
audição, o tato e o olfato (Burdea e Coiffet, 1994). (Pinho; Kirner, 1997) (Tori e Kirner, 2006).
Desde então, vários pesquisadores tentam caracterizar diferenciações entre a proporção de real
e virtual presentes em um determinado ambiente, além de cunhar termos para tanto. Uma dessas
caracterizações refere-se ao continuum de virtualidade proposto por Milgram et al. (1994). Pela Figura
1 é possível observar que nas extremidades são caracterizados os ambientes reais e virtuais. Quando
há predominância do virtual sobre o real, denomina-se Virtualidade Aumentada (VA) e, ao contrário,
Realidade Aumentada (RA). Ao conjunto, tanto VA quanto RA, caracteriza-se por RM.
Realidade Misturada
Ambiente
Real
Realidade
Aumentada
Virtualidade
Aumentada
Ambiente
Virtual
Figura 1. Continuum de Virtualidade.
Adaptado de Milgran et al. (1994)
Por ambiente virtual entende-se aquele ambiente totalmente gerado por computador, podendo ou
não representar um ambiente já existente. Por ambiente real considera-se aquele ambiente palpável,
que existe na realidade.
3. O Conceito de Empresa
De acordo com Bateman e Snell (1998), uma empresa é “um sistema administrado projetado e
operado para atingir determinado conjunto de objetivos”. Tal sistema é um conjunto de partes (Figura
2) que processam insumos em saídas.
Uma Empresa com fins lucrativos tem os objetivos de (Bateman; Snell, 1998): i) realizar lucro
para seus donos; ii) fornecer bens e serviços aos clientes; iii) prover renda para seus funcionários; e iv)
aumentar o nível de satisfação de cada um dos seus envolvidos.
Para atingir esses objetivos, uma Organização divide, executa e coordena as atividades que são
estruturadas de diversas formas. Uma das formas de se estruturar prevê a divisão da Organização em
departamentos com funções específicas (vendas, produção, marketing, recursos humanos, etc.), com
organização hierárquica e funções definidas.
45
AMBIENTE EXTERNO
Insumos
(Recursos)
Humanos
Financeiros
Físicos
Informação
Organização
Resultados
Processo de
Transformação
Bens
Serviços
Figura 2. Partes de um Sistema Organizacional.
Adaptado de Bateman e Snell (1997)
Potencialmente, a tecnologia de RVA pode ser aplicada em cada uma dessas áreas, evidentemente
com objetivos diferentes. Na área de recursos humanos, por exemplo, por ser utilizada em treinamentos. Ou ainda para simular processos de negócios (Diniz et al.; 2004). No contexto desse Capítulo,
abordar-se-á a RVA nas áreas de Marketing e projeto e desenvolvimento de produtos.
4. O Escopo do Marketing
Segundo Kotler e Keller (2006), em uma definição ampla, o Marketing “envolve a identificação
e a satisfação das necessidades humanas e sociais”. Essa definição tem duas perspectivas: social e gerencial. Na perspectiva social, o Marketing visa entender as necessidades dos clientes e oferecer bens e
serviços que os atendam plenamente. Na ótica gerencial, por sua vez, ele é entendido como a “arte de
vender produtos”, ou seja, como uma organização pode vender mais bens ou serviços e, consequentemente, obter mais lucro.
Por organização, entende-se:
“(...) é uma coletividade com uma fronteira relativamente identificável, uma
ordem normativa (regras), níveis de autoridade (hierarquia), sistemas de comunicação e sistemas de coordenação dos membros (procedimentos); essa coletividade existe em uma base relativamente contínua, está inserida em um
ambiente e toma parte de atividades que normalmente se encontram relacionadas a um conjunto de metas; as atividades acarretam conseqüências para
os membros da organização, para a própria organização e para a sociedade”
(Hall, 1984).
46
Nessa definição destaca-se a palavra coletividade, que apresenta uma Organização como um conjunto de indivíduos, seguindo regras e uma hierarquia. A forma de organização mais comum dessa
coletividade é a funcional, onde se agrupa por áreas de especialização em áreas funcionais distintas,
ou seja, são agrupados por departamentos num primeiro nível: Marketing, Produção, Informática,
Financeiro, etc.
Assim, é possível situar o Marketing nesse contexto da coletividade organizacional e estabelecer
seus relacionamentos com os demais departamentos. Uma ação de Marketing não implica somente na
atuação do departamento isoladamente, mas também de outros departamentos como corresponsáveis.
Para a American Marketing Association (apud Kotler e Keller, 2006), “o Marketing é uma função
organizacional e um conjunto de processos que envolvem a criação, a comunicação e a entrega de valor
para os clientes, bem como a administração do relacionamento com eles, de modo que beneficie a organização e seu público interessado.” Nesse cenário, a RVA pode atuar como uma peça de uma ação de
Marketing com potencial para auxiliar a criação, a comunicação e a entrega de valor para os clientes.
Há algumas vantagens e desvantagens relacionadas ao seu uso que são destacadas adiante.
4.1. Vantagens da RVA em Marketing
O uso da RV dentro do escopo do Marketing apresenta algumas vantagens. Apesar de ter 10 anos,
aquelas apresentadas por Ryan (2001) ainda tem pertinência no cenário atual, a saber.
A RV apresenta a capacidade de dar ao usuário a verdadeira experiência de propriedade do produto, sem a necessidade de envio de amostras. Isso acontece quando, por exemplo, o usuário pode interagir com a modelagem de um produto, observando detalhes externos e de funcionamento. Isso permite
ao cliente conhecer melhor as características de um produto antes de comprá-lo. Para a Empresa, a
expectativa é a diminuição de custos com a produção e envio de protótipos ou amostras.
Outra vantagem é a habilidade para demonstrar os produtos em tempo real, utilizando os parâmetros definidos pelo usuário. Pessoas tem diferentes perspectivas sobre um determinado produto.
Permitir que ela possa simular a utilização para a finalidade desejada é importante para que o usuário
decida-se. Além disso, Explicar como equipamentos industriais ou produtos complexos operam pode
ser complicado. A RV é uma excelente ferramenta para comunicar as operações e as capacidades de um
produto ou máquina
A RV é, por definição, multissensorial. Assim, a capacidade para envolver o usuário emocionalmente com o produto (por meio de imersão sensorial.) produz um importante diferencial. Dessa forma, é aconselhável uma apresentação rica em termos de interação.
Para a criação de novos produtos, a RV caracteriza-se pela capacidade e facilidade para implementação de protótipos e realização de testes, gerando economias de custo e tempo, além de melhorar
a tomada de decisão. Uma fabricante de aviões pode, pode exemplo, criar vários protótipos de um
determinado avião e realizar simulações para eliminar o máximo possível de erros antes da produção
de protótipo físico.
Pela característica da imersão, a RV permite uma associação mais estreita entre os meios e as mensagens, uma vez que os usuários entram no canal de mídia e se tornam uma parte dela. Além disso,
há um grande aumento no potencial de mercado uma vez que a sua experiência com o produto pode
47
ser compartilhado por qualquer pessoa no mundo que tem o hardware necessário / software. Nesse
contexto a internet tem papel fundamental.
Por fim, apresenta a possibilidade de se usar todos os quatro elementos do paradigma de novas
comunicações (entreter, informar, persuadir e interagir).
4.2. Desvantagens da RVA em Marketing
Ainda segundo Ryan (2001), não é somente de vantagens que há no uso da RV. Dentre as desvantagens é possível observar que:
Não é apropriado para determinados produtos. RV funciona melhor com os produtos que requerem uma grande interação do usuário. Produtos que dependem do tato e do olfato apresentam grandes
dificuldades para as soluções em RV.
Mesmo com a diminuição de preço de equipamentos, a RV ainda será uma ferramenta de Marketing cara. Necessita ainda que o usuário, em alguns casos, possua um dispositivo para interagir ou
visualizar. Além disso, o processo de criação da RV é, e será, um processo complexo, que depende de
recursos humanos, software e hardware especializados.
Por fim, para algumas soluções há certo inconveniente em ter que fazer o download e instalação
do aplicativo. A velocidade da conexão e os requisitos necessários para instalação podem ser fatores
complicadores.
5. Exemplos de Utilização da RVA em Ações de Marketing
Nessa seção são apresentados alguns exemplos de utilização de RVA, mais especificamente RA,
com os mais diversos objetivos do ponto de vista do Marketing. O objetivo não é esgotar todos os casos,
mas apresentar uma visão geral dos que serão principais para os autores.
5.1. Demonstrações de Produtos
Para produtos como roupas e acessórios, um dos principais obstáculos para a efetivação de compras principalmente na Internet é o fato do cliente ter receio se o produto servirá ou lhe agradará.
Nesse contexto, a Ray-Ban lançou em 2009 um site denominado Ray-Ban Virtual Mirror (http://www.
ray-ban.com/USA/) onde, por meio de recursos de RA sem marcadores (markless), é possível experimentar virtualmente diversos modelos de óculos de sol. A Figura 3(a) exibe um screenshot da execução
do aplicativo.
Os pontos fortes da solução apontam para a utilização de que não requer nenhum marcador especial, para a possibilidade do usuário provar qualquer par de óculos de sol de uma coleção atual, ou
seja, elimina a possibilidade de que o produto desejado esteja fora de estoque e para o grande potencial
de interatividade proporcionado.
48
(a)
(b)
Figura 3. Ray-Ban Virtual Mirror e Vitrine Virtual Tissot
Fontes: (a) Oliveira (2012) e (b) Divulgação Tissot
Os pontos fracos que podem ser apontados remetem para a necessidade de se fazer download do
aplicativo, o que pode demandar certo tempo dependendo do tamanho do arquivo e da conexão, requer sistema operacional Windows e computador atualizado.
Com a utilização de marcadores, diversas peças de Marketing para demonstração de produtos tem
sido elaboradas. Por exemplo, a Tissot, fabricante de relógios, criou em Londres uma vitrine virtual
(Figura 3 (b)).
São distribuídos marcadores em formato de relógio que são colocados no pulso. A imagem é gerada em um monitor sensível ao toque, que permite ainda mudar estilo, cor e tamanho da peça, além de
exibir algumas funcionalidades reais tais como horário e cronometro.
É possível também acessar o aplicativo via internet (http://www.tissot.ch/reality/). É disponibilizado um arquivo com o relógio marcador para ser impresso e posteriormente recortado.
A
intenção dessa ação da Tissot é tentar quebrar a imagem inacessível que algumas pessoas têm de seus
produtos e aproximá-los.
Assim como a solução da Ray Ban, o acesso via internet requer o download e instalação do aplicativo. Apesar de alguns inconvenientes de download (o arquivo da Tissot tem 82 Mbytes) e instalação
que possam acontecer, as soluções são relativamente baratas e tem bom alcance, uma vez que é grande
o número de pessoas que acessam internet e tem uma webcam instalada.
Para provar roupas a empresa Zugara (http://www.zugara.com) criou um provador virtual baseado em marcadores e captura de movimentos, denominado Webcam Social Shopper (Figura 5), já
utilizado por diversas lojas, como a Love Rococo®, do Reino Unido.
A experiência ocorre da seguinte maneira. O cliente o acessa, escolhe o produto que deseja e é
direcionado para a página do produto. Nela, estão disponíveis todas as informações sobre o produto e
há opções para a escolha de tamanhos e cores, além de um botão rotulado: “Tem uma webcam? Veja
como fica!”. Essa interface leva o cliente (usuário) ao uso da ferramenta. Clicando no referido botão, o
aplicativo se inicia automaticamente. A partir daí o cliente se posiciona em frente a webcam como mos-
49
tra a Figura 5, e faz toda a interação com as mãos, que envolve ajustes e escolha de cor, direcionando-as
aos botões presentes na interface.
Figura 5. Provador de Roupas Virtual
Fonte: Oliveira (2012)
Sem dúvidas, o mais explorado potencial da RA está na demonstração de produtos. Seja na aproximação de clientes, ou para aumentar a taxa de conversão em sites de comércio eletrônico, há diversos
aplicativos de várias e grandes Empresas.
5.2. Jogos e Outros
A RA também pode ser utilizada para tentar provocar aumento na venda de produtos. Campanhas
como da Nestlé, Doritos e de Nesquik o mais rápido possível e trabalhar o sistema virtual de transporte
Lego demonstram isso.
A Nestlé encomendou a Zugara um jogo de RA, denominado Nesquik Factory, onde o usuário
é instruído a encher as garrafas do produto. Para acessar o jogo, é necessário ter uma embalagem de
Nesquik.
O jogo está baseado na captura de movimentos com realidade aumentada. A solução desenvolvida
pela Zugara também é aplicada em outros jogos. Dessa forma, o usuário não precisa de nenhum marcador ou dispositivo especial. A interação é feita com as mãos.
Ainda relacionado a jogos, a fabricante brasileira de cadernos e agendas Foroni (www.foroni.com.
br), desenvolveu uma linha de cadernos com marcadores de RA, onde é possível simular uma volta de
carro, no computador, usando o caderno como volante.
A Pepsico (http://www.pepsico.com.br/), fabricante do salgadinho Doritos, também lançou uma
campanha utilizando RA. No verso de cada embalagem do sabor Sweet Chili há um símbolo de RA, que
50
ao ser ativado no site da marca libera um monstrinho em 3D chamado Doritos Lover. Os personagens
podem fazer parte do perfil do usuário no Orkut. Foram criadas mais de 200 mil combinações dos
monstrinhos.
Por fim, a USPS (United States Postal Services) disponibiliza um aplicativo de RA denominado
Virtual Box Simulator (https://www.prioritymail.com/simulator.asp) que permite ao usuário dimensionar e escolher a caixa apropriada para sua encomenda (Figura 6).
Figura 6. Screenshot Virtual Box Simulator
Fonte: Divulgação USPS (2011)
6. O Escopo do Processo de Desenvolvimento de Produtos
A disponibilização de um produto que atenda as necessidades de seus clientes é o objetivo principal de uma organização. Além disso, que o produto satisfaça as necessidades de um maior número de
clientes quanto for possível. Nesse contexto, o processo de desenvolvimento de produtos tem um papel
importante.
Segundo Thalen e van der Voort (2012), uso da RVA no processo de desenvolvimento de produtos
tem início na década de 90, como o uso de CAVE e capacetes tão somente para a visualização tridimensional dos produtos. Com a redução do preço dos dispositivos, a utilização da RVA passou a ter
também finalidade de simulação, treinamento, prototipação e avaliação.
Ainda de acordo com Thalen e van der Voort (2012), a RVA tem sido usada para permitir que produtos ou ambientes ainda não existentes possam ser experimentados de uma forma natural e realista.
Isto é vantajoso quando a situação real é muito perigosa, quando um ambiente tem de ser controlado,
ou quando a prototipagem física é muito caro ou simplesmente não é possível ainda.
51
Uma crítica feita por Thalen e van der Voort (2012), é que a maioria destas aplicações visa apoiar
a colaboração somente entre designers, em vez de, por exemplo, entre designers e usuários finais, o que
poderia representar maior valor ao cliente.
7. Exemplos de Utilização da RVA em Projeto e Desenvolvimento de Produtos
Nessa seção são apresentados alguns exemplos de utilização de RVA, focalizando casos de uso na
indústria automobilística e na aeronáutica para projeto e desenvolvimento de produtos. Estas indústrias foram as precursoras no uso da RVA nesta área, por isso, apesar de existirem outras vertentes,
serão abordados como exemplos. Outra vez, o objetivo não é esgotar todos os casos, mas apresentar
uma visão geral dos que serão principais para os autores.
7.1. RVA na Indústria Automobilística
Os centros de RVA na indústria automobilística possibilitam, dentre outros, a visualização de modelos de carros que ainda não possuem protótipos físicos. Além disso, permitem que uma pessoa seja
capaz de sentir-se imersa em um ambiente que simula um carro real, considerando seu espaço interno
e também o externo.
Do ponto de vista de negócios, testes como estes são válidos para redução do tempo de elaboração
do automóvel, para minimizar os erros de produção e para diminuição dos custos, uma vez que ajudam
a atingir um nível mais elevado de eficiência. No que se refere à redução do tempo de elaboração do
carro, com um centro de RVA, não há necessidade da criação de protótipos físicos fiéis ao tamanho,
para posterior análise e muito prováveis alterações de sua configuração, tudo pode ser visto e analisado
em 3D com dispositivos especiais como óculos, sensores, luvas, capacetes, entre outros.
Sobre minimizar os erros de produção é possível constatar o setor que mais necessita desse
artifício continua sendo o de veículos, apesar de haver uma diminuição do número de recalls no Brasil
no ano de 2012 em relação a 2011 (Martins, 2013), dados estes que possibilitam a reflexão sobre o modo
como a RVA poderia intervir no sentido de preparar melhor todas as equipes de desenvolvimento dos
automóveis, o que acarretaria em uma diminuição destes números. E também é importante ressaltar a
redução dos custos já que se diminui a necessidade de construção de protótipos físicos, exceto aqueles
necessários para crash test, previstos por lei.
Além disso, a tecnologia de RVA pode ser utilizada para treinamento de mecânicos para
atividades de manutenção e associada a ações de marketing, como por exemplo, os simuladores de
direção que possibilitam test drive ou ensinam, por meio de um jogo, a manter uma boa relação entre
quilometragem rodada e combustível consumido (Godirro, 2013).
52
Figura 8. Centro de Realidade Virtual Volkswagen
Fonte: Divulgação Absolut Technologies
Em 2008 o grupo Volkswagen investiu cerca de 4,2 milhões de reais em um centro de RVA, atualmente situado na montadora de São Bernardo do Campo. Projetado e implantado pela Absolut Technologies (http://www.abs-tech.com/), o centro é constituído por um estúdio virtual com conexão em
tempo real com as outras unidades Volkswagen ao redor do mundo, o que acelera ainda mais o processo de desenvolvimento de um automóvel; é também constituído por uma tela chamada Powerwall,
de aproximadamente cinco metros de comprimento e dois de altura, que possibilita aos engenheiros a
visualização do projeto de automóvel em 3D (Figura 8).
A tecnologia Virttex (Virtual Test Track Experiment) é empregada em uma máquina construída
para fábrica de automóveis Ford. Trata-se de um domo suficientemente grande para que caiba um
carro dentro, e que possui um complexo sistema hidráulico acoplado que simula os movimentos que o
carro faz quando está em movimento (Figura 9). Este domo é utilizado para projetar imagens de alta
resolução (45 megapixels) em 360 graus, e com um banco de imagens, parecer um cenário real externo
ao carro, obedecendo a comandos como aceleração, frenagem e direção. Seu custo varia em torno US$
7 milhões, valor aproximadamente vinte e três vezes mais alto em relação ao único aparelho similar
existente nos Estados Unidos (Godirro, 2013).
O aparelho tem como finalidade ajudar a descobrir potenciais pontos fracos da segurança do
automóvel e para isso permite a realização de vários testes que simulam a realidade do motorista, com
situações de distração, sonolência, motoristas com idade avançada e até mesmo inexperientes. Tais testes tem a finalidade de analisar o tempo de reação dos condutores em geral, para que consigam desenvolver algum tipo de dispositivo que seja capaz de alertar o motorista do mais discreto possível, para
obterem os resultados do tempo de reação e as atitudes do motorista, são utilizadas câmeras e sensores.
53
Figura 9. Virttex Ford
Fonte: Divulgação Ford
Uma das tecnologias desenvolvidas pro meio do Virttex é, por exemplo, uma que mede a variação
de movimento do eixo do carro, com objetivo de ver ser ele não está “costurando” na pista, atitude
característica do condutor que está prestes a cochilar; outra tecnologia seria uma que acompanha o
movimento da retina do motorista, o que possibilita cálculos sobre o tempo de reação do mesmo (Godirro, 2013).
Analisando sob o ponto de vista do Marketing da empresa, é possível perceber que a tecnologia
trabalhar a favor da construção de uma imagem positiva da marca, já que carros seguros são bem vistos
no mercado, o que potencializa o crescimento das vendas; mas mais do que isso, trabalha a imagem da
Ford como empresa modelo em segurança.
Do ponto de vista tecnológico, o Virttex demonstra uma grande desvantagem, já que os carros que
entram no domo são reais, o que obriga a empresa a continuar desenvolvendo seus protótipos antes
de analisar a sua segurança, ou existe ainda a opção de utilizar modelos antigos no teste do Virttex,
porém ainda não é o ideal. Uma vantagem é que mesmo existindo essa impossibilidade de o carro ser
projetado ao todo, há a possibilidade de trocar de carro, possibilitando o desenvolvimento de vários
modelos, assim como foi feito com os novos modelos EcoSport, Ranger e Fusion.
A empresa Fiat, visando investir em inovação a fim de melhorar os custos, o tempo de produção e
a qualidade dos projetos, que antes dependiam de protótipos para que fossem analisados, investiu em
2003 R$400 milhões na criação do polo de desenvolvimento de produtos Giovanni Agnelli que reúne
diversas áreas como engenharia de projeto e engenharia experimental.
O local é considerado o mais completo centro de desenvolvimento da empresa fora da Itália, com
laboratórios e recursos de última geração, capazes de simulações e testes dinâmicos em escala real.
Com o objetivo de aperfeiçoar a estrutura do polo, foi inaugurada, em março de 2009, uma moderna sala de Realidade Virtual, denominada Fiat Latin America Style Center, (Figura 10) que além
54
de ajudar na melhoria do processo de design dos modelos de carros da empresa, também serve para
conectar as diversas áreas do centro de desenvolvimento.
Também projetada e implementada pela empresa Absolut Technologies, a sala possui uma tela
com resolução (4.096 x 2.160 pixels) que permite a visualização dos carros em tamanho real. É possível
que também se tenha a perfeita visão de detalhes que passa desde a textura dos tecidos, até o brilho
da pintura do carro. O Fiat Latin America Style Center comporta até 36 pessoas e também possui uma
mesa com microfones e câmeras para videoconferências e iluminação 100% automática, para que diferentes cenários possam ser criados.
Figura 10. Fiat Latin America Center
Fonte: Divulgação Absolut Technologies
Por meio da RVA, problemas podem ser diagnosticados antes de o modelo entrar em produção, e
assim melhorar de maneira significativa a qualidade do produto.
Na tentativa de aproximar designers e usuários, a Fiat realizou a campanha Concept Car (http://
www.fiatmio.cc/), onde era o possível o usuário interagir na concepção do projeto e desenvolvimento
de um veículo. A partir das intenções colhidas dos usuários, em uma das fases foi gerado um modelo
com Realidade Virtual. (Fiat; 2010)
7.2. RVA na Indústria Aeronáutica
O centro de Realidade Virtual da Embraer (Empresa Brasileira de Aeronáutica) entrou em operação em fevereiro do ano 2000 e teve um investimento de US$ 2 milhões e 600 mil, sendo na época, o
maior e o mais desenvolvido da América Latina. Com os objetivos de sobrevivência perante a concorrência e ganhar o mercado internacional, projetistas, técnicos, engenheiros e funcionários têm à sua
disposição, um moderno centro de tecnologia que tornou possível a redução do prazo e dos custos de
desenvolvimento do projeto de uma aeronave.
55
Esse sistema possibilita não somente a visão da imagem do projeto do avião em 3D, mas também
permite a imersão total, onde é possível a interação das pessoas com o mesmo, como se estivessem em
um ambiente real. Utilizando de dispositivos multissensoriais é possível conhecer literalmente o interior da aeronave, possibilitando aos engenheiros e operários a checagem da colocação de peças, espaço
de trabalho no avião, e várias outras ações que só seriam possíveis de se realizar através de protótipos
(Figura 11).
Na imersão total, tudo o que o usuário faz, é repetido por um avatar (duplo virtual) em tempo
real. Para que isso aconteça, é necessário a utilização de capacete, óculos, luvas e um macacão especiais
que possuem sensores para a captação de qualquer movimento feito pelo operador, seis câmeras são
responsáveis por essa captação. O capacete serve para colocar o usuário dentro da realidade virtual
criada no computador fazendo com que ele perca o contato com o ambiente exterior. (Esteves, 2000).
Figura 11. Centro de Realidade Virtual - Embraer
Fonte: Divulgação Embraer
Com a implantação do CRV o tempo para que um projeto ficasse pronto, caiu quase pela metade
e os níveis de risco também diminuíram, pois, proporcionou um melhor treinamento ao pessoal da
montagem, e aos pilotos, que antes dependiam de um protótipo de madeira para testar o acesso aos
comandos. Além disso, a tecnologia também pode ser usada no marketing e vendas, porque com ela, o
cliente tem como “entrar e explorar virtualmente” a aeronave mesmo que esta ainda esteja em processo
de montagem, podendo até personalizar seu avião.
56
8. Considerações Finais
Este Capítulo abordou o uso da RVA em ações de Marketing e também no projeto e desenvolvimento de produtos. Dentro de uma organização, o Marketing tem um importante papel e a utilização
da RVA como uma peça associada a uma determinada ação de Marketing pode contribuir de forma auxiliar tanto na criação, quanto na comunicação e também como uma forma de agregar valor ao cliente.
Com a mesma importância, o projeto e desenvolvimento de produtos é fundamental para que a
Organização possa disponibilizar a seus clientes, produtos que realmente satisfaçam suas necessidades
e lhes agregue valor.
A intenção desse trabalho não foi esgotar o assunto ou mesmo explorar todas as possibilidades
de uso da RVA dentro do escopo abordado. Foi estabelecer perspectivas reais de utilização para que
discussões possam ser iniciadas e novas ações possam ser derivadas dos casos apresentados.
É interessante destacar que a RA tem se apresentado como preferência de uso nas ações de marketing. O que se observar é da menor demanda em termos de requisitos de equipamentos para a
utilização da RA face a RV. Com uma câmera e acesso a internet, cada vez mais comuns para as pessoas atualmente, é possível criar uma peça com RA. O público atingido é obviamente maior quando
se compara a RV que necessita de equipamentos especiais (óculos estereoscópicos e computador com
placa gráfica, por exemplo).
A facilidade de interação proporcionada pela RA, que não requer nenhum dispositivo especial,
bem como algumas vezes utiliza o próprio corpo, é também um dos pontos fortes. Com a RV o uso
de dispositivos se faz necessário em diversas vezes. O que se observa é uma tendência de uso cada vez
maior da RA como peça das ações de Marketing.
No que se refere ao uso da RVA no projeto e desenvolvimento de produtos, percebe-se pelos casos
apresentados que a redução do tempo de projeto, a diminuição de custos e a melhoria da qualidade
são objetivos principais em um ambiente extremamente concorrido, como por exemplo, da indústria
automobilística. Em termos de negócio, o investimento em RVA pode trazer retornos tangíveis (custos)
e intangíveis (relacionamento com clientes, imagem de marca).
Como a finalidade é diferente, o projeto e desenvolvimento de produtos requer maiores investimentos por parte das Organizações, com a necessidade de uma infraestrutura de RVA mais personalizada as necessidades e objetivos de cada uma.
Por fim, percebe-se o uso cada vez mais frequente de tecnologia de RVA em diversos setores da
sociedade. Isso é muito benéfico para a Comunidade de RVA que pode cada vez mais buscar recursos
para aplicação de suas pesquisas e desenvolvimento de seus produtos. Por outro lado, as Organizações
têm ao seu alcance uma tecnologia atual, com potencial de retenção de atenção muito grande e com
capacidade de agregar valor as suas atividades.
57
Referências
BATEMAN, T. S.; SNELL, S. A. (1998). “Administração: construindo vantagem competitiva”. Editora Atlas.
ISBN 85-224-1923-X.
BURDEA, G.; COIFFET, P. (1994). “Virtual Reality Technology”. John Wiley & Sons, New York, N.Y.
DASSAULT SYSTÈMES (2011). Disponível em <http://minimoys.3ds.com/press/3DVIA-Nestle.html>.
Acesso Abril 2011.
DINIZ, A. G.; SANTOS, F. C.; COSTA, R. M. E. M. (2004). “Um Ambiente Virtual para a Simulação de
Processos de Negócios”. Memórias del IX Taller Internacional de Software Educativo. Santiago: Universidad
de Chile, 2004. p. 13-18.
ESTEVES, B. (2000). “Imersão Total: Realidade Virtual – Embraer.” Revista Superinteressante. Disponível
em <http://super.abril.com.br/tecnologia/imersao-total-441357.shtml>. Acesso em março de 2013.
FIAT. (2010). “Making Of Projeto Fiat Mio - Episódio 8 -- Realidade Virtual.” Disponível em <http://www.
youtube.com/watch?v=JjL_88POD-0>. Acesso em março 2013.
GODIRRO, A. (2013). “Cobertura do NAIAS 2013 (Salão do Automóvel de Detroit). Disponível em <
http://www.clubedohardware.com.br/artigos/Cobertura-do-NAIAS-2013-Salao-do-Automovel-deDetroit/2764/1>. Acesso em março de 2013.
HALL, R. (1984). “Organizações: estruturas e processos”. 3 ed. Rio de Janeiro: Prentice Hall do Brasil.
Kotler, P. e Keller, K. L. (2006) “Administração de Marketing”, 12 ed., Pearson Prentice Hall.
LAUDON, K. C; LAUDON, J. P.; (2010). “Sistemas de Informação Gerenciais.” Prentice Hall. 9a. Edição.
Pearson. ISBN: 978857605923-3.
MARTINS, D. (2013). “Setor de veículos lidero número de recalls em 2012.” Jornal Valor Econômico,
Brasília, 21 Jan. 2013. Disponível em: <http://www.valor.com.br/empresas/2978282/setor-de-veiculoslidera-numero-de-recalls-em-2012>. Acesso em: 17 Mar. 2013.
MILGRAN, P.; TAKEMURA, H.; UTSUMI A.; KISHINO, F; (1994) “Augmented Reality: A Class of
Displays on the Reality-Virtuality Continuum”, Telemanipulator and Telepresence Technologies, Vol.
2351, p. 282-292.
OLIVEIRA. T. S. S. (2012). “Uma avaliação do uso Realidade Aumentada em websites de Comércio
Eletrônico sob o ponto de vista do usuário”. Monografia de Conclusão de Curso. FEARP-USP.
PINHO, M.S.; KIRNER, C., (1997) “Uma Introdução à Realidade Virtual.” In: X Simpósio Brasileiro de
Computação Gráfica e Processamento de Imagens, SIBGRAPI’97: Minicurso.
RAY BAN (2011). “The Ray Ban Virtual Mirror”. Disponível em < http://www.ray-ban.com/usa/science/
virtual-mirror>. Acesso em março 2011.
58
REALIDADE AUMENTADA. Jornal da Globo. Rio de Janeiro, Globo, 11 de junho de 2009. Programa de TV.
REVISTA EXAME. (2010). “Itaú Seguros veicula campanha em 3D”. Disponível em <http://exame.abril.
com.br/Marketing/noticias/itau-seguros-aposta-3d-549914>. Acesso em março 2011.
RYAN, C. (2001). “Virtual Reality In Marketing”. Disponível em: http://www.allbusiness.com/technology/
internet-technology/788154-1.html. Acesso em março de 2011.
THALEN, J.; VAN DER VOORT, M. (2012). ”The Virtual Printshop: A case study on using Virtual Reality
in early stages of user-centered product design.” SBC Journal on 3D Interactive Systems, volume 3, number
3.
TORI, R.; KIRNER, C. (2006). “Fundamentos de Realidade Virtual.” In: VIII Simpósio de Realidade Virtual,
Livro do Pré-Simpósio: Fundamentos e Tecnologia de Realidade Virtual e Aumentada, ISBN 857669068-3.
USPS (2011). “Virtual Box Simulator”. Disponível em <https://www.prioritymail.com/simulator.asp>.
Acesso em Abril 2011.
ZHAO, Q. (2009). “A Survey on Virtual Reality”. Science in China Series F: Information Sciences. Science
China Press, co-published with Springer. V52(3). pp. 348-400.
ZUGARA (2011). “Augmented Reality Software.” Disponível em < http://www.zugara.com/augmentedreality/software>. Acesso em março de 2011.
59
60
SANTOS JÚNIOR, Gesmar de Paula, et al. Realidade Aumentada Móvel
Realidade Aumentada Móvel
Gesmar de Paula Santos Júnior
Luciene Chagas de Oliveira
Alexandre Cardoso
Edgard Lamounier Júnior
Marcos Wagner de Souza Ribeiro
Thamer Horbylon Nascimento
Abstract
This chapter presents a theoretical approach to the Mobile Augmented Reality (AR Mobile) and some
possibilities of using mobile AR through example applications. Furthermore, important concepts, justifications, challenges and key technologies for use in mobile AR are discussed by the authors.
Resumo
Este capítulo apresenta uma abordagem teórica sobre a Realidade Aumentada Móvel (RA Móvel) e algumas possibilidades de utilizando da RA Móvel, através de exemplos de aplicações. Além disso, conceitos
importantes, justificativas, desafios e as principais tecnologias para uso de RA Móvel são discutidos pelos
autores.
1. Introdução
A Realidade Aumentada (RA) tornou-se um tema popular no campo da pesquisa acadêmica, porque permite ao usuário uma visão de objetos virtuais sobrepostos ou compostos com o mundo real
(CHAN & TAN, 2010). Os ambientes do mundo real de sistemas de RA são obviamente limitados pelas
leis da Física, que, necessariamente, impõe certas restrições à nossa capacidade de interagir com os
mesmos. Ferramentas de Realidade Aumentada são projetadas para facilitar tais interações, mediadas
por dispositivos móveis, tais como tablets e smartphones.
A Realidade Aumentada Móvel (RA Móvel) é uma das áreas de pesquisa que mais crescem na
RA, parcialmente devido ao surgimento de telefones inteligentes que proporcionam uma plataforma
poderosa e onipresente para apoiar a RA Móvel (AZUMA et al., 2011). Neste contexto, esta capítulo
objetiva alguns desafios da construção de soluções aplicações para dispositivos móveis com o uso de
Realidade Aumentada (RA).
60
Para atingir este objetivo, especificamente seguiu-se o roteiro: apresentam-se as principais referências a Realidade Aumentada Móvel e uma análise avaliação das tecnologias existentes Realidade Aumentada móvel é realizada. A seguir, demonstra-se a aplicabilidade da RA móvel, com uso de
exemplos de aplicação, distinguindo elementos relevantes do processo de desenvolvimento e, por fim,
distinguem-se os mecanismos para aprimorar a aplicação, com uso dos diferentes recursos disponíveis
nos dispositivos móveis, tais como acelerômetros, bússolas etc.
2. Justificativas para o Uso da Realidade Aumentada Móvel
O mercado de celulares está crescendo cada vez mais e estudos mostram que hoje em dia mais de 3
bilhões de pessoas possuem um aparelho celular, e isso corresponde a mais ou menos metade da população mundial (LECHETA, 2010). Os usuários estão procurando celulares e smartphones que possuem
diversos recursos, tais como câmeras, bluetooth, jogos, ótima interface visual, GPS, acesso a internet e
e-mails, entre outras aplicações. Sendo assim, a mobilidade está cada vez mais conhecida e utilizada,
na qual surge a necessidade de mais aplicações que executem em celulares e smartphones e sincronizem
informações das organizações.
Os dispositivos móveis podem ser ferramentas auxiliares à criação de experiências de aprendizagem e, associados a RA, tornarem-se estratégias de desenvolvimento em outras áreas, tais como jogos
e visualização da informação.
Os principais benefícios do uso de dispositivos móveis para a RA incluem: a portabilidade, a mobilidade: estar disponível a qualquer hora e em qualquer lugar, acesso, de forma flexível, a diversos recursos e em tempo real, economia de tempo, rapidez da comunicação, capacitação e envolvimento dos
alunos e o fato da aprendizagem móvel (mobile learning) ser abrangente e dinâmica (WOODILL, 2010).
De acordo com um relatório da ONU, seis em cada dez pessoas no mundo têm assinatura de telefonia móvel, o que significa que os celulares representam a comunicação tecnológica escolhida nos
últimos anos, especialmente nos países mais pobres (WOODILL, 2010).
Alguns fatores de mercado contribuem para efetivação de aplicativos e softwares com a RA, como
a diminuição do custo dos equipamentos que possui tecnologias adequadas para o desenvolvimento e
utilização desses aplicativos, se tornam cada vez mais acessíveis nas diversas classes sociais.
A
amplitude em que a RA vem atuando se tornar imprescindível e coerente para várias soluções contribuindo para o desenvolvimento social e tecnológico.
No desenvolvimento de aplicações utilizando a Realidade Aumentada Móvel (RAM) para acessar
ou armazenar informações devem ser considerados os componentes propostos na Figura 1. Dispositivos, tais como smartphones e tablets, são executados em uma infra-estrutura de rede e rodam em
plataformas, por exemplo, no Android ou no iOS. Nas plataformas são instaladas as ferramentas, as
tecnologias e as bibliotecas que permitem que as aplicações acessem as fontes de informações (CARDOSO et al, 2012).
61
Figura. 1. Componentes para Aplicações da Realidade Aumentada Móvel (CARDOSO et al, 2012)
O conteúdo inclui informações de contexto que são aplicações em diversas áreas, tais como Educação, Medicina, Jogos, Engenharia, entre outros, e os conceitos são as técnicas e formas que são usadas
para acessá-los, tais como a Realidade Aumentada e a Visualização de Informação.
2. Desafios da Realidade Aumentada Móvel
Alguns desafios que devem ser considerados para a RAM são: o tamanho da tela, o consumo de
energia, precisão de localização, câmera de qualidade, processamento e memória, registro, segurança,
tempo real, a dependência, o desempenho, cobertura, grande quantidade de dados, dinamicidade, interação, conteúdo.
Estes desafios são mostrados na Figura 2, que classifica cinco categorias: hardware, aplicação,
rede, meio ambiente e utilizador.
62
Figura. 2. Desafios da Realidade Aumentada Móvel
Primeiramente, no desenvolvimento de uma aplicação móvel é necessário identificar quais são os
recursos de hardware disponíveis em todos os dispositivos que se deseja atingir com a aplicação, como
câmera e teclado, que estão presentes na maioria dos dispositivos existentes atualmente.
No entanto, para os outros tipos de sensores, não se pode garantir que todos devem funcionar
ou existir em todo dispositivo móvel. Devido a isso, é importante identificar o modelo de resposta
dos sensores desenvolvidos e como eles serão utilizados no software, viabilizando o uso da aplicação
mesmo com recursos limitados. Caso uma aplicação utilize um sensor que se encontra na maioria
dos dispositivos, como bússola, giroscópio e GPS, existem algumas particularidades, por exemplo, a
precisão do GPS não é alta em ambientes indoor e alguns possuem câmera de baixa qualidade. Deve-se tratar e apresentar a aplicação também nesses dispositivos de baixa performance, mesmo que seja
de forma degradada ou apresentando uma precisão inferior, evitando que o usuário execute a aplicação
sem travamento ou que a aplicação fique aguardando a resposta a esses sensores.
A tela também pode dificultar o uso da aplicação, para evitar complicações, deve-se trabalhar com
layouts dinâmicos, diminuindo ícones, ocultando menus, trabalhando com diferentes configurações
de tela, mantendo a aplicação funcionando em telas de menor tamanho e resolução.
63
Para dispositivos móveis, o hardware nem sempre apresenta alta duração de bateria, grande capacidade de processamento e memória, o que pode causar baixo desempenho, limitando as funcionalidades e, em segundo momento, a utilização adequado de um dispositivo móvel .
Outro desafio se refere ao registro da aplicação, ou seja, se haverá controle de usuário, trazendo
maior segurança com a devida autenticação da aplicação, quando disponível uma conexão de rede
local ou Internet. Essas necessidades devem ser avaliadas, de acordo com a disponibilidade da infraestrutura de servidores, arquitetura de hardware e software.
Um grande desafio é a questão de rede relacionado a velocidade de tráfego, área de cobertura das
empresas de telefonia e o quanto uma dada aplicação é dependente dessa rede. Para RA indoor, esse
problema pode ser minimizado, utilizando-se uma rede wireless. Porém, para ambientes outdoor tem-se uma dependência das redes de telefonia.
O quarto desafio refere-se ao ambiente, que, atualmente, possui uma grande quantidade de dados.
Quesitos como a dinamicidade e flexibilidade de atualização, além do provimento de dados, em tempo
real, tornam-se demandas de solução, nem sempre trivialmente solucionadas.
O quinto desafio apresentado na Figura 2 refere-se ao usuário em si. O perfil do usuário pode
exigir a disponibilização de elementos de auxílio (help), além da necessidade de aprendizado das diferentes formas de interação com a solução de RA no dispositivo e a busca de novas informações. Outro
quesito relevante refere-se à poluição visual que pode acontecer, por sobreposição de grande conjunto
de informações visuais, por exemplo, sobre um elemento (ou posição) da cena real.
Todas essas questões acarretam em tempo e custo no projeto de desenvolvimento e devem ser
analisadas e inseridas no projeto em fase de planejamento do software.
3. Exemplos do Uso da RA Móvel
A quantidade de pesquisas e experiências de utilização da RA com dispositivos móveis ainda é
recente, mas tende a crescer, em função dos avanços da tecnologia e dos benefícios que essa tecnologia
oferece.
3.1 Geolocalização em RA
Atualmente, a maioria dos aplicativos móveis para RA são desenvolvidos em uma única plataforma ou são criadas versões para cada plataforma. O framework PhoneGap (2013), apresentado neste
trabalho, proporciona a criação de aplicações móveis multiplataforma, tais como, o Windows Phone,
o Android e o iOS.
O trabalho de Santos (2012) utiliza a localização geográfica como elemento de RA, o aplicativo
será executado em espaço aberto, ao ar livre.
O objetivo da aplicação é apresentar a geolocalização
dentro de uma área determinada. Esta aplicação utiliza a tecnologia Realidade Aumentada acrescentando ao mundo real, visualizado através da câmera do dispositivo, a informação virtual através de
uma seta indicando a direção para localizar o destino em relação ao ponto onde o usuário está.
64
Na tela inicial da aplicação são apresentados os botões para ativar o GPS e a bússola, ativá-los, será
exibida uma tela de visualização da seta direcional. O usuário deverá, então utilizar a seta para se guiar
em direção ao ponto de destino. De acordo com a movimentação do usuário a direção e a distância é
alterada em relação ao destino, conforme Figura 3.
Figura. 3. Tela inicial da aplicação, mostrando os botões de ativar o GPS e Bússola, Informações de distância , do GPS e seta apontando para destino atualizadas em tempo real
3.2 Navegação Indoor
Os dispositivos móveis são ferramentas que auxiliam na criação de experiências de aprendizagem
e associados a RA tornam-se uma poderosa ferramenta para desenvolvimento de aplicações em diversas áreas, tais como educação e jogos.
Os benefícios técnicos para a Realidade Aumentada Móvel (RA Móvel) estão se tornando robusto
o suficiente para permitir o desenvolvimento de serviços RA Móvel que são verdadeiramente valiosos
para os consumidores. Para garantir a aceitação e sucesso de futuros serviços da RA Móvel, seu desenvolvimento deve basear-se em saber sobre as expectativas do usuário final em potencial e necessidades.
O trabalho de Olsson (2012) conduz entrevistas semi-estruturadas em centros comerciais, que podem
ser considerados como um contexto fértil para serviços da RA Móvel para provocar novos conheci-
65
mentos sobre as características da experiência do usuário e os requisitos do usuário relacionados ao
RA Móvel.
Outros trabalhos de Oliveira (2012), ilustrados nas Figuras 4 e 5, apresentam exemplos de aplicações para localização em ambientes internos com o uso da RA Móvel, onde o primeiro mostra a
localização de um produto por meio de setas e apresenta informações detalhadas dos produtos de um
supermercado, e o segundo apresenta o desenvolvimento de uma aplicação genérica e configurável
para um ambiente interno que mostra a localização de um objeto ou um lugar por meio de setas e
apresenta informações dos objetos e lugares que estão armazenadas nas nuvens.
Figura. 4. Aplicação da RA Móvel para Visualização de Informações Localização de Produtos em um
Estabelecimento Comercial
66
Figura. 5. Aplicação Genérica da RA Móvel para Localização de Objetos em Ambientes Internos
3.3 Reconhecimento de Toques e Gestos
O trabalho de Braga (2012) aborda as práticas atuais de mobile-learning e apresenta uma estratégia
de desenvolvimento de aplicações educacionais, com uso de dispositivos móveis associados a Ambientes Virtuais e Realidade Aumentada. São adaptadas técnicas de reconhecimento de padrões de gestos e
toques, gerando ambientes de Realidade Aumentada como suporte ao ensino. Como prova de conceito,
implementou-se o aplicativo mostrado na Figura 6, que permite a concepção de experiências de Física
(Mecânica Clássica) através do dispositivo móvel.
Figura. 6. Aplicativo de concepção de experiências de Física através do dispositivo móvel
67
Como mencionado anteriormente, existem desafios para desenvolvimento de uma aplicação de RA
móvel referentes a eficácia do reconhecimento de padrões gestuais, que não envolve apenas a boa aquisição das coordenadas de cada trecho do caminho percorrido, mas também dos seguintes parâmetros de
tempo de aquisição, número de pontos coletados e tipo de resposta esperada. Para a coleta dos dados
de forma correta referente aos gestos, foi levado em consideração as características físicas do dispositivo
móvel, como o tamanho, resolução da tela e o tipo de display adotado (resistivo ou capacitivo).
Com a finalidade de garantir a coerência dos resultados, foi criado um dicionário de gestos utilizando a mesma metodologia de captura de dados para comparação.
Figura. 6. Telas do Imagine 3D
A fim de manter o procedimento o mais intuitivo possível, optou-se por criar um ambiente de desenho comum, como os editores conhecidos, de tal forma que, usando toques com um dedo, o usuário
cria suas formas simulando o uso de um lápis sobre o papel.
68
3.4 Detecção de Marcadores Naturais para RA Móvel
Um problema já conhecido é referente a detecção de marcadores naturais, que são imagens do
mundo real. Silva (2012) utiliza Redes Neurais Artificiais para registro e reconhecimento desses marcadores para aplicações da RA. Além disso, foi desenvolvida uma aplicação de estudo de caso utilizando RA móvel para demonstrar a utilização de um algoritmo de redes neurais para detecção de
marcadores naturais, considerando também a oclusão parcial e a presença de ruídos nos marcadores.
Foram realizados diversos testes com marcadores naturais apresentando alguns tipos de ruídos e oclusão parcial dos marcadores, conforme mostra a Figura 8.
Figura. 8. Reconhecimento de Marcadores Naturais para RA Móvel
69
4. Tecnologias Existentes
Esta seção apresenta os trabalhos relacionados aos softwares de Realidade Aumentada em dispositivos móveis, com o objetivo de analisar suas potencialidades, aplicações e contribuições.
Atualmente há uma infinidade de aplicações e trabalhos científicos relacionados com interações
metodologias para ambientes de Realidade Aumentada (ZHOU, DUH and BILLINGHURST, 2008).
Essas tecnologias permitem o desenvolvimento rápido de uma vasta gama de aplicações de Realidade Aumentada Móvel. Os critérios levados em consideração para análise estão relacionados à usabilidade do mesmo, à tecnologia utilizada para implementação, às tecnologias de suporte necessárias e
bibliotecas utilizadas. Foram definidos como critérios:
• Tecnologia aplicada?
• Ambiente de execução?
• Tecnologia de suporte utilizada?
• Distribuída ou autônoma?
O projeto AndAR - Android Augmented Reality (2011) consiste em uma biblioteca de software
escrito em Java que implementa Realidade Aumentada com o ARToolkit para a plataforma Android.
Este projeto usa marcadores de RA para projetar objetos virtuais na imagem capturada do mundo real.
Uma tecnologia que suporta a portabilidade do ARToolKit para o Adobe Flash®, trazendo assim
Realidade Aumentada para navegadores e dispositivos com suporte a Flash®. Esta tecnologia é conhecida como FLARToolKit, onde todos os princípios de funcionamento do ARToolKit foram preservados.
Outra biblioteca que usa marcadores de Realidade Aumentada é NyARTollkit, também desenvolvido utilizando a linguagem de programação Java, mas também com versões em C # e Android. É uma
versão estendida do código ARToolKit a visão que adiciona recursos, mas quebra a compatibilidade
devido a uma nova classe baseada em API.
NyARToolkitCS fundamenta-se no ARToolKit, tendo sido construído na linguagem C#. É derivado
do Nyartoolkit para Java. NyARToolkitCS é de uso livre para aplicações não comerciais, necessita do
.Net Framework instalado onde o aplicativo de RA for executado. Caso seja em computadores, Net
Framework 2.0 e .NET Compact Framework 3.5 para o uso de dispositivos móveis.
O QCAR SDK (2013), que possui comercialmente o nome de Vuforia, é um framework de RA
Android, iOS e Unity 3D desenvolvido pela empresa americana de telecomunicações Qualcomm, representa uma solução avançada e com ótimos recursos para o desenvolvimento de aplicações destinadas
a Realidade Aumentada para dispositivos móveis. O QCAR não se limita a reconhecer marcadores
bidimensionais, ele implementa uma classe mais geral (chamada Trackable) de elementos identificáveis
e rastreáveis na imagem obtida pela câmera do dispositivo, permitindo o reconhecimento de multimarcadores e detecção de objetos tridimensionais. Além disso, também permite o uso de recursos de
computação em nuvem.
Outro framework que merece atenção é o ElipseAR, que diferente dos marcadores ARToolKit padrão, permite grande vantagem no rastreamento e reconhecimento de imagens coloridas.
Alguns destes frameworks, foram inicialmente concebido para ambientes desktop, como o ARToolKit, mas já possuem implementações para plataformas móveis, mas há opções que auxiliam o desen70
volvimento de aplicações de RA em dispositivos móveis, com recursos dos smartphones: informações
de geolocalização, modelos tridimensionais, com imagens sobrepostas ou animações para a visão da
câmera, permitindo ao usuário perceber uma experiência nova e revolucionária da RA em substituição
dos marcadores tradicionais usados nas implementações usuais, normalmente para desktops.
Para a produção de sistemas de RA Móvel é possível utilizar também frameworks mais voltados
para o desenvolvimento tradicional, iremos utilizar para os exemplos deste capítulo o PhoneGap, uma
robusta biblioteca multi-plataforma que facilita o processo de desenvolvimento entre os vários dispositivos.
A Tabela 1.1 contém um comparativo entre as diferentes tecnologias mencionadas anteriormente:
Tabela 1.1. Tabela de comparação de algumas das tecnologias de Realidade Aumentada.
Tecnologia
Ambiente de execução
Tecnologia de suporte
ARToolKit
AndAR
NyARToolkit
NyARToolkitCS
ElipseAR
FlarToolKit
Vufória
PhoneGap
Symbian OS
Android
Java
Windows
iOS, Android
Flash
iOS, Android e Unity 3D
Multiplataforma
OpenGL
Java
OpenGL
DirectX
Java
ActioScript
OpenGL
HTML5, Javascript e CSS
Outras ferramentas existentes são Unifeye Design (Unifeye, 2011) , D’Fusion SDK (DFUSION,2011) ,
ARToolKit NFT (ARTOOLWORKS,2011) , IN2AR (IN2AR, 2011) e FLARE*NFT (FLARE*NFT,2011).
5. Outros dispositivos de Hardware
O acesso a sensores dentro dos dispositivos móveis através das aplicações estão disponíveis em
várias plataformas e construídas sobre padrões específicos para cada sistema operacional, podendo
também, em sua maioria, serem acessados por navegadores, com isso o aplicativo pode ter uma maior
riqueza de sensores e de detalhes. Através de frameworks, como por exemplo o PhoneGap (2013), uma
aplicação pode ser portável para diferentes plataformas de dispositivos com o mínimo de alterações,
ele possui uma API em JavaScript, que permite o acesso a sensores de diferentes dispositivos através de
um código único e ele se encarrega de entender qual plataforma está sendo utilizada. Este framework
está disponível para as seguintes plataformas: iOS, Android, Blackberry, Windows Phone, Palm WebOS,
Bada e Symbian.
Essa e outras plataformas e APIs foram criadas para acessar as funcionalidades que são comuns
em diferentes smartphones. Algumas destas funcionalidades incluem eventos, armazenamento, mídia e
sensores. A Figura 9 mostra eventos, funções e sensores que estão disponíveis nos dispositivos móveis.
71
Figura. 9. Eventos, funções e sensores disponíveis nos dispositivos móveis
Para aprimorar a aplicação de RA Móvel, aumentar a precisão e também trazer mais informações
ao usuário, podem ser utilizados outros sensores do dispositivo móvel, como giroscópio, acelerômetro
e sensor de luminosidade, a necessidade e o uso desses recursos depende da necessidade do ambiente
de Realidade Aumentada.
Conclui-se que a Realidade Aumentada Móvel está cada vez mais presente na vida das pessoas
e é uma tecnologia capaz de contribuir no desenvolvimento de diversas aplicações em várias áreas,
tais como, navegação indoor, geolocalização, jogos, aprendizagem móvel, Educação, Medicina, entre
outros.
Pesquisadores estão trabalhando para criar aplicações de Realidade Aumentada Móvel de fácil
utilização, com suporte a toque e gestos, com precisão. A qualidade de dispositivos móveis evolui
rapidamente associada à redução de tamanho e peso dos mesmos. Assim, como as novas tecnologias
móveis estão cada vez mais inseridas no mercado, o uso de RA Móvel não será, no futuro, uma exceção.
72
Referências
ARToolWorks. Artoolkit NFT. Disponível em:<http://www.artoolworks.com/ products/stand-alone/
artoolkit-nft>. Acesso em: 07 de agosto de 2011.
AZUMA, R.; BILLINGHURST M.; KLINKER. G. (2011). “Editorial: Special Section on Mobile Augmented
Reality”, in Computer Graphics. pp. vii-viii.
BRAGA, P. H. C.; CARDOSO, A.; LAMOUNIER JR., E. A. “Desenvolvimento de Gestos Personalizados
para Criação e Navegação em Ambientes de Realidade Virtual e Aumentada associada a Dispositivos
Móveis.” XIV Simpósio de Realidade Virtual e Aumentada, 2012.
CARDOSO, A.; JR. LAMOUNIER, E. A.; KIRNER C.; OLIVEIRA C. L.; LOPES A. R.; MARQUES L. “Visão
Geral de um Framework para Realidade Aumentada em Diferentes Níveis de Abstração”. IX Workshop de
Realidade Virtual e Aumentada, 2012
CHANG W.; TAN Q., 2010. “Augmented reality system design and scenario study for location-based
adaptive mobile learning,” in 2010. IEEE 13th International Conference on Computational Science and
Engineering (CSE). ACM Press, 20–27.
DFusion. D’Fusion Studio. Disponível em:< http://www.t-immersion.com/products/dfusion-adobe-flash/
dfusion-sdk-adobe-flash>. Acesso em: 09 de agosto de 2011.
FLARE*NFT. Augmented Reality for Flash. Disponível em: http://www.imagination.at/en/?Products:
Augmented_Reality_for_Flash:flare%2Anft). Acesso em: agosto de 2011.
IN2AR. Augmented Reality Engine For Adobe Flash™ Player. Disponível em:<http://www.in2ar.com/>.
Acesso em: agosto de 2011.
LECHETA, R. R.; Google Android, 2nd ed., Novatec, Ed., 2010. [Online]. Available: http://www.
livroandroid.com.br/
MEIGUINS, B. S.; DO CARMO, R. M. C. L.; GONÇALVES, A. S.; PINHEIRO, S. C. V.; GARCIA, M.
B.; GODINHO, P. I. A. 2006. "Multidimensional information visualization using augmented reality" in
VRCIA '06 Proceedings of the 2006 ACM international conference on Virtual reality continuum and its
applications. ACM, New York, NY, 391-394. DOI= http://doi.acm.org/10.1145/1128923.1128996.
OLIVEIRA L. C., CARDOSO A., JR. LAMOUNIER, E. A. 2012. “Information Visualization in Mobile
Augmented Reality for Locating Objects in Indoor Environments”. In SVR ’12 Proceedings of the 2012. XIV
Symposium on Virtual Reality.
OLIVEIRA L. C, CARDOSO A. JR. LAMOUNIER, E. A. 2012. “Aplicação Genérica da Realidade
Aumentada Móvel para Localização e Visualização de Informações de Objetos e Lugares em Ambientes
Internos”.
73
OLSSON T., LAGERSTAM E., TUULA K. AND MATTILA K. V. V. 2012. “Expected user experience
of mobile augmented reality services: a user study in the context of shopping centres”. In Personal and
Ubiquitous Computing. 2012. DOI: http://dx.doi.org/10.1007/s00779-011-0494-x.
PHONEGAP. “About the project”. Mar 2013. [Online]. Disponível em: http://phonegap.com/about/.
PROJECT G., “Andar - android augmented reality”, Ago 2011. [Online]. Disponível em: http://code.google.
com/p/andar/.
QCAR SDK. “Qualcomm Vuforia, Site Oficial QCAR/Vuforia SDK”, Disponível em: https://developer.
vuforia.com/resources/dev-guide/getting-started-overview . Acesso em Abr 2013.
SANTOS G. P. JR., OLIVEIRA L. C, CARDOSO A. JR. LAMOUNIER, E. A. “Aplicação Multiplataforma
da Realidade Aumentada Móvel para Geolocalização utilizando o PhoneGap”. IX Workshop de Realidade
Virtual e Aumentada, 2012
SILVA A. C., SOUSA L. C. O, OLIVEIRA L. C, CARDOSO A. JR. LAMOUNIER, E. A. “Detecção de
Marcadores Naturais para Realidade Aumentada Móvel utilizando Redes Neurais Artificiais”. IX Workshop
de Realidade Virtual e Aumentada, 2012.
UNIFEYE. Disponível em: <http://docs.metaio.com/bin/view/Main/ UnifeyeDesignSysCompTracking#Pl
anarMarkerlessTracking>. Acesso em: agosto de 2011.
WOODILL G., “The Mobile Learning Edge: Tools and Technologies for Developing Your Teams”, 1st ed.,
McGraw-Hill, Ed., 2010. [Online]. Available: http://www.mobilelearningedge.com.
ZHOU F., DUH H. B. L.; BILLINGHURST, M. “Trends in augmented reality tracking, interaction and
display: A review of ten years of ISMAR,” in ISMAR ’08: Proceedings of the 7th IEEE/ACM International
Symposium on Mixed and Augmented Reality. Washington, DC, USA: IEEE Computer Society, 2008, pp.
193–202.
74
75
KAWAMOTO, André Luiz Satoshi; SILVA, Flávio Soares Correa da. Utilização de Dispositivos de Interfaces Naturais de Usuário em
Aplicações de Realidade Aumentada.
Utilização de Dispositivos de Interfaces Naturais de
Usuário em Aplicações de Realidade Aumentada
André Luiz Satoshi Kawamoto
Flávio Soares Correa da Silva
Abstract
Interfaces Naturais de Usuário (NUI) são uma evolução nas interfaces, capazes de reduzir o tempo de aprendizado e melhorar a usabilidade dos sistemas. Esse novo paradigma é suportado pela evolução tecnológica,
que introduziu dispositivos de hardware e software mais poderosos, responsáveis por dar vazão a funcionalidades como reconhecimento de gestos, comandos de voz, rastreamento de esqueletos, entre outras coisas.
Desde seu lançamento, o Microsoft Kinect tem despertado o interesse de diversos pesquisadores, graças ao
seu baixo custo e facilidade no desenvolvimento de aplicações. O presente trabalho apresenta uma descrição
de NUI, o dispositivo Kinect e sua aplicação na implementação de Sistemas de Realidade Aumentada (RA),
tanto como principal dispositivo de interação como em outras atividades da área de RA.
Resumo
Natural User Interfaces of (NUI) are an evolution in interfaces, capable of reducing the learning curve
and improving the usability of systems. This new paradigm is supported by technological developments,
which introduced more powerful hardware devices and software, responsible for enabling features as gesture recognition, voice commands, tracking skeletons, among other things. Since its release, the Microsoft
Kinect has attracted the interest of several researchers due to its low cost and ease in the development
of applications. This paper presents a description of NUI, the Kinect device and its application in the
development of Augmented Reality (AR) Systems, as primary hardware interaction device as in other
activities in the RA area.
1. Introdução
O termo Interfaces Naturais de Usuário (do inglês NUI - Natural User Interfaces) designa interfaces entre humanos e computadores as quais utilizam dispositivos não convencionais e que são baseadas
75
em elementos naturais. A palavra “natural”, nesse caso, é usada em oposição à maioria das interfaces
de computador, que utilizam dispositivos cuja operação precisa ser aprendida. Nesse tipo de interface,
pode-se afirmar que a interação se dá baseada em conhecimentos prévios do usuário, e dessa forma, é
fácil de aprender e de tornar-se experiente [Blake, 2013].
NUIs podem ser encontradas em vários sistemas e aplicações do nosso cotidiano: telas sensíveis
ao toque em computadores e smartphones; aplicações que aceitam comandos de voz; comandos gestuais para controlar televisores e jogos; sistemas BCI (Brain-Computer Interface – Interface Cérebro-Computador), onde comandos cerebrais desencadeiam a execução de tarefas.
Realidade Aumentada (RA) é uma variação de Realidade Virtual que permite ao usuário perceber
o mundo ao mesmo tempo em que objetos são inseridos de forma a compor com o mundo real. Assim,
a Realidade Aumentada suplementa a realidade, em vez de substitui-la completamente [Azuma, 1997].
Essa tecnologia é extensivamente empregada em diversas aplicações que variam desde ensino, treinamento, simulações, entretenimento, dispositivos de navegação até visualização de dados e apoio a
tarefas complexas, como cirurgias, montagem e manutenção de máquinas.
O presente trabalho apresenta uma visão geral sobre NUI, histórico e definições básicas até diretrizes para a concepção desse tipo de interface, e sua aplicação na área de RA - especificamente nas
implementações que utilizam o dispositivo Microsoft Kinect. Uma descrição desse dispositivo, suas
características técnicas e de programação é apresentada, bem como o estado-da-arte em sistemas que
utilizam Kinect, com os resultados e projeções de aplicações futuras.
2. Interfaces Naturais de Usuário
Historicamente, a interface entre homem e computador apresenta uma evolução, na qual podem ser destacados três paradigmas (Figura 1.1) Interfaces de Linha de Comando (CLI - Command
Line Interface), Interfaces Gráficas (GUI - Graphical User Interface) e, mais recentemente, Interfaces
Naturais(NUI).
Figura 1.1: Evolução de Interfaces.
Fonte: http://en.wikipedia.org/wiki/Natural_user_interface/
Em uma interface de linha de comando, sucessivas linhas de texto (linhas de comando) são enviadas pelo usuário para o sistema. Essa interface é encontrada em sistemas operacionais mais antigos,
como o MS-DOS, versões iniciais do Unix, entre outros. Geralmente, sua implementação consiste de
76
um prompt capaz de aceitar os comandos de texto e convertê-los para funções do sistema. Esse é o tipo
de interface frequentemente preferido por usuários avançados, já que fornece uma maneira concisa e
poderosa de controlar um sistema.
As interfaces gráficas são atualmente as mais comuns, sobretudo aquelas baseadas no paradigma
WIMP (Window, Icon, Menu, Pointer – Janela, Ícone, Menu, Ponteiro). Nesse paradigma, o mouse ou algum dispositivo similar - é usado para manipular elementos na tela (janelas, botões e menus) e,
assim, realizar tarefas. Do ponto de vista da usabilidade, esse tipo de interface traz benefícios como
a facilidade de se lembrar de ações e de se construir modelos que se mantêm coerentes para diversas
tarefas similares. Nesse paradigma, existe feedback visual imediato para indicar os efeitos de uma
determinada ação, por exemplo, ao apagar um arquivo, seu ícone imediatamente é removido da tela.
A maior vantagem de interfaces gráficas é que elas tornam a operação do computador mais intuitiva
e fácil de aprender.
Nos últimos anos, a evolução tecnológica permitiu a criação de uma gama de dispositivos, os
quais permitiram o surgimento de uma nova modalidade de interface, disponível em aplicações como
telas sensíveis ao toque, reconhecimento de comandos de voz, reconhecimento de gestos, entre outras
coisas. Esse novo paradigma é conhecido como Interfaces Naturais de Usuário (NUI). NUIs podem ser
definidas como “interfaces projetadas para reusar habilidades existentes para a interação direta com o
conteúdo” [Blake, 2013].
Essa definição evidencia três importantes conceitos a respeito de NUI. Primeiro, NUIs são projetadas, ou seja, requerem que sejam premeditadas e que sejam feitos esforços prévios para sua concepção. É preciso assegurar que as interações em uma NUI sejam apropriadas tanto para o usuário quanto
para o conteúdo e o contexto. Não basta agrupar diversos conceitos a esmo. É preciso ter ciência do
papel que os projetistas precisam executar ao criar interações naturais e assegurar que à fase de projeto
seja dada a mesma prioridade atribuída à fase de desenvolvimento [Blake, 2013].
Segundo, NUIs reutilizam habilidades existentes. Os usuários são peritos em diversas habilidades
que foram adquiridas pelo simples fato de serem humanos. Durante vários anos, os usuários têm praticado a comunicação, verbal ou não verbal, além de interações com o ambiente. O poder computacional
e tecnologia evoluíram ao ponto em que é possível tirar vantagem dessas habilidades. NUIs fazem isso
ao permitir que usuários interajam com computadores por meio de ações intuitivas como tocar, gesticular e falar, e apresentam interfaces as quais os usuários conseguem compreender primeiramente com
metáforas extraídas de experiências do mundo real [Blake, 2013].
Finalmente, NUIs têm interação direta com o conteúdo, ou seja, o foco da interação está no
conteúdo e na interação direta com ele. Isso não significa que a interface não possa ter controles, como
botões ou caixas de seleção, se necessário. Significa apenas que esses controles deveriam ser considerados secundários, comparados ao conteúdo, e que a direta manipulação do conteúdo deveria ser o
método de interação primário [Blake, 2013].
77
3. Diretrizes para a Construção de Interações Naturais
Em [Blake, 2013], quatro diretrizes são apresentadas para se projetar interações naturais, independente do tipo de interação: Experiência Instantânea (Instant Expertise), Carga Cognitiva (Cognitive
Load), Aprendizagem Progressiva (Progressive Learning) e Interação Direta (Direct Interaction).
A Experiência Instantânea pressupõe que as interações projetadas devem reutilizar habilidades
existentes. Fazendo isso, aproveitamos o investimento prévio feito pelos usuários em suas competências e criamos peritos instantaneamente. Tanto no mundo real quanto na criação de interfaces, o mais
difícil ao utilizar uma habilidade é o processo de aprendizado. Uma vez que essa habilidade é aprendida, torna-se bem mais fácil exercitá-la. Os usuários possuem diversas habilidades antes mesmo de usar
qualquer aplicação, muitas das quais têm sido exercitadas desde a infância. Interações que reutilizam
habilidades existentes permitem que os usuários tornem-se práticos rapidamente e com pouco esforço.
Há duas maneiras de criar peritos instantâneos: aproveitar habilidades específicas do domínio (como
o uso de ferramentas e dispositivos comuns a uma determinada atividade); e aproveitar habilidades
comuns a todos os humanos.
A Carga Cognitiva implica em projetar interfaces nas quais a maioria das interações usam habilidades inatas e simples. Isso traz consigo dois benefícios: a maior parte da interface será fácil de usar
e a interface será rápida para se aprender, mesmo que algumas das habilidades sejam completamente
novas. Se a interface usa habilidades baseadas em interações naturais com o mundo real, a frequência
de interações será muito mais alta. Realmente existe uma relação de custo-benefício entre Experiência
Instantânea e Carga Cognitiva. Essas diretrizes podem conflitar quando usuários já são dotados de
uma habilidade útil como, por exemplo, o uso do mouse. O foco, nesses casos, deve recair em minimizar a carga cognitiva para a maior parte das interações, reutilizando habilidades simples existentes. No
caso do mouse, embora seja possível assumir que os usuários já tenham experiência prévia, uma interface de toque é preferível, uma vez que o uso do mouse exige mais aprendizado do que usar os dedos.
A Aprendizagem Progressiva prevê uma curva de aprendizado suave a partir de tarefas básicas
até as tarefas avançadas. Interfaces Naturais devem permitir que seus usuários aprendam e evoluam
progressivamente, partindo de novatos até o nível de peritos. Ao mesmo tempo, as interfaces não podem dificultar que usuários experientes consigam realizar tarefas avançadas da melhor maneira. Essa
diretriz implica em permitir o uso da aplicação ao mesmo tempo em que tarefas mais complexas são
aprendidas.
A Interação Direta, por sua vez, estabelece que as interações devem se relacionar diretamente
com o conteúdo; ocorrer em frequência alta e ser apropriadas ao contexto. Uma vez que nossas interações com o mundo real apresentam essa característica, a adoção de interações diretas resulta em
interfaces mais fluidas e naturais, e permitem acesso a muitas funcionalidades sem sobrecarregar o
usuário apresentando-as todas ao mesmo tempo.
Em suma, essas quatro diretrizes versam sobre as habilidades, tarefas e interações em Interfaces
Naturais. Enquanto a Experiência Instantânea e Carga Cognitiva fornecem orientações para definir
tarefas individuais, a Aprendizagem Progressiva discute a sequência de tarefas em uma aplicação e,
finalmente, a Interação Direta está relacionada à qualidade da interação entre usuário e conteúdo da
aplicação.
78
4. O Microsoft Kinect
O Sensor Kinect é um dispositivo originalmente criado para prover Interfaces Naturais ao console
de jogos XBox 360. O uso desse dispositivo permite ao usuário controlar jogos por meio de gestos e comandos de voz. O hardware do Kinect é dotado de câmera RGB, sensor de profundidade, microfones,
motor de inclinação e um acelerômetro de três eixos (Figura 1.2).
Figura 1.2: Sensor Kinect e seus Componentes
Adaptado de: http://msdn.microsoft.com/en-us/library/hh855348.aspx/
O sensor de profundidade do Kinect consiste de uma fonte de luz infravermelha e de um laser
que projeta um padrão de pontos, os quais são lidos por um sensor CMOS monocromático. O sensor
detecta segmentos refletidos do padrão de pontos e converte suas intensidades para distâncias. A resolução da profundidade (ao longo do eixo z) é de cerca de um centímetro, enquanto a resolução espacial
(ao longo dos eixos x e y) é dada em milímetros. Cada quadro gerado pelo sensor de profundidade tem
resolução VGA (640 x 480 pixels), contendo valores de profundidade de 11 bits, que fornecem 2048
níveisde sensibilidade. O fluxo de saída tem taxa de quadros de 30 Hz [Jana, 2012].
O fluxo de vídeo RGB utiliza resolução VGA a uma taxa de quadros de 30 Hz. O vetor de áudio
consiste de quatro microfones, com cada canal processando áudio de 16 bits a uma taxa de amostragem de 16 KHz. O hardware inclui supressão de ruídos do ambiente. O Kinect consome 12 watts, mais
do que os 2.5 watts fornecidos por uma porta USB padrão. Isso significa que é necessário conectar o
dispositivo tanto na porta USB do PC quanto a uma fonte de energia separada para que o dispositivo
funcione apropriadamente. A Microsoft sugere que seja liberada uma área de cerca de 1,8 metros entre
o sensor e o usuário.
5. Programação para o Microsoft Kinect
Tão logo ocorreu seu lançamento, diversos desenvolvedores se dispuseram a prover código capaz
de permitir que o Kinect fosse utilizado em outras plataformas (Windows, Linux, Mac), entre esses,
podemos destacar o OpenKinect, OpenNI, e finalmente, o Microsoft Kinect SDK [OpenKinect,2013]
[OpenNI, 2013] [Jana, 2012].
79
OpenKinect é um projeto de código livre responsável pelo libfreenect. O libfreenect permite acesso ao dispositivo Kinect, com suporte a acessar imagens RGB, imagens de profundidade, motores,
acelerômetro. Embora escrito em C, essa biblioteca provê acesso para várias linguagens como Python,
ActionScript, C++, C\# e Java. A biblioteca é usada como base para alguns projetos, como ofxKinect e
RGBDemo, existem exemplos que usam libfreenect como backend para PCL [Cruz et al., 2012].
Open Natural Interaction, ou OpenNI, é uma organização sem fins lucrativos responsável, entre
outras coisas, pela manutenção de um framework de desenvolvimento para o Kinect de código aberto
[OpenNI, 2013] que suporta diversas linguagens de programação e arquiteturas de hardware. OpenNI
é composta de dois conjuntos de APIs, uma implementada pelos dispositivos, e outra implementada
por componentes do middleware. Essa arquitetura permite que aplicações sejam escritas para sem que
haja a preocupação de qual sensor será utilizado. Assim, aplicações podem ser desenvolvidas para diversos fabricantes. OpenNI é usada em diversos projetos, como OpenCV, Unity3D, TUIO, PCL, openFrameworks, entre outros [Cruz et al., 2012].
Microsoft Kinect SDK for Windows é a API da Microsoft para desenvolvimento de aplicações para
sistemas operacionais Windows, que suporta o desenvolvimento de aplicações escritas nas linguagens
C\#, C++ e Visual Basic. Várias funcionalidades são implementadas como, por exemplo, o reconhecimento de posição sentado ou em pé, o reconhecimento e rastreamento facial, o reconhecimento de
comandos de voz, entre outras coisas. A arquitetura do Kinect SDK é apresentada na Figura 1.3.
Figura 1. 3: Arquitetura do MS Kinect SDK
Fonte: http://msdn.microsoft.com/en-us/library/hh855348.aspx/
Na camada 1, encontram-se os componentes de hardware instalados no dispositivo Kinect; a camada 2 é formada pelos drivers do dispositivo, além dos componentes de software capazes de prover
acesso e configuração ao fluxo de áudio e vídeo. As camadas 3, 4 e 5 consistem, basicamente, das APIs
de NUI, Áudio e DMO (DirectX Media Object) – que dá suporte aos microfones do dispositivo; na ca80
mada superior, encontra-se o conjunto de aplicações que utilizam o Kinect e podem ser desenvolvidos,
utilizando essas APIs.
Os drivers do Kinect que constituem o Micrsoft SDK suportam [Jana, 2012]:
• O conjunto de microfones do dispositivo na forma de um dispositivo de áudio que pode ser
acessado por meio das APIs de áudio padrão do Windows;
• Controles para fluxo de áudio e vídeo, tanto para o fluxo de imagens RGB, imagens de profundidade e reconhecimento de esqueleto;
• Funções que dão apoio ao acesso simultâneo de mais de um dispositivo Kinect.
6. Aplicações do Kinect em Realidade Aumentada
Devido ao seu baixo custo, e a facilidade de desenvolver aplicações, o uso do Kinect tem sido
explorado em diversas aplicações, que variam desde seu objetivo primário (entretenimento), passando
por jogos sérios (serious games) para reabilitação e monitoramento de pacientes [Patsadu et al., 2012]
[Martins et al.,2011] [Martin et.al, 2012] [Yeh et al., 2012] [Kondori et al., 2011] [Lange et al., 2011],
ensino de linguagem de sinais [Zafrulla et al., 2011], criação de modelos tridimensionais utilizando
dados do sensor de profundidade [Tong et al., 2012], além da criação de interfaces gestuais associadas
a Interfaces de voz [Lai et al., 2012], entre outras coisas.
Na área de RA, o uso do Kinect tem sido explorado desde a criação de modelos tridimensionais,
até a manipulação de objetos virtuais sem o uso de marcadores e visualização.
Inicialmente, em [Livingston et al., 2012] uma série de testes é conduzida, a fim de investigar a
adequação do Kinect em aplicações nas quais Ambientes Virtuais são controlados por avatares. Foram determinados parâmetros adequados de ruído, precisão, resolução e latência do software durante
o acompanhamento de esqueletos, bem como definidas as distâncias mínima e máxima, dentro das
quais o usuário deve se posicionar a fim de satisfazer esses parâmetros.
Esse estudo tece algumas considerações a respeito do melhor posicionamento do dispositivo:
aproximá-lo reduz o ruído, por outro lado, afastá-lo reduz a latência. Considera ainda questões de
iluminação do ambiente – a luz fluorescente muito intensa pode aumentar o ruído. Os resultados desse
experimento demonstram que o uso do Kinect é bastante adequado para capturar comandos gestuais
nessa classe de aplicação, ou seja, aplicações que utilizam uma única tela de projeção. O ruído não
impediu o reconhecimento de gestos, e a taxa de erros, embora maior que a de dispositivos comerciais
específicos para esse fim, não foi considerada problema. A latência, bem maior que a de dispositivos
comerciais de rastreamento, foi considerada sua maior desvantagem.
Na geração de modelos tridimensionais, o Kinect Fusion [Izadi et al., 2011] é um sistema que
utiliza dados de profundidade obtidos em tempo real da câmera do Kinect e cria modelos 3D de alta
qualidade, geometricamente precisos. Esse sistema possibilita que um usuário, movimentando-se em
um espaço fechado ao mesmo tempo em que segura uma câmera, possa varrer e criar um modelo 3D
do ambiente inteiro e seu conteúdo. Os autores alegam que qualquer movimento permite que novos
pontos de vista da cena sejam criados e, assim, refinamentos e detalhes são adicionados. A aplicação
sucessiva de várias varreduras aplicadas ao mesmo objeto resulta em um modelo 3D preciso.
81
Figura 1. 6: Detalhamento de modelos 3D - Kinect Fusion [Izadi et al., 2011]
Ainda tratando de criação de modelos 3D, em [Kahn, 2011] é discutida a distância existente entre o
processo de se modelar objetos para RA e seu uso efetivo. A consequência disso é que os modelos, criados nas etapas de preparação offline, são difíceis de detectar mudanças e adaptarem-se a elas. O trabalho apresenta um framework para detecção de alterações 3D e ajuste de modelos que combina técnicas
de RA com a geração de imagens de profundidade em tempo real para aproximar a modelagem 3D da
Realidade Aumentada. Esse método detecta as diferenças entre uma cena e o modelo 3D da cena e usa
as diferenças geométricas para atualizar o modelo em tempo real. A precisão da detecção geométrica
depende da precisão das medidas de profundidade, bem como da precisão dos parâmetros intrínsecos
e extrínsecos. Para avaliar a influência desses parâmetros, vários experimentos foram feitos com dados
simulados. Além disso, a avaliação mostra a aplicabilidade de RA e modelagem 3D baseadas em imagens de profundidade para rastreamento de câmera baseados em modelos.
No que diz respeito a interação em aplicações de RA, em [Santos et al., 2011] é apresentado um
sistema que permite ao usuário interagir com menus e manipular objetos (inserir, selecionar, mover,
rotacionar e escalonar) sem o uso de marcadores. Nesse sistema, o uso de mãos e gestos é considerado
uma interface cognitivamente vantajosa em relação ao tradicional uso de marcadores.
Ainda no que diz respeito à interação em sistemas de RA, em [Ionescu et al., 2010] é apresentado
um novo modelo para mapeamento de profundidade em tempo real, que usa uma câmera 3D para
controlar aplicações de computador, variando desde jogos até ambientes multimídia colaborativos.
Esse modelo usa dados de profundidade obtidos da câmera 3D para analisar e reconstruir, em tempo
real, partes do corpo e movimentos do usuário. Os movimentos são pré-determinados, e podem disparar, por exemplo, ações em jogos, veículos não tripulados, controle de produtos eletrônicos, entre
outras coisas. Para demonstrar esse modelo, a câmera 3D é usada para interface em uma aplicação de
realidade aumentada.
Um exemplo de aplicação do Kinect, juntamente com Realidade Aumentada na visualização e no
estudo de interações sociais é dado em [Leroy et al., 2011]. Esse trabalho investiga o conceito de espaços interpessoais (distâncias estabelecidas inconscientemente entre as pessoas). Segundo os autores,
a medida da distância entre os espaços interpessoais pode indicar o grau de intimidade das pessoas.
82
Para suportar essa ideia, uma aplicação de RA foi criada, capaz de modelar os espaços sociais em torno
dos usuários em uma cena. Essa aplicação utiliza a câmera do Kinect para capturar as imagens e para
determinar a posição das pessoas na cena 3D.
Figura 1. 4: Interface da Aplicação Personal Space [Leroy et al., 2011]
Um serious game para reabilitação do movimento de mãos e braços em vítimas de acidentes vasculares cerebrais é apresentado em [Mousavi Hondori et al., 2013]. Trata-se de um sistema que combina
sensores de inércia com o Kinect, e que rastreia a mão do usuário e cria uma interface que envolve os
movimentos do pulso, cotovelo e ombros. Mede-se a amplitude, velocidade e suavidade dos movimentos, além de tirar fotos e envia-las, via e-mail, para clínicas, visando avaliação posterior.
O projeto Augmented Mirror [Vera et al., 2011] propõe uma aplicação de RA que integra imagens
de vídeo, um avatar (controlado em tempo real pelo usuário) e objetos virtuais introduzidos na cena. A
aplicação utiliza, dois Kinects para a captura de movimentos, mapa de profundidade e captura de imagens por meio da câmera, um giroscópio para detectar movimentos da cabeça e algoritmos de controle
para gerenciar a representação de emoções do avatar.
No ensino de Anatomia, um sistema que utiliza um “espelho de RA” é apresentado em [Blum et
al., 2012]. Nesse sistema, a câmera de profundidade é utilizada para rastrear a postura do usuário que
se coloca em frente a uma tela. É gerada, então uma visualização de uma tomografia computadorizada
sobre o usuário, criando a ilusão de que é possível observar o interior de seu corpo, como mostra a
Figura 1.5.
83
Figura 1.5: Mirracle - Realidade Aumentada no Ensino de Anatomia [Blum et al., 2012]
Gestos são usados para selecionar diferentes camadas da tomografia e um conjunto de dados fotográfico pode ser escolhido para visualização. Esse sistema é capaz, ainda, de exibir modelos 3D de
órgãos internos, informações textuais e imagens a respeito de anatomia. A interação com esse sistema
dispensa marcadores e utiliza dados de profundidade, aumentando ou diminuindo a visibilidade das
mãos baseada na sua distância em relação a um plano de interação virtual. Segundo os autores, isso
auxilia o usuário a perceber as relações espaciais entre seu corpo e o plano de interação virtual.
Em [Tang et al., 2011], é apresentada uma técnica de visualização 3D que combina a detecção de
informação de superfícies com a renderização e projeção com perspectiva corrigida. A cena virtual é
alterada e renderizada com informações de superfície detectadas, e então mapeadas e projetadas sobre
as superfícies corespondentes dos objetos. Comparada com realidade aumentada convencional, que
requer dispositivos de exibição adicionais, essa abordagem utiliza melhor informações estruturais dos
objetos e permite referências diretas a partir de objetos físicos usados para projeções, permitindo assim
experiências de RA melhores, e potencial para interação mais intuitiva.
Um método para detecção de objetos em tempo real, capaz de reconhecer objetos tridimensionais,
independente de alterações em sua textura ou condição de iluminação, é apresentado em [Lee et al.,
2011]. Esse método calcula um conjunto de modelos de referência de um objeto a partir de imagens
RGB e de profundidade, que descrevem tanto a textura quanto a geometria do objeto, e os unifica a
fim de uma detecção robusta. O sistema é capaz de atingir detecção em tempo real, consumindo cerca
de 33 milissegundos para detectar objetos e estimar sua posição (Figura 1.6). Esse método é proposto
84
para aplicações de Realidade Aumentada “markerless”, usando objetos tridimensionais reais, além dos
marcadores planos convencionais.
Figura 1.7: Uso de RA aplicado ao reconhecimento de Objetos 3D [Lee et al., 2011]
A grande vantagem desses sistemas, ao adotar o dispositivo Kinect recai, sobretudo no seu baixo
custo, que faz com que a relação custo/benefício seja vantajosa. Além desses, diversos outros sistemas,
que utilizam dispositivos de NUI, têm sido propostos e desenvolvidos. Esses sistemas aproveitam as
facilidades que esses dispositivos introduzem e propiciam o surgimento de novos tipos de interação
com o usuário para sistemas de RA.
NUIs representam uma evolução das interfaces de usuário capaz de introduzir um salto na qualidade dos sistemas, sobretudo no que diz respeito à usabilidade. Entre as vantagens introduzidas pelas
NUIs, o aproveitamento de habilidades intrínsecas, dispensando treinamento e aprendizado de novos
dispositivos.
85
Os avanços tecnológicos têm permitido o desenvolvimento de novos dispositivos de hardware e
software, capazes de suportar funcionalidades de reconhecimento de comandos voz, de gestos, de posturas, monitoramento de faces, entre outras coisas. Dentre os dispositivos que surgiram para prover a
criação de NUI, o Microsoft Kinect permite a implementação de aplicações para várias plataformas de
software, utilizando várias linguagens de programação.
Diversas aplicações aproveitam as facilidades introduzidas pelo Kinect em diversas áreas de aplicação da Realidade Virtual e Aumentada e criam sistemas que dispensam o uso de marcadores e fornecem visualização de dados, monitoramento, tutoria e treinamento de usuários. Outros sistemas, ainda,
estendem o uso primário do Kinect para NUI e aproveitam seus recursos na implementação de novas
funcionalidades, como a modelagem de objetos tridimensionais.
No que diz respeito à convergência de RA e NUI, podemos concluir que há grande possibilidade
de surgimento de uma nova gama de aplicações, limitadas apenas pela imaginação e pela capacidade
inventiva dos pesquisadores da área. As diversas possibilidades de pesquisa e desenvolvimento existentes incluem sistemas para monitoramento de pessoas, vigilância, reabilitação, entretenimento, sistemas médicos, sistemas educacionais para treinamento, ensino, capacitação e simulações interativas,
além da visualização de dados e controle de dispositivos.
Referências
AZUMA, R. T. (1997). “A survey of augmented reality”. Presence: Teleope- rators and Virtual Environments,
Vol. 6, num. 4:355–385.
BLAKE, J. (2013). “Natural User Interfaces in .Net. Manning Pubs Co Series”. Manning Publications
Company.
BLUM, T.; KLEEBERGER, V.; BICHLMEIER, C.; NAVAB, N. (2012). “mirracle: An Augmented Reality
Magic Mirror System for Anatomy Education”. In IEEE Virtual Reality 2012 (VR), Orange County, USA.
CRUZ, L.; LUCIO, D.; VELHO, L. 2012. “Kinect and rgbd images: Challenges and applications”. In
Graphics, Patterns and Images Tutorials (SIBGRAPI- T), 2012 25th SIBGRAPI Conference on, pages
36–49.
HONDORI, H.; KHADEMI, M.; LOPES, C. 2012. “Monitoring intake gestures using sensor fusion
(microsoft kinect and inertial sensors) for smart home tele-rehab setting”. In 2012 IEEE EMBS HIC.
IONESCU, D.; IONESCU, B.; ISLAM, S.; GADEA, C.; MCQUIGGAN, E. SEPT.. “Using depth
measuring cameras for a new human computer interaction in augmented virtual reality environments”.
In Virtual Environments Human-Computer Interfaces and Measurement Systems (VECIMS), 2010 IEEE
International Conference on, pages 114–119.
86
IZADI, S.; KIM, D.; HILLIGES, O.; MOLYNEAUX, D.; NEWCOMBE, R.; KOHLI, P.; SHOTTON, J.;
HODGES, S.; FREEMAN, D.; DAVISON, A.; FITZGIBBON, A. 2011. “KinectFusion: real-time 3d
reconstruction and interaction using a moving depth camera”. In Proceedings of the 24th annual ACM
symposium on User interface software and technology, UIST ’11, pages 559–568, New York, NY, USA.
ACM.
JANA, A. (2012). “Kinect for Windows SDK Programming Guide”. Community experience distilled. Packt
Pub. ISBN: 9781849692397.
KAHN, S. (2011). “Reducing the gap between augmented reality and 3D modeling with real-time depth
imaging”. Virtual Reality, pages 1–13.
KONDORI, F.; YOUSEFI, S.; LI, H.; SONNING, S.;SONNING, S. (2011). “3d head pose estimation using
the kinect”. In Wireless Communications and Signal Processing (WCSP), 2011 International Conference
on, pages 1 –4.
LAI, K.; KONRAD, J.; ISHWAR, P. (2012). “A gesture-driven computer interface using kinect”. In Image
Analysis and Interpretation (SSIAI), 2012 IEEE Southwest Symposium on, pages 185 –188.
LANGE, B.; CHANG, C.Y.; SUMA, E.; NEWMAN, B.; RIZZO, A.; BOLAS, M. 2011. “Development
and evaluation of low cost game-based balance rehabilitation tool using the microsoft kinect sensor”. In
Engineering in Medicine and Biology Society,EMBC, 2011 Annual International Conference of the IEEE,
pages 1831 –1834.
LEE, W.; PARK, N.; WOO, W. 2011. “Depth-assisted real-time 3d object detection for augmented reality”.
In The 21st International Conference on Artificial Reality and Telexistence. The Virtual Reality Society of
Japan.
LEROY, J.; MANCAS, M.; GOSSELIN, B. 2011. “Personal space augmented reality tool”. In First joint
WIC/IEEE SP Symposium on Information Theory and Signal Processing in the Benelux.
LIVINGSTON, M.; SEBASTIAN, J.; AI, Z.; DECKER, J. (2012). “Performance measurements for the
microsoft kinect skeleton”. In Virtual Reality Workshops (VR), 2012 IEEE, pages 119 –120.
MARTIN, C.; BURKERT, D.; CHOI, K.; WIECZOREK, N.; MCGREGOR, P.; HERRMANN, R.; BELING, P.
2012. “A real-time ergonomic monitoring system using the microsoft kinect”. In Systems and Information
Design Symposium (SIEDS), 2012 IEEE, pages 50 –55.
MARTINS, T.; CARVALHO, V.; SOARES, F.; MOREIRA, M. 2011. “Serious game as a tool to intellectual
disabilities therapy: Total challenge”. In Serious Games and Applications for Health (SeGAH), 2011 IEEE
1st International Conference on, pages 1 –7.
MOUSAVI HONDORI, H.; KHADEMI, M.; DODAKIAN, L.; CRAMER, S. C.; LOPES, C. V. 2013). “A
spatial augmented reality rehab system for post-stroke hand rehabilitation”. Stud Health Technol Inform,
184:279–85.
OpenNI, 2013 http://www.openni.org/. Acesso em 23/03/2013.
87
OpenKinect, 2013 http://openkinect.org/. Acesso em 23/03/2013.
PATSADU, O.; NUKOOLKIT, C.; WATANAPA, B. 2012. “Human gesture recognition using kinect
camera”. In Computer Science and Software Engineering (JCSSE), 2012 International Joint Conference
on, pages 28 –32.
SANTOS, E.; LAMOUNIER, E.; CARDOSO, A. (2011). “Interaction in augmented reality environments
using kinect”. In Virtual Reality (SVR), 2011 XIII Symposium on, pages 112 –121.
TANG, Y.; LAM, B.; STAVNESS, I.; FELS, S. 2011. “Kinect-based augmented reality projection with
perspective correction”. In ACM SIGGRAPH 2011 Posters, SIGGRAPH ’11, pages 79:1–79:1, New York,
NY, USA. ACM.
TONG, J.; ZHOU, J.; LIU, L.; PAN, Z.; YAN, H. 2012). “Scanning 3d full human bodies using kinects”.
Visualization and Computer Graphics, IEEE Tran- sactions on, 18(4):643 –650.
VERA, L.; GIMENO, J.; COMA, I.; FERNÁNDEZ, M. (2011). “Augmented mirror: Interactive augmented
reality system based on kinect”. In CAMPOS, P.; GRAHAM, N.; JORGE, J.; NUNES, N.; PALANQUE,
P.; WINCKLER, M., editors, Human-Computer Interaction – INTERACT 2011, volume 6949 of Lecture
Notes in Computer Science, pages 483–486. Springer Berlin Heidelberg.
YEH, S.C.; HWANG, W.Y.; HUANG, T.C.; LIU, W.K.; CHEN, Y.T.; HUNG, Y.P. (2012). “A study for
the application of body sensing in assisted rehabilitation training”. In Computer, Consumer and Control
(IS3C), 2012 International Symposium on, pages 922 –925.
ZAFRULLA, Z.; BRASHEAR, H.; STARNER, T.; HAMILTON, H.; PRESTI, P. (2011). “American sign
language recognition with the kinect”. In Proceedings of the 13th international conference on multimodal
interfaces, ICMI ’11, pages 279–286, New York, NY, USA. ACM.
88
89
DIAS, Diego Roberto Colombo, et al. Desenvolvimento de Aplicações com Interface Natural de Usuário e
Dispositivos PrimeSense como Meio de Interação para Ambientes Virtuais.
Desenvolvimento de Aplicações com Interface
Natural de Usuário e Dispositivos PrimeSense como
Meio de Interação para Ambientes Virtuais
Diego Roberto Colombo Dias
Gustavo Jordan Castro Brasil
Bruno Barberi Gnecco
Mário Popolin Neto
Isabele Andreoli Agostinho
Richard Valdívia
José Remo Ferreira Brega
Luis Carlos Trevelin
Abstract
Natural User Interfaces (NUI) have been used as a form of interaction between user and machines. They
are invisible, since they do not required that users wear any kind of devices. Applications that have NUIs
tend to be easy to learn and have intuitive interaction. Virtual and augmented reality applications can
be improved by this kind of interface, since it can track the user's body and immerse it more faithfully
in the virtual world. The use of devices such as PrimeSnse to track bodies for NUI interfaces is already
quite common and there are many libraries and SDKs available. This pre symposium intends to present
the possible methods to develop NUI applications with device such as Microsoft Kinect, Asys Xtion and
others to interact in virtual environments. Example applications are provided.
Resumo
A Interface Natural de Usuário (NUI) tem sido utilizada como forma de interação entre o usuário e máquina, sendo essa invisível, por não ter a necessidade de que o usuário utilize nenhum tipo de dispositivo
agregado ao corpo. Aplicações que possuam caracterísiticas de NUI tendem a ser de fácil aprendizado e
possuir interação intuitiva. Aplicações de Realidade Virtual e Aumentada podem ser beneficiadas por
este tipo de interface, se utilizada como forma de rastreamento corporal. O uso de dispositivos PrimeSense como meio de rastreamento corporal para aplicações NUI já é bastante difundido, possuindo várias
bibliotecas e SDKs disponíveis. Este pré simpósio visa apresentar as possíveis soluções para o desenvolvimento de aplicações de NUI que utilizem o dispositivo Microsoft Kinect, Asus Xtion entre outros, para a
interação em ambientes virtuais. Aplicações exemplos são apresentadas.
89
1. Introdução
Muitos estudos tem sido realizados na área de Interface Natural de Usuário em função da existência de diversos trabalhos na área da computação que consideram essa abordagem de interface uma
solução viável atualmente, tanto economicamente quanto a sua viabilidade técnica.
Dessa forma, algumas empresas tem se empenhado em desenvolver as inovações para atender
essa demanda. Segundo Gnecco et. al (2012), um grande passo foi realizado com o desenvolvimento da
tecnologia de câmera Z-Buffer, ou seja, cameras capazes de obter informações de distância baseadas
em um conjunto de pontos emitidos por feixe de luz IR (infra-vermelho) e tratados na reconstrução 3D
utilizando luz estruturada.
Ainda conforme Gnecco et. al (2012), câmeras com características de RGB+Z permitiram que
ferramentas computacionais com o conceito de visão computacional de baixo custo fossem desenvolvidas e levadas ao público consumidor. Assim, surgiram várias iniciativas, primeiro da comunidade
do software livre, e depois das corporações privadas, em prover o instrumental necessário para que desenvolvedores pudessem tirar proveito dessa tecnologia, provendo soluções imediatas para problemas
das mais diversas áreas do conhecimento.
Tópicos da área de interesse da Interface Homem Computador (IHC) tem tirado proveito dessa
forma de comunicação com dispositivos eletrônicos, criando normas de interação, e dessa forma, facilitando a vida do usuário. Estudos na área de comunicação por meio de gestos tem sido de grande
relevância para a comunidade científica. Bhuiyan (2009) cita que humanos se comunicam por meio de
gestos, e dessa forma é possível construir um vocabulário que seja interpretável pela máquina, a fim de
tirar proveito dela em diversas tarefas cotidianas.
As áreas de aplicação são inúmeras, e muitas ainda irão surgir, frente a facilidade que essas inovações tecnologicas vem proporcionando. Com a visão computacional, juntamente com o rastreamento
corporal, pode-se obter bons resultados em áreas relacionadas ao entretenimento, a reabilitação cognitiva
e motora, inteligência artificial, comandos a distância para a área da robótica, educação a distância, etc.
Este capítulo apresenta as bibliotecas disponíveis para o desenvolvimento de aplicações para dispositivos PrimeSense. Uma breve descrição de cada biblioteca é apresentada, contudo, são apresentadas apenas aplicações desenvolvidas com a OpenNI, por ser uma das mais utilizadas no meio acadêmico, e prover suporte para todos os dispositivos PrimeSense.
O capítulo está organizado da seguinte forma. A seção 2 apresenta a definição e uso de Interface
Natural de Usuário. A seção 3 apresenta os dispositivos PrimeSense. A seção 4 apresenta as bibliotecas
de desenvolvimento. A seção 5 apresenta as aplicações práticas, sendo essas desenvolvidas em três
diferentes linguagens: C/C++, Java e Processing. Finalmente a seção 6, que apresenta as conclusões e
perspectivas futuras para a tecnologia.
2. Interface Natural de Usuário
A Interface Natural de Usuário e/ou Natural User Interface (NUI) é a interface comum usada por
designers e desenvolvedores de interfaces de computador para se referir à interação com o computador
de um modo efetivamente invisível, ou tornando-se invisível com sucessivas interações aprendidas.
90
Segundo Wigdor (2011), NUI não é uma interface natural, mas sim uma interface que permite seu
usuário agir e sentir como se fosse natural, interpreta-se melhor mudando a forma de dizer "interface
natural", não é uma interface natural de usuário, mas sim uma interface de usuário natural.
A maioria das interfaces de computadores utiliza se de dispositivos de controle artificial, cujo o
aprendizado dos comandos é realizado por meio de botões, tais como teclado alfanúmerico ou controle
de vídeo-game, cuja a curva de aprendizagem pode ser alta. Uma interface NUI exige apenas que o
usuário seja capaz de interagir com o ambiente por meio de interações previamente já conhecidas pelos
mesmos, como, por exemplo, gestos e voz. Esse tipo de interface também exige aprendizagem, porém é
facilitada, pois não exige que o usuário seja apresentado a um novo dispositivo. Assim, a comunicação
por meio de gestos é algo inerente ao ser humano.
Segundo Weiyuan (2010), a NUI possuí as seguintes características:
• Design centrado no usuário: provê as necessidades de mudança da interface para diferentes
usuários;
• Multi-canal: visa capturar vários canais de entrada do usuário para a realização da interação
com o computador. São considerados canais de entrada do usuário: mãos, boca, olhos, cabeça, pés e o corpo como um todo;
• Inexato: as ações e pensamentos dos usuários não são precisos, de modo que, o computador
deve entender a requisição das pessoas;
• Largura de banda alta: devido à grande quantidade de dados gerados pelos dipositivos de
interface utilizados, a NUI deve prover suporte a alta taxa de dados;
• Interação baseada por voz: considerada o meio mais conveniente, eficiente e natural de compartilhamento de informações. Em interfaces NUI possui duas abordagens: reconhecimento
vocal e tecnologia de compreensão;
• Interação baseada por imagens: os humanos utilizam como principal sentido a visão. Para
interfaces NUI, as imagens podem ser abordadas em 3 diferentes níveis: processamento de
imagens, reconhecimento de imagens e percepção de imagens; e
• Interação baseada no comportamento: responsável por reconhecer a linguagem corporal do
usuário, isto é, movimentos que expressem algum significado.
Dispositivos comuns para NUI incluem:
• Sensores 3D - Para utilização de interação baseada por imagens a partir da captura 3D;
• Câmeras RGB - Para utilização de interação baseada por imagens a captura de imagem real
para ser utilizada em ambientes virtuais como realidade aumentada e processamento de pixels para detecção de imagens coloridas em processamento de imagem em geral; e
• Microfones - Para utilização de interação baseada por voz.
No projeto das aplicações com NUI é preciso levar em consideração algumas particularidades de
interfaces. Segundo Gnecco (2012), a precisão dos gestos baseados no rastreamento de câmeras não é
tão alta quanto a de um mouse, por exemplo.
91
3. Dispositivos PrimeSense
Os dispositivos Microsoft Kinect e Asus XTion utilizam a tecnologia criada pela PrimeSense
(2013). O CMOS SoC PS1080, codinome Carmine, que é implementado no Kinect, é capaz de capturar
os dados do sensor infravermelho, fornecendo dados de profundidade em tempo real. O sensor PS1080
possui duas versões: Carmine 1.08 e a Carmine 1.09. A diferença entre as versões está na distância necessária para que o dispositivo realize o rastreamento, sendo 0.8m-3.5m no Carmine 1.08, e 0.,5-1.4m
no Carmine 1.09. A Figura 1 apresenta a arquitetura do chip PrimeSense.
Figura 1 – Sensor PS1080 PrimeSense [PrimeSense, 2013]
O Kinect não é o único dispositivo que usa a tecnologia dos sensores PrimeSense, outras fabricantes também tem desenvolvidos dispositivos semelhantes, como o ASUS Xtion Pro LIVE.
Na Figura 1 pode-se notar a existência de componentes opcionais e obrigatórios. Os componentes
principais do sensor são o gerador de luz infravermelha, a câmera de profundidade, a memória flash
e a interface USB 2.0. Dentre os componentes opcionais, tem-se a câmera RGB e os componentes referentes a microfone e speakers.
92
A próxima geração de sensores de aquisição de profundidade foi criada a partir do sensor PS1200,
codinome Capri, no qual foram otimizados os algoritmos de rastreamento. Esse novo sensor permitirá
uma performance superior em relação a resolução, redução de distância do sensor ao usuário e redução
de custos.
3.1. Microsoft Kinect
O dispositivo Microsoft Kinect para Xbox360, originalmente destinado a ser um dispositivo de
detecção de movimentos para o console Xbox 360, permite ao usuário controlar jogos por meio de
gestos, fala e comandos. Os principais componentes de hardware são uma câmera RGB, sensor de profundidade, vetor de microfones, um motor de inclinação, e um acelerômetro de três eixos. A Microsoft
lançou um Kinect específico para PC, pois os destinados a XBOX 360 não possuem licença para serem
utilizados em PCs. A versão para PC, por sua vez, possui um kit de desenvolvimento básico incluso,
capaz de suportar gestos e voz em aplicações desenvolvidas para o sistema operacional Windows.
O Kinect é baseado em um projeto do sensor PrimeSensor, desenvolvido pela PrimeSense. A
captura de profundidade consiste em uma fonte de luz infravermelha (IR) que projeta um padrão de
pontos, que são lidos por uma câmera IR monocromática. A câmera IR captura partes refletidas do
padrão de pontos e converte suas intensidades em distâncias.
Nos modelos atuais cada quadro gerado pelo sensor de profundidade possuí resolução VGA (640
× 480 pixels), com uma taxa de atualização de 30 Hz. O uso de uma resolução maior, de até UXGA
(1600 x 1200 pixels) é possível por meio de interpolação. A matriz de áudio é composta por quatro microfones, com cada canal de processamento de áudio de 16 bits, a uma taxa de amostragem de 16 kHz.
O hardware inclui a supressão de ruído ambiente. O Kinect utiliza 12 watts de energia de alimentação
externa e mais de 2,5 watts fornecidos por uma porta USB padrão.
3.2. Asus Xtion
O Xtion PRO LIVE provê soluções para desenvolvedores que desejam utilizar tecnologia de sensor
de movimento em aplicações industriais ou de pesquisa. O Kit vendido pela Asus permite ao desenvolvedor criar aplicações diversas. O Xtion PRO LIVE utiliza sensores infravermelhos, tecnologia de
detecção de profundidade, uma câmera RGB e microfones, para capturar vídeo e imagem em tempo
real, tornando o rastreamento mais preciso.
O dispositivo permite o rastreamento de mãos sem nenhum atraso, tornando a mão do usuário
em um controle. Ele permite 8 posições pré definidas para a execução de movimentos de push, click,
wave entre outros, o que permite que aplicações de controle para interfaces gráficas sejam desenvolvidas facilmente. As aplicações de RV podem utilizar essas poses pré definidas para efetuar a interação
de ambientes com foco em visualização, ao invés dos controles convencionais, como teclado e mouse.
O rastreamento corporal permite que o usuário utilize todo o seu corpo como meio de interação a
aplicações, sendo ideal para jogos. Como o Kinect, ele também é compatível com soluções baseadas em
soluções de software OpenNI/NITE. O Xtion PRO LIVE tem suporte ao motor gráfico Unity3D, o que
permite ao desenvolvedor criar aplicações de forma rápida, mas com a qualidade de um motor gráfico.
93
4. Ferramentas de Desenvolvimento
As soluções de desenvolvimento para dispositivos PrimeSense possuem características que tendem a facilitar o seu uso. Contudo, existem soluções open source e comerciais, uma característica
que deve ser levada em conta no momento inicial de desenvolvimento de um aplicativo. Esta seção
apresenta as três ferramentas de desenvolvimento mais conhecidas, apresentando as suas principais
características.
4.1. OpenKinect
A OpenKinect (2013) é uma comunidade aberta, com pessoas interessadas em utilizar o dispositivo Kinect em computadores pessoais ou outros dispositivos. O foco da comunidade é o desenvolvimento da biblioteca libfreenect distribuído sob a GNU General Public License (GPL v2.0) . A libfreenect
compõe classes de desenvolvimento para acesso ao hardware do dispositivo e suas funcionalidades em
geral, sendo a primeira biblioteca a prover a possibilidade de desenvolvimento de aplicações utilizando
o Kinect como interface para a interação. Sua API é compatível com os sistemas operacionais Windows, GNU/Linux e OS X, possuindo bindings e extensões para C, C++, .NET (C#/VB.NET) e Java.
A libfreenect permite que as câmeras infravermelho e RGB sejam utilizadas pelas aplicações desenvolvidas, contudo, os dados devem ser tratados por outras ferramentas. O tratamento dos dados
pode ser realizado em conjunto com bibliotecas de visão computacional, como a OpenCV (Open Source Computer Vision Library), que possuí módulos para reconhecimento de objetos, e/ou a ARToolKit,
que possui métodos de detecção de tags em imagens implementados em sistemas de realidade aumentada. A libfreenect funciona apenas com o Kinect, não provendo suporte a outros dipositivos que
utilizam a tecnologia de sensores PrimeSense.
Com o crescimento do interesse pelo uso do Kinect, a comunidade da linguagem Processing,
criada por Casey Reas e Ben Fry, ambos do Massachusetts Institute of Technology (MIT), desenvolveu
ports da libfreenect para que o programador possa usufruir de uma sintaxe Java Like, permitindo usar
as pontencialidades do Kinect juntamente com as facilidades oferecidas pela linguagem Java, a qual é
orientada a objetos, tornando invisível ao usuário as dificuldades técnicas do gerenciamento de memória e do uso de ponteiros.
4.2. OpenNI 2.0
A OpenNI (2013) é uma organização sem fins lucrativos, formada pela própria indústria de fabricantes para certificar e promover a compatibilidade e interoperabilidade de equipamentos de interação
natural. Por padrão, ela não possibilita o uso do Kinect, o que é possível por meio do Avin2 Sensor.
O Open Natural Interaction (OpenNI) é um framework que fornece uma API para o desenvolvimento de aplicações que fazem uso de interação natural. Esta API abrange a comunicação com dispositivos de baixo nível (por exemplo, sensores de visão e áudio), bem como soluções de alto nível (por
exemplo, o acompanhamento visual utilizando visão computacional). O framework está escrito e dis-
94
tribuído sob a GNU Lesser General Public License (LGPL), sendo o código fonte livremente distribuído
e disponível ao público em geral.
Em resumo, existem diversos componentes modulares (chamados generators), responsáveis por
diferentes tarefas de deteção e rastreamento. Os componentes são chamados de nó de produção, sendo
classificados em dois tipos: nó de dispositivo e nó de middleware. Os nós de produção de dispositivo
são classificados em cinco tipos: dispositivo, gerador de profundidade, gerador de imagem, gerador de
infravermelho e gerador de aúdio. Os nós de middleware são classificados em quatro tipos: detecção
das mãos, detecção e alerta de gestos, análise de cena e análise do corpo. Estes componentes podem ser
utilizados separados ou em conjuntos.
4.3. NITE 2
O NITE (2013) é um middleware usado pelo framework OpenNI, desenvolvido pela PrimeSense.
Apesar de ter seu código fechado, é gratuito para o uso, podendo ser usado no desenvolvimento de
aplicações comerciais. Ele é responsável por identificar os usuários e rastrear seus movimentos. Os
movimentos rastreados podem ser transformados em gestos, os quais são detectados a partir da sessão
em que o gesto é aguardado e identificado. O middleware prove dois tipos de rastreamento, um para
mãos, capaz de detectar gestos de push, wave, circle etc; e outro para o corpo, que permite rastrear o
corpo todo, fornecendo informações sobre as principais juntas corporais.
4.4. Microsoft Kinect SDK v1.7
O Microsoft SDK (2013) é um conjunto de componentes de desenvolvimento de aplicações que
utilizam o Kinect como meio de interação. É destinado aos sistemas operacionais Windows 7, Windows Embedded Standard 7 e Windows 8 Developer. O SDK fornece suporte para os componentes
de hardware do dispositivo Kinect (câmera RGB, câmera e projetor de infravermelho, vetor de
microfones, motor de inclinação e o acelerômetro de três eixos). É um SDK proprietário, sendo
a distribuição de licença, para o uso comercial, vinculada ao dispositivo Microsoft Kinect para
Windows, estabelecendose a diferença em relação ao Microsoft Kinect para Xbox 360. Segundo
o fabricante, o dispositivo para Windows possui interface USB melhorada, entre outras otimizações.
O suporte para desenvolvimento de aplicações do SDK nas linguagens .NET como, C++, C# ou
Visual Basic, é realizado por meio do módulo Skeletal Tracker (captura do esqueleto do usuário)
e de reconhecimento de voz para utilização em comandos.
5. Aplicações Exemplo
Esta seção apresenta os exemplos práticos de ambientes virtuais sendo controlados por dispositivos PrimeSense. Os exemplos foram desenvolvidos utilizando três linguagens: C/C++, Java e Processing. O exemplo Hand Tracker foi desenvolvido em C/C++, sendo utilizado na interação de um
ambiente do tipo CAVE, o Mini CAVE, provendo ações de translação, rotação e zoom realizadas pelas
95
mãos do usuário. O Skeleton Tracker foi desenvolvido em Java, sendo utilizado na interação de um avatar dentro de um ambiente virtual. O Processing é apresentado como uma terceira solução de desenvolvimento, destacando-se pela facilidade na criação das aplicações. O código completo da aplicação está
disponível para download em : http://laviic.dc.ufscar.br/pre_svr2013.zip
5.1. Rastreamento de mãos
O Hand Tracker é uma aplicação exemplo da NITE a qual possibilita a utilização de gestos gerados pelas mãos do usuário para manipular aplicações computacionais. Nesta seção, uma versão extendida do Hand Tracker é apresentada, sendo utilizada como forma de interação em um Mini CAVE
[Dias, 2012], sendo assim uma interface de entrada para vários ambientes virtuais. A aplicação consiste
em mapear os gestos rastreados para entradas convencionais de teclado e mouse por meio do driver
uinput. O uinput é um módulo do kernel Linux que permite lidar com o subsistema de entrada de
teclado e mouse. Ele pode ser usado para criar e manipular os dispositivos de entrada a partir de uma
aplicação, criando um dispositivo de caracteres em /dev/input. A Figura 2 apresenta o uso do Kinect no
Mini CAVE do LaVIIC (Laboratório de Visualização Imersiva, Interativa e Colaborativa).
Figura 2 – Rastreamento de mãos como meio de interação no Mini CAVE do LaVIIC
Primeiramente, deve-se realizar os includes. O principal include é o XnVSessionManager, responsável por gerenciar a sessão do dispositivo. Os includes XnVWaveDetector, XnVPushDetector e
o XnVCircleDetector, são responsáveis por reconhecer os gestos realizados com as mãos. O include
uinput é responsável pelo driver capaz de mapear os gestos reconhecidos pelo dispositivo para entradas
de teclado e mouse.
96
// Cabeçalhos da NITE e UINPUT
#include <XnVSessionManager.h>
#include "XnVMultiProcessFlowClient.h"
#include <XnVWaveDetector.h>
#include <XnVPushDetector.h>
#include <XnVCircleDetector.h>
#include <linux/uinput.h>
Para utilizar as funcionalidades da OpenNI, deve-se primeiro criar um objeto de contexto e inicializá-lo. Antes disso, o aplicativo não pode obter nenhum dado da OpenNI. A classe de contexto fornece
várias funções de inicialização, por exemplo, xn ::Context::Init() e xn::Context::InitFromXmlFile().
Uma vez que se tem um objeto Context inicializado é possível criar nós de produção. Sempre que um
objeto de xn::ProductionNode é criado, este deve ser associado a um objeto de contexto. No trecho
de código abaixo, o contexto é carregado a partir de um arquivo XML. O Gerador de Sessão está relacionado ao início do processo de rastreamento. Neste exemplo, o rastreamento se inicia depois do
movimento de “Click” e “RaiseHand”, por meio do comando context.StartGeneratingAll().
{
….
xn::Context context;
XnVSessionGenerator* pSessionGenerator;
// Create context
XnStatus rc = context.InitFromXmlFile(SAMPLE_XML_FILE);
// Create the Session Manager
pSessionGenerator = new XnVSessionManager();
rc = ((XnVSessionManager*)pSessionGenerator)->Initialize(&context, "Click", "RaiseHand");
// Inicialização realizada. Gerando entrada.
context.StartGeneratingAll();
}
O trecho de código abaixo apresenta os comandos básicos utilizados para interagir com o ambiente virtual proposto (loader do Mini CAVE). São comandos de teclado e mouse. Os comandos relacionados ao teclado e mouse são: movimentos do ponteiro do mouse (X e Y), botão do centro, botão
direto e botão esquerdo. As teclas W e S do teclado foram utilizadas para efetuar zoom in e zoom out.
int setup_uinput_device()
{
// Botões do mouse
ioctl(uinp_fd, UI_SET_RELBIT, REL_X);
ioctl(uinp_fd, UI_SET_RELBIT, REL_Y);
ioctl(uinp_fd, UI_SET_KEYBIT, BTN_LEFT);
ioctl(uinp_fd, UI_SET_KEYBIT, BTN_MIDDLE);
ioctl(uinp_fd, UI_SET_KEYBIT, BTN_RIGHT);
97
// Teclas do teclado
ioctl(uinp_fd, UI_SET_KEYBIT, KEY_W);
ioctl(uinp_fd, UI_SET_KEYBIT, KEY_S);
return 1;
}
O trecho de código abaixo apresenta o modo como as coordenadas X e Y do Kinect são mapeadas
para as coordenadas do mouse. O Callback efetua a chamada do método move_cursor() sempre que
for detectado um movimento de mão pelo dispositivo PrimeSense. Os dados obtidos a partir do dispositivo são normalizados para uma precisão compatível com a do mouse.
// Cursor do Mouse
void move_cursor(int x, int y )
{
memset(&event, 0, sizeof(event));
gettimeofday(&event.time, NULL);
event.type = EV_REL;
event.code = REL_X;
event.value = x;
write(uinp_fd, &event, sizeof(event));
event.type = EV_REL;
event.code = REL_Y;
event.value = y;
event.type = EV_SYN;
event.code = SYN_REPORT;
event.value = 0;
}
// Callback
void XN_CALLBACK_TYPE OnPointUpdate(const XnVHandPointContext* pContext, void* cxt)
{
move_cursor((int)(pContext->ptPosition.X/40),(int) -(pContext->ptPosition.Y/40));
…
}
A OpenNI também possui um wrapper para a linguagem Processing (2013). Max Rheiner implementou a Simple-OpenNI (2013), um wrapper que combina algumas funcionalidades da OpenNI
e a NITE para a linguagem Processing. Do mesmo modo que o exemplo em C/C++, o primeiro passo
importante para esse experimento é habilitar a camera RGB e o mapa de profundidade a partir da instância do objeto Simple-OpenNI. O código da aplicação Processing está diponível no pacote de código
disponibilizado em: http://laviic.dc.ufscar.br/pre_svr2013.zip.
98
5.2. Rastreamento de esqueleto
O Skeleton Tracker é uma aplicação exemplo presente no pacote da NITE, a qual utiliza o fluxo
para habilitar o gerador de usuários (UserGenerator). Existem callbacks que realizam a detecção dos
usuários. Nas primeiras versões da OpenNI/NITE, para que o usuário fosse detectado, era necessário
que o mesmo estivesse na posição psi. Isso não é mais necessário. O rastreamento retorna a posição e
orientação de uma série de juntas ao longo do corpo, permitindo que avatares possam ser animados.
Os pontos rastreados são: cabeça, pescoço, tronco, cintura, ombros, cotovelos, pulso, mãos, ponta das
mãos, quadril, joelhos, tornozelos e pés.
Este exemplo foi desenvolvido utilizando-se a linguagem Java, sendo uma possível solução de
desenvolvimento, visto que a OpenNI possui bindings para a linguagem Java. Para que o esqueleto do
usuário seja rastreado, é necessário a criação de alguns objetos Java. O UserGenerator é o gerador de
usuário. O SkeletonCapability é responsável por atribuir as capacidades do objeto UserGenerator. O
PoseDetectionCapability é responsável por identificar as juntas do esqueleto rastreado. O objeto skels
é criado a partir da classe SkelsManager, responsável pelas caracterísitcas do esqueleto do usuário.
private UserGenerator userGen;
private Context context;
private SkeletonCapability skelCap;
private PoseDetectionCapability poseDetectionCap;
private SkelsManager skels;
Os objetos OpenNI devem ser inicializados. O trecho de código abaixo apresenta a inicilização
dos objetos. O objeto context é inicializado e utilizado pelo objeto userGen (Gerador de Usuário).
O objeto skels realiza a integração entre o esqueleto rastreado e o avatar que será renderizado pelo
Java3D.
private void configOpenNI()
{
try {
context = new Context();
context.setGlobalMirror(true);
userGen = UserGenerator.create(context);
skels = new SkelsManager(userGen, sceneBG);
context.startGeneratingAll();
System.out.println("Inicializado...");
}
catch (Exception e) {
System.out.println(e);
System.exit(1);
}
}
99
O Skeleton Tracker possibilita o rastreamento de vários usuário simultaneamente. Para cada usuário detectado, um novo ID é gerado. A verificação skelCap.isSkeletonCalibrating(userID) garante
que não ocorram falhas durante a execução do sistema.
// Para cada usuário detectado
public void update()
{
try {
int[] userIDs = userGen.getUsers(); // Vários usuários detectados
for (int i = 0; i < userIDs.length; i++) {
int userID = userIDs[i];
if (skelCap.isSkeletonCalibrating(userID))
continue;
if (skelCap.isSkeletonTracking(userID))
userSkels3D.get(userID).update();
}
}
catch (StatusException e)
{ System.out.println(e); }
}
A classe principal do sistema, a TrackerPanel3D, implementa Runnable, sendo assim executada
por uma thread. Portanto, o método run() recebe as atualizações referentes ao rastreamento e atualiza
o estado do esqueleto renderizado durante toda a execução da aplicação. O código abaixo apresenta
um trecho do método run().
{
isRunning = true;
while (isRunning) {
try {
context.waitAnyUpdateAll();
}
catch(StatusException e)
{ System.out.println(e);
System.exit(1);
}
skels.update(); // get the skeletons manager to carry out the updates
}
A Figura 3 apresenta o Skeleton Tracker sendo utilizado para controlar um avatar dentro de um
ambiente virtual Java3D.
100
Figure 3 – Skeleton Tracker contrlando um avatar em um ambiente virtual Java3D.
A Simple-OpenNI também permite desenvolver aplicações com rastreamento corporal. O método setup() é responsável por inicializar os objetos necessários para que o rastreamento possa ser
realizado.
SimpleOpenNI kinect;
void setup() {
kinect = new SimpleOpenNI(this);
kinect.enableDepth();
kinect.enableUser(SimpleOpenNI.SKEL_PROFILE_ALL);
size(640, 480);
fill(255, 0, 0);
}
O método draw() é um loop infinito da aplicação Processing. O Simple-OpenNI ainda não detecta
automaticamente o usuário, sendo necessário que o usuário esteja na posição psy (PSY Pose). Uma vez
detectada a posição psy, o método getUsers(IntVector) irá retornar a lista de usuários encontrados na
cena. Para este exemplo, a aplicação renderiza somente um usuário, como pode ser visto no trecho int
userId = userList.get(0).
101
void draw() {
kinect.update();
image(kinect.depthImage(), 0, 0);
IntVector userList = new IntVector();
kinect.getUsers(userList);
if (userList.size() > 0) {
int userId = userList.get(0);
if ( kinect.isTrackingSkeleton(userId)) {
drawSkeleton(userId);
}
}
}
6. Conclusões
O desenvolvimento de aplicações que utilizam como base de comunicação os gestos, ou em termos
de Interface Homem Máquina, a comunicação por meio de NUI, são hoje uma realidade. Vários estudos apontam essa tecnologia como uma ferramenta de alta aceitação nas próximas décadas.
Este capítulo apresentou três possíveis bibliotecas de desenvolvimento de aplicações que necessitem utilizar NUI por meio de dispositivos PrimeSense: a libfreenect, a OpenNI e a Microsoft Kinect
SDK v1.7. Foram apresentados exemplos utilizando a OpenNI, por se tratar de uma biblioteca que
provê meios de rastreamento de mãos e corpo de um modo facilitado (nativamente e NITE), e suporte
aos dispositivos PrimeSense (A libfreenect e a Microsoft SDK proveem suporte apenas ao Kinect).
Exemplos em três linguagens diferentes foram apresentados, C/C++, Java e Processing, demonstrando
assim, o quão flexível pode ser o desenvolvimento de aplicações que realizem interação em ambientes
virtuais utilizando os dipositivos PrimeSense.
O Rastreador de Mão (Hand Tracker) integrado com o Mini CAVE possibilita a interação de diversos ambientes virtuais utilizando somente as mãos, bastando apenas que as teclas de interação do
ambientes sejam mapeadas pelo uinput.
O Rastreador de Esqueleto possibilita que o usuário possa caminhar dentro de um ambiente virtual renderizado em Java3D, podendo ser aplicado a qualquer avatar que utilize o mesmo esquema de
juntas descritos no exemplo.
Utilizando Simple-OpenNI, pode-se obter resultados análogos aos alcançados nativamente com
a OpenNI com a simplicidade do Java. Contudo, a Simple-OpenNI não provê todas as funções da
OpenNI 2.0.
Como tendência futura, tem-se também a interação em ambientes virtuais por meio de estímulos
cerebrais. A Neurociência tem realizado pesquisas relacionadas a BCI (Brain Computer Interface),
sendo considerada um canal não muscular de comunicação com o computador.
102
7. Referências
BHUIYAN, M.; PICKING, R. “Gesture-controlled user interfaces, what have we done and what’s next?”,
In: Proceedings of the Fifth Collaborative Research Symposium on Security, E-Learning, Internet and
Networking (SEIN 2009), Darmstadt, Germany, 26-27, 2009.
CHERNSHENG LIN A; ET.AL. “Development of a body motion interactive system with a weight voting
mechanism and computervision technology”. Elsevier, 2011.
DIAS, D. R. C. ; BREGA, J. R. F. ; TREVELIN, L. C. ; POPOLIN NETO, M. ; GNECCO, B. B. ; GUIMARÃES,
M.P. “Design and Evaluation of an Advanced Virtual Reality System for Visualization of Dentistry
Structures”. In: 18th International Conference on Virtual Systems and Multimedia, 2012, Milan. VSMM
2012, 2012. v. 1. p. 1-1.
GHIROTTI S. E.; MORIMOTO C. H. “Um sistema de interação baseado em gestos manuais tridimensionais
para ambientes virtuais”. Departamento de Ciência da Computação, IME/USP.
GNECCO, B. B.; DIAS, D. R. C.; BRASIL, G.J.C.; GUIMARÃES, M. P. “Desenvolvimento de Interfaces
Naturais de Interação usando o Hardware Kinect”. Tendências e Técnicas em Realidade Virtual e
Aumentada, v. 2, p. 37-62, 2012.
Microsoft SDK. Kinect for Windows | Voice. Movement & Gesture Recognition. Disponível em: http://
www.microsoft.com/en-us/kinectforwindows/. Acessado em: março de 2013.
NITE. Middleware PrimeSense. Disponível em: http://www.primesense.com/solutions/nite-middleware/.
Acessado em: março de 2013.
OpenKinect. libfreenect – Github. Disponível em: https://github.com/OpenKinect/libfreenect. Acessado
em: março de 2013.
OpenNI. The standard framework for 3D sensing. Disponível em: http://www.openni.org/. Acessado em:
março de 2013.
PrimeSense. Sensors PrimeSense. Disponível em: http://www.primesense.com/. Acessado em: março de 2013.
Processing. Getting Started with Kinect and Processing - Disponível em: http://www.shiffman.net/p5/
kinect/. Acessado em: março de 2013.
Simple-OpenNI. OpenNI library for Processing. Disponível em: http://www.openni.org/files/
simpleopenni/#.UVCS1KD2a0w. Acessado em: março de 2013.
WEIYUAN, L. “Natural user interface - next mainstream product user interface” Computer-Aided
Industrial Design & Conceptual Design (CAIDCD), 2010 IEEE 11th International Conference on , vol.1,
no., pp.203-205, 17-19 Nov. 2010.
WIGDOR, D.; WIXON, D. “Brave NUI World: Designing Natural User Interfaces for Touch and Gesture”
(1st ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2011.
103
104
GNECCO, Bruno Barberi, et al. Estratégias mistas de mecanismos para imersão
em modelos de interação em ambientes virtuais de treinamento.
Estratégias mistas de mecanismos para imersão
em modelos de interação em ambientes virtuais de
treinamento
Bruno Barberi Gnecco
Rodrigo de Godoy Domingues
Gustavo Jordan Castro Brasil
Diego Roberto Colombo Dias
Luis Carlos Trevelin
Abstract
Virtual environments for training are common in high value industries, such as in flight simulators,
where the cost of equipment and/or the human risks are high. They are being increasily more used and
one of its type, serious games, has established itself in the market. We still have a lot to improve in how we
interact physically with the software. In high cost systems it is possible to reproduce the entire physical interface of the equipment, and use visual, aural and haptic feedback. The simplest systems use only mouse
and keyboard, with which the user can train the concept of the task at hand, but not the physical aspect,
which is a completely differect kind of learning, mapped to other areas of the brain. In this text we show
how interaction and immersion in serious games can be accomplished to enhance the user experience and
engage the physical aspect of training.
Resumo
Ambientes virtuais de treinamento são comuns em indústrias de alto valor agregado, como simuladores
de vôos, onde o custo de um equipamento e/ou o risco humano são altos. Estão sendo cada vez mais usados e sua vertente de serious games tem se estabelecido. No entanto o modelo de interação é ainda um
componente a ser trabalhado. Em sistemas de maior custo é possível reproduzir a interface física do equipamento real, e usar retorno visual, audível e háptico. Sistemas básicos se reduzem a mouse e teclado, o
que auxilia o treinamento mental mas não permite treinar as tarefas físicas, que envolvem uma forma
de aprendizado cerebral distinta. Neste texto mostramos possibilidades de mecanismos de interação com
maior imersão, que permitem envolvimento físico.
104
1. Introdução
Ambientes virtuais de treinamento utilizando abordagem de serious games estão sendo utilizados
cada vez mais para formação, treinamento e educação cientifica sobre situações do mundo real. A fim
de reproduzir um modelo de interação e imersão eficiente sobre uma abordagem com nível de realismo em ambientes virtuais e sistemas de interação, é fundamental desenvolver aplicações semelhantes
ao mundo real. O nível de realismo pode influenciar a uma reação e estratégia esperada diferente no
mundo virtual.
Os mecanismos de interação, como uma interface física de um equipamento real, são elementos
fundamentais para a percepção e ações de estímulos sensoriais como audição, olfato e tato. A modelagem virtual e seus aspectos realistas na simulação da cena, personagens e objetos se tornam afetivos
para a cognição do usuário com o ambiente. Atributos da cena como espaço-tempo, interação e comportamento fazem com que a experiência do usuário se torne mais real. Este capítulo visa demonstrar
as atuais abordagens de uso dos serious games em ambientes virtuais e suas possibilidades de mecanismos de interação com maior nível de imersão, permitindo também o envolvimento físico.
2. Ambientes Virtuais e Sistema de Interação
Ambientes virtuais de treinamento são comuns em indústrias de alto valor agregado, como simuladores de vôos, onde o custo de um equipamento e/ou o risco humano são altos. A segurança proporcionada por tais ambientes também é um chamativo para esse tipo de treinamento, pois se o aluno
efetuar algum erro, este não causará nenhum dano real ao equipamento ou a si mesmo.
Os ambientes virtuais de treinamento podem ser utilizados para, praticamente, todos os tipos de
áreas de aplicação com níveis de complexidade diversos. A característica básica em um ambiente virtual de treinamento é a interação. O ambiente deve prover alto nível de interação, fornecendo feedback
ao usuário e o aprendizado que ele proporciona. O usuário deve ser capaz de realizar o treinamento
quantas vezes for necessário, de modo que o sistema apresente a ele seus resultados, identificando os
erros e indicando a ação correta para um treinamento eficiente.
Morton Heilig, na década de 1950, fez uma das primeiras tentativas a fornecer ao usuário um
ambiente virtual multissensorial [Rheingold, 1992]. O ambiente, chamado Sensorama, era um dispositivo mecânico que apresentava imagens estereoscópicas 3D, movimentação de inclinação do usuário,
reprodução de áudio em estéreo, vento, som e aromas. Ambientes virtuais por muitas décadas foram
restritos a estímulos visuais, táteis e auditivos. No entanto, a utilização de aromas para o estimulo do
olfato tem sido alvo de pesquisas para ambientes de treinamento no manuseio de matérias perigosas,
treinamento de bombeiros, diagnóstico médico, entretenimento e a visualização de processos científicos como reações químicas.
Umas das primeiras aplicações para treinamento auxiliadas pelo uso de ambientes virtuais foram
as cabines virtuais para pilotos. Desde o surgimento da primeira aeronave, surgiu a necessidade de
se treinar os pilotos sem que esses fossem expostos a riscos. Os primeiros simuladores de vôo eram
compostos por cabines com controles mecânicos acionados por ar comprimido. No entanto, somente
a sensação de estar dentro de uma aeronave não é suficiente, sendo necessário conhecimentos prévios
105
de todos os comandos, painéis e procedimentos corretos para cada aeronave. A geração de situações
extremas adversas devem ser treinadas, sendo característica de um bom sistema de treinamento de
vôo. A área médica também tem sido beneficiada por ambientes virtuais de treinamento, pois neste
tipo de treinamento não somente os usuários correm riscos, mas também os pacientes. Hoje em dia,
os futuros médicos são treinados utilizando-se cobaias ou por meio da observação de outros médicos.
Chagas et. al. (2012) propuseram um ambiente virtual de treinamento de operadores de sondas de
perfuração terrestre. Ainda Chagas et. al. (2012) demonstra que um treinamento contínuo para os
trabalhadores é altamente recomendado, assim, no ambiente proposto, os operadores são expostos a
várias circunstâncias nas quais eles podem exercitar seu conhecimento sobre o seu trabalho e aprender
com situações adversas.
3. Serious Games
O termo game ou jogo pode ser definido de várias formas. Comumente o termo é utilizado para
definir uma competição física ou mental, que utiliza um conjunto de regras artificiais com objetivo
a ser alcançado e, na maioria das vezes para diversão dos participantes. Os video-games podem ser
caracterizados por aplicações baseadas em computação gráfica, no entanto, focando o entretenimento
[Machado et. al, 2009].
Os video-games são desenvolvidos para várias plataformas, tais como computadores, consoles e
atualmente smartphones. As plataformas têm suas diferenças e características, como capacidade de
processamento, interface visual e, do utilizador. Os serious games praticados em ambientes virtuais e
sistemas de interação podem ser caracterizados como uma sub-categoria de simulation video-games,
geralmente projetados para simular aspectos da realidade ou ficção; entretanto serious games são desenvolvidos para abordar aspectos de treinamento e não apenas o entretenimento. Contudo, não existe
uma definição precisa para o termo serious games [Machado et. al , 2009]. Segundo Zyda (2005), os
serious games visam simular as situações práticas cotidianas, objetivando proporcionar o treinamento
de profissionais, situações extremas em treinamentos na educação, formação empresarial, saúde, politicas públicas, e os objetivos de comunicação estratégica. Assim, os serious games utilizam as abordagens da indústrias de jogos para tornar as simulações mais atraentes aos usuários [Blackman, 2005].
Segundo Machado et. al. (2009), os primeiros serious games surgiram na década de 80, impulsionados
pelos simuladores desenvolvidos pelos Estados Unidos para a área militar. Eles também afirmam que a
integração entre os serious games e a Realidade Virtual e Aumentada encontra-se na proposta de novas
aplicações e formas de exploração dos recursos computacionais.
Como mencionado, os serious games são aplicados em simulações de situações críticas que envolvam riscos, tomada de decisões ou desenvolver habilidades específicas. Serious games tem sido aplicado na saúde para buscar e modificar o comportamento com cuidados da saúde [Thompson, 2010] e
também na utilização da prevenção de doenças e no alcance de hábitos saudáveis [Baranowski, 2008].
Segundo Tolentino (2011) os serious games aplicados na área da saúde, se obtém representações sobre
o confronto entre a saúde e a doença podendo trazer as pessoas em riscos uma mensagem positiva de
otimismo e perseverança ao usuário. Alguns exemplos de serious games são apresentados a seguir.
106
O ViMeTGame é uma ferramenta proposta para o treinamento de biópsias mamárias utilizando
dispositivos hápticos em ambientes virtuais [Torres et. al, 2012]. A Figura 1 apresenta o ambiente de
execução e a execução do serious games ViMeTGame.
Figura 1 – ViMeTGame [Torres et. al, 2012]
Aplicações para o treinamento de condução de veículos também são utilizadas. O 3D Driving
Academy recria áreas de Paris, Londres e Berlim, aplicando as diferentes leis de trânsitos para cada
local, sendo capaz de emitir o resultado de avaliação do usuário, apresentando as possíveis violações de
leis de trânsito que ele tenha cometido [3D-fahrschule, 2013] a figura 2 apresenta o simulador veicular.
Figura 2 - 3D-Fahrschule - Simulador de condução veicular [3D-fahrschule, 2013]
107
O SGIL Virtual Aircraft Handler é um simulador para o treinamento de pessoas para o manuseio
de aeronaves. Ele pode criar uma experiência de treinamento realista e intensa, por meio de tecnologias
de visualização e interação. O principal benefício do SGIL VIrtual Aircraft Handler é possibilitar, de
forma eficiente e segura, o treinamento de uma tarefa difícil de ser realizada em um local real, isto é,
um aeroporto [Holodeck, 2013]. A Figura 3 apresenta um exemplo do uso do simulador.
Figura 3 - SGIL Virtual Aircraft Handler [Holodeck, 2013]
4. Realismo
Os ambientes virtuais que proporcionam a mesma resposta de percepção como se estivessem realmente presentes na cena real Chalmers et. al (2007) define como there-reality. Na construção de um
ambiente virtual de simulação, as características e aspectos mais relevantes a serem ensinados devem
estar presentes no mesmo. Assim o realismo em serious games tem um papel importante na experiência
dos usuários, pois a exposição em ambientes virtuais inadequados influencia nas estratégias das ações
futuras [Mania et. al, 2003].
Efeitos visuais, sonoros e de interfaces de retorno háptico são bastante utilizados em serious games, mas nem sempre estes estímulos são baseados em algoritmos para reprodução da física adequada.
Segundo Chalmers et .al (2009) o LoR (Levels of Realism) deve ser definido para se alcançar o melhor
mapeamento de uma experiência no ambiente virtual ao mesmo nível de um ambiente real. Yu et. al
(2012), classifica dois tipos de realismo visual que podem ser aplicados em ambiente virtuais: o realismo geométrico e o realismo de iluminação.
Rossou (2004) propôs uma abordagem baseada na utilização de imagens 3D, com intuito de criar
modelos realistas aplicando as fotografias sobre modelos aramados. A Figura 4 um exemplo de aplicação de imagens 3D. A comunidade da CryEngine propôs um concurso Crysis versus Realidade. [Bayer
108
2008] faz sua reprodução a partir da CryEngine na figura 5 apresenta os screenshots demonstrando a
capacidade realista de iluminação e sombra da game engine.
Figura 4 - Aplicação de fotografias sobre modelos virtuais aramados [Roussou, 2004]
Figura 5 - Fotografia Real (esquerda) Computação Gráfica gerado por CryEngine2 (direita) [Bayer, 2008]
5. Modelagem virtual de atributos físicos de cenas reais
O impacto da percepção dos estímulos sensoriais dos ambientes virtuais são evidenciados anteriormente, sendo assim a modelagem de todos os atributos físicos reais para reprodução destes estímulos devem ser considerados.
109
5.1. Game Engines
No desenvolvimento de jogos, o desenvolvedor deve se preocupar com características como arte,
áudio e jogabilidade. O processo de desenvolvimento de jogos possui 3 estágios: pré produção, produção e pós produção. A pré produção está relacionada a ideia e conceitos que o jogo abordará. A
produção está relacionada ao design, programação, produção de arte, áudio e teste. A pós produção
é fase de manutenção e atualização do jogo. É na fase de produção que a base tecnológica para jogos
modernos geralmente é fornecida por uma game engine, o qual auxilia o desenvolvedor no processo
de desenvolvimento de jogos, provendo um grupo de ferramentas visuais e componentes reutilizáveis.
A indústria de jogos demonstra que se utilizam de games engines no processo de desenvolvimento de
seus games [Deloura, 2009].
Um game engine é subdividido em subsistemas: renderer, detecção de colisão, entrada e saída, som
e música, comunicação de rede, gerenciador de dados, inteligência artificial, física e interface gráfica.
O desenvolvimento de jogos, o desenvolvedor deve se preocupar com características como arte, áudio
e jogabilidade. O processo de desenvolvimento de jogos possui 3 estágios: pré produção, produção e
pós produção. A pré produção está relacionada a idéia e conceitos que o jogo abordará. A produção
está relacionada ao design, programação, produção de arte, áudio e teste. A pós produção é fase de
manutenção e atualização do jogo. É na fase de produção que a base tecnológica para jogos modernos
geralmente é fornecida por uma game engine, o qual auxilia o desenvolvedor no processo de desenvolvimento de jogos, provendo um grupo de ferramentas visuais e componentes reutilizáveis. A indústria
de jogos demonstra que se utilizam de games engines no processo de desenvolvimento de seus games
[Deloura, 2009]. A Tabela 1 apresenta alguns games engines e suas compatibilidades.
Tabela 1 - Compatibilidade dos Game Engines
Engine
Windows
GNU/Linux
Android
iOS
Xbox 360
PlayStation
CryEngine3
√
x
x
x
√
√
RAGE Engine
√
x
x
x
√
√
Anvil Engine
√
x
x
√
√
Unreal Engine 3
√
x
x
√
√
√
Blender Game
Engine
√
√
x
x
X
x
Unity3D
√
√
√
√
√
√
O CryEngine 3 é um game engine criado pela empresa Crytec. Ele é multiplataforma, sendo compatível com PC, XBOX 360 e PS3. Na plataforma PC, o CryEngine 3 é compatível com DirectX 9, 10 e
11, sendo um engine com tecnologias gráficas avançadas, física e animação. Dentre as melhorias gráficas, tem-se o sistema de iluminação e sombra, onde o CryEngine 3 proporciona um realismo nunca
provido por outros engines.
110
RAGE, ou Rockstar Advanced Game Engine, foi uma colaboração conjunta entre RAGE Technology Group e Rockstar. RAGE combina uma estrutura de processamento, motor de física, áudio,
bibliotecas de rede, motor de animação e linguagem de script. Algumas dessas características vêm de
outras fontes, como o motor Euphoria (animação) e motor de física Bullet, partes do qual foram integrados ao RAGE.
O Anvil Engine é um game engine multiplataforma desenvolvido pela Ubisoft em 2007. A modelagem do ambiente pode ser feita no 3ds Max e a dos personagens no ZBrush. O Anvil Engine foi
utilizado por alguns jogos na franquia Assassin’s Creed.
O Unreal Engine 3 foi desenvolvido pela Epic Games em 2005, sendo usado pela primeira vez no
game Gears of War, jogo exclusivo do XBOX 360. Ele possui suporte ao PlayStation 3 e XBOX 360.
Houve adição de novas tecnologias no game engine devido as parcerias feitas pela Epic, por exemplo, o
recurso PhysX da NVidia.
O Unity3D Engine é um game engine desenvolvido pela Unity Technologies, sendo a última versão lançada em dezembro de 2012. É um engine multiplataforma, sendo compatível até mesmo com dispositivos móveis e ambientes web. O Unity Engine foi escrito em C/
C++, suportando o desenvolvimento de jogos em outras linguagens, tais como o C# e Javascript.
A Corollarium Tecnologia (2013) está desenvolvendo o Virtuactor, um game engine baseado no Unity3D. Ele permite criar aplicações com interação realizada por Wii Remote e Kinect. É um sistema
dinâmico e desacoplado de regras, de modo a facilitar a arquitetura e desenvolvimento de sistemas de
RV com modelagem comportamental para produção de serious games.
6. Visão geral da interação multi modal e Imersão
6.1. Imersão
Os ambientes virtuais devem ser imersivos e engajadores. Segundo Kirner et. al (2004), a imersão
está relacionada à sensação de estar dentro do ambiente virtual. O uso de dispositivos específicos para
alcançar a imersão é necessário, tais como HMDs e CAVEs. Segundo Childs (2010), alguns dos usuários
de sistemas de Realidade Virtual nunca tiveram uma experiência imersiva completa, outros tiveram
imersão parcial, e alguns poucos tiveram uma imersão total. Ele afirma que apenas utilizar um ambiente
virtual não faz com que o usuário tenha uma experiência imersiva. Childs afirma que 4 fatores são importantes para que um usuário usufrua de imersão em um ambiente virtual: (i) A disposição do usuário
com relação a imersão; (ii) O uso de avatares; (iii) A interação com outros usuários no mesmo ambiente
virtual; (iv) e As características técnicas do ambiente virtual, isto é, o quão próximo do real ele é.
6.2. Mecanismos de interação
Em um ambiente virtual a interação é uma característica importante para uma experiência de
RV com qualidade. Assim, é de extrema importância a satisfação do usuário com relação a interação,
111
com o intuito de aumentar o seu engajamento no ambiente. Diferentes aplicações requerem tecnologias distintas, que vão desde rastreamento corporal por meio de dispositivos de Interface Natural de
Usuário até mesmo a controles convencionais acionados por meio de botões. Ao escolher um meio de
interação, deve-se focar nos seguintes aspectos: possibilidade de replicar os movimentos e ações reais
do usuário, permitindo que ocorra um treinamento do corpo todo e; foco nas ações em si, e não nos
dispositivos utilizados. O usuário deve poder executar as ações do serious game sem precisar perder a
atenção ao jogo em si, portanto elas devem ser simples e naturais comparadas ao ambiente real. Esta
seção apresenta alguma tecnologias e inovações existentes capazes de prover diferentes formas de interação em ambientes virtuais para serious games. A Figura 6 apresenta um exemplo de criação de um
serious game.
Figura 6 - Virtuactor, criação e visualização do serious game [Corollarium, 2013]
6.2.1. Rastreamento por câmeras
Dispositivos de rastreamentos por câmera, tem sido uma das atuais abordagens para interação
pela indústria de games e de abordagens estudas pela linha de Natural User Interfaces [Gnecco et. al,
2012]. Um exemplo proeminente é o dispositivo Microsoft Kinect lançado como sensor de movimento
para o console Xbox 360, jogos onde o usuário se utiliza de gestos, fala e comandos para interagir com
game por sua vez o dispositivo tem sido explorado e aplicado em outras áreas como interface humano
computador, o estudo de caso, do jogo de quebra cabeças o KiPuzzle [Guimarães et. al, 2011] na figura
7, que utiliza como interface o dispositivo Kinect, demonstra que o nível de dificuldade aprendizado
diminui utilizando gestos no qual pode ser aplicado aos serious games.
112
Figura 7 - Jogo de quebra-cabeça KiPuzzle [Guimarães et. al, 2011]
O dispositivo Microsoft Kinect possuí dentre seus componentes uma câmera RGB, sensor de profundidade, vetor de microfones, um motor de inclinação, sensor de voz, e, um acelerômetro de três
eixos e conexão USB 2.0. A Microsoft lançou um Kinect específico para PC, pois os destinados a XBOX
360 não possuem licença para serem utilizados em PCs. A versão para PC, por sua vez, possui um kit
desenvolvimento básico incluso, capaz de suportar gestos e voz em aplicações desenvolvidas para o
sistema operacional Windows.
O dispositivo Microsoft Kinect é baseado em um projeto do sensor PrimeSensor desenvolvido
pela PrimeSense. A PrimeSense detentora da tecnologia PrimeSense Light Coding™ Technology [PrimeSense, 2013] implementa em seus chips a tecnologia de captura de profundidade, cor, e áudio. A captura de profundidade é baseada na reconstrução 3D por luz estruturada: consiste em uma fonte de luz infravermelha (IR) que projeta um padrão de pontos, que são lidos por uma câmera IR monocromática.
A câmera IR captura partes refletidas do padrão de pontos e converte suas intensidades em distâncias.
A empresa ASUS também possui seu sensores a classe Xtion [AsusXtion, 2013] baseado na tecnologia
da PrimeSense Light Coding™ Technology. Atualmente sensores são fabricados também pela PrimeSense dentre eles são o Carmine que possuí duas versões 1.08 e 1.09 a diferença entre as versões está no
range das câmeras infra-vermelho, sendo 0.8m-3.5m no Carmine 1.08, e 0.,5-1.4m no Carmine 1.09
e o CAPRI 1.25 sensor baseado para dispositivos como smartphones, tablets e sistemas embarcados.
O LEAP Motion Controller [LEAP, 2013] é um dispositivo de interação por meio de gestos, sua
principal características é ser focado em uso em desktops para o uso das mãos ou canetas em uma área
de oito metros cúbicos, ele possui três LEDs e duas câmeras infravermelho que são capazes de detectar
movimento em um centésimo de milímetro. Sua conexão de dados é feita por USB 2.0. A tecnologia
de profundidade se baseia também na reconstrução 3D por luz estruturada igualmente ao Microsoft
Kinect. A Figura 9 apresenta o dispositivo Leap Motion Controller.
113
Figura 9 - Leap Motion Controller
Sony PlayStation Move [Move, 2013] é composto pela PlayStation Eye uma câmera RGB comum e
um vetor de microfones semelhante ao dispositivo Microsoft Kinect e o PlayStation Move's motion controller dispositivo que possuí um acelerômetro e um giroscópio de três eixos e conexão Bluetooth 2.0.
O PlayStation Move, possuí uma diferença ao Wii Remote, pode localizar o controlador de movimento
no espaço 3D. A câmera PlayStation Eye reconhece a posição X e Y, bem como o tamanho relativo da
esfera brilhante no controlador de movimento para identificar a localização do controlador referente a
distância entre o dispositivo e o usuário.
6.2.2. Joysticks
O uso, de Joysticks, pode trazer uma interface mais próxima do treinamento e que promovem a
utilização de botões para simulação artificial dos comandos, assim, o nível de aprendizado da reprodução dos comandos aumenta e, deve se focar nos resultados do usuário com a interface. Um exemplo
é um manche avião muitas empresas de dispositivos de entrada para games tendem a aproximar o
modelo de seus joysticks o mais próximo do real.
A utilização de controles e joysticks pela indústria de games para reprodução de interface de armas
e volantes para direção tem se destacado um exemplo proeminente é o Wii Remote [WiiRemote, 2013]
um controle desenvolvido pela Nintendo para o console Wii. Segundo a Nintendo, o controle foi uma
revolução na forma de jogar, pois, diferente de controles convencionais, ele capta os movimentos do
usuário por meio de acelerômetros e sensor infra vermelho. O Wii Remote possui uma extensão para o
Nunchuk, sendo esse um controle analógico que se encaixa anatomicamente na mão do usuário. O Wii
Remote e o Nunchuk podem ser utilizados simultaneamente. Aplicações e ambientes de realidade virtual tem se utilizado o Wii Remote. Dias et al (2012), utiliza o Wii Remote como meio de interação em
um ambiente de ensino de odontologia. A Figura 10 apresenta o ambiente de ensino. Por possuir uma
interface de conexão bluetooth, pode ser facilmente conectado a um computador. As possibilidades de
desenvolvimento são diversas, possuindo bindings em C/C++, Java e Python.
114
Figura 10 - O uso do dispositivo Wii Remote na miniCAVE do grupo LaVIIC [LaVIIC, 2013]
6.2.3. Luvas
As luvas são capazes de prover o rastreamento de movimentos intuitivos de toque, apontamento
e manipulação de objetos em um ambiente virtual. Alguns modelos de luvas permitem ao usuário a
sensação de feedback, isto é, toda interação que o usuário realizar em um ambiente virtual pode gerar
alguma sensação de retorno ao mesmo. São três os possíveis feedback: tátil, força ou térmico. O feedback tátil possibilita ao usuário sentir a determinada textura do objeto que está sendo manipulado. O
feedback de força oferece resistência a manipulação do usuário, por exemplo, quando o usuário efetua
o movimento de pegar uma caixa, a luva deve prover alguma resistência, de modo que o usuário realmente tenha a sensação de estar segurando algo. O feedback térmico permite que o usuário tenha
sensações referentes a temperatura do objeto que está sendo manipulado.
Existem diversas luvas de dados no mercado, porém, uma das mais utilizadas é a 5DT Data Glove
[Glove]. Esta luva é capaz de capturar movimentos das mãos do usuário para serem utilizados em
animações ou ambientes virtuais. Sua interface de comunicação é USB, tendo a possibilidade de ser
conectada por uma interface sem fio comercializada separadamente. A 5DT é comercializada em dois
modelos, o que difere os modelos é a quantidade de sensores, o que tem influência diretamente na
precisão de detecção dos movimentos.
As luvas de dados são utilizadas em ambientes que necessitam de rastreamento precisos das mãos.
Marca et. al (2011) desenvolveu um sistema de treinamento de LIBRAS (Língua Brasileira de Sinais), o
qual utiliza luvas de dados para obter o rastreamento dos dedos do usuário; o movimento dos braços
são rastreados por meio de Wii Remotes acoplados nos braços do usuário. A Figura 11 apresenta o
Sistema de Treinamento de LIBRAS.
115
Figura 11 - Sistema de Treinamento de LIBRAS [Marca et. al, 2011]
6.2.4. Aromas
Aromas, podem potencializar as ações e experiências do jogo, trazendo odores naturais do ambiente. Segundo Washburn (2004) o olfato pode desempenhar um papel crucial em ambientes virtuais
de treinamentos, um exemplo é no treinamento de bombeiros. Ainda Washburn (2004) cita que os atuais ambientes virtuais possuem sistemas avançados de saída de áudio e vídeo para imersão visual, mas
para o aroma é muito limitado e/ou ausente. A reprodução de um aroma pode desencadear excitação,
medo e muitas outras emoções. Adicionando estas reproduções aos serious games se visa criar uma
experiência de treinamento mais realista.
O dispositivo ScentWave cria experiências de aromas e pode ser utilizado em ambientes virtuais,
possuí tecnologia de ar seco sem a utilização de aerossóis ou óleo, sua duração e intensidade podem ser
configuradas. Ele possuí um detector de movimento de até 8 metros distância. Cada ScentWave é carregado com um cartucho de perfume que é incorporado com uma fragrância. Estes cartuchos podem
ser facilmente substituídos, permitindo que você altere aromas para coordenar com novos ambientes.
A empresa AromaJet criou um protótipo sistema de geração de aroma o Pinoke. Eles demonstraram que a tecnologia pode ser um dispositivo para o usuário de games. Utilizando uma linguagem de
programação para gerar eventos para emissão do gerador de aromas.
Pesquisadores da University of Southern California’s ICT em colaboração com a empresa AnthroTronix Inc, tem realizado pesquisas de sensores para ambientes imersivos, e desenvolveram um
projeto de um dispositivo de estimulação olfativa. O dispositivo chamado ICT Scent Collar o colar tem
intensidade ajustável para o controle da quantidade e a duração do aroma liberado sua interface de
comunicação é via Bluetooth.
116
7. Análise e feedback aos usuários
Além da segurança e menor custo, outra grande vantagem de usar serious games ao invés de equipamentos reais é a possibilidade de monitorar detalhadamente o desempenho do usuário. Isso permite
rever as sessões de treinamento, identificar problemas e treinar os aspectos mais deficitários do usuário.
Para isso é importante ter um sistema de relatórios, visualização de resultados e até mesmo poder assistir novamente as sessões dos usuários, para verificar falhas e poder aprender com elas. Um serious
game que não tenha estas informações cumpre mal seu propósito, pois não permite quantificar qual o
conhecimento do usuário, qual sua taxa de aprendizado, quais seus erros mais comuns. Não permite
também verificar que as pessoas estão acessando o sistema e usando-o. Dentre os relatórios desejados
temos relatórios gerais do sistema, como relatórios de acesso, assim como relatórios de desempenho
dos usuários, e relatórios comparativos entre usuários. Alguns dados importantes para estes relatórios:
• Quantidade de acessos, por usuário e global do sistema. É importante para verificar se o
sistema está sendo usado por todos na taxa esperada.
• Tempo de uso do sistema por cada usuário: pode ser medido por simulação, verificando o
tempo médio dela, e agregado por mês, notando quantas horas de treinamento cada usuário
recebe.
• Roteiros treinados: serious games podem apresentar vários roteiros ou cenários diferentes,
cada um explorando um determinado aspecto ou problema. É preciso verificar quais Permite
também quantificar quais os roteiros mais usados e menos usados.
• Execução do roteiro: data do teste, usuário e roteiro utilizado são informações básicas. É
preciso também anotar coisas como etapas corretas, etapas esquecidas, etapas feitas fora de
ordem, etapas feitas incorretamente. Baseado no tempo esperado, pode-se quantificar a eficiência da operação, com um gráfico do tempo gasto nas diferentes etapas do processo.
• Relatórios agregados: em empresas grandes com diversos usuários é importante gerar relatórios agregados, que mostrem resultados por área geográfica, por roteiro, por tipo de equipamento simulador, etc. Isso permite identificar onde estão os principais problemas correntes
para concentrar as simulações nele.
• Cruzar informação de treino com informações reais: se determinado equipamento possui
uma taxa maior de erros no seu uso real, deve-se aumentar o treinamento dele. É importante
poder cruzar os dados reais com os virtuais para identificar estas necessidades.
• Relatórios históricos: permitem acompanhar a melhora de desempenho dos usuários ao longo do tempo, demonstrando a eficácia do treinamento ou verificando que certos problemas
persistem e precisam ser lidados.
8. Conclusão
Serious games estão cada vez mais populares. Com as atuais possibilidades de imersão e interação,
eles permitem um maior engajamento do usuário e uma simulação mais realista e condizente. Este
capítulo apresentou possíveis formas de interação a serious games visando melhorias com relação à
imersão dos usuários nessas aplicações.
117
Foram apresentadas diferentes tecnologias, desde dispositivos que fazem o uso de Interface Natural de Usuário, até mesmo joysticks, que fazem uso de botões artificiais. Existe diferença com relação
ao custo desses dispositivos. Alguns, tais como as luvas de dados, são mais caros que os outros, por
exemplo, o Wii Remote. Contudo, deve-se definir qual o tipo de interação necessária a aplicação que
será desenvolvida, para que o dispositivo correto possa ser escolhido.
Existe também a possibilidade de combinar diferentes dispositivos, por exemplo, pode-se efetuar
o rastreamento do esqueleto do usuário com um Kinect, e, ao mesmo tempo, obter dados referentes aos
dedos do usuário utilizando uma luva de dados. Aplicações, tal como o treinamento de linguagem de
sinais, necessitam desse tipo de combinação de rastreamento, visto que dispositivos por rastreamento
de rastreamento de câmeras como o Kinect não são capazes de rastrear, com precisão, os dedos.
Como foi afirmado, o usuário deve efetuar o treinamento quantas vezes for necessário, mas com
um acompanhamento efetivo de seu aproveitamento. Isso permite verificar as falhas e problemas e
corrigi-los rapidamente.
Com relação aos efeitos visuais, os game engines têm se destacado. O uso de tal tecnologia garante
desempenho, qualidade gráfica e alta produtividade. Como apresentado na seção 5, existem alguns
game engines que possuem compatibilidade com várias plataformas. Assim, o desenvolvimento de serious games criados a partir da combinação de game engines e a interação por meio de dispositivos
como os que foram apresentados, permite a criação de aplicações de simulação e treinamento cada vez
mais realistas, e explorando a cognição dos usuários.
Referências
RHEINGOLD, H. (1992). “Virtual Reality”, Simon & Schuster, New York, N.Y.
CHAGAS, J.F.S.; NETO, F.M.M.; BONATES, M.F.; BRASIL, I.S.; LIMA, R.M. (2012) “Um Jogo para
Treinamento de Operadores de Sondas de Perfuração Terrestre”, Ano 28, Vol 1, 2012.
MACHADO, L.S.; MORAES, R.M.; MARQUES, F.L.S.N. (2009). “Serious Games para Saúde e Treinamento
Imersivo”, In: Fátima L. S. Nunes; Liliane S. Machado; Márcio S. Pinho; Cláudio Kirner. (Org.). Abordagens
Práticas de Realidade Virtual e Aumentada. Porto Alegre: SBC, 2009, v. , p. 31-60.
ZYDA, M. (2005) "From visual simulation to virtual reality to games," In: Computer , vol.38, no.9, pp.25,32,
Sept. 2005
BLACKMAN, S. (2005). “Serious games...and less!” In: SIGGRAPH Comput. Graph. 39, 1 (February
2005), 12-16.
THOMPSON, D; BARANOWSKI, T; BUDAY, R; BARANOWSKI, J.; JAGO, R.; GRIFFITH, M. J. (2010)
”Serious Video Games for Health: How Behavioral Science Guided the Development of a Serious Video
Game” In: Simulation & Gaming, vol. 41, no. 4, pp. 587–606, 2010.
BARANOWSKI,T.; BUDAY, R.; THOMPSON, D. I; BARANOWSKI, J. (2008) “Playing for Real Video
Games and Stories for Health-Related Behavior Change” Am J Prev Med, vol. 34, no.1, pp. 74–82, 2008.
118
TOLENTINO, G.P.; BATTAGLINI, C.; PEREIRA, A.C.V.; DE OLIVERIA, R.J.; DE PAULA, M.G.M. (2011)
"Usability of Serious Games for Health," Games and Virtual Worlds for Serious Applications (VS-GAMES),
2011 Third International Conference on , vol., no., pp.172,175, 4-6 May 2011
TORRES, R.S. ; BISCARO, H. H. ; ARAUJO, L. V. ; NUNES, F. L. S. (2012) “ViMeTGame: A serious game
for virtual medical training of breast biopsy”. SBC Journal on 3D Interactive Systems, v. 3, p. 12-19, 2012.
3D-fahrschule. “3D Driving Academy”. Disponível em: http://www.3d-simulator.de/. Acesso em: março
de 2013.
HOLODECK. “Holodeck Technology” (2013) Disponível em: http://www.seriousgamesinternational.com/
products/-Holodeck.aspx. Acesso em: março de 2013.
CHALMERS, A.; DEBATTISTA,K.; MASTOROPOULOU,G.; DOS SANTOS, L. (2007) “There-Reality:
Selective Rendering in High Fidelity Virtual Environments” In: The International Journal of Virtual
Reality, vol. 6, no. 1, pp. 1–10, 2007.
MANIA, K; TROSCIANKO, T; HAWKES,R; CHALMERS, A. (2003). “Fidelity metrics for virtual
environment simulations based on spatial memory awareness states”. Presence: Teleoper. Virtual Environ.
12, 3 (June 2003), 296-310
CHALMERS, A.; DEBATTISTA, K. (2009) "Level of Realism for Serious Games," Games and Virtual
Worlds for Serious Applications, 2009. VS-GAMES '09. Conference in , vol., no., pp.225,232, 23-24 March
2009
YU, I; MORTENSEN, J.; KHANNA, P.; SPANLANG, B.; SLATER, M. (2012) "Visual Realism Enhances
Realistic Response in an Immersive Virtual Environment - Part 2," In: Computer Graphics and Applications,
IEEE , vol.32, no.6, pp.36,45, Nov.-Dec. 2012
ROUSSOU, M.; DRETTAKIS, G.; TSINGOS, N.; RECHE, A.; GALLO, E. (2004) "A user-centered approach
on combining realism and interactivity in virtual environments," Virtual Reality, 2004. Proceedings. IEEE,
vol., no., pp.251,252, 27-31 March 2004
BAYER, T. “Screenshot contest: Crysis versus Reality” (2013). Disponível em: http://www.
pcgameshardware.com/aid,645624/Screenshot-contest-Crysis-versus-Reality/Imagegallery/&article_
id=645624. Acesso em: março de 2013.
DELOURA, M. "The engine survey: Technology results" - GamaSutra Experts Blogs (2009) Disponível
em: http://www.gamasutra.com/blogs/MarkDeLoura/20090316/903/The_Engine_Survey_Technology_
Results.php, 2009. Acesso em: março de 2013
KIRNER, C.; ROMERO, C. 2004 “Realidade Virtual: Conceitos e Tendencias”. 1 ed. São Paulo: Editora
Mania de Livro, 2004, v. 1, p. 43-59.
Corollarium. “Corollarium Techonologies” (2013). Disponível em: http://corollarium.com/. Acessado em:
março de 2013.
119
CHILDS, M. (2010) “Learners’ Experience of Presence in Virtual Worlds”, PhD Thesis, University of
Warwick, Coventry, UK. 2010.
GNECCO, B. B. ; DIAS, D. R. C. ; BRASIL, G. J. C. ; GUIMARÃES, M. P. (2012) “Desenvolvimento de
Interface Naturais de Interação usando o hardware Kinect” In: XIV Simpósio de Realidade Virtual e
Aumentada - Tendências e Técnicas em Realidade Virtual e Aumentada, v. 2, p. 1-264, 2012
GUIMARÃES, M. P. ; BRASIL, G. J. C. ; SALVADOR, V. F. M. ; TREVELIN, L. C. (2011) “Um Modelo
de Processo de Desenvolvimento de Interfaces de Gesto: Definição e um Estudo de Caso”. In: XXXVII
Conferencia Latinoamericana de Informática (XXXVII CLEI), 2011, Quito.
PrimeSense. “Technology - PrimeSense” (2013). Disponível em: http://www.primesense.com/solutions/
technology/. Acesso em: março de 2013
AsusXtion. “ASUS - Xtion” (2013). Disponível em: http://www.asus.com/Multimedia/Xtion/. Acesso em:
março de 2013
LEAP. “Leap Motion” (2013). Disponível em: https://www.leapmotion.com/product. Acesso em: março
de 2013
Move. “Sony PlayStation® Move” (2013). Disponível em: http://us.playstation.com/ps3/playstation-move/.
Acesso em: março de 2013
WiiRemote. “Wii Remote” (2013). Disponível em: http://www.nintendo.co.jp/event/e3_2006/wii/
controller.html. Acesso em: março de 2013
DIAS, D. R. C. ; BREGA, J. R. F. ; TREVELIN, L. C. ; POPOLIN, M.N ; GNECCO, B. B. ; GUIMARÃES,
M. P. (2012) “Design and Evaluation of an Advanced Virtual Reality System for Visualization of Dentistry
Structures”. (2012) In: 18th International Conference on Virtual Systems and Multimedia, 2012, Milan.
VSMM 2012, 2012. v. 1. p. 1-1.
LaVIIC. “LaVIIC · Laboratório de Visualização, Imersiva, Interativa e Colaborativa” (2013). Disponível em:
http://laviic.dc.ufscar.br . Acesso em: março de 2013
Glove. “5DT DAta Glove Ultra Series” (2013). Disponível em: www.5DT.com. Acesso em: março de 2013.
MARCA, A. F. L. ; BREGA, J. R. F ; DIAS, D. R. C. (2011) “Rastreamento Corporal através de Dispositivos
não Convencionais”. In: WRVA 2011, 2011, Uberlândia - MG. Anais do WRVA 2011, 2011. v. 1.
WASHBURN, D.A.; JONES, L.M. (2004) "Could olfactory displays improve data visualization?" In:
Computing in Science & Engineering , vol.6, no.6, pp.80,83, Nov.-Dec. 2004
120
121
CORRÊA, Cléber Gimenez, et al. Avatares baseados em vídeo e suas aplicações em sistemas virtuais imersivos.
Avatares baseados em vídeo e suas aplicações em
sistemas virtuais imersivos
Cléber Gimenez Corrêa
Silvio Ricardo Rodrigues Sanches
Daniel de Andrade Lemeszenski
Daniel Makoto Tokunaga
Romero Tori
Abstract
The use of avatars generated from video, or simply video-avatars, has as goal to provide for users of Augmented Reality systems, more realistic experiences. Applications that use this type of avatar have been
explored by scientific community and, recently, systems based in this type of technology started being
found in the market. In this context, the goal of the present chapter consists in the presenation of the process of video-avatars generation, as well as the applications in the academic and commercial domains .
Resumo
A utilização de avatares gerados a partir de vídeo, ou simplesmente vídeo-avatares, tem como objetivo
proporcionar aos usuários de sistemas de Realidade Aumentada, experiências mais realistas. Aplicações
que utilizam esse tipo de avatar há algum tempo têm sido exploradas pela comunidade científica e, recentemente, sistemas que se baseiam nesse tipo de tecnologia começaram a ser encontrados também no
mercado. Inserido nesse contexto, o objetivo do presente capítulo consiste na apresentação do processo de
geração de vídeo-avatares, bem como suas aplicações nos âmbitos acadêmico e comercial.
1. Introdução
Originalmente, na mitologia hindu, o termo avatar fazia referência à forma de manifestação corporal de um ser sobre-humano [Sheth 2002]. No contexto dos ambientes virtuais, o termo foi empregado pela primeira vez no sistema multiusuário Habitat [Morningstar e Farmer 1991], em que figuras
animadas em tempo real, controladas por usuários, podiam praticar várias ações dentro de um ambiente [Sanches et al. 2009].
A popularização do termo, no entanto, aconteceu apenas na década de 1990 com a publicação do
livro de ficção científica “Snow Crash” [Allbeck e Badler 1992]. Muitas das características descritas na
121
obra como pertencentes aos personagens denominados avatares eram semelhantes às dos humanos
virtuais, criados para os sistemas de Realidade Virtual da época.
Com o objetivo de tornar os avatares mais realistas, os modelos bidimensionais, como os do Habitat, foram sendo substituídos por representações tridimensionais com níveis elevados de detalhes
[Takashima et al. 2008]. Apesar da relativa sofisticação desses modelos, existem algumas características humanas difíceis de serem reproduzidas com fidelidade [Ogi et al. 2001]. A exatidão de movimentos, como a naturalidade de gestos, expressões faciais e emoções são exemplos dessas características
[Corrêa et al. 2011].
Segundo Ogi et al. (2001), um vídeo-avatar consiste em uma imagem tridimensional sintetizada
por computador, gerada a partir de vídeo capturado em tempo real. Outras definições, no entanto, o
definem como uma representação virtual – não necessariamente tridimensional – baseada na imagem
de um usuário humano, obtida por meio de um dispositivo de aquisição de vídeo e atualizada em tempo real [Nakamura 2008].
A utilização de imagens de vídeo, ainda que sejam bidimensionais, pode proporcionar maior realismo ao ambiente 3D, desde que o avatar se mostre integrado ao ambiente [Hauber et al. 2005]. Várias
são as técnicas empregadas na geração de avatares, que podem ser construídos na forma plana [Corrêa
et al. 2011], semi-plana [Corrêa et al. 2011, Tokunaga et al. 2009] ou tridimensional [Shin et al. 2010,
Kanade e Narayanan 2007, Goldlucke e Magnor 2003, Prince et al. 2002, Tamagawa et al. 2001].
Inserido nesse contexto, os objetivos do presente capítulo são: i) descrever aplicações computacionais, desenvolvidas nos âmbitos acadêmico e comercial, que empregam a abordagem de vídeo-avatar e
ii) apresentar, de forma simplificada, o processo de geração de vídeo-avatares.
Para que favoreça seu entendimento, este capítulo está organizado da seguinte forma: a seção 1.2
descreve o processo geral de geração de avatares baseados em vídeo; as seções 1.3 e 1.4 apresentam
aplicações que empregam a abordagem de vídeo-avatar nos âmbitos comercial e acadêmico, respectivamente; e, finalmente, na seção 1.5, são expostas as conclusões.
2. Processo geral de geração do vídeo-avatar
De uma forma geral, o processo de geração de um avatar baseado em vídeo pode ser descrito em
etapas. São elas: aquisição ou captura de informações do mundo real, no qual está inserido o usuário;
segmentação, em que se remove o fundo do ambiente real para isolar a região que contém o usuário; e
síntese, que trata da composição da representação o usuário.
As subseções 1.2.1, 1.2.2 e 1.2.3 detalham as etapas mencionadas, identificando equipamentos e
técnicas normalmente empregadas, bem como suas vantagens e desvantagens.
2.1. Aquisição de informações do ambiente real
A aquisição é a etapa que envolve, além da captura de vídeo do usuário no ambiente real, informações adicionais, como a profundidade de cada pixel das imagens que compõem o vídeo e o áudio.
Apesar da importância do áudio, no presente capítulo, somente as informações relacionadas a imagens
122
e profundidade serão enfatizadas. As informações adicionais normalmente referem-se a profundidade
dos pixels das imagens, sendo que o conjunto das profundidades forma o denominado mapa de profundidade.
Deve-se ressaltar que uma aquisição de vídeo de qualidade é de grande importância, visto que
uma captura adequada elimina ou minimiza a necessidade de algoritmos complexos, como os de processamento de imagens, geralmente empregados para correção de erros provenientes da aquisição
[Magnor et al. 2005].
Um aspecto relevante na aquisição de informações é a natureza dos equipamentos adotados na
captura, o que determina o tipo de infraestrutura do sistema. Há infraestruturas de baixo custo, caracterizadas pela utilização de câmeras monoculares (consideradas dispositivos convencionais) [Corrêa et
al. 2011, Shin et al. 2010, Hämäläinen et al. 2005, Kauff e Schreer 2002], como webcams, por exemplo.
Entretanto, como diversas técnicas utilizadas na etapa de síntese de geração de vídeo-avatares
requerem informações adicionais, infraestruturas mais elaboradas se fazem necessárias. Tais infraestruturas podem ser compostas por múltiplas câmeras ou equipamentos especiais. Exemplos de infraestruturas de captura são: duas câmeras calibradas, para uma captura binocular [Kanade e Narayanan
2007, Ogi et al. 2001]; mais de duas câmeras, para a captura do usuário de diferentes ângulos [Shin et
al. 2010, Kanade e Narayanan 2007, Kim et al. 2007, Lee et al. 2004, Goldlucke e Magnor 2003, Koyama
et al. 2003, Gross et al. 2002, Tamagawa et al. 2001, Ogi et al. 2001] e, dispositivos com sensores específicos ou equipamentos especiais [Jones et al. 2009, Tokunaga et al. 2009a, Tokunaga et al. 2009b, Rhee
et al. 2007, Lee et al. 2005].
As duas primeiras formas podem necessitar de calibração dos equipamentos, uma tarefa considerada trabalhosa para que técnicas como a triangulação [Ohta e Kanade 1985] possam ser aplicadas
para criar o mapa de profundidade. Quando se utiliza equipamentos baseados em sensores ativos, a
sincronização do sensor com a imagem também se faz necessária.
Sensores ativos emitem sinais do tipo TOF (Time of Flight) [Rhee et al. 2007], permitindo a
utilização de técnicas como luz estruturada [Jones et al. 2009] para determinar o mapa de profundidade.
Os sinais atingem o usuário refletindo para o equipamento uma parede de luz que permite o
carregamento de uma impressão do usuário [Iddan e Yahav 2001].
Uma das técnicas de captura de profundidade se baseia em luz estruturada. Essa abordagem consiste no uso de uma fonte emissora de um padrão de luz pré-definido sobre o objeto de interesse para
em seguida capturar imagens do objeto iluminado por esse padrão [Will e Pennington 1971]. Dessa
forma, o mapa de profundidade é calculado por meio da correspondência entre o padrão original e o
padrão projetado sobre o modelo.
123
Figura 1.1. Arranjo de equipamentos na técnica de luz estruturada convencional.
Esse padrão é gerado por um equipamento emissor de luz, por exemplo, um projetor convencional, conforme apresentado na Figura 1.1, ou um LED especializado como é feito no caso do Kinect.
Cada padrão é constituído por uma sequência de códigos, dessa forma, cada ponto da superfície do
objeto recebe um código que o identifica dentro do padrão. Assim, é obtido um mapeamento direto
entre os códigos e as coordenadas (x,y) correspondentes de cada ponto do objeto.
Outras formas de aquisição envolvem a utilização de múltiplos equipamentos especiais [Lemeszenski e Nakamura 2011].
2.2. Segmentação
A etapa de segmentação consiste na tarefa de extrair, a cada quadro do vídeo, a imagem do elemento de interesse – nesse caso, uma pessoa – do seu contexto original para que esse elemento possa
ser utilizado na geração do avatar [Sanches et al. 2012].
Uma característica comum a maioria dos sistemas que constroem avatares é que a segmentação
é executada em ambientes controlados, onde a cena pode ser manipulada para que uma cor constante
seja exibida como fundo [Tokunaga et al. 2009, Lee et al. 2004, Tamagawa et al. 2001], reproduzindo a
técnica do chroma-key [Gibbs et al. 1998]. Na Figura 1.2 são apresentados o usuário no ambiente real e
o avatar após a etapa de segmentação, inserido no ambiente virtual. Desse modo, o elemento de interesse pode ser isolado de forma precisa.
Uma técnica também utilizada na segmentação de vídeo para geração de avatares é a subtração de
fundo [Piccardi 2004], que consiste, basicamente, na comparação do quadro atual com um modelo do
fundo da cena. Em aplicações que utilizam equipamentos especializados [Kanade e Narayanam 2007,
Tamagawa et al. 2001], que geram mapas de profundidades, tal informação pode ser utilizada para
auxiliar a segmentação.
124
Figura 1.2. Segmentação do avatar [Sanches et al. 2009].
2.3. Síntese
A etapa de síntese pode ser dividida em geração do modelo geométrico a partir das informações
adquiridas, como por exemplo, o mapa de profundidade; e renderização deste modelo.
2.3.1. Modelagem
Existem diversos aspectos referentes a representação geométrica de um avatar. O principal está relacionado à forma geométrica, envolvendo modelos planares, 2,5D ou 3D. Na abordagem mais simples,
o avatar é representado por um plano no qual é projetada a imagem 2D do usuário. O modelo 2,5D é
caracterizado pela representação parcial do usuário, como uma imagem e mapa de profundidade obtidos de determinado ângulo do usuário. Na abordagem completa, é gerado um modelo 3D do usuário,
por meio de um estúdio composto por várias câmeras posicionadas ao seu redor.
Uma técnica utilizada para evitar que o usuário perceba que a representação do avatar é um único
plano é o switching planes [Insley et al. 1997]. Nessa abordagem o apresentador é filmado por diversas
câmeras posicionadas em ângulos distintos, dessa forma, um usuário ao se mover pelo ambiente virtual visualizará o vídeo capturado pela câmera com ponto de vista mais próximo do seu ângulo.
Outra técnica de modelagem, considerada uma das técnicas mais utilizadas em sistemas imersivos,
é a técnica de visual hull [Prince et al. 2002, Kanade e Narayanan 2007, Lee et al. 2005]. Essa técnica
baseia-se na reconstrução por shapes from silhoutte, inicialmente proposta por Laurentini (1994), permitindo a representação tridimensional do usuário por meio de silhuetas capturada em diversos ângulos.
2.3.2. Renderização
Na renderização de vídeo-avatares diversas técnicas podem ser adotadas, sendo o desempenho
considerado como um fator importante. Para esse tipo de aplicação é necessário que o processamento
seja em tempo real.
125
Um termo normalmente utilizado no contexto de renderização de objetos é a chamada nuvem de
pontos, que consiste em dados que representam voxels ou mapa de profundidade de um conjunto denso
de pontos espaciais amostrados de um determinado objeto de interesse.
Uma forma performática de visualizar nuvens de pontos que contenham informação referente a
cor de cada vértice é a renderização de pontos desconectados (Figura 1.3.), sem utilizar malha de polígonos. Essa técnica consiste na varredura da matriz de pontos por linha e coluna e desenhar um ponto
para cada vértice com a informação RGB (Red, Green, Blue) correspondente.
Figura 1.3. Renderização de uma nuvem de pontos sem mesh em (a) e imagem ampliada em (b).
Outra abordagem aplicável em tempo real é a técnica de microfacet billboarding [Yamazaki et al.
2002]. Nessa técnica são renderizadas micro-facetas planas que são posicionadas paralelamente ao plano onde se encontra a câmera, causando uma redução de frestas entre os pontos renderizados.
Partindo para a utilização de malhas de polígonos, que exige um maior esforço computacional do
que as técnicas de renderização de pontos desconectados, são encontrados diversos algoritmos de renderização de superfície que tem uma nuvem de pontos como entrada e uma malha poligonal como saída.
As técnicas de tecelagem com malha de triângulos são as mais utilizadas, pois a maior parte das
GPUs (Graphics Processor Unit) e APIs (Application Programming Interface) são customizadas para
manipular triângulos [Moller et al. 2008]. Como implementações dessa classe de técnicas destacam-se
os algoritmos de cubos marchantes [Lorensen e Cline 1987], de ball-pivoting [Bernardini et al. 1999] e
de Poisson [Kazhdan et al. 2006].
O algoritmo de cubos marchantes divide a nuvem de pontos em camadas (linhas) e para cada duas
camadas adjacentes obtém oito vértices, quatro de cada camada, que constituirão um cubo lógico. O
algoritmo encontra qual o padrão de triângulos será renderizado por meio da análise de como a superfície intersecta o cubo, comparando os valores de cada vértice do cubo com um conjunto de padrões de
triângulos pré-estabelecidos para construção da malha.
O algoritmo de ball-pivoting é iniciado em um vértice raiz p e gera um triângulo somente se a
esfera com raio R toca exclusivamente três pontos. Então essa esfera se move em relação a uma aresta
126
em busca de outro ponto para gerar outro triângulo vizinho e a tecelagem prossegue até que todas as
arestas formadas sejam visitadas.
O algoritmo de Poisson para renderização de superfícies é uma técnica de malha poligonal com
grande resistência a ruídos em nuvens de pontos. Primeiramente, cada ponto é classificado por meio
de uma função que indica se o ponto pertence à área interna do modelo (atribuindo o valor 1) ou à área
externa (valor 0). Com isso, é reconstruído o modelo geométrico pelo cálculo da iso-superfície.
3. Exemplos de aplicações comerciais
No mercado, existem empresas que oferecem sistemas (hardware e software) para geração de vídeo-avatares, atuando em áreas como esportes, industrial e teleconferência imersiva.
Na presente seção, produtos deste tipo oferecidos por duas empresas, 4D View Solutions e a DVE
(Digital Video Enterprises), serão descritos. A empresa 4D View Solutions oferece sistemas para captura de
informações, com softwares para calibração e sincronização de imagens obtidas a partir de múltiplos equipamentos, podendo ser utilizados em aplicações das áreas industrial (Figura 1.4) e esportiva (Figura 1.5).
Figura 1.4. Aplicação de captura na indústria automotiva [4D View Solutions 2013].
•
•
•
Os principais sistemas são [4D View Solutions 2013]:
2DX Multi-Camera, que permite a sincronização de até 80 câmeras, podendo ser calibrado
manualmente ou por meio de um plug-in para calibração, além de possibilitar a integração
de dispositivos do tipo TOF;
4DV Capture, que propicia a captura de cenas de modo offline, utilizando o sistema 2DX
Multi-Camera na captura e permitindo a geração de dados de malha e textura do objeto de
interesse;
127
•
4DV Interactive, que permite a captura em tempo real, utilizando como suporte o sistema
2DX Multi-Camera e gerando dados de malha e textura do objeto de interesse.
Figura 1.5. Aplicação na análise de movimentos de atletas [4D View Solutions 2013].
Os sistemas utilizam algoritmos de subtração de fundo em ambientes controlados para segmentação, provavelmente a técnica de visual hull na modelgem e a combinação de diversos equipamentos
para aquisição.
Os equipamentos fornecidos incluem câmeras e sensores do tipo TOF. Na Figura 1.6 são apresentados o sensor TOF DP-01 e a câmera de captura série DX-20, fornecidos pela empresa 4D View Solutions. Os sistemas da 4D View Solutions atuam na análise de movimentos de atletas praticando golfe,
futebol e voleibol, e na indústria, em testes de protótipos de carros.
Figura 1.6. Equipamentos utilizados nos sistemas da empresa 4D View Solutions (a) Sensor TOF e (b) Câmera.
128
A DVE oferece sistemas de conferência imersiva para salas de reuniões e palestras. Oferece diversos sistemas ou produtos [DVE 2013], como:
• Huddle Room 70, que permite apresentar um grupo de participantes em tamanho real, geralmente uma parte do corpo, em um outro ambiente;
• Telepresence Stage, que permite apresentar pessoas de corpo inteiro caminhando por um palco;
• Immersive Podium, que permite apresentar o participante em uma bancada, sendo que este
pode interagir com objetos 3D em um cenário de palestra, provavelmente por meio de gestos
e utilizando óculos ativos para visualização 3D.
Um dos equipamentos de telepresença para Realidade Aumentada, que compõe o produto Huddle
Room 70, consiste em uma tela transparente, cujo tamanho pode variar de 65 a 70 polegadas, com câmera embutida, a qual pode ser instalada em mesas de reuniões.
Em determinados produtos, para a segmentação é empregada a técnica de chroma-key, por isso,
a empresa recomenda alterações no ambiente real, como a cor das paredes dos escritórios ou salas de
reuniões. No entanto, produtos como o Huddle Room 70, não requerem modificações no ambiente real.
4. Exemplos de aplicações acadêmicas
Esta seção apresenta trabalhos recentes encontrados no meio científico e que apresentam contribuições para sistemas vídeo-avatar.
4.1 AVMix
O sistema AVMix é uma aplicação de vídeo-avatar com interação 3D por meio da captura de imagens do usuário por câmeras de vídeo convencionais [Nakamura 2008].
O sistema proposto foi dimensionado para ser executado em equipamentos domésticos, como
computadores pessoais e webcams, sem a necessidade de hardware especial de alto custo e alta complexidade de configuração.
4.2 AVTC
No sistema de teleconferência imersiva AVTC (Augmented Virtuality Tele-Conferencing) o apresentador é filmado por duas câmeras que geram um par estereoscópico de imagens [Siscoutto e Tori
2004]. Essa digitalização é realizada em um estúdio com fundo azul devido o uso da técnica de chroma-key para remoção do fundo.
Por meio do módulo de integração é possível inserir o vídeo estereoscópico no ambiente virtual
3D. Além disso, neste trabalho é apresentado um modelo de locomoção do apresentador definindo
uma forma de comando do usuário em relação ao mundo virtual e uma proposta de sistema distribuído com um estúdio local e as salas remotas.
129
4.3 Blue-C
No trabalho desenvolvido por Gross et al. (2003) foi criado um ambiente de imersão do usuário
constituído por três telas de projeção ativas e um sistema de captura de vídeo 3D.
É utilizada a técnica de visual hull para obtenção do modelo geométrico do usuário e splatting
para renderização desse modelo. Para obtenção das imagens do apresentador é utilizado um conjunto
de quinze câmeras. Algumas filmam diretamente o alvo e outras estão posicionadas atrás das telas
de projeção ativas, sendo que as imagens são obtidas no momento em que as telas ficam translúcidas.
Além disso, é aplicado um filtro de correção de cores nas imagens capturadas devido a variação do
espectro de cor de cada uma das câmeras [Reinhard et al. 2001].
4.4 Coliseum
Coliseum é um sistema de teleimersão desenvolvido nos laboratórios da Hewlett-Packard para realização de vídeoconferências com múltiplos participantes em tempo real [Baker et al. 2005]. Para cada
participante, uma representação geométrica é gerada e inserida em um ambiente virtual.
Novas perspectivas de cada usuário podem ser geradas por meio de um método baseado em visual
hull, que utiliza cinco câmeras conectadas ao computador de cada participante. Na Figura 1.7 é apresentado o sistema Coliseum.
Figura 1.7. Utilização do sistema Coliseum.
130
4.5. 3D Vídeo Avatar
O sistema 3D Video Avatar é uma aplicação de teleimersão na qual o usuário é inserido em um estúdio cercado por telas de projeção [Lee et al. 2005]. O processo responsável pela modelagem do avatar
tridimensional no ambiente virtual utiliza a técnica de visual hull.
O servidor responsável pela execução do processo recebe os fluxos de vídeo de múltiplas câmeras
e utiliza a GPU para realizar o processamento do algoritmo de modelagem pela técnica de visual hull
em tempo real.
Além disso, é utilizado um método de segmentação com câmera infravermelha para remoção
do fundo e uma técnica de iluminação ativa na qual apenas o corpo do participante é iluminado, no
intuito de obter a textura sem abrir mão do ambiente imersivo de CAVE (Cave Automatic Virtual
Environment).
4.6. Kinect 3D Video Capture
O sistema de captura de vídeo 3D utiliza o fluxo de dados de profundidade e o de textura gerados
pelo Kinect para produzir um vídeo 2,5D em tempo real da cena que está sendo filmada [Kreylos 2011].
Além do modo de execução com apenas um Kinect, esse sistema suporta múltiplos Kinects. Para
gerar o vídeo 3D, os seguintes passos são necessários:
Alinhamento da textura com mapa de profundidade. Como a câmera de profundidade e a câmera
RGB do Kinect estão a alguns centímetros uma da outra, por meio da calibração com marcador fiducial móvel é calculada a função de transformação para projetar a textura no mapa de profundidade.
Nesta primeira calibragem, o marcador é identificado manualmente pelo usuário no mapa de profundidade e na imagem colorida (Figura 1.8);
No caso da utilização de múltiplos Kinects, é utilizado um marcador fiducial (tabuleiro de xadrez)
fixo que é capturado por cada Kinect em seu ponto de vista. Em seguida, é calculada uma função de
transformação para cada Kinect, convertendo o sistema local de coordenadas para um sistema global
de coordenadas.
Figura 1.8. Processo de calibração da textura RGB com o mapa de profundidade.
131
5. Conclusão
A utilização de vídeo-avatares além das fronteiras acadêmicas vem aumentando, demonstrando
sua importância em diversas áreas do conhecimento, como por exemplo, as áreas industrial e esportiva. O presente capítulo procurou apresentar sistemas ou aplicações desta natureza, nos âmbitos acadêmico e comercial, bem como as principais etapas na geração de avatares baseados em vídeo.
Os avatares baseados em vídeo objetivam proporcionar uma representação fidedigna do usuário,
incluindo expressões faciais e naturalidade de gestos, elevando o nível de realismo de ambiente de Realidade Aumentada. No entanto, o nível de realismo depende da qualidade dos avatares, que depende
das técnicas adotadas nas etapas de geração.
Para finalizar, foram realizadas comparações entre as principais aplicações apresentadas. Nas tabelas 1.1 e 1.2 é possível observar as comparações de aplicações acadêmicas e comerciais, respectivamente, as quais foram baseadas nos seguintes parâmetros: técnica de modelagem, infraestrutura de
aquisição, geração em tempo real, calibração e tipo de modelo geométrico gerado.
Tabela 1.1. Comparação de aplicações acadêmicas.
Aplicação
AVTC
Blue-C
Coliseum
Técnica
Depth maps from
stereo vision
Switching planes
Visual hull
Visual hull
3D Video Avatar
Visual hull
Kinect 3D Video
Capture
Luz estruturada
AVMix
Infraestrutura
Tempo real Calibração Modelo
2 câmeras
Sim
Manual
2,5D
2 câmeras
15 câmeras
5 câmeras
Câmeras RGB e
infravermelho
Sim
Sim
Sim
Manual
Manual
Manual
2D
3D
2,5D
Sim
Manual
3D
Sim
Manual
2,5D
1 ou mais Kinects
Tabela 1.2. Comparação de aplicações comerciais.
Aplicação
Técnica
4DV Capture
Visual hull
4D Ineractive
Visual hull
Série DVE
-
Infraestrutura
Até 80 câmeras e
sensor TOF
Até 80 câmeras e
sensor TOF ras
1 câmera
Tempo real
Não
Sim
Sim
Calibração
Manual ou plug-in
de calibração
Manual ou plug-in
de calibração
-
Modelo
3D
3D
2D
De acordo com a tabela 1.1, observa-se que a calibração é uma das principais dificuldades, entretanto, a execução ocorre em tempo real, um parâmetro considerado relevante em ambientes de
Realidade Aumentada.
132
Além disso, é possível de se notar que para obter um modelo 3D do usuário, como é o caso do
Blue-C e 3D Video Avatar, é necessário o uso de uma infraestrutura composta por um grande número
de câmeras, o que exige um sistema distribuído para processar os fluxos de vídeos obtidos.
Dependendo da aplicação, limitando o ponto de vista da audiência, como é o caso do AVMix e
Kinect 3D Video Capture, podem ser utilizadas técnicas que geram um modelo 2,5D sem prejuízo da
percepção de profundidade do avatar.
Outro item que reduz a complexidade da calibração desse setup é a utilização de sensores de profundidade especializados, como é o caso do Kinect. Ao invés do uso de técnicas de geração de mapa
profundidade por meio de visão estereoscópica, essa etapa é executada diretamente no hardware embarcado.
A série DVE envolve os sistemas Huddle Room 70, Telepresence Stage e Immersive Podium, descritos na seção 1.3. A 4D View Solutions não menciona o número mínimo de câmeras e uma das aplicações da empresa não trabalha em tempo real. A remoção de fundo estático e chroma-key são as técnicas
de segmentação geralmente adotadas nas aplicações comerciais.
Há diversas semelhanças entre aplicações acadêmicas e comerciais, como: a técnica de visual hull
é amplamente utilizada na modelagem; é comum a adoção de múltiplas câmeras e sensores TOF para
geração de avatares 3D; a remoção de fundo estático e chroma-key são técnicas de segmentação empregadas em diversos sistemas na etapa de aquisição; e a calibração representa um desafio, embora
recursos para resolver o problema têm sido desenvolvidos, como o plug-in de calibração fornecido pela
4D View Solutions.
6. Agradecimentos
Os autores agradecem a CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior),
pelas bolsas de estudos de Silvio R. R. Sanches, Daniel Makoto Tokunaga e Cléber Gimenez Corrêa;
ao INCT-MACC (Instituto Nacional de Ciência e Tecnologia – Medicina Assistida por Computação
Científica), Edital nº 15/2008, e a FAPESP (Fundação de Amparo à Pesquisa do Estado de São Paulo),
Processo nº 2005/60618-1, pelo apoio financeiro.
Referências
4D View Solutions. (2013) Disponível em: http://www.4dviews.com/. Acesso em: 10 mar. 2013.
ALLBECK, J.; BADLER, N. (1992) “Avatars à la Snow Crash”. In: CA 1998 - Proceedings of the Computer
Animation, Filadélfia, PA, USA, IEEE Computer Society, p. 19.
BAKER, H. H.; BHATTI, N.; TANGUAY, D.; SOBEL, I.; GELB, D.; GOSS, M. E. (2003) “Computation
and performance issues in coliseum: an immersive videoconferencing system”, In: MULTIMEDIA 2003 Proceedings of the eleventh ACM International Conference on Multimedia, Berkeley, CA, USA, ACM, p.
470–479.
133
BURRUS, N. Nicolas Burrus Homepage - Kinect RGBDemo v0.6.1. (2011) Disponível em: http://nicolas.
burrus.name/index.php/Research/KinectRgbDemoV6. Acesso em: 20 nov. 2011.
BERNARDINI, F.; MITTLEMAN, J.; RUSHMEIER, H.; SILVA, C.; TAUBIN, G. (1999) “The
ball-pivoting algorithm for surface reconstruction”, IEEE Transactions on Visualization and Computer
Graphics, v. 5, n. 4, p. 349-359.
BESL, P.; MCKAY, N. (1992) “A method for registration of 3-D shapes”, IEEE Transactions on Pattern
Analysis and Machine Intelligence, v. 14, n. 2, p. 239-256.
CORRÊA, C. G.; TOKUNAGA, D. M.; SANCHES, S. R. R.; NAKAMURA, R.; TORI, R. (2011) “Immersive
teleconferencing system based on video-avatar for distance learning”, In: SVR 2011 - XIII Symposium on
Virtual and Augmented Reality, Uberlândia, MG, Brasil, Sociedade Brasileira de Computação, p. 197–206.
DVE – Digital Video Enterprises. (2013) Disponível em: http://www.dvetelepresence.com/. Acesso em: 10
mar. 2013.
GIBBS, S.; ARAPIS, C.; BREITENEDER, C.; LALIOTI, V MOSTAFAWY, S.; SPEIER, J. (1998) “Virtual
studios: an overview”, IEEE Multimedia, vol. 5, p. 18–35.
GOLDLUCKE, B.; MAGNOR, M. (2003) “Real-time microfacet billboarding for free-viewpoint video
rendering”, In: ICIP 2003: Proceedings of the International Conference on Image Processing, vol. 3, n. 3,
Barcelona, Catalunha, Espanha, p. 713–716.
GROSS, M.; WÜRMLIN, S.; NAEF, M.; LAMBORAY, E.; SPAGNO, C.; KUNZ, A.; KOLLERMEIER, E.;
SVOBODA, T.; VAN GOOL, L.; LANG, S.; STREHLKE, K.; MOERE, A. V.; STAADT, O. (2003) “Blue-C: a
spatially immersive display and 3D video portal for telepresence.”, In: Proceedings of the ACM SIGGRAPH
- International Conference and Exhibition on Computer Graphics and Interactive Techniques, San Diego,
CA, USA, ACM, p. 819–827.
HÄMÄLÄINEN, P.; ILMONEN, T.; HÖYSNIEMI, J.; LINDHOLM, M.; NYKÄNEN, A. (2005) “Martial
arts in artificial reality”, In: CHI 2005 - Proceedings of the SIGCHI Conference on Human Factors in
Computing Systems, Portland, Oregon, USA, ACM, p. 781–790.
HAUBER, J.; REGENBRECHT, H.; HILLS, A.; COCKBURN, A.; BILLINGHURST, M. (2005) “Social
presence in two – and three-dimensional videoconferencing”, In: Proceedings of the 8th Annual
International Workshop on Presence, London, UK, Computer Science and Software Engineering, p. 189–
198.
IDDAN, G. J.; YAHAV, G. (2001) “Three-dimensional imaging in the studio and elsewhere”, In: Corner,
B. D., Nurre, J. H., e Pargas, R. P., editors, Proceedings of SPIE Society of Photo-Optical Instrumentation
Engineers, vol. 4298, Bellingham, Washington, USA, p. 48–55.
INSLEY, J.; SANDIN, D.; DEFANTI, T. (1997) “Using video to create avatars in virtual reality”, In:
Visual Proceedings of the SIGGRAPH International Conference and Exhibition on Computer Graphics
and Interactive Techniques, Los Angeles, CA, USA, p. 128.
134
JONES, A.; LANG, M.; FYFFE, G.; YU, X.; BUSCH, J.; MCDOWALL, I.; BOLAS, M.; DEBEVEC, P.
(2009) “Achieving eye contact in a one-to-many 3D video teleconferencing system”, ACM Transactions on
Graphics, vol. 28, n. 3, p. 64:1–64:8.
KANADE, T.; NARAYANAN, P. J. (2007) “Virtualized reality: Perspectives on 4D digitization of dynamic
events”, IEEE Computer Graphics and Applications, vol. 27, n. 3, p. 32–40.
KAUFF, P.; SCHREER, O. (2002) “An immersive 3d videoconferencing system using shared virtual team
user environments”, In: CVE 2002 - Proceedings of the 4th International Conference on Collaborative
Virtual Environments, Bonn, Alemanha, ACM, p. 105–112.
KAZHDAN, M.; BOLITHO, M.; HOPPE, H. (2006) “Poisson surface reconstruction”, In: Proceedings of the
fourth Eurographics symposium on Geometry processing, Aire-la-Ville, Suíça, Eurographics Association,
p. 61-70.
KIM, H.; SAKAMOTO, R.; KITAHARA, I.; TORIYAMA, T.; KOGURE, K. (2007) “Reliability-based 3D
reconstruction in real environment”, In: MULTIMEDIA 2007 - Proceedings of the 15th International
Conference on Multimedia, Augsburg, Alemanha, ACM, p. 257–260.
KOYAMA, T.; KITAHARA, I.; OHTA, Y. (2003) “Live mixed-reality 3D video in soccer stadium”, In:
ISMAR 2003 - Proceedings of the 2nd IEEE/ACM International Symposium on Mixed and Augmented
Reality, Tóquio, Japão, IEEE Computer Society, p. 178.
KREYLOS, O. Oliver Kreylos' Research and Development Homepage - Kinect Hacking. (2011) Disponível
em: http://idav.ucdavis.edu/~okreylos/ResDev/Kinect/index.html. Acesso em: 15 mai. 2011.
LAURENTINI, A. (1994) “The visual hull concept for silhouette-based image understanding”, IEEE
Transactions on Pattern Analysis and Machine Intelligence, vol. 16, n. 2, p. 150–162.
LEE, S.Y.; KIM, I.J.; AHN, S. C.; KO, H.; LIM, M.T.; KIM, H.G. (2004) “Real time 3D avatar for
interactive mixed reality”, In: VRCAI 2004 - Proceedings of the ACM SIGGRAPH International Conference
on Virtual Reality Continuum and its Applications in Industry, Nanyang, Cingapura, ACM, p. 75–80.
LEE, S.Y.; KIM, I.J.; AHN, S. C.; LIM, M.T.; KIM, H.G. (2005) “Toward immersive telecommunication:
3D video avatar with physical interaction”, In: ICAT 2005: Proceedings of the International Conference on
Augmented Teleexistence, Christchurch, Nova Zelândia, ACM, p. 56–61.
LEMESZENSKI, D.; NAKAMURA, R. (2011) “Multiple 3D data acquisition system setup based on
structured ligth technique for immersive videoconferencing applications”, In: Anais do 8th Workshop de
Realidade Virtual e Aumentada, Uberaba, MG, Brasil.
LORENSEN, W. E.; CLINE, H. E. (1987) “Marching cubes: A high resolution 3D surface construction
algorithm”, In: SIGGRAPH 1987 - International Conference and Exhibition on Computer Graphics and
Interactive Techniques: Computer Graphics, ACM, vol. 21, n. 4, p. 163-169.
MAGNOR, M. A. Video-Based Rendering. AK Peters Limited: Wellesley, MA, USA, 2005.
135
MOLLER, T.; HAINES, E.; HOFFMAN, N. Real-time rendering. AK Peters Limited: Wellesley, MA, USA,
p. 446, 2008.
MORNINGSTAR, C.; FARMER, F. R. (1991) “The lessons of lucasfilm’s habitat”, Cyberspace, Cambridge,
MA, USA, MIT Press, p. 273–302.
NAKAMURA, R. (2008) “Vídeo-Avatar com detecção de colisão para realidade aumentada e jogos”, Tese
de Doutorado, Escola Politécnica da Universidade de São Paulo.
OGI, T.; YAMADA, T.; TAMAGAWA, K.; KANO, M.; HIROSE, M. (2001) “Immersive telecommunication
using stereo video avatar”, In: VR 2001 - Proceedings of the Virtual Reality Conference, Yokohama, Japão,
IEEE Computer Society, p. 45-51.
OHTA, Y.; KANADE, T. (1985) “Stereo by intra- and inter-scanline search using dynamic programming”,
IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 7, p. 139–154.
PICCARDI, M. (2004) “Background subtraction techniques: a review”, In: IEEE International Conference
on Systems, Man and Cybernetics, vol. 4, p. 3099–3104.
PRINCE, S.; CHEOK, A.; FARBIZ, F.; WILLIAMSON, T.; JOHNSON, N.; BILLINGHURST, M.; KATO,
H. (2002) “3D Live: real time captured content for mixed reality” In: ISMAR 2002 - Proceedings of the
International Symposium on Mixed and Augmented Reality, Darmstadt, Alemanha, p. 7–13.
REINHARD, E.; ADHIKHMIN, M.; GOOCH, B.; SHIRLEY, P. 2001) “Color transfer between images”,
IEEE Computer Graphics and Applications, v. 21, n. 5, p. 34 -41.
RHEE, S.M.; ZIEGLER, R.; PARK, J.; NAEF, M.; GROSS, M.; KIM, M.H. (2007) “Low-cost telepresence
for collaborative virtual environments”, IEEE Transactions on Visualization and Computer Graphics, vol.
13, p. 156 –166.
SANCHES, S. R. R.; TOKUNAGA, D. M.; CORRÊA, C. G.; BERNARDES, J. L.; TORI R. (2012) Sistemas
Imersivos que Utilizam Avatares baseados em Vídeo: visão geral e implementação de um sistema
simplificado. Tendências e Técnicas em Realidade Virtual e Aumentada, vol. 2, p. 93-123.
SANCHES, S. R. R.; SEMENTILLE, A. C.; TORI, R. (2009) “Método Para Segmentação de Vídeo em
Tempo-Real para Aplicações em Teleimersão”, In: SVR 2009 – Proceedings of the XI Symposium on
Virtual and Augmented Reality, Porto Alegre, RS, Brasil, Sociedade Brasileira de Computação, p. 175-184.
SHETH, N. (2002) “Hindu avatara and christian incarnation: A comparison”, Philosophy East and West,
vol. 52, p. 98–125.
SHIN, T.; KASUYA, N.; KITAHARA, I.; KAMEDA, Y.; OHTA, Y. (2010) “A comparison between two 3D
free-viewpoint generation methods: Player-billboard and 3D reconstruction”, In: Proceedings of the 3DTV
- Conference: The True Vision - Capture, Transmission and Display of 3D Video, p. 1–4.
136
SISCOUTTO, R.; TORI, R. (2004) “Augmented virtuality teleconferencing”, In: SVR 2004: Proceedings
of the VII Symposium on Virtual Reality, São Paulo, SP, Brasil, Sociedade Brasileira da Computação, p.
124–136.
TAKASHIMA, K.; OMORI, Y.; YOSHIMOTO, Y.; ITOH, Y.; KITAMURA, Y.; KISHINO, F. (2008) “Effects
of avatar’s blinking animation on person impressions”, In: GI 2008 - Proceedings of graphics interface,
Toronto, Ontario, Canadá, Canadian Information Processing Society, p. 169–176.
TAMAGAWA, K.; YAMADA, T.; OGI, T.; HIROSE, M. (2001) “Developing a 2.5-D video avatar”, IEEE
Signal Processing Magazine, vol. 18, n. 3, p. 35–42.
TOKUNAGA, D. M.; NAKAMURA, R.; TORI, R. (2009a) “Nonphotorealistic 3D video-avatar”, In:
SIGGRAPH 2009- International Conference and Exhibition on Computer Graphics and Interactive
Techniques: Posters, New Orleans, LA, USA, ACM, p. 101:1–101:1.
TOKUNAGA, D. M.; SANCHES, S. R. R.; TRIAS, L. P.; NAKAMURA, R.; BERNARDES, J. L.; TORI, R.
(2009b) “Video-based microfacet-billboard avatar for educational immersive teleconference systems”, In:
SVR 2009 - Proceedings of XI Symposium on Virtual and Augmented Reality, Porto Alegre, RS, Brasil,
Sociedade Brasileira da Computação, p. 199–209.
WILL, P.; PENNINGTON, K. (1971) “Grid coding: A preprocessing technique for robot and machine
vision”, Artificial Intelligence, v. 2, n. 3-4, p. 319-329.
YAMAZAKI, S.; SAGAWA, R.; KAWASAKI, H.; IKEUCHI, K.; SAKAUCHI, M. (2002) “Microfacet
billboarding”, In: EGRW ’02: Proceedings of the 13th Eurographics workshop on Rendering, Aire-la-Ville,
Switzerland, Eurographics Association, p. 169–180.
137
138
MARTINS, Valéria Farinazzo; CORRÊA, Ana Grasielle Dionísio; GUIMARÃES, Marcelo de Paiva.
Avaliação de Usabilidade para Aplicações de Realidade Aumentada.
Avaliação de Usabilidade para Aplicações de
Realidade Aumentada
Valéria Farinazzo Martins
Ana Grasielle Dionísio Corrêa
Abstract
The augmented reality applications differ from conventional in many ways such as add virtual objects in
real scenes and, commonly, use markers for interaction. The unconventional way of interaction of these applications become the evaluation of usability essential. This chapter presents the evaluation of usability of
augmented reality applications based on the interpretation of ISO 9241-11 (1998), heuristics of Nielsen (1994)
and usability metrics of Martins et. al (2012). We took into account two modalities of evaluation: Usability
Inspection, conducted by experts; and Usability Test, performed by final users. It also presented the evaluation
of two case studies form the marketing area.
Resumo
As aplicações de Realidade Aumentada diferenciam-se das convencionais em diversos aspectos como, por
exemplo, adicionam objetos virtuais em cenas reais e, comumente, utilizam marcadores para interação.
Assim, tendo uma forma de interação não convencional, a necessidade de se avaliar a usabilidade dessas
aplicações é evidente. Este capítulo apresenta a avaliação de usabilidade de aplicações de Realidade Aumentada realizada através de medidas vindas de interpretações da ISO 9241-11 (1998), das heurísticas
de Nielsen (1994) e também de pesquisas dos autores (Martins et al, 2012). A avaliação levou em consideração duas modalidades: inspeção de usabilidade, realizada por especialistas e testes de usabilidade,
com usuários finais. Através de estudos de caso – duas aplicações na área de Marketing- são validadas
estas duas modalidades de avaliação.
1. Introdução
As aplicações de RA têm sido desenvolvidas, em muitos casos, sem seguir uma metodologia ou
seguindo uma metodologia tradicional de desenvolvimento de software, que não levam em considera138
ção as peculiaridades desta classe de aplicações. Sendo RA considerada uma tecnologia recente e que
permite uma interação não-convencional, torna-se essencial a análise de sua qualidade, principalmente referente à usabilidade de suas aplicações. É válido ressaltar que, embora essa qualidade possa ser
responsável pelo sucesso ou pelo fracasso das aplicações, pouco se conhece a respeito da opinião dos
usuários, suas satisfação e frustrações no uso destas aplicações. Dessa forma, surge a necessidade de se
definir regras que ajudem no desenvolvimento e na avaliação destas aplicações, mensurando o quanto
elas são “utilizáveis” e “amigáveis”.
Metodologias tradicionais para avaliar a usabilidade podem ser utilizadas, porém não conseguem
alcançar questões bastante específicas de RA para medir novos conceitos, como marcadores e objetos
virtuais, apresentados concomitantemente com o mundo real nestas aplicações. Não foram encontrados, na literatura, muitos trabalhos sobre avaliação de usabilidade de RA: Kostaras e Xenos (2009)
descrevem, de maneira genérica, quais são as diretrizes a serem abordadas para esta classe de aplicação.
Eles citam os pontos fortes e fracos de se realizar avaliações de interfaces por meio de entrevistas, questionários, inspeções ou testes de usabilidade. No entanto, não produzem métricas para isso. Também
Zainuddin, Zaman e Ahmad (2011) ao realizarem a avaliação de um ambiente com RA, não descrevem
quais as métricas utilizadas para mensurar os resultados. Uma pesquisa recente realizada por Martins
et al (2012) aponta a criação de métricas de usabilidade para sistemas de RA, baseadas em reinterpretações das heurísticas de Nielsen (1994).
Sendo assim, torna-se necessário estudar, de maneira mais profunda, como metrificar a usabilidade de
aplicações em RA, de modo a apoiar os desenvolvedores em seu processo de desenvolvimento. Este estudo
considera tanto avaliação de usabilidade para usuários finais (testes de usabilidade), quanto inspeção de
usabilidade (baseado em especialistas).
A fim de validar as métricas estabelecidas neste capítulo, foram escolhidas e avaliadas duas aplicações voltadas para o mercado publicitário e de moda. A primeira, que é da área automobilística, visa
apresentar um modelo de carro para homens e utiliza marcadores. A segunda é voltada para a venda
de acessórios para mulheres e não utiliza marcadores (markless).
Este capítulo está organizado como se segue. A seção 1.2 discorre sobre Avaliação de Usabilidade,
abordando seus conceitos, vantagens e tipos. Já a seção 1.3 traz a avaliação de usabilidade especificamente para aplicações de RA. Na seção 1.4 são abordados os dois estudos de caso, que coloca em
prática a avaliação de usabilidade dividida em testes de usabilidade – envolvendo usuários finais – e
inspeção de usabilidade. Finalmente, na seção 1.5 são realizadas as conclusões deste trabalho.
2. Avaliação de Usabilidade
O termo usabilidade possui várias definições, incluindo a estabelecida pela ISO 9241-11 (1998):
usabilidade é a capacidade que um sistema interativo oferece a seu usuário, em um determinado contexto de operação, para a realização de tarefas, de maneira eficaz (que é a precisão e a completude com
que usuários conseguem atingir seus objetivos); eficiente (que é a relação entre a precisão e a completude com que usuários atingem certos objetivos e os recursos gastos para atingi-los); e satisfatória (que é
o conforto e as atitudes positivas dos usuários concernentes ao uso do sistema).
139
Já para Lauesen (2005), Avouris (2001), Sommerville (2011) e Nielsen (1993), a usabilidade é mais
abrangente e consiste de fatores tais como:
• Funcionalidade: o quanto o sistema oferece suporte às tarefas reais dos usuários;
• Fácil de aprender: quão fácil é o aprendizado sobre o sistema para vários grupos de usuários;
• Fácil de memorizar: esforço cognitivo do usuário necessário para lembrar como interagir
com a interface do sistema interativo;
• Eficaz: capacidade de o usuário interagir com o sistema para alcançar seu objetivo;
• Eficiente: recursos (tempo, mão de obra e materiais envolvidos) necessários para que o usuário interaja com o sistema e alcance seu objetivo;
• Seguro: se refere ao grau de proteção de um sistema contra condições desfavoráveis ou perigosas;
• Satisfação subjetiva: o quanto o usuário está satisfeito com aquele determinado sistema. Expressa o
efeito do uso do sistema sobre as emoções e os sentimentos dos usuários;
• Compreensão: quão fácil é entender o que o sistema executa. Este fator é particularmente importante para situações não usuais que podem ocorrer quando há falhas ou erros no sistema;
• Adequação a padrões específicos: o quanto o sistema consegue estar de acordo com um padrão de projeto de interfaces; e
• Adaptação ao nível de experiência dos usuários: o quanto o sistema é adaptativo às necessidades de usuários com níveis diferentes de conhecimento sobre o sistema, que podem variar
entre iniciante, intermediário e avançado.
A fase de avaliação de um sistema deve ocorrer durante todo o processo de desenvolvimento,
utilizando seus resultados como melhorias a serem aplicadas gradativamente na interface - Rocha e
Baranauskas (2003). Assim, a avaliação de usabilidade é cada vez mais usada no desenvolvimento de
software.
Atualmente, existem vários métodos de avaliação de usabilidade que, em geral, variam quanto à
etapa do desenvolvimento em que são aplicados, à maneira de coletar dados e às características destes,
além do tipo de análise realizada com base nos dados obtidos. Dentre os métodos de avaliação de usabilidade, é possível citar: inspeção de usabilidade, realizada por especialistas e testes de usabilidade,
com usuários finais. Estes dois métodos serão descritos a seguir – Preece, Rogers e Sharp (2007).
2.1. Testes de Usabilidade
O teste com usuários é um método fundamental de usabilidade. Embora seja considerado um
método bastante caro e demorado, alguns autores afirmam que eles têm acelerado muitos projetos e
levado a uma significativa redução em seus custos – Gold e Lewis (1985) e Rubin e Chisnell (2008).
Os testes de usabilidade podem ajudar no desenvolvimento do sistema ou podem visar à avaliação
da qualidade global da interface. Geralmente um teste de usabilidade é um processo composto por
quatro passos:
1. Preparação: todos os elementos envolvidos (equipamentos de hardware e software, questionários e roteiros de testes) são adequados;
140
2.
3.
4.
Introdução: a situação de teste é apresentada para os usuários;
Teste: o avaliador auxilia o teste de cada usuário, que é feito de forma isolada;
Sessão final: depois da realização dos testes (tarefa), cada participante é convidado a fazer
comentários ou sugestões gerais por meio de entrevistas ou questionários.
As informações coletadas dos usuários possibilitam a identificação de pontos fortes e fracos das
aplicações. As técnicas para tal coleta são as seguintes:
• Questionários: permite coletar dados sobre o perfil dos usuários (pré-teste) e suas opiniões
e emoções a respeito da interface (pós-teste). É um método relativamente barato de avaliar
uma interface. As questões devem ser tão precisas quanto possível, a fim de se conseguir
respostas claras. Por exemplo, questões do tipo “por favor, comente sobre a usabilidade desta
interface” devem ser evitadas. Visando maior precisão nas respostas dos usuários, sugere-se
padronizar as respostas: as questões podem ser elaboradas com base em perguntas fechadas
com respostas variando de acordo com alguma escala de mensuração, tal como a apresentada
por Likert (1932).
• Observação de usuário: obtém as informações através da observação dos usuários utilizando
o sistema. Esse método busca pontos como as facilidades no uso e os erros cometidos. Isto
pode ser complementado com sessões de “pensando em voz alta”, nas quais os usuários falam
sobre as ações realizadas, decisões tomadas, opiniões e sentimentos enquanto interagem com
o produto ou protótipo;
• Vídeo Snapshots do sistema: consiste em gravar todas as ações do usuário em arquivos de
vídeo (captura as telas e os áudios) para posterior análise. Equipamentos de vídeo, de custo
relativamente baixo, permitem registrar a observação direta de sessões do usuário para posterior análise. Contudo, a análise completa de vídeo pode se tornar dispendiosa economicamente, caso haja necessidade de equipamentos específicos com muitas câmeras focadas no
usuário e na tela. Entretanto, a gravação de operações de um usuário selecionado pode ser
útil para detectar problemas;
• Coleta automática: inclusão, no software, de coleta automática de informações, tais como
tempo e número de cliques que o usuário realizou para finalizar uma tarefa, pode fornecer
dados sobre as maiores facilidades e erros encontrados pelos usuários. Assim, por exemplo, o
tempo que o usuário demorou em selecionar uma opção pode ser um indicativo de que ele se
sente perdido em relação à escolha ou não a consegue encontrá-la facilmente.
Nenhuma destas técnicas de coletas é completamente segura e são, provavelmente, insuficientes
para detectar todos os problemas de interface do usuário. Entretanto, elas podem ser usadas por um
grupo de voluntários, antes que o sistema seja liberado, sem um grande gasto de recursos. A maioria
dos grandes problemas de projeto de interface do usuário pode, então, ser descoberta e corrigida.
141
2.2. Inspeção de Usabilidade
O método de Inspeção de Usabilidade é realizado por especialistas e consiste em examinar, segundo critérios estabelecidos, a interface de um sistema buscando verificar se a mesma atende aos
requisitos de usabilidade. Além de encontrar os problemas, é necessário quantificar sua severidade:
problemas mais graves devem ser tratados com maior prioridade que problemas menos importantes
– Nielsen (1993). Então, os problemas podem ser classificados da seguinte forma: 0 - não é necessariamente um erro de usabilidade; 1 - Problema estético: não é necessário ser corrigido ao menos que haja
tempo disponível; 2 - Baixa prioridade: problema menor de usabilidade; 3 - Alta prioridade: problema
maior de usabilidade; 4 – Catástrofe: deve ser corrigido imediatamente.
A maioria dos métodos de inspeção tem um efeito significativo na interface final somente se for
usado durante o ciclo de vida do desenvolvimento, o que, efetivamente, não ocorre na maioria dos
casos, seja porque são caros, difíceis ou demorados - Rocha e Baranauskas (2003). Pesquisando este
problema, Nielsen (1993) propôs o que ele chama de Engenharia Econômica de Usabilidade. A avaliação heurística é o principal método desta proposta e envolve um pequeno conjunto de avaliadores examinando a interface e julgando suas características, em face de reconhecidos princípios de usabilidade,
definidos por uma heurística. Segundo Nielsen (1993), são necessários 3 a 5 avaliadores para realizar
a inspeção, que é feita, primeiramente, de maneira individual. Cada avaliador percorre a interface diversas vezes, inspecionando os diferentes componentes de diálogo e, ao verificar problemas, estes são
relacionados às heurísticas violadas – Nielsen (1994). Tipicamente, uma sessão de avaliação dura cerca
de 2 horas, mas, dependendo do tamanho ou complexidade da interface, é recomendável dividi-la em
várias sessões abordando cenários específicos. Ao final da avaliação, todos os resultados são consolidados em uma única lista.
As heurísticas de Nielsen são compostas por 10 princípios fundamentais de usabilidade – Nielsen
(1994) - e versam desde critérios como consistência e padrões até documentação. Elas são bastante gerais e foram originalmente criadas para sistemas Web. Por isso, em alguns casos, é necessário adaptá-las ao tipo de sistema que se venha a avaliar. Por exemplo, Salvador, Oliveira Neto e Guimarães (2009)
as adaptaram para a avaliação de interfaces baseadas em voz e Sutcliffe e Gault (2004) para avaliar
sistemas de Realidade Virtual.
A fim de facilitar e orientar o trabalho de inspeção, pode-se utilizar checklists que focalizam aspectos importantes da interface que deveriam ser analisados mais profundamente. Esta é uma técnica
relativamente barata e que pode ser adaptada às diversas situações de avaliações, bastando, para isso,
que se selecionem regras ergonômicas adequadas. Estas regras são construídas a partir da experiência
de usuário, durante anos, no desenvolvimento de vários projetos na área ou ainda entendidas como
regras de “bom senso” – Orth (2005).
De maneira geral, a aplicação das técnicas de inspeção de usabilidade realizada por especialistas
é uma alternativa menos dispendiosa, do ponto de vista de custo e de tempo, em relação aos testes de
usabilidade. Porém, não substituem a avaliação do usuário, devendo, preferencialmente, serem aplicadas antes da avaliação com o usuário final, a fim de que problemas identificados possam ser solucionados antes da liberação do produto ao público em geral.
142
3. Avaliação de Usabilidade para Aplicações de Realidade Aumentada
Para criar medidas de usabilidade para avaliação de sistemas de RA, foi reinterpretado o conjunto
de heurísticas propostas por Nielsen (1994) e acrescentadas outras diretrizes, propostas pelos autores,
que são específicas para aplicações de RA. A reinterpretação foi fundamental para criar um checklist
para a Inspeção de Usabilidade, assim como a criação de um questionário para os testes de usabilidade.
As heurísticas de Nielsen são bastante populares para medir usabilidade por causa de sua capacidade
de serem aplicadas facilmente, sua simplicidade e baixo custo, porém requerem especialistas em usabilidade bastante treinados. A reinterpretação dessas heurísticas no contexto de RA é a seguinte:
1. Visibilidade do status do sistema: o sistema deve informar ao usuário sobre as ações que estão
ocorrendo na aplicação. Para isso, o desempenho do sistema deve ser rápido o suficiente, o
que exige, por exemplo, um sistema eficiente de tracking e de carregamento de objetos virtuais na cena;
2. Compatibilidade do sistema com o mundo real: o projeto do sistema deve seguir convenções
do mundo real, fazendo com que a informação apareça numa ordem natural e lógica. Os
usuários devem interagir com o conteúdo virtual como no mundo real, sendo que a escala do
objeto e animação devem ser coerentes com a cena;
3. Controle do usuário e liberdade: tem como objetivo avaliar o quanto a aplicação permite que
o usuário esteja livre para executar ações e como o usuário pode desfazer ações realizadas
por engano. Quando o usuário apresenta, por exemplo, um marcador errado para a câmera,
o sistema deve suportar a substituição deste marcador facilmente ou, se possível, alertá-lo
sobre o erro;
4. Consistência e padrões: avalia convenções de layout e utilização de padrões. Está também ligado às boas metáforas visuais, visto que o usuário, quando visualiza um objeto virtual, deve
reconhecer aquele objeto como parte do seu mundo. Então, pode-se, por exemplo, associar
cada marcador a uma ação específica ou a um objeto virtual para evitar erros;
5. Prevenção de erros: a aplicação deve estar projetada para evitar erros e para prevenir a ocorrência de eventos indesejados. Se isso ocorrer, é fundamental a disponibilização de mensagens de fácil entendimento como, por exemplo, “o carregamento de objetos 3D não estar
funcionando adequadamente”;
6. Reconhecimento ao invés de relembrança: verifica se o usuário consegue executar a aplicação
de modo intuitivo. Boas metáforas em RA podem ajudar o usuário a reconhecer funcionalidades, já que o usuário interage com um ambiente real mesclado com objetos virtuais. Funcionalidades de marcação e posicionamento na cena devem ser memorizadas com facilidade;
7. Flexibilidade e eficiência de uso: avalia o quanto o usuário pode manipular a aplicação,
quantas personalizações e interações podem ser amplamente desenvolvidas de modo aberto
e flexível. Deve permitir: a) Uma aplicação com alto desempenho e que eleve o interesse do
usuário, mesmo após já ter utilizado a mesma em momentos diferentes; b) Uma estabilidade
na detecção dos marcadores e na adição dos objetos virtuais correspondentes na cena; não
havendo perda de detecção; c) Processo de adição do objeto virtual na cena também deve ser
suficientemente rápido - objetos virtuais tridimensionais não devem ter alta quantidade de
143
polígonos, pois afetará o tempo de leitura e apresentação, e, consequentemente a interação
da aplicação;
8. Estética e design minimalista: o sistema não deve fornecer informação irrelevante no diálogo
com o usuário. Informações irrelevantes concorrem com as relevantes e acabam por focar
a atenção do usuário para pontos não importantes da aplicação. A sobreposição de objetos
virtuais ao mundo real pode produzir no usuário uma sobrecarga de informação. Assim, a
quantidade mínima de objetos virtuais deve ser agregada ao ambiente, ou seja, devem ser
adicionados somente aqueles objetos que produzirão funcionalidades para a aplicação ou que
sejam realmente importantes;
9. Ajudar os usuários a reconhecer, diagnosticar e corrigir erros: o sistema deve indicar precisamente o problema e construtivamente compor uma sugestão. Por exemplo, se um marcador
não cadastrado é detectado, o sistema tem que proporcionar uma orientação para resolver o
erro;
10. Ajuda e documentação: embora seja melhor um sistema que possa ser usado sem documentação, é necessário prover ajuda e documentação. Essas informações devem ser fáceis de
serem encontradas, focadas na tarefa do usuário e não muito extensas. Devem, por exemplo,
explicar o uso inicial da aplicação (e como cada marcador funciona). É interessante que sejam
adicionados vídeos de utilização ou exemplos, para que o usuário consiga compreender como
deve utilizar o sistema.
Outras medidas foram adicionadas a fim de tratar de maneira mais direta questões relacionadas
à eficácia, eficiência e satisfação, de acordo com a ISO 9241-11 – ISO(1998), visto que as heurísticas
propostas inicialmente por Nielsen (1994) eram utilizadas para inspeções de usabilidade e não contemplam os usuários finais. Neste trabalho, elas serão utilizadas como base para a elaboração de checklists
para a inspeção de usabilidade e para a geração dos questionários para os testes com usuários finais.
Estas outras medidas incluem:
1. Precisão: quão preciso é o sistema durante as interações. Posição do conteúdo virtual da imagem, que é determinada pelo sistema de localização, deve estar justaposta à posição do objeto
real e não deve oscilar;
2. Facilidade de uso: o quanto o usuário se sente confortável e seguro no uso da aplicação, mesmo na primeira vez que a utiliza;
3. Configuração do ambiente: aplicações RA exigem dispositivos especiais como sensores ou
câmeras. Além disso, podem ser necessários os marcadores, tais como, marcadores fiduciais.
A configuração do meio ambiente deve ser o mais simples possível;
4. Satisfação: mede o quanto a aplicação supera a expectativa do usuário. A interação é um
aspecto fundamental nas aplicações RA, e então a aplicação deve alcançar atitudes positivas
em relação ao seu usuário.
144
3.1. Testes de Usabilidade para Realidade Aumentada
O objetivo deste teste é entender a opinião do usuário sobre o sistema, seja em questões gerais ou
mais especificamente sobre o sistema de RA. Baseado em Martins et. al. (2012), nas reinterpretações de
Nielsen (item 1.3) e na ISO 9241-11 – ISO (1998), são exemplos de questões a serem abordadas (Tabela 1):
Tabela 1. Exemplo de Questionário
Questão
Heurística
Entendi facilmente como utilizar a aplicação e o seu objetivo.
Facilidade de uso
Quando existiam mensagens na aplicação, sejam textuais ou em vídeo, a
Prevenção de erros
linguagem foi entendida facilmente.
Em nenhum momento eu me senti perdido na aplicação, sem saber o que Controle do usuário e
fazer.
liberdade
Visibilidade do status
Ao mostrar o marcador, o objeto 3D é carregado rapidamente.
do sistema
Flexibilidade e
O objeto da cena segue de forma correta à posição do marcador.
Eficiência de Uso
Os marcadores são detectados corretamente.
Precisão
Foi uma experiência bastante agradável utilizar a aplicação.
Satisfação
Eu utilizaria novamente a aplicação, se fosse possível.
Satisfação
Eu sempre executava as mesmas ações para acionar as mesmas
Consistência e padrões
funcionalidades
A quantidade de objetos virtuais adicionados na cena é coerente com o
Estética e design
propósito da aplicação.
minimalista
O objeto virtual sempre estava posicionado adequadamente conforme a
Precisão
posição do marcador
O sistema disponibilizou um material de documentação de uso.
Ajuda e Documentação
3.2. Inspeção de Usabilidade para RA
Para a inspeção de aplicações de RA, podem ser organizados checklists que facilitam o trabalho
dos especialistas. Baseado em Martins et. al. (2012) e no exposto na seção 1.3, foram criados os checklists, classificado como satisfação (Tabela 2), eficácia (Tabela 3) e eficiência (Tabela 4). Seguir estes
checklists atentamente é uma forma de avaliar as aplicações de RA baseado em um método de inspeção.
Ele também ajuda o avaliador a não esquecer algumas heurísticas, e aumenta a objetividade da avaliação, confiabilidade e reprodutibilidade.
145
Tabela 2. Checklist: Verificação da variável Satisfação
Item
A quantidade de mecanismos de interação é satisfatória?(marcador,
teclado, mouse, joystick)
Heurística
Estética e design
minimalista
Estética e design
minimalista
É satisfatório o manual da aplicação? (vídeo, textos, áudio)
Ajuda e documentação
É satisfatória a quantidade de objetos virtuais na cena?
É satisfatório o mecanismo de interação da aplicação? (por exemplo, com
o tipo de marcador)
A liberdade de movimentação durante a interação é satisfatória? (por
exemplo, não é necessário olhar para a câmera constantemente)
Satisfação
Satisfação
Tabela 3. Checklist: Verificação da variável Eficácia
Item
O usuário sabe o status da aplicação durante toda a interação?
Se existe mais de um marcador em cena, é possível especificar um?
Heurística
do sistema
Controle do usuário e
liberdade
É possível realizar as operações “redo” ou “undo” facilmente? (por
Controle do usuário e
exemplo, retornar para o status anterior da aplicação sem nenhum objeto
liberdade
virtual na cena)
O objetivo da aplicação é alcançado?
Satisfação
146
Tabela 4. Checklist: Verificação da variável Eficiência
Item
Heurística
É satisfatório o tempo de carregamento de objetos virtuais na cena?
do sistema
Os objetos virtuais são misturados com o mundo real corretamente? (por Compatibilidade com o
exemplo: posição, textura, escala)
mundo real
Compatibilidade com o
A animação dos objetos virtuais é coerente com o mundo real?
mundo real
As ações e feedback são padronizados? (por exemplo, uma borda é
Consistência e padrões
adicionada em todos os marcadores detectados)
Existe prevenção de erros? (por exemplo, é apresentada para o usuário
Prevenção de erros
alguma mensagem quando um marcador não cadastrado é detectado)
As funcionalidades da aplicação são lembradas facilmente? (por exemplo, Reconhecimento ao
é fácil lembrar a função de cada marcador)
invés de lembrança
Flexibilidade e
Como é a curva de aprendizagem dos usuários iniciantes?
eficiência de uso
Usuários experientes podem utilizar a aplicação de maneira otimizada?
Flexibilidade e
(por exemplo, eles não assistem os vídeos introdutórios)
eficiência de uso
Flexibilidade e
É fácil posicionar o marcador para a câmera/sensor? (orientação/posição)
eficiência de uso
Ajuda os usuários
A aplicação auxilia o usuário durante a interação? (por exemplo, instruir
a reconhecer,
a mostrar um marcador)
diagnosticar e corrigir
erros
A aplicação exige algum pré-requisito?(câmera, marcador, dispositivo
Configuração do
móvel, GPS, posição do usuário, luz, impressão de marcador, calibragem)
ambiente
O sistema de tracker é estável?
Precisão
A aplicação continua funcionando de forma correta quanto vários
Precisão
marcadores estão visíveis na cena?
4. Estudo de Caso de Avaliação de RA
Duas aplicações de RA na área de Marketing e Moda foram selecionadas para validação das métricas. O primeiro estudo de caso é uma aplicação da área automotiva e visa promover um carro. Nela
o usuário utiliza um marcador fiducial para interagir com o veículo (Figura 1). Depois de inicializada,
o usuário é instruído a apresentar o marcador para a câmera, que é a imagem de um volante, então o
veículo virtual é sobreposto. O carro gira conforme a posição do volante, assim o usuário pode visualizar o veículo por diversos ângulos. Clicando sobre o carro o usuário liga as luzes do carro e pode
agendar um test drive.
147
Figura 1. Aplicação automotiva
A outra aplicação escolhida foi desenvolvida para a área de Moda (de venda de acessórios) e não
utiliza marcadores (markeless). O usuário pode provar virtualmente pulseiras, brincos e colares. Para
isso, a aplicação realiza o tracker de partes do corpo do usuário (face, pescoço e braços). A Figura 2
mostra imagens dessa aplicação com objetos sobrepostos.
Brinco virtual
(b) Bracelete virtual
Figura 2. Aplicação da área de venda de acessórios
4.1. Testes de Usabilidade
Foi aplicado o teste de usabilidade para um conjunto de 32 pessoas, sendo 20 do sexo masculino
para a primeira aplicação e 12 do sexo feminino para a segunda aplicação, com perfil variado de conhecimento, embora todas estas pessoas sejam de uma universidade (secretárias, professores da área
148
de Computação, professores fora da área de Computação, alunos). A faixa etária deste público-alvo
variou de 16-48 anos.
Primeiramente, estas pessoas tiveram uma introdução ao tema – conceitos de RA, maneira de
interagir – por cerca de 5 minutos e mais 2 minutos para responder ao pré-teste (questões relacionadas
ao perfil). Depois, puderam experimentar a aplicação por 10 minutos cada. O pós-teste, com o questionário, apresentado na seção 1.3.1 durou 5 minutos, em média.
As tarefas do usuário consistiram de: todos os usuários assistiram ao vídeo explicativo sobre uso
da ferramenta. As tarefas do público masculino foram: manipular o volante (girar para a esquerda;
girar para a direita; deixar parado) com a luz acesa e depois com a luz apagada. As tarefas do público
feminino foram: testar o brinco (escolher três brincos na galeria), testar o colar (escolher três colares
na galeria); testar a pulseira (escolher três pulseiras na galeria).
Estas questões referentes à usabilidade do pós-teste possuem cinco alternativas possíveis, de acordo com a escala Likert de cinco pontos – Likert (1932), a fim de medir o nível de concordância à afirmação.
A seguir, é possível verificar a opinião dos usuários a respeito das duas aplicações (Tabela 5 e
Tabela 6).
Tabela 5. Resultado da opinião dos usuários sobre o sistema automobilístico
Questão
Entendi facilmente como utilizar a aplicação e o seu o objetivo.
As mensagens apresentadas (texto ou vídeo) foram entendidas facilmente.
Em nenhum momento eu me senti perdido na aplicação, sem saber o que fazer.
O objeto da cena segue de forma correta a posição do marcador.
Eu sempre executava as mesmas ações para acionar as mesmas funcionalidades
A quantidade de objetos virtuais adicionados na cena é coerente com o propósito da
aplicação
O objeto virtual sempre estava posicionado adequadamente conforme a posição do
marcador
149
Média
4,7
4,15
3,95
3,65
2
4,2
4,5
4,5
3,9
4,7
4,1
4
Tabela 6. Resultado da opinião dos usuários sobre a aplicação de acessórios
Questão
Entendi facilmente como utilizar a aplicação e o seu o objetivo.
As mensagens apresentadas (texto ou vídeo) foram entendidas facilmente.
Em nenhum momento eu me senti perdido na aplicação, sem saber o que fazer.
O objeto da cena segue de forma correta a posição do marcador.
Eu sempre executava as mesmas ações para acionar as mesmas funcionalidades
A quantidade de objetos virtuais adicionados na cena é coerente com o propósito da
aplicação
O objeto virtual sempre estava posicionado adequadamente conforme a posição do
marcador
Média
4,83
4,25
3
3,67
2
3,33
4,17
4,08
2,75
4,41
2
4,5
Todas as questões tiveram o mesmo peso. A aplicação automobilística atingiu a média total de
4,02, o que se pode considerar um bom resultado. Os pontos de maior atenção foram os itens 4 e 5, que
tratam do tempo para apresentação dos objetos e a perda do marcador durante a execução. A média
geral da aplicação de acessórios (markless) foi de 3,58, que pode ser considerada satisfatória. Os principais pontos de atenção detectados foram principalmente nos itens 3, 5, 9 e 11, que tratam do status da
aplicação; do sistema de tracking; da falta de padronização das interações e da falta de ajuste de escala
e posicionamento dos objetos virtuais.
4.2. Inspeção de Usabilidade
Para a inspeção realizada, foram utilizados 3 especialistas, autores deste capítulo. Estes especialistas são da área de Inteface Homem-Computador, com média de 3 anos de experiência em desenvolvimento e uso de aplicações de RA. Embora Nielsen (1993) pontue que sejam necessárias, em média,
2 horas para a realização da inspeção, as aplicações eram bastante simples e por isso os especialistas
utilizaram, em média, apenas 30 minutos para relacionar os problemas encontrados em cada aplicação.
Foram gerados três checklists que, posteriormente, foram concatenados de forma a resultar nos
seguintes apontamentos (Tabela 7 a 9):
150
Tabela 7. Verificação da variável Satisfação na aplicação automotiva
Grau de
severidade
Comentários dos especialistas
0,0,0
Nenhum problema
4,4,4
A simplicidade da aplicação gera
desinteresse dos usuários
0,0,0
Nenhum problema
É satisfatório o mecanismo de interação
da aplicação? (por exemplo, com o tipo de
marcador)
2,3,1
O posicionamento do marcador
com uma mão é a interação com o
mouse com a outra é difícil
A liberdade de movimentação durante
a interação é satisfatória? (por exemplo,
não é necessário olhar para a câmera
constantemente)
2,1,2
A aplicação exige o posicionamento
no campo de visão da câmera
Checklist
É satisfatória a quantidade de objetos virtuais
na cena?
A quantidade de mecanismos de interação
é satisfatória? (marcador, teclado, mouse,
joystick)
É satisfatório o manual da aplicação? (vídeo,
textos, áudio)
Tabela 8. Verificação da variável Eficácia na aplicação automotiva
Checklist
Grau de
severidade
O usuário sabe o status da aplicação durante
toda a interação?
0,0,0
Nenhum comentário
Se existe mais de um marcador em cena, é
possível especificar um?
0,0,0
Não aplicável
É possível realizar as operações “redo” ou
“undo” facilmente? (por exemplo, retornar
para o status anterior da aplicação sem
nenhum objeto virtual na cena)
0,0,0
É possível ligar e desligar as luzes
do carro.
1,2,1
O objetivo da aplicação é atingido,
porém, o objetivo é muito simples.
A aplicação deveria permitir a
customização do veículo, como, por
exemplo, troca de cor do veículo e
abertura de portas.
151
Tabela 9. Verificação da variável Eficiência na aplicação automotiva
Checklist
Grau de
severidade
0,0,1
Por volta de 5 segundos, o que é
considerado alto
0,0,0
Nenhum problema
0,0,0
Nenhum problema
0,0,0
Nenhum problema
0,0,0
Não aconteceu nenhum erro
0,0,0
A interação é fácil. O usuário deve
apenas girar o volante
É satisfatório o tempo de carregamento de
objetos virtuais na cena?
Os objetos virtuais são misturados com o
mundo real corretamente? (por exemplo:
posição, textura, escala)
A animação dos objetos virtuais é coerente
com o mundo real?
As ações e feedback são padronizados? (por
exemplo, uma borda é adicionada em todos
os marcadores detectados)
Existe prevenção de erros? (por exemplo,
é apresentada para o usuário alguma
mensagem quando um marcador não
cadastrado é detectado)
As funcionalidades da aplicação são
lembradas facilmente? (por exemplo, é fácil
lembrar a função de cada marcador)
Como é a curva de aprendizagem dos
usuários iniciantes?
1,2,1
Usuários experientes podem utilizar a
aplicação de maneira otimizada? (por
exemplo, eles não assistem os vídeos
introdutórios)
3,2,3
É fácil posicionar o marcador para a câmera/
sensor? (orientação/posição)
2,1,2
A aplicação auxilia o usuário durante a
interação? (por exemplo, instruir a mostrar
um marcador)
A aplicação exige algum prérequisito?(câmera, marcador, diapositivo
móvel, GPS, posição do usuário, luz,
impressão de marcador, calibragem)
A aplicação continua funcionando de forma
correta quanto vários marcadores estão
visíveis na cena?
0,1,0
152
A aplicação não é muito intuitiva,
porém é apresentado um vido que
demonstra como interagir.
A aplicação é simples, então
usuários novatos e experientes
interagem da mesma maneira.
O usuário precisa posicionar o
marcador no campo de visão da
câmera
Estão disponíveis para o usuário
um vídeo e um manual, que são
bons.
1,1,2
É necessário imprimir o marcador
0,0,0
Nenhum comentário
0,0,0
Nenhum comentário
A seguir são apresentados os resultados da inspeção de usabilidade para o segundo estudo de caso
(Tabelas 10 a 12).
Tabela 10. Verificação da variável Satisfação na aplicação de venda de acessórios
Checklist
Grau de
severidade
0,0,0
Nenhum comentário
0,0,0
Nenhum comentário
0,0,0
Muito bom
0,0,0
Nenhum comentário
3,2,2
É desejável maior liberdade para se
movimentar
É satisfatória a quantidade de objetos virtuais
na cena?
A quantidade de mecanismos de interação
é satisfatória? (marcador, teclado, mouse,
joystick)
É satisfatório o manual da aplicação? (vídeo,
textos, áudio)
É satisfatório o mecanismo de interação
da aplicação? (por exemplo, com o tipo de
marcador)
A liberdade de movimentação durante
a interação é satisfatória? (por exemplo,
não é necessário olhar para a câmera
constantemente)
Tabela 11. Verificação da variável Eficácia na aplicação de venda de acessórios
Checklist
Grau de
severidade
O usuário sabe o status da aplicação durante
toda a interação?
0,0,0
Nenhum comentário
Se existe mais de um marcador em cena, é
possível especificar um?
2,3,2
Se outro usuário aparecer na cena,
o sistema se perde
É possível realizar as operações “redo” ou
“undo” facilmente? (por exemplo, retornar
para o status anterior da aplicação sem
nenhum objeto virtual na cena)
1,2,3
O usuário pode trocar o tipo de
acessório a qualquer momento.
0,0,0
Sim, é possível experimentar os
acessórios.
153
Tabela 12. Verificação da variável Satisfação na aplicação de venda de acessórios
Checklist
Grau de
severidade
É satisfatório o tempo de carregamento de
objetos virtuais na cena?
1,0,1
Menos do que um segundo
Os objetos virtuais são misturados com o
mundo real corretamente? (por exemplo:
posição, textura, escala)
4,4,4
O sistema de posicionamento dos
acessórios precisa ser aprimorado.
Os braceletes se mantêm em posição
fi xa quando o usuário se move.
A animação dos objetos virtuais é coerente
com o mundo real?
0,0,0
Nenhum comentário
1,3,1
A aplicação exige que o usuário
não se mova após selecionar um
acessório. É desejável uma maior
liberdade de movimentação para o
usuário.
0,0,0
Não ocorreram erros
0,0,0
A aplicação fornece instruções de
interação durante a execução
As ações e feedback são padronizados? (por
exemplo, uma borda é adicionada em todos
os marcadores detectados)
Existe prevenção de erros? (por exemplo,
é apresentada para o usuário alguma
mensagem quando um marcador não
cadastrado é detectado)
As funcionalidades da aplicação são
lembradas facilmente? (por exemplo, é fácil
lembrar a função de cada marcador)
Como é a curva de aprendizagem dos
usuários iniciantes?
Usuários experientes podem utilizar a
aplicação de maneira otimizada? (por exemplo,
eles não assistem os videos introdutórios)
É fácil posicionar o marcador para a câmera/
sensor? (orientação/posição)
A aplicação auxilia o usuário durante a
interação? (por exemplo, instruir a mostrar
um marcador)
A aplicação exige algum pré-requisito?
(câmera, marcador, dispositivo móvel,
GPS, posição do usuário, luz, impressão de
marcador, calibragem)
0,0,0
Fácil de aprender
0,0,0
Fácil de usar
1,0,0
É necessária uma câmera/webcam
e o usuário em uma determinada
posição.
4,4,4
O baixo desempenho afeta a
interação.
A aplicação continua funcionando de forma
correta quanto vários marcadores estão
visíveis na cena?
3,4,4
O sistema se perde quando um
novo usuário aparece na cena.
2,1,3
1,2,1
154
O usuário deve ficar em ma posição
fi xa para calibrar o sistema
A aplicação disponibiliza um vídeo,
um manual e a silhueta da facilitar
o posicionamento do usuário.
5. Conclusões
Este capítulo apresentou dois métodos para avaliação de usabilidade de aplicações de RA. Estes
métodos foram aplicados a dois estudos de caso voltados à área de Marketing e Moda. Através dos testes de usabilidade, foi possível verificar que:
• A principal desvantagem da aplicação da área automotiva é a falta de opções de interação,
dada a simplicidade da aplicação. Porém, ela foi melhor avaliada pelos usuários;
• A aplicação de acessórios não utiliza marcadores (markerless), exigindo que o usuário fique
em uma posição pré-definida, o que gera desconforto aos usuários;
• A posição e escala do conteúdo virtual adicionado à aplicação de acessórios não são exatos, o
que causa frustração aos usuários.
• A curva de aprendizagem de ambas as aplicações não é rápida. Porém, como a aplicação de
acessórios não utiliza marcadores, torna-se mais intuitiva;
• Os botões da interface da aplicação de acessórios não funcionam de forma apropriada. Além
disso, a escala e o posicionamento dos objetos não são precisos;
• As opções do menu da aplicação acessórios não funcionam adequadamente: ao clicar na seta
“para baixo” ou “para cima” para navegar pelas opções, o menu inicia uma animação de deslizamento vertical dificultando o clique na opção desejada;
• Foi observado que mulheres com cabelos soltos tiveram mais dificuldade de interagir com a
aplicação de acessórios, mesmo àquelas que deixaram a orelha à vista. Atingiu-se um melhor
resultado com o cabelo preso.
• A inspeção de usabilidade (Eficiência, Eficácia e Satisfação) resultou que:
• A aplicação da área automobilística demonstrou uma boa eficiência e eficácia. Porém, não
obteve sucesso em relação à satisfação. O principal fator limitante foi a falta de opções de
interações, como, por exemplo, a customização do carro e a movimentação do mesmo. Além
disso, em todos os testes, a opção de interação com a luz acesa não fez com que o modelo 3D
acendesse os faróis, levando os usuários à frustração em relação a este recurso;
• A variável Satisfação obteve melhores resultados na aplicação de acessórios. Os aspectos medidos pelas outras variáveis devem ser aprimorados, principalmente o sistema de tracking,
tanto durante a calibração quanto ao rastreamento. Devido a falhas de calibração, a escala
dos objetos não estava correta em diversos usuários. Em mais de 80% dos casos o colar não
ficou proporcional ao tamanho dos usuários. Além disso, não existe uma opção de nova
calibração disponível.
Com base no experimento realizado é possível concluir que o método de avaliação de usabilidade
de sistemas de RA aqui proposto foi eficaz na detecção dos problemas de usabilidade. Além disso, o
método mostrou-se relativamente fácil de aplicar e economicamente viável.
155
Referências
Avouris, N.M. (2001).“An introduction to software usability. Workshop on Software Usability”. In: Proceedings of the
8th Panhellenic Conference on Informatics. v. 2, p. 514-522.
ISO 9241-11(1998).”Ergonomic requirements for office work with visual display terminals (VDTs) -- Part 11:
Guidance on usability”.
Kostaras, N.N. e Xenos, M. N. Xenos (2009). ”Assessing the usability of augmented reality system,” in 13th
Panhellenic Conference on Informatics, Greece.
Lauesen, S. (2005). “User Interface Design: A software engineering perspective”, Pearson Education, Great
Britain, ISBN 0 321 18143 3, 2005.
Likert, R. (1932) “A Technique for the measurement of attitudes”. Archives of Psychology, 140, 1-55.
Martins, V. R. , Makihara, E.L., Soares, L.V. , Mattos, V.B. ; Guimarães, M. P. (2012).“Métricas de Usabilidade para
Aplicações de Realidade Aumentada”. In: Conferencia Latinoamericana en Informática, Medellin. XXXVIII
Conferencia Latinoamericana en Informática.
Nielsen, J.(1993).”Usability Engineering”. Academic Press, Cambridge, MA.
Nielsen, J. (1994). Heuristic Evaluation. In: J. Nielsen (ed.) Usability Inspection Methods. John Wiley, New York,
1994.
Orth, A.I. (2005). “Interface Homem-Máquina”. Porto Alegre: AIO.
Preece, J.; Rogers, Y.; Sharp, H. (2007). Interaction design: beyond human-computer interaction, Wiley, New
York.
Rocha, H. V.; Baranauskas, M. C. C. (2003). “Design e avaliação de interfaces humano-computador”, NIED,
Instituto de Computação, Unicamp, Campinas.
Rubin, J., Chisnell, D. (2008). “Handbook of usability testing: how to plan, design and conduct effective tests”.
2nd ed., New York: John Wiley & Sons.
Salvador, V. F. M., Oliveira Neto, J. S., Guimarães, M. P. (2009) “Levantamento de heurísticas para avaliação de
interfaces do usuário baseadas em voz”. In: Interaction South America, São Paulo, 2009.
Sommerville.I.(2011). ”Engenharia de Software”, 9th ed., Addison Wesley, ISBN 978-85-7936-108.
Sutcliffe, A.; Gault, B. (2004). “Heuristic evaluation of virtual reality applications”. In: Interacting with
Computers 16, New York: Elsevier.
Zainuddin, N.M.M.; Zaman, H.B.; Ahmad, A. (2011) “Heuristic Evaluation on Augmented Reality Courseware
for the Deaf”. In 2011 International Conference on User Science and Engineering.
156
157
ARRUDA, Ermano Ardiles; FIGUEIREDO, Lucas Silva; TEICHRIEB, Veronica.
Percepção Natural de Profundidade: Uma Análise do Fish Tank Virtual Reality.
Percepção Natural de Profundidade:
Uma Análise do Fish Tank Virtual Reality
Ermano Ardiles Arruda
Lucas Silva Figueiredo
Veronica Teichrieb
Abstract
In this work the topic of interactive visualization is approached focusing on Natural Interaction and
Depth Perception aspects. The technique called Fish Tank Virtual Reality (FTVR) is addressed with more
details. This technique is tested in accordance to aspects such as physical and cognitive freedom of the
user. Furthermore, its implementation is discussed and detailed to meet these aspects. Finally, the applicability of the technique of FTVR is studied and a number of applications are illustrated and discussed in
order to understand the contributions they got by using FTVR, and in which direction these contributions
are going, taking into account areas including Virtual Reality and Augmented Reality.
Resumo
Neste trabalho o tema de visualização interativa é abordado com foco nos aspectos de Interação Natural
e Percepção de Profundidade. Em mais detalhes, a técnica Fish Tank Virtual Reality (FTVR) é abordada.
A técnica é analisada segundo os aspectos primados como a liberdade física e cognitiva do usuário. Mais
além, sua implementação é discutida e detalhada visando atender estes aspectos. Por fim, a aplicabilidade da técnica é estudada e uma série de aplicações do estado da arte são ilustradas e analisadas, com a
finalidade de entender as contribuições que existem no uso do FTVR para visualizações interativas, em
que direção estas contribuições caminham, levando em conta as áreas de Realidade Virtual e inclusive
Realidade Aumentada.
1. Introdução
É dito que, em certos níveis de expertise, as ferramentas que o homem usa passam a ser não apenas
ferramentas, mas extensões de seu próprio corpo, e o seu uso passa a ser totalmente instintivo e natural. Tais ferramentas passam a integrar a realidade do homem de uma forma profunda e inseparável.
157
Em sua tentativa de aprimorar as ferramentas que utiliza, o homem está sempre criando, aprimorando
e recriando novas. Os computadores são um dos principais instrumentos do homem moderno, e estão
de tal modo entrelaçados com a vida de tantas pessoas, que é difícil imaginar um mundo sem computadores. Essas mesmas ferramentas são alvos de melhorias e aprimoramentos contínuos. E, se fosse
possível criar um instrumento tão entrelaçado com a vida humana, e de sua realidade, que essa própria
ferramenta se tornasse a realidade por si mesma, ou fosse capaz de criá-la?
As pesquisas em Realidade Virtual (RV) se dedicam a explorar essa capacidade que o instrumento
computador possibilita: criar ambientes, por vezes concretamente impossíveis, mas cuja simulação
artificial é capaz de dar a impressão de realidade, ou possuir potencial de ser indissociável entre o que
é real e o que não o é, ou até mesmo criar percepções que antes seriam impossíveis. Várias técnicas
foram desenvolvidas nessa área, e o arcabouço teórico já existe, embora os desenvolvimentos práticos
ainda se encontrem, naturalmente, muito distantes de tal objetivo ideal. Apesar disso, RV é um objeto
de estudo interessante não apenas pelo seu ideal longínquo temporal e tecnologicamente, mas por sua
intrínseca interdisciplinaridade e diversão propiciada [Brooks 1999].
Como um exemplo, a Figura 1 apresenta um simulador da ponte de comando de um navio construído em Warsash que representa um navio mercante genérico, apesar da vista do navio a partir da
ponte poder ser customizada para representar um tipo de navio ou até um navio em particular. De
forma similar, a aparência e os controles podem ser customizados até um pequeno nível, para simular
diferentes configurações de ponte.
Figura 1. Simulador da ponte de comando de um navio no Warsash Maritime Centre [Brooks 1999].
O presente trabalho irá apresentar um panorama básico sobre RV, e algumas de suas técnicas.
Em especial será discutida com mais detalhes uma implementação simples e de baixo custo da técnica
conhecida como Fish Tank Virtual Reality, a qual pode servir como uma boa introdução à RV e alguns
de seus conceitos.
158
Na subseção 1.2, é explanada a visão geral sobre renderização interativa em ambientes de RV,
debatendo a sua origem e significado científico. Também, são introduzidos alguns conceitos acerca da
percepção da profundidade humana. Na subseção 1.3, este trabalho aborda de forma mais detalhada
a implementação da técnica de Fish Tank Virtual Reality, seu arcabouço matemático e módulos adicionais utilizados, como o rastreamento de faces. Ao fim, a monografia é concluída com uma reflexão
acerca das aplicações que se beneficiariam com o uso de tal técnica, e são esboçadas algumas perspectivas futuras sobre RV e Realidade Aumentada (RA) em relação à técnica estudada.
2. Visão Geral
Realidade Virtual, ou simplesmente RV, pode ser definida de duas formas diferentes. A primeira
se refere à utilização de computadores e interfaces humano-computador para simular um mundo tridimensional contendo objetos interativos, de tal forma que cria-se uma forte sensação de presença real
no ambiente [Bryson 1996]. A segunda forma de definir RV adota uma perspectiva independente da
existência de computadores, ou qualquer dispositivo computacional. Assim, ela é definida com base na
noção de telepresença, isto é, o ato de experimentar estar em um ambiente por intermédio de algum
meio de comunicação [Steuer 1992]. Dessa forma, RV é vista como sendo um ambiente real ou simulado no qual se experimenta a telepresença. Resumidamente, RV é a simulação da presença de uma
pessoa em um ambiente, seja ele real ou imaginário. Pesquisadores em RV buscam novas formas de
imersão, visando diminuir as fronteiras de interação entre homem e máquina. Assim, são levados em
consideração todos os sentidos humanos no esforço de simular fielmente tal percepção, em especial,
neste trabalho, a visão.
2.1. História
A área de estudo em RV é multidisciplinar. Os principais primeiros estudos na área datam da
década de 60, frutos do trabalho de Ivan Sutherland [Wayne 2003]. Em uma aula como convidado,
intitulada The Ultimate Display [Sutherland 1965], ocorrida em 1965, Ivan Sutherland forneceu uma
nova visão, a possibilidade de criação de um mundo completamente virtual, e uma expansão no modo
como interagimos com os computadores e recebemos feedback dos mesmos.
Em sua visão, o que chamamos de monitores, hoje em dia a principal interface de saída dos computadores, são completamente obsoletos. Isso se deve ao fato de que os monitores tradicionais se aproveitam apenas de uma dimensão de percepção, a informação estática bidimensional, i.e., imagens. Ele,
portanto, sugere que os monitores deveriam ser melhorados de forma a fornecer uma experiência sensorial mais rica, incorporando outras fontes de estímulos para os sentidos humanos, como estímulos
olfativos e táteis, por exemplo. Mais ainda, na concepção de Sutherland, os monitores deveriam ter o
poder de recriar ambientes completos, explorando toda a nossa percepção sensorial ao ponto que tais
ambientes parecessem completamente reais. Dessa forma, em suas próprias palavras, uma cadeira criada por esse monitor seria boa o bastante para se sentar, e uma bala disparada por uma arma seria letal.
159
Desde então, várias pesquisas se intensificaram rumo à criação de sistemas de RV que possibilitassem uma maior imersão de interação, tais como a Cave Automatic Virtual Environment (CAVE)
[Cruz-Neira et al. 1993], Head-Mounted Displays (HMDs) [Sutherland 1968], Fish Tank e Whale Tank
Virtual Reality Displays [Ware et al. 1993] [Maksakov 2009]. Apesar de possuírem diferenças entre si,
esses sistemas adicionam uma camada sensorial comum, que é a percepção de profundidade no ambiente, através da renderização da cena de acordo com o ponto de vista do usuário.
2.2. Interação Natural
O conceito de Interação Natural pode ser abordado e definido em relação às liberdades físicas e
cognitivas que são apresentadas ao usuário durante a interação. Quão maiores sejam estas liberdades,
mais natural será a experiência. Este conceito pode ser resumido pela quebra de paradigma na interação: o que antes era atribuído ao usuário como tarefa, entender a interface, estuda-la, treinar para
usá-la, agora passa a ser tarefa do sistema. Ou seja, o sistema passa a ser responsável por entender o
usuário e não mais o contrário, o que pode ser traduzido como liberdades físicas e cognitivas oferecidas
ao usuário pelo sistema, deixando este se expressar como bem entender. Assim, a responsabilidade de
interpretação das intenções do usuário passa a ser cada vez maior por parte do sistema [Valli 2005].
Liberdade Física
A liberdade física trata o aspecto de expressão do usuário no mundo real. Seja através de gestos
com a mão, com o corpo inteiro, através do toque, da fala ou qualquer outra forma de interação, o usuário precisa expressar suas intenções fisicamente. Essa expressão pode ser um movimento do corpo, um
comando de voz, ou até um olhar direcionado. Independente de que interação será realizada, para que
esta seja reconhecida pelo sistema se faz necessária uma interface que realize a captura e o reconhecimento da interação. É na definição desta interface que surgem as restrições físicas.
Analisando mais especificamente as interações por gestos corporais, é comum fazer uso de dispositivos anexos ao corpo para assim medir a movimentação de cada parte deste, através de sensores
como acelerômetros e giroscópios. Por exemplo, para entender o posicionamento relativo da mão, obter conhecimento da angulação das articulações de cada dedo, é comum usar luvas hápticas, equipadas
com diversos sensores [Prachyabrued e Borst 2012]. Em geral, os dispositivos anexos carregam vantagens expressivas em relação à precisão e ao tempo de resposta. Por outro lado, eles restringem a liberdade física do usuário de forma que se tornam um empecilho para a interação. Este incômodo pode
surgir tanto no momento inicial em que o usuário precisa vestir/anexar o dispositivo, quanto ao longo
da interação, causando desconforto, restrições de movimento, cuidado excessivo com o equipamento e
até acelerando o processo de fadiga a depender da estrutura e peso do dispositivo.
Avançando no grau de liberdade física oferecida ao usuário, existem dispositivos que não requerem que o usuário os vista ou os anexe a alguma parte do corpo, pois apenas precisam ser segurados
[Lee 2008]. Apesar de a priori a diferença ser pequena, o fato de o usuário poder pegar e largar o
dispositivo rapidamente lhe oferece uma liberdade chave para o uso do sistema com pausas. De fato,
160
a sensação de que o sistema lhe prende durante o uso tende a ser bem menor se o usuário é capaz de
largar o dispositivo, com pouco esforço e tempo, sempre que sentir a necessidade de uma pausa.
Por fim, já é possível encontrar hoje na literatura e na indústria diversos métodos que são capazes
de capturar os movimentos do usuário à distância sem a necessidade que este vista ou segure qualquer
dispositivo. Usando câmeras e/ou sensores de profundidade é possível estimar, por exemplo, a pose
da cabeça do usuário [Prachyabrued e Borst 2012], da sua mão [Stenger et al. 2003], ou do seu corpo
como um todo [Chang e Lin 2010]. No entanto, é importante ressaltar que mesmo estes dispositivos
apresentam restrições físicas que podem se tornar uma dificuldade para a interação. Por exemplo, o
dispositivo Leap Motion [Leap 2013] se propõe a rastrear com precisão e alta taxa de visualização os
dedos do usuário em um subespaço de Xm³ acima do sensor. Este subespaço é uma limitação física
do sensor e por vezes pode ser insuficiente para a interação, requerendo que o usuário se adeque às
restrições do sensor para interagir com o sistema. Além do mais, o fato desta restrição não estar demarcada explicitamente para o usuário pode levar o mesmo ao erro contínuo de experimentação das
fronteiras de captura do sensor. Esse efeito pode ser observado em diversos jogos para o Xbox 360 que
fazem uso do Kinect [Microsoft 2013] para rastrear o corpo do usuário. Nestes jogos existe um esforço
para educar o usuário sobre o seu posicionamento na cena de forma que o sensor possa capturar seus
movimentos corretamente.
Todas estas restrições físicas vêm sendo abrandadas com a evolução dos dispositivos de captura
e reconhecimento. É notável o surgimento e popularização de novas tecnologias que se propõem a
rastrear o usuário sem que este precise de qualquer equipamento junto ao seu corpo, o que revela a
tendência de dar possibilidade para que as novas aplicações ofereçam interações mais naturais. Este é
um dos motivadores para revisitarmos técnicas de interação para visualização, como o Fish Tank VR,
diante deste novo panorama tecnológico.
Liberdade Cognitiva
Ainda que o usuário se sinta livre para mover-se durante a interação com o sistema, o processo de
entendimento de suas intenções pode não estar preparado para transformar as informações capturadas
em comandos intuitivos. Isto pode acontecer por restrições do método de rastreamento e reconhecimento ou simplesmente por um design da interação inadequado.
Um caso comum em jogos digitais do tipo plataforma é que usuários inexperientes tentam fazer o
personagem se mover inclinando e/ou transladando o joystick para direita ou para a esquerda. Nestes
jogos, em geral, o personagem reage somente a comandos enviados pelos botões do joystick e não à
sua inclinação ou posicionamento. Assim, a reação intuitiva do usuário é descartada pelo sistema por
limitações do mesmo, o que causa frustração por parte do usuário, dificultando a execução da tarefa.
Apoiados nesta metáfora de interação, jogos como Flower e Mario Kart passam a usar os sensores inerciais dos joysticks para a navegação no jogo, sugerindo formas de interação mais intuitivas.
Mais além, existem casos em que apesar de o usuário usar o corpo como ferramenta de interação,
a mesma não ocorre de forma natural. Em [UM3DLab 2011] é demonstrado um método de navegação em ambientes virtuais apresentados em CAVEs. O Kinect é utilizado para rastrear o corpo do
usuário e gestos são definidos para que o usuário possa fazer sua personificação (avatar) no ambiente
161
virtual seguir adiante, virar para esquerda, para direita, etc. No entanto, os gestos corporais podem
ser atribuídos a funções de forma a confundir o usuário, dificultando a interação. Por exemplo, em
[UM3DLab 2011] o gesto de levantar o braço direito foi atribuído ao ato de mover o avatar para frente.
A priori este gesto é um gesto simples de ser executado e sua memorização também é simples, porém
basta o fato de o usuário ter que memoriza-lo para ocupar parte de sua carga cognitiva [Valli 2005].
Assim, se mais gestos são adicionados e precisam ser memorizados, o usuário tem sua interatividade
limitada, pois estará ocupando parte considerável de sua carga cognitiva no ato de traduzir intenções
em comandos aceitos pelo sistema. Como lembrado em [Valli 2005] os seres humanos são capazes de
tratar simultaneamente 5 a 9 elementos que ocupam sua carga cognitiva. Para uma interação natural, é
essencial ocupar o mínimo possível desta carga, fazendo com que a interação seja intuitiva o suficiente
para que o usuário não precise revisitar sua memória constantemente procurando formas específicas
de interagir. Assim, o usuário pode usar a maior parte de sua carga na execução da tarefa em si, sendo
habilitado a resolver problemas mais complexos, por exemplo.
Sobre o uso de rastreamento de faces para visualizações interativas, é possível usar a informação
rastreada de diversas formas. Especificamente a técnica Fish Tank VR apresenta uma metáfora poderosa de interação. Através do rastreamento do ponto de vista do usuário a técnica se propõe a transformar monitores (ou outros displays) em dispositivos dotados de profundidade. Neste caso, a tela passa a
ser interpretada como uma janela para o mundo virtual, podendo ser aplicada a praticamente qualquer
cenário de aplicação em 3D. A metáfora oferecida é intuitiva visto que interagimos de forma análoga
com espaços reais em nosso cotidiano.
Em adição, a popularização massiva das câmeras, hoje inclusive acopladas a laptops e smartphones, juntamente com a evolução dos algoritmos de rastreamento de face, que dispensam dispositivos
anexos à cabeça, se tornam fatores motivadores para uma nova análise da evolução no uso desta metáfora. O cenário tecnológico caminha para interfaces mais naturais e o panorama atual levanta a
possibilidade do uso massivo da técnica Fish Tank VR.
2.3. Sistemas Head Coupled
Um sistema que se habilita a rastrear a posição e orientação da cabeça do usuário para corrigir
a perspectiva da renderização é um sistema Head Coupled [Stevenson 2002]. Trata-se de um sistema
que combina ou é acoplado à informação espacial da cabeça do usuário para realizar algum trabalho.
Em vários ambientes de RV a implantação de um sistema head coupled é considerada pelo ganho na
percepção de profundidade, assim aumentando a imersão do usuário durante sua experiência com o
sistema. Isso é válido para sistemas implantados em CAVEs, renderizados em HMDs ou em displays
mais simples como monitores e projeções em uma única parede através da técnica Fish Tank Virtual
Reality Displays [Stevenson 2002].
Em 1968, Ivan Sutherland descreveu seu projeto de dispositivo de visualização chamado head-mounted three dimensional display [Sutherland 1968]. Hoje em dia, ele passou a ser largamente chamado apenas de Head Mounted Display (HMD). Como discutido previamente, nosso cérebro também
percebe a profundidade na cena a partir de duas imagens diferentes obtidas a partir do ponto de vista
de cada um de nossos olhos. Os HMDs possuem uma facilidade para este tipo de renderização visto que
162
já se encontram acoplados à cabeça do usuário, e a estereoscopia é conseguida simplesmente dedicando
duas imagens diferentes no display, uma para cada olho. Além disso, de forma geral os HMDs consideram o motion parallax, pois sua importância nos critérios de sensação de profundidade e imersão não é
suplantada pela estereoscopia. De fato, estudos demonstram que as duas variáveis são complementares
para se conseguir uma visualização mais completa, no entanto, vale ressaltar que se tratados independentemente, considerando a atividade de estimar a profundidade da cena, o motion parallax pode ser
considerado mais importante do que a estereoscopia [Sutherland 1968] [Ware et al. 1993].
Desta forma, um HMD consiste de um par de óculos com um monitor para cada olho e, além
disso, um dispositivo que rastreie a posição espacial da cabeça do usuário, a fim de apresentar as imagens corretamente para cada retina do usuário de acordo com o ponto de vista do mesmo (orientação
e posição da cabeça). O pipeline de execução do projeto proposto por Sutherland primeiro adquiria a
posição da cabeça do usuário e depois passava essa informação para o sistema computacional responsável por calcular os próximos frames que seriam mostrados ao usuário através dos óculos. Assim, o
usuário podia se mover e olhar para diferentes posições, vendo diferentes partes da cena virtual que
foi desenhada à sua volta [Sutherland 1968]. Atualmente, existem versões muito mais modernas de
HMDs, cada vez mais leves e arrojados, mas o princípio continua sendo o mesmo. Apresentar imagens
ao usuário, de acordo com sua posição no espaço. A Figura 2 ilustra exemplos de HMDs, dando uma
ideia da evolução deste tipo de tecnologia em respeito a características de ergonomia, como campo de
visão, tempo de resposta, resolução das imagens, entre outros.
Figura 2. Versões de HMDs: a) versão primordial construída por Sutherland [Sutherland 1968]; b)
HMZ-T2 da Sony, propondo um HMD mais arrojado e a um preço comercial [Sony 2013]; c) Oculus Rift
proposto pela Oculus VR, que visa proporcionar um maior campo de vista em relação a outros HMDs (à
direita da parte c), além de atingir uma taxa de atualização maior [Oculus 2013].
163
Uma CAVE se trata de uma instalação para sistemas de RV que utiliza projetores, projetando em
várias paredes em volta do usuário, para assim adicionar imersão à experiência. As CAVEs podem ter
um número variado de lados projetados, geralmente entre 3 (esquerdo, frente e direito) e 4 (o mesmo
que uma CAVE de 3 lados com a adição da projeção no chão), podendo chegar em 6 lados (incluindo
o teto e atrás). Nestas instalações, em geral o sistema de visualização interativa é resolvido pelo uso
de óculos 3D acoplados com marcadores infravermelhos para o rastreamento da posição e orientação
da cabeça. Assim, o rastreamento da cabeça é calibrado com todas as projeções, de forma que a estereoscopia e a renderização de acordo com o ponto de vista do usuário são comumente aplicados neste
cenário [Halarnkar et al. 2012] [Cruz-Neira et al. 1993].
Um dos principais motivadores para o uso de CAVEs é a possibilidade de criar um ambiente
propício para visualização científica [Cruz-Neira et al. 1993]. Os usuários podem caminhar pelo ambiente, geralmente em uma área que varia entre 4m² e 9m² e enxergar o universo virtual de uma série
de ângulos diferentes visto que as projeções estão por todos os lados. A Figura 3 ilustra o conceito e
um exemplo de aplicação em CAVEs. Na parte a) da figura podem ser observados os projetores, sendo
alguns deles voltados para espelhos para economizar espaço na instalação, visto que a projeção precisa
estar a uma distância mínima do projetor para ocupar o espaço alocado na parede destinada. Além
disso, ainda na parte a) pode ser visto que o usuário está usando óculos justamente para fornecer os
efeitos de estereoscopia e motion parallax.
Figura 3. CAVE: a) conceito; b) exemplo de aplicação em que um usuário navega por um ambiente virtual
obtendo uma visualização simulada de como seria realizar a mesma navegação no mundo real.
Por sua vez, a técnica Fish Tank Virtual Reality (FTVR) se diferencia dos HMDs e CAVEs por se
propor a aplicar o conceito de visualização head coupled para displays planares, sejam estes monitores,
dispositivos portáteis (smartphones e tablets) ou até projeções em uma única parede ou tela. Por se propor a cenários mais comuns e de baixo custo, a técnica FTVR se destaca por sua vasta aplicabilidade.
O cenário tecnológico é propício para o uso do FTVR. Como será discutido na sequência, atualmente
existem algoritmos de rastreamento de face/cabeça que usam apenas informações de imagens coloridas
164
a um baixo custo de processamento. Por sua vez, as câmeras necessárias para este processamento são
facilmente encontradas, acopladas em diversos dispositivos, como smartphones, tablets e laptops.
Assim, considerando os casos em que não se aborda a estereoscopia, esta técnica apresenta um
potencial de ser inserida em praticamente qualquer aplicação de RV, oferecendo um ganho na interatividade em relação à percepção de profundidade. Recapitulando, segundo o experimento descrito em
[Ware et al. 1993], é averiguado que a adição de uma renderização head coupled reduz consideravelmente o erro na execução da tarefa de definir a profundidade de partes da cena. Mais além, também
é averiguado que a adição da estereoscopia apresenta uma redução em relação ao mesmo erro. Além
disso, o fato de não ser necessário o uso de nenhum equipamento extra (ex.: óculos) para a visualização
com o efeito motion parallax é uma característica valiosa no contexto de liberdade física dentro do
conceito de Interação Natural.
Desta forma, motivados pelas vastas possibilidades de aplicabilidade do FTVR, e também por sua
congruência em relação aos conceitos relacionados a uma interação mais natural (como liberdade física
e uma metáfora sólida de visualização interativa), este trabalho visa estudar mais a fundo os aspectos
da técnica. Em sequência, serão apresentadas suas principais características, bem como as opções de
rastreamento para a captura da pose da face do usuário.
2.4. Percepção de Profundidade
Os seres humanos estimam profundidade de objetos a partir de diversas variáveis. Existem variáveis psicológicas, fisiológicas, monoculares e binoculares [Mello 2013]. Existem ainda fatores empíricos associados [Purves et al. 2002]. Esses fatores contribuem para a percepção de profundidade humana. Tais fatores são considerados ao se criar ambientes imersivos de visualização [Bradski e Kaehler
2008], citados anteriormente.
Entre as variáveis psicológicas, a perspectiva é a que merece atenção especial neste trabalho. Perspectiva é o nome dado ao efeito dos objetos aparentarem possuir tamanhos diferentes conforme se está
próximo ou distante dos mesmos. Matematicamente, trata-se de um tipo de projeção sobre um plano,
chamado plano da imagem. Uma das características da projeção em perspectiva é que quanto mais
distante um ponto 3D estiver do centro de projeção, este ponto tenderá a ficar mais próximo do centro do plano da imagem. Isto significa que objetos tenderão a aparentar menores conforme estiverem
mais distantes, e o contrário também é verdadeiro. Assim, a objetos maiores são atribuídos graus de
profundidade mais próximos.
Outras variáveis psicológicas como a oclusão e as sombras se tornam dicas importantes para o
ser humano definir a profundidade de cada objeto na cena. Por exemplo, os objetos ocluídos na cena
são definidos instintivamente como mais distantes daqueles que os ocluem. O mesmo acontece para
o sombreamento na cena. A sombra de um objeto sobre outro indica que para aquele ponto de vista, o
primeiro está mais a frente.
Estas, dentre outras variáveis, são indicativos de profundidade que podem ser observados mesmo
em uma cena estática, como em uma foto por exemplo. Ao mesmo tempo, estas variáveis são inerentes
à criação de cenas virtuais, durante o processo de modelagem 3D dos objetos da cena e das fontes de
luz. Quando a cena é renderizada estes efeitos são demonstrados automaticamente visto que, por exem165
plo, as projeções são em perspectiva, consideram a oclusão visual e também a iluminação. Assim, ao
olhar para a cena o usuário é capaz de distinguir a profundidade de cada elemento nesta. No entanto,
mesmo podendo definir a profundidade de cada elemento na cena, o usuário continua a ter a sensação
de que observa um plano à sua frente (plano da imagem).
Para quebrar esta sensação é preciso oferecer ao usuário formas de visualização que explorem
suas capacidades fisiológicas além das psicológicas. As duas principais ferramentas para atingir esse
objetivo são a estereoscopia e o motion parallax.
A estereoscopia se enquadra dentro das variáveis fisiológicas binoculares. Seu efeito é produzido
combinando duas imagens obtidas a partir de posições ligeiramente diferentes. Mais especificamente,
são geradas duas projeções em perspectiva do ambiente virtual, uma para cada olho. Na sequência o
cérebro humano, ao processar as imagens, é capaz de reconstruir tridimensionalmente o espaço observado, atribuindo valores de profundidade a cada ponto projetado sobre a retina. Esta técnica permite
o usuário, por exemplo, distinguir a profundidade de dois objetos com a mesma aparência na imagem
(plano projetado) que, no entanto, possuem tamanhos reais diferentes.
Por sua vez, o motion parallax é uma variável fisiológica monocular. Este nome é dado ao fenômeno visual dos objetos mais distantes se moverem com velocidade relativa menor que os objetos que
estão mais próximos da posição ocular de um observador em movimento. Assim, ao mover o ponto de
vista (no caso a cabeça), o usuário consegue perceber a movimentação dos objetos observados e então
correlaciona os dados capturados para definir a profundidade de cada parte da cena. Além de ser uma
dica importante para a estimativa da profundidade na cena, o ato de mover a cabeça permite que o
usuário enxergue partes não visíveis, dado um ponto de vista fixo.
De fato, o ideal é combinar as duas variáveis, porém em casos em que cada uma é usada separadamente, já foi averiguado que o motion parallax produz melhores resultados em relação à experiência de
visualização. Neste trabalho, iremos estudar mais profundamente a técnica Fish Tank VR, que tem por
objetivo produzir o efeito de motion parallax em ambientes virtuais de forma calibrada com o mundo
real. A técnica faz parecer que o conteúdo disponibilizado pelo display faz parte da realidade, reagindo
visualmente da mesma forma que qualquer outro objeto real no campo de vista do usuário reagiria.
3. Fish Tank Virtual Reality
A intensão da técnica de Fish Tank Virtual Reality (FTVR) é a de criar a ilusão de profundidade
em um monitor de vídeo tradicional. A adição dessa camada de percepção 3D possibilita uma melhoria na execução de tarefas, principalmente aquelas que envolvem que o usuário indique uma posição
tridimensional no espaço projetado em um monitor [Lee 2008].
3.1. Rastreamento
Primeiramente, para calcular o ponto de vista do usuário é preciso que o sistema tenha conhecimento da posição do sistema visual do usuário. Existem diversos métodos que podem cumprir tal tarefa.
Alguns são mais intrusivos e podem vir a requerer um maior custo de aquisição, enquanto que outros
166
métodos apesar de serem menos intrusivos e mais baratos tendem a necessitar de um processamento mais refinado. Este cenário entre custo de aquisição, necessidade de dispositivos anexos e custo de
processamento em geral, dificilmente apresenta uma solução completa. Mais a frente, apresentaremos
métodos de rastreamento na direção de uma técnica que combine estas qualidades previamente citadas.
Wiimote
Primeiramente, existem vários métodos que utilizam dispositivos anexos à cabeça do usuário para
rastreá-la em tempo real. Em geral, estas técnicas apresentam alta precisão de rastreamento além de
um rápido tempo de resposta, porém requerem a confecção ou aquisição de dispositivos bem específicos os quais não são popularizados o suficiente para serem usados em larga escala. No entanto, recentemente, a técnica FTVR foi demonstrada por Lee [Lee 2008] utilizando o controle do console Nintendo
Wii (chamado Wiimote) para detectar a posição dos olhos do usuário. Lee, em seu trabalhado de título
“Hacking the Nintendo Wii remote” [Lee 2008], descreve sua abordagem para transformar o controle
do Nintendo Wii em um rastreador, para encontrar a posição da cabeça do usuário e, com base nisso,
criar um ambiente FTVR. Esta abordagem levanta uma vantagem em relação às anteriores relacionada
aos equipamentos necessários para realizar o rastreamento. O Wiimote, por ser um dispositivo disponível em larga escala, é uma ferramenta acessível para desenvolvedores e usuários por todo o globo.
Em relação ao funcionamento do rastreamento, este é possível dado que o controle do Nintendo
Wii possui uma câmera capaz de detectar o espectro infravermelho da luz a uma alta taxa de atualização (por volta de 100 quadros por segundo). Lee então criou óculos adaptados com dois emissores de
luz infravermelha e o utilizou para rastrear a cabeça do usuário. Por fim, o controle do console foi posicionado na frente da televisão, de forma a capturar a luz emitada pelos óculos. Por fim, um PC passa
a ser responsável pelo processamento das imagens capturadas pelo Wiimote. Dada a distância entre os
pontos na imagem, a posição 3D da cabeça do usuário é estimada. A Figura 4 ilustra os equipamentos
utilizados para o rastreamento da cabeça do usuário.
Figura 4. Dispositivos utilizados para rastrear o ponto de vista do usuário por Lee [Lee 2008]: a) versão do
Wiimote disponível no mercado; b) Wiimote aberto com detalhe em sua câmera infravermelho; c) óculos
com emissores infravermelhos nas laterais.
No entanto, existem algumas considerações quanto a estas abordagens de rastreamento a partir de
dispositivos anexos. A intrusão representada pela necessidade de se utilizar óculos especiais, ou outros
equipamentos como uma combinação de sensores inerciais, pode dificultar a interação prolongada,
167
além de restringir o uso do sistema. Por exemplo, em ambientes abertos e não controlados, pode não
ser inconveniente pedir para que os usuários experimentem o sistema com o mesmo óculos e que tenham o cuidado necessário com o equipamento. Além disso, mesmo considerando a abrangência dos
equipamentos sugeridos por Lee, o uso de uma câmera comum é preferível. Em outras palavras, apesar
do Wiimote ser disponível em larga escala, este não é um dispositivo periférico tão comum para os
computadores quanto uma câmera. Por outro lado, é de fato possível utilizar uma câmera para rastrear
a cabeça do usuário, e isso pode ser alcançado utilizando-se algoritmos de rastreamento como o TLD/
Predator [Kalal et al. 2010], descrito adiante.
TLD/Predator
O algoritmo de rastreamento de longo prazo, TLD (Tracking Learning Detection), permite que a
partir de um exemplo inicial seja dado início a um processo de contínuo aprimoramento de um classificador binário dentro de uma sequencia de imagens [Kalal et al. 2010]. O processo de aprendizado é
guiado por restrições estruturais, as quais o autor do algoritmo nomeia de P-N Learning Constraints.
A partir do exemplo inicial, um rastreador de curto termo é utilizado para rastrear o objeto desejado
ao mesmo tempo em que o detector tenta formular novas hipóteses de onde estaria o objeto, em um
dado frame. A decisão se o rastreamento ou a melhor hipótese do detector deve prevalecer é feita pelo
modelo online de decisão, criado até então para o objeto rastreado.
Sempre que o tracker prevalece, é criado um novo conjunto de treinamento para o classificador,
que é então aprimorado através das P-N Learning Constraints. Estas ditam que um exemplo dever ser
positivo (P) se estiver com um grau de overlapping dentro de um certo limiar estipulado, ou negativo
(N), caso contrário. Assim são criados novos exemplos de treinamento. E dessa forma, é possível demonstrar que existem situações em que o sistema decresce a sua taxa de erro com o passar o tempo,
assim detectando cada vez com mais precisão e com maior chance de sucesso o objeto que se quer rastrear. De maneira geral, o pipeline de processamento pode ser representado pelo diagrama apresentado
na Figura 5.
168
Figura 5. Modelo online do objeto rastreado, contento exemplos positivos e negativos.
O TLD é conhecido também como Predator, dada a sua eficiência em rastrear o alvo que lhe foi
atribuído. Em casos críticos, o TLD/Predator pode perder o alvo. Para esses casos, o algoritmo é então
reinicializado com a ajuda de um segundo algoritmo de aprendizagem, chamado Adaboost, cuja implementação já existe na biblioteca OpenCV [Bradski e Kaehler 2008]. A partir deste rastreamento de
faces é estimada a posição espacial da cabeça do usuário, utilizada para configurar o ambiente FTVR
adequadamente, como será explicado em mais detalhes logo adiante. A grande vantagem de se utilizar
o rastreamento de faces baseado em imagens de uma câmera tradicional é o baixo custo e o fato de
não haver a necessidade de configurar ambientes complexos ou artesanais para o cálculo da posição da
cabeça do usuário, como é o caso da utilização do Wii remote.
Por fim, o rastreamento dá como saída as delimitações de um retângulo (bounding box), dentro do
qual se encontra a face do usuário (Figura 6). É com base nas dimensões desse retângulo, no ângulo de
visão da câmera e nas dimensões da imagem obtida pela câmera que será calculada a posição da cabeça
do usuário no espaço.
169
Figura 6. Resultados usando o rastreamento de faces com TLD (aka Predator).
3.2. Estimativa de Posição Espacial
Queremos computar a posição no espaço da face do usuário (x’, y’, z’) a partir de um retângulo que
a delimita. Para resolver esse problema, partimos do princípio de que toda câmera possui um ângulo
de visão; este ângulo determina o campo de visão (field of view, ou FOV) de uma câmera, como mostra
a Figura 7.
Figura 7. FOV de uma câmera, visto de cima.
170
A Figura 7 mostra um objeto de tamanho m situado a uma distância z da câmera, de tal forma que
esse objeto ocupa toda a lateral da imagem da câmera, que por sua vez possui largura w. Ao se realizar
esse experimento, é possível calcular o ângulo de visão horizontal, em radianos, da câmera da seguinte
maneira:
Assim, fixando-se a largura da imagem obtida pela câmera, w, é possível obter a razão entre o ângulo de visão horizontal e a quantidade de pixels de uma imagem obtida por essa câmera. Chamemos
essa razão de RPP (Radians Per Pixel), a qual é descrita por:
Consequentemente, um retângulo detectado pelo TLD/Predator representando a face do usuário
pode ser representado como apresentado
p
na Figura
g 8.
Figura 8. Retângulo detectado pelo TLD/Predator, visto de cima.
A face do usuário possui largura, em unidades espaciais reais, de magnitude m. Em pixels, a face
do usuário ocupa uma área da imagem de largura w’. Assim sendo, utilizando a razão RPP, podemos
calcular α’ e, por fim, a coordenada de profundidade z da seguinte maneira:
Trigonometricamente, portanto, podemos deduzir que:
171
Por sua vez, as coordenadas x’ e y’ podem ser calculadas com base nas dimensões reais horizontal
e vertical do monitor, rw e rh, respectivamente. Dado o baricentro do retângulo (xp, yp), é possível se
estabelecer a seguinte relação linear entre rw e xp, yp e rh. Em suma, essa relação linear irá mapear as
coordenadas dadas em pixels (xp, yp) para coordenadas espaciais reais, com base nas dimensões reais
do monitor. A Figura 9 ilustra graficamente esse mapeamento para a coordenada xp. Uma vez que o
processo é análogo para a coordenada yp, esse passo será omitido. Dessa forma, então, são calculadas as
coordenadas espaciais da face do usuário (x’, y’, z’), as quais são utilizadas para configurar o ambiente
de renderização, com o propósito de criar o ambiente FTVR.
Figura 9. Remapeamento de xp.
3.3. Cálculo da Matriz de Parâmetros Extrínsecos
A matriz de parâmetros extrínsecos Rt, é composta por uma rotação e uma translação. Esta matriz
é responsável, dentro do pipeline de renderização, por transformar os pontos que estão em um sistema
de coordenadas de referência, chamados de coordenadas de mundo, para o sistema de coordenadas da
câmera virtual. Nesse caso, deseja-se que a câmera virtual esteja situada no próprio olho do usuário,
ou que ela seja ou represente o próprio olho do usuário, de tal forma que o que ele vê na tela é visto de
acordo com sua posição real no espaço. Dada a posição da face do usuário, que nós chamaremos de E =
(x’, y’, z’, 1), em coordenadas homogêneas, calculamos a matriz de parâmetros extrínsecos da seguinte
forma:
172
Assim a matriz de rotação (R) dada por:
E a matriz de translação (t) é dada por:
Onde, R é uma matriz de dimensões 3x3 e t um vetor 1x3. A matriz Rt é dada por:
Rt é uma matriz de dimensões 4x4, chamada matriz de parâmetros extrínsecos, ou matriz de
câmera, e 0 é o vetor (0,0,0).
3.4. Cálculo da Matriz de Projeção (Frustum de Visualização)
A matriz de projeção define o volume de visualização, ou frustum. Ela é totalmente especificada
com base em oito parâmetros referentes aos limitantes do tronco de pirâmide considerado como subespaço do mundo virtual que será renderizado: left, right, bottom, top, left e right, near e far. A sua
função é a de projetar os pontos do espaço que estiverem dentro do volume de visualização no plano
da imagem. O plano da imagem, por sua vez, se encontra situado a uma distância da câmera denotada
por near. Uma representação do frustum é mostrada na Figura 10.
173
Figura 10. Frustum de uma cena virtual. Os oito parâmetros estão denotados apenas por suas iniciais.
Dentro do contexto do FTVR, o volume de visualização não permanece simétrico e constante,
mas é de natureza assimétrica e muda conforme a posição da face do usuário, seguindo sua posição
no espaço. É essa correção de perspectiva que, ao se adequar à posição do usuário, cria a ilusão de profundidade. Assim, quando o usuário altera sua posição, o frustum deve ser corrigido, e essa correção
recebe contribuição de duas fontes. A primeira é quando o usuário se desloca sobre o eixo z, e a segunda é quando ele se move sobre os eixos x e y. Essas duas contribuições são computadas e, em conjunto,
corrigem o frustum.
Movimentação no eixo z
A Figura 11 ilustra a geometria da cena demonstrando as variáveis necessárias para se estimar a
profundidade (coordenada z) da face do usuário.
174
Figura 11. Calculando o novo frustum, movimentação no eixo z.
Por semelhança de triângulos, pode-se demonstrar que:
Movimentação nos eixos x e y
De forma análoga à Figura 11, a Figura 12 ilustra a variação da posição da face do usuário no plano
xy, bem como as variáveis necessárias para estimar sua posição na cena.
Figura 12. Calculando o novo frustum, movimentação nos eixos x e y.
Seguindo uma linha de raciocínio semelhante, demonstra-se que:
175
A partir disso, pode-se corrigir o frustum antigo (geralmente simétrico e pré-definido pela aplicação), obtendo os novos valores que o definem: left’, right’, bottom’ e top’ como demonstrado abaixo. Os
valores, near e far são constantes [Maksakov 2009].
O resultado da aplicação do pipeline pode ser visualizado na Figura 13. A informação do rastreamento (retângulo azul) foi usada para estimar o ponto de vista do usuário (coordenadas x, y e z da face).
Em seguida essa informação foi usada para modificar o frustum da cena. Como pode ser visto, a cena
renderizada (parte direita da Figura 13) aparenta estar distorcida. Este efeito ocorre pois o frustum
deixa de ser simétrico para se adequar ao ponto de vista do usuário.
Figura 13. FTVR em execução, retângulo azul com face detectada.
4. Aplicações
A técnica FTVR pode ser aplicada em diversos cenários. Os requisitos para a aplicação da técnica
são mínimos considerando o contexto tecnológico. De fato, praticamente qualquer aplicação de RV
176
que conte com uma câmera à disposição e com uma carga de processamento disponível pode aplicar
a técnica para incrementar a sua visualização. Exemplos de sua aplicação constam desde trabalho colaborativo na análise de dados até a simulação de hologramas. Tais cenários se beneficiam do maior
nível de detalhes possibilitado pelo FTVR, da geração de campo de visão variável, e da percepção de
profundidade.
4.1. Whale Tank Virtual Reality
Dentro do escopo do trabalho colaborativo, uma expansão do sistema FTVR foi proposta, sendo
chamada de Whale Tank Virtual Reality [Maksakov 2009]. A proposta do Whale Tank é fornecer um
sistema de visualização baseado no FTVR, substituindo monitores tradicionais por telas maiores. Por
causa disso, é possível que dois ou mais usuários colaborem entre si usando a mesma tela. No Whale
Tank, mostrado na Figura 14, cada usuário pode interagir com o ambiente ao tocar na tela. Além disso,
cada um possui seu próprio viewport, ou seja, sua própria visualização, de acordo com seu ponto de
vista, baseado no FTVR. O rastreamento da posição da cabeça do usuário é feito usando sensores especiais que fornecem informações com 6 graus de liberdade, três graus para a posição (translação) e três
para a configuração angular (rotação). Os usuários podem interagir com os objetos virtuais via toque.
O Whale Tank é um bom exemplo que demonstra uma possível utilização do sistema em cenários de
trabalho colaborativo, mesclando a interação por toques e gestos com a renderização baseada no ponto
de vista do usuário.
Figura 14. Trabalho colaborativo com Whale Tank Virtual Reality.
177
4.2. pCube
Em [Stavness et al. 2010] é descrito um dispositivo, chamado pCube (ver Figura 15). Este dispositivo pode servir tanto como ferramenta de visualização quanto ferramenta de input. O pCube usa
a metáfora de uma caixa de vidro, e em cada uma de suas faces existe uma tela LCD que renderiza o
ambiente virtual de acordo com o ponto de vista do usuário. Cada tela funciona independentemente,
como um monitor com a técnica FTVR. Para simular coerentemente a metáfora de uma caixa de vidro,
foi utilizada uma engine física para simular a movimentação dos objetos de acordo com o manuseio
da mesma. O pCube utiliza o FTVR de uma forma diferente de todas as outras abordagens vistas até
então. Mas, da mesma forma que o Whale Tank, houve a tentativa de expandir as capacidades do sistema padrão FTVR. O pCube pode ser usado para uma grande gama de aplicações em educação, jogos,
radar 3D, mapas, entre outros [Stavness et al. 2010]. Essas e outras aplicações servem como indícios da
riqueza de aplicações que podem se beneficiar pela técnica FTVR.
178
Figura 15. Detalhamento do pCube: a) imagem conceitual do pCube mostrando a renderização isolada
em cada face e as renderizações integradas; b) imagem do pCube construído, também mostrando o
controlador A/D e o Headphone contendo o dispositivo de head tracking; c) ilustração da engine física
atuando sobre os objetos.
4.3. Holo Desk
Recentemente, foi publicado pela Microsoft Research um trabalho que descreve o sistema Holo
Desk [Hilliges et al. 2012]. O Holo Desk é um sistema interativo de RA que permite ao usuário o manuseio de objetos virtuais sem a necessidade de vestir nenhum hardware auxiliar. O usuário visualiza os
objetos virtuais através de um vidro semitransparente, onde os mesmos são projetados. Nesse sistema
é possível interagir com os objetos virtuais de forma natural, através de gestos de agarrar e também
através de outros objetos reais, como livros, vasilhas e folhas de papel. O sistema utiliza a câmera do
Kinect para detectar a interação entre os objetos reais e virtuais. Uma vez que o sistema foi criado com
o intuito de não necessitar de nenhum outro tipo de instrumento auxiliar para manipular o ambiente
virtual, a simulação de profundidade foi obtida usando-se a técnica FTVR para correção de perspectiva de acordo com o ponto de vista do usuário. Esta opção é tomada com base em estudos que sugerem
que a correção de perspectiva de acordo com o ponto de vista é mais importante para a estimativa da
profundidade na cena, do que a própria estereoscopia [Ware et al. 1993] [Stavness et al. 2010]. Entre as
principais contribuições do Holo Desk figura a integração em um único sistema da simulação física de
objetos virtuais no mundo real, além da interação com a mão livre e a visualização corrigida a partir do
ponto de vista do usuário. A Figura 16 ilustra o funcionamento do Holo Desk. Nas partes A e B o usuário interage com esferas virtuais usando a mão e uma tigela. Na parte C é possível ver em detalhes as
features rastreadas da mão do usuário, utilizadas para efetuar a sua interação com os objetos virtuais.
Na parte D é possível observar o usuário levantando um cubo virtual com as duas mãos. Por fim, na
parte E da Figura 16, é observado o uso de um caderno para sustentar um cubo virtual.
Figura 16. Cenário de aplicação do Holo Desk.
4.4. Robótica e Telepresença
179
Em [Heinrichs and McPherson 2012], um sistema de telepresença é proposto, com o objetivo de
simular o comportamento do FTVR em um ambiente real. Dessa forma, a ideia de simular uma janela
para um outro espaço é alterada. O espaço que o observador vê não é mais virtual, mas sim real, e está
situado remotamente. A intenção foi a de criar uma forte sensação de presença física no local remoto,
fazendo o usuário se sentir como se estivesse realmente olhando para uma janela que mira para outro
ponto no espaço físico. O sistema é composto por um braço robótico, o qual segura uma câmera, e a
translada de acordo com a mudança de posição da cabeça do usuário. A cabeça do usuário, por sua
vez, é rastreada por um Kinect. É possível perceber que nestes trabalhos, o conceito de visualização
imersiva passa a transcender o caso comum. A Figura 17 ilustra o cenário e os equipamentos utilizados
para a experimentação do conceito.
Figura 17. Apresentação do sistema de telepresença que usa um braço robótico (topo) controlado pelo
movimento do usuário na cena, o qual é rastreado por um Kinect (base).
4.5. Lentes Mágicas
Em [Baricevi et al. 2012] é demonstrado um protótipo de Lentes Mágicas (Magic Lenses). Toda
aplicação de RA pode ser considerada uma lente mágica, pois sobrepõe informação que só pode ser
vista na tela do dispositivo que está exibindo a cena, neste caso, dispositivos móveis, como tablets e
smartphones. No entanto, todas as aplicações mostram as informações apenas sob o ponto de vista do
próprio dispositivo, ao invés de levarem em conta o ponto de vista do usuário na cena. Por exemplo, se
180
o usuário mudar o ângulo como observa a tela do dispositivo, a imagem não irá mudar, pois o dispositivo continua apontado para a mesma posição, e no mesmo local do espaço. Entretanto, seria desejável
que a imagem mostrada para o usuário mudasse de acordo com o ponto de vista do mesmo, criando a
ilusão de que a tela do dispositivo é realmente uma lente transparente. Este é justamente o objetivo do
trabalho descrito em [Baricevi et al. 2012].
O protótipo pode ser visto na Figura 18, parte a). Consiste de um Kinect e um Wiimote, ambos
acoplados a um tablet. O Kinect foi utilizado para reconstruir a cena, estimar a pose da câmera do
dispositivo, a fim de renderizar os objetos virtuais nos lugares adequados, e também renderizar a própria reconstrução de forma diferenciada, baseada no ponto de vista do usuário. Para rastrear e obter
o ponto de vista do usuário foi utilizado o Wiimote, juntamente com um óculos que possui emissores
de luz infravermelho, de modo semelhente à configuração proposta por Lee [Lee 2008], explanada
anteriormente. As principais contribuições deste trabalho se concentram na realização de um estudo
comparando entre os dois tipos de lentes mágicas, a primeira que utiliza apenas o ponto de vista do dispositivo, enquanto a segunda, que se baseia no ponto de vista do usuário, gerando resultados quantitativos e qualitativos favoráveis ao uso da perspectiva baseada no ponto de vista do usuário. Além disso,
a prova de conceito é de que é possível aplicar a técnica de FTVR também em cenários reais através da
reconstrução destes em tempo real com sensores de profundidade como o Kinect. Mais além, é notável
o feito de construir uma lente mágica desta natureza com componentes de hardware pré-fabricados e
acessíveis (Kinect e Wiimote).
Figura 18. Lentes mágicas: a) protótipo utilizado; b) cena aumentada sob o ponto de vista do dispositivo;
c) cena aumentada sob o ponto de vista do usuário; d) ilustração conceitual do objetivo da aplicação.
O presente trabalho introduz temas que concernem a Realidade Virtual, as suas origens, alguns de
seus sistemas e técnicas. Temas como Interação Natural e Percepção de Profundidade são abordados
e correlacionados com técnicas de visualização interativa. Em especial, a implementação da técnica
Fish Tank Virtual Reality (FTVR) é abordada em detalhes. Mais além, é discutida uma implementação
do sistema FTVR utilizando câmeras de baixo custo (e.g. webcams) e rastreamento de faces utilizando
TLD/Predator. Esta combinação de implementação se destaca por usar unicamente uma câmera comum e um algoritmo de baixo custo de processamento para definir o ponto de vista do usuário.
181
Na sequência, a aplicabilidade da técnica é analisada. Visto que seu custo de implementação e implantação é baixo, uma vasta gama de aplicações pode se beneficiar deste tipo de visualização interativa. Tais aplicações vão desde jogos em primeira pessoa [Andersen et al. 2010] até sistemas de interação
em disposivos móvel [Francone and Nigay 2011]. Outras sugestões também podem ser citadas, como a
visualização de volumes em aplicações científicas, as quais exigem que um grande conjunto de dados
seja renderizado, ou aplicações voltadas para trabalhos cooperativos [Maksakov 2009]. Mais além, trabalhos do estado da arte são apresentados, indicando que a técnica FTVR passa a ser aplicada inclusive
em ambientes reais, com o objetivo de tornar também a representação da realidade nos displays, calibrada de acordo com o ponto de vista do usuário [Hilliges et al. 2012] [Heinrichs and McPherson 2012]
[Baricevi et al. 2012]. Nestas aplicações é também demonstrado que a adição da técnica enriquece a
interação e ajuda na execução de tarefas em que a informação de profundidade é relevante.
References
ANDERSEN, A.S.; HOLST, J.; VESTERGAARD, S.E. (2010) “The Implementation of Fish Tank Virtual
Reality in Games: Exploring the concepts of motion parallax simulation and stereoscopy”, Department of
Medialogy, Aalborg University Copenhagen.
BARICEVI, D.; LEE, C.; TURK, M.; HOLLERER, T.; BOWMAN, D. A. (2012) “A Hand-held AR Magic
Lens with User-Perspective Rendering”, International Symposium on Mixed and Augmented Reality ISMAR, United States.
BRADSKI, G.; KAEHLER, A. Learning OpenCV: computer vision with the OpenCV library, O'Reilly
Media, 2008.
BROOKS JR.; F. P. (1999) “What’s Real About Virtual Reality?”, IEEE Computer Graphics and Applications,
19(6), 16-27.
BRYSON, S. (1996) “Virtual Reality in Scientific Visualization”, Communications of the ACM, MS T27A-1,
NASA Ames Research Center, Moffett Field, CA, United States.
CHANG, I.; LIN, S. (2010) “3D Human Motion Tracking based on a Progressive Particle Filter”, Pattern
Recognition Letters, 43(10), 3621-3635.
CRUZNEIRA, C.; SANDIN, D. J.; DEFANTI, T. A. (1993) “Surround-screen Projection-based Virtual
Reality: The Design and Implementation of the CAVE”, annual conference on Computer graphics and
interactive techniques - SIGGRAPH, pp. 135-142.
FRANCONE, J.; NIGAY, L. (2011) “Using the User’s Point of View for Interaction on Mobile Devices”,
Université Joseph Fourier Grenoble 1, Laboratoire d’Informatique de Grenoble, France.
GOKTURK, S.; TOMASI, C. (2004). “3D head tracking based on recognition and interpolation using a
time-of-flight depth sensor”, Computer Vision and Pattern Recognition – CVPR.
182
HALARNKAR, P.; SHAH, S.; SHAH, H.; SHAH, H.; SHAH, A. (2012) “A Review on Virtual Reality”,
International Journal of Computer Science Issues, 9(6), 325-330.
HEINRICHS, C.; MCPHERSON, A. 2012) “Recreating the Parallax Effect Associated with Fishtank VR in
a Real-Time Telepresence System Using Head-Tracking and a Robotic Camera”, International Symposium
on Mixed and Augmented Reality – ISMAR, United States.
HILLIGES, O.; KIM, D.; IZADI, S.; WEISS, M.; WILSON, A. D. (2012) “HoloDesk: Direct 3D Interactions
with a Situated See-Through Display”, SIGCHI Conference on Human Factors in Computing Systems,
United States, p 2421-2430.
Sony (2013) “HMZ-T2 Visualizador Pessoal 3D”, http://www.sony.pt/product/visualizador-pessoal-3d/
hmz-t2, 25/03/2013.
KALAL, Z.; MATAS, J.; MIKOLAJCZYK, K. (2010) “P-N Learning: Bootstrapping Binary Classifiers by
Structural Constraints”, Computer Vision Pattern and Recognition - CVPR, United States.
Leap Motion, Inc. (2013) “Leap Motion”, https://www.leapmotion.com/, 25/03/2013.
LEE, J. C. (2008) “Hacking the Nintendo wii remote”, IEEE Pervasive Computing, United States, Vol. 7, pp.
39-45.
MAKSAKOV, E. (2009) Whale Tank Virtual, Dissertação de Mestrado, Ciência da Computação, The
University of British Columbia, United Kingdom.
MELLO, C. A. “Percepção de Profundidade”, http://www.cin.ufpe.br/~cabm/visao/PV_Aula01_Percepcao.
pdf, 15/03/2013.
Microsoft (2013) “Xbox 360 + Kinect”, http://www.xbox.com/en-US/xbox360?xr=shellnav, 25/03/2013.
Oculus VR, Inc. (2013) “Oculus Rift”, http://www.oculusvr.com/, 25/03/2013.
PRACHYABRUED, M.; BORST, C. W. (2012) “Virtual Grasp Release Method and Evaluation”, International
Journal of Human-Computer Studies, 70(11), 828-848.
PURVES, D.; LOTTO, B.; NUNDY, S. (2002) “Why We See What We Do: An Empirical Theory of Vision”,
American Scientist, Sunderland, MA: Sinauer Associates, United Kingdom.
STAVNESS, I.; LAM, B.; FELS, S. (2010) “pCubee: A Perspective-Corrected Handheld Cubic Display”,
ACM CHI, 1381-1390, New York, United States.
STENGER, B.; THAYANANTHAN, A.; TORR, P. H. S.; CIPOLLA, R. (2003) “Filtering using a Tree-Based
Estimator”, International Conference on Computer Vision, p. 1063.
STEUER, J. (1992) “Defining Virtual Reality: Dimensions Determining Telepresence”, Journal of
Communication, 42(4), 73-93.
183
STEVENSON, A. (2002) “Calibrating Head-Coupled Virtual Reality Systems”, Master of Science, The
Faculty of Graduate Studies, The University of British Columbia, United Kingdom.
SUTHERLAND, I. E. (1965) “The Ultimate Display”, IFIPS Congress, New York, United States, Vol. 2, pp.
506-508.
SUTHERLAND, I. E. (1968) “Head-Mounted Three Dimensional Display”, AFIPS Fall Joint Computer
Conference, United States, Vol. 33, pp. 757-764.
UM3DLab (2011) “Kinect - Navigation in a Virtual Reality CAVE”, http://www.youtube.com/
watch?v=XMl4Q2smpPk, 25/03/2013.
VALLI, A. (2005) “Notes on Natural Interaction”, http://www.idemployee.id.tue.nl/g.w.m.rauterberg/
lecturenotes/valli-2004.pdf, 25/03/2013.
WARE, C.; ARTHUR, K.; BOOTH, K. S. (1993) “Fish Tank Virtual Reality”, CHI, pp. 37-42.
WAYNE, C. (2003) “A Critical History of Computer Graphics and Animation, Section 17: Virtual Reality”,
http://design.osu.edu/carlson/history/lesson17.html, 29/02/2013.
184
185
ELISEO, Maria Amelia; PACHECO, Beatriz de Almeida; DELMONDES, Darlan Silva Alves.
Desenvolvimento de websites com ambientes virtuais 3D interativos
Desenvolvimento de websites com ambientes
virtuais 3D interativos
Maria Amelia Eliseo
Beatriz de Almeida Pacheco
Darlan Silva Alves Delmondes
Abstract
This chapter shows aspects for developing websites with interactive 3D virtual environments. The use of
HTML 5 Canvas and the X3DOM framework, allows the construction and display of environments that
does not require the installation of plugins in the browser. X3DOM integrates X3D scenes in HTML and
allows the manipulation of content by adding, removing or altering dynamically HTML DOM elements.
The result is a 3D virtual environment where the user can navigate and interact with objects in threedimensional world.
Resumo
Este capítulo mostra os aspectos para o desenvolvimento de websites com ambientes virtuais 3D interativos. O recurso Canvas da HTML 5 e o framework X3DOM dão suporte para a construção destes
ambientes e sua exibição não necessita da instalação de novos plugins no browser. X3DOM integra cenas
X3D no código HTML e permite a manipulação do conteúdo adicionando, removendo ou alterando dinamicamente os elementos DOM HTML. O resultado é um ambiente virtual 3D onde o usuário poderá
navegar e interagir com os objetos do mundo tridimensional.
1. Introdução
Nos últimos anos, os avanços tecnológicos tornaram possível a construção de modelos 3D interativos e ambientes virtuais 3D, que podem ser experimentados através da Web, usando para seu desenvolvimento computadores comuns, de baixo custo. A ideia de se construir um conteúdo 3D na web não
é novidade, no entanto percebe-se ainda hoje, um pequeno número de sites que trazem este recurso. O
entrave ocorrido no passado para tal popularização se deu devido à capacidade de processamento das
185
máquinas e a largura de banda de transmissão de dados existente na Web, que não permitia a visualização e manipulação de conteúdo 3D.
Tal, obstáculo vem sendo superado com a melhoria da performance das máquinas e da transmissão de dados via Internet. Aliado a isso, nos últimos anos surgiram algumas tecnologias que permitiram otimizar a performance de renderização, como o X3D, algumas Game Engines, entre outros.
Como resultado, há um crescente incremento de conteúdos 3D na web, cada vez mais utilizados em
áreas diferentes de aplicação, tais como a educação e formação profissional [Chittaro e Ranon 2007a],
[John 2007], [Sims 2007], e-commerce, arquitetura e turismo, comunidades virtuais (Active Worlds,
Second Life) e museus virtuais [Barbieri e Paolini 2001].
Web sites que distribuem conteúdo 3D (doravante, chamados de Web Sites em 3D) podem ser
divididos em duas grandes categorias:
• Sites de Exibição: possuem modelos interativos 3D de objetos embutidos em páginas da Web,
como sites de comércio eletrônico que permitem aos clientes examinar os produtos por meio
de sua manipulação tridimensional;
• Sites que se baseiam principalmente em um Ambiente Virtual 3D exibido dentro do navegador
Web, como sites de turismo que permitem aos usuários navegar dentro de uma cidade virtual.
No primeiro caso, a estrutura de informação primária e os métodos de interação do usuário ainda
se baseiam no modelo tradicional de hipermídia, com a possibilidade adicional de inspecionar objetos
em 3D. Já no segundo caso, a estrutura de informação principal é um espaço 3D, em que os usuários
podem se mover para todas as direções e executar várias ações.
Logo após o surgimento da Web, já existia a vontade de desenvolvedores e pesquisadores em desenvolver conteúdo tridimensional e interativo na rede. A capacidade de visualizar e manipular conteúdo 3D em tempo real parecia ser a nova tecnologia que tornaria a navegação na web mais próxima
das experiências interativas dos usuários em seu meio ambiente. Nesse sentido, algumas soluções foram desenvolvidas ao longo dos últimos 15 anos, mas poucas delas introduziram um modelo realmente novo e revolucionário (jogos on-line, por exemplo) [Behr et al. 2009].
Vale destacar que ainda não há uma única tecnologia que seja amplamente utilizada para a visualização e interação com tais modelos. Diversos sistemas e soluções têm sido propostos e desenvolvidos
para superar este problema, mas na maioria destas abordagens há uma aproximação de paradigma
tecnológico. Assim, costuma haver uma contribuição da comunidade científica no sentido de adicionar
novos recursos aos padrões desenvolvidos a partir da detecção de problemas nas soluções anteriormente propostas. Dessa forma, uma série de extensões foi adicionada a soluções individuais, gerando
muitas vezes um confronto com fornecedores de tecnologia e distribuidores de conteúdo e gerando
uma quantidade grande de ambientes sobrecarregados [Behr et al. 2009].
É possível perceber também, que o desenvolvimento de Sites 3D não visa a substituir o modelo
hipermídia que é a mote principal da web de hoje, mas eles podem aumentar a eficácia de web tradicional, agregando valor a ela ao disponibilizar a visualização de modelos 3D aos sites ou ao permitirem
experiências em primeira pessoa em ambientes online [Chittaro e Ranon 2007b].
Tal como no caso da Web hipermidiática, a adaptatividade pode desempenhar um papel importante no aumento da utilidade, eficácia e utilidade de sites 3D. Por exemplo, um sistema adaptativo
186
inteligente de apoio à navegação poderia ajudar os usuários com diferentes habilidades de navegação,
repertório e estrutura cognitiva a orientar-se na medida em que adquirem conhecimento espacial do
ambiente com o qual interagem.
Nesse sentido, um cuidado adicional no desenvolvimento tem de ser tomado, por se tratar de
modelos conceitualmente peculiares, são poucas as abordagens conceituais, técnicas e ferramentas de
software de desenvolvimento de conteúdo 3D que podem aceitar diretamente recursos adaptativos.
No entanto, alguns projetos de pesquisa têm abordado a questão da adaptabilidade para sites 3D. Por
exemplo, uma arquitetura de software para a construção dinâmica de conteúdo Web 3D foi proposto
e aplicado ao e-commerce e museus virtuais. Alguns pesquisadores desenvolveram métodos para suporte de navegação personalizado, interação adaptativa [Celentano e Pittarello 2004] e apresentação de
conteúdo em 3D [Chittaro e Ranon 2000, 2002].
Este capítulo visa apresentar ao leitor os conceitos, temas e técnicas de sites em 3D. A intenção
é centrar os estudos aqui apresentados principalmente em sites 3D da primeira categoria apresentada anteriormente, uma vez que esta categoria é a mais geral e complexa (mas a maioria das técnicas
discutidas pode ser aplicada também a sites interativos com objetos 3D). O capítulo está estruturado
da seguinte forma. Seção 1.1 fornece uma introdução aos sites da Web em 3D para o leitor iniciante,
descreve as principais áreas de aplicação, e menciona as principais tecnologias, com foco em padrões.
A seção, 1.2, por sua vez, apresenta alguns exemplos de aplicação da web 3D no modelo que é discutido
no presente trabalho. Já a seção 1.3 discute o contexto de desenvolvimento de web sites em 3D e em
relação à Web baseada em hipermídia. Já a seção 1.4 descreve o modelo usado no minicurso proferido
no Simpósio de Realidade Virtual, enquanto a seção 1.5, apresenta o exercício desenvolvido com suas
considerações e explicações. Finalmente, a seção 1.6 conclui o capítulo.
2. A Web 3D
A web evoluiu rapidamente desde sua popularização na década de 1990. Desde as páginas HTML
(HyperText Markup Language) estáticas, com estilo incorporado nos tags (inline), passando para uma
fase de conteúdo separado da apresentação (HTML + CSS), chegando aos dias atuais, nos quais se constrói páginas web dinâmicas baseadas em JavaScript e tecnologia AJAX. A base para essas mudanças
são desenvolvimentos impulsionados pelas comunidades de XHTML (eXtensible HyperText Markup
Language) e HTML5, bem como sistemas navegação como o Mozilla e WebKit [Behr et al., 2009].
As linguagens, protocolos e ferramentas de software que permitem a construção de modelos 3D e
Ambientes Virtuais 3D que podem ser experimentados por meio da Web são conhecidos como tecnologias Web3D. Atualmente, com o aumento da largura de banda e do poder de processamento (especialmente a capacidade de gerar e renderizar gráficos 3D), é possível que cada vez um número maior
de usuários possa interagir com sistemas e ambientes complexos em 3D baseados na Web, como as
cidades virtuais, visualizações de dados científicos, ou museus virtuais.
As tecnologias usadas para a criação da Web3D baseiam-se nas escolhas técnicas e arquitetônicas
típicas do ambiente web: o conteúdo é representado normalmente por um formato (muitas vezes texto),
que é armazenado em um servidor. Quando solicitado por um cliente, normalmente através de HTTP
(HyperText Transfer Protocol), é exibido por um navegador, ou, mais frequentemente, por um plug-in
187
para um navegador da Web. Como resultado, o conteúdo 3D pode ser fortemente integrado com outros
tipos de conteúdo da Web, aumentando sites com objetos 3D interativos (um modelo 3D pode aparecer
em uma página da Web com conteúdo HTML), bem como ao exibir a maioria dos tipos de conteúdo da
Web (como imagens, sons, vídeos) dentro de um Ambiente Virtual 3D acessível por meio da Internet.
Estas são as principais características distintivas das tecnologias Web3D com relação a outros
tipos de gráficos 3D interativos demais tecnologias relacionadas, tais como as em Realidade Virtual.
Além disso, enquanto a Realidade Virtual normalmente se concentra em experiências de imersão em
3D, por exemplo, empregando head-mounted displays (HMDs) e luvas, o conteúdo da Web 3D é geralmente experimentado com os dispositivos de entrada/saída comuns computadores pessoais (monitor,
teclado e mouse) [Chittaro e Ranon, 2007b].
Apesar de se estruturarem em termos de protocolos e arquitetura de forma bem semelhante às da
Web tradicional (hipermidiática), as tecnologias da Web 3D possuem suas próprias características e
linguagens.
As aplicações 3D costumam manipular conteúdo dinâmico e estilo em uma descrição XML (eXtensible Markup Language) representada por um modelo DOM (Document Object Model) . Este modelo DOM inclui um gráfico 2D que descreve o conteúdo de um aplicativo específico. Esses padrões
incluem métodos para manipular este DOM sobre interfaces com script específicos, o que leva a mudanças dinâmicas. Há diversas tecnologias web disponíveis, que fornecem distribuição, comunicação
e segurança de conteúdo [Behr et al., 2009].
Apesar de diversas formas de desenvolvimento de aplicações web 3d estarem disponíveis, ainda
não há uma única padronização para tais soluções, o que gera um série de possibilidades diferentes
de trabalhos na área, mas uma dificuldade grande de acesso a tais sistemas, devido à necessidade de
plug-ins ou outras especificações para que tais ambientes possam ser acessados.
Para solucionar este problema gerado pela falta de padronização de conteúdos 3D dinâmicos na
Web, deve haver um esforço no sentido de transformar tal conteúdo em algo que possua característica
de mídia web, e dessa forma, possa ser transmitido e compartilhado com os demais recursos hipermídia de tal ambiente, isto é, texto, imagens, áudio e vídeo. Uma boa solução para esta integração está no
uso direto da árvore DOM [Behr et al., 2009].
3. Tecnologias Envolvidas no Desenvolvimento de Web Sites em 3D
Várias tecnologias têm sido desenvolvidas para que construção de cenas 3D interativas bem como
ambientes virtuais 3D em web sites sejam viáveis. Os entraves do passado, como o desempenho do
processamento envolvido na renderização e taxa de transmissão das cenas 3D via Internet estão sendo
superados.
Este subcapítulo apresenta algumas tecnologias utilizadas para o desenvolvimento de web sites
em 3D, como o elemento canvas da HTML 5, a API (Application Programming Interface) WebGL e a
linguagem X3D (eXtensible 3D). Com a integração destas tecnologias, cenas 3D podem ser visualizadas, enriquecidas por animações, além de permitir interação do usuário com as cenas, promovendo
“passeios virtuais” interativos através de web sites.
188
3.1. O elemento canvas da HTML 5
A especificação HTML 5 inclui uma gama de novas funcionalidades, e dentre elas está o elemento
<canvas>. Este elemento permite construir representações gráficas através de scripts. Representa um
conteúdo incorporado que consiste de uma imagem criada dinamicamente. O elemento canvas possui
um contexto de renderização, que se não for definido nada aparecerá na tela. O contexto pode ser definido como 2D, WebGL ou por algum algoritmo descrito na especificação [W3C Consortium 2013].
Para ajustar as dimensões de canvas, utiliza-se os atributos “width” e “height”. A Figura 1.1 mostra
como incluir canvas num documento HTML. O elemento canvas é um elemento HTML normal que se
inicia com a tag de abertura <canvas> e se encerra com a tag de fechamento </canvas>. O atributo id é
utilizado para identificar o elemento <canvas>. O atributo width (largura) define quantos pixels canvas
irá ocupar na horizontal em uma página web. Da mesma forma, height (altura) define a área vertical
que ocupará na página, na Figura 1.1 são 200 pixels.
<canvas id="meuDesenho" width="400" height="200"></canvas>
Figura 1.1. O uso do element canvas num documento HTML.
Com CSS (Cascading Style Sheet) é possível visualizar as bordas do elemento canvas nas dimensões especificadas com os atributos width e heigth. Como alternativa estas dimensões também podem
ser definidas através do CSS.
A linguagem JavaScript é utilizada para desenhar em canvas. A Figura 1.2 mostra uma função
JavaScript para a construção de um retângulo (que aqui é um quadrado, pois a largura é igual a altura).
window.onload = function() {
var canvas = document.getElementById("meuDesenho");
var context = canvas.getContext("2d");
context.fillRect(10, 10, 100, 100);
};
Figura 1.2. Código JavaScript para desenhar um retângulo de 10 x 10 no elemento canvas.
Na Figura 1.2 o elemento canvas foi identificado pelo ID através do método getElementById de
HTML DOM (que é um padrão para acessar e manipular documentos HTML). O contexto foi definido
como 2D. Para desenhar o retângulo, utilizou-se o método context.fillRect(x, y, w, h), onde x e y corresponde a posição do retângulo em canvas e w, h, a largura e altura, respectivamente, do retângulo.
Além de retângulos, com o elemento canvas é possível criar arcos (e consequentemente circunferências), desenhar linhas, inserir textos, imagens, aplicar texturas, gradientes e inclusive incorporar
cenas 3D utilizando a API WebGL ou a linguagem X3D.
189
3.2. A API WebGL
WebGL é uma API Javascript de renderização de ambientes tridimensionais projetada para a Web.
Esta API é derivada do OpenGL ES 2.0 (uma variação do OpenGL, que facilita a aplicação da API em
dispositivos com baixo poder de processamento: smartphones, por exemplo) e fornece funcionalidades
de renderização similares, porém em um contexto HTML. WebGL utiliza o elemento <canvas>, um
novo elemento do padrão HTML5, para a renderização, permitindo a renderização sem a instalação
de plug-ins adicionais.
Como exemplos de uso desta API pode-se citar: passeios virtuais, jogos e visualização de dados.
Mas, é importante salientar que nem todos os navegadores Web oferecem suporte a WebGL, como é o
caso do IE, que requer plug-ins a serem instalados (JebGL e IEWebGL) para as renderizações.
3.3. Características das Cenas X3D
X3D é um padrão internacional aberto de representação de cenas 3D resultantes de esforços do
Consórcio Web3D. Constitui-se num formato padrão para representar cenas e objetos 3D usando a
linguagem XML [WEB3D CONSORTIUM 2012]. X3D usa grafos de cena para modelar os vários nós
gráficos que constituem um ambiente virtual [Brutzman e Daly 2007].
Segundo [Walsh 2002], [Woolford 2003], [Gutiérrez, Vexo e Thalmann 2008], um grafo de cena
é uma estrutura de dados abstrata, representada por uma árvore. Descreve, de forma conceitual e
hierárquica, os objetos ou elementos gráficos que compõem um cenário num ambiente virtual e o
relacionamento entre eles.
O grafo de cena é composto de nós, dispostos numa hierarquia, onde cada nó corresponde espacialmente e semanticamente ao objeto modelado. Espacialmente porque cada objeto é único e está
distribuído no espaço. Semanticamente porque cada nó é consistente com a noção humana da natureza
do objeto e os elementos que o constituem [Woolford 2003]. Os nós são divididos em três categorias:
• Nó raiz (root node) ou nó pai (parent node);
• Nó interno (internal node) ou nó filho (child node);
• Nó folha (leaf node).
A Figura 1.3 mostra um grafo de cena representado por uma estrutura em árvore que descreve,
através da hierarquia de seus nós, a construção de uma escada. Os nós filho “Degrau”, “Balaústre” e
“Corrimão” são constituídos pelos nós folha “Geometria” e “Aparência”. Os nós “Degrau” e “Balaústre”
formam o nó “degrau:Grupo”, que pode ser reutilizado quantas vezes forem necessárias. O nó “escada:Grupo”, que representa a estrutura da escada é formado pelos nós “Transformação Geométrica”,
que descrevem o posicionamento, a escala e a rotação de cada um de seus nós filho, “Corrimão” (que é
reutilizado para a visualização do segundo corrimão na cena) e “degrau:Grupo” [Eliseo 2012].
190
Figura 1.3. Exemplo de grafo de cena representado por uma árvore que descreve uma escada.
Fonte: [Eliseo 2012].
X3D melhora o padrão internacional VRML (Virtual Reality Modeling Language) e usa XML para
expressar a geometria e as capacidades de comportamento da VRML. VRML é um formato intercambiável 3D altamente expressivo sendo suportado por muitas ferramentas. Seguindo seu antecessor,
X3D, além de expressar representações geométricas e comportamentos de animação, permite, também, criar scripts (em ECMAScript ou Java) e nós prototyping, que, juntos, oferecem um suporte para
extensões de grafos de cena gráfico e nova linguagem funcionalmente definida pelos autores [Brutzman e Daly 2007].
Em X3D pode-se reutilizar elementos gráficos quantas vezes forem necessárias. Isso pode ser feito
através de scripts, de recursos de agrupar e instanciar (DEF e USE, respectivamente) e prototypes. DEF
e USE são atributos utilizados dentro dos nós, onde DEF define uma identificação para o elemento
e USE utiliza o elemento identificado. O nó prototype de X3D permite a criação de novos elementos
gráficos que podem ser utilizados repetidamente. Uma vez definido um prototype, pode-se fazer uso
dele através de instâncias. Sua vantagem, além da reutilização de elementos gráficos (USE, DEF), é ser
flexível para alterações em suas instâncias, como escala, cor, textura, etc. A definição de um prototype
pode ser feita num arquivo externo ao cenário [Brutzman e Daly 2007].
Para visualizar um documento X3D é necessário um navegador X3D, ou seja, uma aplicação que lê
as cenas X3D para que possam ser renderizadas e visualizadas. Não se trata apenas de mostrar objetos
3D, mas também, habilitar animações e interações do usuário. Geralmente são implementados como
plug-ins que funciona como um complemento de um navegador web.
191
A Figura 1.4 mostra a arquitetura de uma aplicação X3D, que foi adaptada de [Brutzman e Daly
2007], utilizada num navegador. As cenas X3D são arquivos lidos pelo navegador (X3D browser). Parsers são utilizados ler os formatos de arquivo. Nós são criados e enviados para o gerenciador do grafo
de cena, que mantém o controle de geometria definida, aparência, locais e orientações. O gerenciador
do grafo de cena percorre repetidamente a árvore do grafo de cena de nós X3D para desenhar quadros
de imagem de saída a uma taxa rápida, que redesenha a imagem, de forma precisa, conforme a visualização do usuário. Os nós de evento, definidos por um script (Scripting Engines) mantém o controle da
animação e podem mudar aspectos da imagem renderizada. A SAI (Scene Authoring Interface) define
como as APIs trabalham, permitindo que os autores criem códigos de script para funcionar em diferentes navegadores e sistemas operacionais. Finalmente, páginas web e aplicações externas também
podem ser usadas para incorporar o plug-in do navegador X3D, permitindo aos usuários interagirem
com imagens 3D [Brutzman e Daly 2007].
Figura 1.4. Arquitetura de uma aplicação X3D. Adaptado de [Brutzman e Daly 2007].
Dentro da família de especificações de X3D, que inclui codificação de arquivos e linguagem de
programação, tem-se o DOM, uma API para linguagens de marcação, tais como HTML, XML, SVG.
O DOM fornece uma representação logicamente estruturada de um documento, e um conjunto de
objetos e métodos para manipular essa estrutura [Web Platform Docs 2013]. Possui métodos para modificar, inserir ou remover elementos, atributos e valores.
Devido à extensibilidade de X3D foram definidos perfis (profiles) para funcionalidade oferecida.
A Figura 1.5 mostra os diferentes perfis de X3D que dão suporte aos navegadores ao lerem o código em
níveis intermediários. Assim, Core profile abrange as definições básicas de X3D (routes, metadados),
192
não incluindo geometria, aparência ou animação. Interchange profile é a base para a troca de modelos
geométricos entre aplicações 3D. Contém a geometria básica (incluindo primitivas, triângulos e polígonos), a aparência (material e da textura), e nós de animação. Foi projetado para facilitar a exportação
e importação. Interactive profile é um pouco maior do que o Interchange, e acrescenta a maioria dos
nós necessários para a interação dos com uma cena. CADInterchange profile suporta modelos CAD
(Computer Aided Design). Immersive profile inclui tudo que foi definido em Interactive e adiciona capacidades avançadas, além de novos nós como: geometria 2D, efeitos de ambiente (environmental effects),
eventos de utilidades (event utilities), etc. E Full profile inclui todos os nós definidos nas especificações
de X3D, estendendo o perfil Immersive. Incorpora DIS (Distributed Interactive Simulation), H-Anim
(Humanoid Animation), NURBS (Non-Uniform Rational B-spline Surfaces) e outros components avançados [Brutzman e Daly 2007].
Figura 1.5. Os perfis (profi les) definidos para X3D como suporte para os navegadores.
Fonte: [Brutzman e Daly 2007].
4. O modelo X3DOM
X3DOM, um framework open-source que promove a inserção de conteúdo 3D interativo numa
aplicação web, foi descrito em [Behr et al. 2009], [Behr et al. 2010], [Behr et al. 2011]. Integra X3D com
HTML 5, mapeando e sincronizando elementos DOM com o modelo de cena X3D. Ao inserir uma
cena X3D, o desenvolvedor pode manipular seu conteúdo 3D adicionando, removendo ou alterando
os elementos DOM. Esta abordagem permite que o conteúdo 3D seja visualizado sem a necessidade
193
de plug-ins ou plug-ins de interfaces como SAI (Scene Access Interface), utilizado para exibição de
documentos X3D.
Figura 1.6. Arquitetura de X3DOM. Adaptada de [Behr et al. 2009], [Behr et al. 2010].
A Figura 1.6 mostra a arquitetura de X3DOM proposta por [Behr et al. 2009], [Behr et al. 2010]. O
navegador web dá suporte à árvore DOM, integra e compõe a renderização final e provê algum endereço URI para baixar imagens, vídeos, áudios e cenas X3D. X3D runtime fornece serviços para construir
e atualizar a cena X3D, que é renderizada a cada alteração ou ação do usuário durante a navegação. O
conector X3DOM constrói o núcleo interno da arquitetura e conecta a árvore DOM com o X3D runtime. Distribui as alterações ocorridas tanto no DOM quanto na representação X3D. Atualiza a árvore
DOM quando nós são adicionados ou removidos ou quando há alteração em atributos. Através de
respostas do observador, aciona eventos estilo DHTML a partir das ações do usuário ao navegar pelo
conteúdo 3D. Manipula o upstream e o downstream de mídias como a visualização da cena, imagens,
vídeos e áudios.
Com o uso de X3D para descrever as cenas 3D integradas ao HTML, foi necessário criar um novo
perfil (profile) para X3D. Este novo perfil, o X3D DOM profile, estende o Interactive profile incluindo
novas características para animação e manuseio de eventos. Não inclui suporte para os scripts e nem
para os nós prototype.
As alterações na árvore DOM, as atualizações do X3D e a visualização do conteúdo 3D são realizadas através de JavaScript. A arquitetura geral é implementada como parte da aplicação web utilizando
o framework para a renderização. Devido a APIs 3D, como por exemplo, o WebGL, é possível visualizar
o conteúdo 3D sem a instalação de plug-ins. Para utilizar o framework deve-se inserir o arquivo JavaScript no documento HTML, através da tag <script>, conforme a Figura 1.7. A codificação JavaScript
pode ser obtida em “http://www.x3dom.org/download/dev/x3dom.js”.
194
<script src="x3dom.js"></script>
Figura 1.7. Linha de código HTML que insere um arquivo JavaScript.
O framework monitora a árvore DOM e implementa um modelo de retorno a cada tag <X3D>
encontrada no código HTML. X3DOM dá suporte para as seguintes características, segundo [Behr et
al. 2010]:
• tag <x3d> usada como tag raiz
• X3D runtime completo incluindo routes
• sistema de material declarativo e shader
• nó Texture genérico, e ImageTexture explícita, etc;
• IndexedFaceSet (pode precisar de cópia extra)
• nós adicionais X3D (Interpolator, TimeSensor, Inline, ...)
Embora a maior parte das funcionalidades de X3D são cobertas pelo framework, não há suporte
para a inserção dos scripts utilizados pelo X3D e nem dos nós prototypes. Se houver a necessidade de
inserir scripts, isso será feito diretamente na HTML.
A integração de conteúdo 3D com navegadores web também se integra com tecnologias web dinâmicas, como DHTML e AJAX. Isto permite uma maior interação do usuário com o conteúdo 3D, sem
sobrecarregar a performance da aplicação.
5. Web Sites em 3D com o Framework X3DOM
Para desenvolver aplicações web com cenas 3D utilizando o framework X3DOM deve-se fazer um
download dos arquivos JavaScript, x3dom.js e CSS, x3dom.css, encontrado em <http://www.x3dom.
org/download/dev/>. Pode-se, também, fazer uma referência diretamente do site x3dom.org, mantendo, desta forma, o framework sempre atualizado, uma vez que X3DOM ainda está em desenvolvimento.
As Figuras 1.8 e 1.9 mostram a inclusão dos arquivos x3dom.js e x3dom.css, respectivamente, no
código HTML. A inserção foi feita através do link para o site x3dom.org.
<script src="http://www.x3dom.org/download/x3dom.js"></script>
Figura 1.8. Código HTML incluindo o arquivo x3dom.js, com o código JavaScript.
<link rel="stylesheet" type="text/css" href="href=http://www.x3dom.org/download/x3dom.css">
Figura 1.9. Código HTML incluindo o arquivo x3dom.css, com o código CSS.
Para a integração das cenas 3D provenientes de X3D, foi incluindo na HTML o elemento <x3d>
(que até a data de publicação deste texto não era uma especificação da HTML 5). Dentro das tags <x3d>
e </x3> deve vir o código que descreve os grafos de cena de X3D.
195
A Figura 1.10. mostra o código HTML com a inclusão do X3D que descreve
a
representação de uma caixa. O nó scene descreve a cena X3D, que é constituída dos nós transform e
shape. O nó transform define o posicionamento e a escala do elemento geométrico. Pode definir também a rotação. O nó shape define a forma do elemento geométrico. Inclui os nós appearance e box. O
nó appearance define a aparência do elemento gráfico, como cor, textura e contém o nó material. O nó
box define a geometria da caixa. No exemplo da Figura 1.10 é definido um cubo de aresta 3.
<x3d width="200px" height="400px">
<scene>
<transform translation='3 0 -5' scale="1 1 1" >
<shape>
<appearance>
<material diffuseColor='#FCDA15' />
</appearance>
<box size='3 3 3'/>
</shape>
</transform>
</scene>
</x3d>
Figura 1.10. Código HTML que insere uma caixa descrita com X3D.
O código apresentado na Figura 1.10 é renderizado através da API WebGL. O navegador web precisa ter suporte a esta API, tais como:
• Firefox 4+
• Safari 5.1+ (OS X only)
• Chrome 9+
• Opera 12alpha+
O Internet Explorer não possui este suporte, por enquanto.
Uma vez renderizada, a cena é exibida através do elemento canvas da HTML 5. No código HTML
não será feita nenhuma referência a este elemento, que será inserido dinamicamente, através do HTML
DOM.
Os elementos geométricos inseridos podem ser manipulados através de eventos definidos com JavaScript. Por exemplo, o usuário, ao clicar na caixa inserida com o código da Figura 1.10, abre uma tela
de texto. Para que esta ação seja realizada, é necessário acrescentar um evento JavaScript onClick no nó
transform, conforme Figura 1.11. O evento onClick dispara a função JavaScript showValue.
<transform translation='3 0 -5' scale="1 1 1"
onClick="showValue('http://en.m.wikipedia.org/wiki/Cube#top')">
Figura 1.11. Inserção do evento JavaScript onClick no nó transform.
196
Além do evento onClick, será acrescentado o elemento HTML iframe para a exibição do texto. A
Figura 1.12 mostra a inserção do elemento iframe, identificado com o atributo id. No exemplo da Figura 1.12, o elemento frame foi identificado como como “infoText”. O elemento iframe está contido dentro
de outro elemento div que recebe uma formatação CSS inline (style="overflow:hidden; height:90%;"). O
atributo src está vazio, pois será controlado pela função showValue.
<div style="overflow:hidden; height:90%;">
<iframe id="infoText" frameborder="0" src="">
</iframe>
</div>
Figura 1.12. Inclusão dos elementos HTML div e iframe para a exibição do texto informativo.
Há necessidade de inserir o elemento HTML a que estabelece o link da caixa com a exibição do
texto. Este link será controlado pela função JavaScript showValue e terá sua ação concluída quando o
usuário clicar na caixa definida na Figura 1.10. A Figura 1.13 mostra a inserção do elemento HTML
a identificado como “outlink” através do atributo id. O atributo href está vazio, pois será controlado
através da função JavaScript showValue.
<a id="outlink" href=""></a>
Figura 1.13. Inserção do elemento HTML a para estabelecer um link entre o elemento geométrico e o
texto a ser exibido.
Para que o evento onClick funcione é necessário declarar a função JavaScript showValue que é
disparada quando o usuário clicar na caixa definida na cena X3D. A Figura 1.14 mostra o código que
implementa esta função.
<script type="text/javascript">
function showValue(link) {
var outlink = document.getElementById('outlink');
var frame = document.getElementById("infoText");
frame.src = link;
}
</script>
Figura 1.14. Código JavaScript declarando a função showValue.
A função showValue, mostrada na Figura 1.14, possui como argumento o link que será disparado
quando a função for chamada, através do evento onClick. As variáveis “outlink” e “ frame” referem-se
ao elemento a e ao elemento iframe da HTML, respectivamente. Ambas são identificadas pelo método
getElementById() de HTML DOM). A variável frame insere dinamicamente o link especificado no
evento onClick no atributo src do elemento iframe.
197
O resultado final será uma caixa com evento que dispara um link externo e apresenta o conteúdo
deste link no elemento iframe. A Figura 1.15 mostra o resultado final da aplicação web que incorpora
cenas 3D. Outros elementos geométricos foram acrescentados a cena, como o cilindro, o cone e a esfera.
Cada elemento geométrico, ao ser clicado, apresenta seu texto descritivo.
Esta ação é realizado devido ao evento onClick que dispara a função JavaScript que implementa
esta dinâmica. O lado esquerdo da Figura 1.15 apresenta as cenas X3D, onde o usuário interage com as
formas e seleciona aquela que deseja ver informações. O lado direito exibe o texto, num iframe HTML,
do elemento gráfico selecionado. Esta aplicação pode ser utilizada na área da educação para o aprendizado da geometria.
Figura 1.15. Aplicação web que integra cenas X3D com elementos HTML e eventos JavaScript.
Este artigo visou apresentar algumas considerações sobre o uso de modelos tridimensionais na
Web e especificamente apresentar um modelo de integração baseado em DOM para X3D e HTML5.
Partiu-se de um levantamento histórico e da apresentação de alguns questionamentos sobre o fato
da Web 3D ainda não ser uma realidade, com diversas aplicações já funcionando, principalmente pelo
fato da necessidade de alguns recursos possibilitantes de sua visualização, como plug-ins específicos.
Apesar das especificações ainda estarem em desenvolvimento, já podem ser usadas com resultados
198
significativos. Dessa forma, o presente capítulo aborda as tecnologias usadas para o desenvolvimento
de uma aplicação web 3D, usando DOM e X3D, em navegador web e HTML5.
Finalmente, a partir de uma explanação teórica, faz-se um levantamento e apresentação de um
tutorial para desenvolvimento de web site em 3D com o framework X3DOM.
Como trabalhos futuros pode-se destacar o desenvolvimento de uma aplicação web com cenas 3D
para um passeio virtual interativo em edifícios tombados pelo Patrimônio Histórico, como meio para
preservação de sua memória.
Referências
BARBIERI, T.; PAOLINI, P. (2001) “Reconstructing Leonardo's Ideal City - from Handwritten Codexesto
Webtalk-II: a 3D Collaborative Virtual Environment System”, In: Conference on Virtual Reality, Archeology,
and Cultural Heritage, 2001. Athens, Greece. Proceedings… New York: ACM, p. 61-66.
BEHR, J.; ESCHLER, P.; JUNG, Y.; ZÖLLNER, M. (2009) “X3DOM – A DOM-based HTML5/ X3D
Integration Model”, In: 14th International Conference on 3D Web Technology, 2009, Darmstadt.
Proceedings… New York: ACM, p.127-135.
BEHR, J.; JUNG Y.; DREVENSEK, T.; ADERHOLD, A. (2011) “Dynamic and Interactive Aspects of
X3DOM”, In: 16th International Conference on 3D Web Technology, 2011. Paris. Proceedings… New York:
ACM, p. 81-87.
BEHR, J.; JUNG Y.; KEIL, J.; DREVENSEK, T.; ZOELLNER, M.; ESCHLER, P.; FELLNER, D. (2010) “A
scalable architecture for the HTML5/X3D integration model X3DOM”, In: 15th International Conference
on Web 3D Technology, 2010, Los Angeles. Proceedings… New York: ACM, p.185-194.
BRUTZMAN, D.; Daly, L. X3D extensible graphics for web authors. California: Morgan Kaufmann, 2007.
CELENTANO A.; PITTARELLO F. (2004) “Observing and Adapting User Behavior in Navigational
3D Interfaces”, In: 7th International Conference on Advanced Visual Interfaces, 2004. Gallipoli, Italy.
Proceedings… New York: ACM, p. 275-282.
CHITTARO L.; IERONUTTI L.; RANON R. (2004) “Navigating 3D Virtual Environments by Following
Embodied Agents: a Proposal and its Informal Evaluation on a Virtual Museum Application”. In:
Psychnology Journal. v.2, p. 24-42
CHITTARO L.; RANON R. (2000) “Adding Adaptive Features to Virtual Reality Interfaces for E-commerce”.
In: 1st International Conference on Adaptive Hypermedia and Adaptive Web-based Systems, Trento, Italy.
Proceedings… Berlin: Springer-Verlag, p. 85-96.
CHITTARO L.; RANON R. (2002) “New Directions for the Design of Virtual Reality Interfacesto
E-Commerce Sites”. In: Proc. of the 5th International Conference on Advanced Visual Interfaces, Trento,
Italy. Proceedings… New York: ACM, 308-315.
199
CHITTARO L.; RANON R. (2004) “Using the X3D Language for Adaptive Manipulation of 3D Web
Content”. In: 3rd International Conference on Adaptive Hypermedia and Adaptive Web-based Systems,
Eindhoven, Netherlands. Proceedings… Berlin: SpringerVerlag, p. 287-290.
CHITTARO L.; RANON R. (2007a) “Web3D Technologies in Learning, Education and Training:
Motivations, Issues, Opportunities”. In: Computers and Education, Oxford: Elsevier Science Ltd., v. 49, n.
1, p. 3-18.
CHITTARO L.; RANON R. (2007b) “Adaptive Hypermedia Techniques for 3D Educational Virtual
Environments”. IEEE Intelligent Systems, v. 22, n. 4, p. 31-37.
CHITTARO L.; RANON R.; IERONUTTI L. (2003) “Guiding Visitors of Web3D Worlds through
Automatically Generated Tours”. In: 8th International Conference on 3D Web Technology, St. Malo,
France. Proceedings… New York: ACM, p. 85-91.
DANCHILLA, B. “Beginning WebGL for HTML 5”. Apress, 2012.
ELISEO, M. A. “Modelo de representação espaço-temporal em reconstruções digitais tridimensionais”.
2012. Tese (Doutorado em Ciências) – Instituto Tecnológico de Aeronáutica, São José dos Campos.
GUTIÉRREZ, M.A.; VEXO, F.; THALMANN, D. “Stepping into virtual reality”. London: Springer-Verlag,
2008.
JOHN, N. W. (2007) “The Impact of Web3D Technologies on Medical Education and Training”. In:
Computers and Education, Oxford: Elsevier Science Ltd., v. 49, n. 1, p. 19-31.
Khronos Group. (2013) “WebGL Specification”. Disponível em: <http://www.khronos.org/registry/webgl/
specs/latest/#2.3>. Acesso em: 24/03/2013.
SIMS, E.M. (2007) “Reusable, Lifelike Virtual Humans for Mentoring and Role-Playing”. In: Computers
and Education, Oxford: Elsevier Science Ltd., v. 49, n. 1, p. 75-92.
W3C Consortium. (2013) “HTML 5”. Disponível em: <http://www.w3.org/TR/html5/>. Acesso em:
24/03/2013.
WALSH, A. E. (2002) “Understanding scene graphs”. Dr Dobb’s Journal of Software Tools, v. 27, n. 7, p.
17-26.
Web Platform Docs. (2013) “DOM.” Disponível em: <http://docs.webplatform.org/wiki/dom>. Acesso
em: 20/03/2013.
Web3d Consortium. (2012) “What is X3D?” Disponível em: <http://www.web3d.org/realtime-3d/x3d/
what-x3d>. Acesso em: 10/02/2012.
WOOLFORD, D. (2003) “Understanding and using scene graphs”. (COMP4201 Lectures). Disponível em:
<www.itee.uq.edu.au>. Acesso em: 19/01/2012.
200
201
SILVA, Luciano. Simulações Físicas para Ambientes de RV e RA.
Simulações Físicas para Ambientes de RV e RA
Luciano Silva
Resumo
Simulações físicas permitem acrescentar um alto grau de realismo tanto em sistemas de RV quanto RA.
Com o aumento das capacidades de processamento de CPUs e GPUs, além do surgimento de bibliotecas,
frameworks e engines focados em Física, a realização de simulações complexas tornou-se uma realidade
e, em muitos casos, uma necessidade. Dentro deste contexto, este capítulo apresenta as bases de simulações físicas para RV e RA, apresentando desde as principais aplicações até detalhes internos de funcionamento de solvers e os fundamentos de programação para Havok Physics, um engine bastante comum e
portável para implementação de Física;
1. Introdução
Com o advento de placas gráficas programáveis e novas bibliotecas, frameworks e engines, fenômenos físicos podem ser incorporados em aplicações para RV e RA, com o objetivo de se alcançar
um alto grau de realismo em rendering e animação. Simulações baseadas em Física ou, simplesmente,
simulações físicas correspondem aos processos que permitem esta incorporação.
Porém, sem um embasamento físico teórico adequado, a utilização destas ferramentas, tanto em
hardware quanto em software, pode ficar limitada, pois uma grande parte deles implementa diretamente equações que dependem de um conhecimento mais aprofundado dos parâmetros para sua correta configuração. Esta exigência cria um ambiente interdisciplinar bastante interessante entre Computação e Física, fértil para pesquisas tanto no âmbito teórico quanto no aplicado.
Dentro deste contexto, este capítulo apresenta os principais conceitos físicos para utilização de
bibliotecas, frameworks e engines de Física, objetivando-se aplicações em RV e RA. Além deste suporte
teórico, o capítulo também apresenta os fundamentos de organização e programação para o engine de
Física Havok, que pode ser integrado com diversas soluções de RV e RA.
O texto está organizado da seguinte forma: a Seção 1.2 apresenta os principais tipos de fenômenos
físico-mecânicos importantes para ambientes de RV e RA; a Seção 1.3 apresenta as equações diferen201
ciais, muito úteis para modelagem de fenômenos físicos variacionais, além dos principais métodos
numéricos utilizados para solucioná-las, base da implementação dos solvers; a Seção 1.4 apresenta a
estrutura do engine de Física Havok e seus fundamentos de programação; a Seção 1.5 apresenta os
comentários finais deste capítulo e, finalmente, a Seção 1.6 apresenta um conjunto de referências bibliográficas aos interessados em iniciar desenvolvimentos nesta importante área de pesquisa.
2. Estática, Cinemática e Dinâmica
A Mecânica é uma área da Física que trata do movimento e repouso de corpos e sua evolução
no tempo. Compreende três sub-áreas principais: Cinemática e Dinâmica (movimento) e Estática
(repouso).
A Cinemática descreve os movimentos dos corpos utilizando, por exemplo, posições, velocidades e acelerações, sem se procupar com a análise de suas causas e consequências. Normalmente, os
resultados diretos dos cálculos cinemáticos são utilizados por processos de animação ou renderização
dentro de sistemas de RV e RA, sendo considerados elementos quantitativos dentro de um engine de
Física.
As causas e consequências do movimento de um corpo são os objetos principais de estudo da Dinâmica. Força, impulso e energia são alguns dos conceitos que podem estar relacionados às causas de
movimento, enquanto que deformação de corpos e transformações energéticas podem ser relacionar
às consequências de movimentos. Geralmente, os resultados diretos dos cálculos dinâmicos não são
utilizados diretamente pelos processos de animação ou renderização, pois precisam ser transformados
em posições, velocidades e acelerações. Por isto, são considerados elementos qualitativos dentro de
um engine de Física.
A Estática procupa-se com sistemas sob a ação de forças que se equilibram. Raramente, engines
de Física implementam ou disponibilizam recursos diretos de Estática. Assim, este capítulo considera
somente as sub-áreas de Cinemática e Dinâmica para a descrição dos fenômenos físicos relacionados
à Mecânica.
2.1 Cinemática e Dinâmica da Partícula
A Cinemática da partícula caracteriza o movimento de um ponto em relação a um referencial
(referenciais serão detalhados no próximo capítulo). Se o movimento do ponto em relação a um mesmo
referencial é carcaterizado unicamente pela variação da distância e sentido, este movimento é chamado
de retilíneo. Porém, se o movimento em relação a um referencial permanece constante s sua direção
varia segundo um plno, este movimento é chamado de circular ou curvilíneo (que inclui o bem conhecido movimento retilíneo). A Figura 1 ilustra exemplos destes movimentos no caso bidimensional:
202
Figura 1: Movimentos curvilíneo e circular de uma partícula.
O movimento retilíneo, do ponto de vista cinemático, fica completamente caracterizado em relação se forem fornecidas a posição, velocidade e aceleração. Para o movimento circular, são necessárias
a posição, velocidade angular e aceleração angular. Quando uma partícula está sujeita a um sistema
de forças não-equilibradas, ela terá um movimento acelerado. Força é toda a causa capaz de modificar
o estado de repouso ou de movimento de um corpo ou lhe causar deformações. As relações entre força
e movimento de partículas é o objeto de estudo da Dinâmica da partícula.
A Dinâmica da partícula é caracterizada por quatro conceitos fundamentais: espaço, tempo, massa e força. No caso geral, forças são funções do ponto de aplicação, da velocidade e do tempo. A Figura
2 ilustra diversas forças aplicadas a um bloco de massa m (de dimensões desprezíveis):
Figura 2: Forças (peso, atrito e normal) aplicadas a um bloco visto como uma partícula.
Na linha de Dinâmica da partícula, existem dois problemas fundamentais em RV e RA:
• conhecidas as leis de movimento de um partícula, pretende-se obter as forças que sobre ela
atuam ou
• conhecidas as forças que atuam sobre uma partícula, pretende-se obter o movimento desta
partícula.
203
2.2. Cinemática e Dinâmica de Corpos Rígidos
Os movimentos em Cinemática de corpos rígidos podem ser classificados em cinco tipos, conforme abaixo:
• Translação: ocorre quando qualquer reta, unindo dois pontos quaisquer do corpo, conserva
a mesma direção durante o movimento. A Figura 3 ilustra este tipo de movimento:
Figura 3: Translação curvilínea de um corpo rígido.
•
Rotação em Torno de um Eixo Fixo: ocorre quando os pontos que formam o corpo rígido
se deslocam em planos paralelos ao longo de circunferências, cujos centros estão sobre uma
mesma reta fixa. A Figura 4 ilustra este tipo de movimento:
Figura 4: Força unidimensional aplicada a um bloco visto como uma partícula.
•
Movimento Plano Geral: ocorre quando todos os pontos que formam o corpo se deslocam
em planos paralelos. Exemplos cássicos deste tipo de movimento são os discos rolantes e as
hastes deslizantes, conforme mostrado na Figura
g 5:
Figura 5: Movimentos planos gerais de corpos rígidos.
204
•
Movimento em Torno de um Ponto Fixo: movimento tridimensional em torno de um ponto
fixo como, por exemplo, o movimento de um ppião sobre o solo (Figura 5):
Figura 6: Movimento em torno de um ponto fi xo.
•
Movimento Geral: qualquer movimento que não esteja incluído nos movimentos anteriores.
Um exemplo típico deste movimento é o movimento caótico de um corpo rígido sobre a ação
do vento.
2.3 Cinemática e Dinâmica de Corpos Deformáveis
Corpos deformáveis (soft bodies) representam a categoria mais complexa de simulação física em
RV e RA, uma vez que a distância entre dois pontos quaisquer do objetos pode variar com o tempo.
Tanto para Cinemática quando para Dinâmica de corpos deformáveis, existem diversas abordagens
diferentes para o tratamento da deformação, dentre os quais se pode destacar:
• Modelo massa-mola (mass-spring): o corpo é modelado como um conjunto de pontos com
massa (nós), conectados por molas elásticas ideais e sem peso, que obedecem a alguma variação de Lei de Hooke ( a se tratada no capítulo de Dinâmica da Partícula). Este conjunto
pode ser utilizado como uma representação de malha poligonal para a superfície do corpo,
onde as simulações físicas podem ser aplicadas. A Figura 9 mostra um exemplo destas malhas
poligonais como sistemas massa-mola:
Figura 9: Exemplo de sistema massa-mola definindo uma malha poligonal.
205
Aplicando-se, por exemplo, a Segunda Lei de Newton (na forma diferencial) a cada um dos
nós da malha, obtém-se um sistema de equações diferenciais para o movimento dos nós que,
normalmente, é resolvido por esquemas numéricos para EDO (Equações Diferenciais Ordinárias) ou EDP (Equações Diferenciais Parciais). Uma vez realizada a simulação física, a
renderização de um modelo massa-mola pode ser realizado com esquemas convencionais do
tipo free-form deformation.
•
Dinâmica Baseada em Posição (Position-based Dynamics ou PBD): trata-se de uma abordagem baseada em relaxação de restrições, onde um modelo massa-mola é convertido em
um sistema de restrições. Este sistema é resolvido sequencialmente e interativamente, movimentando diretamente nós para satisfazer cada restrição, numa abordagem semelhante ao
método de Gauss-Seidel ao sistema matricial implícito definido pelo modelo massa-mola.
Trata-se de um esquema bastante utilizado para simulação em tempo real de tecidos nos
engines PhysX™, Havok Cloth™ e Maya nCloth™.
•
Deformação baseada em Corpos Rígidos: nesta abordagem, o corpo deformável é modelado
como uma malha de múltiplos corpos rígidos, conectados por restrições.
A Figura 10 mostra um exemplo destas malhas:
Figura 10: Malha de corpos rígidos subjacente a um corpo deformável.
Para efeitos de renderização, esta malha funciona como um sistema esquelético para a superfície do objeto. Assim, pode-se utilizar um esquema do tipo skinning mesh para calcular a
deformação da superfície do objeto. Esta abordagem é utilizada, por exemplo, na simulação
física de objetos deformáveis no Havok Destruction™.
•
Simulação de Elementos Finitos: nesta abordagem, que melhora sensivelmente a acurácia
da resolução das equações diferenciais de Cinemática e Dinâmica, o objeto deformável é visto como um continuum elástico, sendo discretizado em um grande número de elementos
sólidos (os elementos finitos). Estes elementos, tipicamente, são triângulos (superfícies) ou
tetraedros (volumes), agrupados e para os quais são simulados os modelos físicos para o corpo deformável.
206
2.4. Exemplos de Aplicações de Física em RV e RA
•
Colisão é, inegavelmente, umas das aplicações mais comuns de Física de contato dentro de
sistemas de RV e RA. A Figura 11 mostra uma sequência de imagens relativas a uma colisão
de um corpo rígido (uma esfera) com um corpo deformável (líquido):
Figura 11: Sequência de colisão de um corpo rígido com um corpo deformável.
Fonte: graphics.stanford.edu
O cálculo da interação entre a esfera e o líquido nesta colisão, assim como a movimentação do
líquido e a da esfera, são bastante complexos e exigem a aplicação das Equações de Navier-Stokes, um
sistema de equações de derivadas parciais.
207
A Animação baseada em Física é outro exemplo onde diversas áreas da Mecânica podem tornar
sequências de animações mais reais, como mostrado na Figura 12:
Figura 12: Animação baseada em Física, com aplicação de gravidade e fraturas em materiais.
Neste exemplo, foi aplicado um movimento retilíneo uniformemente variado (MRUV) para especificar a queda das esferas. O modelo de fratura para as esferas é um modelo dinâmico, com quantidade de fragmentos definida através de uma variável aleatória. Além, após a queda e fratura das esferas
no solo, ocorre a formação de um pequeno movimento oscilatório amortecido até o repouso total.
208
Ainda na linha de Animação baseada em Física, é muito comum se encontrar animações de corpos rígidos com presença de vínculos, conforme mostra a Figura 13:
Figura 13: Animação baseada em Física, com presença de vínculos em corpos rígidos.
Neste exemplo, os vínculos estão presentes como restrições que interligam os diversos componentes da ponte (corpo deformável). Embora a ponte como um todo seja um corpo deformável, suas componentes são corpos rígidos com equações de Cinemática e Dinâmica próprias, mas que obedecem às
restrições dos vínculos. A presença de vínculos também pode ser encontrada em sistemas esqueléticos
e musculares para animação de personagens.
209
O disparo de projéteis e balas por armas, muito comum em jogos baseados em RV e RA, representa um outro exemplo bastante comum de uso de diversos recursos de Cinemática e Dinâmica. O
exemplo da Figura 14 mostra o disparo de um projétil esférico (corpo rígido), com posterior colisão
com um anteparo (corpo deformável):
Figura 14: Colisão entre um projétil esférico e um anteparo deformável.
210
O movimento do projétil segue uma força Newtoniana. A deformação do anteparo até a sua posterior ruptura em fragmentos utiliza um modelo mais complexo que o sistema de ruptura do exemplo
anterior.
Simulação de Fluidos (líquidos, fogo, fumaça) podem ser realizados com grande acurácia via modelos físicos como as já mencionadas Equações de Navier-Stokes (líquidos) ou sistemas de partículas
(fogo, fumaça), inclusive com interações com outros corpos físicos. A Figura 15 mostra alguns exemplos destes fluidos já renderizados:
Figura 15: Exemplos de fluidos com simulação física renderizados.
211
É importante observar que as simulações físicas somente calculam os movimentos dos fluidos
(partículas, malhas e volumes). Os efeitos foto-realísticos são devido aos processos de renderização
baseada em Física (Physically Based Rendering), que trabalha com modelos de iluminação e materiais
adequados para fluidos.
Tecidos representam um exemplo típico de corpos deformáveis e possuem diversas aplicações em
RV e RA: vestimentas de personagens, bandeiras de demarcação de territórios, decoração de interiores
de cenários, dentre outros. A Figura 16 ilustra alguns exemplos de simulação física de tecidos, inclusive
com interação com objetos rígidos e fluidos:
Figura 16: Exemplos de simulação de tecidos e interação com corpos rígidos e deformáveis.
212
A simulação de tecidos, normalmente, é baseada em Dinâmica baseada em Posições, realizada
sobre modelos do tipo massa-mola. Estes modelos podem incluir diversas propriedades dos tecidos
como, por exemplo, massa, elasticidade e resistência das fibras do tecido, propriedades hidrodinâmicas de absorção de líquidos, vínculos (como os os prendem as extremidades dos tecidos na Figura 16),
dentre outras.
Veículos são objetos bastante complexos para simulação física pois, além de incluírem diversos
vínculos entre as suas diversas partes (carroceria, portas, direção, rodas, dentre outros), ainda precisam interagir com o meio onde circulam. O meio pode ser algo simples como nos dois primeiros quadros da Figura 17 (abaixo) ou mais complexo como o último quadro desta figura, onde há obstáculos
formados pelo próprio cenário, além de outros veículos.
Figura 17: Exemplos de veículos em ambientes simples e complexos.
213
Não é incomum se encontrar um sub-sistema somente dedicado a veículos em grande parte dos
engines de Física. Eles, normalmente, implementam os recursos de Cinemática e Dinâmica, além de
oferecerem uma interface para integração com dispositivos de E/S como volantes, para aumentar a
imersão do jogador.
Embarcações, por sua vez, não são tão comuns como os veículos em engines de Física. Normalmente, quando o sistema de RV ou RA necessita de tal recurso, é comum uma implementação própria
de recursos hidrostáticos e hidrodinâmicos para suportar a Cinemática e Dinâmica exigidas pelas
embarcações. A Figura 18 exibe alguns screenshots do jogo PT-Boats, que faz uso intensivo de recursos
de Física para embarcações.
Figura 18: Exemplos de embarcações e interação com os meios aquáticos/marinhos.
Fonte: Jogo PT-Boats
214
Além dos vínculos naturais entre as diversas partes das embarcações, há um fator bastante complexo na simulação física destes objetos: a interação com o meio líquido. Normalmente, as equações
são bastante complexas envolvendo as tradicionais Equações de Navier-Stokes para líquidos, além de
restrições com resistência dos materiais. Além disto, sub-sistemas para embarcações ainda deveriam
disponibilizar interfaces de interação com dispositivos de E/S e a navegação em meio aquático/marítimo requer maiores conhecimentos do usuário.
Aeronaves também não são tão comuns em engines de Física como os veículos. A própria mecânica de vôo, que exige cálculos complexos de Aerodinâmica, varia bastante de aeronave para aeronave.
Os elementos físicos que definem esta mecânica podem ser igualmente complexos aos das embarcações, mesmo que o meio (ar) tenha equações mais simples. A Figura 19 mostra dois exemplos de aeronaves em simuladores de vôo (dois quadros superiores da figura) e um exemplo de jogo de estratégia
aérea, com temática de guerra.
Figura 19: Exemplos de aeronaves.
215
Uma das principais dificuldades na implementação de aeronaves refere-se aos controles aerodinâmicos que, normalmente, exigem um conhecimento mais aprofundado não só de mecânica de vôo,
como também princípios de funcionamento dos diversos módulos que compõem a aeronave. Do usuário, também é exigido um grau maior de conhecimento destes controles, pois as interfaces dependem
deste conhecimento para operarem adequadamente.
3. Equações Diferenciais e Métodos Numéricos de Resolução
A parte central de um sistema de simulação física para RV e RA é composto por equações diferenciais. Uma equação diferencial é uma equação cujas incógnitas são funções na forma de derivadas.
Equações diferenciais são muito úteis para modelagem de fenômenos físicos, pois permitem estabelecer relações entre variações infinitesimais, representadas pelas derivadas. Por exemplo, a Segunda Lei
de Newton da Dinâmica para partículas é, na verdade, uma equação diferencial de segunda ordem:
‫ܨ‬Ԧ ሺ‫ݎ‬Ԧǡ ‫ݐ‬ሻ ൌ ݉
݀ଶ ‫ݎ‬Ԧ
݀‫ ݐ‬ଶ
Resolvendo-se esta equação, obtém-se o vetor-posição da partícula num instante t.
As equações diferenciais dividem-se em dois tipos:
•
Equação Diferencial Ordinária (EDO): contém apenas funções de uma variável e derivadas
daquela mesma variável. Um exemplo típico é a EDO do oscilador harmônico unidimensional, bastante comum na implementação de sistemas massa-mola:
݀ଶ ‫ݔ‬ሺ‫ݐ‬ሻ
݉
ൌ െ݇‫ݔ‬ሺ‫ݐ‬ሻ
݀‫ ݐ‬ଶ
Para se evitar a sobrecarga na notação, é comum se indicar as derivadas ,…, por , respectivamente. Assim, a EDO do oscilador harmônico unidimensional também poderia ser escrita
abreviadamente como:
݉‫ݔ‬ԢԢ ൌ െ݇‫ݔ‬
Dependendo da ordem das derivadas, uma EDO pode receber designações mais específicas.
Se contiver apenas derivadas de primeira ordem, será uma EDO de primeira ordem. Ela será
uma EDO de segunda ordem (como a do oscilador acima) se a maior ordem de derivação for
dois e assim por diante.
216
•
Equação Diferencial Parcial (EDP): contém funções com várias variáveis e suas derivadas
parciais. Um exemplo simples de EDP é a equação da onda, que permite obter um modelo
bastante simplificado para ondas se deslocando com velocidade em meios homogêneos e
isotrópicos:
߲ ଶ ‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ ߲ ଶ ‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ
߲ ଶ ‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ
ଶ
ൌ
‫ݒ‬
ቆ
൅
ቇ
߲‫ ݐ‬ଶ
߲‫ ݔ‬ଶ
߲‫ ݕ‬ଶ
Assim como ocorre nas EDOs, há também uma notação simplificadora
para derivadas parడమ ௨ሺ௫ǡ௬ǡ௧ሻ
ciais em EDPs: డ௨ሺ௫ǡ௬ǡ௧ሻ pode ser representada por ‫ݑ‬௧ , డ௧ మ , por ‫ݑ‬௧௧ e, o Laplaciano
డమ ௨ሺ௫ǡ௬ǡ௧ሻ
డమ ௨ሺ௫ǡ௬ǡ௧ሻ డ௧
൅ డ௬ మ , porమ ‫׏‬ଶ . Logo, a equação da onda pode ser escrita de forma simplificada
డ௫ మ
como:
‫ݑ‬௧௧ ൌ ‫ ݒ‬ଶ ‫׏‬ଶ ‫ݑ‬
EDPs também podem receber designações específicas como lineares, não-lineares, homogêneas, não-homogênas, hiperbólicas, parabólicas ou elípticas. Isto será tratado nos tópicos
específicos onde elas aparecem, assim como as interpretações de EDOs e EDPs do ponto de
vista físico.
Geralmente, para se explicitar uma solução específica, uma equação diferencial vem acompanhada ou de um valor inicial ou de uma condição de contorno. No caso de um valor inicial, tem-se um
problema chamado Problema de Valor Inicial (PVI) (ou Problema de condições Iniciais) como no
exemplo de EDO abaixo:
‫ݕ‬ᇱ ൌ ‫ݕ‬
൜
‫ݕ‬ሺͲሻ ൌ ʹ
Quando uma condição de contorno (ou fronteira) é fornecida, tem-se um Problema de Valor
sobre o Contorno (PVC). Um exemplo de PVC é a EDO abaixo no intervalo
݀ଶ‫ݕ‬
൅ ͵‫ ݕ‬ൌ ͳǡcom‫ݕ‬ሺͲሻ ൌ ʹe‫ݕ‬ሺͳሻ ൌ ͷ
݀‫ ݐ‬ଶ
Como a fronteira do intervalo é representada por 0 e 1, são fornecidas restrições de valores para
esta fronteira.
Existem diversos métodos numéricos (solvers) para se resolver EDOs. Nesta seção, serão apresentados os principais métodos comumente encontrados em engines de Física para problemas de valores
iniciais, em ordem crescente de complexidade das equações e métodos.
Inicialmente, será considerada um PVI da seguinte forma:
൜
‫ ݕ‬ᇱ ሺ‫ݐ‬ሻ ൌ ݂ሺ‫ݐ‬ǡ ‫ݕ‬ሻ
‫ݕ‬ሺ‫ݐ‬଴ ሻ ൌ ‫ݕ‬଴
217
Um dos métodos mais elementares para se resolver numericamente esta forma de EDO é o Método de Euler, bastante comum em engines de Física mais simples. Ele consiste em utilizar a seguinte
aproximação para a primeira derivada:
‫ݕ‬ሺ‫ ݐ‬൅ ݄ሻ െ ‫ݕ‬ሺ‫ݐ‬ሻ
‫ ݕ‬ᇱ ሺ‫ݐ‬ሻ ൎ
݄
Nesta aproximação, é chamado passo do método e é um importante parâmetro de configuração
dos solvers para EDOs nos engines de Física.
Para evitar o cálculo de múltiplas derivadas e ainda melhorar a acurácia do Método de Euler,
existe o Método de Runge-Kutta (Método RK), um dos mais utilizados em engines de Física, principalmente o de quarta ordem. A idéia básica do Método de Runge-Kutta é utilizar uma função F que
calcula ݂ሺ‫ݐ‬ǡ ‫ݕ‬ሻ em múltiplos pontos e tomar uma média aritmética ponderada destes valores para
obter uma aproximação da derivada de y. De uma forma geral, F tem a seguinte expressão:
௠
‫ܨ‬ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൌ ෍ ‫ݓ‬௝ ݂ሺ‫ݑ‬௝ ǡ ‫ݒ‬௝ ሻ
௝ୀଵ
O número m é chamado número de estágios ou ordem do Método de Runge-Kutta. Por exemplo,
o Método de Runge-Kutta de segunda ordem ( solver RK2) é dado por:
݄
݄
‫ݕ‬௜ାଵ ൌ ‫ݕ‬௜ ൅ ݄݂ ൭‫ݐ‬௜ ൅ ǡ ‫ݕ‬௜ ൅ ݂ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ൱
ʹ
ʹ
O solver RK2 também é conhecido como Método de Euler Melhorado. Já o Método de Runge-Kutta de quarta-ordem (solver RK4) é dado por:
݄
‫ݕ‬௜ାଵ ൌ ‫ݕ‬௜ ൅ ൫‫ܭ‬ଵ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൅ ʹ‫ܭ‬ଶ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൅ ʹ‫ܭ‬ଷ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൅ ‫ܭ‬ସ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ൯
͸
‫ܭ‬ଵ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൌ ݂ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ
݄
݄
‫ܭ‬ଶ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൌ ݂ ൭‫ݐ‬௜ ൅ ǡ ‫ݕ‬௜ ൅ ‫ܭ‬ଵ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ൱
ʹ
ʹ
݄
݄
‫ܭ‬ଷ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൌ ݂ ൭‫ݐ‬௜ ൅ ǡ ‫ݕ‬௜ ൅ ‫ܭ‬ଶ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ൱
ʹ
ʹ
‫ܭ‬ସ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ ൌ ݂൫‫ݐ‬௜ ൅ ݄ǡ ‫ݕ‬௜ ൅ ݄‫ܭ‬ଷ ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ሻ൯
O processo de obtenção destes dois métodos é bastante longo e utiliza alguns resultados elementares de otimização para se aproximar da expansão em Série de Taylor com a ordem correspondente. Ao
leitor interessado em verificar como estes métodos são obtidos, recomenda-se a referência LENGYEL
(2012).
218
Para EDOs de ordem superior, uma maneira bastante simples de se resolver consiste em transformar a equação em um sistema de EDOs de primeira ordem equivalente e aplicar algum dos solvers
vistos anteriormente. Por exemplo, considere-se a seguinte EDO de ordem 2:
‫ ݕ‬ᇱᇱ ൌ ݂ሺ‫ݐ‬ǡ ‫ݕ‬ǡ ‫ ݕ‬ᇱ ሻ
Esta EDO de ordem 2 é equivalente ao seguinte sistemas de EDOs de primeira ordem:
‫ ݕ‬ᇱ ሺ‫ݐ‬ሻ ൌ ‫ݖ‬ሺ‫ݐ‬ሻ
ቐ
‫ ݖ‬ᇱ ሺ‫ݐ‬ሻ ൌ ݂ሺ‫ݐ‬ǡ ‫ݕ‬ǡ ‫ ݕ‬ᇱ ሻ
Utilizando-se as condições iniciais e , pode-se derivar a seguinte variação do Método de Euler
para este sistema:
‫ݐ‬௜ାଵ ൌ ‫ݐ‬௜ ൅ ݄
‫ݕ‬௜ାଵ ൌ ‫ݕ‬௜ ൅ ݄‫ݖ‬௜
‫ݖ‬௜ାଵ ൌ ‫ݖ‬௜ ൅ ݄݂ሺ‫ݐ‬௜ ǡ ‫ݕ‬௜ ǡ ‫ݖ‬௜ ሻ
Em geral, uma EDO de n-ésima ordem , pode ser escrita como o seguinte sistema de EDOs de
primeira ordem:
‫ ݖ‬ᇱଵ ሺ‫ݐ‬ሻ ൌ ‫ݖ‬ଶ ሺ‫ݐ‬ሻ
‫ۓ‬
ۖ
ۖ
‫ ݖ‬ᇱ ଶ ሺ‫ݐ‬ሻ ൌ ‫ݖ‬ଷ ሺ‫ݐ‬ሻ
‫۔‬
ǥ
ۖ
ۖ
‫ ݖە‬ᇱ ௡ ሺ‫ݐ‬ሻ ൌ ݂ሺ‫ݐ‬ǡ ‫ݖ‬ଵ ǡ ‫ݖ‬ଶ ǡ ǥ ǡ ‫ݖ‬௡ ሻ
, que pode ser resolvida, dentro de determinadas condições iniciais, pelo Método de Euler, Método da
Série de Taylor ou Método de Runge-Kutta. É comum, devido à acurácia e velocidade do método, o
RK4 ser também implementado como rotina básica para resolução de EDOs de ordem superior dentro
dos engines de Física.
No entanto, é importante observar que os métodos apresentados anterioemente não são os únicos
para EDOs e que existem alguns métodos numéricos específicos para tipos específicos de EDOs, onde
há exploração de esquemas de simetria, esparsidade, dentre outros.
Geralmente, os métodos numéricos para resolução de EDPs baseiam-se no tipo específico da
equação (parabólica, hiperbólica ou elíptica). Uma maneira bastante comum para se resolver EDPs é
utilizar uma malha (grid), criar um processo de aproximação para as derivadas nesta malha e definir
um processo iterativo de melhorar esta aproximação.
Como exemplo desta estratégia, considere-se uma versão mais complexa da equação da onda,
mostrada abaixo, EDP classificada como hiperbólica:
219
߲ ଶ ‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ
߲ ଶ ‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ ߲ ଶ ‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ
߲‫ݑ‬ሺ‫ݔ‬ǡ ‫ݕ‬ǡ ‫ݐ‬ሻ
ଶ
ൌ
‫ݒ‬
ቆ
൅
ቇെߤ
ଶ
ଶ
ଶ
߲‫ݐ‬
߲‫ݔ‬
߲‫ݕ‬
߲‫ݐ‬
Nesta versão, além da velocidade de propagação da onda no líquido, introduziu-se o fator de
viscosidade do líquido. Para se obter uma aproximação numérica para esta equação, inicialmente
será definida uma malha , de tamanho , para a variáveis e a fim de se obter uma aproximação para as
derivadas, conforme mostra a Figura
Figura 28: Malha para resolução numérica da equação da onda.
Esta malha define uma discretização do ambiente onde a onda será simulada e a qualidade desta
simulação depende, inicialmente, do fator que regula a grossura da malha. Malhas mais grossas geram
resultados mais rápidos, porém de baixa qualidade. Malhas mais finas produzem resultados de melhora qualidade, porém são mais lentos de se calcular.
Utilizando um esquema de diferenças centrais nesta malha, as derivadas de primeira ordem podem ser aproximadas por:
߲‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ‫ݑ‬ሺ݅ ൅ ͳǡ ݆ǡ ݇ሻ െ ‫ݑ‬ሺ݅ െ ͳǡ ݆ǡ ݇ሻ
߲‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ
ൎ
߲‫ݔ‬
ʹ݀
߲‫ݕ‬
‫ݑ‬ሺ݅ǡ ݆ ൅ ͳǡ ݇ሻ െ ‫ݑ‬ሺ݅ǡ ݆ െ ͳǡ ݇ሻ
ൎ
ʹ݀
De maneira semelhante, as derivadas de segunda ordem podem ser aproximadas pelos seguintes
esquemas de diferenças:
220
߲ ଶ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ‫ݑ‬ሺ݅ ൅ ͳǡ ݆ǡ ݇ሻ െ ʹ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ െ ͳǡ ݆ǡ ݇ሻ
ൎ
߲‫ ݔ‬ଶ
݀ଶ
߲ ଶ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ‫ݑ‬ሺ݅ǡ ݆ ൅ ͳǡ ݇ሻ െ ʹ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ǡ ݆ െ ͳǡ ݇ሻ
ൎ
߲‫ ݕ‬ଶ
݀ଶ
߲ ଶ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ ൅ ͳሻ െ ʹ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ െ ͳሻ
ൎ
‫ݐ‬ଶ
߲‫ ݐ‬ଶ
Substituindo as aproximações de primeira e segunda ordens na equação da onda considerada,
tem-se:
‫ݑ‬ሺ݅ǡ ݆ǡ ݇ ൅ ͳሻ െ ʹ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ െ ͳሻ
‫ݐ‬ଶ
‫ݑ‬ሺ݅
൅
ͳǡ
݆ǡ
݇ሻ
െ
ʹ‫ݑ‬ሺ݅ǡ
݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ െ ͳǡ ݆ǡ ݇ሻ
ൌ ‫ݒ‬ଶ ቈ
቉൅
ଶ
݀
‫ݒ‬ଶ ቈ
‫ݑ‬ሺ݅ǡ ݆ ൅ ͳǡ ݇ሻ െ ʹ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ǡ ݆ െ ͳǡ ݇ሻ
‫ݑ‬ሺ݅ǡ ݆ǡ ݇ ൅ ͳሻ െ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ െ ͳሻ
቉െߤቈ
቉
ଶ
݀
ʹ‫ݐ‬
Normalmente, o interesse está em se obter uma fórmula para atualização da malha na posição
para um instante , ou seja, deseja-se conhecer o valor de . Isolando-se este termo na igualdade anterior,
tem-se:
ͺܿ ଶ ‫ ݐ‬ଶ
݀ ଶ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ሻ െ ߤ‫ ݐ‬െ ʹ ‫ݑ‬ሺ݅ǡ ݆ǡ ݇ െ ͳሻ
‫ݑ‬ሺ݅ǡ ݆ǡ ݇ ൅ ͳሻ ൌ ߤ‫ ݐ‬൅ ʹ
ߤ‫ ݐ‬൅ ʹ
Ͷെ
ʹܿ ଶ ‫ ݐ‬ଶ
ଶ
ሾ‫ݑ‬ሺ݅ ൅ ͳǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ െ ͳǡ ݆ǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ǡ ݆ ൅ ͳǡ ݇ሻ ൅ ‫ݑ‬ሺ݅ǡ ݆ െ ͳǡ ݇ሻሿ
൅ ݀
ߤ‫ ݐ‬൅ ʹ
Um detalhe bastante importante em relação a este tipo de método é a estabilidade. Por exemplo,
para que o método acima se torne estável, é necessário (além de boas condições iniciais) que o intervalo
de tempo t onde a simulação será feita obedeça à restrição abaixo:
Ͳ൏‫ݐ‬൏
ߤ ൅ ටߤ ଶ ൅ ͵ʹ
ͺ
ܿଶ
݀ଶ
ܿଶ
݀ଶ
O método anterior pertence à categoria dos Métodos das Diferenças Finitas (FDM - Finite Difference Method), bastante usual em engines de Física. Outros métodos numéricos que também são
comumente usados em RV e RA são: Método dos Elementos Finitos (FEM – Finite Element Method) e
o Método dos Volumes Finitos (FVM - Finite Volume Method). Ao leitor interessado no detalhamen221
to destes métodos adicionais (e outros específicos para EDPs parabólicas ou elípticas), recomenda-se
consultar a referência BURDEN e FAIRES (2008).
4. Engine Havok Physics™
O engine Havok Physics™ foi desenvolvido, inicialmente, pela empresa irlandesa Havok e, atualmente, é de domínio da Intel, que o disponibilizou gratuitamente para estudo e ensino. Ele disponibiliza recursos de Física para diversas plataformas como Windows™, Xbox™ (inclusive 360), Game Cube™,
Wii™, Playstation 2™ e 3™, PSP™, Linux™ e Mac OS X™, uma vez que é todo desenvolvido em C/C++.
Para a versão gratuita, os programadores têm à disposição um conjunto de bibliotecas dinâmicas
para ligar com as suas aplicações, sem acesso ao código-fonte. Aos possuidores de licenças, é fornecido
acesso ao código-fonte para otimizações e adaptações locais.
A estrutura genérica
g
do engine
g é mostrado na Figura
g 20:
Figura 20: Estrutura básica do engine Havok Physics™.
Fonte:www.havok.com
Esta estrutura é executada como um loop principal de simulação e, a partir de uma configuração
inicial, o Havok Physics™:
• Determina quais objetos estão sobrepostos (colisão) ou próximos de estarem em sobreposição, efetuada em três níveis de refinamento (broadphase, midphase e narrowphase) que serão
discutidos a seguir.
• Coleta informações de forças externas e determina, adicionalmente, quais forças são produzidas pelos processos de colisão.
• Com base em todo o sistema de forças e eventuais restrições (constraints), o solver (núcleo
central de simulação) calcula os próximos estados dos objetos (posição, orientação, velocidade, aceleração) e os disponibiliza para o sub-sistema que faz a atualização gráfica destes
objetos em tela. O solver pode ser disparado, eventualmente, sob coordenação de eventos.
222
De forma mais detalhada, os passos definidos anteriormente estão organizados nos elementos da
Figura 21:
Figura 21: Estrutura básica do engine Havok Physics™.
Fonte:www.havok.com
A detecção de colisão é uma das tarefas principais do Havok Physics™ . Há dois resultados importantes gerados pela colisão de pares de corpos: os agentes de contato (passados como parâmetros de
configuração para as ilhas de simulação) e os pontos de contato, passados para as configurações de
restrições, que serão detalhados no capítulo de tratamento de colisões.
Antes da simulação física, os objetos são agrupados em ilhas de simulação, que permitem que
grupos de objetos sejam simulados de forma independente aproveitando, por exemplo, recursos de
multithreading ou programação multi/manycore. Corpos podem compartilhar ilhas de simulação se
existe alguma restrição ou efeito físico entre eles como, por exemplo, um vínculo. A determinação
destas ilhas de simulação é realizada automaticamente pelo Havok Physics™ e não é possível (na atual
versão deste framework) interferir nesta determinação.
Uma ação é uma implementação que controla o estado dos corpos na simulação. A cada passo
de simulação, uma ação precisa ser adicionada ao mundo para que ela possa ser aplicada. O Havok
Physics™ já traz algumas ações pré-implementadas como, por exemplo, a ação de controle de veículos
(vehicle action) e outras mais específicas devem ser implementadas pelo programador, conforme será
mostrado posteriormente. Ações podem depender de implementações externas de forças.
223
Uma restrição (constraint) é uma relação entre dois corpos, utilizadas para criar corpos mais
complexos a partir de interrelacionamentos entre corpos mais simples. Forças aplicadas a um determinado corpo também são transmitidas, segundo as suas leis, para os outros corpos quer fazem parte
da restrição. Tipicamente, existem vários tipos de restrições que aparecem naturalmente em corpos
como springs (molas), dashpots (amortecedores) e joints(junções). Além de lidar com estes tipos de
restrições, o Havok Physics™ também recebe as informações das restrições de contato geradas pelo
sub-sistema de colisão.
Finalmente, entra em cena o solver, que resolve a dinâmica do sistema dentro das restrições apresentadas, repassando as informações de resolução para o integrador. O integrador calcula o novo
estado da movimentação (posição, orientação, velocidade, aceleração) para cada corpo, que pode ser
repassado, por exemplo, para um renderizador para exibição em tela.
Como exemplo de aplicação, considere-se a cena mostrada na Figura 22, composta de dois blocos
físicos que interagem entre si:
Figura 23: Exemplo de aplicação em Havok Physics™.
Fonte:www.havok.com
A implementação será realizada na linguagem C++, linguagem-base de programação da Havok
Physics.
O primeiro passo, é construir uma função main, definir uma configuração geral para a simulação
física através de uma classe HavokCore, conforme mostrado abaixo:
224
Um exemplo de classe HavokCore é mostrada abaixo:
225
Como exemplo de criação dos objetos físicos, tem-se o código abaixo, onde é criado um corpo
rígido e seão configurados os seus principais parâmetros físicos:
Nesta configuração, são definidos a posição (m_position), o tipo de movimento do corpo (m_motionType) e a forma do objeto (m_shape).
Este pequeno texto mostrou as principais aplicações de simulações físicas para ambientes de RV e
RA, além de evidenciar os seus princípios de funcionamento como equações diferenciais e solvers. O autor
espera que esta introdução ao tema possa despertar o interesse do leitor em aprofundar os seus conhecimentos nesta importante área de RV e RA, assim como contribuir para o avanço em pesquisas na área.
Referências
BOYCE, E.; DIPRIMA, W. Equações Diferenciais Elementares e Problemas de Valores de Contorno.
8.ed. Rio de Janeiro: Editora LTC, 2006.
BURDEN, R.L.; FAIRES, J.D. Análise Numérica. São Paulo: Gengage Learning, 2008.
EBERLY, D.H. Game Physics. New York: CRC Press, 2010.
JOST, J. Partial Differential Equations. New York: Springer-Verlag, 2002.
LENGYEL, E. Mathematics for 3D Game Programming and Computer Graphics. 3.ed. New York:
Course Technology PTR, 2012.
PALMER, G. Physics for Game Programmers. New York: Apress, 2005.
226
227
SILVA, Luciano. Desenvolvimento de Aplicações de RV e RA para Smart TVs.
Desenvolvimento de Aplicações de RV e RA para
Smart TVs
Luciano Silva
Resumo
Smart TVs são televisores digitais dotados de um ambiente capaz de executar aplicações e, geralmente,
disponibilizar mecanismos de interação mais sofisticados com os usuários como, por exemplo, reconhecimento de voz e gestos. Com o desenvolvimento de novas bibliotecas e frameworks, além de processadores
mais potentes, as Smart TVs configuram-se com um novo ambiente para desenvolvimento de aplicações
de RV e RA. Neste contexto, este capítulo apresenta os fundamentos de organização destas TVs e os princípios básicos de programação que podem suportar o desenvolvimento de aplicações de RV e RA neste
ambiente.
1. Introdução
Com a introdução de processadores genéricos e gráficos dentro dos televisores digitais, configurou-se nos últimos anos um ambiente bastante viável para desenvolvimento de aplicações chamado
Smart TV. Trata-se um televisor digital capaz de executar aplicações e disponibilizar mecanismos de
interação mais sofisticados como reconhecimento de voz e de gestos, além do tradicional controle
remoto.
Neste mesmo período, aumentou-se muito o desempenho e memória destes processadores que,
aliado ao desenvolvimento de bibliotecas, frameworks e engines específicos para programação de
Smart TVs, disponibiliza um novo ambiente para desenvolvimento de aplicações de RV e RA.
Dentro deste contexto, este capítulo se propõe a apresentar a organização básica deste novo ambiente e mostrar os seus princípios básicos de programação, objetivando-se construir um suporte para
implementação de aplicações para RV e RA. Além disto, dada a escassez de materiais sobre o assunto,
é intenção deste capítulo organizar um caminho inicial ao leitor interessado em prosseguir com pesquisas na área.
O texto está organizado da seguinte forma: a Seção 2.2 apresenta os detalhes de hardware de uma
Smart TV (SAMSUNG SMART TV), a Seção 2.3 traz a organização do ambiente operacional e das
227
aplicações, a Seção 2.4 mostra como fazer a tradicional aplicação Hello World no SAMSUNG SDK, a
Seção 2.4 mostra como programar o acesso à câmera, a Seção 2.5 como programar o sistema de reconhecimento de gestos, a Seção 2.6 como programar o sistema de reconhecimento de voz, a Seção 2.7
traz os fundamentos de acesso à câmera para suporte a AR, a Seção 2.8 traz os comentários finais e,
finalmente, a Seção 2.9 apresenta um conjunto de referências bibliográficas aos interessados em iniciar
desenvolvimentos nesta área emergente em RV e RA.
2 Samsung Smart TV
Como exemplo de smart TV a ser considerado neste texto, escolheu-se a Samsung Smart TV
(www.samsung.com) devido à sua potencialidade em termos de hardware e por possuir um dos SDKs
mais evoluídos no mercado. Outras opções possíveis de televisores digitais que também suportam
programação são as smart tvs da LG e da Sony.
A tela da Samsung Smart TV é composta por um sistema de leds e o aspecto visual do painel frontal é como o mostrado na Figura 1, onde já se pode notar a aplicação Smart Hub, que é uma espécie de
ambiente operacional que permite acesso ao vídeo do sinal de TV e às aplicações:
Figura 1: Samsung Smart TV, painel frontal.
Fonte: www.samsung.com
Nesta mesma figura, pode-se notar na parte superior a câmera o sistemas de captação de áudio
(microfones). Atualmente, há diversas resoluções destas TVs.
Alguns detalhes internos deste televisor não são divulgados(ainda) pela Samsung. Porém, sabe-se que
o processador atual destes televisores é dual core. Na linha do processador, uma grande vantagem da Samsung Smart TV é possibilidade de upgrade no processador através do Evolution Kit, mostrado na Figura 2:
228
Figura 2: Evolution kit.
Este kit é composto, essencialmente, de processadores genéricos e gráficos, além de memória.
Chama-se a atenção para o fato de que a saída deste kit é no estilo HDMI.
Vários modelos da Samsung SDK já vêm com suporte nativo a estereoscopia ativa. Normalmente,
o aparelho é acompanhado de dois a quatro óculos ativos, conforme mostra a Figura 3:
Figura 3: Óculos estéreos da Samsung Smart TV.
229
Outro detalhe bastante importante deste televisor é o suporte à tecnologia Anynet+, que permite
integrar vários dispositivos através de conexão cabeada (HDMI, por exemplo) ou através de adaptadores wi-fi, conforme mostra a Figura 4:
Figura 4: Redes de dispositivos Anynet+.
A tecnologia Anynet+ permite, por exemplo, controle (leitura/escrita) para projetores interligados
via HDMI. Assim, tem-se um suporte muito interessante para se trabalhar com visualização distribuída para RV. Se o dispositivo suporta a tecnologia Anynet+, o seu reconhecimento pelo televisor e pelas
aplicações é automático.
Outro recurso bastante interessante e que já está implementado em hardware é o reconhecimento
facial, conforme mostrado na Figura 5:
230
Figura 5: Reconhecimento facial na Samsung Smart TV.
Todas as informações provenientes do reconhecimento facial podem ser acessadas diretamente
pelas aplicações. No exemplo da Figura 5, o usuário faz um login automático no Skype.
O reconhecimento de gestos também é outra funcionalidade já implementada em hardware na
Samsung Smart TV. A Figura 6 mostra um exemplo da interface exibida ao usuário:
Figura 6: Sistema de reconhecimento de gestos da Samsung Smart TV.
231
Todas as informações de gestos podem ser recuperadas pelas aplicações. Além isto, é possível se
definir novos gestos e incorporá-los ao sistema de gestos do televisor. Finalmente, outro detalhe importante que também é implementado em hardware refere-se ao sistema de reconhecimento de voz,
mostrado na Figura 7:
Figura 7: Interface de reconhecimento de voz e dispositivo de amplificação.
Os comandos de voz podem ser direcionados para a TV em diversas línguas. Por exemplo, para
ligar a TV em Português dizemos “Ligar Smart TV”; já, em Inglês, dizemos “Turn on Smart TV”.
Quando a distância entre o usuário e o televisor não é suficiente para reconhecimento, utiliza-se um
dispositivo de amplificação como o mostrado na Figura 7.
3 Organização do Ambiente Operacional e Aplicações
Essencialmente, as aplicações para a Smart TV são “executadas” sob um grande navegador (browser) chamado Smart HUB, que pode ser visto quando o televisor carrega o ambiente operacional,
conforme mostra a Figura 8:
Figura 8: Smart HUB.
232
As aplicações, quando desenvolvidas, podem ser descarregadas diretamente na Samsung Smart
TV ou através do Hub Site, que é um repositório de aplicações para este televisor:
Figura 9: Hub Site.
O Hub Site pode ser acessado através de qualquer dispositivo ou diretamente da Samsung Smart TV.
Mesmo que as aplicações sejam “executadas” sob um navegador diferente, “executar” uma aplicação no Smart HUB é quase equivalente a visualizar uma página Web em um computador convencional, conforme mostrado na Figura
g 10:
Figura 10: Comparação entre execução de aplicações e visualização de páginas.
233
Esta “quase” equivalência deve-se às diferenças de resolução dos dois ambientes, especificações de
hardware e mecanismos de interação.
O mecanismo de controle do navegador do Smart Hub é feito por um engine chamado App Engine
que, atualmente (Março/2013), está na versão 6.0. Para gerenciar a “execução” das aplicações, existe um
gerenciador chamado Application Manager, que utiliza as funcionalidades do App Engine, conforme
mostra a Figura 11:
Figura 11: Camadas de controle de execução das aplicações na Samsung Smart TV.
Uma aplicação típica para a Samsung Smart TV é formada de uma página HTML, um arquivo
CSS, um arquivo JavaScript onde a aplicação é efetivamente programada, um arquivo de configuração
em XML e os artefatos da aplicação/página como imagens, vídeos, áudio e aplicações Flash. A Figura
12 mostra esta organização:
Figura 12: Componentes de uma aplicação para Samsung Smart TV.
Existem, basicamente, três formas de visualização para aplicações na Samsung Smart TV, mostradas na Figura 13:
234
full-screen
single-sided
g
ticker
Figura 13: Formas de visualização de uma aplicação para Samsung Smart TV.
Em full-screen, a aplicação ocupa toda a tela e outras aplicações são bloqueadas. Em single-sided,
a aplicação ocupa apenas uma parte da tela e outras aplicações podem “rodar” simultanemente. Em
ticker, a aplicação ocupa toda a tela, mas outras aplicações continuam a “rodar”.
4. A Aplicação “Hello World” em Samsung Smart TV SDK
Para desenvolvimento para Samsung Smart TV, é necessário o Samsung Smart TV SDK, que pode
ser descarregado gratuitamente do site da SAMSUNG (http://developer.samsung.com). O SDK é formado, além do framework de classes em Java, de um IDE conforme mostra a Figura 14:
235
Figura 14: IDE para desenvolvimento em Samsung Smart TV SDK.
Fonte: developer.samsung.com
Para usuários de Eclipse, existe um ambiente semelhante já pré-configurado. Para o teste das
aplicações, não é necessária uma Smart TV. Tanto a IDE da Samsung quanto o Eclipse já trazem um
emulador, como mostrado na Figura 15:
Figura 15: Emulador para aplicações em Samsung Smart TV SDK.
236
Como exemplo de programação, os próximos passos irão criar a famosa aplicação “Hello World”,
versão para Smart TV. O aspecto final da aplicação é como mostrado abaixo, onde já estão presentes
os arquivos do projeto:
p j
Figura 16: Aplicação Hello World em Samsung Smart TV SDK.
Os arquivos Main.css, Main.js, config.xml e index.html são criados automaticamente quando se
cria um projeto em Samsung Smart TV SDK. O primeiro arquivo importante é o config.xml, mostrado
abaixo:
237
No arquivo de configuração config.xml, define-se, por exemplo, se ela ocupará toda a tela (fullwidget ou ticker). No arquivo de configuração anterior, ambos os marcadores estão desabilitados (n), indicado que a aplicação será single-sided e terá um tamanho definido em width e height.
Configurações adicionais da janela podem ser definidas (ou redefinidas) no arquivo Main.css,
escrito em CSS (Cascading StyleSheet), como mostrado a seguir:
A aplicação fica vinculada, essencialmente, no arquivo Main.js, conforme mostrado a seguir:
238
O código acima interage com eventos do controle remoto mostrado (normal ou qwerty) na Figura
17 e substitui o identificador welcome, que conterá inicialmente uma frase com Hello World, para
outras mensagens:
Figura 17: Controles básicos de interação com aplicações na Samsung Smart TV.
239
Finalmente, todos estes arquivos são agrupados dentro do arquivo index.html, conforme mostrado abaixo, que é a página que dispara a execução da aplicação:
Observe que, em particular, a aplicação é carregada através da invocação do método onload do
objeto Main do arquivo Main.js. Observe, também, que esta invocação é síncrona, fato que pode concorrer para diminuir o desempenho das aplicações.
Para contrapor a chamada síncrona, é possível se utilizar algo semelhante ao AJAX, via tecnologia
XHR:
No objeto XHRExample, será definida uma chamada assíncrona muito semelhante ao que se faz
em AJAX:
240
Inclusive, a forma de utilização é muito semelhante ao AJAX: instancia-se um objeto XMLHttpRequest e indica-se a aplicação que se quer invocar.
Outro detalhe bastante importante e que permite transições suaves entre o carregamento das aplicações é feito através dos efeitos de transição. Pode-se utilizar, para tanto, o diagrama mostrado na
Figura 18:
Figura 18: Estados e transições entre as aplicações.
Abaixo, tem-se um exemplo
p de um esqueleto
q
de código
g para
p realizar as transições via JavaScript:
241
5. Reconhecimento de Gestos
O primeiro passo para realizar o reconhecimento de gestos é verificar se este recurso está habilitado e/ou disponível no seu televisor:
A partir desta confirmação, o reconhecimento é feito através registro e processamento de eventos,
conforme mostrado no código abaixo:
242
Todas as constantes utilizadas nos comandos case são pré-definidas no Samsung Smart TV SDK e
correspondem aos gestos. É possível, ainda, incluir o Gesture Helpbar, para trabalhar com gestos mais
complexos. O Gesture Helpbar
p é mostrado na Figura
g 19:
Figura 19: Gesture Helpbar funcionando em conjunto com o emulador do Samsung Smart TV SDK.
A leitura dos estados do Gesture Helpbar para saber qual o gesto foi escolhido, é mostrado abaixo:
243
6. Reconhecimento de Voz
Assim como ocorreu no reconhecimento de gestos, o primeiro passo para realizar o reconhecimento de voz é verificar se este recurso está habilitado e/ou disponível no seu televisor:
A partir deste reconhecimento, o processamento de áudio também é feito por detecção de eventos
e associação de ações:
244
Como exemplo do método handleMainCommand, o código abaixo reconhece os comandos up,
down, left, right, open e exit:
245
Para áudio, também existe o Voice Helpbar, mostrado na Figura 20:
Figura 20: Voice Helpbar funcionando em conjunto com o emulador do Samsung Smart TV SDK.
Assim como ocorria no Gesture Helpbar, o acesso ao Voice Helpbar também é feito através de
registro e tratamento de eventos:
246
É possível, também, a configuração de quais opções estarão disponíveis no Voice Helpbar:
247
7. Uso da Câmera
A câmera da Samsung Smart TV é um dos recursos mais importantes para dar suporte a aplicações baseadas em RA. O primeiro passo é inicializar a câmera:
A inicialização da câmera ocorre quando o usuário clica no botão PLAY, disponível na interface
do simulador (ou da TV). A partir disto, pode-se iniciar a captura dos frames ou parada da câmera,
conforme mostra o código abaixo:
248
O objeto deviceapis pode, agora, ser integrado a bibliotecas de RA que dão suporte à linguagem
Java. É possível, por exemplo, se utilizar os ports de ARToolkit para Java ou mesmo o Samsung Smart
TV AR Simulator.
Este pequeno texto mostrou os fundamentos de desenvolvimento de aplicações para Smart TVs,
com foco no equipamento Samsung Smart TV e com ênfase nos mecanismos que possam servir de suporte a aplicações de RV e RA. Como todos observarão abaixo, existe uma quantidade bastante escassa
de referências nesta área, dada a sua atualidade.
Assim, o autor espera que esta pequena introdução ao tema possa despertar o interesse de alunos,
professores e pesquisadores de RV e RA no desenvolvimento de técnicas, bibliotecas, frameworks, engines, padrões e aplicações para alavancar esta área emergente em RV e RA.
Referências
Para se conhecer o suporte de redes para aplicações na Samsung Smart TV, recomenda-se as duas
referências de livros abaixo, onde deve ser dada especial atenção aos mecanismos de IPTV. Para desenvolvimento, recomenda-se iniciar pelo documento Samsung Developer Guide. Há, também, uma
comunidade bastante ativa no Samsung Developer Forum.
BENOIT, H. Digital Television: Satellite, Cable, Terrestrial, IPTV, Mobile TV in the DVB
Framework. New York: Focal Press, 2008.
SIMPSON, W. IPTV and Internet Video. New York: Focal Press, 2009.
SAMSUNG. Samsung Developer Program. Disponível em: http://developer.samsung.com. Acesso
em: 01.03.2013.
__________. Samsung Developer Forum. Disponível em: http://www.samsungdforum.com/.
Acesso em: 05.03.2013.
__________. Samsung Developer Guide. Disponível em: http://www.samsungdforum.com/
Guide/. Acesso em: 05.03.2013.
249
250
CERQUEIRA, Christopher Shneider; KIRNER, Claudio. Introdução à utilização de openFrameworks
para o desenvolvimento de aplicações de RVA
Introdução à utilização de openFrameworks para o
desenvolvimento de aplicações de RVA
Christopher Shneider Cerqueira
Claudio Kirner
Abstract
Virtual and augmented reality interactive applications development requires tools that easy and accelerates the coding time through the reuse of components. The openFrameworks is an example of tool oriented to reuse. This chapter shows the context of openFramework use and this type of tool-framework, with
the exploration of three examples: one basic to explain the structure, one using additional components
and the third to develop an augmented reality environment.
Resumo
Desenvolvimento de aplicações interativas de realidade virtual e aumentada requer ferramentais que
facilitem e acelerem o tempo de codificação através do reuso de componentes. O openFrameworks é um
exemplo deste tipo de ferramental. Neste capítulo é mostrado o contexto de utilização e outros exemplos
de frameworks, a exploração de três exemplos: um básico para explicar a estrutura, um utilizando componentes adicionais e o terceiro desenvolvendo um ambiente de realidade aumentada.
1. Introdução
O desenvolvimento de sistemas interativos nem sempre é apenas uma atividade de codificação
para cientistas da computação ou engenheiros. Artistas, professores, designer e estudantes dos mais
variados segmentos podem se interessar em criar interações que satisfaçam as suas necessidades de
apresentação ou coleta de dados, focando em aplicações que possam parecer extremamente high-tech
ou utilizar metáforas de interação mais parecidas com o ambiente temático onde será implantado.
Este capítulo descreve em breves linhas, um roteiro de desenvolvimento desde a explicação de
conceitos básicos de desenvolvimento interativo e criativo, os cenários atuais de alguns frameworks e a
motivação de reutilizar componentes de código livre. Passa por uma explicação estrutural e dinâmica
250
do funcionamento do openFrameworks (oF), mostrando o que é possível e o papel importante da comunidade de desenvolvimento.
O exemplo ilustrado, passo a passo, mostra como gerar um novo exemplo, partindo para a utilização de alguns componentes interessantes como o ofxAssimp, um wrapper da biblioteca ASSIMP [1]
que permite a utilização de vários formatos de modelos tridimensionais, o ofxEasyCam, da biblioteca
do openFrameworks que permite fácil interação de movimentação de elementos 3D da cena e por fim
utilização do componente ofxARToolKitPlus, um wrapper do ARToolKitPlus [2], para criação de ambientes de realidade aumentada [3], como mostrado na Figura 1.
Figura 1. oF em criação de ambientes de realidade aumentada.
Nota-se que o oF é muito mais que este pequeno exemplo, contudo para fins ilustrativos e introdutórios foi escolhido este roteiro.
1.2. Conceitos básicos de desenvolvimento criativo e interativo
Desenvolvimento criativo e interativo é focado primariamente na interação, criando aplicações
que o usuário realize interações diretamente de forma mas natural e envolvente. O usuário necessita
de uma boa experiência de forma que o valor agregado do seu sistema seja atingido.
Atualmente tem-se utilizado a terminologia de Desenvolvedor de Experiência com Usuário, ou
UX Developer do Inglês User Experience Developer [4], como a maneira de denominar o profissional,
ou equipe, que não desenvolve apenas interfaces com o usuário, mas é capaz de determinar experiências de uso, neste são necessários o conhecimento de frentes multidisciplinares como psicologia,
antropologia, sociologia, semiótica, epistemologia, historia, etc. [5]. O Desenvolvedor de Experiência
colhe o design da meta-mensagem alvo e a recobre pela interface que contém a tecnologia para realizar
a interação [6].
Mas o que é interação? Qual a sua natureza? Interação pode ser definida como a troca de informação entre dois ou mais atores. Como um desenvolvedor de interação, é necessário entender o que
o usuário quer, qual ambiente ele está inserido, quais os fatores culturais para definir como ele vai
251
entrar com dados, e como espera que o sistema responda. Interação não se trata de uma atividade unidirecional com o sistema, trata-se da transformação do sistema num sistema reativo [7] que responde
aos estímulos do usuário. Um exemplo de atividade unidirecional é a transmissão de televisão, este é
simplesmente um sinal transmitido se o usuário está ou não escutando, e ocorre no seu próprio tempo.
A televisão digital tem inserido controles, que podem retroceder, adicionar legendas ou informações.
Estes controles introduzem interação a um sistema que era unidirecional, mudando substancialmente
a maneira como a experiência de uso ocorre, agora a televisão ocorre no tempo do usuário, centrada
nas suas expectativas e necessidades.
Interação ocorre através das trocas bidirecionais de mensagens entre o sistema e o usuário. Estas
podem ser texto, voz, cores, imagens, respostas ou entradas mecânicas. O mais difícil de criar interações é entender como o sistema vê as mensagens do usuário e como os usuários veem as mensagens do
sistema. Para ilustrar esta dificuldade pense na maneira que duas pessoas conversam; a comunicação
entre eles foi calcada em anos de estudo (treinamento), aprendendo a linguagem, formas de interação.
Quando um sistema aumenta a complexidade da sua interação mais coisas podem dar errado. Para isso
o desenvolvedor deve tentar antecipar as experiências.
A interface que cobre as mensagens e uma parte importante em comunicar a interação. A interface
é o meio entre o usuário e o sistema, este diz o que é possível e o que não é possível, o que é eficiente
ou não e a emoção da interação. Ter uma interface funcional, expressiva e atrativa é importante para
tornar a interação agradável ao usuário.
Interações tem um vocabulário, assim como a nossa comunicação. O usuário deve entender a
ação que realiza e saber que o sistema entende que a ação realizada tem um significado e realizará a
atividade esperada. Interações podem envolver: manipulação física, entrada de códigos, manipulação
de mouse, reconhecimento de presença, local ou imagem, interfaces hápticas e de toque, gestos ou
reconhecimento de voz. Cada uma destas modalidades de interação tem suas propriedades e características, que devem ser analisadas.
Finalizando, a tarefa ou objetivo é facilitar a interação homem-sistema, seja essa para visualização
de dados, organizar-se, criar experiências, permitir colaboração entre usuários, controlar mecanismos
e experimentos, criar ambientes ou contar uma narrativa.
1.3. Cenário atual dos frameworks
Existem varias formas de desenvolver interação criativamente, neste momento serão revistos alguns ferramentais (frameworks) mais conhecidos como Processing, Flash, Unity, cinder e o openFrameworks.
Processing é um framework desenvolvido para Java. É uma ferramenta open-source e tem um
forte apelo educacional. É baseada em programação via código e possibilita a utilização de
openGL. É possível conectar bibliotecas Java para complementar as aplicações e aumentar as
possibilidades. Uma das vantagens é a fácil exportação de projetos para web. Processing está
disponível em: http://processing.org/
Adobe Flash é uma possibilidade bem conhecida para desenvolvimento criativo, baseado em ActionScript. É muito utilizado por ter uma estrutura familiar com ferramentas de design como
252
o Photoshop e Illustrator. A IDE de desenvolvimento da Adobe é paga, contudo existe a opção do Flash Builder, pois esta é grátis para estudantes e professores. Flash é completamente
exportável para web, porem isso impacta na performance e no acesso a hardware quando
comparado a outras tecnologias. Flash Buider está disponível em: http://www.adobe.com/
products/flash-builder-family.html
Unity é um motor de jogos, grátis para desenvolvimento em Windows e pago para dispositivos
móveis, e como motor de jogos permite desenvolvimento com grafo de cena, editor de níveis,
etc. A programação pode ser realizada em C#. Não é open-source, mas deve ser considerado
depende do projeto. Unity está disponível em: http://unity3d.com/
Cinder é um ferramental open-source e cross-plataform disponível para Mac, iOS e Windows.
A programação é baseada em C++ e possui diversos elementos prontos: como manipulação
3D, áudio, vídeo, rede, processamento de imagem, etc. Cinder está disponível em: http://
libcinder.org/features/
openFrameworks é um ferramental open-source e cross-plataform disponível para Mac, Linux,
Windows, Android e iOS. A programação é baseada em C++ e isso permite uma liberdade,
que num ponto dificulta o iniciante, mas em contrapartida possibilita a utilização da criatividade para qualquer aplicação. Possui uma gama de componentes criados pela comunidade
facilitando o reuso além dos elementos prontos como: manipulação 3D, áudio, vídeo, rede,
processamento de imagem, etc. openFrameworks está disponível em: http://www.openframeworks.cc/
2. oF – openFrameworks
oF é uma coleção de códigos criados para ajudar em uma determina atividade, ou framework. Alguns frameworks são criados para trabalhar com banco de dados, outros para controle de Internet. oF
é um framework que, em tese, foi criado para artistas e designers trabalharem com design interativo.
Contudo, a atividade não é simples, pois requer conhecimento em C++, uma linguagem forte e poderosa, porém complexa. Como a base da codificação é em C++, este é um framework que permite muita
flexibilidade e acesso a hardware. oF é desenvolvido principalmente por Zach Liberman, Theo Watson,
Artuno Castro e Chris O’Shea e hoje recebe colaborações da comunidade. oF nasceu do desconforto da
falta de comunicação entre diversas bibliotecas em C++, que não falavam a mesma língua.
Deve-se considerar utilizar oF quando:
• O projeto renderiza muitos gráficos 3D, e/ou;
• Utilizar muita visão computacional, e/ou;
• Controlar equipamentos, como, por exemplo, o ARDUINO.
oF inclui uma série de bibliotecas, como:
• OpenGL, GLEW, GLUT, libtess2 e cairo para gráficos.
• rtAudio, PortAudio ou FMOD e Kiss FFT para entrada, saída e análise de áudio.
• FreeType para fontes.
• FreeImage para salvar e carregar imagens.
253
•
•
Quicktime e videoInput para playback e aquisição de vídeo.
Poco, que contém uma variedade de utilidades.
O código foi bem escrito para ser compatível com várias arquiteturas e vários ambientes de desenvolvimento, no momento de escrita deste capítulo eram suportados cinco sistemas operacionais (Windows, OSX, Linux, iOS e Android) e quatro IDEs (XCODE, Code::Blocks, Visual Studio e Android).
Deve-se ainda ressaltar que é open-source distribuído utilizando a Licença MIT [8].
2.1. Requisitos para desenvolvimento
Neste capítulo utilizaremos como exemplo o sistema operacional Windows, utilizando a IDE/
Compilador do Visual Studio C++ 2010 Express (VC2010E). Assim é necessário fazer o download e
instalação do VC2010E, fazer o download do oF correspondente e o add-on do ARToolKitPlus.
O oF fornece os tutoriais para cada sistema operacional e ambiente de desenvolvimento na página:
http://www.openframeworks.cc/download/
Para este exemplo, devem ser realizados o download do oF (versão 0.7.4 no momento de escrita
deste capítulo) para Visual Studio 2010 (Seta 1 na Figura 2) e da realização da configuração do ambiente de desenvolvimento com o tutorial (Seta 2 na Figura 2).
Figura 2. Download do openFrameworks.
254
Caso não queira seguir o tutorial do ambiente de desenvolvimento o link para o VC2010E é o
seguinte: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express
Tendo o oF e o VC2010E instalados, faça um teste inicial, descompacte a pasta em algo semelhante
à Figura 3:
Figura 3. Exemplo de caminho para desenvolvimento.
Para testar um exemplo e validar o ambiente de desenvolvimento vá à pasta de exemplo, pasta de 3D, exemplo pointPickerExample e faça duplo click no arquivo pointPickerExample.sln. Como
ilustrado na Figura 4.
Figura 4. Projeto do VC2010E.
Como ilustração do uso no VC2010E, pode-se gerar o executável em versão Release ou Debug,
selecione a versão Release (Seta 1 na Figura 5) e com o botão direito clique em Solution ‘pointPickerExample’ no Solution Explorer (Seta 2 na Figura 5) e selecione Build Solution. Este procedimento deve
compilar o oF e o exemplo. Gerando o seguinte resultado de compilação como na Figura 6 e o exemplo
da execução na Figura 7. Nota-se que todas as dlls necessárias para são copiadas para a pasta bin.
255
Figura 5. Procedimento para compilar.
Figura 6. Resultado esperado da compilação.
256
Figura 7. Exemplo do funcionamento.
2.1.1. Componentes da Comunidade
Uma das vantagens do oF é o fato da comunidade poder desenvolver componentes ou funcionalidades que possam ser inseridas no oF. Estes componentes são chamados de add-ons.
A página oficial (http://ofxaddons.com/) de contribuições do oF está dividindo os add-ons nos
seguintes seguimentos:
• Animation: animação de elementos simples, como posicionar e movimentar na tela.
• Bridges: bridges são formas de adicionar elementos de outros frameworks, adaptando a interface de dados para o oF.
• Computer Vision: rotinas de rastreio, usando openCV e Kinect.
• Graphics: rotinas para renderizar elementos na tela.
• GUI: componentes para criar interfaces com usuário.
• Hardware Interface: rotinas de acesso a vários hardwares.
• iOS: rotinas específicas para desenvolvimento e utilização dos recursos do iOS.
• Machine Learning: rotinas de inteligência artificial.
• Physics: rotinas de processamento de física, colisão, etc.
• Sound: rotinas e wrappers de bibliotecas para tratamento e execução de áudio.
• Typography: rotinas para manipulação de texto.
257
•
•
•
Utilities: rotinas diversas para manipulação com o computador, sistema operacional e outros
recursos.
Video/Camera: rotinas e wrappers de bibliotecas para tratamento e execução de vídeo e dados
de câmera (incluindo Kinect e openNI).
Web/Networking: rotinas para interconexão de sistemas, http, ftp, json, ssl, etc.
Para o exemplo, faça o download do add-on do ofxARToolKitPlus do fishkingsin como indicado
na Figura 8, pois o mesmo é o mais atualizado (Last updated: 30 January, 2013). Salve numa pasta conhecida. Sugestão: colocar na mesma pasta que o oF.
Figura 8. Link para download do ofxARToolKitPlus.
3. Desenvolvendo exemplos
Com os requisitos prontos (oF para Visual Studio, VC2010E e ofxARToolKitPlus) é possível explorar um roteiro para explicar o funcionamento e tentar suavizar a curva de aprendizado. O roteiro será
dividido em três casos, com incremento de dificuldade:
• Caso 1: o exemplo vazio para explorar a estrutura de arquivos do oF, a utilização do gerador
automático e a organização do código.
• Caso 2: exemplo com modelos 3D para explorar a utilização de bibliotecas de modelos 3D e
de controle de câmera.
• Caso 3: exemplo com RA para explorar a utilização de add-ons adicionais.
3.1. Caso1: O exemplo vazio
Descompactando o oF, temos uma série de pastas que contêm a estrutura do oF, como visto na
Figura 9.
258
Figura 9. Estrutura das pastas do oF.
De cima para baixo temos os seguintes itens:
• Pasta addons: contém os add-ons que estendem o oF. Para adicionar um novo add-on basta
salva-lo nesta pasta. Geralmente o add-on inicia-se com as letras ofx;
• Pasta apps: local sugerido para salvar os projetos de desenvolvimento;
• Pasta examples: contém diversos exemplos (100) dos recursos do oF, separados pelas temáticas: 3d, add-ons, communication, events, gl, graphics, math, sound, utils e video;
• Pasta export: contém as dlls que são exportadas para a pasta de execução durante a montagem/compilação;
• Pasta libs: contém as bibliotecas estáticas dos componentes que fazem parte do oF. Algumas
bibliotecas para serem livre determinam que a aplicação só pode usar a versão da biblioteca
dinâmica, neste caso apenas os includes (.h) estão nesta pasta;
• Pasta other: contém um exemplo de código para comunicação com ARDUINO;
• Pasta projectGenerator: contém o gerador de projeto que facilita a montagem do projeto.
Cada distribuição de oF contem um gerador de projeto para a arquitetura/IDE desejada;
• Pasta script: contém scripts para facilitar o funcionamento, este diferencia para cada distribuição do oF;
• Arquivos changes.txt e license.md: contém uma listagem das principais alterações e da licença de uso.
3.1.1. O gerador automático projetos
Uma das grandes dificuldades é montar o projeto para a IDE e resolver todas as dependências
de add-ons, para resolver este problema o oF disponibiliza um gerador automático de projetos. Ele se
encontra dentro da pasta projectGenerator no caminho do oF. A utilização da interface é bem simples,
259
contendo campos para nomear o projeto, qual o endereço (para o gerador criar o projeto com todos
os endereços relativos corretamente), a plataforma do gerador e quais os add-ons, como na Figura 10.
Figura 10. Pagina inicial do projectGenerator.
Clicando em Addons abre-se um novo menu pedindo para selecionar os add-ons desejados. Para
este caso deixaremos todos os add-ons sem seleção, como na Figura 11, e retornar para o menu anterior.
Figura 11. Menu para escolher add-ons do projectGenerator.
260
OBS.: Em alguns casos houve problema de compilar, isso ocorreu devido ao caminho do oF ou
do projeto conter espaços e se o oF e o projeto estão em HD separados.
Para gerar o projeto, por exemplo, na pasta <of>/apps/myApps/ clique em GENERATE PROJECT.
Na pasta gerada, é colocada a estrutura para o desenvolvimento utilizando a IDE/SO desejado, no
caso VC2010E no Windows. Neste, o projeto é o <of>/apps/myApps/caso1/caso1.sln.
3.1.2. Estrutura lógica dos arquivos de projeto
Abrindo o projeto, no Solution Explorer estão dois projetos, o do caso1 e do openFrameworks. Na
maioria dos casos não é necessário modificar o oF, mas se necessário é requerido uma recompilação.
Expandindo os diretórios do caso1, na pasta com os fontes (src) existem três arquivos, que são o básico
do funcionamento do oF: main.cpp, testApp.cpp e o testApp.h, como na Figura 12.
Figura 12. Estrutura do projeto no VC2010E.
O arquivo main.cpp é o ponto inicial, contendo o int main(). Neste arquivo não é necessário nenhuma modificação. Porém é interessante explicar a função ofRunApp(). Esta função é responsável por
alocar a classe que contém os métodos padrões para o funcionamento: testApp.h. Esta classe herda da
classe virtual ofBaseApp o formato e métodos virtuais que devem ser implementados para ser compatível com o esperado pela ofRunApp. A Figura 13 mostra o código do arquivo main.cpp.
261
#include “ofMain.h”
#include “testApp.h”
#include “ofAppGlutWindow.h”
//========================================================================
int main( ){
ofAppGlutWindow window;
ofSetupOpenGL(&window, 1024,768, OF_WINDOW);
GL context
// <-------- setup the
// this kicks off the running of my app
// can be OF_WINDOW or OF_FULLSCREEN
// pass in width and height too:
ofRunApp( new testApp());
}
Figura 13. Código fonte do main.cpp.
O arquivo de cabeçalho testApp.h, é a implementação concreta da classe virtual ofBaseApp, com
as definições concretas dos métodos, como mostrado na Figura 14.
#pragma once
class testApp : public ofBaseApp{
public:
void setup();
void update();
void draw();
void
void
void
void
void
void
void
void
void
};
keyPressed (int key);
keyReleased(int key);
mouseMoved(int x, int y );
mouseDragged(int x, int y, int button);
mousePressed(int x, int y, int button);
mouseReleased(int x, int y, int button);
windowResized(int w, int h);
dragEvent(ofDragInfo dragInfo);
gotMessage(ofMessage msg);
Figura 14. testApp.h inicial para o caso1.
262
Os métodos são implementado no arquivo fonte testApp.cpp. O gerador automático cria os métodos sem conteúdo, como na Figura 15, adaptada.
#include “testApp.h”
//-------------------------------------------------------------void testApp::setup(){ }
//-------------------------------------------------------------void testApp::update(){ }
//-------------------------------------------------------------void testApp::draw(){ }
//-------------------------------------------------------------void testApp::keyPressed(int key){ }
//-------------------------------------------------------------void testApp::keyReleased(int key){ }
//-------------------------------------------------------------void testApp::mouseMoved(int x, int y ){ }
//-------------------------------------------------------------void testApp::mouseDragged(int x, int y, int button){ }
//-------------------------------------------------------------void testApp::mousePressed(int x, int y, int button){ }
//-------------------------------------------------------------void testApp::mouseReleased(int x, int y, int button){ }
//-------------------------------------------------------------void testApp::windowResized(int w, int h){ }
//-------------------------------------------------------------void testApp::gotMessage(ofMessage msg){ }
//-------------------------------------------------------------void testApp::dragEvent(ofDragInfo dragInfo){ }
Figura 15. testApp.cpp inicial para o caso1.
Os desenvolvedores de openGL estão acostumados com esta divisão de métodos, que separam
em apenas uma função os procedimentos de controle e desenho da janela e nos outros métodos são
realizadas a gerencia dos dados.
• O método void testApp::setup() é chamado no início do programa, e nele são colocadas todas as inicializações do programa, por exemplo, se tem que ler algum arquivo com as definições
do programa, se tem que configurar qual o conteúdo da barra de título ou inicializar variáveis.
• O método void testApp::update() é chamado sempre que a aplicação não estiver ocupada
resolvendo a exibição. Nesta, por exemplo, são chamadas as funções de captura e análise de
uma câmera, requisições de status de hardware, atualização de conexão, etc.
• O método void testApp::draw() é chamado para realizar o “desenho” da janela, apenas
esta função pode abrir contextos de exibição. Lembrando que assim como o openGL o ponto
0,0 é o canto superior esquerdo e o incrementa-se o valor de X no sentido esquerda à direita e
incrementa-se o valor de Y no sentido superior à inferior.
263
•
•
•
•
•
O método void keyPressed(int key) e void keyReleased(int key) são relacionados
à utilização do teclado como forma de interação, o primeiro é chamado quando uma tecla é
pressionada e o segundo quando todas as teclas (se mais de uma) forem liberadas. Os métodos tem como parâmetro de entrada o código da tecla. O arquivo <of>/libs/openFrameworks/
utils/ofConstants.h contém os códigos das teclas.
Os métodos void mouseMoved(int x, int y ), void mouseDragged(int x, int y, int
button), void mousePressed(int x, int y, int button) e void mouseReleased(int
x, int y, int button) tratam a utilização do mouse como forma de interação, o primeiro é chamado no caso onde ocorrer um arraste do mouse, no momento que ele é liberado, o
segundo é chamado quando um botão do mouse é apertado e o terceiro quando os botões (se
mais de um) forem liberados. Os métodos tem como parâmetro de entrada a posição x, y na
tela da aplicação e qual o botão apertado.
O método void windowResized(int w, int h) é chamado quando ocorrer um redimensionamento
da tela, este método é útil para adaptar o conteúdo da tela para o redimensionamento, por exemplo:
ajustando a orientação, posicionamento e exibição de conteúdo.
O método void dragEvent(ofDragInfo dragInfo) é chamado quando algo de fora da
aplicação é arrastado para dentro do contexto. É utilizado, por exemplo, quando se deseja
arrastar uma figura para a aplicação. O método recebe como parâmetro de entrada a nova
largura (w - weight) e a nova altura (h – height).
O método void gotMessage(ofMessage msg) é chamado quando uma mensagem de
algum bloco da aplicação pede atenção.
Compilando o programa é gerado na pasta /bin do projeto o programa caso1.exe com as dlls necessárias para execução, como mostrado na Figura 16a e o resultado da execução na Figura 16b.
ç
g
(a)
(b)
Figura 16. (a) pasta bin com arquivos copiados e gerados; (b) executando o exemplo vazio.
Para fechar o Caso1, modificaremos o programa para exibir uma mensagem que segue o mouse, e
quando clicar na tela desenhar um círculo de raio regulável pelo arrasto do mouse.
264
Criar as variáveis na classe testApp.h, como na Figura 17:
...
string mensagem;
int x_i,y_i;
float raio;
...
Figura 17. testApp.h para o caso1 modificado.
Para este teste, basta preencher os métodos setup para inicializar a mensagem e o raio inicio, preencher o mousePressed para salvar a posição inicial do mouse, e mouseDragged para mudar o raio de
acordo com o arraste e finalizar o valor do arraste em mouseReleased. No método draw foi colocado
para imprimir um circulo da cor azul, no ponto onde o mouse foi criado com o raio do arraste, e em
vermelho a mensagem seguindo os valores do mouse, como na Figura 18.
//-------------------------------------------------------------void testApp::setup(){
mensagem = “Hello SVR2013!!!”;
raio = 0;
}
//-------------------------------------------------------------void testApp::draw(){
ofSetColor(ofColor::blue);
ofCircle(x_i,y_i,raio);
ofSetColor(ofColor::red);
ofDrawBitmapString(mensagem,mouseX,mouseY);
}
//-------------------------------------------------------------void testApp::mouseDragged(int x, int y, int button){
raio = ofDist(x_i,y_i,x,y);
}
//-------------------------------------------------------------void testApp::mousePressed(int x, int y, int button){
x_i = x;
y_i = y;
}
//-------------------------------------------------------------void testApp::mouseReleased(int x, int y, int button){
raio = ofDist(x_i,y_i,x,y);
}
Figura 18. testApp.cpp para o caso1 modificado.
265
3.2. Caso2: Adicionando modelos 3D e controle de câmera
Este caso trata o uso de um modelo 3D manipulado pelo add-on ofxAssimp e pelo controle de
visualização via a câmera ofEasyCam.
Incialmente deve-se gerar o projeto utilizando o projectGenerator, coloca-se o nome caso2 e escolhe o add-on ofxAssimp. Para separar o processo, dividiremos em duas etapas, inserção do modelo
3D e depois da manipulação:
3.2.1. Inserindo modelos 3D.
O oF fornece na distribuição uma add-on para utilização da biblioteca Assimp. Esta biblioteca foi
desenvolvida em C++, sob licença BSD, e possui bindings para outras linguagens, como C# e Python.
E a vantagem de utilização desta lib é a possibilidade de carregar vários formatos de modelos 3D,
utilizando-os de maneira semelhante. Alguns exemplos de tipos de modelos possíveis são: Collada,
Blender, 3DS Max, AutoCad, Ogre, Quakes, Valve, Unreal e DirectX X.
O site do Assimp disponibiliza para download um AssimpViewer e este pode ser utilizado para
testar se o modelo e o tipo desejado funcionam. Para este exemplo foi utilizado um dos modelos do
exemplo da biblioteca Assimp, mas poderia ser realizado o download de um modelo 3D no formato
Collada do repositório 3D do Google (http://sketchup.google.com/3dwarehouse/). O modelo antes
de ser utilizado pode ser testado utilizando o aplicativo AssimpViewer, como visto na Figura 19.
Figura 19. Modelo visualizado no assimpViewer.
266
O projeto do oF já está preparado para procurar os caminhos da biblioteca ofxAssimpModelLoader. O primeiro passo para inserir o modelo 3D no oF no arquivo testApp.h é criar uma variável do
tipo afxAssimpModelLoader e o include da biblioteca, como na Figura 20.
#pragma once
#include “ofxAssimpModelLoader.h”
// Não apagar o que já tinha
ofxAssimpModelLoader model;
};
Figura 20. testApp do caso2 com a instancia do modelo.
O segundo passo é realizar a carga do modelo no método setup() e no método draw() fazer a chamada do modelo, posicionando-o no centro da janela, como visto no código da Figura 21 e o Resultado
na Figura 22.
ofBackground(50, 0);
//Configura o fundo
// Abre o arquivo
if( !model.loadModel(“astroBoy_walk.dae”, false) )
ofSystemAlertDialog(“Erro em carregar arquivo”);
// configurações do openGL
glEnable(GL_DEPTH_TEST);
glShadeModel(GL_SMOOTH); //some model / light stuff
}
// Configura a cor do objeto
ofSetColor(255);
ofPushMatrix();
// Abre o contexto do openGL
ofTranslate(ofGetWidth()/2,ofGetHeight()/2+100,0);
//model.drawWireframe(); // desenha o wireframe
model.drawFaces();
// desenha as faces
//model.drawVertices();
// desenha os vértice
ofPopMatrix();
// fecha o contexto do openGL
}
Figura 21. testApp.cpp com os métodos setup() e draw() preenchidos.
267
Figura 22. Resultado do caso2.
3.2.2. Manipulando o modelo
O oF disponibiliza um componente de manipulação de câmera, chamado ofEasyCam. Este componente é um facilitador de visualização 3D, permitindo orbitar e dar zoom com o arrasto do mouse
com o botão esquerdo ou o direito apertado, respectivamente.
Para utilizar o ofEasyCam deve-se criar na classe testApp.h um atributo do tipo ofEasycam, e no
método draw() abrir e fechar o contexto da EasyCam, como mostrados na Figura 23 e Figura 24.
#pragma once
...
ofEasyCam cam;
};
Figura 23. testApp.h do caso2 com EasyCam.
268
ofSetColor(255);
// Configura a cor do objeto
cam.begin();
// Abre o contexto da câmera
//model.drawWireframe();
// desenha o wireframe
model.drawFaces();
// desenha as faces
//model.drawVertices();
// desenha os vértice
cam.end();
// fecha o contexto da câmera }
Figura 24. testApp.cpp do caso2 com EasyCam no método draw().
3.3. Caso3: Juntando dois mundos
Para o desenvolvimento de RA é possível criar um rastreador de característica com alguma metodologia, seja ela usando openCV ou algum derivado, para rastreio de características naturais, ou
utilizar o rastreio de marcadores.
Está disponível para o oF um wrapper do ARToolKitPlus, inicialmente desenvolvido pelo grupo
da Graz University of Technology [2] como uma alternativa ao ARToolKit desenvolvido pelo HITLab
[9]. O ARToolKitPlus, foi feliz em alguns aspectos, dentre eles a velocidade de rastreio, pois ao invés
da análise realizada em todo a área de código do marcador, validando o seu conteúdo, apenas algum
pontos numa matriz de 6x6 são rastreados para identificar o marcador. Este tipo de marcador tem um
código, ou ID, característico e implícito. Este tipo de técnica é chamado de ID-encoded marker detection enquanto o do ARToolKit é chamado template marker detection.
Para este caso, será explorado o exemplo dado pelo ofxARToolKitPlus, porém com a criação inicial do projeto e depois com a inserção do código, e com a utilização do modelo 3D adicionado no caso
2 como exemplo de conteúdo virtual. O procedimento será dividido em duas partes, desenvolvimento
da infraestrutura, relacionamento do real com o virtual através do rastreio de marcadores, e depois da
inserção do modelo 3D.
3.3.1. Desenvolvendo infraestrutura
O primeiro passo é descompactar o ofxARToolKitPlus e salva-lo dentro de <of>/addons. Ele vem
com o sufixo –master. Este sufixo deve ser apagado, deixando apenas o nome principal.
O primeiro passo para o desenvolvimento é criar o projeto, através do projectGenerator. Para este
caso, devem ser marcado os add-ons ofxOpenCv, ofxAssimpModelLoader e o ofxARToolKitPlus. De
forma a repetir o procedimento, nomeia-se este projeto como caso3.
O projeto vem incompleto, sem as definições de biblioteca estática do oxARToolKitPlus. Para incluir, deve-se entrar nas propriedades do projeto (caso3), Configuration Properties Æ Linker ÆGeneral
ÆAdditional Library Directories e inclua o caminho para a biblioteca, no caso:
..\..\..\addons\ofxARtoolkitPlus\libs\ARToolKitPlus\lib\win32
269
E em Configuration Properties ÆLinker ÆInput Æ Additional Dependencies incluir a lib:
ARToolKitPlus.lib
O ARToolKitPlus utiliza o openCV, por isso deve ser adicionado também. Como os outros casos,
no arquivo testApp.h deve ser adicionado os includes necessários e as variáveis. Neste exemplo, utilizamos o rastreio de câmera do próprio oF, é necessário instanciar a classe do ARToolKitPlus, e as
variáveis de processamento de imagem do openCV. O cabeçalho testApp.h está na Figura 25.
#pragma once
#include “ofxOpenCv.h”
#include “ofxARToolkitPlus.h”
//Cabeçalho do OpenCV
//Cabeçalho do ARToolKitPlus
public:
void setup();
void update();
void draw();
void
void
void
void
void
void
void
void
void
keyPressed (int key);
keyReleased(int key);
mouseMoved(int x, int y );
mouseDragged(int x, int y, int button);
mousePressed(int x, int y, int button);
mouseReleased(int x, int y, int button);
windowResized(int w, int h);
dragEvent(ofDragInfo dragInfo);
gotMessage(ofMessage msg);
int width, height;
ofVideoGrabber vidGrabber;
// Tamanho da janela da câmera
// Componente do oF que pega a câmera.
ofxARToolkitPlus artk;
int threshold;
// Instância do ARToolKitPlus
// Threshold da relação preto/branco
ofxCvColorImage colorImage;
ofxCvGrayscaleImage grayImage;
ofxCvGrayscaleImage grayThres;
//imagem capturada pela câmera
//imagem em tons de cinza (mais rápida)
//imagem com threshold antes de ir pro artk
};
Figura 25. testApp.h do caso3 com carregador de vídeo e ARToolKitPlus.
270
No caso 3 serão necessários o preenchimento de quatro métodos do arquivo fonte testApp.h
O primeiro método chamado é o setup(), serão configurados a janela, o tamanho da imagem,
alocado na memória o local para armazenar o buffer de aquisição da câmera, e das etapas de processamento de imagem, inicializado o ARToolKitPlus (neste caso utilizando calibração e marcadores
padrão), o ARToolKitPlus faz o threshold automático, mas para fins de mostrar o resultado, neste
exemplo, ficará manual. O método setup() está ilustrado na Figura 26.
ofSetWindowShape(1280,480);
// Ajusta o tamanho da aplicação
width = 640; height = 480;
// largura e altura da imagem da câmera
vidGrabber.initGrabber(width, height);
câmera
colorImage.allocate(width, height);
rida
grayImage.allocate(width, height);
grayThres.allocate(width, height);
tada
// reserva espaço para o buffer da
artk.setup(width, height);
padrão
// inicia o ARToolKitPlus com valores
threshold = 85;
artk.setThreshold(threshold);
ajuste é externo
}
// threshold para a imagem ajustada
// informa ao ARToolKitPlus que o
// reserva espaço para a imagem colo// reserva espaço para a imagem mono
// reserva espaco para a imagem ajus-
Figura 26. Método setup() do testApp.h do caso3.
O método update() realiza as leitura da câmera, o processamento da imagem, e envia a imagem
monocromática para o ARToolKitPlus realizar o rastreio. A Figura 27 contém o código do método
update();
271
//-------------------------------------------------------------void testApp::update(){
vidGrabber.grabFrame();
frame da câmera
bool bNewFrame = vidGrabber.isFrameNew();
novo
// Pega
// configura que é um frame
if(bNewFrame) {
// se um frame novo
/pega os pixels do buffer da câmera e armazena
colorImage.setFromPixels(vidGrabber.getPixels(), width, height);
grayImage = colorImage; //converte a imagem para mono
//Como queremos testar o threshold temos que gerar essa imagem
grayThres = grayImage;
grayThres.threshold(threshold);
//Passa para o ARToolKitPlus a imagem monocromática
artk.update(grayImage.getPixels());
}
}
Figura 27. Método update() do testApp.h do caso3.
A exibição da camada virtual junto com a real filmada é realizada no método draw(). Neste exemplo foi dividida a exibição em duas imagens, a principal com a sobreposição e a imagem adaptada para
exemplificar o rastreio. As imagens são exibida pela função draw() da imagem, antes de cada uma é
necessário indicar a cor branca, senão a janela fica de acordo com a última cor. A imagem colorida usa
a colorImage.draw() e a adaptada grayThres.draw(). Como em RA o conteúdo virtual sempre sobrescreve o conteúdo real filmado, inicialmente devem ser exibidas as duas imagens. Para mostrar qual o
marcador foi encontrado é utilizado a função draw do ARToolKitPlus. Para detectar os marcadores
é necessário aplicar a matriz de projeção da câmera. Para cada marcador encontrado é aplicado um
modelo 3D, no exemplo é um empilhamento de retângulos ajustados para matriz de perspectiva do
marcador da lista de marcadores encontrados. A Figura 28 contém o código do método draw().
272
ofSetColor(ofColor::white);// inicia a cor dos objetos como branca
colorImage.draw(0, 0);// exibe a imagem capturada colorida
grayThres.draw(640, 0);// exibe a imagem adaptada
artk.draw(640, 0);// Esta função exibe a posição e etiqueta o marcador
// ARTK 3D
artk.applyProjectionMatrix(); // primeiro passo é aplicar a matriz de projeção da camera
int numDetected = artk.getNumDetectedMarkers(); //detectar os marcadores
ofEnableAlphaBlending();//habilitar a transparência
for(int i=0; i<numDetected; i++) { // passar por todos os marcadores encontrados
artk.applyModelMatrix(i); //aplicar a matriz de perspectiva do marcador
//Local onde colocar o conteúdo 3D do marcador
// neste exemplo é uma pilha de retângulos.
ofNoFill();
ofEnableSmoothing();
ofSetColor(255, 255, 0, 50);
for(int i=0; i<10; i++) {
ofRect(-25, -25, 50, 50);
ofTranslate(0, 0, i*1);
}
}
}
Figura 28. Método draw() do testApp.h do caso3.
Para o ajuste manual do threshold é necessário tratar a entrada de teclado. Para isso é necessário
utilizar o método keyPressed. Nele deve-se filtrar qual a tecla foi apertada e aplicar o resultado desejado. Neste são utilizados a tecla da seta para cima para aumentar o valor do threshold e a respectiva
tecla para baixo para diminuí-lo. Adicionalmente a tecla ‘s’ abre o painel de configuração da aquisição
da câmera. O método keyPressed está na Figura 29.
273
//-------------------------------------------------------------void testApp::keyPressed(int key){
if(key == OF_KEY_UP) {
artk.setThreshold(++threshold); // aumenta o valor do threshold
} else if(key == OF_KEY_DOWN) {
artk.setThreshold(--threshold); // diminui o valor do threshold
} else if(key == ‘s’) {
vidGrabber.videoSettings(); // chama a configuração da câmera
}
}
Figura 29. Método keyPressed() do testApp.h do caso3.
O resultado da compilação está na Figura 30.
Figura 30. Resultado do reconhecimento do caso3.
3.3.2. Adicionando conteúdo
Finalizando a sequencia de passos, criada a infraestrutura é necessário inserir o conteúdo, para
isto será reutilizado o modelo do caso 2 (encontrado no exemplo do ofxAssimp no oF). Semelhante
ao caso 2, deve-se incluir o cabeçalho do ofxAssimpModelLoader e criar uma variável do modelo no
arquivo testApp.h, como exemplificado no código da Figura 31.
274
#pragma once
#include “ofxOpenCv.h”
#include “ofxARToolkitPlus.h”
...
ofxCvGrayscaleImage
grayThres;
};
Figura 31. testApp.h do caso3 com exibição de modelo 3D.
No método setup() é necessário carregar o modelo, e no método draw() após a aplicação da matriz
de perspectiva do marcador desenhar o modelo 3D. Estes passos estão ilustrados na Figura 32, que
contém os dois métodos completos para melhor ilustrar a posição destes elementos adicionais.
ofSetWindowShape(640,480);// Ajusta o tamanho da aplicação
width = 640; height = 480;// largura e altura da imagem da câmera
vidGrabber.initGrabber(width, height);// reserva espaço para o buffer da
câmera
colorImage.allocate(width, height);// reserva espaço para a imagem colorida
grayImage.allocate(width, height);// reserva espaço para a imagem mono
artk.setup(width, height);// inicia o ARToolKit plus com valores padrão
ofBackground(50, 0);//Configura o fundo
// Abre o arquivo
if( !model.loadModel(“astroBoy_walk.dae”, false) )
ofSystemAlertDialog(“Erro em carregar arquivo”);
}
275
Continua
ofSetColor(ofColor::white);// inicia a cor dos objetos como branca
colorImage.draw(0, 0);// exibe a imagem capturada colorida
ofDrawBitmapString(“alive”,mouseX,mouseY);
artk.draw(0, 0);// Esta função exibe a posição e etiqueta o marcador
// ARTK 3D
artk.applyProjectionMatrix();// primeiro passo é aplicar a matriz da câmera
int numDetected = artk.getNumDetectedMarkers(); //detectar os marcadores
for(int i=0; i<numDetected; i++) { // passar por todos os marcadores encontrados
artk.applyModelMatrix(i); //aplicar a matriz de perspectiva do marcador
//Local onde colocar o conteúdo 3D do marcador
//pilha de retângulos.
ofPushMatrix();// Abre o contexto
ofEnableAlphaBlending();
ofEnableSmoothing();
ofSetColor(255, 255, 0, 50);
for(int i=0; i<10; i++) {
ofRect(-25, -25, 50, 50);
ofTranslate(0, 0, i*1);
}
ofDisableSmoothing();
ofDisableAlphaBlending();
ofPopMatrix();// fecha o contexto
// Modelo 3D
ofSetColor(255);// Configura a cor do objeto
ofPushMatrix();// Abre o contexto
glEnable(GL_DEPTH_TEST);// habilita profundiade
ofScale(0.1,0.1,0.1);// ajusta escala
ofRotateX(-90);// rotaciona 90 graus
model.drawFaces();// desenha as faces
glDisable(GL_DEPTH_TEST); // desabilita profundidade
ofPopMatrix();// fecha o contexto
}
}
Figura 32. Métodos setup() e draw() do testApp.h do caso3 com exibição de modelo 3D.
276
O resultado da adição de conteúdo 3D está na Figura 33.
Figura 33. Resultado do caso3 com modelo 3D.
4. Conclusões
Este capítulo visou apresentar um ferramental, de desenvolvimento multi-plataforma baseado em
C++, chamado openFrameworks. Sendo o mesmo open-source e livre para desenvolvimento educacional e comercial.
Apresentou-se dois casos introdutórios, para explicar o framework e sua estrutura e o uso de
elementos adicionais, no caso o uso da biblioteca Assimp, chamados add-on, finalizando com um
exemplo de construção de ambientes de realidade aumentada utilizando uma biblioteca similar ao
ARToolKitPlus.
Como contribuição, esperamos que este ferramental auxilie no desenvolvimento de aplicações
mais criativas e de desenvolvimento veloz, com:
• Codificação C++ portável
• Facilidade de acesso a hardware
• Múltiplos componentes prontos disponíveis pela comunidade
• Facilidade de acesso ao disco
• Facilidade de comunicação
• Facilidade de uso de áudio e vídeo.
Como sugestão de livro e aprofundamento, aconselhamos o livro Programming Interactivity da
O´Reilly e os tutoriais do site do openFrameworks.
277
Referências
GESSLER, A.; SCHULZE, T.; KULLING K.; NADLINGER, D. “Assimp,” 2013. [Online]. Available: http://
assimp.sourceforge.net/. [Acesso em 15 03 2013].
D. Wagner e D. Schmalstieg, “ARToolKitPlus for Pose Tracking on Mobile Devices,” Proceedings of 12th
Computer Vision Winter Workshop (CVWW’07), Fevereiro 2007.
KIRNER, C.; CERQUEIRA, C. S.; KIRNER, T. G. “Claudio Kirner, Christopher Shneider Cerqueira and
Tereza Gonçalves Kirner (2012). Using Augmented Reality Cognitive Artifacts in Education and Virtual
Rehabilitation, Virtual Reality in Psychological, Medical and Pedagogical Applications, Dr. Christiane,” em
Virtual Reality in Psychological, Medical and Pedagogical Applications, InTech, 2012.
REICHELT L. “What is a UX Developer and are they really a thing?,” 25 01 2012. [Online]. Available: http://
www.disambiguity.com/what-is-a-ux-developer/. [Acesso em 15 03 2013].
TOGNAZZINI, B. Tog on interface, Addison-Wesle, 1992.
FERNANDES, L. A. F. “Interface Homem/Máquina,” 2011. [Online]. Available: http://www2.ic.uff.
br/~laffernandes/teaching/2011.1/tcc-00.184/aula_06.pdf. [Acesso em 15 03 2013].
WIERINGA, R. J. Design methods for reactive systems: yourdon, statemate, and the uml, Amsterdam,
Netherlands: Morgan Kaufmann, 2003.
OPEN SOURCE INITIATIVE. “The MIT License,” Open Source Initiative, [Online]. Available: http://
opensource.org/licenses/MIT. [Acesso em 15 03 2013].
LAMB, P. “ARToolKit,” [Online]. Available: http://www.hitl.washington.edu/artoolkit/. [Acesso em 13 03
2013].
278

Book 1.indb

Transcrição

Documentos relacionados

Realidade Aumentada Aplicada a Medicina

Técnicas de Interação para Ambientes de Realidade Virtual e

IPOSTAL LANÇA CARTÃO MÁGICO PARA O DIA DOS NAMORADOS

Ambientes Interativos e Colaborativos baseados em Realidade

DOI - IEEE-RITA

Jornalismo aumentado: experiências digitais com novas camadas

Desenvolvimento de Jogo da Memória Educativo Infantil utilizando

Investigadores desenvolvem sistema de comunicação entre

Realidade Aumentada para o Ensino de Geometria Espacial

Corollarium é escolhida pelo MinC para expor na feira Museum