78
Laborat ´ orio VISGRAF Instituto de Matem ´ atica Pura e Aplicada Framework para Aplicacoes em Plataformas Moveis usando Panoramas com Camadas Carlos Eduardo Rocha, Diego Bretas, Hallison da Paz Paulo Rosa, Luiz Velho (orientadores) Technical Report TR-14-04 Relat ´ orio T ´ ecnico October - 2014 - Outubro The contents of this report are the sole responsibility of the authors. O conte ´ udo do presente relat ´ orio ´ e de ´ unica responsabilidade dos autores.

Laboratorio VISGRAF´ - IMPA · neste aspecto de imersão tratando situações de oclusão de elementos e explorando o efeito de paralaxe entre as camadas para simular pequenas alterações

Embed Size (px)

Citation preview

Laboratorio VISGRAFInstituto de Matematica Pura e Aplicada

Framework para Aplicacoes em Plataformas Moveis usando

Panoramas com Camadas

Carlos Eduardo Rocha, Diego Bretas, Hallison da PazPaulo Rosa, Luiz Velho (orientadores)

Technical Report TR-14-04 Relatorio Tecnico

October - 2014 - Outubro

The contents of this report are the sole responsibility of the authors.O conteudo do presente relatorio e de unica responsabilidade dos autores.

MINISTÉRIO DA DEFESAEXÉRCITO BRASILEIRO

DEPARTAMENTO DE CIÊNCIA E TECNOLOGIAINSTITUTO MILITAR DE ENGENHARIA

(Real Academia de Artilharia Fortificação e Desenho/1792)

SEÇÃO DE ENGENHARIA DE COMPUTAÇÃO

CARLOS EDUARDO PINHEIRO ROCHA

DIEGO BRETAS DE ALVARENGA CARVALHO

HALLISON OLIVEIRA DA PAZ

FRAMEWORK PARA APLICAÇÕES EM PLATAFORMASMÓVEIS USANDO PANORAMAS COM CAMADAS

RIO DE JANEIRO

2014

INSTITUTO MILITAR DE ENGENHARIA

CARLOS EDUARDO PINHEIRO ROCHA

DIEGO BRETAS DE ALVARENGA CARVALHO

HALLISON OLIVEIRA DA PAZ

FRAMEWORK PARA APLICAÇÕES EM PLATAFORMASMÓVEIS USANDO PANORAMAS COM CAMADAS

Relatório apresentado ao Curso de Engenharia deComputação do Instituto Militar de Engenharia,como requisito parcial para conclusão do curso.

Orientadores: Paulo Fernando Ferreira Rosa – Ph.D.Luiz Carlos Pacheco Rodrigues Velho – Ph.D.

Rio de Janeiro

2014

2

INSTITUTO MILITAR DE ENGENHARIA

CARLOS EDUARDO PINHEIRO ROCHADIEGO BRETAS DE ALVARENGA CARVALHO

HALLISON OLIVEIRA DA PAZ

FRAMEWORK PARA APLICAÇÕES EM PLATAFORMASMÓVEIS USANDO PANORAMAS COM CAMADAS

Relatório apresentado ao Curso de Engenharia de Computação do Instituto Militar deEngenharia, como parte integrante do Projeto Final de Curso.

Orientadores: Paulo Fernandes Ferreira RosaLuiz Carlos Pacheco Rodrigues Velho

Aprovado em 6 de outubro de 2014 pela seguinte Banca Examinadora:

Paulo Fernando Ferreira Rosa – Ph.D. , do IME – Presidente

Luiz Carlos Pacheco Rodrigues Velho – Ph.D. , do IMPA

Ricardo Choren Noya – D.Sc. , do IME

Carla Liberal Pagliari – Ph.D. , do IME

RIO DE JANEIRO

2014

3

Dedicamos este projeto à todos os nossos familiares, amigos ecolegas de turma que contribuíram e nos incentivaram durantea elaboração do mesmo.

4

AGRADECIMENTOS

Nossos sinceros agradecimentos a todos que de alguma forma puderam nos ajudar aolongo do ano na conclusão deste trabalho.

Ao professor Luiz Velho, pela disponibilidade, conhecimento, incentivo e prestreza nodesenvolver do trabalho e durante as reuniões sobre o andamento deste Projeto de Fimde Curso.

Ao professor Paulo Rosa por ter contribuído com suas ideias e sugestões e pela pron-tidão para nos auxiliar sempre que necessário.

5

SUMÁRIO

LISTA DE ILUSTRAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

LISTA DE SIGLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 TÓPICOS TUTORIAIS E O ESTADO DA ARTE . . . . . . . . . . . . . 192.1 REALIDADE AUMENTADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.1 PRINCIPAIS PROBLEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 IMAGENS PANORÂMICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 REALIDADE AUMENTADA INDIRETA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1 PANORAMAS COM CAMADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 VISUALIZAÇÃO IMERSIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 AMBIENTE DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . 263.1 TECNOLOGIA GRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 TECNOLOGIAS DE COMUNICAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 TECNOLOGIA DE MICROLOCALIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.1 BEACON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 MODELAGEM E VISUALIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1 GRAFO DE CENA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 MALHA POLIGONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 PANORAMA COM CAMADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.1 IMAGEM DE REPRESENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4 FERRAMENTAS MATEMÁTICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 SHADERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.6 CÂMERA VIRTUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6.1 ATUALIZAÇÃO DA CÂMERA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.7 PERSPECTIVA DINÂMICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.7.1 CORE IMAGE FRAMEWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.7.2 TRANSLATIONMANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.8 CICLO DE RENDERIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 COMPONENTES DE INTERAÇÃO E MICROLOCALIZAÇÃO 45

6

5.1 INTERAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.1 RAY PICKING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.2 CAMADA DE COLISÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.1.3 EXIBIÇÃO DE CONTEÚDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 MICROLOCALIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.1 CLBEACON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.2 CLBEACONREGION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.3 CLLOCATIONMANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.4 BEACONMANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 O FRAMEWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.1 ESTRUTURA DOS COMPONENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2 UTILIZAÇÃO E ESPECIALIZAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2.1 APLICAÇÃO DE TESTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3 DIFICULDADES ENCONTRADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.3.1 RUÍDOS NO SINAL PROVENIENTE DA DETECÇÃO DE FACES . . . . . 606.3.2 DESLIZAMENTO APARENTE DE OBJETOS . . . . . . . . . . . . . . . . . . . . . . . 616.4 AMBIENTE DE AUTORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.1 TRABALHOS FUTUROS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8 REFERÊNCIAS BIBLIOGRÁFICAS. . . . . . . . . . . . . . . . . . . . . . . . . 66

A TECNOLOGIAS DE TRANSMISSÃO DE DADOS. . . . . . . . . . . . 73A.1 BLUETOOTH LOW ENERGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.2 NEAR FIELD COMMUNICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74A.3 QR CODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B INSERÇÃO DE NOVOS ELEMENTOS: BILLBOARDS . . . . . . . 77

7

LISTA DE ILUSTRAÇÕES

FIG. 1.1 Chewbacca e C3PO em momento de lazer [1] . . . . . . . . . . . . . . . . . . . . . 13

FIG. 1.2 Visor do exterminador do futuro [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

FIG. 1.3 Interfaces apresentadas em Minority Report [3] . . . . . . . . . . . . . . . . . . . 14

FIG. 1.4 Aplicativo Paprika [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

FIG. 2.1 Ilustração do problema do registro [13] . . . . . . . . . . . . . . . . . . . . . . . . . . 20

FIG. 2.2 Exemplo de panorama equirretangular [18] . . . . . . . . . . . . . . . . . . . . . . . 21

FIG. 2.3 Arquitetura de panoramas com camadas [8] . . . . . . . . . . . . . . . . . . . . . . 23

FIG. 2.4 Posições relativas entre o observador e o aparelho [10] . . . . . . . . . . . . . . 25

FIG. 3.1 Interface aplicação-GPU [23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

FIG. 3.2 Beacon da marca Estimote em visão explodida [31] . . . . . . . . . . . . . . . . 28

FIG. 3.3 Desenho esquemático de um pacote de dados transmitido . . . . . . . . . . 29

FIG. 3.4 Desenho esquemático das três regiões (near, far e immediate) deatuação do Estimote Beacon [32] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

FIG. 4.1 Exemplo de Grafo de Cena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

FIG. 4.2 Malhas poligonais 3D com destaque para vértices, arestas e faces . . . . 33

FIG. 4.3 Malha esférica com faces quadrangulares [36] . . . . . . . . . . . . . . . . . . . . . . 34

FIG. 4.4 Imagem da camada mais externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

FIG. 4.5 Imagem da camada intermediária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

FIG. 4.6 Imagem da camada mais interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

FIG. 4.7 Pipeline simplificado de renderização da OpenGL [38] . . . . . . . . . . . . . . 36

FIG. 4.8 Transformações componentes da câmera . . . . . . . . . . . . . . . . . . . . . . . . . 38

FIG. 4.9 Pirâmide de Visualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8

FIG. 4.10 Orientação dos eixos coordenados no sistema iOS [39] . . . . . . . . . . . . . . 40

FIG. 4.11 Core Image identifica limites das faces em uma imagem [44] . . . . . . . . . 41

FIG. 4.12 Comparativo da precisão do algoritmo de detecção de face [43] . . . . . . 42

FIG. 4.13 Zoom a partir da aproximação da face ao dispositivo [10] . . . . . . . . . . . 43

FIG. 4.14 Efeito de paralaxe pelo posicionamento da face em relação aodispositivo [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

FIG. 4.15 Projeção da panorama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

FIG. 5.1 Vetores de Rotação da Câmera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

FIG. 5.2 Sistema de Coordenadas nativo da tela [51] . . . . . . . . . . . . . . . . . . . . . . . 46

FIG. 5.3 Ray Picking [52] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

FIG. 5.4 Camada de Interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

FIG. 5.5 Conteúdo exibido após interação com televisão . . . . . . . . . . . . . . . . . . . . 50

FIG. 5.6 Modelagem da máquina de estados finitos . . . . . . . . . . . . . . . . . . . . . . . . 53

FIG. 6.1 Relação entre os componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

FIG. 6.2 Planta baixa da cena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

FIG. 6.3 Marcação sobre quadro interativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

FIG. 6.4 Tela informativa sobre o quadro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

FIG. 6.5 Interação com a porta da cena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

FIG. 6.6 Deslizamento aparente dos objetos sobre o chão . . . . . . . . . . . . . . . . . . . 62

FIG. A.1 Estrutura de um QR Code [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

FIG. B.1 Árvores desenhadas com a técnica do billboarding [63] . . . . . . . . . . . . . 77

9

LISTA DE SIGLAS

AFH Adaptative Frequency-Hopping

API Application Programming Interface

BLE Bluetooth Low Energy

BSD Berkeley Software Distribution

CF Core Foundation

CL Core Location

CM Core Motion

CRC Cyclic Redundancy Check

GLSL Graphics Library Shader Language

GPS Global Positioning System

GPU Graphics Processing Unit

GSFK Gaussian Frequency-Shift Keying

LP Layered Panorama

NFC Near Field Communication

OpenGL Open Graphics Library

OpenGL ES Open Graphics Library Embedded System

P2P Peer to Peer

PDA Personal Digital Assistant

QR Codes Quick Response Codes

RA Realidade Aumentada

UUID Universally Unique Identifier

10

RESUMO

Este trabalho tem por finalidade descrever o desenvolvimento de um framework

voltado para aplicações em plataformas móveis utilizando uma representação de

imagens panorâmicas com camadas. Este framework deve apoiar o desenvolvimento

de aplicações baseadas em imagens interativas, que utilizem os recursos disponíveis

em dispositivos móveis atuais, tais como os sensores de atitude, câmeras, GPS e

o padrão de comunicação sem fio bluetooth. Para validação deste framework, será

desenvolvido um caso de teste objetivando prover uma experiência em realidade

aumentada ao usuário.

11

ABSTRACT

This work aims to describe the development of a framework for applications

on mobile platforms using a layered representation of panoramic images. This fra-

mework should support the development of interactive image based applications,

which use resources available in today’s mobile devices, such as attitude sensors,

cameras, GPS and standard Bluetooth wireless communication. To validate this

framework we will develop a test case aiming to provide to the user an augmented

reality experience.

12

1 INTRODUÇÃO

Desde muito tempo atrás, o homem traça projeções futuristas em que as tecnolo-gias da era digital participam intensamente de seu dia-a-dia. Muitas dessas projeçõesconseguiram atingir uma visibilidade internacional por meio das artes como a literaturae o cinema, e exerceram (e ainda exercem de certa maneira), impacto sobre pesquisascientíficas ambiciosas que almejam tornar realidade aquilo que outrora era ficção.

Neste cenário, uma parcela destas projeções apresentava a situação particular em quedados virtuais mesclavam-se com o mundo real de forma a complementá-lo ou expandí-lo. Pode-se citar exemplos de filmes consagrados como a série Guerra nas Estelas (StarWars), em que a personagem Chewbacca joga com o robô C3PO uma partida de umjogo de tabuleiro com peças virtuais (FIG. 1.1), ou O Exterminador do Futuro (TheTerminator), que possuía um visor onde informações relevantes sobre seus alvos eramsobrepostas à própria visão do ambiente, como ilustrado na FIG. 1.2.

FIG. 1.1: Chewbacca e C3PO em momento de lazer [1]

13

FIG. 1.2: Visor do exterminador do futuro [2]

Mais recentemente, em 2002, Steven Spielberg na direção de A Nova Lei (Mino-rity Report) retratou interfaces digitais que podiam ser manipuladas com gestos “no ar”(FIG. 1.3), ampliando sua contribuição no quadro da realidade aumentada. Em umaanálise bem simplificada, as principais barreiras tecnológicas para se alcançar essas proje-ções futuristas estão no desafio da visualização, isto é, em como exibir estas informaçõesvirtuais em nosso mundo real e no desafio da interação, que consiste em como se podemanipular estes dados e o que pode ser feito com eles.

FIG. 1.3: Interfaces apresentadas em Minority Report [3]

A popularização dos smartphones e o advento dos novos tablets foram fenômenos quecontribuíram fortemente para a integração de diversas tecnologias ao cotidiano das pes-

14

soas, na medida em que são dispositivos que podem e são carregados para praticamentequalquer ambiente social e congregam um conjunto de inúmeras ferramentas desde calcu-ladoras, agendas e navegadores de internet até câmeras fotográficas e aparelhos de GPS(Global Positioning System). Estes dispositivos móveis possuem um impacto muito im-portante na popularização do termo realidade aumentada não só pela facilidade de unificaruma grande variedade de recursos que já existiam, mas principalmente por propiciar o de-senvolvimento de novas formas de utilização da informação e de interação com o conteúdodigital.

Dentro deste contexto, surgem cada vez mais aplicações que se apoiam sobre os dispo-sitivos móveis para solucionar desafios da área. Por exemplo, aplicações como o Paprika[4] implementam soluções de visualização baseadas na captura da imagem da cena com acâmera de um dispositivo móvel e na exibição de uma nova imagem, processada e aumen-tada, na tela do aparelho. Para a interação, explora-se a capacidade sensível ao toque datela ou até mesmo os sensores de atitude do dispositivo. Na FIG. 1.4 pode-se ver umaimagem da tela do aplicativo em funcionamento.

FIG. 1.4: Aplicativo Paprika [4]

1.1 OBJETIVO

O objetivo deste trabalho é desenvolver um framework para visualização e interaçãocom imagens panorâmicas omnidirecionais previamente capturadas a fim de prover umaexperiência imersiva e dinâmica em dispositivos móveis. O framework será implementadopara a plataforma iOS [5], utilizada pelos dispositivos da companhia Apple [6].

Para tratar dos aspectos de visualização, utilizar-se-á os dados dos sensores de atitudedisponíveis (acelerômetro, giroscópio e magnetômetro) e também da câmera frontal dodispositivo. As câmeras omnidirecionais permitem capturar uma imagem em um campo devisão de 360 graus [7]. A proposta consiste em trabalhar sobre um modelo de representaçãode imagens panorâmicas equirretangulares segmentadas por camadas de acordo com a

15

profundidade relativa entre os elementos da cena representada. O processo de criaçãodesta representação não faz parte do escopo deste projeto.

Imagens panorâmicas omnidirecionais [8] são estruturas com um apelo natural à imer-são, na medida em que proporcionam ao observador a visualização de uma cena em todasas direções. Com uma representação segmentada por camadas, pretende-se ir mais alémneste aspecto de imersão tratando situações de oclusão de elementos e explorando o efeitode paralaxe entre as camadas para simular pequenas alterações de perspectiva baseadasna pose do aparelho e na direção de visualização do observador.

Além dos frameworks básicos para desenvolvimento de aplicações para a plataformaiOS [5], utilizar-se-á diretamente a Open Graphics Library [9] para tratar da modelagem erenderização de elementos gráficos tridimensionais, visando maior desempenho e controlesobre o resultado desejado. Com as bases da visualização construídas, o enfoque dotrabalho será a implementação de estratégias para a interação com o conteúdo visualizado,bem como a exibição de conteúdos adicionais à cena, levando em consideração, inclusive,o posicionamento do usuário.

1.2 MOTIVAÇÃO

Dados os dois problemas propostos, visualização e interação, as plataformas móveistêm se apresentado como uma alternativa eficaz para atacá-los devido à variedade derecursos integrados. A facilidade de acesso a esses dispositivos e também de distribuiçãode aplicativos em lojas virtuais permitiu o desenvolvimento de um sólido mercado ondesoluções criativas podem ser um bom diferencial. No meio acadêmico, pesquisadorestambém acrescentaram estes aparelhos aos seus aparatos de trabalho [8, 10, 11, 12, 13],apostando na evolução do poder da computação móvel para adaptação de soluções jáexistentes e o desenvolvimento de novas soluções para o futuro.

As pesquisas nas áreas de computação gráfica e visão computacional há muito tempoabordam problemas relacionados à visualização tanto no campo bidimensional (imagens)quanto no campo tridimensional, não raramente interligando ambos os campos. Comuma estrutura física 2D e uma estrutura semântica 3D, imagens panorâmicas têm sidofrequentemente utilizadas quando se objetiva proporcionar a um observador uma visãogeral de um ambiente a baixo custo.

No que diz respeito à interação com elementos virtuais, a modelagem 3D constitueum processo eficaz, principalmente pela facilidade em se modificar o ponto de vista dosobjetos. No entanto, modelar uma cena por completo seria um processo muito custosoprincipalmente pelo tempo necessário para se modelar cada objeto. Aliado a isto, a mes-clagem de objetos modelados com elementos reais da cena ainda apresenta problemas devisualização difíceis de se resolver. Assim, imagens panorâmicas apresentam-se como bonssubstitutos tanto para a modelagem de ambientes, quanto para a visualização de novos

16

elementos, que modifiquem a percepção do usuário em seu mundo. Uma arquitetura depanoramas com camadas possibilitaria a aproximação entre este modelo baseado em ima-gens e um modelo tridimensional tanto na visualização quanto na interação, introduzindomudanças de perspectiva e oclusão.

1.3 METODOLOGIA

Este projeto foi segmentado em 4 áreas relacionadas, porém implementadas com umcerto grau de independência. A primeira área trata da modelagem, que abrange o projetoe a implementação de um sistema gráfico tridimensional renderizador em tempo real.Como a visualização pretendida é feita de forma indireta, por imagens omnidirecionais, amodelagem trata basicamente da implementação de um visualizador de panoramas paraum dispositivo móvel, além da modelagem de todos os elementos auxiliares necessáriospara que haja interatividade.

A visualização em si consiste de uma outra área, que aborda a segmentação das ima-gens em camadas por profundidade, o preenchimento de espaços resultantes da segmen-tação em camadas e a exploração do efeito de paralaxe entre as camadas para gerar umavisualização mais imersiva. Os problemas de visualização comuns à realidade aumen-tada são tratados nesta área. Como abordado no objetivo, supõe-se que a representaçãode uma panorama por camadas já se encontra pronta ou foi obtida manualmente. Odesenvolvimento de mecanismos para a segmentação de imagens e/ou a recuperação daprofundidade estimada de cada pixel da imagem constituiriam, por sua complexidade, umtrabalho à parte.

A terceira área trata da microlocalização do usuário. Nesta área, objetivou-se provermecanismos para que fosse possível localizar o usuário dentro de um ambiente in-doorcomo um museu ou outro tipo de exposição onde haja interesse em utilizar aplicativoscom imagens interativas.

Unindo-se às duas áreas apresentadas, tem-se as interfaces com o usuário e disposiçãode conteúdo. Neste ponto, estuda-se como explorar recursos como os sensores de atitudedo dispositivo, as câmeras e a tela sensível ao toque para se interagir de forma intuitivae apresentar ao usuário conteúdos coerentes com as interações.

1.4 ESTRUTURA DO TRABALHO

Este trabalho está estruturado em 7 capítulos principais e 2 capítulos de apêndice.Após uma introdução para situar o leitor em alto nível dentro do assunto, apresenta-seum capítulo com tópicos tutoriais para este trabalho e o estado da arte dos assuntosrelacionados, em que é feita uma revisão bibliográfica. Neste capítulo, conceitua-se rea-lidade aumentada (RA) [14], apresenta-se os principais problemas desta área de estudoe aborda-se como os dispositivos móveis contribuíram para a popularização deste termo.

17

Além disso, explica-se um pouco sobre imagens panorâmicas omnidirecionais e o porquêelas são relevantes para este trabalho.

O capítulo 3 trata sobre as tecnologias utilizadas na implementação do projeto. Comenta-se sobre a plataforma iOS [5], escolhida para implementação do framework, o padrãoOpenGL [9], o Bluetooth Low Energy (BLE) e o iBeacon, tecnologias que serão utilizadasdireta ou indiretamente na implementação do projeto.

Em seguida, nos capítulos 4 e 5, descreve-se as estratégias adotadas em cada compo-nente do framework. O capítulo 4 apresenta detalhes quanto à visualização, abordando aarquitetura de panoramas com camadas, os elementos de suporte à modelagem de umacena, a abordagem adotada para inserir mudanças de perspectiva e abstrações auxiliarespara lidar indiretamente com a API da OpenGL.

O capítulo 5 trata dos componentes de interação e de microlocalização. Inicialmente,descreve-se como implementar a técnica de ray picking e como utilizar uma camada es-pecial, não visível, para a interação dentro do ambiente 3D. Após isso, trata-se dos com-ponentes implementados para a microlocalização utilizando a comunicação por BLE.

O capítulo 6 trata do framework propriamente dito, mostrando como todos esses com-ponentes se relacionam e como o cliente do framework poderia utilizá-lo. Neste capítulorelaiza-se uma análise dos resultados obtidos a partir da implementação das estratégiasapresentadas.

Ao final, há uma conclusão com sugestões para a expansão do framework e comentáriossobre propostas de trabalhos futuros. No apêndice, abordam-se outras informações sobretecnologias de transmissão de dados alternativas ao Bluetooth Low Energy e também sobrea utilização de billboards em cenas 3D.

18

2 TÓPICOS TUTORIAIS E O ESTADO DA ARTE

Este capítulo aborda conceitos teóricos e alguns trabalhos cujos resultados são muitorelevantes para a realização deste projeto. Essas contribuições ajudam a entender algumasrazões para a escolha da abordagem deste trabalho.

2.1 REALIDADE AUMENTADA

A terminologia Realidade Aumentada (RA) é muito tratada sob a perspectiva da com-putação gráfica, que enfatiza os aspectos ligados à coexistência em harmonia de ambientesvirtuais e reais cada vez mais interativos. Uma definição clássica para o termo seria: Re-alidade Aumentada é um sistema que mistura o mundo real com elementos virtuais, atuaem três dimensões, e possui interatividade em tempo real [14].

No entanto, frequentemente, esta terminologia tem sido interpretada de maneira maisampla, englobando também, por exemplo, o campo sonoro. Portanto, consideraremosrealidade aumentada como uma experiência dada pela percepção de mesclagem entreelementos que não existem fisicamente (virtuais) com os elementos que existem fisicamenteem nosso mundo, desde que haja interatividade em tempo real e o usuário ainda sereconheça inserido no mesmo local físico em que se encontra. Esta noção de estar nomesmo local é uma importante diferença entre a realidade aumentada e a realidade virtual.

O advento dos dispositivos móveis, assim como o surgimento de outras tecnologias,possibilitaram novas formas de interação e manipulação dos dados pelos usuários. Alémdisso, aproximaram mais ainda a tecnologia digital à vida do usuário comum, que passoua conviver de forma quase que dependente, com uma ferramenta que integra diversossensores e possui alto poder computacional. Dada a grande quantidade de informaçãoostensivamente espalhada pela internet, selecionar esta informação e torná-la disponívelno momento adequado para o usuário constituem desafios de interesse para o suporte auma experiência de realidade aumentada através da conexão visual entre o que poderiaser visto em uma página web e o que está sendo visto no mundo real.

As lojas virtuais de aplicativos facilitaram o processo de distribuição e venda de apli-cações para estes novos dispositivos e atraíram a atenção de muitos desenvolvedores in-dependentes, empresas e pesquisadores do meio acadêmico, que passaram a investir emsoluções criativas para diferenciação e sucesso de seus produtos. Embora a ideia de reali-dade aumenta exista desde muitos anos atrás, foi este contexto da computação móvel quecolocou a RA em evidência dentro da sociedade.

2.1.1 PRINCIPAIS PROBLEMAS

Os principais problemas de visualização encontrados para se fazer aplicações em reali-dade aumentada são o problema do registro, do rastreamento e da oclusão [8]. O problema

19

do rastreamento ou rastreamento do ponto de vista do usuário, é o problema de se de-terminar a perspectiva sob a qual a imagem virtual deverá ser desenhada. Para isso, énecessário reconhecer de onde e como o usuário observa a cena, determinando os parâ-metros intrínsecos (distância focal, ponto principal, dimensões de imagem) e extrínsecos(pose) da câmera, processo conhecido como calibração de câmera [15].

Conhecendo-se o ponto de vista adequado, deve-se tratar do problema do registro,que em uma análise geral consiste em encontrar a transformação entre dois sistemas decoordenadas [16], objetivando alinhá-los. Dentro da RA, o registro frequentemente setraduz no alinhamento geométrico entre duas imagens, algo extremamente importantepara uma correta ilusão de coexistência dos objetos para o usuário [17]. No caso darealidade aumentada, as duas imagens referidas no problema são representadas pelosobjetos reais e virtuais. A FIG. 2.1 ilustra uma situação em que o registro entre a cena(real) e a anotação (virtual) está inadequado e outra em que o registro está correto.

(a) Registro incorreto (b) Registro correto

FIG. 2.1: Ilustração do problema do registro [13]

O problema da oclusão consiste de um problema de ordenação e ocultação de objetosque se sobrepoem na visão do usuário. Se, por exemplo, na visualização de uma sala deestar insere-se uma bolinha de tênis rolando pelo chão em um plano mais afastado doobservador em relação ao plano em que se encontra um sofá, esta aplicação deve ser capazde identificar quando a bolinha e o sofá se sobreporiam em relação ao observador e, porconseguinte, ocultar a bolinha enquanto esta condição permanecer.

2.2 IMAGENS PANORÂMICAS

Imagens panorâmicas, ou panoramas, são imagens que possuem um grande campo devisão e contém uma quantidade de informação visual muito superior à que os seres huma-nos são capazes de observar e compreender naturalmente. Para ser observada no plano,como uma única imagem, esta informação visual pode ser parametrizada de diversas ma-neiras diferentes, dando origem a vários tipos de panoramas tais como a panorama planar,a cilíndrica, a cúbica ou a equirretangular. Este tipo de imagem pode ser capturado comequipamentos especiais tais como câmeras com lente do tipo ”olho-de-peixe” (fisheye lens)ou pode ser sintetizado por software a partir de várias fotografias comuns de um mesmo

20

local, processo conhecido como panorama stitching. Para mais detalhes sobre as formasde aquisição de imagens panorâmicas, ver [8] e suas referências.

Para este trabalho, sempre que for tratado de imagens panorâmicas ou panoramas,estaremos nos referenciando às imagens omnidirecionais, isto é, imagens que contém todaa informação visual da esfera de visão [7], compreendendo, portanto, tudo que pode servisualizado em uma cena a partir de um ponto fixo em qualquer direção. Dentre asimagens omnidirecionais, selecionou-se o formato equirretangular de parametrização paraimplementação do projeto (FIG. 2.2).

FIG. 2.2: Exemplo de panorama equirretangular [18]

A parametrização equirretangular é obtida a partir de uma analogia das coordenadasesféricas com as coordenadas cartesianas, dividindo-se por intervalos iguais os ângulos Je f das direções horizontal e vertical, respectivamente. Por conseguinte, uma panoramaequirretangular possui uma associação natural com um sistema de latitude e longitude.

2.3 REALIDADE AUMENTADA INDIRETA

O trabalho de [13] sobre realidade aumentada indireta é a principal base deste pro-jeto. Os autores realizaram um estudo sobre o uso de imagens panorâmicas para realidadeaumentada ao invés da imagem capturada em tempo real através da câmera de um dispo-sitivo móvel e chamaram a este tratamento de realidade aumentada indireta. Os autoresfizeram testes com usuários, buscando estabelecer comparações entre esta abordagem ea abordagem tradicional de visão direta por vídeo, obtendo resultados sobre a percepçãohumana a partir das impressões deste conjunto de teste.

Dentre outras coisas, buscou-se responder o seguinte questionamento: ”a realidadeaumentada indireta tem o mesmo nível de imersão que a direta?”. Para isso, foramfeitos testes com situações favoráveis às duas abordagens e depois uma comparação com

21

situações desfavoráveis à abordagem indireta, tais como um ambiente dinâmico, o usode panoramas com centro de projeção afastado da posição do usuário e mudanças deiluminação causadas, por exemplo, por uma imagem capturada no início da manhã eutilizada ao final da tarde. As conclusões destes testes foram sintetizadas em quatroconstatações:

1. Em condições favoráveis para as duas abordagens, a grande maioria dos usuáriosnão notou diferenças entre a RA indireta e a RA tradicional.

2. Em condições favoráveis, a RA indireta teve a preferência dos usuários sob todos ostestes.

3. Nos testes em ambientes com elementos dinâmicos, a experiência em RA indiretafoi menos prejudicada que a em RA tradicional.

4. Utilizar uma panorama capturada em uma posição diferente daquela em que o usuá-rio se encontra realmente reduz a imersão e modifica a experiência. No entanto, estamudança é apenas significante quando as duas localidades estão bem separadas.

Esse resultado se deve, em parte, à vantagem da realidade aumentada indireta nasolução do alinhamento entre os objetos reais, do mundo físico, e os elementos virtuaisadicionados. Enquanto nas abordagens tradicionais os erros neste problema de visuali-zação são facilmente notados, na abordagem indireta, este erro só é percebido entre oaparelho e o ambiente externo; ou seja, a imagem exibida na tela do aparelho pode estarem registro perfeito. Como tanto a panorama quanto os demais elementos virtuais sãomovimentados em conjunto, não há deslocamentos entre eles.

Muitas aplicações de realidade aumentada tradicional utilizam recursos como QR Co-des [19] ou outras marcações fiduciais, isto é, marcações com características propícias àdetecção, para determinar os pontos da cena no mundo real em que serão inseridos oselementos virtuais e/ou como estes elementos serão inseridos. Outra solução adotadaconsiste em utilizar algoritmos de visão computacional para pré-processar as imagens eidentificar os pontos de interesse para a aplicação; no entanto, esta solução é muito custosado ponto de vista computacional e nem sempre muito robusta. Ambas as soluções sãosuscetíveis a erros e imprecisões no registro, inerentes aos sensores utilizados. A utilizaçãode imagens seria, portanto, uma abordagem diferente para este problema através de umasolução mais simples, dado que pode-se posicionar perfeitamente novos elementos dentrode uma imagem que já se conhece previamente. Além disso, a imprecisão dos sensoresnão exerce impacto sobre a visualização já que não há mais um contraste entre o mundoreal e o mundo virtual. A experiência depende da preparação do ambiente e do conteúdoe também do uso que será dado à aplicação.

22

Evidentemente, esta abordagem não funciona para qualquer tipo de aplicação. No-tadamente limitações na cena como tráfego (elementos dinâmicos), mudanças bruscas notempo (clima) e na iluminação não podem ser representadas por uma imagem estática.Como visto em [13], em se tratando de imagens panorâmicas, um fator que pode ser limi-tante à experiência é o fato de que a perspectiva exibida é aquela que pode ser percebidaa partir do centro de projeção da panorama, isto é, a partir do ponto em que esta infor-mação visual foi capturada. Assim, sempre que possível, deve-se selecionar uma imagemcujo centro de projeção esteja o mais próximo possível à posição real do observador.

2.3.1 PANORAMAS COM CAMADAS

Dentro do contexto de utilização de imagens pré-fotografadas para aplicações em re-alidade aumentada, em [8] os autores propõem uma arquitetura baseada em panoramascom camadas para tratar o problema de inserção de novos elementos na cena. Utilizandoimagens panorâmicas equirretangulares, seria possível compor uma estrutura com esfe-ras ou fragmentos de esferas concêntricas com raios de tamanhos diferentes (FIG. 2.3).Estruturas com uma ideia similar, como mosaicos concêntricos [20] ou panoramas commapas de profundidade [21] foram exploradas anteriormente, inclusive para aplicações emrealidade aumentada.

Na proposta original de [8], os autores propõem que a camada mais externa seja umaesfera completa, uma imagem panorâmica que represente a cena original. As camadasmais internas serviriam para a adição de elementos que não estavam presentes na cenaoriginal. Para o observador, esta estrutura de panorama em camadas se comportariacomo uma imagem única e que poderia ser tornada interativa a partir de tratamentosespecíficos para cada camada.

FIG. 2.3: Arquitetura de panoramas com camadas [8]

A região da cena que é exibida depende apenas do ângulo de visão do observador.Dessa forma, o tamanho do raio das camadas não interfere na porção da imagem que será

23

visualizada, servindo somente para definição da profundidade dos elementos em relaçãoao observador, consequentemente definindo uma ordenação para fins de oclusão.

Em [21], os autores utilizam um modelo de camadas com profundidade, em que érealizada uma estimação da profundidade de cada ponto da cena, gerando-se um mapade profundidade que é utilizado para modelar as relações entre os objetos de forma maispróxima da imagem real. Neste projeto, adota-se um modelo mais simplificado em que ascamadas determinam apenas uma ordem de prioridade entre os elementos. Este modeloé suficiente para determinar relações de oclusão e explorar o efeito de paralaxe dentro dacena, como será abordado na seção 2.4 sobre ”Visualização Imersiva”.

2.4 VISUALIZAÇÃO IMERSIVA

O problema da visualização omnidirecional em dispositivos móveis consiste, basica-mente, em pegar uma imagem panorâmica e fazer com que seja exibida na tela do dis-positivo apenas uma pequena parte desta imagem, compatível com o campo de visãohumano e coerente com o que a maioria das câmeras desses aparelhos nos permitiriaobservar. Além disso, o trecho da imagem a ser exibido deve ser determinado pela ori-entação do aparelho no espaço, sendo sempre alterado pelos movimentos do usuário. Ouseja, se segurarmos o dispositivo tentando observar o teto através dele, em sua tela deveser exibido o equivalente ao teto da cena.

Como as imagens panorâmicas possuem um único ponto de observação, chamado decentro de projeção, a cena será sempre observada a partir do ponto em que a imagemfoi fotografada. Para suportar translações do observador dentro da cena, seria necessáriauma base de dados de várias panoramas adquiridas a partir de pontos diferentes do mesmoambiente. Este tipo de abordagem é alvo de recentes pesquisas e não pretende-se tratá-lano escopo deste trabalho.

No entanto, baseado no trabalho de [10], apresenta-se um método para simular pe-quenas mudanças de perspectiva para um observador próximo ao centro de projeção dapanorama de acordo com a orientação de sua face em relação à orientação do dispositivo.Para isso, propõe-se uma modificação na arquitetura em relação ao trabalho de [8]: acamada mais externa, outrora constituída por uma imagem completa, será segmentadaem duas ou mais camadas, considerando a profundidade relativa entre os objetos da cena,isto é, objetos mais afastados do observador ficarão em uma camada e os mais próximosem outra. Cada camada, portanto, contém apenas uma parte da informação da imagemcompleta. Sobre a camada mais afastada, realiza-se um tratamento para completar totalou parcialmente as partes de informação que faltam, com o auxílio de algoritmos para pre-enchimento de regiões como os implementados em programas de edição de imagens. Comisso, pretende-se recuperar de forma aproximada a informação supostamente ocultadapelo que está presente nas camadas mais próximas.

24

Em [10], os autores propõem um método de fusão de dados provenientes dos sensoresde atitude de um dispositivo móvel (acelerômetro, giroscópio e magnetômetro) com umalgoritmo de detecção de face utilizado sobre a imagem da câmera frontal do aparelho. Oobjetivo desta fusão é a visualização de imagens maiores do que a tela do dispositivo, comuma interface livre de toques sobre a tela como mecanismo de rolagem e deslocamento.

A ideia é unir a eficiência dos sensores, que podem realizar medidas da pose do aparelhorapidamente com a eficácia de algoritmos de detecção de faces para estimar a posição deobservação do usuário em relação ao dispositivo. Assim, pode-se tratar adequadamentesituações como a ilustrada na FIG. 2.4 onde estão representados um dispositivo móvel naparte superior e um observador na parte inferior. Nas situações b e c, percebe-se que odispositivo apresenta o mesmo valor DJG de inclinação, porém o usuário observa a telado aparelho sob um ângulo diferente. Os sensores de atitude do aparelho não são capazesde diferenciar estas duas situações, pois eles lidam apenas com a estimação da pose doaparelho dentro do mundo real, independente de onde esteja o observador.

FIG. 2.4: Posições relativas entre o observador e o aparelho [10]

Para este projeto de fim de curso, almeja-se utilizar o princípio desta pesquisa comobase para propor uma visualização de panoramas com camadas que explore o efeito deparalaxe entre as camadas da panorama, a fim de simular pequenas mudanças de pers-pectiva que correspondam a movimentos de cabeça do observador. Com isto, pretende-setornar a experiência de visualização de uma panorama mais tridimensional e, sobretudo,mais imersiva.

Utilizando os sensores de atitude e a câmera frontal do aparelho móvel, explora-se oefeito de paralaxe entre as camadas, isto é, além de movimentar a cena de acordo com apose do aparelho, movimenta-se também uma camada em relação à outra de acordo coma direção de observação do usuário. Com esta técnica, pretende-se simular a noção quetemos ao observar o mundo real e movimentar a cabeça, por exemplo, para observar umobjeto parcialmente ocultado por outro a partir de nossa posição.

25

3 AMBIENTE DE DESENVOLVIMENTO

Para a implementação deste framework, os testes serão realizados sobre dispositivosque utilizem o sistema operacional iOS [5]. A Apple [6], empresa responsável pelo desen-volvimento desta plataforma, é também responsável pelo desenvolvimento do hardwareque a utiliza, o que gera um alto grau de padronização entre as funcionalidades dos apa-relhos e garante o mesmo nível de qualidade para todos. O iOS foi estruturado paratirar máxima vantagem do hardware dos dispositivos que o suportam. Desenvolver paraessa plataforma tem uma relativa facilidade devido às tecnologias compartilhadas com oOS-X [22], que incluem o kernel OS-X, soquetes BSD para networking e compiladoresObjective-C e C/C++ para performance nativa [5]. Além disso, o iOS em conjunto como framework Cocoa Touch, cria uma experiência de interface para usuário de múltiplos to-ques (multi-touch), aumentando as possibilidades de desenvolvimento de aplicativos paraa plataforma. Todos os dispositivos recentes da Apple, isto é, lançados nos últimos 2anos, possuem os sensores acelerômetro, giroscópio, magnetômetro, além de uma câmeraposterior e outra anterior.

3.1 TECNOLOGIA GRÁFICA

A Open Graphics Library [9] é um padrão gráfico da indústria que possibilita a ren-derização de objetos gráficos bidimensionais e tridimensionais, funcionando como umainterface de baixo nível entre a aplicação e a placa gráfica (GPU), demostrada esquemati-camente na FIG. 3.1. Essa ferramenta foi desenvolvida e mantida pelo consórcio KhronosGroup. Ela possui um grande conjunto de funções que faz uso de praticamente todosos recursos do hardware de vídeo. Dentre os aspectos que podem ser controlados pelaAPI (Application Programming Interface) da OpenGL estão as cores, níveis de transpa-rência, cálculos para controle de iluminação, sombreamento, neblina, etc. Encontra-seatualmente em sua versão 4.4. Devido à característica móvel deste projeto, será adotadaa OpenGL ES (Embedded System) [23], que é uma versão projetada especificamente paraambientes móveis como telefones celulares, PDAs e consoles de video games, restringindoalgumas funcionalidades das versões principais, devido às limitações de hardware dessetipo de dispositivos.

26

FIG. 3.1: Interface aplicação-GPU [23]

A API da OpenGL ES encontra-se atualmente na versão 3.0, que assim como a suaversão anterior, possui pontos programáveis no pipeline de renderização, o Vertex Shadere o Fragment Shader, ambos escritos com a Graphics Library Shader Language (GLSL).Neste projeto, será utilizada a versão 2.0 da OpenGL ES, penúltima versão disponibilizada.

3.2 TECNOLOGIAS DE COMUNICAÇÃO

Bluetooth Low Energy (BLE) [24], também conhecido como Bluetooth Smart, é umatecnologia de transmissão de dados via rádio de sinais digitais na frequência de 2.4 GHz.Possui como principal diferencial um consumo energético extremamente baixo, em média1 mA, principalmente devido ao fato do tráfego de dados limitado quando comparado aoutras tecnologias, abrindo, dessa forma, espaço para uma nova gama de aplicações, istoé, além dos tradicionais dispositivos que já utilizam a tecnologia Bluetooth clássica, oBLE é visto também em outros aparelhos como, por exemplo, relógios de pulso, sensoresesportivos, brinquedos, sensores automotivos, além de encontrar diversas aplicações namedicina. Atualmente, diversos sistemas operacionais, incluindo iOS [5], Android [25],Windows Phone [26], BlackBerry [27], OSX [22] e Windows 8 [28] já são compatíveiscom esse novo modelo de Bluetooth.

Neste projeto, o BLE será utilizado em conjunto com estruturas denominadas beaconscomo meio de captação de dados que possam modificar o estado de aplicações. Algumasalternativas ao BLE seriam o QR Code e o NFC, ambos são tratados no apêndice A destetrabalho.

3.3 TECNOLOGIA DE MICROLOCALIZAÇÃO

3.3.1 BEACON

Beacon [29] é um dispositivo que funciona como um sistema de detecção de proxi-midade para lugares fechados ou de dimensões relativamente pequenas. O aparelho secomunica com outros dispositivos transmitindo pacotes em intervalos regulares de tempoatravés da tecnologia Bluetooth Low Energy, sendo capaz de detectar aqueles que estive-

27

rem em suas proximidades, desde que estejam com o Bluetooth ativado, podendo inclusivecalcular a que distância eles se encontram.

Um beacon possui ainda a capacidade de enviar mensagens e expô-las na tela doaparelho celular mesmo se os usuários não estiverem com o aplicativo aberto ou mesmose estiverem com o celular bloqueado, desde que o aplicativo esteja ao menos instalado.Tal fato surge como uma janela de oportunidades para diversas aplicações, visto que casobeacons estejam dispostos em uma loja, prédio ou shopping, por exemplo, provavelmentequem passar próximo a um deles, receberá mensagens com informações relevantes.

Especificações TécnicasO Estimote Beacon [30], modelo utilizado para a realização desse trabalho, é consi-

derado um iBeacon por se comunicar através do padrão tecnológico desenvolvido pelaApple. Trata-se de um pequeno super-computador, possuindo um processador 32-bitARM® Cortex M0 CPU com 256kB memória flash, acelerômetro, sensor de temperaturae 2.4 GHz Bluetooth 4.0 Smart, também conhecido como BLE ou Bluetooth Low Energy,envoltos por uma estrutura flexível feita de silicone. Na FIG. 3.2 é possível ver um beaconda marca Estimote em visão explodida.

FIG. 3.2: Beacon da marca Estimote em visão explodida [31]

Interação entre dispositivosCelulares e outros aparelhos recebem os sinais enviados periodicamente pelos beacons,

sem necessidade de pareamento prévio, e estimam sua distância através da força do sinalrecebido, sendo que quanto mais perto o usuário estiver, mais forte será o sinal. Depen-dendo da implementação, aparelhos podem examinar o sinal a cada 1 segundo ou 10 vezespor segundo, quanto mais frequente for, mais estável será o sinal e melhor a experiênciado usuário. Além disso, é possível programar o aparelho para enviar mensagens distintasde acordo com a região em que o usuário se encontre. É interessante ressaltar tambémque cada aparelho consegue receber o sinal de mais de um beacon de uma vez e, desdeque instalado o aplicativo apropriado, estimar a distância relativa entre cada um deles.

O dispositivo Estimote utiliza a comunicação BLE através de um formato padroni-zado pela Apple no qual cada pacote transmitido consiste em cinco partes principais de

28

informação:

• Prefixo iBeacon (9 bytes): String padronizada pela Apple para distinguir os apare-lhos utilizando seu padrão tecnológico;

• UUID (16 bytes): Utilizado para diferenciar um grande grupo relacionado de be-acons. Caso eles sejam utilizados em shopping, por exemplo, todos os beacons deuma mesma loja teriam, provavelmente, o mesmo identificador UUID;

• Major (2 bytes): Utilizado para diferenciar pequenos grupos de beacons. No exem-plo de uma grande loja, todos os beacons de um mesmo departamento teriam omesmo identificador Major;

• Minor (2 bytes): Identificador individual de cada beacon;

• Tx Power (2 bytes): Definido como a força do sinal a exatamente um metro dedistância do aparelho e utilizado para determinar a proximidade que o usuário seencontra do beacon.

Na FIG. 3.3 está representado esquematicamente o pacote de dados transmitido.

FIG. 3.3: Desenho esquemático de um pacote de dados transmitido

A distância máxima que o Estimote Beacon consegue enviar sinais depende do ambi-ente em que ele está localizado, dado que o sinal pode ser difratado, sofrer interferênciaou absorvido por água, por exemplo. Em geral, ele é capaz de enviar e receber sinaisa distâncias que variam de 5 centímetros a até aproximadamente 70 metros, sendo essadistância categorizada em 3 regiões distintas, como visto na FIG. 3.4.

• Immediate: Poucos centímetros;

• Near: Menor do que 10 metros;

• Far: Maior do que 10 metros;

O dispositivo pode, ainda, ser programado para enviar diferentes tipos de mensagens deacordo com qual das três regiões o usuário se encontrar.

29

FIG. 3.4: Desenho esquemático das três regiões (near, far e immediate) de atuação doEstimote Beacon [32]

30

4 MODELAGEM E VISUALIZAÇÃO

Os componentes de modelagem e visualização apresentam soluções ligadas ao processode renderização, isto é, ao processo que recebe a descrição de uma cena tridimensionalem um espaço de coordenadas próprio e produz uma imagem no espaço de coordenadasda tela do dispositivo de exibição. Este capítulo descreve as estratégias e alguns doscomponentes implementados no framework que estão diretamente relacionados com aatividade de renderização para visualização em tempo real de imagens panorâmicas.

4.1 GRAFO DE CENA

Para que se possa compreender a organização e as relações entre os elementos queserão dispostos nas cenas utilizando este framework, é necessário enteder o conceito deum grafo de cena. Um grafo de cena é uma estrutura de dados que permite gerenciar demaneira eficiente todos os elementos de uma cena. Com esta estrutura, pode-se definirrelacionamentos entre objetos da cena e criar hierarquias entre eles, unindo vários objetosem um grupo. Isto é muito útil, por exemplo, para que seja possível especificar a posição ea orientação de um determinado objeto em relação a outro, sem que seja necessário sabera posição absoluta daquele determinado objeto na cena como um todo.

Cada elemento do grafo é chamado de nó. As relações entre os elementos são definidascomo em um grafo comum (estrutura algébrica), no entanto há algumas restrições. Cadanó pode ter nenhum ou muitos nós filhos, porém apenas um único nó pai. Isso evita queo grafo tenha ciclos. A cena será definida como o nó do qual todos os demais nós dografo são descendentes. O grafo de cena é, portanto, um grafo acíclico e conexo, o quecaracteriza uma árvore, em que a raiz representa uma cena, onde os demais objetos estãopresentes.

(a) (b)

FIG. 4.1: Exemplo de Grafo de Cena

Cada objeto constitui um único nó e pode fazer parte de um grupo de objetos com umnó pai em comum. Assim, por exemplo, se quiséssemos desenhar um carro, poderíamoster diversos objetos componentes como chassi, rodas etc, que fazem parte de uma única

31

entidade: nó carro (FIG. 4.1). Todas as transformações de um nó pai são propagadaspara os nós filhos, portanto se o carro se locomove para uma dada direção, todos osseus componentes também se locomovem para aquela direção, mas cada componentepode apresentar uma transformação própria que é levada em consideração em relação aocarro; as rodas, por exemplo, podem rotacionar independente do chassi. Cada nó possuiuma matriz de transformação local, que representa sua pose em relação ao nó pai, euma matriz de transformação global ou do mundo, que define efetivamente o estado desteobjeto na cena. A matriz de transformação global é obtida multiplicando-se as matrizes detransformação local de cada nó ancestral do nó em questão pela matriz de transformaçãolocal do próprio nó. Em nossa implementação, para facilitar algumas operações futuras,armazenou-se também as matrizes inversas de cada transformação como apresentado em[33].

A implementação do grafo de cena segue o padrão de projeto Composite (ObjetoComposto) [34]. A classe SceneNode representa o nó base do grafo. Uma cena e qualquerobjeto que pode estar presente em uma cena é descendente de SceneNode. DrawableNodeé uma especialização de SceneNode que trata dos objetos que podem, efetivamente, seremdesenhados em tela. Nós que podem ser desenhados possuem uma referência a umainstância de uma malha poligonal 3D (Mesh), uma textura e respondem à mensagem draw,delegada à malha, que executa chamadas à API da OpenGL. Os nós que não constituemobjetos que podem ser desenhados em tela repassam a mensagem draw para seus filhos e,portanto, não podem estar presentes nos níveis mais profundos do grafo. É interessantenotar que, com esta modelagem, objetos desenháveis e não desenháveis podem ser tratadosda mesma forma, isto é, sob a mesma interface, pela cena modelada.

SceneNode não é uma classe abstrata, pois há nós no grafo que representam apenastransformações a serem aplicadas a um grupo de objetos. Referindo-se ao exemplo docarro, nesta modelagem, por representar um agrupamento, um carro seria um SceneNodecomum, porém cada parte do carro seria um DrawableNode.

4.2 MALHA POLIGONAL

Os objetos 3D são descritos por propriedades que podem ser traduzidas em númerosa partir de uma modelagem matemática. A abstração básica sobre a qual pode-se repre-sentar atributos de um objetos são os vértices. Para aplicações gráficas, o conceito devértice é muito mais abrangente que aquele utilizado no estudo na geometria plana ou es-pacial. Um vértice é um elemento que pode possuir vários atributos descritos por n-uplasordenadas, tais como coordenadas de posição, cor, vetor normal, coordenadas de textura,etc. A ligação entre dois vértices se chama aresta e a região convexa do espaço delimitadaentre um conjunto de arestas constitui uma face. Na etapa de modelagem, apenas osvértices possuem propriedades atribuídas explicitamente, os elementos de ordem superior

32

(arestas e vértices) têm suas propriedades calculadas em função dos valores dos vérticesque os compõem. A coleção de vértices, arestas e faces que descrevem a geometria de umdeterminado objeto denomina-se malha poligonal. Cada um destes conceitos encontra-seilustrado na FIG. 4.2.

FIG. 4.2: Malhas poligonais 3D com destaque para vértices, arestas e faces

Na modelagem adotada neste trabalho, uma malha poligonal é responsável por en-capsular atributos intrínsecos da geometria de um objeto, deixando como atribuição dainstância de nó (DrawableNode) definir atributos extrínsecos como a cor ou a texturaque será associada aos vértices da malha do objeto, além da matriz de transformação quedefine a pose e a escala do objeto. Desta forma, objetos com formas geométricas similares,que podem ser transformadas umas nas outras por meio de transformações homogêneas[35], podem compartilhar a mesma instância de malha.

A classe Mesh foi modelada como a classe primitiva que encapsula os dados e as opera-ções para recuperar ou modificar os dados da geometria de um objeto. Por especializaçãode Mesh, pode-se escrever malhas que representem a geometria de objetos específicoscomo, por exemplo, um cubo, um cilindro ou até mesmo geometrias mais complexas.

Dado que as panoramas equirretangulares possuem uma associação natural com osistema de coordenadas em latitude e longitude, cada camada é representada por umamalha poligonal de uma esfera cujos vértices foram obtidos por amostragem segundouma discretização uniforme dos ângulos em coordenadas esféricas. Assim, é como secada vértice possuísse sua coordenada de posição sobre a interseção entre um meridianoe um paralelo sobre a superfície da esfera (FIG. 4.3). Essa parametrização nos permitecalcular com facilidade as coordenadas de textura de cada vértice e mapear uma imagemequirretangular como textura no interior da esfera.

33

FIG. 4.3: Malha esférica com faces quadrangulares [36]

A classe SphereMesh é uma especialização de Mesh que implementa a geometria deuma esfera por amostragem uniforme em latitude e longitude. O acesso à malha foiimplementado segundo o padrão de projeto Singleton (Objeto Singular) [34] para queobjetos com geometria similar à de uma esfera compartilhem uma instância única demalha, otimizando a ocupação da memória. Visando uma otimização de desempenho, aclasse SphereMesh possibilita que sejam solicitadas instâncias de malhas em alta resolução(maior amostragem de vértices) ou em baixa resolução. Desta forma, sacrifica-se umpouco de memória por uma economia de processamento na renderização de objetos quenão requeiram uma alto grau de detalhamento.

4.3 PANORAMA COM CAMADAS

Uma panorama com camadas é implementada como um contêiner de esferas concên-tricas ordenadas pelo tamanho de seu raio. Cada esfera tem uma imagem associada deforma que uma única cena seja gerada com os elementos de cada imagem dispostos deforma complementar. O mapeamento das imagens sobre a superfície das esferas e a trans-formação aplicada pela câmera, como será descrito na seção 4.6 sobre a câmera virtual,permitem que a imagem seja visualizada sem distorções.

4.3.1 IMAGEM DE REPRESENTAÇÃO

Para a correta utilização de uma panorama com camadas, deve-se prover a este com-ponente um conjunto de imagens equirretangulares que, ao serem sobrepostas, compõemuma cena coerente. Uma forma de obter tais imagens é por meio da segmentação de umaimagem panorâmica primitiva em 2 ou mais imagens, separando-se os objetos de acordocom suas distâncias relativas ao ponto de projeção da panorama. A FIG. 4.4, a FIG. 4.5e a FIG. 4.6 ilustram a representação utilizada.

34

FIG. 4.4: Imagem da camada mais externa

FIG. 4.5: Imagem da camada intermediária

FIG. 4.6: Imagem da camada mais interna

A camada mais externa contém a maior parte do conteúdo da imagem original. Noslocais onde estavam localizados os objetos que foram segmentados para camadas maisinternas, aplica-se um algoritmo de reconstituição de imagem para que seja feito o pre-enchimento dos buracos remanescentes. Estes buracos são ocultados pelas camadas mais

35

internas, porém é importante que essa reconstituição seja realizada para que se possaexplorar os efeitos de paralaxe, pois ao introduzir pequenas translações na cena, seriapossível visualizar as regiões segmentadas da camada mais externa.

As imagens das camadas mais internas possuem apenas alguns objetos esparsos, como restante da imagem com preenchimento transparente.

Neste trabalho, as etapas de segmentação e preenchimento de buracos foram realizadasmanualmente com auxílio do software de edição de imagens: Adobe Photoshop CS6 [37].

4.4 FERRAMENTAS MATEMÁTICAS

Trabalhar com OpenGL [9] exige a manipulação de muitos vetores e matrizes em ope-rações comuns da álgebra linear, tais como produto escalar, produto vetorial, transposiçãode matriz, dentre outras. Por conta disso, inclui-se algumas classes para que fosse possí-vel tratar com vetores e matrizes de uma forma orientada a objetos e também que fossepossível retornar o endereço de memória que desse acesso aos dados de cada objeto, o quedeve ser passado como parâmetro a vários comandos da API da OpenGL.

4.5 SHADERS

A partir da versão 2.0, a OpenGL incorporou em seu pipeline de renderização duasetapas programáveis: o vertex shader e o fragment shader. A FIG. 4.7 representa umesquema simplicado do pipeline de renderização da OpenGL ES 2.0 [23]. Para maioresdetalhes de como funciona o pipeline de renderização e como escrever código para asetapas programáveis, uma boa referência é [38].

FIG. 4.7: Pipeline simplificado de renderização da OpenGL [38]

36

O vertex shader é responsável por realizar operações sobre vértices. Como definidona seção 4.2 sobre ”Malha Poligonal”, vértice é uma abstração que possui uma posiçãono espaço, dada por suas coordenadas cartesianas, e pode possuir outras propriedadescomo cor, coordenadas de textura, vetor normal, etc. O vertex shader recebe, por meiode chamadas da API da OpenGL, os atributos dos vértices sobre os quais irá operare, então, pode executar operações como transformações de coordenadas, filtragem devalores, cálculos sobre a direção de raios de luz etc. As operações são realizadas sobrecada vértice individualmente, embora possam ser definidos alguns parâmetros comuns aserem aplicados a todos os vértices. Utilizar o vertex shader para executar transformaçõessobre os vértices é mais eficiente do que realizar essas transformações previamente dentroda aplicação. Os dados resultantes do vertex shader são passados como entrada para ofragment shader.

O fragment shader é responsável por operações sobre os fragmentos. Fragmentos são”candidatos” a serem exibidos em tela, resultado da etapa de rasterização (mapeamento dageometria da cena para a forma de pixel) [33, 35, 38]. O fragment shader é um programaque define como serão geradas as cores de cada fragmento e associa-as a eles. É nestaestapa do pipeline de renderização que são determinados os atributos das arestas e facesde um objeto. Está intimamente relacionado, portanto, ao mapeamento de textura emsuperfícies, utilizando os dados disponíveis para interpolação.

Essas duas etapas são escritas como programas na Graphics Library Shader Language(GLSL). Estes programas devem ser lidos, compilados e ligados (linked) em um únicoprograma de shader (shader program), que será utilizado para a renderização dos objetosna cena. Características como propriedades dos materias componentes dos elementos sãodefinidas a partir de operações no fragment shader, portanto, na etapa de renderização,pode-se utilizar diferentes programas de shader para desenhar cada elemento (objeto) dacena.

Como muitas das operações necessárias para se criar um programa de shader são co-muns, definiu-se no framework uma classe Shader para encapsular todas essas operações,desde a leitura dos arquivos em que os programas se encontram. Assim, o usuário doframework tem que se preocupar apenas em manipular um objeto de shader para cadaprograma de shader em sua aplicação e requisitar as informações necessárias (como ende-reço do programa de shader, erros obtidos etc) enviando mensagens a este objeto.

4.6 CÂMERA VIRTUAL

A câmera determina o ponto de vista da cena. Para fins de renderização, a câmeraé apenas uma matriz de transformação, que aplicada aos elementos da cena produz umadeterminada imagem para a tela do dispositivo. No entanto, especificar diretamente estatransformação para atender às nossas necessidades e produzir imagens da maneira que se

37

deseja é uma tarefa complicada. Para se ter um controle adequado sobre esta transfor-mação e sobre quais elementos da cena serão desenhados e como eles serão desenhados natela do dispositivo de exibição, é necessário que seja definida uma abstração de câmeravirtual com parâmetros que podem ser estudados e compreendidos facilmente por um serhumano.

A API do OpenGL ES 2.0 não fornece uma abstração de câmera, como as versõesanteriores, ficando à cargo do programador implementar a sua própria abstração. Aimplementação da câmera para a arquitetura proposta segue um padrão peculiar, vistoque para visualizar imagens panorâmicas, o observador ficará sempre fixo no centro deprojeção da imagem. O modelo de câmera virtual adotado neste trabalho é o modelo dacâmera de furo (pinhole camera) [33, 35], comum em diversas aplicações de computaçãográfica.

Para construir uma abstração com parâmetros facilmente manipuláveis, a câmera foidividida em três transformações aplicadas em uma ordem bem definida sobre os elementosda cena e geridas internamente por uma instância da classe câmera. Cada transformaçãoé representada por uma matriz quadrada de ordem 4.0

BB@

0R

modelo

00

tx

ty

tz

1

1

CCA

0

BB@

0R

camera

00

tx

ty

tz

1

1

CCA

0

BB@

p1 p2 p3 p4p5 p6 p7 p8p9 p10 p11 p12p13 p14 p15 1

1

CCA =

0

BB@

a1 a2 a3 a4a5 a6 a7 a8a9 a10 a11 a12a13 a14 a15 1

1

CCA

FIG. 4.8: Transformações componentes da câmera

Na FIG. 4.8, a primeira transformação, da esquerda para a direita, dada pela modelmatrix representa o posicionamento do objeto em relação ao mundo, isto é, qual é a posee a escala do objeto que será desenhado em relação ao cenário 3D. Esta transformaçãonão indica o posicionamento dos objetos em relação a elementos da panorama, mas sim,o posicionamento do objeto em relação ao espaço em que a panorama também se en-contra imersa. A segunda transformação, dada pela view matrix, representa a pose dacâmera dentro do cenário. Por último, aplica-se uma transformação de projeção, dadapela projection matrix, representando a vista em perspectiva.

Ainda na FIG. 4.8, pode-se ver uma representação row-major por blocos da viewmatrix. O bloco R é constituído por uma matriz 3x3 que representa uma rotação. Osvalores t

x

, ty

e tz

constituem um vetor do R3 que representa a posição da câmera nesteespaço (o quanto ela transladou em relação à origem). A última linha tem seus valoresfixos. O produto matricial entre a view matrix e a model matrix resulta em uma matrizconhecida por ModelView Matrix, que representa os parâmetros extrínsecos da câmera.

A projection matrix, por sua vez, representa os parâmetros intrínsecos da câmera. Aprojeção adotada é a projeção perspectiva [15], que oferece uma boa aproximação do com-

38

portamento de câmeras reais. A transformação de projeção define um tronco de pirâmide(frustrum) de visualização. Apenas os elementos que se encontram dentro do volume dessetronco de pirâmide são candidatos a serem desenhados, os demais encontram-se fora docampo de observação da câmera. O plano mais próximo ao observador denomina-se planonear e o mais afastado, plano far (FIG. 4.9).

FIG. 4.9: Pirâmide de Visualização

Há, ainda, uma quarta matriz, que representa uma correção no posicionamento dacâmera, que pode ser necessária devido a erros de georreferenciamento de imagem, porexemplo. Esta matriz de correção é encapsulada dentro da classe câmera e incorporadaautomaticamente na view matrix, isto é, toda a vez que a aplicação necessita atualizara view matrix, a instância de câmera corrente atualiza o valor já pós múltiplicado pelamatriz de correção.

4.6.1 ATUALIZAÇÃO DA CÂMERA

Nosso objetivo nesta etapa é obter uma matriz que represente a transformação deum vetor no referencial global para um vetor no referencial do dispositivo. Esta matrizserá incoporada à nossa abstração de câmera, representando o posicionamento da câmeraefetivamente (view matrix). Como o ponto a partir do qual a cena é visualizada é fixo,coincidindo com o centro da estrutura de camadas esféricas, a matriz que precisamos serásempre uma matriz de rotação, obtida a partir da orientação do dispositivo em relaçãoao mundo. A FIG. 4.10 apresenta a convenção adotada pelo sistema iOS para os eixoscoordenados dos aparelhos.

39

FIG. 4.10: Orientação dos eixos coordenados no sistema iOS [39]

Qualquer aparelho com um magnetômetro e um acelerômetro é capaz de estimar suaorientação a partir das medidas obtidas para a magnitude da aceleração da gravidade noseixos coordenados, da estimativa do norte magnético e da medida da aceleração adicionaldevida aos movimentos sobre o aparelho. O kit de desenvolvmento para iOS possui oframework Core Motion [39], que permite a utilização ds dados dos sensores para seobter uma matriz de rotação que representa a orientação do dispositivo em relação a umreferencial fixo do mundo (Plano XY paralelo ao solo, com X positivo à direita e eixo Ypositivo no sentido terra-céu). Precisamos, portanto, da matriz inversa daquela retornadapela API do Core Motion. Como uma matriz de rotação é uma matriz ortonormal, suainversa é igual à sua transposta, o que facilita a solução do problema.

4.7 PERSPECTIVA DINÂMICA

No intuito de adicionar mais imersão na experiência do usuário, implementou-se umrecurso de perspectiva dinâmica na visualização das camadas do panorama. A inspira-ção para essa abordagem veio do trabalho [10], o qual foi feito em uma parceria entre odepartamento de pesquisas de Redmond da Microsoft com o Instituto Indiano de Tecno-logia localizado em Kanpur. Neste trabalho é estudado uma maneira de fundir os dadosprovenientes da detecção de faces através da câmera frontal do dispositivo com os dadoscolhidos do giroscópio para determinar a posição tridimensional do usuário em relação àtela do dispositivo.

Com esse tipo de informação, pode-se criar uma abordagem que deixe a interfacelivre de toques, não sendo necessário tocar na tela para navegar pelo ambiente da cenae permitindo que o usuário utilize somente uma mão para segurar o dispositivo. Alémdisso, utilizar esse tipo de interação é fácil e intuitivo. Um exemplo muito utilizado nasaplicações atuais é o movimento de pinça para ativar movimentos de zoom. Apesar de

40

ser uma solução efetiva, é necessário o uso de dois dedos colados na tela para realizar omovimento, o que oculta uma significante porção da cena. Em aplicações que o usuáriopode interagir com os elementos contidos na cena a partir do toque, se torna difícil corrigira ambiguidade de que tipo de ação está sendo realizada: interação ou zoom.

4.7.1 CORE IMAGE FRAMEWORK

A partir da versão 5.0 do iOS, foi adicionada o framework Core Image [40, 41]. Umdos recursos desse framework é a API para detecção de faces [42, 43] que pode analisar eencontrar faces humanas em uma imagem. É importante ressaltar que ele realiza detecçãode faces e não reconhecimento de faces. Detecção de faces é a identificação de regiões daimagem que possuem características de um rosto humano, enquanto reconhecimento defaces é a identificação do rosto de uma pessoa específica. Após essa ferramenta detectaruma face, podem ser colhidas informações como a posição dos olhos e da boca. A partirdele também pode-se rastrear a posição de uma face em um vídeo. Na FIG. 4.11 pode-sever um exemplo dessa ferramenta em ação.

FIG. 4.11: Core Image identifica limites das faces em uma imagem [44]

Essa API para detecção de faces é fácil de ser utilizada. As duas classes principais sãoa CIDetector [42] e a CIFaceFeature [45]. A primeira é responsável por analisar uma ima-gem e retornar uma coleção de objetos da segunda descrevendo a(s) face(s) encontrada(s).Existem dois níveis de precisão para o algoritmo: CIDetectorAccuracyLow e CIDetecto-rAccuracyHigh. O segundo nível produz resultados bem mais precisos, porém requer maistempo para realizar a análise. Em situações de análise em tempo real (detecção de facesem um vídeo) a opção de baixa precisão produz resultados bastante aceitáveis.

41

FIG. 4.12: Comparativo da precisão do algoritmo de detecção de face [43]

A FIG. 4.12 mostra um exemplo da API de detecção de faces em ação. As imagensilustram a diferença entre as configurações de baixa e alta precisão. A localização dascaracterísticas detectadas não são muito diferentes entre as duas imagens, porém o tempopara o algoritmo de alta precisão rodar é bem mais demorado que o de baixa precisão. Oaplicativo utilizado para gerar esse exemplo pode ser encontrado em [43].

A Apple disponibiliza uma aplicação básica para desenvolvedores chamada SquareCam[46] que permite realizar a detecção de face utilizando o CIDetector [42] em tempo realatravés de imagem ou vídeo capturado pela câmera, exibindo um quadrado vermelho emtorno da face. Outro exemplo de utilização dessa ferramenta pode ser encontrado em [47],no qual foi criada uma classe que pode ser facilmente adicionada a um projeto e utilizadapara recuperar as informações das características da face: EVFaceTracker.

4.7.2 TRANSLATIONMANAGER

A classe TranslationManager abstrai as ações de detecção de faces do resto da aplica-ção. Ela é responsável por iniciar a captura de vídeo em tempo real a partir da câmerafrontal do dispositivo. Utilizando os frames capturados, a classe CIDetector realiza adetecção de face e retorna as informações relevantes para utilização na aplicação. Osdois principais métodos da classe TranslationManager são: getTranslation e getProxi-mityFactor. O método getTranslation retorna um CGPoint, ou seja, um par ordenadoque representa o posicionamento da face em relação ao centro da tela do dispositivo.O método getProximityFactor retorna o valor da distância da face ao plano da tela dodispositivo. Esse resultado é estimado a partir do tamanho do retângulo que demarcaa estimativa de posição da face na imagem (FIG. 4.11 e FIG. 4.12). Se o retângulo forgrande, então o rosto está próximo do dispositivo e se for pequeno, o rosto está longe.Esses valores são normalizados e, portanto, variam dentro de um intervalo que vai de -1a 1. Os limites de intervalo foram determinados experimentalmente.

42

Através da informação da distância do rosto, pode-se criar recursos de visualizaçãomais interativos. Por exemplo, quando o usuário aproximar o rosto do dispositivo, podeser aplicado um zoom na imagem visualizada e quando o usuário afastar seu rosto, o zoomé desfeito. Na FIG. 4.13 é possível visualizar o exemplo citado.

FIG. 4.13: Zoom a partir da aproximação da face ao dispositivo [10]

Utilizando a informação do posicionamento do rosto, pode-se adicionar efeitos de pa-ralaxe na visualização das camadas, aumentado o grau de imersão na cena. Na FIG. 4.14é demonstrado o efeito de paralaxe na exploração da cena.

FIG. 4.14: Efeito de paralaxe pelo posicionamento da face em relação ao dispositivo [10]

4.8 CICLO DE RENDERIZAÇÃO

Com toda esta estrutura construída, devemos definir uma forma de gerenciar esseselementos para desenhar a cena de forma coerente. O ciclo da aplicação funciona basica-mente em duas etapas: atualização e desenho. Estas duas etapas são coordenadas pelocontrolador de cena (SceneViewController).

Na etapa de atualização, percorre-se o grafo de cena atualizando a matriz de trans-formação global de cada nó, assim como a inversa desta matriz. Atualiza-se também aview matrix com o a matriz de orientação obtida com a API do CoreMotion. Cada nódesenhável percorrido é adicionado a uma lista ordenada pelo raio da camada em que elese encontra, visando facilitar a etapa de desenho.

A atualização da model matrix ocorre antes da renderização de cada objeto da cena.Durante o percurso do grafo de cena, solicita-se a cada nó desenhável do grafo a suamatriz de transformação global, isto é, como a sua pose e escala estão definidos emrelação ao referencial da cena, que leva em conta todos os elementos. Esta transformaçãocorresponderá à model matrix neste ponto específico.

43

A atualização da view matrix ocorre segundo o descrito na subseção 4.6.1 para o blocode rotação, utilizando os dados de translação e proximidade do TranslationManager paraatualizar o bloco de translação e induzir uma perspectiva dinâmica.

Em geral, a matriz de projeção permanece constante durante a maior parte da execuçãodo programa. Caso fosse necessário alterar as distâncias dos planos near e far, redefiniro campo de visão para realizar um zoom ou alterar qualquer outro parâmetro instrínsecoda câmera, seria necessário alterar a matriz de projeção.

Na etapa de desenho, o controlador de cena percorre sequencialmente a lista ordenadade elementos desenháveis, verifica se há necessidade de atualizar o programa de shader,baseado nas propriedades do objeto a ser desenhado, e o atualiza se for necessário. Cadaelemento é desenhado do mais afastado para o mais próximo à câmera, conforme o Algo-ritmo do Pintor [48, 49]. O fato de as camadas possuírem uma ordem com intervalos bemdefinidos evita ciclos no grafo de oclusão da cena [48].

As chamadas à API da OpenGL bem como os dados necessários para as operaçõesde desenho estão encapsulados na classe Mesh (malha). Todo nó desenhável possui umareferência a uma instância de Mesh, que responde por delegação às mensagens de desenho.

FIG. 4.15: Projeção da panorama

Aplicando-se as transformações de câmera descritas e após a projeção da imagem sobreo interior da malha poligonal de uma esfera, pode-se visualizar a cena fotografada semas distorções características do panorama equirretangular, dentro de um campo de visãorestrito (FIG. 4.15) . Todas as transformações citadas são aplicadas na ordem em queforam apresentadas a cada elemento candidato a ser desenhado. A gerência das matrizesé feita por uma instância de câmera, porém a aplicação das transformações aos vértices éfeita no vertex shader.

44

5 COMPONENTES DE INTERAÇÃO E MICROLOCALIZAÇÃO

5.1 INTERAÇÃO

Esta seção trata das estratégias adotadas para a implementação dos componentesnecessários para a criação de aplicações interativas com este framework. A interação seráfeita pela tela sensível ao toque dos dispositivos. O sistema iOS já fornece o frameworkCocoaTouch [50] para tratar, dentre outras coisas, do reconhecimento de toques e gestossobre a tela dos aparelhos. Esta etapa, portanto, consiste em como utilizar este frameworkpara gerar interações coerentes dentro do ambiente gráfico 3D proposto. Para isso, énecessário identificar elementos da cena e permitir a exibição de conteúdos baseados noque for identificado.

5.1.1 RAY PICKING

O CocoaTouch nos permite identificar que ponto sobre a superfície da tela foi tocadopelo usuário. No entanto, para que o usuário possa interagir com elementos de umacena tridimensional, é preciso identificar que ponto dentro do ambiente 3D foi tocado. Atécnica de ray picking [52] permite que essa identificação seja feita baseada em traçadode raios. Nesta abordagem, quando o usuário toca em algum ponto da tela, um raio élançado na cena e, então, calcula-se qual objeto foi interceptado pelo raio, gerando umaresposta do sistema.

Um raio é uma estrutura representada por dois vetores do espaço R3, um vetor deter-mina sua origem e o outro a sua direção. Para fins de operações matemáticas, uma direçãoé tratada como um vetor especial, pois deve ser invariante a transformações de translação.A classe Ray encapsula o estado do raio e suas operações segundo esta modelagem.

Para que os raios sejam lançados na cena coerentemente, algumas etapas de trans-formações devem ser seguidas. Devemos determinar a que plano, mais precisamente, aque região plana, a tela do dispositivo corresponde dentro do espaço da cena. Ou seja,devemos mapear a tela do aparelho em uma região plana dentro da cena para determinaro ponto origem e a direção do raio a ser emitido, como descrito a seguir. Pelo modelo decâmera virtual, podemos considerar que o raio tem origem sobre o plano near da pirâmidevisão. Conhecendo a view matrix, podemos deteminar a orientação da câmera e obter osvetores que representam as direções horizontal, e vertical de visualização.

0

@H

x

Vx

Lx

Hy

Vy

Ly

Hz

Vz

Lz

1

A

FIG. 5.1: Vetores de Rotação da Câmera

45

Precisamos escrever o referencial da câmera nas coordenadas do referencial global paraobter cada um destes vetores, o que equivale a inverter a rotação da view matrix. A ope-ração de inversão de uma matriz normalmente é uma operação computacionalmente cara,porém como o bloco R é uma matriz de rotação, sua matriz inversa é igual à sua matriztransposta, que é fácil de computar. A figura FIG. 5.1 ilustra a matriz R, bloco de rotaçãoda view matrix, e as coordenadas dos vetores H, V e L, das direções horizontal, verticale de observação (look) respectivamente. Assim, as instâncias de câmera são capazes deresponder a mensagens solicitando as direções horizontal, vertical e de observação comovetores normalizados do espaço R3.

FIG. 5.2: Sistema de Coordenadas nativo da tela [51]

As coordenadas absolutas do ponto podem ser obtidas pela API do CocoaTouch naforma de par ordenado (X, Y) , assumindo como origem o ponto superior esquerdo datela (FIG. 5.2). Para trabalhar de forma independente do tamanho da tela, adota-se umreferencial normalizado em que a origem se encontra no centro da tela e o canto superiordireito tem coordenanda (1,1) Duas transformações, portanto, devem ser realizadas: umatranslação da origem para o centro da tela e uma rotação dos eixos para que, independenteda orientação do aparelho, tenhamos o eixo Y alinhado com a direção vertical da câmera.Para normalizar as coordenadas X e Y, basta dividi-las, respectivamente, pela metade dosvalores absolutos máximos nas direções horizontal e vertical.

Ao concluir estas etapas, a origem do raio na cena será dada pela equação 1:

Raioorigem

= posCamera+ dirObservacao ⇤ near+ dirHorizontal ⇤X + dirV ertical ⇤ YEquação 1

Como o observador é sempre colocado no cenro de projeção da panorama, que coincidecom a origem do sistema de coordenadas, a equação 5.1.1 se reduz a:

46

Raioorigem

= dirObservacao ⇤ near + dirHorizontal ⇤X + dirV ertical ⇤ YEquação 2

Em que posCamera é o vetor que representa a posição da câmera na cena; view é ovetor que representa a direção de observação da câmera; near é a distância entre a câmerae o plano de recorte mais próximo do observador; dirHorizontal é o vetor que representaa direção horizontal, com magnitude igual a metade do comprimento total do plano nestadireção; dirVertical é o vetor que representa a direção vertical, com magnitude igual àmetade do comprimento total do plano nesta direção; e X e Y são os valores normalizadosque representam a posição do toque do usuário na tela.

A direção do raio é simplesmente dada pela subtração entre o vetor que representasua origem e o vetor que representa a posição da câmera, conforme a equação 3:

Raiodirecao

= Raioorigem

� posCamera

Equação 3

FIG. 5.3: Ray Picking [52]

Todo objeto passível de interação deve, portanto, implementar um método que recebeum raio e calcula se há intersecção com este raio. Para isso, foi criada a classe Interactable,que funciona como um protocolo, mas implementado com herança múltipla, visto que essacamada do framework foi desenvolvida em C++.

A interseção é calculada com base na geometria do objeto, sendo necessário determi-nar se existe um parâmetro real que seja solução de um sistema de equações resultanteda substituição da equação paramétrica do raio na equação implícita da superfície que

47

representa o objeto [33]. Superfícies simples como uma esfera ou um cubo possuem formassimples de se calcular a interseção, porém superfícies de geometria mais complexa podemtornar esta tarefa muito difícil. Algumas estratégias de aproximação podem ser utilizadaspara simplificar o tratamento de superfícies de geometria complexa. A mais comum delasé a de não testar a interseção com o objeto, mas sim com sua caixa envolvente ”boundingbox ” [33], que seria o paralelepípedo de menor volume que contém o objeto.

Para facilitar este cálculo, a construção dos objetos 3D do sistema segue um padrãode modelagem por primitivas geométricas [33], em que cada primitiva é modelada mate-maticamente por equações simples, ficando a sua pose no espaço determinada por umatransformação projetiva (matriz de transformação global). Portanto, para determinar seo raio dado intersecta ou não um determinado objeto, primeiramente, é necessário aplicara transformação inversa do objeto em relação ao mundo sobre o raio, permitindo que elesestejam no mesmo referencial .

5.1.2 CAMADA DE COLISÃO

Agora que é possível determinar um ponto no espaço onde o usuário tenha realizadoum toque, é necessário um mecanismo para determinar uma região interativa da cena,como um dado objeto, por exemplo. Uma possível abordagem para esse problema seriautilizar billboards. Billboards são polígonos que estão sempre voltados para a câmerae que podem simular objetos tridimensionais, para mais detalhes, ver o apêndice B. Omecanismo consistiria em posicionar polígonos transparentes sobre as regiões interativase testar a interseção dos raios com cada polígono para determinar que resposta deve serdada ao usuário.

Contudo, para este trabalho, resolvemos implementar uma solução baseada na utili-zação de uma camada especial apenas para a interação. A implementação desta soluçãoé mais simples e apresenta uma complexidade maior em memória, porém pode ser maiseficiente em processamento, dependendo da quantidade de regiões interativas. Esta pro-posta consiste em produzir uma nova imagem a partir da imagem panorâmica que sepretende visualizar, de tal forma que essa nova imagem contenha apenas as regiões inte-rativas, cada uma pintada em uma única cor distinta. Para cada região, atribui-se umaidentificação baseada em sua cor. Quando uma interação por toque ocorrer na tela, testa-se a interseção do raio lançado apenas com a camada de interação e a resposta ao usuárioé determinada pela identificação (de cor) da região onde a interseção tenha ocorrido.

48

FIG. 5.4: Camada de Interação

A FIG. 5.4 apresenta um exemplo de imagem para a camada de interação. Quatroitens foram marcados como interativos, a porta em azul, um quadro em verde, a televisãoem vermelho e o ornamento sobre a mesa de centro foi marcado em roxo. O restante daimagem é apresentado em preto e branco apenas para que o leitor possa fazer uma com-paração com a FIG. 2.2, imagem original. A cor das demais regiões não é relevante desdeque seja diferente das cores escolhidas para cada região interativa, contudo recomenda-seque elas sejam deixadas completamente em uma única cor, por exemplo o preto, para quecompressão do arquivo seja mais eficiente.

A vantagem deste mecanismo é que calcula-se apenas uma interseção. Por outro lado,utiliza-se uma imagem completa, armazenando-se em memória dados sobre regiões ondenão há interações disponíveis. Para economizar espaço de memória, a imagem utilizadana camada de interação tem uma resolução 16 vezes menor que as imagens utilizadas nasdemais camadas, que são desenhadas.

A camada de interação não é um objeto desenhável em tela, sendo um objeto estáticona estrutura de uma panorama com camadas.

5.1.3 EXIBIÇÃO DE CONTEÚDO

Após perceber um toque sobre a tela do dispositivo, o controlador da cena calcula eencaminha um raio para a cena, que o direciona para cada objeto interativo do grafo decena. Ao receber um raio, uma panorama com camadas encaminha-o para a sua camadade interação, que computa o ponto de interseção do raio e, a partir dele, reconstrói acoordenada de textura correspondente e interpola os pixels da imagem demarcada parainteração, a fim de determinar a cor da região intersectada pelo raio. A posição e a corda região intersectada são retornados para o controlador de cena dentro de uma estruturachama iNode (index node).

49

Determinar que ação será executada após a identificação de um toque sobre umaregião interativa é um problema a ser solucionado pela implementação de um ambiente deautoria. Utilizando apenas os componentes implementados neste framework, esta decisãoé deixada exclusivamente sobre o desenvolvedor que o utilizará como uma das ferramentasde sua aplicação. No entanto, disponibiliza-se integrada ao framework uma solução parasimples exibição de conteúdo estático em forma de imagem e texto, como ilustrado naFIG. 5.5.

FIG. 5.5: Conteúdo exibido após interação com televisão

Para que uma aplicação funcione com esta modelagem, é necessário prover ao controla-dor de cena um mapeamento entre o conteúdo que se deseja exibir e as cores dos elementosinterativos. Este mapeamento é feito por meio de unidades de conteúdo (ContentUnit),objetos que detém um vetor do R3 com as coordenadas RGB da cor e a referência a umarquivo de texto e outro de imagem que irão compor o conteúdo apresentado ao usuário.

5.2 MICROLOCALIZAÇÃO

A fim de possibilitar a interação entre um ibeacon e um dispositivo com tecnologiaBLE a Apple introduziu novos recursos no seu framework Core Location [53] que, essen-cialmente, permite ao usuário determinar a localização atual de seu dispositivo utilizandoo hardware disponível. Através da implementação de suas classes e protocolos é possíveldefinir regiões geográficas, monitorar quando um usuário as atravessa e enviar notificaçõespara seu dispositivo.

Vale ressaltar que esse framework já existe há alguns anos e vem sendo implementado,por exemplo, aliado ao GPS. A mudança recente foi apenas a adição de algumas classes

50

para tratar dos emissores de Bluetooth Low Energy. Através desses recursos posterior-mente introduzidos pela Apple é possível não só monitorar iBeacons, mas também dispo-sitivos que estejam atuando como um. Utilizando recursos do Core Bluetooth Framework[54] é possível desenvolver aplicações de tal tipo para aparelhos com iOS e Macbooks,desde que os mesmos possuam hardware com suporte para Bluetooth 4.0.

A seguir serão detalhadas as três classes desse framework implementadas nesse tra-balho assim como a classe BeaconManager criada a fim de auxiliar a interação entre osdispositivos através da tecnologia BLE.

5.2.1 CLBEACON

CLBeacon [55] é a classe do framework Core Location [53] que representa o beaconencontrado durante o monitoramento da região. Instâncias dessa classe não são criadasdiretamente. Um objeto da classe CLLocationManager [56] é responsável por reportar osbeacons encontrados e suas informações podem ser utilizadas para sua identificação.

Possui seis propriedades que permitem identificar e localizar cada dispositivo, sendoelas:

• ProximityUUID : representa o UUID do beacon ou de um grupo de beacons;• Major e Minor : valores opcionais utilizados para auxiliar na identificação dos be-

acons, geralmente utilizado para separar um grupo de beacons representado pelo mesmoUUID em subgrupos menores;

• Accuracy : representa a acurácia do valor da proximidade, medido em metros;• Proximity : representa a distância relativa ao beacon, possui quatro regiões pré-

definidas que podem ser recebidas como valores de retorno (unknown, immediate, near,far);

• RSSI: representa a intensidade do sinal recebido, medido em decibéis.

5.2.2 CLBEACONREGION

Um objeto da classe CLBeaconRegion [57] define uma região baseada na proximidadecom um dispositivo emissor de sinal Bluetooth, essa região estará basicamente buscandodispositivos cuja identificação coincida com a informação fornecida pelo usuário.

Essa identificação funciona da seguinte maneira: cada região definida possui, assimcomo os beacons, um UUID, um major e um minor e utilizará essas propriedades paraverificar se o aparelho encontrado está entre os que devem ser monitorados.

A priori, não é de interesse do aplicativo desse trabalho enviar notificações para ousuário de acordo com seu posicionamento relativo ao emissor de sinal bluetooth, masapenas determinar sua localização. Todavia, as notificações são vistas na verdade como ogrande avanço obtido com os beacons quando comparado com outros tipos de tecnologias,dado que mesmo com a aplicação estando em background é possível que um usuário as

51

receba. Visto isso, foi implementado apenas o envio dessas notificações através do métodosendNotificationsForRegion. Caso no futuro seja de interesse utilizá-las, é necessário ape-nas desenvolver a parte da aplicação na qual essas mensagens são definidas e introduzidaspelo usuário juntamente com cada região.

5.2.3 CLLOCATIONMANAGER

A classe CLLocationManager define uma interface para configurar a entrega de eventosrelacionados à aplicação. Através da implementação de uma instância dessa classe, é pos-sível controlar quando e quais tipos de notificações deve-se receber e também informaçõesa respeito da localização atual do dispositivo.

Existem dois métodos distintos para o gerenciamento da localização, o primeiro deles,startMonitoringForRegion permite determinar quando um dispositivo entra ou sai da vi-zinhança de um beacon. Após registradas as regiões a serem monitoradas, serão recebidoscall-backs constantes de acordo com os métodos do protoclo CLLocationManagerDelegate[58] no qual será possível determinar qual o estado efetivo do dispositivo monitorado.Para interromper o monitoramento, utiliza-se stopMonitoringForRegion.

Nessa aplicação, para o controle de localização do beacon, o método desse protocoloque é implementado é o didDetermineState. Existem três tipos de valores de retornosdistintos possíveis o primeiro, CLRegionStateUnknown, utilizado quando o estado da re-gião ainda não é determinado. CLRegionStateInside e CLRegionStateOutside quando odispositivo está, respectivamente, dentro ou fora da CLBeaconRegion especificada.

Apenas quando determinado que o beacon está dentro da região monitorada é possívelutilizar o segundo método de gerenciamento, startRangingBeaconsInRegion. Através deleé possível receber notificações quando a distância relativa entre os dispositivos, com issoobtém-se informações mais detalhadas e não apenas a simples inferência se o beacon estádentro ou fora da área de atuação. Para o presente trabalho esse último método é essencial,dado que ter informações acerca da proximidade em relação aos beacons é primordial paraa aplicação desenvolvida. Tais dados são recebidos através de três propriedades diferentes:proximity, accuracy e RSSI. Analogamente ao anterior, para interromper o rastreamento,utiliza-se stopRangingBeaconsInRegion.

5.2.4 BEACONMANAGER

Essa classe foi criada a fim de permitir que o componente de visualização do aplicativoesteja sempre atualizado em relação a qual dispositivo emissor deve ser considerado comoreferência, e dessa forma garantir uma melhor experiência ao usuário. Ela atua comoum mediador entre as demais classes necessárias para a correta utilização dos beacons emuma aplicação, sendo, portanto, a interface entre os beacons e os demais componentes doframework.

52

Para tanto, foi modelada uma máquina de estados finitos com N+1 estados, em queN é o número de beacons que estão sendo monitorados em um determinado instante. Aspassagens de um estado para outro acontecem de acordo com a força do sinal recebido.Na FIG. 5.6 temos um exemplo de diagrama para três estados.

FIG. 5.6: Modelagem da máquina de estados finitos

O estado S0 é aquele no qual não há um beacon de referência, enquanto nesse estadomonitora-se a área ao redor do usuário a fim de encontrar algum dispositivo dentro daregião de ativação, que para o caso de teste deste trabalho foi definida como a área com-preendida pelas regiões Immediate e Near pré-definidas pelo padrão da Apple. Enquantoem um estado diferente de S0, monitora-se o sinal recebido do beacon de referência eapenas quando o beacon estiver fora da região de ativação pré-estabelecida, retorna-se aoestado S0.

Através do método startLookingForReferenceBeacons, implementado de acordo com amodelagem descrita acima, o aplicativo recebe informações a respeito da distância relativaentre o usuário e todos os beacons que estão sendo monitorados. A partir desses dados,determina-se se algum dos emissores está próximo o suficiente do usuário a tal ponto quea experiência com a realidade aumentada seja positiva, isto é, se algum dos emissores estádentro da região de ativação. Caso encontre algum nessa situação, realiza-se a identificaçãodo mesmo. Foi implementado também o stopLookingForReferenceBeacons, método quepermite ao aplicativo parar de receber as informações supracitadas.

A fim de possibilitar que o componente que trata a visualização esteja a par dessasinformações, é implementado o protocolo BeaconClient que o permite, através do Beacon-DidChangeID receber notificações sempre que o valor de referência for atualizado. Dessamaneira, ele terá a informação necessária para decidir qual panorama deve ser exibidopela aplicação. Para o caso de encontrar-se no estado S0, isto é, sem nenhum beacon de

53

referência, será exibido, no caso de testes elaborado, uma planta baixa com a disposiçãodos emissores e dos objetos com que a pessoa poderá interagir, a fim de aprimorar aexperiência do usuário.

54

6 O FRAMEWORK

O framework projetado constitui uma infraestrutura para o desenvolvimento de apli-cações móveis baseadas em imagens panorâmicas e que queiram fazer uso dos sensoresde atitude, da câmera e da tela sensível ao toque para interação e ou visualização coma cena proposta. O framework não trata, portanto, do domínio da aplicação, sendo estadefinição de responsabilidade do decisor do projeto. Embora a proposta de imagens pa-norâmicas em dispositivos móveis possa parecer bastante específica, há uma variedade deaplicações que podem ser desenvolvidas sobre esta infraestrutura, tais como games, guiasvirtuais para ambientes in-doors como hotéis, restaurantes e museus, além de simulado-res. Notavelmente, aplicações centradas em realidade aumentada indireta podem fazeruso de mais componentes do framework e se beneficiarem da microlocalização para tornara experiência mais agradável, principalmente em ambientes fechados.

O framework foi desenvolvido para a plataforma iOS com alguns componentes escritosem Objective-C e outros em C++. A integração entre Objective-C e C++ pode serrealizada por meio do dialeto Objective-C++, em que os arquivos de implementação doObjective-C deixam de ter a extensão ”.m” e assumem a extensão ”.mm”. Dessa forma, épossível instanciar objetos de classes escritas em C++ e fazê-los interagir com o restantedo programa com algumas restrições.

A nomenclatura dos componentes segue um padrão em que antes do nome de cadaclasse adiciona-se duas letras para indicar o framework de origem, servindo também comouma forma de modularização em namespace. Este padrão é adotado por diversos fra-meworks comerciais, inclusive os próprios frameworks disponíveis por padrão no ambientede desenvolvimento da Apple, tais como Core Motion (CM), Core Location (CL) e CoreFoundation (CF). As iniciais escolhidas foram LP (Layered Panorama) por representarpanorama com camada.

O framework é distribuído na forma de uma biblioteca estática (static library), sendonecessário a inclusão do header ”Layered_Panorama_Framework.h” nos arquivos que uti-lizem seus componentes.

6.1 ESTRUTURA DOS COMPONENTES

Nosso objetivo é prover ao usuário do framework os componentes necessários paraque seja possível descrever uma cena utilizando uma imagem omnidirecional, especificaráreas interativas dentro desta cena e responder às interações do usuário com conteúdoespecífico à cena em questão. Para atingir este objetivo, o framework possui componentesde modelagem e visualização, de interação e de microlocalização. A FIG. 6.1 ilustra orelacionamento entre os componentes.

55

FIG. 6.1: Relação entre os componentes

O controlador de cena (SceneViewController) é responsável por gerenciar os eventosque ocorrem na tela do dispositivo, como toques e gestos, além de gerenciar o ciclo derenderização da OpenGL, desde a configuração de estados na inicialização, passando pelosciclos de atualização e de desenho de cada quadro em tela e também pela liberaçãodos recursos de hardware nos momentos em que o aplicativo é colocado em segundoplano ou finalizado. É o controlador de cena que gerencia a interação do usuário com acena, gerando os raios, recebendo as respostas de intersecções e utilizando as unidades deconteúdo para acionar outros gerenciadores.

O controlador de cena, portanto, age como mediador [34] de vários subsistemas quedevem ser integrados. Os componentes de modelagem e visualização foram implementa-dos na linguagem C++, por questões de portabilidade e de eficiência, enquanto os demaiscomponentes foram implementados em Objective-C, linguagem padrão para a programa-ção em iOS. Portanto, com essa abordagem, evita-se a propagação de arquivos ”.mm”e mantém-se independentes os componentes escritos em linguagens diferentes, sendo ocontrolador de cena o único componente em Objective-C++.

O gerenciador de sensores (SensorManager), monitora os dados dos sensores de atitudeque são recebidos já de forma integrada através da API do framework Core Motion, e osdados da detecção de faces, tratados pelo gerenciador de translação (TranslationManager).Este componente é responsável por integrar estas fontes de informações sobre a direção deobservação do usuário e calcular uma matriz que será utilizada pela câmera como a viewmatrix. Durante o ciclo de renderização, o controlador de cena solicita a transformação

56

da view matrix ao gerenciador de sensores antes de percorrer o grafo de cena e, então,atualiza a câmera.

O gerenciador de beacons (BeaconManager) é um objeto singular e compartilhado portoda a aplicação, mesmo quando a cena 3D não é a tela corrente em exibição. Esta carac-terística se deve ao fato de que aplicações que utilizam beacons o fazem para determinarqual conteúdo será exibido e como ele será exibido, podendo a situação ser modificadaconstantemente de acordo com a localização do usuário no ambiente.

O controlador de cena possui uma referência para a cena corrente. Todos os elementosque serão desenhados na tela são nós descendentes da cena corrente. Portanto, para secomunicar com algum elemento da cena, lançando um raio, por exemplo, o controladorde cena tem que encaminhar uma requisição para a cena e aguardar a resposta. A cenarealiza o redirecionamento dessa requisição enquanto for necessário, segundo o padrão deprojeto Cadeia de Responsabilidade (Chain of Responsability) [34] e, quando obtém umaresposta, ela finalmente a repassa ao controlador de cena.

6.2 UTILIZAÇÃO E ESPECIALIZAÇÕES

O gerenciador de beacons e o gerenciador de translação fazem parte da estrutura fixado framework, de forma que não há necessidade de especializá-los para utilizá-los. Estescomponentes podem ter o seu comportamento configurado pelo cliente e se comunicamcom ele por meio de protocolos.

Dentro do grafo de cena há bastante espaço para adições personalizadas pelo usuário.O framework fornece apenas elementos básicos para manter estados e realizar operaçõessobre camadas de panoramas, tais como uma malha poligonal de esfera, um nó desenhávelde uma esfera ou uma panorama com camadas. Caso seja necessário, o usuário podeimplementar outras formas geométricas derivando uma malha a partir da classe Meshe um nó a partir da classe DrawableNode. Ressalta-se que novos elementos interativosdevem herdar também da classe Interactable e implementar um método para cálculo deinterseções com um raio.

Uma cena é um componente que deve ser especializado em quaquer aplicação. Porconta disso, a classe LPScene foi transformada em uma classe abstrata. Dessa forma,é necessário escrever uma especialização de LPScene para cada aplicação, pois é nessaclasse que define-se os componentes da cena e o estado em que eles serão inicializados noprograma. Definir a estrutura de uma cena e organizar todo o conteúdo para visualizaçãoou interação pode ser uma tarefa custosa de se realizar manualmente. A criação de umambiente de autoria para ser integrado ao framework poderia solucionar este probemacomo será abordado na seção 6.4.

A diferença da utilização do framework para aplicações em realidade aumentada eaplicações que não centradas em realidade aumentada está, basicamente, na navegação

57

dentro da cena e entre as cenas geradas para a aplicação. Em uma aplicação de realidadeaumentada, é necessário que o usuário esteja presente fisicamente no ambiente em que asinterações serão propostas. Dessa forma, há determinados conteúdos que fazem sentidoserem exibidos quando o usuário se localiza próximo a determinados pontos, que podemser identificados por beacons, e há outros conteúdos que devem ser omitidos até o mo-mento oportuno para que não haja prejuízo da experiência. Naturalmente, aplicações derealidade aumentada utilizam mais componentes do framework, relizando mais trabalhode processamento em tempo real.

Em uma aplicação cujo objetivo não seja alcançado somente por meio da realidadeaumentada, como, por exemplo um jogo ou um aplicativo utilizado para promover ouvender um espaço comercial ou residencial, pode-se permitir ao usuário ter acesso aomesmo conteúdo em uma cena independente de onde ele se encontre fisicamente. Váriascenas podem ser interligadas de modo a permitir a navegação do usuário entre elas.

6.2.1 APLICAÇÃO DE TESTE

Para teste e validação do framework, foi implementada uma aplicação que fizesse usode todos os componentes disponibilizados. A aplicação foi testada em um iPad Mini comsistema operacional iOS 7.1.2 e um iPhone 5 com iOS 8.0.2. A imagem da FIG. 2.2 foiutilizada como cena principal da aplicação, sendo segmentada em 3 camadas conforme aFIG. 4.4, a FIG. 4.5 e a FIG. 4.6 para compor a representação de entrada para a aplicação.

Esta aplicação de teste foi projetada para simular um possível uso em uma exposiçãoem ambiente fechado. Ao abrir a aplicação, o usuário é apresentado a uma planta baixada sala (FIG. 6.2), onde ele pode verificar quais são os objetos interativos (marcados porum contorno colorido), e onde eles se localizam. Nesta planta também é possível localizarum dispositivo beacon, marcado com um ”B” dentro de uma circunferência azul.

FIG. 6.2: Planta baixa da cena

58

O beacon está localizado próximo ao ponto de onde a panorama foi capturada. Ao seaproximar da região de influência do beacon, a aplicação o identifica e realiza a transiçãoda planta baixa da sala para uma visualização omnidirecional da sala, atualizada segundoos dados dos sensores de atitude. Os objetos interativos foram marcados na cena comcontornos coloridos, conforme a FIG. 6.3, de maneira similar à apresentada na plantabaixa.

FIG. 6.3: Marcação sobre quadro interativo

Ao tocar sobre um objeto interativo, a aplicação executa uma resposta ao usuário. Estaresposta pode ser implementada de várias formas diferentes pelo usuário do framework.Uma possível opção de resposta seria utilizar a solução proposta da seção 5.1.3 e exibiruma tela informativa sobre o objeto tocado como a FIG. 5.5 e a FIG. 6.4. Nesta aplicaçãode teste, para toque sobre a porta, implementou-se uma transição para uma outra cena,um corredor externo à sala como ilustrado na FIG. 6.5.

59

FIG. 6.4: Tela informativa sobre o quadro

(a) Porta interativa (b) Corredor externo

FIG. 6.5: Interação com a porta da cena

A segmentação da cena em 3 camadas possibilitou a exploração do efeito de paralaxeque pôde ser melhor notado ao se observar na direção da mesa de centro, das extremidadesdo sofá, ou do rack sobre o qual a televisão se encontra apoiada.

6.3 DIFICULDADES ENCONTRADAS

6.3.1 RUÍDOS NO SINAL PROVENIENTE DA DETECÇÃO DE FACES

Na perspectiva dinâmica, algumas dificuldades foram detectadas referente à detecçãode faces. Foi percebida uma pequena latência no tempo de resposta, porém não foi pre-judicial para a experiência do usuário. Além disso, os sinais recebidos possuíam ruídos

60

que faziam as imagens oscilarem muito, causando uma impressão não natural ao obser-vador. Esses ruídos podem ser devidos à sensibilidade dos sensores, nos quais pequenasmudanças no formato do rosto e da iluminação podem produzir sinais inesperados. Umaoutra possível causa está relacionada ao relacionamento entre as threads da aplicação,visto que muitos recursos estão sendo utilizados ao mesmo tempo e, possivelmente, deforma não otimizada. Para tratar adequadamente este problema, seria necessário umamaior investigação quanto à utilização dos recursos do hardware e quanto a ajustes derelacionamento entre as threads. Esse problema pôde ser contornado através do uso dealgoritmos de filtragem temporal, ainda que ao preço de mais latência.

O algoritmo escolhido para solucionar o problema do ruído foi o filtro de média móvel[59], o qual é obtido calculando-se a média de um conjunto de valores, sempre descartandoo valor mais antigo e adicionando o valor mais recente a cada iteração. Quando maiora janela escolhida, número de valores que irão compor a média, mais suave será a varia-ção dos valores recebido dos sensores, porém mais tempo de processamento é necessário.Experimentalmente foi detectado que aplicando um valor de janela 25 houve uma suavi-zação considerável do sinal e não prejudicou a experiência na visualização da paralaxe nacena. Existem outros filtros que poderiam produzir resultados melhores, porém o filtro damédia móvel é de rápida e fácil implementação e proporcionou resultados aceitáveis paraos casos de teste executados. O filtro foi modularizado de forma a facilitar a substituiçãoquando necessário.

6.3.2 DESLIZAMENTO APARENTE DE OBJETOS

Um outro problema observado com o recurso de perspectiva dinâmica foi o desliza-mento dos objetos por sobre o chão quando tentamos observá-los sobre outra perspectiva.Este efeito pode ser observado ao compararmos as posições dos pés da mesa na FIG. 6.6ae na FIG. 6.6b. Isto se deve à modelagem de esferas concêntricas escolhida para as ca-madas. Nesta modelagem, não estamos considerando as profundidades dos pontos dacena, então as camadas definem apenas uma ordem de prioridade para desenho. Destaforma, objetos que se encontram em uma mesma camada encontram-se a uma mesmadistância do observador e objetos que estejam em camadas diferentes encontram-se emprofundidades diferentes, mesmo que eles tenham alguma superfície em comum.

61

(a) (b)

FIG. 6.6: Deslizamento aparente dos objetos sobre o chão

Esse resultado mostra que para cenas onde há um acoplamento entre as camadas, istoé, em que elementos de camadas diferentes estão dispostos de forma a encostar uns nosoutros, um modelo mais elaborado, que considere a profundidade dos pontos é necessário.Mesmo que a profundidade real de cada região da cena não possa ser recuperada, é precisoque haja coerência entre as profundidades de objetos adjacentes.

Em particular, é natural que em praticamente qualquer cena haja objetos apoiadossobre o chão. Na FIG. 2.2, por exemplo, há um sofá, uma mesa, dentre outros móveis,que estão apoiados sobre o chão da sala. O trabalho [21] utiliza imagens panorâmicas commapas de profundidade para reconstruir um modelo do ambiente e realizar experimentosde realidade aumentada, uma representação similar poderia ser utilizada.

6.4 AMBIENTE DE AUTORIA

Este trabalho detém-se à implementação de cada componente apresentado para esteframework. Contudo, para um uso efetivo do framework na concepção e disseminação deaplicações móveis, é desejável que hava um esforço na implementação e integração de umambiente de autoria para facilitar a geração e a organização de conteúdo em represen-tações compatíveis com o que foi proposto. Assim, desenvolvedores sem conhecimentosespecíficos sobre os conceitos apresentados neste trabalho poderiam construir aplicaçõescompletas mais facilmente.

Neste projeto, para a relização de testes dos componentes do framework, realizou-se aautoria manualmente, isto é, codificando-se cada elemento necessário para a composição

62

de uma cena. Após esse processo, levantou-se as seguintes necessidades para um ambientede autoria:

1. Segmentação de uma imagem panorâmica em camadas e definição da prioridadeentre as camadas.

2. Definição e marcação dos pontos interativos da cena.

3. Carregamento, inserção e controle sobre o posicionamento de outros modelos tridi-mensionais na cena.

4. Interfaces de usuário para geração e exibição de conteúdo quando há interação dousuário com a cena.

5. Cadastramento dos beacons e dos eventos iniciados em cada região de microlocali-zação.

A construção de um ambiente de autoria, portanto, passa pela automatização de algunsprocessos como o cadastramento dos beacons para microlocalização e a definição de regiõesinterativas, e também pelo desenvolvimento de recursos complexos como a segmentação deuma imagem em camadas. Para inserção de outros modelos 3D dentro das cenas, pode-secriar mecanismos para suportar a leitura de arquivos nos formatos mais populares parase exportar modelos (.obj, .wrl, .off, .blen etc).

63

7 CONCLUSÃO

Há, ainda, muito o que se explorar no campo das imagens panorâmicas. A experiênciaproporcionada por imagens interativas pode ser aproveitada tanto para a imersão em am-bientes virtuais, quanto para aplicações em realidade aumentada. A arquitetura baseadaem camadas contribui para a exploração de características tridimensionais da imagemao considerar uma profundidade relativa entre os elementos da cena. Os dispositivosmóveis atuais possuem poder computacional e recursos adequados para uma experiênciainterativa e de realidade aumentada utilizando imagens.

Embora o enfoque deste projeto tenha sido a visualização e interação com imagens, emparticular imagens omnidirecionais, não se exclui a possibilidade de uma abordagem mista.A modelagem tridimensional possibilita interações mais flexíveis com os objetos, poismodelos 3D podem ser manipulados livremente por transformações projetivas e podemser visualizados sob qualquer direção. Uma abordagem mista, em que utiliza-se panoramase modelos 3D dentro da mesma cena poderia se beneficiar do menor custo de modelagemdas imagens e da maior flexibilidade dos modelos. Esse experimento poderia ser realizadopor meio da extensão do grafo de cena do framework.

7.1 TRABALHOS FUTUROS

Como propostas de trabalhos futuros, sugere-se a integração de um ambiente de au-toria que abrangesse os componentes desenvolvidos. Um ambiente de autoria facilitaria aconstrução de cenas e a organização de conteúdo pelos usuários do framework, tornando-ouma opção de desenvolvimento mais viável para desenvolvedores não familiarizados comconceitos de computação gráfica.

Levar em consideração a profundidade real dos pontos da cena, ou pelo menos garantirque a profundidade relativa entre os objetos da cena seja coerente com a profundidadereal desses elementos, seria um próximo passo na direção de melhorar a exploração deparalaxe entre as camadas de imagens. Uma representação similar à utilizada em [21, 72]poderia ser utilizada para a obtenção de camadas com profundidades coerentes com adisposição dos elementos da cena, possibilitando o tratamento da situação particular deobjetos que, mesmo apoiados sobre o chão, apresentam movimento aparente em relaçãoa ele. Unindo-se esta informação de profundidade para a reconstrução das malhas dascamadas mais internas, pode-se modelar o chão da cena como um plano que tangenciatodos os objetos apoiados.

Propõe-se, ainda, a integração de um método para obtenção da representação daimagem necessária como entrada para as aplicações, isto é, panoramas segmentadas emcamadas. Isto poderia passar pela pesquisa de um método baseado na captura de pa-noramas com profundidade ou na estimação da profundidade dos elementos na cena a

64

partir de técnicas de estereografia, tornando o processo menos dependente da utilizaçãode softwares proprietários. Uma outra abordagem poderia ser a criação de uma inter-face de usuário, integrada a um ambiente de autoria, para que esta segmentação fosserealizada de maneira assistida como uma etapa preliminar de todas as aplicações sobreeste framework ; assim, a entrada passaria a ser uma imagem equirretangular natural e,então, o usuário do framework definiria, como etapa preliminar da aplicação, onde e comosegmentar a imagem.

O suporte à geração de animações por sobre as imagens originais também constituium enriquecimento aos recursos do framework. Estas animações poderiam ser utilizadasna geração de imagens com um aspecto vivo, contribuindo, por exemplo, na formulaçãode simuladores. Em uma aplicação para museus, por exemplo, poder-se-ia animar olhosde personagens em quadros famosos dando características lúdicas à aplicação.

65

8 REFERÊNCIAS BIBLIOGRÁFICAS

[1] Chewbacca chess: http://img3.wikia.nocookie.net/__cb20130310062923/starwars/images/7/72/ Dejarik_Falcon.png – acessado em 18 de maio de 2014.

[2] Terminator Vision: http://lemonsblack.com/wp-content/uploads/2012/02/termi-nator_vision_02.jpg – acessado em 18 de maio de 2014.

[3] Minority Report Image: http://lgblog.nl/wp-content/uploads/2013/02/mino-rity_report_2.png – acessado em 18 de maio de 2014.

[4] Paprika (iTunes Store): https://itunes.apple.com/br – acessado em 19 de maio de2014.

[5] Apple developer. iOS Dev Center: https://developer.apple.com/devcenter/ios/in-dex.action - acessado em 23 de julho de 2014.

[6] Apple. https://www.apple.com/br/ - acessado em 12 de janeiro de 2014.

[7] ADELSON, Edward H.; BERGEN, James R. The Plenoptic Function and theElements of Early Vision, Cambridge, MA: MIT Press, 1991.

[8] PAZ, Hallison O.; ALTHOFF, Paulo Eduardo. Uso de Imagens Pa-norâmicas para aplicações em Realidade Aumentada Móvel. Ins-tituto Militar de Engenharia: Rio de Janeiro, 2013. Disponível em:http://www.polinize.com.br/media/contents/Uso_de_Imagens_Panorâmicas_para_aplicações_de _Realidade_Aumentada_Móvel.pdf — acessado em 28 de julho de2014.

[9] About OpenGL: http://www.opengl.org/about/ - acessado em 19 de maio de 2014.

[10] JOSHI, Neel; KAR, Abhishek; COHEN, Michael. Looking At You: Fused Gyroand Face Tracking for Viewing Large Imagery on Mobile Devices. SIGCHI,2012.

[11] CRAIG, Alan B. Understanding Augmented Reality - Concepts and Appli-cations. Waltham, EUA: Elsevier, 2013.

[12] WAGNER, Daniel; MULLONI, Alessandro; LANGLOTZ, Tobias; SCHMALSTIEG,Dieter. Real-time Panoramic Mapping and Tracking on Mobile Phones.Institute for Computer Graphics and Vision - Graz University of Technology, IEEEVirtual Reality, 2010.

66

[13] WITHER, Jason; TSAI, Yun-Ta; AZUMA, Ronald. Indirect Augmented Rea-lity. Computers & Graphics, vol. 35, #4 (August 2011). Special issue on MobileAugmented Reality. pp. 810-822.

[14] AZUMA , Ronald T. - A Survey of Augmented Reality - Presence: Teleoperatorsand Virtual Environments 6, 4 (August 1997).

[15] CARVALHO, Paulo Cezar; VELHO, Luiz; MONTENEGRO, Anselmo Antunes; PEI-XOTO, Adelailson; SÁ, Asla; SOARES, Esdras. Fotografia 3D. IMPA: 25° ColóquioBrasileiro de Matemática, 2005.

[16] OLSSON, Carl; KAHL, Fredrik; OSKARSSON, Magnus. The Registration Pro-blem Revisited: Optimal Solutions From Points, Lines and Planes. Centrefor Mathematical Sciences Lund University: Sweden, 2006.

[17] AZUMA, Ronald; BISHOP, Gary. Improving Static and Dynamic Registrationin an Optical See-through HMD. Department of Computer Science - Universityof North Carolina at Chapel Hill, 1994.

[18] DAN Mihai Photography. Flickr Equirectangular Panorama 360:https://www.flickr.com/photos/danmihaieu/4650968060/ — acessado em 5 dejulho de 2014.

[19] ISO/IEC 18004:2006. Information technology - Automatic identification anddata capture techniques-QR Code 2005 bar code symbology specification,2006.

[20] SHUM, Heung-Yeung; HE, Li-Wei. Rendering with Concentric Mosaics. InProceedings SIGGRAPH, 1999.

[21] FELINTO, D.; ZANG, A. R.; VELHO, L. Production framework for full pano-ramic scenes with photo-realistic augmented reality. XXXVIII ConferênciaLatinoamericana en Informática, 2012.

[22] OS X: https://www.apple.com/br/osx/what-is/ - acessado em 25 de julho de 2014.

[23] About OpenGL ES: https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Introduction/Introducti-on.html – acessado em 19 de maio de 2014.

[24] Bluetooth Technology. About Bluetooth Low Energy Technology.http://www.bluetooth.com/Pages/Bluetooth-Smart.aspx — acessado em 17 deabril de 2014.

67

[25] Android: http://www.android.com - acessado em 25 de julho de 2014.

[26] Windows Phone: http://www.windowsphone.com/pt-BR - acessado em 25 de ju-lho de 2014.

[27] BlackBerry: http://br.blackberry.com - acessado em 25 de julho de 2014.

[28] Windows 8: http://windows.microsoft.com/pt-br/windows-8/meet - acessado em25 de julho de 2014.

[29] Apple Developer. Getting Started with iBeacon.https://developer.apple.com/ibeacon/Getting-Started-with-iBeacon.pdf — acessadoem 17 de abril de 2014.

[30] Estimote. API Documentation. http://estimote.com/api/— acessado em 20 deabril de 2014.

[31] Estimote. Preorder for Estimote Beacons Available.http://blog.estimote.com/post/57087851702/preorder-for-estimote-beacons-available-shipping-this— acessado em 17 de abril de 2014.

[32] Estimote. Intro to Beacons. http://estimote.com/api/getting-started/intro-to-beacons.html— acessado em 17 de abril de 2014.

[33] VELHO, Luiz; GOMES, Jonas. Sistemas Graficos 3D. Rio de Janeiro, IMPA,2007.

[34] GAMMA, Erich; HELM, Richard ; JOHNSON, Ralph; VLISSIDES, John. DesignPatterns: Elements of Reusable Object-Oriented Software. Pearson Educa-tion, 1995.

[35] VELHO, Luiz; GOMES, Jonas. Fundamentos da Computação Gráfica. Rio deJaneiro: IMPA, 2008.

[36] SEARLS, Delmar E. Introduction to 3-D Modeling:http://dsearls.org/courses/C122CompSci/ Graphics/IntroModeling.htm — acessadoem 23 de julho de 2014.

[37] Adobe Photoshop CS6. http://helpx.adobe.com/br/photoshop/topics-cs6.html —acessado em 23 de março de 2014.

[38] MUNSHI, Aaftab; GINSBURG, Dan; SHREINER, Dave. The OpenGL ES 2.0programming guide. Pearson Education: Boston, 2009.

68

[39] Apple Developer. Core Motion Framework Reference.https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/Co-reMotion_Reference/index.html — acessado em 23 de julho de 2014.

[40] Apple Developer. Core Image Programming Guide:https://developer.apple.com/library/ios/documentation/graphicsimaging/conceptu-al/coreimaging/ci_intro/ci_intro.html - acessado em 25 de julho de 2014

[41] Apple Developer. Core Image Reference Colection:https://developer.apple.com/library/ios/DOCUMENTATION/GraphicsImaging/Re-ference/CoreImagingRef/index.html - acessado em 25 de julho de 2014

[42] Apple Developer. CIDetector Class Reference:https://developer.apple.com/library/ios/DOCUMENTATION/CoreImage/Referen-ce/CIDetector_Ref/index.html - acessado em 25 de julho de 2014

[43] MCCUNE, Bob. iOS 5 Face Detection with Core Image:http://www.bobmccune.com/2012/03/22/ios-5-face-detection-with-core-image/- acessado em 25 de julho de 2014.

[44] Apple Developer. Detecting Faces in an Image:https://developer.apple.com/library/ios/documentation/graphicsimaging/conceptu-al/coreimaging/ci_detect_faces/ci_detect_faces.html - acessado em 25 de julho de2014.

[45] Apple Developer. CIFaceFeature Class Reference:https://developer.apple.com/library/ios/DOCUMENTATION/CoreImage/Referen-ce/CIFaceFeature/index.html - acessado em 25 de julho de 2014.

[46] Apple Developer. SquareCam: https://developer.apple.com/library/ios/sampleco-de/SquareCam/Introduction/Intro.html - acessado em 28 de julho de 2014.

[47] VERMEER, Edwin. EVFaceTracker: https://github.com/evermeer/EVFaceTracker- acessado em 28 de julho de 2014.

[48] SNYDER, John; LENGYEL, Jed. Visibility sorting and compositing withoutsplitting for image layer decompositions. In Proceedings SIGGRAPH, 1998.

[49] Visible Surface Determination: Painter’s Algorithm:http://www.siggraph.org/education/materials/HyperGraph/scanline/visibility/painter.htm — acessado em 25 de julho de 2014.

69

[50] Apple Developer. Cocoa Touch frameworks.https://developer.apple.com/technologies/ios/cocoa-touch.html — acessado em25 de julho de 2014.

[51] Apple Developer. View Programming Guide for iOS:https://developer.apple.com/library/ios/documentation/windowsviews/conceptual/viewpg_iphoneos/WindowsandViews/ WindowsandViews.html — acessado em 23de julho de 2014.

[52] SCHABACK, Johannes. Open GL Picking in 3D: http://schabby.de/picking-opengl-ray-tracing/ — acessado em 14 de julho de 2014.

[53] Apple Developer. Core Location Framework Reference.https://developer.apple.com/ library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/index.html — acessado em 25 de julho de 2014.

[54] Apple Developer. Core Bluetooth. https://developer.apple.com/library/ios/docu-mentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBlu-etooth_concepts.pdf - acessado em 25 de julho de 2014.

[55] Apple Developer. CLBeacon Class Reference.https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLBeacon_class/Reference/Reference.html — acessado em 26 de julho de 2014.

[56] Apple Developer. CLLocationManager Class Reference.https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/ CLLocationManager.html —acessado em 26 de julho de 2014.

[57] Apple Developer. CLBeaconRegion Class Reference.https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLBeaconRegion_class/Reference/Reference.html — acessado em 26 de julho de2014.

[58] Apple Developer. CLLocationManagerDelegate Protocol Reference.https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManagerDelegate_Protocol/CLLocationManagerDelegate/CLLocationManagerDelegate.html — acessado em 26 de julho de 2014.

[59] Filtro de média móvel: http://borgescorporation.blogspot.com.br/2013/05/filtro-de-media-movel.html - acessado em 28 de agosto de 2014.

70

[60] Bluetooth Technology. Bluetooth Smart Technology: Powering the Internetof things. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx — acessadoem 17 de abril de 2014.

[61] Near Field Comunication: http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2013_2/nfc/ introducao.html - acessado em 20 de abril de 2014.

[62] NOSOWITZ, Dan. Everything you need to know about near field communi-cation. Popular Science Magazine. Popular Science, 2011.

[63] Billboard Tree: https://www.ssugames.org/pluginfile.php/1773/mod_resource/content/1/10-billboards/bb1.png – acessado em 18 de maio de 2014.

[64] Apple Developer. Air Locate. https://developer.apple.com/library/ios/samplecode/AirLocate/Introduction/Intro.htm — acessado em 17 de julho de 2014.

[65] Apple Developer. UIAcceleration Class Reference:https://developer.apple.com/library/ios/documentation/uikit/reference/uiaccelera-tion_class/Reference/UIAcceleration.html — acessado em 23 de julho de 2014.

[66] BROOKS, Frederick P. Jr. - The Computer Scientist as Toolsmith II. CACM39, 3 (March 1996).

[67] CHANG, Yu-Hsuan, CHU, Chung-Hua, CHEN, Ming-Syan. A General Scheme forExtracting QR Code from a non-uniform background in Camera Phonesand Applications, Simpósio Internacional de Multimídia - IEEE, 2007.

[68] Erick-nl – https://www.flickr.com/photos/erik-nl/185125112/in/set-1001899 – aces-sado em 18 de maio de 2014.

[69] GROHS, Emanuel Motta, MAESTRI, Patrick Renan Bernardes. Realidade Au-mentada para Informações Geográficas. Pontifícia Universidade Católica doRio Grande do Sul, 2002.

[70] KIRNER, C.; SISCOUTTO, R. Realidade Virtual e Aumentada: Conceitos,projetos e aplicações. Petrópolis: Laboratório Nacional de ComputaçãoCientífica,2007.

[71] WAGNER, Chris. Developing iOS 7 Applications with iBeacons Tutorial:http://www.raywenderlich.com/66584/ios7-ibeacons-tutorial — acessado em 15 dejulho de 2014.

[72] ZANG, Aldo René; FELINTO, Dalai ; VELHO, Luiz. Rendering Synthetic Ob-jects Into Full Panoramic Scenes Using Light-Depth Maps. Rio de Janeiro:Visgraf Laboratory - Institute of Pure and Applied Mathematics (IMPA), 2012.

71

APÊNDICE

72

A TECNOLOGIAS DE TRANSMISSÃO DE DADOS

Esta seção de apêndice aborda mais detalhes relativos às tecnologias de transmissãode dados consideradas e o porquê da escolha do Bluetooth Low Energy.

A.1 BLUETOOTH LOW ENERGY

A arquitetura do BLE é dividida em Host e Controlador, sendo que boa parte dasatividades é concentrada no controlador, a fim de permitir que o Host durma durantelongos períodos e desperte apenas para executar uma ação específica, minimizando assimo gasto energético.

Para efetuar a interação entre dispositivos, o BLE utiliza os canais de dados e os deanúncio. Sendo que os primeiros ocupam quase a totalidade dos canais, 37 dos 40 disponí-veis, e são utilizados nas comunicações bidimensionais entre dispositivos conectados entresi. Já o segundo tipo ocupa apenas os três restantes e possui como objetivos detectaroutros aparelhos que estejam nas proximidades e realizar transmissão em broadcast.

A comunicação BLE consiste em dois eventos principais: Anúncio e Conexão. Noprimeiro deles o aparelho anunciador envia, em modo Broadcast, pacotes de dados emintervalos regulares de tempo que variam de 20ms a 10s. Já no segundo, o dispositivoiniciador aguarda eventuais anunciadores nos canais de anúncio e, ao encontrar, enviauma requisição de conexão P2P entre ambos, na qual, possuirá poder de interrompê-la aqualquer momento.

De acordo com informações oficiais disponíveis no website do desenvolvedor da tecno-logia, o BLE possui as seguintes especificações técnicas: [24, 60]

• Transferência de dados: Pacotes de dados transferidos a uma velocidade de até, nomáximo, 1 Mbps;

• Frequency Hopping: Utiliza o AFH ou spread spectrum, o mesmo utilizado em todasas versões da tecnologia Bluetooth padrão para minimizar a interferência de outrastecnologias que utilizem a mesma frequência;

• Latência: Possui suporte para latências de estabelecimento de conexão e transferên-cia de dados de 3ms;

• Alcance: Pode chegar a mais de 100 metros;

• Modulação: Gaussian Frequency-Shift Keying (GSFK), com índice entre 0.45 e 0.55;

• Número de canais: 40, com espaçamento de 2 MHz;

• Robustez: Utiliza a verificação de redundância cíclica (CRC) de 24 bits em todosos pacotes para garantir uma forte robustez contra interferência;

73

• Segurança: Encriptação AES-128 utilizando o modo contador com CBC-MAC (CCM);

• Topologia: Possui um endereço de acesso de 32 bits em todos os pacotes paracada dispositivo escravo, permitindo dessa forma que bilhões de dispositivos estejamconectados ao mesmo tempo utilizando a topologia estrela, entretanto a tecnologiaé otimizada para conexões entre dois dispositivos apenas.

Apesar de herdar algumas características do Bluetooth clássico, vale ressaltar que o modode operar de ambos é diferente, portanto, não são compatíveis. Nos dias de hoje, umdispositivo compatível somente com a tecnologia low energy é chamado de smart, jáaquele compatível com ambas é denominado de smart ready.

A.2 NEAR FIELD COMMUNICATION

A Near Field Communication (NFC) [61] ou, em português, Comunicação por Campode Proximidade é uma tecnologia de transmissão de dados de forma segura e sem fio apequenas distâncias, geralmente menores do que 10 centímetros. Um dispositivo, conhe-cido como iniciador, utiliza indução magnética para criar um campo magnético que serádetectada e acessada pelo aparelho alvo.

As duas principais maneiras de se realizar a comunicação utilizando essa tecnologiasão: o modo de leitura e escrita que permite a dispositivos lerem e escreverem em outrosdispositivos passivos como uma etiqueta NFC e o modo P2P que permite a dispositivosNFC trocar dados uns com os outros, um exemplo de aplicação que realiza sua comuni-cação dessa maneira é o Android Beam.

Essa tecnologia possui uma velocidade máxima de transmissão de dados de 0.424 Mbps,bastante baixa se comparado a outros protocolos sem fio como o Wi-Fi ou o BluetoothClássico. Entretanto, seu consumo energético de 15 mA é menor, além de oferecer umamaior segurança na transmissão de dados, muito devido à baixa área de atuação, e de nãoprecisar de um pareamento prévio como existe em outros protocolos. O NFC se destacaprincipalmente para os tipos de comunicação que exijam apenas dois atores ao mesmotempo, como, por exemplo, uma transação monetária. Um chip NFC pode facilmente serconfigurado para agir como um cartão de crédito ou débito, o que nos dias de hoje já éuma realidade em larga escala em países como Estados Unidos e Japão, onde é possívelcomprar passagens de transporte público, ingressos de cinema, tickets de estacionamento,entre outros [62].

Para se obter um melhor funcionamento do framework desenvolvido nesse trabalho énecessária uma interação entre dispositivos a distâncias extremamente grandes se compa-radas aos poucos centímetros nas quais é possível utilizar o NFC, portanto, devido a essemotivo foi tomada a decisão de descartar a utilização dessa tecnologia.

74

A.3 QR CODE

O Quick Response Code é uma espécie de código de barras bidimensional, designadoinicialmente para a indústria automotiva japonesa em 1994, mas que nos dias de hoje jápossui diversas funções adicionais, principalmente no que tange à indústria de marketinge comunicação.

Um QR Code possui uma capacidade máxima de armazenamento de informação de4296 caracteres alfanuméricos, entretanto toda sua superfície não é utilizada apenas comoárea de dados, ela é subdivida em espaços menores voltados para facilitar a leitura, pro-porcionar outras funcionalidades e melhorar o seu desempenho, são os finder patterns,alignment patterns, timing patterns e a quiet zone. Esses espaços permitem também queo mesmo seja lido em qualquer direção, deformado, danificado, com as cores invertidas ouespelhado [8].

FIG. A.1: Estrutura de um QR Code [8]

Os finder patterns consistem em três estruturas idênticas localizadas em três das quatroextremidades de acordo com a FIG. A.1, esses padrões permitem ao software reconhecero QR Code e determinar a orientação de maneira correta. Já os alignment patterns sãoresponsáveis por auxiliar o software que irá decodificar a imagem a compensar eventuaisdistorções que possam existir. Os timing patterns são linhas que marcam as direções hori-zontal e vertical do código bidimensional, também é utilizado na correção de deformações.Por último, existe a quiet zone que é utilizada para auxiliar no reconhecimento do fim daimagem pelo decodificador.

Para se utilizar um QR Code a grandes distâncias é necessário um espaço físico muitogrande, como, por exemplo, telões ou outdoors. Devido a esse fato, na maior parte dasaplicações, seu uso é restrito a distâncias reduzidas, além disso, essa tecnologia possuia desvantagem de ser necessário direcionar a câmera do aparelho decodificador para ocódigo, visto que ela funcionará como um leitor. Dessa forma essas duas características

75

restringem bastante suas aplicações e foram os principais motivos que fizeram com queessa tecnologia fosse preterida em relação ao Bluetooth Low Energy.

76

B INSERÇÃO DE NOVOS ELEMENTOS: BILLBOARDS

Em complemento à utilização de uma camada de interação, como apresentado naseção 5.1.2, a técnica de billboards poderia ser utilizada para inserir novos elementosdentro da cena. Billboards são polígonos planos que estão sempre voltados para a câmera,isto é, a direção normal à face do polígono coincide com a direção de observação (eixoótico da câmera virtual). Esta técnica é muito utilizada quando se quer representar, deforma simplificada, elementos tridimensionais distantes ou que apresentariam um altocusto computacional devido a um grande nível de detalhes. Sobre o polígono, mapeia-se uma textura que represente o objeto desejado. Devido à disposição deste elementona cena (apontando na direção da câmera), o observador tem a impressão de que ele étridimensional. A FIG. B.1 ilustra o uso de billboards para representar árvores.

FIG. B.1: Árvores desenhadas com a técnica do billboarding [63]

Como em nossa arquitetura o observador mantém-se fixo no centro de projeção dapanorama, o uso de billboards pode gerar resultados de alta qualidade a baixo custocomputacional.

77