avaliação de usabilidade para aplicações de realidade aumentada

Tendências e Técnicas em Realidade Virtual e Aumentada

Av. Bento Gonçalves, 9500 - Setor 4 - Prédio 43.412 - Sala 219 - Bairro AgronomiaCEP 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 RegionaisEdson Norberto Cáceres (UFMS)Diretor de Divulgação e MarketingRoberto da Silva Bigonha (UFMG)

Diretor de Relações ProfissionaisRicardo de Oliveira Anido (UNICAMP)

Diretor de Competições CientíficasRaimundo José de Araújo Macêdo (UFBA)

Diretor de Cooperação com Sociedades CientíficasSergio Vanderlei Cavalcante

Diretor de Articulação de Empresas

Publicação anual | Cuiabá | v. 3 | p. 1-278 | 2013

Tendências e Técnicas em Realidade Virtual e Aumentada

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

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

AnualISSN 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 de-senvolvidos 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 Socie-dade Brasileira de Computação e organizado pelo Instituto de Computação da Univer-sidade Federal de Mato Grosso (UFMT) e apoiado pelo Instituto Federal de Ciência e Tecnologia de Mato Grosso (IFMT).

Cuiabá, MT2013

Índice para catálogo sistemático:1. Realidade Virtual e Aumentada: Ciência da Computação 006

Dados Internacionais de Catalogação na Publicação (CIP)

EDITORESAlexandre CardosoEzequiel ZorzalMarcelo de Paiva GuimarãesMárcio Pinho

CONSELHO EDITORIALAlexandre CardosoEzequiel ZorzalFátima L. S. NunesLiliane dos Santos MachadoLuciano P. SoaresMarcelo de Paiva GuimarãesMárcio PinhoSelan Rodrigues

PRODUÇÃO GRÁFICACanal 6 Projetos Editoriais - www.canal6.com.br

5

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, Ed-gard 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

6

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 Le-meszenski, 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

7

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 Com-putaçã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 exi-bidos 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 apresen-ta 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 organizadoresAlexandre Cardoso

Ezequiel ZorzalMarcelo de Paiva Guimarães

Márcio Pinho

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 inte-ractions, high levels of motivation and involvement, autonomy, special devices independence, etc. Fur-thermore, 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 pro-fessores e alunos possam utilizar intensivamente essa tecnologia, como a necessidade de conhecimen-tos 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

10


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 uti-lizados;

• 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 professo-res, 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 desenvol-vimento 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 en-contrar 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 educa-cional.

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, denomi-nada 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.

11


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 aprendiza-gem 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 reali-dade 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 pro-duzir 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.

12


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 fren-te 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, difi-cultando 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 pro-fissionais comprometidos com o produto, mas, recentemente, com o crescimento da filosofia de aber-tura [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.

13


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 FLA-RAS enquadra-se aqui, usando dois marcadores.

A ausência de marcador facilita a manipulação da aplicação, mas deve ser precedida de um cadas-tramento 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.

14


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 vir-tuais 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 compu-tador do usuário, a partir de ações visuais, e solicitam a digitação de parâmetros como posição, incli-naçã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 ar-quivos 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 pro-gramaçã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 pura-mente 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.

15


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 sis-temas 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 caracte-rí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 FLA-RAS, 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 educacio-nais 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.

16


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 fer-ramenta 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 her-dada 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 tam-bé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 tex-tos 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.

17


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 desabili-tada 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 inter-face 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

18


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 qua-tro á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.

19


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 posiciona-mento 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 aumenta-da [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 necessi-dade 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

20


aplicação educacional online com realidade aumentada, abordando o jogo de geometria – sólidos geo-mé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 des-locado 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 base-ado nas revoluções das figuras planas.

A área de figuras, mais abaixo, permite explorar as figuras, identificando aquelas que serão asso-ciadas 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.

21


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 aci-dentais, 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 ani-maçõ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 mos-tradas, 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üen-cial 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 fi-

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

22


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 mar-cador.

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 apon-tando 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 apli-caçã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.

23


4.4. Adaptação do Jogo

O projeto do jogo também permite que os usuários possam estudá-lo e modificá-lo, gerando apli-caçõ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 local-mente, 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 caracte-rística importante é a alta capacidade de adaptação das aplicações desenvolvidas com FLARAS, permi-tindo 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 desen-volvidos, 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.

24


Espera-se que a facilidade de produção e de adaptação desses jogos, aliada a sua inerente capa-cidade 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, Th e New Media Consortium, http://www.nmc.org/pdf/2012-horizon-report-K12.pdf.

JOHNSON, L.; SMITH, R.; WILLIS, H.; LEVINE, A.; HAYWOOD, K. (2011) “Th e 2011 Horizon Report”, Austin, Texas, Th e 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, Th e 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.

25


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: Co-Learning 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, Th e New Media Consortium, http://www.nmc.org/pdf/2013-horizon-higher-ed-shortlist.pdf.

NMC (2013) “NMC Horizon Reports”, Austin, Texas, Th e 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/fl artoolkit/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.

26

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 27-44, maio/2013.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 tech-niques. 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 integra-ted 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 proje-tos, integração com ambientes de fabricação digital, interação com usuários para visualização de pro-jetos e alta portabilidade entre diversas plataformas de acesso como Web, computadores e notebooks, tablets e celulares, facilitando a mobilidade no acesso aos projetos.

26

27


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 possi-bilidades 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 Ar-

quitetura;• 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

28


É 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 mo-delo 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.Fonte: www.totalcad.com.br

Mesmo que as maquetes consigam transpor a limitação da representação bidimensional das plan-tas, 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:

29


Figura 3: Representações arquitetônicas para decoração de interiores.

Fonte: www.totalcad.com.br

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 maque-tes) 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

30


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 Ma-nufacturing) 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 im-

pactos ?• como disponibilizar um ambiente de visualização aos usuários de tal forma que possibilida-

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

31


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 exem-plo, 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áfi co (Google Maps).Fonte: maps.google.com

32


Na linha específica de RV, maquetes arquitetônicas podem ser visualizadas em displays que per-mitem 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 po-dem 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

33


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, impres-soras 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

34


Uma vez que o modelo arquitetônico esteja impresso, sistemas de RA podem expandir a visua-lizaçã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

35


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 am-biente a ser vistoriado e reparado.

Neste sentido, para um ambiente devidamente sensorizado, um sistema de RV permite a um ar-quiteto vistoriar e decidir por reparos diretamente no modelo virtual, através de um tour virtual ilus-trado na Figura 14:

Figura 14: Tour virtual de um arquiteto para fi ns 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 neces-sita 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 sta-tus 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:

36


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.

37


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, Ma-ckenzie, 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 exem-plo, 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 desenvol-ver 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.

38


Moradores podem, por exemplo, visitar virtualmente a habitação antes dela ser construída. Arqui-tetos 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 arquitetura2. 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 TICHIS4. Definição de contextos de navegação dentro do sistema colaborativo5. Implementação do projeto de interface e contexto de navegação6. 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:

39


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 auto-má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.

40


Além disto, foi implementada a integração entre o Kinect e o Quest3D para navegação básica den-tro 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 identifi cados.

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 pro-gramaçã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).

41


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

42


O sistema já foi testado com exibição de informações fictícias (não-reais) apenas para fins de veri-ficaçã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 procu-rados 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.

43

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 43-59, maio/2013.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. RodelloMarize Minakawa

Thais F. da PazJosé 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 Orga-nizations 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 proto-tipagem 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 exce-lê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

44



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 finalida-des, 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 Orga-nizaçã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 de-senvolvimento 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 tam-bém “evoluiu”. Historicamente atribui-se o termo “Realidade Virtual” a Jaron Lanier, cientista da com-putaçã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-

45



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.

Ambiente Real

Virtualidade Aumentada

Ambiente Virtual

Realidade Misturada

Realidade Aumentada

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.

46



Insumos (Recursos)

Humanos Financeiros

Físicos Informação

Organização

Processo de Transformação

Resultados

Bens Serviços

AMBIENTE EXTERNO

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 treinamen-tos. 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 ge-rencial. 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, consequente-mente, 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 co-municação e sistemas de coordenação dos membros (procedimentos); essa co-letividade existe em uma base relativamente contínua, está inserida em um ambiente e toma parte de atividades que normalmente se encontram relacio-nadas 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).

47



Nessa definição destaca-se a palavra coletividade, que apresenta uma Organização como um con-junto 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 or-ganizaçã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 produ-to, sem a necessidade de envio de amostras. Isso acontece quando, por exemplo, o usuário pode intera-gir 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 emocional-mente com o produto (por meio de imersão sensorial.) produz um importante diferencial. Dessa for-ma, é 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 imple-mentaçã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 men-sagens, 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

48



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 desvan-tagens é possível observar que:

Não é apropriado para determinados produtos. RV funciona melhor com os produtos que reque-rem 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 Ma-rketing 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 com-pras 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 experi-mentar 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 es-pecial, 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.

49



(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, re-quer 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 é gera-da 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/). É disponibili-zado 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 apli-cativo. 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 ba-seado 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-

50



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 VirtualFonte: Oliveira (2012)

Sem dúvidas, o mais explorado potencial da RA está na demonstração de produtos. Seja na apro-ximaçã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 mar-cador 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

51



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 dimen-sionar e escolher a caixa apropriada para sua encomenda (Figura 6).

Figura 6. Screenshot Virtual Box SimulatorFonte: 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 princi-pal 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 tridi-mensional 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 pro-dutos 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.

52



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ús-trias 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 mo-delos 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).

53



Figura 8. Centro de Realidade Virtual VolkswagenFonte: Divulgação Absolut Technologies

Em 2008 o grupo Volkswagen investiu cerca de 4,2 milhões de reais em um centro de RVA, atual-mente situado na montadora de São Bernardo do Campo. Projetado e implantado pela Absolut Tech-nologies (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 pro-cesso 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 tes-tes tem a finalidade de analisar o tempo de reação dos condutores em geral, para que consigam desen-volver 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.

54



Figura 9. Virttex FordFonte: 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 (Go-dirro, 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 mo-derna sala de Realidade Virtual, denominada Fiat Latin America Style Center, (Figura 10) que além

55



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 dife-rentes cenários possam ser criados.

Figura 10. Fiat Latin America CenterFonte: 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 concor-rê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.

56



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 inte-rior 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 - EmbraerFonte: 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.

57



8. Considerações Finais

Este Capítulo abordou o uso da RVA em ações de Marketing e também no projeto e desenvolvi-mento 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 au-xiliar 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 ma-rketing. 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 pes-soas 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 investi-mentos por parte das Organizações, com a necessidade de uma infraestrutura de RVA mais personali-zada 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.

58



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 Soft ware 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-de-Detroit/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-veiculos-lidera-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”. Monografi a 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áfi ca e Processamento de Imagens, SIBGRAPI’97: Minicurso.

RAY BAN (2011). “Th e Ray Ban Virtual Mirror”. Disponível em < http://www.ray-ban.com/usa/science/virtual-mirror>. Acesso em março 2011.

59



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). ”Th e 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 Soft ware.” Disponível em < http://www.zugara.com/augmented-reality/soft ware>. Acesso em março de 2011.

60

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 60-74, maio/2013.SANTOS JÚNIOR, Gesmar de Paula, et al. Realidade Aumentada Móvel

Realidade Aumentada Móvel

Gesmar de Paula Santos JúniorLuciene Chagas de Oliveira

Alexandre CardosoEdgard Lamounier Júnior

Marcos Wagner de Souza RibeiroThamer 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, justifi-cations, 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 algu-mas 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, por-que 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

61


Para atingir este objetivo, especificamente seguiu-se o roteiro: apresentam-se as principais re-ferências a Realidade Aumentada Móvel e uma análise avaliação das tecnologias existentes Realida-de 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 popu-laçã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 aprendiza-gem 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 mo-bilidade: estar disponível a qualquer hora e em qualquer lugar, acesso, de forma flexível, a diversos re-cursos 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 te-lefonia 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 contri-buindo 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. Disposi-tivos, 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 (CAR-DOSO et al, 2012).

62


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, in-teração, conteúdo.

Estes desafios são mostrados na Figura 2, que classifica cinco categorias: hardware, aplicação, rede, meio ambiente e utilizador.

63


Figura. 2. Desafi os 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. De-ve-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.

64


Para dispositivos móveis, o hardware nem sempre apresenta alta duração de bateria, grande capa-cidade de processamento e memória, o que pode causar baixo desempenho, limitando as funcionalida-des 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 infraes-trutura 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 dife-rentes 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 platafor-ma 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 acrescen-tando 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á.

65


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

tâ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 diver-sas á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 desen-volvimento 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-

66


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 apli-caçõ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

67


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 Ambien-tes 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

68


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 utili-zando 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 de-senho 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.

69


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 mar-cadores para aplicações da RA. Além disso, foi desenvolvida uma aplicação de estudo de caso utili-zando 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 oclu-são parcial dos marcadores, conforme mostra a Figura 8.

Figura. 8. Reconhecimento de Marcadores Naturais para RA Móvel

70


4. Tecnologias Existentes

Esta seção apresenta os trabalhos relacionados aos softwares de Realidade Aumentada em disposi-tivos 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 Rea-lidade Aumentada Móvel. Os critérios levados em consideração para análise estão relacionados à usa-bilidade 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 é conhe-cida como FLARToolKit, onde todos os princípios de funcionamento do ARToolKit foram preservados.

Outra biblioteca que usa marcadores de Realidade Aumentada é NyARTollkit, também desenvol-vido 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, repre-senta 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 multi-marcadores 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 pa-drão, permite grande vantagem no rastreamento e reconhecimento de imagens coloridas.

Alguns destes frameworks, foram inicialmente concebido para ambientes desktop, como o ARTo-olKit, mas já possuem implementações para plataformas móveis, mas há opções que auxiliam o desen-

71


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 dispo-sitivos.

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 suporteARToolKit Symbian OS OpenGL

AndAR Android JavaNyARToolkit Java OpenGL

NyARToolkitCS Windows DirectXElipseAR iOS, Android Java

FlarToolKit Flash ActioScriptVufória iOS, Android e Unity 3D OpenGL

PhoneGap Multiplataforma HTML5, Javascript e CSSOutras 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.

72


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.

73


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-fl ash/dfusion-sdk-adobe-fl ash>. 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:fl are%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”.

74


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 Ofi cial 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 Artifi ciais”. IX Workshop de Realidade Virtual e Aumentada, 2012.

UNIFEYE. Disponível em: <http://docs.metaio.com/bin/view/Main/ UnifeyeDesignSysCompTracking#PlanarMarkerlessTracking>. Acesso em: agosto de 2011.

WOODILL G., “Th e 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.

75

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 75-88, maio/2013.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 KawamotoFlá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 apren-dizado 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 funciona-lidades 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 ges-ture 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 interfa-ces entre humanos e computadores as quais utilizam dispositivos não convencionais e que são baseadas

75

76



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 ges-tuais 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, trei-namento, 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é di-retrizes 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 po-dem 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).

F igura 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 en-viadas 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

77



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 proje-tadas, 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 prati-cado 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, gesti-cular 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 conside-rados 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].

78



3. Diretrizes para a Construção de Interações Naturais

Em [Blake, 2013], quatro diretrizes são apresentadas para se projetar interações naturais, inde-pendente 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ên-cias 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 é aprendi-da, 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 habi-lidades 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 minimi-zar 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 inter-face 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 po-dem 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 in-terações com o mundo real apresentam essa característica, a adoção de interações diretas resulta em interfaces mais f luidas 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.

79



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

Fi gura 1.2: Sensor Kinect e seus ComponentesAdaptado 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 reso-luçã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 amostra-gem 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].

80



OpenKinect é um projeto de código livre responsável pelo libfreenect. O libfreenect permite aces-so 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 di-versos fabricantes. OpenNI é usada em diversos projetos, como OpenCV, Unity3D, TUIO, PCL, open-Frameworks, 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 reconhe-cimento 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.

Fig ura 1. 3: Arquitetura do MS Kinect SDKFonte: http://msdn.microsoft .com/en-us/library/hh855348.aspx/

Na camada 1, encontram-se os componentes de hardware instalados no dispositivo Kinect; a ca-mada 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 ca-

81



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

fundidade 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. Fo-ram 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.

82



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, cria-dos nas etapas de preparação offline, são difíceis de detectar mudanças e adaptarem-se a elas. O traba-lho 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 ima-gens 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 dis-parar, 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.

83



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 vascu-lares 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 movimen-tos, 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 ima-gens 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.

84



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 fo-tográ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

85



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 quali-dade 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.

86



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 pos-turas, 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 apli-cação da Realidade Virtual e Aumentada e criam sistemas que dispensam o uso de marcadores e forne-cem 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 exis-tentes incluem sistemas para monitoramento de pessoas, vigilância, reabilitação, entretenimento, sis-temas 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.

87



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.

88



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.

89

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 89-103, maio/2013.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 DiasGustavo Jordan Castro Brasil

Bruno Barberi GneccoMário Popolin Neto

Isabele Andreoli AgostinhoRichard Valdívia

José Remo Ferreira BregaLuis 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 PrimeSen-se 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 desenvolvi-mento 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

90



1. Introdução

Muitos estudos tem sido realizados na área de Interface Natural de Usuário em função da exis-tê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 desenvol-vidas 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 de-senvolvedores 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, fa-cilitando 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 dis-positivos PrimeSense. Uma breve descrição de cada biblioteca é apresentada, contudo, são apresenta-das apenas aplicações desenvolvidas com a OpenNI, por ser uma das mais utilizadas no meio acadêmi-co, 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.

91



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 com-partilhamento 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 pi-xels 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.

92



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 ne-cessá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 fabrican-tes 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 refe-rentes a microfone e speakers.

93



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 pro-fundidade, 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 mi-crofones, 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 desen-volvedor 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 desenvolvi-das 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.

94



4. Ferramentas de Desenvolvimento

As soluções de desenvolvimento para dispositivos PrimeSense possuem características que ten-dem 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 dispositi-vo Kinect em computadores pessoais ou outros dispositivos. O foco da comunidade é o desenvolvimen-to 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 Win-dows, 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 de-senvolvidas, 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 Sour-ce 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 au-mentada. 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 fabri-cantes 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 desenvolvi-mento de aplicações que fazem uso de interação natural. Esta API abrange a comunicação com dispo-sitivos 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-

95



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, Win-dows 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, estabelecendo se 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 disposi-tivos PrimeSense. Os exemplos foram desenvolvidos utilizando três linguagens: C/C++, Java e Pro-cessing. 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

96



mãos do usuário. O Skeleton Tracker foi desenvolvido em Java, sendo utilizado na interação de um ava-tar dentro de um ambiente virtual. O Processing é apresentado como uma terceira solução de desenvol-vimento, 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 ge-rados pelas mãos do usuário para manipular aplicações computacionais. Nesta seção, uma versão ex-tendida 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, res-ponsá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.

97



// 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 inicia-lizá-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á re-lacionado 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 contextXnStatus rc = context.InitFromXmlFile(SAMPLE_XML_FILE);// Create the Session ManagerpSessionGenerator = 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 am-biente virtual proposto (loader do Mini CAVE). São comandos de teclado e mouse. Os comandos re-lacionados 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);

98



// 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 dispo-sitivo 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; write(uinp_fd, &event, sizeof(event)); event.type = EV_SYN; event.code = SYN_REPORT; event.value = 0; write(uinp_fd, &event, sizeof(event)); }// Callbackvoid 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 im-plementou 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 ins-tâ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.

99



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); } }

100



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

101



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

102



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 estu-dos 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 necessi-tem 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 di-versos 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 vir-tual 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.

103



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.

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

104

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 104-120, maio/2013.GNECCO, Bruno Barberi, et al. E stratégias mistas de mecanismos para imersão

em modelos de interação em ambientes virtuais de treinamento.

E stratégias mistas de mecanismos para imersão em modelos de interação em ambientes virtuais de

treinamento

Bruno Barberi GneccoRodrigo de Godoy DominguesGustavo Jordan Castro BrasilDiego 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 in-terface 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 usa-dos 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 equi-pamento 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

105



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 realis-mo 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 mode-lagem 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 com-portamento 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 mecanis-mos 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 si-muladores de vôos, onde o custo de um equipamento e/ou o risco humano são altos. A segurança pro-porcionada 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 vir-tual 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 dispo-sitivo 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ífi-cos 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

106



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 de-senvolvidos 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, po-liticas públicas, e os objetivos de comunicação estratégica. Assim, os serious games utilizam as abor-dagens 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 envol-vam riscos, tomada de decisões ou desenvolver habilidades específicas. Serious games tem sido apli-cado 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.

107



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]

108



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 re-almente 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 ga-mes, 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 realis-mo 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

109



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 fotografi as sobre modelos virtuais aramados [Roussou, 2004]

Figura 5 - Fotografi a Real (esquerda) Computação Gráfi ca 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 ante-riormente, sendo assim a modelagem de todos os atributos físicos reais para reprodução destes estímu-los devem ser considerados.

110



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, pro-duçã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 desenvol-vimento 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 com-patí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.

111



RAGE, ou Rockstar Advanced Game Engine, foi uma colaboração conjunta entre RAGE Tech-nology 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 inte-grados ao RAGE.

O Anvil Engine é um game engine multiplataforma desenvolvido pela Ubisoft em 2007. A mo-delagem 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 úl-tima 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 Uni-ty3D. 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 im-portantes 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,

112



com o intuito de aumentar o seu engajamento no ambiente. Diferentes aplicações requerem tecnolo-gias 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 in-teraçã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.

113



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 pro-fundidade, 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 [Prime-Sense, 2013] implementa em seus chips a tecnologia de captura de profundidade, cor, e áudio. A captu-ra de profundidade é baseada na reconstrução 3D por luz estruturada: consiste em uma fonte de luz in-fravermelha (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 PrimeSen-se 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.

114



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 con-troller 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 repro-duçã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 vir-tual 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.

115



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 feed-back 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 re-almente 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.

116



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 am-biente. 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 atu-ais 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 é car-regado 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 demonstra-ram 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 An-throTronix 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.

117



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 equi-pamentos 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 as-sistir 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 equipa-mento 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 lon-go 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.

118



Foram apresentadas diferentes tecnologias, desde dispositivos que fazem o uso de Interface Natu-ral 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 se-rious 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.

119



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.

120



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

121

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 121-137, maio/2013.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êaSilvio Ricardo Rodrigues SanchesDaniel 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 Aug-mented 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 pro-cess 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, re-centemente, 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 cor-poral de um ser sobre-humano [Sheth 2002]. No contexto dos ambientes virtuais, o termo foi empre-gado 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 am-biente [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

122


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 Ha-bitat, 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ísti-cas humanas difíceis de serem reproduzidas com fidelidade [Ogi et al. 2001]. A exatidão de movimen-tos, 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 tem-po real [Nakamura 2008].

A utilização de imagens de vídeo, ainda que sejam bidimensionais, pode proporcionar maior rea-lismo 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 computacio-nais, 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, respecti-vamente; 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, infor-maçõ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

123


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 pro-fundidade.

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 pro-cessamento 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, carac-terizadas 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 infraes-truturas podem ser compostas por múltiplas câmeras ou equipamentos especiais. Exemplos de infra-estruturas 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 consi-derada 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 profundida-de. 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 con-siste 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.

124


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 convencio-nal, 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 [Le-meszenski 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 ele-mento 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 inte-resse 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.

125


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á re-lacionado à 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 obti-dos 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 virtu-al 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 Naraya nan 2007, Lee et al. 2005]. Essa técnica baseia-se na reconstrução por shapes from silhoutte, inicialmente proposta por Laurentini (1994), permi-tindo 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.

126


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 po-lí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 pla-no 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 rende-rizaçã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 super-fí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

127


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 equi-pamentos, 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;

128


• 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 segmen-taçã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 apresen-tados o sensor TOF DP-01 e a câmera de captura série DX-20, fornecidos pela empresa 4D View Solu-tions. 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.

129


A DVE oferece sistemas de conferência imersiva para salas de reuniões e palestras. Oferece diver-sos sistemas ou produtos [DVE 2013], como:

• Huddle Room 70, que permite apresentar um grupo de participantes em tamanho real, geral-mente 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 contri-buiçõ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 ima-gens 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 comple-xidade de configuração.

4.2 AVTC

No sistema de teleconferência imersiva AVTC (Augmented Virtuality Tele-Conferencing) o apre-sentador é 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.

130


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 re-alizaçã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 é apre-sentado o sistema Coliseum.

Figura 1.7. Utilização do sistema Coliseum.

131


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 es-tú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 fidu-cial 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 profun-didade 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.

132


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 esporti-va. 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 Re-alidade 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 ta-belas 1.1 e 1.2 é possível observar as comparações de aplicações acadêmicas e comerciais, respectiva-mente, 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 Técnica Infraestrutura Tempo real Calibração Modelo

AVMix Depth maps from stereo vision 2 câmeras Sim Manual 2,5D

AVTC Switching planes 2 câmeras Sim Manual 2DBlue-C Visual hull 15 câmeras Sim Manual 3D

Coliseum Visual hull 5 câmeras Sim Manual 2,5D

3D Video Avatar Visual hull Câmeras RGB e infravermelho Sim Manual 3D

Kinect 3D Video Capture Luz estruturada 1 ou mais Kinects Sim Manual 2,5D

Tabela 1.2. Comparação de aplicações comerciais.

Aplicação Técnica Infraestrutura Tempo real Calibração Modelo

4DV Capture Visual hull Até 80 câmeras e sensor TOF Não Manual ou plug-in

de calibração 3D

4D Ineractive Visual hull Até 80 câmeras e sensor TOF ras Sim Manual ou plug-in

de calibração 3D

Série DVE - 1 câmera Sim - 2D

De acordo com a tabela 1.1, observa-se que a calibração é uma das principais dificuldades, en-tretanto, a execução ocorre em tempo real, um parâmetro considerado relevante em ambientes de Realidade Aumentada.

133


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 pro-fundidade 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 em-barcado.

A série DVE envolve os sistemas Huddle Room 70, Telepresence Stage e Immersive Podium, descri-tos 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 em-pregadas 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.

134


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.; KOLLERMEIER, 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.

135


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.

136


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.

137


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.

138

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 138-156, maio/2013.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 MartinsAna Grasielle Dionísio CorrêaMarcelo de Paiva Guimarães

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 ap-plications 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 Au-mentada 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 consi-deraçã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 considera-

138

139



çã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, principalmen-te 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 encon-trados, 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, ques-tioná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 reinterpre-taçõ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 apli-caçõ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 especifi-camente 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 con-texto 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 completu-de 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).

140



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

gosas;• 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 im-

portante 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 pa-

drão de projeto de interfaces; e• Adaptação ao nível de experiência dos usuários: o quanto o sistema é adaptativo às necessi-

dades 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 usa-bilidade, é 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, questio-nários e roteiros de testes) são adequados;

141



2. Introdução: a situação de teste é apresentada para os usuários;3. Teste: o avaliador auxilia o teste de cada usuário, que é feito de forma isolada; 4. 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 pos-terior análise. Contudo, a análise completa de vídeo pode se tornar dispendiosa economica-mente, 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.

142



2.2. Inspeção de Usabilidade

O método de Inspeção de Usabilidade é realizado por especialistas e consiste em examinar, se-gundo 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 é necessaria-mente 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 exa-minando 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 di-versas 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 conso-lidados 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 ge-rais 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 as-pectos 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 aplica-das antes da avaliação com o usuário final, a fim de que problemas identificados possam ser soluciona-dos antes da liberação do produto ao público em geral.

143



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 usabi-lidade 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 vir-tuais 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 li-gado à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 ocor-rência de eventos indesejados. Se isso ocorrer, é fundamental a disponibilização de mensa-gens 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 funcionali-dades, já que o usuário interage com um ambiente real mesclado com objetos virtuais. Fun-cionalidades 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

144



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 precisa-mente 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 docu-mentaçã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 contem-plam 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 ima-gem, 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, mes-mo 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.

145



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

linguagem foi entendida facilmente. Prevenção de erros

Em nenhum momento eu me senti perdido na aplicação, sem saber o que fazer.

Controle do usuário e liberdade

Ao mostrar o marcador, o objeto 3D é carregado rapidamente. Visibilidade do status do sistema

O objeto da cena segue de forma correta à posição do marcador. Flexibilidade e Efi ciê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

funcionalidades Consistência e padrões

A quantidade de objetos virtuais adicionados na cena é coerente com o propósito da aplicação.

Estética e design minimalista

O objeto virtual sempre estava posicionado adequadamente conforme a posição do marcador Precisão

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 che-cklists, 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.

146



Tabela 2. Checklist: Verifi cação da variável SatisfaçãoItem Heurística

É satisfatória a quantidade de objetos virtuais na cena? Estética e design minimalista

A quantidade de mecanismos de interação é satisfatória?(marcador, teclado, mouse, joystick)

Estética e design minimalista

É satisfatório o manual da aplicação? (vídeo, textos, áudio) Ajuda e documentação

É satisfatório o mecanismo de interação da aplicação? (por exemplo, com o tipo de marcador) Satisfação

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

Tabela 3. Checklist: Verifi cação da variável Efi cáciaItem Heurística

O usuário sabe o status da aplicação durante toda a interação? Visibilidade do status do sistema

Se existe mais de um marcador em cena, é possível especifi car um? Controle do usuário e liberdade

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

Controle do usuário e liberdade

O objetivo da aplicação é alcançado? Satisfação

147



Tabela 4. Checklist: Verifi cação da variável Efi ciênciaItem Heurística

É satisfatório o tempo de carregamento de objetos virtuais na cena? Visibilidade do status do sistema

Os objetos virtuais são misturados com o mundo real corretamente? (por exemplo: posição, textura, escala)

Compatibilidade com o mundo real

A animação dos objetos virtuais é coerente com o mundo real? Compatibilidade com o mundo real

As ações e feedback são padronizados? (por exemplo, uma borda é adicionada em todos os marcadores detectados) Consistência e padrões

Existe prevenção de erros? (por exemplo, é apresentada para o usuário alguma mensagem quando um marcador não cadastrado é detectado) Prevenção de erros

As funcionalidades da aplicação são lembradas facilmente? (por exemplo, é fácil lembrar a função de cada marcador)

Reconhecimento ao invés de lembrança

Como é a curva de aprendizagem dos usuários iniciantes? Flexibilidade e efi ciência de uso

Usuários experientes podem utilizar a aplicação de maneira otimizada? (por exemplo, eles não assistem os vídeos introdutórios)

Flexibilidade e efi ciência de uso

É fácil posicionar o marcador para a câmera/sensor? (orientação/posição) Flexibilidade e efi ciência de uso

A aplicação auxilia o usuário durante a interação? (por exemplo, instruir a mostrar um marcador)

Ajuda os usuários a reconhecer,

diagnosticar e corrigir erros

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)

Confi guração do ambiente

O sistema de tracker é estável? PrecisãoA aplicação continua funcionando de forma correta quanto vários

marcadores estão visíveis na cena? Precisão

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 visu-alizar o veículo por diversos ângulos. Clicando sobre o carro o usuário liga as luzes do carro e pode agendar um test drive.

148



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 co-nhecimento, embora todas estas pessoas sejam de uma universidade (secretárias, professores da área

149



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 questio-ná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 acor-do com a escala Likert de cinco pontos – Likert (1932), a fim de medir o nível de concordância à afir-maçã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 Média Entendi facilmente como utilizar a aplicação e o seu o objetivo. 4,7

As mensagens apresentadas (texto ou vídeo) foram entendidas facilmente. 4,15 Em nenhum momento eu me senti perdido na aplicação, sem saber o que fazer. 3,95

Ao mostrar o marcador, o objeto 3D é carregado rapidamente. 3,65 O objeto da cena segue de forma correta a posição do marcador. 2

Os marcadores são detectados corretamente. 4,2 Foi uma experiência bastante agradável utilizar a aplicação. 4,5

Eu utilizaria novamente a aplicação, se fosse possível. 4,5 Eu sempre executava as mesmas ações para acionar as mesmas funcionalidades 3,9

A quantidade de objetos virtuais adicionados na cena é coerente com o propósito da aplicação 4,7

O objeto virtual sempre estava posicionado adequadamente conforme a posição do marcador 4,1

O sistema disponibilizou um material de documentação de uso. 4

150



Tabela 6. Resultado da opinião dos usuários sobre a aplicação de acessórios

Questão Média Entendi facilmente como utilizar a aplicação e o seu o objetivo. 4,83

As mensagens apresentadas (texto ou vídeo) foram entendidas facilmente. 4,25 Em nenhum momento eu me senti perdido na aplicação, sem saber o que fazer. 3

Ao mostrar o marcador, o objeto 3D é carregado rapidamente. 3,67 O objeto da cena segue de forma correta a posição do marcador. 2

Os marcadores são detectados corretamente. 3,33 Foi uma experiência bastante agradável utilizar a aplicação. 4,17

Eu utilizaria novamente a aplicação, se fosse possível. 4,08 Eu sempre executava as mesmas ações para acionar as mesmas funcionalidades 2,75

A quantidade de objetos virtuais adicionados na cena é coerente com o propósito da aplicação 4,41

O objeto virtual sempre estava posicionado adequadamente conforme a posição do marcador 2

O sistema disponibilizou um material de documentação de uso. 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 princi-pais 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 especia-listas são da área de Inteface Homem-Computador, com média de 3 anos de experiência em desenvol-vimento 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):

151



Tabela 7. Verifi cação da variável Satisfação na aplicação automotiva

Checklist Grau de severidade Comentários dos especialistas

É satisfatória a quantidade de objetos virtuais na cena? 0,0,0 Nenhum problema

A quantidade de mecanismos de interação é satisfatória? (marcador, teclado, mouse,

joystick)4,4,4 A simplicidade da aplicação gera

desinteresse dos usuários

É satisfatório o manual da aplicação? (vídeo, textos, áudio) 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ícilA 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

Tabela 8. Verifi cação da variável Efi cácia na aplicação automotiva


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 especifi car 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.

O objetivo da aplicação é alcançado? 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.

152



Tabela 9. Verifi cação da variável Efi ciência na aplicação automotiva


É satisfatório o tempo de carregamento de objetos virtuais na cena? 0,0,1 Por volta de 5 segundos, o que é

considerado altoOs objetos virtuais são misturados com o mundo real corretamente? (por exemplo:

posição, textura, escala)0,0,0 Nenhum problema

A animação dos objetos virtuais é coerente com o mundo real? 0,0,0 Nenhum problema

As ações e feedback são padronizados? (por exemplo, uma borda é adicionada em todos

os marcadores detectados)0,0,0 Nenhum problema

Existe prevenção de erros? (por exemplo, é apresentada para o usuário alguma mensagem quando um marcador não

cadastrado é detectado)

0,0,0 Não aconteceu nenhum erro

As funcionalidades da aplicação são lembradas facilmente? (por exemplo, é fácil

lembrar a função de cada marcador)0,0,0 A interação é fácil. O usuário deve

apenas girar o volante

Como é a curva de aprendizagem dos usuários iniciantes? 1,2,1

A aplicação não é muito intuitiva, porém é apresentado um vido que

demonstra como interagir.Usuários experientes podem utilizar a aplicação de maneira otimizada? (por exemplo, eles não assistem os vídeos

introdutórios)

3,2,3A aplicação é simples, então

usuários novatos e experientes interagem da mesma maneira.

É fácil posicionar o marcador para a câmera/sensor? (orientação/posição) 2,1,2

O usuário precisa posicionar o marcador no campo de visão da

câmeraA aplicação auxilia o usuário durante a

interação? (por exemplo, instruir a mostrar um marcador)

0,1,0Estão disponíveis para o usuário um vídeo e um manual, que são

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

1,1,2 É necessário imprimir o marcador

O sistema de tracker é estável? 0,0,0 Nenhum comentárioA aplicação continua funcionando de forma

correta quanto vários marcadores estão visíveis na cena?

0,0,0 Nenhum comentário

153



A seguir são apresentados os resultados da inspeção de usabilidade para o segundo estudo de caso (Tabelas 10 a 12).

Tabela 10. Verifi cação da variável Satisfação na aplicação de venda de acessórios


É satisfatória a quantidade de objetos virtuais na cena? 0,0,0 Nenhum comentário

A quantidade de mecanismos de interação é satisfatória? (marcador, teclado, mouse,

joystick)0,0,0 Nenhum comentário

É satisfatório o manual da aplicação? (vídeo, textos, áudio) 0,0,0 Muito bom

É satisfatório o mecanismo de interação da aplicação? (por exemplo, com o tipo de

marcador)0,0,0 Nenhum comentário

A liberdade de movimentação durante a interação é satisfatória? (por exemplo,

não é necessário olhar para a câmera constantemente)

3,2,2 É desejável maior liberdade para se movimentar

Tabela 11. Verifi cação da variável Efi cácia na aplicação de venda de acessórios


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 especifi car 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.

O objetivo da aplicação é alcançado? 0,0,0 Sim, é possível experimentar os acessórios.

154



Tabela 12. Verifi cação da variável Satisfação na aplicação de venda de acessórios


É 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

As ações e feedback são padronizados? (por exemplo, uma borda é adicionada em todos

os marcadores detectados)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.

Existe prevenção de erros? (por exemplo, é apresentada para o usuário alguma mensagem quando um marcador não

cadastrado é detectado)

0,0,0 Não ocorreram erros

As funcionalidades da aplicação são lembradas facilmente? (por exemplo, é fácil

lembrar a função de cada marcador)0,0,0 A aplicação fornece instruções de

interação durante a execução

Como é a curva de aprendizagem dos usuários iniciantes? 0,0,0 Fácil de aprender

Usuários experientes podem utilizar a aplicação de maneira otimizada? (por exemplo,

eles não assistem os videos introdutórios)0,0,0 Fácil de usar

É fácil posicionar o marcador para a câmera/sensor? (orientação/posição) 2,1,3 O usuário deve fi car em ma posição

fi xa para calibrar o sistemaA aplicação auxilia o usuário durante a

interação? (por exemplo, instruir a mostrar um marcador)

1,2,1A aplicação disponibiliza um vídeo, um manual e a silhueta da facilitar

o posicionamento do usuário.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)

1,0,0É necessária uma câmera/webcam e o usuário em uma determinada

posição.

O sistema de tracker é estável? 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.

155



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 tes-tes 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 des-lizamento 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 me-didos 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.

156



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 offi ce 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.

157

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 157-184, maio/2013.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 ArrudaLucas 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 appli-cability 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 aplicabilida-de 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 natu-ral. Tais ferramentas passam a integrar a realidade do homem de uma forma profunda e inseparável.

157

158



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 com-putadores. 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 cons-truí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.

159



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 adi-cionais 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 perspec-tivas 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 tri-dimensional 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 simu-lado 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 com-putadores, são completamente obsoletos. Isso se deve ao fato de que os monitores tradicionais se apro-veitam 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 sen-sorial 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 cria-da por esse monitor seria boa o bastante para se sentar, e uma bala disparada por uma arma seria letal.

160



Desde então, várias pesquisas se intensificaram rumo à criação de sistemas de RV que possibi-litassem 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 am-biente, 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 inte-raçã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 reconheci-mento 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 dis-positivos 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, ob-ter 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 vanta-gens expressivas em relação à precisão e ao tempo de resposta. Por outro lado, eles restringem a liber-dade 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 reque-rem 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,

161



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 de-marcada 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 reconheci-mento 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 iner-ciais 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

162



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 pode-rosa de interação. Através do rastreamento do ponto de vista do usuário a técnica se propõe a transfor-mar 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 smartpho-nes, 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 me-tá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 cha-mado 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

163



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 conside-ram 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 indepen-dentemente, 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 ima-gens 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 respon-sá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].

164



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 este-reoscopia 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 am-biente, 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 pro-por 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

165



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 intera-tividade 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 consideravel-mente 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 hu-mana. 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. Pers-pectiva é 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 cen-tro 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 exem-

166



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 obser-vado, 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 separada-mente, 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 melho-ria 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 conheci-mento 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

167



métodos apesar de serem menos intrusivos e mais baratos tendem a necessitar de um processamen-to 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ífi-cos os quais não são popularizados o suficiente para serem usados em larga escala. No entanto, recente-mente, 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 dis-poní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 po-sicionado 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 necess idade de se utilizar óculos especiais, ou outros equipamentos como uma combinação de sensores inerciais, pode dificultar a interação prolongada,

168



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 te-nham 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 clas-sificador 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 de-monstrar 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 ras-trear. De maneira geral, o pipeline de processamento pode ser representado pelo diagrama apresentado na Figura 5.

169



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 im-plementação já existe na biblioteca OpenCV [Bradski e Kaehler 2008]. A partir deste rastreamento de fa ces é 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.

170



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.

171



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 ân-gulo 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 na Figura 8.p g

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:

172



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:

173



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 su-bespaç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.

174



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 pro-fundidade. 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 segun-da é quando ele se move sobre os eixos x e y. Essas duas contribuições são computadas e, em conjunto, corrigem o fr ustum.

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.

175



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 yDe 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 no vo frustum, movimentação nos eixos x e y.

Seguindo uma linha de raciocínio semelhante, demonstra-se que:

176



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 rastrea-mento (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 fa ce 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

177



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 co-laborativo 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 espe-ciais 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.

178



4.2. pCube

Em [Stavness et al. 2010] é descrito um dispositivo, chamad o pCube (ver Figura 15). Este dispo-sitivo 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 siste-ma 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.

179



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 con struí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 manu-seio 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 perspecti-va 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

180



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 ap licaçã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

181



o usuário mudar o ângulo como observa a tela do dispositivo, a imagem não irá mudar, pois o disposi-tivo 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 dis-positivo, enquanto a segunda, que se baseia no ponto de vista do usuário, gerando resultados quantita-tivos 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 Inter açã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 co-mum e um algoritmo de baixo custo de processamento para definir o ponto de vista do usuário.

182



Na sequência, a aplicabilidade da técnica é analisada. Visto que seu custo de implementação e im-plantação é baixo, uma vasta gama de aplicações pode se beneficiar deste tipo de visualização interati-va. 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, tra-balhos 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, cali-brada 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.

CRUZNEIRA, 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.

183



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.

184



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.

185

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 185-200, maio/2013.ELISEO, Maria Amelia; PACHECO, Beatriz de Almeida; DELMONDES, Darlan Silva Alves.

Desenvolvimento de websites com ambientes virtuais 3D interativos


Maria Amelia EliseoBeatriz 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 three-dimensional world.

Resumo

Este capítulo mostra os aspectos para o desenvolvimento de websites com ambientes virtuais 3D inte-rativos. 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 di-namicamente 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 intera-tivos e ambientes virtuais 3D, que podem ser experimentados através da Web, usando para seu desen-volvimento 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

186



máquinas e a largura de banda de transmissão de dados existente na Web, que não permitia a visuali-zação e manipulação de conteúdo 3D.

Tal, obstáculo vem sendo superado com a melhoria da performance das máquinas e da transmis-são de dados via Internet. Aliado a isso, nos últimos anos surgiram algumas tecnologias que permi-tiram 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 de-senvolver conteúdo tridimensional e interativo na rede. A capacidade de visualizar e manipular con-teú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 fo-ram desenvolvidas ao longo dos últimos 15 anos, mas poucas delas introduziram um modelo realmen-te 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 visua-lizaçã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 anterior-mente 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 tradi-cional, 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 impor-tante no aumento da utilidade, eficácia e utilidade de sites 3D. Por exemplo, um sistema adaptativo

187



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 su-porte 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 apresenta-da 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 cons-tró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 tecno-logias Web3D. Atualmente, com o aumento da largura de banda e do poder de processamento (espe-cialmente 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

188



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 é geral-mente 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 (eX-tensible Markup Language) representada por um modelo DOM (Document Object Model) . Este mo-delo 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 mu-danç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 visualiza-das, 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.

189



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 de-finido 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 dimen-sõ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 cor-responde 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 circun-ferências), desenhar linhas, inserir textos, imagens, aplicar texturas, gradientes e inclusive incorporar cenas 3D utilizando a API WebGL ou a linguagem X3D.

190



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 es-pacialmente 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ó “esca-da: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].

191



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 intercam-biá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, tam-bé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 [Brutz-man 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 f lexí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.

192



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). Par-sers 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 visuali-zaçã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 dife-rentes 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 mo-dificar, 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),

193



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 capa-cidades 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 perfi s (profi les) defi nidos 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

194



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 run-time. 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 realiza-das 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 JavaS-cript 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”.

195



<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, manten-do, 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.

196



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 tam-bé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 pre-cisa 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 Ja-vaScript. 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.

197



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 Figu-ra 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.

198



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 apren-dizado 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

199



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.

200



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.

201

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 201-226, maio/2013.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 funcio-namento 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 direta-mente equações que dependem de um conhecimento mais aprofundado dos parâmetros para sua cor-reta configuração. Esta exigência cria um ambiente interdisciplinar bastante interessante entre Com-putaçã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 diferen-

201

202


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 bi-bliográ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, velocida-des 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 Di-nâ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 co-nhecido movimento retilíneo). A Figura 1 ilustra exemplos destes movimentos no caso bidimensional:

203


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, mas-sa 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.

204


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, confor-me 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 5:g

Figura 5: Movimentos planos gerais de corpos rígidos.

205


• Movimento em Torno de um Ponto Fixo: movimento tridimensional em torno de um ponto fixo como, por exemplo, o movimento de um pião sobre o solo (Figura 5):p

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 va-riaçã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 defi nindo uma malha poligonal.

206


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 Or-diná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 abor-dagem 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, mo-vimentando 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 super-fí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 é vis-to 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 cor-po deformável.

207


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.

208


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. Fonte: graphics.stanford.edu

Neste exemplo, foi aplicado um movimento retilíneo uniformemente variado (MRUV) para espe-cificar a queda das esferas. O modelo de fratura para as esferas é um modelo dinâmico, com quantida-de 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.

209


Ainda na linha de Animação baseada em Física, é muito comum se encontrar animações de cor-pos 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.Fonte: graphics.stanford.edu

Neste exemplo, os vínculos estão presentes como restrições que interligam os diversos componen-tes da ponte (corpo deformável). Embora a ponte como um todo seja um corpo deformável, suas com-ponentes 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.

210


O disparo de projéteis e balas por armas, muito comum em jogos baseados em RV e RA, repre-senta 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.Fonte: graphics.stanford.edu

211


O movimento do projétil segue uma força Newtoniana. A deformação do anteparo até a sua pos-terior 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 mo-delos 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 exem-plos destes fluidos já renderizados:

Figura 15: Exemplos de fl uidos com simulação física renderizados.Fonte: graphics.stanford.edu

212


É 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 f luidos:

Figura 16: Exemplos de simulação de tecidos e interação com corpos rígidos e deformáveis.Fonte: graphics.stanford.edu

213


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âmi-cas 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 preci-sam interagir com o meio onde circulam. O meio pode ser algo simples como nos dois primeiros qua-dros 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.

214


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. Normal-mente, 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

215


Além dos vínculos naturais entre as diversas partes das embarcações, há um fator bastante com-plexo 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íti-mo 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 aero-naves 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.

216


Uma das principais dificuldades na implementação de aeronaves refere-se aos controles aerodi-nâ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 dife-renciais. 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 estabele-cer 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 unidimensio-nal, bastante comum na implementação de sistemas massa-mola:

Para se evitar a sobrecarga na notação, é comum se indicar as derivadas ,…, por , respecti-vamente. 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.

217


• 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, homo-gê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 acompanha-da 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 apresen-tados 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:

218


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, princi-palmente 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 elementa-res 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).

219


Para EDOs de ordem superior, uma maneira bastante simples de se resolver consiste em trans-formar 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:

220


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 melho-ra qualidade, porém são mais lentos de se calcular.

Utilizando um esquema de diferenças centrais nesta malha, as derivadas de primeira ordem po-dem ser aproximadas por:

De maneira semelhante, as derivadas de segunda ordem podem ser aproximadas pelos seguintes esquemas de diferenças:

221


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 Di-fference 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 detalhamen-

222


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, atual-mente, é de domínio da Intel, que o disponibilizou gratuitamente para estudo e ensino. Ele disponibi-liza 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 do engine é mostrado na Figura 20:g g g

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 produ-zidas 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, veloci-dade, 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.

223


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 impor-tantes 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.

224


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 deter-minado 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 apre-sentadas, 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:

225


Um exemplo de classe HavokCore é mostrada abaixo:

226


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_mo-tionType) 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 conheci-mentos 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.

227

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 227-249, maio/2013.SILVA, Luciano. Desenvolvimento de Aplicações de RV e RA para Smart TVs.

Desenvolvimento de Aplicações de RV e RA para Smart TVsLuciano 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, reconheci-mento 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 prin-cí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, configu-rou-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 am-biente 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 pes-quisas 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

228


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 reco-nhecimento 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 fron-tal é 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 Sam-sung Smart TV é possibilidade de upgrade no processador através do Evolution Kit, mostrado na Figura 2:

229


Figura 2: Evolution kit.Fonte: www.samsung.com

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.Fonte: www.samsung.com

230


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 adaptado-res wi-fi, conforme mostra a Figura 4:

Figura 4: Redes de dispositivos Anynet+.Fonte: www.samsung.com

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:

231


Figura 5: Reconhecimento facial na Samsung Smart TV.Fonte: www.samsung.com

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.Fonte: www.samsung.com

232


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 im-portante 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 amplifi cação.

Fonte: www.samsung.com

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 (bro-wser) chamado Smart HUB, que pode ser visto quando o televisor carrega o ambiente operacional, conforme mostra a Figura 8:

Figura 8: Smart HUB.Fonte: www.samsung.com

233


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.Fonte: www.samsung.com

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 convencio-nal, conforme mostrado na Figura 10:g

Figura 10: Comparação entre execução de aplicações e visualização de páginas.Fonte: www.samsung.com

234


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.Fonte: www.samsung.com

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.Fonte: www.samsung.com

Existem, basicamente, três formas de visualização para aplicações na Samsung Smart TV, mos-tradas na Figura 13:

235


full-screen single-sidedg

tickerFigura 13: Formas de visualização de uma aplicação para Samsung Smart TV.

Fonte: www.samsung.com

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 é for-mado, além do framework de classes em Java, de um IDE conforme mostra a Figura 14:

236


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.Fonte: developer.samsung.com

237


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.Fonte: developer.samsung.com

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:

238


No arquivo de configuração config.xml, define-se, por exemplo, se ela ocupará toda a tela (fullwid-get ou ticker). No arquivo de configuração anterior, ambos os marcadores estão desabilitados (n), indi-cado 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:

239


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.Fonte: developer.samsung.com

240


Finalmente, todos estes arquivos são agrupados dentro do arquivo index.html, conforme mostra-do 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 con-correr 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:

241


Inclusive, a forma de utilização é muito semelhante ao AJAX: instancia-se um objeto XMLHtt-pRequest e indica-se a aplicação que se quer invocar.

Outro detalhe bastante importante e que permite transições suaves entre o carregamento das apli-caçõ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.Fonte: developer.samsung.com

Abaixo, tem-se um exemplo de um esqueleto de código para realizar as transições via JavaScript:p q g p

242


5. Reconhecimento de Gestos

O primeiro passo para realizar o reconhecimento de gestos é verificar se este recurso está habili-tado 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:

243


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 é mostrado na Figura 19: p g

Figura 19: Gesture Helpbar funcionando em conjunto com o emulador do Samsung Smart TV SDK.Fonte: developer.samsung.com

A leitura dos estados do Gesture Helpbar para saber qual o gesto foi escolhido, é mostrado abaixo:

244


6. Reconhecimento de Voz

Assim como ocorreu no reconhecimento de gestos, o primeiro passo para realizar o reconheci-mento 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:

245


Como exemplo do método handleMainCommand, o código abaixo reconhece os comandos up, down, left, right, open e exit:

246


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.Fonte: developer.samsung.com

Assim como ocorria no Gesture Helpbar, o acesso ao Voice Helpbar também é feito através de registro e tratamento de eventos:

247


É possível, também, a configuração de quais opções estarão disponíveis no Voice Helpbar:

248


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:

249


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 su-porte 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, en-gines, 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 de-senvolvimento, 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.

250

Tendências e Técnicas em Realidade Virtual e Aumentada, v. 3, p. 250-278, maio/2013.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 accele-rates the coding time through the reuse of components. The openFrameworks is an example of tool orien-ted 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 com-ponentes 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

251



do funcionamento do openFrameworks (oF), mostrando o que é possível e o papel importante da co-munidade de desenvolvimento.

O exemplo ilustrado, passo a passo, mostra como gerar um novo exemplo, partindo para a utili-zaçã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 am-bientes de realidade aumentada [3], como mostrado na Figura 1.

F igura 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 intro-dutó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 infor-maçã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

252



entrar com dados, e como espera que o sistema responda. Interação não se trata de uma atividade uni-direcional 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 caracte-rí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 al-guns ferramentais (frameworks) mais conhecidos como Processing, Flash, Unity, cinder e o openFra-meworks.

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 Ac-tionScript. É muito utilizado por ter uma estrutura familiar com ferramentas de design como

253



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 criati-vidade 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.openfra-meworks.cc/

2. oF – openFrameworks

oF é uma coleção de códigos criados para ajudar em uma determina atividade, ou framework. Al-guns 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 pode-rosa, 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.

254



• 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 desen-volvimento, no momento de escrita deste capítulo eram suportados cinco sistemas operacionais (Win-dows, 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 ambien-te de desenvolvimento com o tutorial (Seta 2 na Figura 2).

Fi gura 2. Download do openFrameworks.

255



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:

Fig ura 3. Exemplo de caminho para desenvolvimento.

Para testar um exemplo e validar o ambiente de desenvolvimento vá à pasta de exemplo, pas-ta de 3D, exemplo pointPickerExample e faça duplo click no arquivo pointPickerExample.sln. Como ilustrado na Figura 4.

Figu ra 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 ‘pointPickerE-xample’ 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.

256



Figur a 5. Procedimento para compilar.

Figura 6. Resultado esperado da compilação.

257



Figura 7. Exemplo do funcionamento.

2.1.1. Componentes da Comunidade

Uma das vantagens do oF é o fato da comunidade poder desenvolver componentes ou funcionali-dades 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 inter-

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

258



• 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 co-nhecida. 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 explo-rar 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.

259



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áti-

cas: 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 monta-

gem/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 distri-

buição do oF;• Arquivos changes.txt e license.md: contém uma listagem das principais alterações e da li-

cenç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,

260



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.

261



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. E strutura do projeto no VC2010E.

O arquivo main.cpp é o ponto inicial, contendo o int main(). Neste arquivo não é necessário ne-nhuma 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 compa-tível com o esperado pela ofRunApp. A Figura 13 mostra o código do arquivo main.cpp.

262



#include “ofMain.h”#include “testApp.h”#include “ofAppGlutWindow.h”

//========================================================================int main( ){

ofAppGlutWindow window; ofSetupOpenGL(&window, 1024,768, OF_WINDOW); // <-------- setup the GL context

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

#include “ofMain.h”

class testApp : public ofBaseApp{

public:void setup();void update();void draw();

void keyPressed (int key);void keyReleased(int key);void mouseMoved(int x, int y );void mouseDragged(int x, int y, int button);void mousePressed(int x, int y, int button);void mouseReleased(int x, int y, int button);void windowResized(int w, int h);void dragEvent(ofDragInfo dragInfo);void gotMessage(ofMessage msg);};

Figura 14. testApp.h inicial para o caso1.

263



Os métodos são implementado no arquivo fonte testApp.cpp. O gerador automático cria os méto-dos 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 to-das 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.

264



• 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éto-dos 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 primei-ro é 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 ne-cessá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.

265



Criar as variáveis na classe testApp.h, como na Figura 17:

...string mensagem;int x_i,y_i;fl oat raio;...

Figura 17. testApp.h para o caso1 modifi cado.

Para este teste, basta preencher os métodos setup para inicializar a mensagem e o raio inicio, pre-encher 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 modifi cado.

266



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 es-colhe 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.

F igura 19. Modelo visualizado no assimpViewer.

267



O projeto do oF já está preparado para procurar os caminhos da biblioteca ofxAssimpModelLo-ader. 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”#include “ofMain.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 cha-mada do modelo, posicionando-o no centro da janela, como visto no código da Figura 21 e o Resultado na Figura 22.

//--------------------------------------------------------------void testApp::setup(){

ofBackground(50, 0); //Confi gura o fundo // Abre o arquivo if( !model.loadModel(“astroBoy_walk.dae”, false) ) ofSystemAlertDialog(“Erro em carregar arquivo”); // confi gurações do openGL glEnable(GL_DEPTH_TEST); glShadeModel(GL_SMOOTH); //some model / light stuff

}//--------------------------------------------------------------void testApp::draw(){ ofSetColor(255); // Confi gura a cor do objeto 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érticeofPopMatrix(); // fecha o contexto do openGL}

Figura 21. testApp.cpp com os métodos setup() e draw() preenchidos.

268



F igura 22. Resultado do caso2.

3.2.2. Manipulando o modelo

O oF disponibiliza um componente de manipulação de câmera, chamado ofEasyCam. Este com-ponente é 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#include “ofxAssimpModelLoader.h”#include “ofMain.h”

class testApp : public ofBaseApp{ ... ofxAssimpModelLoader model; ofEasyCam cam; };

Figura 23. testApp.h do caso2 com EasyCam.

269



//--------------------------------------------------------------void testApp::draw(){ofSetColor(255); // Confi gura 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 me-todologia, 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 detec-tion enquanto o do ARToolKit é chamado template marker detection.

Para este caso, será explorado o exemplo dado pelo ofxARToolKitPlus, porém com a criação ini-cial 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 in-cluir, 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

270



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, uti-lizamos 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” //Cabeçalho do OpenCV#include “ofxARToolkitPlus.h” //Cabeçalho do ARToolKitPlus


public:void setup();void update();void draw();

void keyPressed (int key);void keyReleased(int key);void mouseMoved(int x, int y );void mouseDragged(int x, int y, int button);void mousePressed(int x, int y, int button);void mouseReleased(int x, int y, int button);void windowResized(int w, int h);void dragEvent(ofDragInfo dragInfo);void gotMessage(ofMessage msg);

int width, height; // Tamanho da janela da câmera ofVideoGrabber vidGrabber; // Componente do oF que pega a câmera.

ofxARToolkitPlus artk; // Instância do ARToolKitPlusint threshold; // Threshold da relação preto/branco ofxCvColorImage colorImage; //imagem capturada pela câmeraofxCvGrayscaleImage grayImage; //imagem em tons de cinza (mais rápida)ofxCvGrayscaleImage grayThres; //imagem com threshold antes de ir pro artk };

Figura 25. testApp.h do caso3 com carregador de vídeo e ARToolKitPlus.

271



No caso 3 serão necessários o preenchimento de quatro métodos do arquivo fonte testApp.hO 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 pro-cessamento 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.

//--------------------------------------------------------------void testApp::setup(){ofSetWindowShape(1280,480); // Ajusta o tamanho da aplicaçãowidth = 640; height = 480; // largura e altura da imagem da câ-mera

vidGrabber.initGrabber(width, height); // reserva espaço para o buffer da câmeracolorImage.allocate(width, height); // reserva espaço para a imagem colo-rida grayImage.allocate(width, height); // reserva espaço para a imagem mono grayThres.allocate(width, height); // reserva espaco para a imagem ajus-tada artk.setup(width, height); // inicia o ARToolKitPlus com valores padrão

threshold = 85; // threshold para a imagem ajustadaartk.setThreshold(threshold); // informa ao ARToolKitPlus que o ajuste é externo}

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();

272



//--------------------------------------------------------------void testApp::update(){

vidGrabber.grabFrame(); // Pega frame da câmerabool bNewFrame = vidGrabber.isFrameNew(); // confi gura que é um frame novo 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 exem-plo 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 sobres-creve 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().

273



//--------------------------------------------------------------void testApp::draw(){ ofSetColor(ofColor::white);// inicia a cor dos objetos como brancacolorImage.draw(0, 0);// exibe a imagem capturada coloridagrayThres.draw(640, 0);// exibe a imagem adaptada artk.draw(640, 0);// Esta função exibe a posição e etiqueta o marcador // ARTK 3Dartk.applyProjectionMatrix(); // primeiro passo é aplicar a matriz de pro-jeção da camera int numDetected = artk.getNumDetectedMarkers(); //detectar os marcadoresofEnableAlphaBlending();//habilitar a transparência for(int i=0; i<numDetected; i++) { // passar por todos os marcadores en-contrados artk.applyModelMatrix(i); //aplicar a matriz de perspectiva do mar-cador //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 dese-jado. 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.

274



//--------------------------------------------------------------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 confi guração da câmera

}}

Figura 29. Método keyPressed() do testApp.h do caso3.

O resultado da compilação está na Figura 30.

F igura 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.

275



#pragma once


#include “ofxOpenCv.h”#include “ofxARToolkitPlus.h”#include “ofxAssimpModelLoader.h”


...

ofxCvGrayscaleImage grayThres; ofxAssimpModelLoader model;

};

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.

//--------------------------------------------------------------void testApp::setup(){ofSetWindowShape(640,480);// Ajusta o tamanho da aplicaçãowidth = 640; height = 480;// largura e altura da imagem da câmera

vidGrabber.initGrabber(width, height);// reserva espaço para o buffer da câmeracolorImage.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);//Confi gura o fundo

// Abre o arquivoif( !model.loadModel(“astroBoy_walk.dae”, false) ) ofSystemAlertDialog(“Erro em carregar arquivo”);}//--------------------------------------------------------------void testApp::draw(){

276



ContinuaofSetColor(ofColor::white);// inicia a cor dos objetos como brancacolorImage.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 3Dartk.applyProjectionMatrix();// primeiro passo é aplicar a matriz da câmeraint numDetected = artk.getNumDetectedMarkers(); //detectar os marcadores for(int i=0; i<numDetected; i++) { // passar por todos os marcadores encon-trados 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);// Confi gura 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.

277



O resultado da adição de conteúdo 3D está na Figura 33.

F igura 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 educacio-nal 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.

278



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

avaliação de usabilidade para aplicações de realidade aumentada

Documents