FRAMEWORK PARA APLICAÇÕES EM …lvelho.impa.br/hp/files/Hallison-Monografia.pdfem dispositivos...

MINISTÉRIO DA DEFESA

EXÉRCITO BRASILEIRO

DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA

INSTITUTO 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 PLATAFORMAS MÓVEISUSANDO PANORAMAS COM CAMADAS

RIO DE JANEIRO

2014






Relatório apresentado ao Curso de Engenharia deComputação do Instituto Militar de Engenharia, como requi-sito 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






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

Aprovado em 2014 pela seguinte Banca Examinadora:

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

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

Ricardo Choren Noya – D.C. , do IME

Carla Liberal Pagliari – Ph.D. , do IME

RIO DE JANEIRO

2014

3

Dedicamos este projeto à todos os nossos familiares, amigos e colegas deturma que contribuíram e nos incentivaram durante a elaboração do mesmo.

4

AGRADECIMENTOS

Nossos sinceros agradecimentos a todos que de alguma forma puderam nos ajudar ao longo do anona conclusão deste trabalho.

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

Ao professor Paulo Rosa por ter contribuído com suas ideias e sugestões e pela prontidão para nosauxiliar sempre que necessário.

5

SUMÁRIO

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

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 TÓPICOS TUTORIAIS E O ESTADO DA ARTE . . . . . . . . . . . . . . . . . . . . . . . . . 182.1 REALIDADE AUMENTADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.1 PRINCIPAIS PROBLEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 IMAGENS PANORÂMICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 REALIDADE AUMENTADA INDIRETA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 PANORAMAS COM CAMADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4 VISUALIZAÇÃO IMERSIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 AMBIENTE DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 TECNOLOGIA GRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 TECNOLOGIAS DE COMUNICAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 TECNOLOGIA DE MICROLOCALIZAÇÃO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.1 BEACON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 MODELAGEM E VISUALIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1 GRAFO DE CENA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 MALHA POLIGONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 PANORAMA COM CAMADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.1 IMAGEM DE REPRESENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 FERRAMENTAS MATEMÁTICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5 SHADERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6 CÂMERA VIRTUAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.1 ATUALIZAÇÃO DA CÂMERA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7 PERSPECTIVA DINÂMICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.7.1 CORE IMAGE FRAMEWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.7.2 TRANSLATIONMANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.8 CICLO DE RENDERIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 COMPONENTES DE INTERAÇÃO E MICROLOCALIZAÇÃO . . . . . . . . . . . . 425.1 INTERAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.1.1 RAY PICKING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.1.2 CAMADA DE COLISÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.3 EXIBIÇÃO DE CONTEÚDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 MICROLOCALIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.1 CLBEACON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2 CLBEACONREGION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2.3 CLLOCATIONMANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6

5.2.4 BEACONMANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 O FRAMEWORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.1 ESTRUTURA DOS COMPONENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 UTILIZAÇÃO E ESPECIALIZAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3 AMBIENTE DE AUTORIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4 ANÁLISE DOS RESULTADOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7 CONCLUSÃO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

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

A TECNOLOGIAS DE TRANSMISSÃO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . 62A.1 BLUETOOTH LOW ENERGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62A.2 NEAR FIELD COMMUNICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A.3 QR CODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

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

7

LISTA DE ILUSTRAÇÕES

Figura 1.1 Chewbacca e C3PO em momento de lazer [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figura 1.2 Visor do exterminador do futuro [62] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figura 1.3 Interfaces apresentadas em Minority Report [50] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figura 1.4 Aplicativo Paprika [54] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figura 2.1 Ilustração do problema do registro [71] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figura 2.2 Exemplo de panorama equirretangular [37] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figura 2.3 Arquitetura de panoramas com camadas [57] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figura 2.4 Posições relativas entre o observador e o aparelho [47] . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figura 3.1 Interface aplicação-GPU [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figura 3.2 Beacon da marca Estimote em visão explodida [41] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figura 3.3 Desenho esquemático de um pacote de dados transmitido . . . . . . . . . . . . . . . . . . . . . . . . 28

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

Figura 4.1 Exemplo de Grafo de Cena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

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

Figura 4.3 Malha esférica com faces quadrangulares [59] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figura 4.4 Imagem da camada mais externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figura 4.5 Imagem da camada intermediária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figura 4.6 Imagem da camada mais interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figura 4.7 Pipeline simplificado de renderização da OpenGL [51] . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figura 4.8 Transformações componentes da câmera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figura 4.9 Pirâmide de Visualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Figura 4.10 Orientação dos eixos coordenados no sistema iOS [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figura 4.11 Core Image identifica limites das faces em uma imagem [20] . . . . . . . . . . . . . . . . . . . . . . 38

Figura 4.12 Comparativo da precisão do algoritmo de detecção de face [49] . . . . . . . . . . . . . . . . . . . . 39

8

Figura 4.13 Zoom a partir da aproximação da face ao dispositivo [47] . . . . . . . . . . . . . . . . . . . . . . . . . 40

Figura 4.14 Efeito de paralaxe a partir do posicionamento da face em relação ao dispositivo [47] . 40

Figura 4.15 Projeção da panorama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Figura 5.1 Vetores de Rotação da Câmera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Figura 5.2 Sistema de Coordenadas nativo da tela [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figura 5.3 Ray Picking [58] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Figura 5.4 Camada de Interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figura 5.5 Conteúdo exibido após interação com televisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figura 5.6 Modelagem da máquina de estados finitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Figura 6.1 Relação entre os componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figura 6.2 Deslizamento aparente dos objetos sobre o chão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Figura A.1 Estrutura de um QR Code [57] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Figura B.1 Árvores desenhadas com a técnica do billboarding [28] . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9

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

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

10

ABSTRACT

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

using a layered representation of panoramic images. This framework 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.

11

1 INTRODUÇÃO

Desde muito tempo atrás, o homem traça projeções futuristas em que as tecnologias da era digitalparticipam intensamente de seu dia-a-dia. Muitas dessas projeções conseguiram atingir uma visibilidadeinternacional por meio das artes como a literatura e o cinema, e exerceram (e ainda exercem de certamaneira), impacto sobre pesquisas científicas ambiciosas que almejam tornar realidade aquilo que outroraera ficção.

Neste cenário, uma parcela destas projeções apresentava a situação particular em que dados virtuaismesclavam-se com o mundo real de forma a complementá-lo ou expandí-lo. Pode-se citar exemplosde filmes consagrados como a série Guerra nas Estelas (Star Wars), em que a personagem Chewbaccajoga com o robô C3PO uma partida de um jogo de tabuleiro com peças virtuais (Figura 1.1), ou OExterminador do Futuro (The Terminator), que possuía um visor onde informações relevantes sobre seusalvos eram sobrepostas à própria visão do ambiente, como ilustrado na Figura 1.2.

Figura 1.1: Chewbacca e C3PO em momento de lazer [35]

12

Figura 1.2: Visor do exterminador do futuro [62]

Mais recentemente, em 2002, Steven Spielberg na direção de A Nova Lei (Minority Report) retratouinterfaces digitais que podiam ser manipuladas com gestos “no ar” (Figura 1.3), ampliando sua contri-buição no quadro da realidade aumentada. Em uma análise bem simplificada, as principais barreirastecnológicas para se alcançar essas projeções futuristas estão no desafio da visualização, isto é, em comoexibir estas informações virtuais em nosso mundo real e no desafio da interação, que consiste em comose pode manipular estes dados e o que pode ser feito com eles.

Figura 1.3: Interfaces apresentadas em Minority Report [50]

A popularização dos smartphones e o advento dos novos tablets foram fenômenos que contribuíramfortemente para a integração de diversas tecnologias ao cotidiano das pessoas, na medida em que sãodispositivos que podem e são carregados para praticamente qualquer ambiente social e congregam umconjunto de inúmeras ferramentas desde calculadoras, agendas e navegadores de internet até câmerasfotográficas e aparelhos de GPS (Global Positioning System). Estes dispositivos móveis possuem um im-pacto muito importante na popularização do termo realidade aumentada não só pela facilidade de unificar

13

uma grande variedade de recursos que já existiam, mas principalmente por propiciar o desenvolvimentode novas formas de utilização da informação e de interação com o conteúdo digital.

Dentro deste contexto, surgem cada vez mais aplicações que se apoiam sobre os dispositivos móveispara solucionar desafios da área. Por exemplo, aplicações como o Paprika [54] implementam soluçõesde visualização baseadas na captura da imagem da cena com a câmera de um dispositivo móvel e naexibição de uma nova imagem, processada e aumentada, na tela do aparelho. Para a interação, explora-se a capacidade sensível ao toque da tela ou até mesmo os sensores de atitude do dispositivo. Na Figura 1.4podemos ver o aplicativo em funcionamento.

Figura 1.4: Aplicativo Paprika [54]

1.1 OBJETIVO

O objetivo deste trabalho é desenvolver um framework para visualização e interação com imagenspanorâmicas omnidirecionais previamente capturadas a fim de prover uma experiência imersiva e dinâmicaem dispositivos móveis. O framework será implementado para a plataforma iOS [22], utilizada pelosdispositivos da companhia Apple [6].

Para tratar dos aspectos de visualização, utilizar-se-á os dados dos sensores de atitude disponíveis(acelerômetro, giroscópio e magnetômetro) e também da câmera frontal do dispositivo. As câmerasomnidirecionais permitem capturar uma imagem em um campo de visão de 360 graus. A proposta consisteem trabalhar sobre um modelo de representação de imagens panorâmicas equirretangulares segmentadaspor camadas de acordo com a profundidade relativa entre os elementos da cena representada. O processode criação desta representação não faz parte do escopo deste projeto.

Imagens panorâmicas omnidirecionais [57] são estruturas com um apelo natural à imersão, na me-dida em que proporcionam ao observador a visualização de uma cena em todas as direções. Com umarepresentação segmentada por camadas, pretende-se ir mais além neste aspecto de imersão tratando situ-ações de oclusão de elementos e explorando o efeito de paralaxe entre as camadas para simular pequenasalterações de perspectiva baseadas na 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 plataforma iOS [22],

14

utilizar-se-á diretamente a Open Graphics Library [1] para tratar da modelagem e renderização de ele-mentos gráficos tridimensionais, visando maior desempenho e controle sobre o resultado desejado. Comas bases da visualização construídas, o enfoque do trabalho será a implementação de estratégias para ainteração com o conteúdo visualizado, bem como a exibição de conteúdos adicionais à cena, levando emconsideração, inclusive, o posicionamento do usuário.

1.2 MOTIVAÇÃO

Dados os dois problemas propostos, visualização e interação, as plataformas móveis têm se apresen-tado como uma alternativa eficaz para atacá-los devido à variedade de recursos integrados. A facilidade deacesso a esses dispositivos e também de distribuição de aplicativos em lojas virtuais permitiu o desenvolvi-mento de um sólido mercado onde soluções criativas podem ser um bom diferencial. No meio acadêmico,pesquisadores também acrescentaram estes aparelhos aos seus aparatos de trabalho [47, 36, 68, 71, 57],apostando na evolução do poder da computação móvel para adaptação de soluções já existentes e odesenvolvimento de novas soluções para o futuro.

As pesquisas nas áreas de computação gráfica e visão computacional há muito tempo abordamproblemas relacionados à visualização tanto no campo bidimensional (imagens) quanto no campo tridi-mensional, não raramente interligando ambos os campos. Com uma estrutura física 2D e uma estruturasemântica 3D, imagens panorâmicas têm sido frequentemente utilizadas quando se objetiva proporcionara um observador uma visão geral de um ambiente a baixo custo.

No que diz respeito à interação com elementos virtuais, a modelagem 3D constitue um processoeficaz, principalmente pela facilidade em se modificar o ponto de vista dos objetos. No entanto, modelaruma cena por completo seria um processo muito custoso principalmente pelo tempo necessário para semodelar cada objeto. Aliado a isto, a mesclagem de objetos modelados com elementos reais da cena aindaapresenta problemas de visualização difíceis de se resolver. Assim, imagens panorâmicas apresentam-se como bons substitutos tanto para a modelagem de ambientes, quanto para a visualização de novoselementos, que modifiquem a percepção do usuário em seu mundo. Uma arquitetura de panoramas comcamadas possibilitaria a aproximação entre este modelo baseado em imagens e um modelo tridimensionaltanto na visualização quanto na interação, introduzindo mudanças de perspectiva e oclusão.

1.3 METODOLOGIA

Este projeto foi segmentado em 4 áreas relacionadas, porém implementadas com um certo graude independência. A primeira área trata da modelagem, que abrange o projeto e a implementação deum sistema gráfico tridimensional renderizador em tempo real. Como a visualização pretendida é feitade forma indireta, por imagens omnidirecionais, a modelagem trata basicamente da implementação deum visualizador de panoramas para um dispositivo móvel, além da modelagem de todos os elementosauxiliares necessários para que haja interatividade.

15

A visualização em si consiste de uma outra área, que aborda a segmentação das imagens em camadaspor profundidade, o preenchimento de espaços resultantes da segmentação em camadas e a exploraçãodo efeito de paralaxe entre as camadas para gerar uma visualização mais imersiva. Os problemas devisualização comuns à realidade aumentada são tratados nesta área. Como abordado no objetivo, supõe-se que a representação de uma panorama por camadas já se encontra pronta ou foi obtida manualmente.O desenvolvimento de mecanismos baseados na segmentação automática de imagens e/ou na recuperaçãoda profundidade estimada de cada pixel da imagem constituiriam, por sua complexidade, um trabalho àparte.

A terceira área trata da microlocalização do usuário. Nesta área, objetivou-se prover mecanismospara que fosse possível localizar o usuário dentro de um ambiente in-door como um museu ou outro tipode exposição onde haja interesse em utilizar aplicativos com imagens interativas.

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

1.4 ESTRUTURA DO TRABALHO

Este trabalho está estruturado em 8 capítulos principais e 2 capítulos de apêndice. Após umaintrodução para situar o leitor em alto nível dentro do assunto, apresenta-se um capítulo com tópicostutoriais para este trabalho e o estado da arte dos assuntos relacionados, em que é feita uma revisãobibliográfica. Neste capítulo, conceitua-se realidade aumentada (RA) [27], apresenta-se os principaisproblemas desta área de estudo e aborda-se como os dispositivos móveis contribuíram para a popularizaçãodeste termo. 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 sobrea plataforma iOS [22], escolhida para implementação do framework, o padrão OpenGL [1], o BluetoothLow Energy e o iBeacon, tecnologias que serão utilizadas direta ou indiretamente na implementação doprojeto.

Em seguida, nos capítulos 4 e 5, descreve-se as estratégias adotadas em cada componente do fra-mework. O capítulo 4 apresenta detalhes quanto à visualização, abordando a arquitetura de panoramascom camadas, os elementos de suporte à modelagem de uma cena, a abordagem adotada para inserirmudanças de perspectiva e abstrações auxiliares para lidar indiretamente com a API do OpenGL.

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

O capítulo 6 trata do framework propriamente dito, mostrando como todos esses componentes serelacionam e como o cliente do framework poderia utilizá-lo. Neste capítulo relaiza-se uma análise dosresultados obtidos a partir da implementação das estratégias apresentadas.

Ao final, há uma conclusão com sugestões para a expansão do framework e comentários sobre propos-tas de trabalhos futuros. No apêndice, abordam-se outras informações sobre tecnologias de transmissão

16

de dados alternativas ao Bluetooth Low Energy e também sobre a utilização de billboards em cenas 3D. Adocumentação do framework e o diagrama de classes dos componentes também se encontram no apêndicea este trabalho.

17

2 TÓPICOS TUTORIAIS E O ESTADO DA ARTE

Este capítulo aborda conceitos teóricos e alguns trabalhos cujos resultados são muito relevantes paraa realização deste projeto. Essas contribuições ajudam a entender algumas razões para a escolha daabordagem deste trabalho.

2.1 REALIDADE AUMENTADA

A terminologia Realidade Aumentada (RA) é muito tratada sob a perspectiva da computação gráfica,que enfatiza os aspectos ligados à coexistência em harmonia de ambientes virtuais e reais cada vez maisinterativos. Uma definição clássica para o termo seria: Realidade Aumentada é um sistema que misturao mundo real com elementos virtuais, atua em três dimensões, e possui interatividade em tempo real [27].

No entanto, frequentemente, esta terminologia tem sido interpretada de maneira mais ampla, englo-bando também, por exemplo, o campo sonoro. Portanto, consideraremos realidade aumentada como umaexperiência dada pela percepção de mesclagem entre elementos que não existem fisicamente (virtuais)com os elementos que existem fisicamente em nosso mundo, desde que haja interatividade em tempo reale o usuário ainda se reconheça inserido no mesmo local físico em que se encontra. Esta noção de estarno mesmo 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, possibilitaramnovas formas de interação e manipulação dos dados pelos usuários. Além disso, aproximaram mais aindaa tecnologia digital à vida do usuário comum, que passou a conviver de forma quase que dependente,com uma ferramenta que integra diversos sensores e possui alto poder computacional. Dada a grandequantidade de informação ostensivamente espalhada pela internet, selecionar esta informação e torná-ladisponível no momento adequado para o usuário constituem desafios de interesse para o suporte a umaexperiência de realidade aumentada através da conexão visual entre o que poderia ser visto em umapá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 aplicações paraestes novos dispositivos e atraíram a atenção de muitos desenvolvedores independentes, empresas e pes-quisadores do meio acadêmico, que passaram a investir em soluções criativas para diferenciação e sucessode seus produtos. Embora a ideia de realidade aumenta exista desde muitos anos atrás, foi este contextoda computação móvel que colocou 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 realidade aumen-tada são o problema do registro, do rastreamento e da oclusão [57]. O problema do rastreamento ourastreamento do ponto de vista do usuário, é o problema de se determinar a perspectiva sob a qual a

18

imagem virtual deverá ser desenhada. Para isso, é necessário reconhecer de onde e como o usuário observaa 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 [33].

Conhecendo-se o ponto de vista adequado, deve-se tratar do problema do registro, que em umaanálise geral consiste em encontrar a transformação entre dois sistemas de coordenadas [55], objetivandoalinhá-los. Dentro da RA, o registro frequentemente se traduz no alinhamento geométrico entre duasimagens, algo extremamente importante para uma correta ilusão de coexistência dos objetos para ousuário [26]. No caso da realidade aumentada, as duas imagens referidas no problema são representadaspelos objetos reais e virtuais. A Figura 2.1 ilustra uma situação em que o registro entre a cena (real) e aanotação (virtual) está inadequado e outra em que o registro está correto.

(a) Registro incorreto (b) Registro correto

Figura 2.1: Ilustração do problema do registro [71]

O problema da oclusão consiste de um problema de ordenação e ocultação de objetos que se sobre-poem na visão do usuário. Se, por exemplo, na visualização de uma sala de estar insere-se uma bolinhade tênis rolando pelo chão em um plano mais afastado do observador em relação ao plano em que seencontra um sofá, esta aplicação deve ser capaz de identificar quando a bolinha e o sofá se sobreporiamem relação ao observador e, por conseguinte, 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 de visão e contémuma quantidade de informação visual muito superior à que os seres humanos são capazes de observare compreender naturalmente. Para ser observada no plano, como uma única imagem, esta informaçãovisual pode ser parametrizada de diversas maneiras diferentes, dando origem a vários tipos de panoramastais como a panorama planar, a cilíndrica, a cúbica ou a equirretangular. Este tipo de imagem podeser capturado com equipamentos especiais tais como câmeras com lente do tipo ”olho-de-peixe” (fisheyelens) ou pode ser sintetizado por software a partir de várias fotografias comuns de um mesmo local,processo conhecido como panorama stitching. Para mais detalhes sobre as formas de aquisição de imagenspanorâmicas, ver [57] e suas referências.

Para este trabalho, sempre que for tratado de imagens panorâmicas ou panoramas, estaremos nosreferenciando às imagens omnidirecionais, isto é, imagens que contém toda a informação visual da esferade visão, compreendendo, portanto, tudo que pode ser visualizado em uma cena a partir de um pontofixo em qualquer direção. Dentre as imagens omnidirecionais, selecionou-se o formato equirretangular deparametrização para implementação do projeto (Figura 2.2).

19

Figura 2.2: Exemplo de panorama equirretangular [37]

A parametrização equirretangular é obtida a partir de uma analogia das coordenadas esféricas comas coordenadas cartesianas, dividindo-se por intervalos iguais os ângulos J e f das direções horizontal evertical, respectivamente. Por conseguinte, uma panorama equirretangular possui uma associação naturalcom um sistema de latitude e longitude.

2.3 REALIDADE AUMENTADA INDIRETA

O trabalho de [71] sobre realidade aumentada indireta é a principal base deste projeto. Os autoresrealizaram um estudo sobre o uso de imagens panorâmicas para realidade aumentada ao invés da imagemcapturada em tempo real através da câmera de um dispositivo móvel e chamaram a este tratamento derealidade aumentada indireta. Os autores fizeram testes com usuários, buscando estabelecer comparaçõesentre esta abordagem e a abordagem tradicional de visão direta por vídeo, obtendo resultados sobre apercepção humana a partir das impressões deste conjunto de teste.

Dentre outras coisas, buscou-se responder o seguinte questionamento: ”a realidade aumentada indi-reta tem o mesmo nível de imersão que a direta?”. Para isso, foram feitos testes com situações favoráveisàs duas abordagens e depois uma comparação com situações desfavoráveis à abordagem indireta, taiscomo um ambiente dinâmico, o uso de panoramas com centro de projeção afastado da posição do usuárioe mudanças de iluminaçã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 quatro constatações:

1. Em condições favoráveis para as duas abordagens, a grande maioria dos usuários não notou dife-renç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 os testes.

3. Nos testes em ambientes com elementos dinâmicos, a experiência em RA indireta foi menos preju-dicada que a em RA tradicional.

20

4. Utilizar uma panorama capturada em uma posição diferente daquela em que o usuário se encontrarealmente reduz a imersão e modifica a experiência. No entanto, esta mudança é apenas significantequando as duas localidades estão bem separadas.

Esse resultado se deve, em parte, à vantagem da realidade aumentada indireta na solução do ali-nhamento entre os objetos reais, do mundo físico, e os elementos virtuais adicionados. Enquanto nasabordagens tradicionais os erros neste problema de visualização são facilmente notados, na abordagemindireta, este erro só é percebido entre o aparelho e o ambiente externo; ou seja, a imagem exibida natela do aparelho pode estar em registro perfeito. Como tanto a panorama quanto os demais elementosvirtuais são movimentados em conjunto, não há deslocamentos entre eles.

Muitas aplicações de realidade aumentada tradicional utilizam recursos como QR Codes [46] ououtras marcações fiduciais, isto é, marcações com características propícias à detecção, para determinaros pontos da cena no mundo real em que serão inseridos os elementos virtuais e/ou como estes elementosserão inseridos. Outra solução adotada consiste em utilizar algoritmos de visão computacional para pré-processar as imagens e identificar os pontos de interesse para a aplicação; no entanto, esta solução é muitocustosa do ponto de vista computacional e nem sempre muito robusta. Ambas as soluções são suscetíveis aerros e imprecisões no registro, inerentes aos sensores utilizados. A utilização de imagens seria, portanto,uma abordagem diferente para este problema através de uma solução mais simples, dado que pode-seposicionar perfeitamente novos elementos dentro de uma imagem que já se conhece previamente. Alémdisso, a imprecisão dos sensores não exerce impacto sobre a visualização já que não há mais um contrasteentre o mundo real 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.

Evidentemente, esta abordagem não funciona para qualquer tipo de aplicação. Notadamente limi-tações na cena como tráfego (elementos dinâmicos), mudanças bruscas no tempo (clima) e na iluminaçãonão podem ser representadas por uma imagem estática. Como visto em [71], em se tratando de imagenspanorâmicas, um fator que pode ser limitante à experiência é o fato de que a perspectiva exibida é aquelaque pode ser percebida a partir do centro de projeção da panorama, isto é, a partir do ponto em que estainformação visual foi capturada. Assim, sempre que possível, deve-se selecionar uma imagem cujo centrode 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 realidade aumen-tada, em [57] os autores propõem uma arquitetura baseada em panoramas com camadas para tratar oproblema de inserção de novos elementos na cena. Utilizando imagens panorâmicas equirretangulares,seria possível compor uma estrutura com esferas ou fragmentos de esferas concêntricas com raios de ta-manhos diferentes (Figura 2.3). Estruturas com uma ideia similar, como mosaicos concêntricos [60] oupanoramas com cartas de profundidade [42] foram exploradas anteriormente, inclusive para aplicaçõesem realidade aumentada.

21

Figura 2.3: Arquitetura de panoramas com camadas [57]

Na proposta original de [57], os autores propõem que a camada mais externa seja uma esfera com-pleta, uma imagem panorâmica que represente a cena original. As camadas mais internas serviriam paraa adição de elementos que não estavam presentes na cena original. Para o observador, esta estrutura depanorama em camadas se comportaria como uma imagem única e que poderia ser tornada interativa apartir de tratamentos específicos para cada camada.

A região da cena que é exibida depende apenas do ângulo de visão do observador. Dessa forma, otamanho do raio das camadas não interfere na porção da imagem que será visualizada, servindo somentepara definição da profundidade dos elementos em relação ao observador, consequentemente definindo umaordenação para fins de oclusão.

Em [42], os autores utilizam um modelo de camadas com profundidade, em que é realizada umaestimação da profundidade de cada ponto da cena, gerando-se uma carta de profundidade que é utilizadapara modelar as relações entre os objetos de forma mais próxima da imagem real. Neste projeto, adota-seum modelo mais simplificado em que as camadas determinam apenas uma ordem de prioridade entre oselementos. Este modelo é suficiente para determinar relações de oclusão e explorar o efeito de paralaxedentro da cena, 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, basicamente, em pegaruma imagem panorâmica e fazer com que seja exibida na tela do dispositivo apenas uma pequena partedesta imagem, compatível com o campo de visão humano e coerente com o que a maioria das câmerasdesses aparelhos nos permitiria observar. Além disso, o trecho da imagem a ser exibido deve ser deter-minado pela orientaçã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 deve ser exibido oequivalente ao teto da cena.

Como as imagens panorâmicas possuem um único ponto de observação, chamado de centro deprojeção, a cena será sempre observada a partir do ponto em que a imagem foi fotografada. Para suportarde alguma forma translações do observador dentro da cena, seria necessária uma base de dados de várias

22

panoramas adquiridas a partir de pontos diferentes do mesmo ambiente. Este tipo de abordagem é alvode recentes pesquisas e não pretende-se tratá-la no escopo deste trabalho.

No entanto, baseado no trabalho de [47], apresenta-se um método para simular pequenas mudançasde perspectiva para um observador próximo ao centro de projeção da panorama de acordo com a orientaçãode sua face em relação à orientação do dispositivo. Para isso, propõe-se uma modificação na arquiteturaem relação ao trabalho de [57]: a camada mais externa, outrora constituída por uma imagem completa,será segmentada em duas ou mais camadas, considerando a profundidade relativa entre os objetos dacena, isto é, objetos mais afastados do observador ficarão em uma camada e os mais próximos em outra.Cada camada, portanto, contém apenas uma parte da informação da imagem completa. Sobre a camadamais afastada, realiza-se um tratamento para completar total ou parcialmente as partes de informação quefaltam, com o auxílio de algoritmos para preenchimento de regiões como os implementados em programasde edição de imagens. Com isso, pretende-se recuperar de forma aproximada a informação supostamenteocultada pelo que está presente nas camadas mais próximas.

Em [47], os autores propõem um método de fusão de dados provenientes dos sensores de atitudede um dispositivo móvel (acelerômetro, giroscópio e magnetômetro) com um algoritmo de detecção deface utilizado sobre a imagem da câmera frontal do aparelho. O objetivo desta fusão é a visualizaçãode imagens maiores do que a tela do dispositivo com uma interface livre de toques sobre a tela comomecanismo de rolagem e deslocamento.

A ideia é unir a eficiência dos sensores, que podem realizar medidas da pose do aparelho rapidamentecom a eficácia de algoritmos de detecção de faces para estimar a posição de observação do usuário emrelação ao dispositivo. Assim, pode-se tratar adequadamente situações como a ilustrada na Figura 2.4onde estão representados um dispositivo móvel na parte superior e um observador na parte inferior. Nassituações b e c, percebe-se que o dispositivo apresenta o mesmo valor DJG de inclinação, porém o usuárioobserva a tela do 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 do aparelho dentrodo mundo real, independente de onde esteja o observador.

Figura 2.4: Posições relativas entre o observador e o aparelho [47]

Para este projeto de fim de curso, almeja-se utilizar o princípio desta pesquisa como base parapropor uma visualização de panoramas com camadas que explore o efeito de paralaxe entre as camadasda panorama, a fim de simular pequenas mudanças de perspectiva que correspondam a movimentos decabeça do observador. Com isto, pretende-se tornar a experiência de visualização de uma panorama maistridimensional e, sobretudo, mais imersiva.

23

Utilizando os sensores de atitude e a câmera frontal do aparelho móvel, explora-se o efeito de paralaxeentre as camadas, isto é, além de movimentar a cena de acordo com a pose do aparelho, movimenta-setambém uma camada em relação à outra de acordo com a direção de observação do usuário. Com estatécnica, pretende-se simular a noção que temos ao observar o mundo real e movimentar a cabeça, porexemplo, para observar um objeto parcialmente ocultado por outro a partir de nossa posição.

24

3 AMBIENTE DE DESENVOLVIMENTO

Para a implementação deste framework, os testes serão realizados sobre dispositivos que utilizem osistema operacional iOS [22]. A Apple [6], empresa responsável pelo desenvolvimento desta plataforma, étambém responsável pelo desenvolvimento do hardware que a utiliza, o que gera um alto grau de padro-nização entre as funcionalidades dos aparelhos e garante o mesmo nível de qualidade para todos. O iOSfoi estruturado para tirar máxima vantagem do hardware dos dispositivos que o suportam. Desenvol-ver para essa plataforma tem uma relativa facilidade devido às tecnologias compartilhadas com o OS-X[56], que incluem o kernel OS-X, soquetes BSD para networking e compiladores Objective-C e C/C++para performance nativa [22]. Além disso, o iOS em conjunto com o framework Cocoa Touch, cria umaexperiência de interface para usuário de múltiplos toques (multi-touch), aumentando as possibilidadesde desenvolvimento de aplicativos para a plataforma. Todos os dispositivos recentes da Apple, isto é,lançados nos últimos 2 anos, possuem os sensores acelerômetro, giroscópio, magnetômetro, além de umacâmera posterior e outra anterior.

3.1 TECNOLOGIA GRÁFICA

A Open Graphics Library [1] é um padrão gráfico da indústria que possibilita a renderização deobjetos gráficos bidimensionais e tridimensionais, funcionando como uma interface de baixo nível entrea aplicação e a placa gráfica (GPU), demostrado esquematicamente na Figura 3.1. Essa ferramentafoi desenvolvida e mantida pelo consórcio Khronos Group. Ela possui um grande conjunto de funçõesque faz uso de praticamente todos os recursos do hardware de vídeo. Dentre os aspectos que podemser controlados pela API (Application Programming Interface) da OpenGL estão as cores, níveis detransparência, cálculos para controle de iluminação, sombreamento, neblina, etc. Encontra-se atualmenteem sua versão 4.4. Devido à característica móvel deste projeto, será adotada a OpenGL ES (EmbeddedSystem) [2], que é uma versão projetada especificamente para ambientes móveis como telefones celulares,PDAs e consoles de video games, restringindo algumas funcionalidades das versões principais, devido àslimitações de hardware desse tipo de dispositivos.

Figura 3.1: Interface aplicação-GPU [2]

A API da OpenGL ES encontra-se atualmente na versão 3.0, que assim como a sua versão anterior,

25

possui pontos programáveis no pipeline de renderização, o Vertex Shader e o Fragment Shader, ambosescritos com a Graphics Library Shader Language (GLSL). Neste projeto, será utilizada a versão 2.0 daOpenGL ES, penúltima versão disponibilizada.

3.2 TECNOLOGIAS DE COMUNICAÇÃO

Bluetooth Low Energy (BLE) [30], também conhecido como Bluetooth Smart, é uma tecnologia detransmissão de dados via rádio de sinais digitais na frequência de 2.4 GHz. Possui como principal dife-rencial um consumo energético extremamente baixo, em média 1 mA, principalmente devido ao fato dotráfego de dados limitado quando comparado a outras tecnologias, abrindo, dessa forma, espaço para umanova gama de aplicações, isto é, além dos tradicionais dispositivos que já utilizam a tecnologia Bluetoothclássica, o BLE é visto também em outros aparelhos como, por exemplo, relógios de pulso, sensores espor-tivos, brinquedos, sensores automotivos, além de encontrar diversas aplicações na medicina. Atualmente,diversos sistemas operacionais, incluindo iOS [22], Android [5], Windows Phone [70], BlackBerry [29],OSX [56] e Windows 8 [69] já são compatíveis com esse novo modelo de Bluetooth.

Neste projeto, o BLE será utilizado em conjunto com estruturas denominadas beacons como meiode captação de dados que possam modificar o estado de aplicações. Algumas alternativas ao BLE seriamo QR Code e o NFC, ambos são tratados no apêndice A deste trabalho.

3.3 TECNOLOGIA DE MICROLOCALIZAÇÃO

3.3.1 BEACON

Beacon [21] é um dispositivo que funciona como um sistema de detecção de proximidade para lugaresfechados ou de dimensões relativamente pequenas. O aparelho se comunica com outros dispositivostransmitindo pacotes em intervalos regulares de tempo através da tecnologia Bluetooth Low Energy,sendo capaz de detectar aqueles que estiverem em suas proximidades, desde que estejam com o Bluetoothativado, podendo inclusive calcular a que distância eles se encontram.

Um beacon possui ainda a capacidade de enviar mensagens e expô-las na tela do aparelho celularmesmo se os usuários não estiverem com o aplicativo aberto ou mesmo se estiverem com o celular bloque-ado, desde que o aplicativo esteja ao menos instalado. Tal fato surge como uma janela de oportunidadespara diversas aplicações, visto que caso beacons estejam dispostos em uma loja, prédio ou shopping,por exemplo, provavelmente quem passar próximo a um deles, receberá mensagens com informaçõesrelevantes.

Especificações Técnicas

26

O Estimote Beacon [39], modelo utilizado para a realização desse trabalho, é considerado um iBeaconpor se comunicar através do padrão tecnológico desenvolvido pela Apple. Trata-se de um pequeno super-computador, possuindo um processador 32-bit ARM® Cortex M0 CPU com 256kB memória flash,acelerômetro, sensor de temperatura e 2.4 GHz Bluetooth 4.0 Smart, também conhecido como BLE ouBluetooth Low Energy, envoltos por uma estrutura flexível feita de silicone. Na Figura 3.2 é possível verum beacon da marca Estimote em visão explodida.

Figura 3.2: Beacon da marca Estimote em visão explodida [41]

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

dade de pareamento prévio, e estimam sua distância através da força do sinal recebido, sendo que quantomais perto você estiver, mais forte será o sinal. Dependendo da implementação, aparelhos podem exami-nar o sinal a cada 1 segundo ou 10 vezes por segundo, quanto mais frequente for, mais estável será o sinale melhor a experiência do usuário. Além disso, é possível programar o aparelho para enviar mensagensdistintas de acordo com a região em que o usuário se encontra. É interessante ressaltar também que cadaaparato consegue receber o sinal de mais de um beacon de uma vez e, desde que instalado o aplicativoapropriado, estimar a distância relativa entre cada um deles.

O dispositivo Estimote utiliza a comunicação BLE através de um formato padronizado pela Appleno qual cada pacote transmitido consiste em cinco partes principais de informação:

• Prefixo iBeacon (9 bytes): String padronizada pela Apple para distinguir os aparelhos utilizandoseu padrão tecnológico;

• UUID (16 bytes): Utilizado para diferenciar um grande grupo relacionado de beacons. Caso elessejam utilizados em shopping, por exemplo, todos os beacons de uma mesma loja teriam, provavel-mente, o mesmo identificador UUID;

• Major (2 bytes): Utilizado para diferenciar pequenos grupos de beacons. No exemplo de umagrande loja, todos os beacons de um mesmo departamento teriam o mesmo 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 de distância do aparelhoe utilizado para determinar a proximidade que o usuário se encontra do beacon.

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

27

Figura 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 ambiente em queele está localizado, dado que o sinal pode ser difratado, sofrer interferência ou absorvido por água, porexemplo. Em geral, ele é capaz de enviar e receber sinais a distâncias que variam de 5 centímetros a atéaproximadamente 70 metros, sendo que essa distância é categorizada em 3 regiões distintas, como vistona Figura 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 de acordo com qualdas três regiões o usuário se encontrar.

Figura 3.4: Desenho esquemático das três regiões (near, far e immediate) de atuação do Estimote Beacon[40]

28

4 MODELAGEM E VISUALIZAÇÃO

Os componentes de modelagem e visualização apresentam soluções ligadas ao processo de renderiza-ção, isto é, ao processo que recebe a descrição de uma cena tridimensional em um espaço de coordenadaspróprio e produz uma imagem no espaço de coordenadas da tela do dispositivo de exibição. Este capítulodescreve as estratégias e alguns dos componentes implementados no framework que estão diretamenterelacionados com a atividade 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 que serão dispostosnas cenas utilizando este framework, é necessário enteder o conceito de um grafo de cena. Um grafo decena é uma estrutura de dados que permite gerenciar de maneira eficiente todos os elementos de umacena. Com esta estrutura, pode-se definir relacionamentos entre objetos da cena e criar hierarquias entreeles, unindo vários objetos em um grupo. Isto é muito útil, por exemplo, para que seja possível especificara posição e a orientação de um determinado objeto em relação a outro, sem que seja necessário saber aposiçã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 definidas como emum grafo comum (estrutura algébrica), no entanto há algumas restrições. Cada nó pode ter nenhumou muitos nós filhos, porém apenas um único nó pai. Isso evita que o grafo tenha ciclos. A cena serádefinida como o nó do qual todos os demais nós do grafo são descendentes. O grafo de cena é, portanto,um grafo acíclico e conexo, o que caracteriza uma árvore, em que a raiz representa uma cena, onde osdemais objetos estão presentes.

(a) (b)

Figura 4.1: Exemplo de Grafo de Cena

Cada objeto constitui um único nó e pode fazer parte de um grupo de objetos com um nó paiem comum. Assim, por exemplo, se quiséssemos desenhar um carro, poderíamos ter diversos objetoscomponentes como chassi, rodas etc, que fazem parte de uma única entidade: nó carro (Figura 4.1).Todas as transformações de um nó pai são propagadas para os nós filhos, portanto se o carro se locomovepara uma dada direção, todos os seus componentes também se locomovem para aquela direção, mas cadacomponente pode apresentar uma transformação própria que é levada em consideração em relação ao

29

carro; as rodas, por exemplo, podem rotacionar independente do chassi. Cada nó possui uma matriz detransformação local, que relaciona sua pose em relação ao nó pai, e uma matriz de transformação globalou do mundo, que define efetivamente o estado deste objeto na cena. A matriz de transformação globalé obtida multiplicando-se as matrizes de transformação local de cada nó ancestral do nó em questão pelamatriz de transformação local do próprio nó. Em nossa implementação, para facilitar algumas operaçõesfuturas, armazenou-se também as matrizes inversas de cada transformação como apresentado em [64].

A implementação do grafo de cena segue o padrão de projeto Composite (Objeto Composto) [44]. Aclasse SceneNode representa o nó base do grafo. Uma cena e qualquer objeto que pode estar presente emuma cena é descendente de SceneNode. DrawableNode é uma especialização de SceneNode que trata dosobjetos que podem, efetivamente, serem desenhados em tela. Nós que podem ser desenhados possuem umareferência a uma instância de uma malha poligonal 3D (Mesh), uma textura e respondem à mensagemdraw, delegada à malha, que executa chamadas à API da OpenGL. Os nós que não constituem objetos quepodem ser desenhados em tela repassam a mensagem draw para seus filhos e, portanto, não podem estarpresentes nos níveis mais profundos do grafo. É interessante notar que, com esta modelagem, objetosdesenháveis e não desenháveis podem ser tratados da mesma forma, isto é, sob a mesma interface, pelacena modelada.

SceneNode não é uma classe abstrata, pois há nós no grafo que representam apenas transformaçõesa serem aplicadas a um grupo de objetos. Referindo-se ao exemplo do carro, nesta modelagem, porrepresentar um agrupamento, um carro seria um SceneNode comum, porém cada parte do carro seria umDrawableNode.

4.2 MALHA POLIGONAL

Os objetos 3D são descritos por propriedades que podem ser traduzidas em números a partir deuma modelagem matemática. A abstração básica sobre a qual pode-se representar atributos de umobjetos são os vértices. Para aplicações gráficas, o conceito de vértice é muito mais abrangente queaquele utilizado no estudo na geometria plana ou espacial. Um vértice é um elemento que pode possuirvários atributos descritos por n-uplas ordenadas, 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çodelimitada entre um conjunto de arestas constitui uma face. Na etapa de modelagem, apenas os vérticespossuem propriedades atribuídas explicitamente, os elementos de ordem superior (arestas e vértices) têmsuas propriedades calculadas em função dos valores dos vértices que os compõem. A coleção de vértices,arestas e faces que descrevem a geometria de um determinado objeto denomina-se malha poligonal. Cadaum destes conceitos encontra-se ilustrado na Figura 4.2.

30

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

Na modelagem adotada neste trabalho, uma malha poligonal é responsável por encapsular atributosintrínsecos da geometria de um objeto, deixando como atribuição da instância de nó (DrawableNode)definir atributos extrínsecos como a cor ou a textura que será associada aos vértices da malha do objeto,além da matriz de transformação que define a pose e a escala do objeto. Desta forma, objetos comformas geométricas similares, que podem ser transformadas umas nas outras por meio de transformaçõeshomogêneas [63], 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 pararecuperar ou modificar os dados da geometria de um objeto. Por especialização de Mesh, pode-se escrevermalhas que representem a geometria de objetos específicos como, por exemplo, um cubo, um cilindro ouaté mesmo geometrias mais complexas.

Dado que as panoramas equirretangulares possuem uma associação natural com o sistema de coorde-nadas em latitude e longitude, cada camada é representada por uma malha poligonal de uma esfera cujosvértices foram obtidos por amostragem segundo uma discretização uniforme dos ângulos em coordenadasesféricas. Assim, é como se cada vértice possuísse sua coordenada de posição sobre a interseção entreum meridiano e um paralelo sobre a superfície da esfera (Figura 4.3). Essa parametrização nos permitecalcular com facilidade as coordenadas de textura de cada vértice e mapear uma imagem equirretangularcomo textura no interior da esfera.

Figura 4.3: Malha esférica com faces quadrangulares [59]

31

A classe SphereMesh é uma especialização de Mesh que implementa a geometria de uma esfera poramostragem uniforme em latitude e longitude. O acesso à malha foi implementado segundo o padrão deprojeto Singleton (Objeto Singular) [44] para que objetos com geometria similar à de uma esfera compar-tilhem uma instância única de malha, otimizando a ocupação da memória. Visando uma otimização dedesempenho, a classe SphereMesh possibilita que sejam solicitadas instâncias malhas em alta resolução(maior amostragem de vértices) ou em baixa resolução. Desta forma, sacrifica-se um pouco de memóriapor uma economia de processamento na renderização de objetos que não requeiram uma alto grau dedetalhamento.

4.3 PANORAMA COM CAMADAS

Uma panorama com camadas é implementada como um contêiner de esferas concêntricas ordenadaspelo tamanho de seu raio. Cada esfera tem uma imagem associada de forma que uma única cena sejagerada com os elementos de cada imagem dispostos de forma complementar. O mapeamento das imagenssobre a superfície das esferas e a transformação aplicada pela câmera, como será descrito na seção sobrea 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 componente umconjunto de imagens equirretangulares que, ao serem sobrepostas, compõem uma cena coerente. Umaforma de obter tais imagens é por meio da segmentação de uma imagem panorâmica primitiva em 2 oumais imagens, separando-se os objetos de acordo com suas distâncias relativas ao ponto de projeção dapanorama. A Figura 4.4, a Figura 4.5 e a Figura 4.6 ilustram a representação utilizada.

Figura 4.4: Imagem da camada mais externa

32

Figura 4.5: Imagem da camada intermediária

Figura 4.6: Imagem da camada mais interna

A camada mais externa contém a maior parte do conteúdo da imagem original. Nos locais ondeestavam localizados os objetos que foram segmentados para camadas mais internas, aplica-se um algoritmode reconstituição de imagem para que seja feito o preenchimento dos buracos remanescentes. Estesburacos são ocultados pelas camadas mais internas, porém é importante que essa reconstituição sejarealizada para que se possa explorar os efeitos de paralaxe, pois ao introduzir pequenas translações nacena, seria possível visualizar as regiões segmentadas da camada mais externa.

As imagens das camadas mais internas possuem apenas alguns objetos esparsos, com o restante daimagem com preenchimento transparente.

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

4.4 FERRAMENTAS MATEMÁTICAS

Trabalhar com OpenGL [1] exige a manipulação de muitos vetores e matrizes em operações comunsda álgebra linear, tais como produto escalar, produto vetorial, transposição de matriz, dentre outras. Porconta disso, inclui-se algumas classes para que fosse possível tratar com vetores e matrizes de uma forma

33

orientada a objetos e também que fosse possível retornar o endereço de memória que desse acesso aosdados de cada objeto, o que deve 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 duas etapas programá-veis: o vertex shader e o fragment shader. A Figura 4.7 representa um esquema simplicado do pipeline derenderização da OpenGL ES 2.0 [2]. Para maiores detalhes de como funciona o pipeline de renderizaçãoe como escrever código para as etapas programáveis, uma boa referência é [51].

Figura 4.7: Pipeline simplificado de renderização da OpenGL [51]

O vertex shader é responsável por realizar operações sobre vértices. Como definido na seção 4.2 sobre”Malha Poligonal”, vértice é uma abstração que possui uma posição no espaço, dada por suas coordenadascartesianas, e pode possuir outras propriedades como cor, coordenadas de textura, vetor normal, etc. Overtex shader recebe, por meio de chamadas da API da OpenGL, os atributos dos vértices sobre osquais irá operar e, 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 sobre cada vérticeindividualmente, embora possam ser definidos alguns parâmetros comuns a serem aplicados a todos osvértices. Utilizar o vertex shader para executar transformações sobre os vértices é mais eficiente do querealizar essas transformações previamente dentro da aplicação. Os dados resultantes do vertex shadersão passados como entrada para o fragment 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 da geometria da cena para aforma de pixel) [51, 63, 64]. O fragment shader é um programa que define como serão geradas as coresde cada fragmento e associa-as a eles. É nesta estapa do pipeline de renderização que são determinados

34

os atributos das arestas e faces de um objeto. Está intimamente relacionado, portanto, ao mapeamentode textura em superfí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 único programa de shader (shaderprogram), que será utilizado para a renderização dos objetos na cena. Características como propriedadesdos materias componentes dos elementos são definidas 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) da cena.

Como muitas das operações necessárias para se criar um programa de shader são comuns, definiu-seno framework uma classe Shader para encapsular todas essas operações, desde a leitura dos arquivosem que os programas se encontram. Assim, o usuário do framework tem que se preocupar apenas emmanipular um objeto de shader para cada programa de shader em sua aplicação e requisitar as informaçõesnecessárias (como endereç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 umamatriz de transformação, que aplicada aos elementos da cena produz uma determinada imagem paraa tela do dispositivo. No entanto, especificar diretamente esta transformação para atender às nossasnecessidades e produzir imagens da maneira que se deseja é uma tarefa complicada. Para se ter umcontrole adequado sobre esta transformação e sobre quais elementos da cena serão desenhados e comoeles serão desenhados na tela do dispositivo de exibição, é necessário que seja definida uma abstração decâmera virtual com parâmetros que podem ser estudados e compreendidos facilmente por um ser humano.

A API do OpenGL ES 2.0 não fornece uma abstração de câmera, como as versões anteriores, ficandoà cargo do programador implementar a sua própria abstração. A implementação da câmera para a arqui-tetura proposta segue um padrão peculiar, visto que para visualizar imagens panorâmicas, o observadorficará sempre fixo no centro de projeção da imagem. O modelo de câmera virtual adotado neste trabalhoé o modelo da câmera de furo (pinhole camera) [63, 64], comum em diversas aplicações de computaçãográfica.

Para construir uma abstração com parâmetros facilmente manipuláveis, a câmera foi dividida em trêstransformações aplicadas em uma ordem bem definida sobre os elementos da cena e geridas internamentepor uma instância da classe câmera. Cada transformação é representada por uma matriz quadrada deordem 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

Figura 4.8: Transformações componentes da câmera

Na Figura 4.8, a primeira transformação, dada pela model matrix representa o posicionamento doobjeto em relação ao mundo, isto é, qual é a pose e a escala do objeto que será desenhado em relaçãoao cenário 3D. Esta transformação não indica o posicionamento dos objetos em relação a elementos da

35

panorama, mas sim, o posicionamento do objeto em relação ao espaço em que a panorama também seencontra imersa. A segunda transformação, dada pela view matrix, representa a pose da câmera dentrodo cenário. Por último, aplica-se uma transformação de projeção (projection matrix ), representando avista em perspectiva.

Ainda na Figura 4.8, pode-se ver uma representação row-major por blocos da view matrix. O blocoR é constituído por uma matriz 3x3 que representa uma rotação. Os valores t

x

, ty

e tz

constituem umvetor do R3 que representa a posição da câmera neste espaço (o quanto ela transladou em relação àorigem). A última linha tem seus valores fixos. O produto matricial entre a view matrix e a model matrixresulta em uma matriz conhecida por ModelView Matrix, que representa os parâmetros extrínsecos dacâmera.

A projection matrix, por sua vez, representa os parâmetros intrínsecos da câmera. A projeção adotadaé a projeção perspectiva [33], que oferece uma boa aproximação do comportamento de câmeras reais. Atransformação de projeção define um tronco de pirâmide (frustrum) de visualização. Apenas os elementosque se encontram dentro do volume desse tronco de pirâmide são candidatos a serem desenhados, os demaisencontram-se fora do campo de observação da câmera. O plano mais próximo ao observador denomina-seplano near e o mais afastado, plano far (Figura 4.9).

Figura 4.9: Pirâmide de Visualização

Há, ainda, uma quarta matriz, que representa uma correção no posicionamento da câmera, que podeser necessária devido a erros de georreferenciamento de imagem, por exemplo. Esta matriz de correção éencapsulada dentro da classe câmera e incorporada automaticamente na view matrix, isto é, toda a vezque a aplicação necessita atualizar a view matrix, a instância de câmera corrente atualiza o valor já pósmúltiplicado pela matriz de correção.

4.6.1 ATUALIZAÇÃO DA CÂMERA

Nosso objetivo nesta etapa é obter uma matriz que represente a transformação de um vetor noreferencial global para um vetor no referencial do dispositivo. Esta matriz será incoporada à nossaabstração de câmera, representando o posicionamento da câmera efetivamente (view matrix). Como oponto a partir do qual a cena é visualizada é fixo, coincidindo com o centro da estrutura de camadasesféricas, a matriz que precisamos será sempre uma matriz de rotação, obtida a partir da orientação dodispositivo em relação ao mundo. A Figura 4.10 apresenta a convenção adotada pelo sistema iOS para

36

os eixos coordenados dos aparelhos.

Figura 4.10: Orientação dos eixos coordenados no sistema iOS [19]

Qualquer aparelho com um magnetômetro e um acelerômetro é capaz de estimar sua orientaçãoa partir das medidas obtidas para a magnitude da aceleração da gravidade nos eixos coordenados, daestimativa do norte magnético e da medida da aceleração adicional devida aos movimentos sobre oaparelho. O kit de desenvolvmento para iOS possui o framework Core Motion [19], que permite autilização ds dados dos sensores para se obter uma matriz de rotação que representa a orientação dodispositivo em relação a um referencial fixo do mundo (Plano XY paralelo ao solo, com X positivo àdireita e eixo Y positivo 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, sua inversa é 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, acrescentou-se perspectiva dinâmicana visualização das camadas do panorama. A inspiração para essa abordagem veio do trabalho [47],o qual foi feito em uma parceria entre o departamento de pesquisas de Redmond da Microsoft com oInstituto Indiano de Tecnologia localizado em Kanpur. Neste trabalho é estudado uma maneira de fundiros dados provenientes da detecção de faces através da câmera frontal do dispositivo com os dados colhidosdo 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 interface livre de toques,não sendo necessário tocar na tela para navegar pelo ambiente da cena e permitindo que o usuário utilizesomente uma mão para segurar o dispositivo. Além disso, utilizar esse tipo de interação é fácil e intuitivo.Um exemplo muito utilizado nas aplicações atuais é o movimento de pinça para ativar movimentos dezoom. Apesar de ser uma solução efetiva, é necessário o uso de dois dedos colados na tela para realizaro movimento, o que oculta uma significante porção da cena. Em aplicações que o usuário pode interagircom os elementos contidos na cena a partir do toque, se torna difícil corrigir a ambiguidade de que tipo

37

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 [16, 17]. Um dos recursosdesse framework é a API para detecção de faces [8, 49] que pode analisar e encontrar faces humanas emuma imagem. É importante ressaltar que ele realiza detecção de faces e não reconhecimento de faces.Detecção de faces é a identificação de retângulos que contém características de um rosto humano, enquantoreconhecimento de faces é 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 partir dele tambémpode-se rastrear a posição de uma face em um vídeo. Na Figura 4.11 pode-se ver um exemplo dessaferramenta em ação.

Figura 4.11: Core Image identifica limites das faces em uma imagem [20]

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

38

Figura 4.12: Comparativo da precisão do algoritmo de detecção de face [49]

A Figura 4.12 mostra um exemplo da API de detecção de faces em ação. As imagens ilustram adiferença entre as configurações de baixa e alta precisão. A localização das características detectadasnão são muito diferentes entre as duas imagens, porém o tempo para o algoritmo de alta precisão rodaré bem mais demorado que o de baixa precisão. O aplicativo utilizado para gerar esse exemplo pode serencontrado em [49].

A Apple disponibiliza uma aplicação básica para desenvolvedores chamada SquareCam [23] quepermite realizar a detecção de face utilizando o CIDetector [8] em tempo real através de imagem ouvídeo capturado pela câmera, exibindo um quadrado vermelho em torno da face. Outro exemplo deutilização dessa ferramenta pode ser encontrado em [65], no qual foi criada uma classe que pode serfacilmente adicionada a um projeto e utilizada para 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âmera frontal do dispositivo.Utilizando os frames capturados, a classe CIDetector realiza a detecção de face e retorna as informaçõesrelevantes para utilização na aplicação. Os dois principais métodos da classe TranslationManager são:getTranslation e getProximityFactor. O método getTranslation retorna um CGPoint, ou seja, um parordenado que representa o posicionamento da face em relação ao centro da tela do dispositivo. O métodogetProximityFactor retorna o valor da distância da face ao plano da tela do dispositivo. Esse resultadoé estimado a partir do tamanho do retângulo. Se o retângulo for grande, então o rosto está próximo dodispositivo e se for pequeno, o rosto está longe. Esses valores são normalizados e, portanto, variam dentrode um intervalo que vai de -1 a 1. Os limites de intervalo foram determinados experimentalmente.

Através da informação da distância do rosto, pode-se criar recursos de visualização mais interativas.Por exemplo, quando o usuário aproximar o rosto do dispositivo, pode ser aplicado um zoom na imagemvisualizada e quando o usuário afastar seu rosto, o zoom é desfeito. Na Figura 4.13 é possível visualizaro exemplo citado.

39

Figura 4.13: Zoom a partir da aproximação da face ao dispositivo [47]

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

Figura 4.14: Efeito de paralaxe a partir do posicionamento da face em relação ao dispositivo [47]

4.8 CICLO DE RENDERIZAÇÃO

Com toda esta estrutura construída, devemos definir uma forma de gerenciar esses elementos paradesenhar a cena de forma coerente. O ciclo da aplicação funciona basicamente em duas etapas: atualizaçãoe desenho. Estas duas etapas são coordenadas pelo controlador de cena (SceneViewController).

Na etapa de atualização, percorre-se o grafo de cena atualizando a matriz de transformação globalde cada nó, assim como a inversa desta matriz. Atualiza-se também a ViewMatrix com o a matriz deorientação obtida com a API do CoreMotion. Cada nó desenhável percorrido é adicionado a uma listaordenada pelo raio da camada em que ele se encontra, visando facilitar a etapa de desenho.

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

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

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

40

Na etapa de desenho, o controlador de cena percorre sequencialmente a lista ordenada de elementosdesenháveis, verifica se há necessidade de atualizar o programa de shader, baseado nas propriedades doobjeto a ser desenhado, e o atualiza se for necessário. Cada elemento é desenhado do mais afastado parao mais próximo à câmera, conforme o Algoritmo do Pintor [61, 66]. O fato de as camadas possuírem umaordem com intervalos bem definidos evita loops no grafo de oclusão da cena [61].

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

Figura 4.15: Projeção da panorama

Aplicando-se as transformações de câmera descritas e após a projeção da imagem sobre o interior damalha poligonal de uma esfera, como a apresentada na seção 7.1, pode-se visualizar a cena fotografadasem as distorções características do panorama equirretangular, dentro de um campo de visão restrito(Figura 4.15) . Todas as transformações citadas são aplicadas na ordem em que foram apresentadas acada 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.

41

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

Este capítulo trata das estratégias adotadas para a implementação dos componentes necessários paraa criação de aplicações interativas com este framework. A interação será feita pela tela sensível ao toquedos dispositivos. O sistema iOS já fornece o framework CocoaTouch [14] para tratar, dentre outras coisas,do reconhecimento de toques e gestos sobre a tela dos aparelhos. Esta etapa, portanto, consiste em comoutilizar este framework para gerar interações consistentes dentro do ambiente gráfico 3D proposto. Paraisso, é necessário identificar elementos da cena e permitir a exibição de conteúdos baseados no que foridentificado.

5.1 INTERAÇÃO

5.1.1 RAY PICKING

O CocoaTouch nos permite identificar que ponto sobre a superfície da tela foi tocado pelo usuário.No entanto, para que o usuário possa interagir com elementos de uma cena tridimensional, é precisoidentificar que ponto dentro do ambiente 3D foi tocado. A técnica de ray picking permite que essaidentificação seja feita baseada em traçado de raios. Nesta abordagem, quando o usuário toca em algumponto da tela, um raio é lançado na cena e, então, calcula-se qual objeto foi interceptado pelo raio,gerando uma resposta do sistema.

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

Para que os raios sejam lançados na cena coerentemente, algumas etapas de transformações devem serseguidas. Devemos determinar a que plano, mais precisamente, a que região plana, a tela do dispositivocorresponde dentro do espaço da cena. Ou seja, devemos mapear a tela do aparelho em uma regiãoplana dentro da cena para determinar o ponto origem e a direção do raio a ser emitido, como descritoa seguir. Pelo modelo de câmera virtual, podemos considerar que o raio tem origem sobre o plano nearda pirâmide visão. Conhecendo a ViewMatrix, 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

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

Precisamos escrever o referencial da câmera nas coordenadas do referencial global para obter cada umdestes vetores, o que equivale a inverter a rotação da ViewMatrix. A operação de inversão de uma matriz

42

normalmente é uma operação computacionalmente cara, porém como o bloco R é uma matriz de rotação,sua matriz inversa é igual à sua matriz transposta, que é fácil de computar. A figura Figura 5.1 ilustra amatriz R, bloco de rotação da ViewMatrix, e as coordenadas dos vetores H, V e L, das direções horizontal,vertical e de observação (look) respectivamente. Assim, as instâncias de câmera são capazes de respondera mensagens solicitando as direções horizontal, vertical e de observação como vetores normalizados doespaço R3.

Figura 5.2: Sistema de Coordenadas nativo da tela [25]

As coordenadas absolutas do ponto podem ser obtidas na forma de par ordenado (X, Y) pela APIdo CocoaTouch, assumindo como origem o ponto superior esquerdo da tela (Figura 5.2). Para trabalharde forma independente do tamanho da tela, adota-se um referencial normalizado em que a origem seencontra no centro da tela e o canto superior direito tem coordenanda (1,1) Duas transformações, por-tanto, devem ser realizadas: uma translação da origem para o centro da tela e uma rotação dos eixospara que, independente da orientação do aparelho, tenhamos o eixo Y alinhado com a direção verticalda 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

= posicaoCamera+direcaoObservacao⇤near+direcaoHorizontal⇤X+direcaoV ertical⇤YEquação 1

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

Raioorigem

= direcaoObservacao ⇤ near + direcaoHorizontal ⇤X + direcaoV ertical ⇤ YEquação 2

Em que posicaoCamera é o vetor que representa a posição da câmera na cena; view é o vetor querepresenta a direção de observação da câmera; near é a distância entre a câmera e o plano de recorte maispróximo do observador; h é o vetor que representa a direção horizontal, com magnitude igual a metade docomprimento total do plano nesta direção; v é o vetor que representa a direção vertical, com magnitude

43

igual à metade do comprimento total do plano nesta direção; e X e Y são os valores normalizados querepresentam a posição do toque do usuário na tela.

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

Raiodirecao

= Raioorigem

� posicaoCamera Equação 3

Figura 5.3: Ray Picking [58]

Todo objeto passível de interação deve, portanto, implementar um método que recebe um raio ecalcula se há intersecção com este raio. Para isso, foi criada a classe Interactable, que funciona como umprotocolo, mas implementado com herança múltipla, visto que essa camada do framework foi desenvolvidaem C++.

A interseção é calculada com base na geometria do objeto, sendo necessário determinar se existeum parâmetro real que seja solução de um sistema de equações resultante da substituição da equaçãoparamétrica do raio na equação implícita da superfície que representa o objeto [64]. Superfícies simplescomo uma esfera ou um cubo possuem formas simples de se calcular a interseção, porém superfícies degeometria mais complexa podem tornar esta tarefa muito difícil. Algumas estratégias de aproximaçãopodem ser utilizadas para simplificar o tratamento de superfícies de geometria complexa. A mais comumdelas é a de não testar a interseção com o objeto, mas sim com sua caixa envolvente ”bounding box ” [64],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ão de modela-gem por primitivas geométricas [64], em que cada primitiva é modelada matematicamente por equaçõessimples, ficando a sua pose no espaço determinada por uma transformação projetiva (matriz de trans-formação global). Portanto, para determinar se o raio dado intersecta ou não um determinado objeto,primeiramente, é necessário aplicar a transformação inversa do objeto em relação ao mundo sobre o raio,permitindo que eles estejam no mesmo referencial .

44

5.1.2 CAMADA DE COLISÃO

Agora que é possível determinar um ponto no espaço onde o usuário tenha realizado um toque, énecessário um mecanismo para determinar uma região interativa da cena, como um dado objeto, porexemplo. Uma possível abordagem para esse problema seria utilizar billboards. Billboards são polígonosque estão sempre voltados para a câmera e que podem simular objetos tridimensionais, para mais deta-lhes, ver o apêndice B. O mecanismo consistiria em posicionar polígonos transparentes sobre as regiõesinterativas e testar a interseção dos raios com cada polígono para determinar que resposta deve ser dadaao usuário.

Contudo, para este trabalho, resolvemos implementar uma solução baseada na utilização de umacamada especial apenas para a interação. A implementação desta solução é mais simples e apresentauma complexidade maior em memória, porém pode ser mais eficiente em processamento, dependendoda quantidade de regiões interativas. Esta proposta consiste em produzir uma nova imagem a partirda imagem panorâmica que se pretende visualizar, de tal forma que essa nova imagem contenha apenasas regiões interativas, 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çãodo 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.

Figura 5.4: Camada de Interação

A Figura 5.4 apresenta um exemplo de imagem para a camada de interação. Quatro itens forammarcados como interativos, a porta em azul, um quadro em verde, a televisão em vermelho e o ornamentosobre a mesa de centro foi marcado em roxo. O restante da imagem é apresentado em preto e brancoapenas para que o leitor possa fazer uma comparação com a Figura 2.2, imagem original. A cor dasdemais regiões não é relevante desde que seja diferente das cores escolhidas para cada região interativa,contudo recomenda-se que elas sejam deixadas completamente em uma única cor, por exemplo o preto,para que compressão do arquivo seja mais eficiente.

A vantagem deste mecanismo é que calcula-se apenas uma interseção. Por outro lado, utiliza-se umaimagem completa, armazenando-se em memória dados sobre regiões onde não há interações disponíveis.Para economizar espaço de memória, a imagem utilizada na camada de interação tem uma resolução 16

45

vezes menor que as imagens utilizadas nas demais camadas, que são desenhadas.A camada de interação não é um objeto desenhável em tela, sendo um objeto estático na 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 e encaminha umraio para a cena, que o direciona para cada objeto interativo do grafo de cena. Ao receber um raio, umapanorama com camadas encaminha-o para a sua camada de interação, que computa o ponto de interseçãodo raio e, a partir dele, reconstrói a coordenada de textura correspondente e interpola os pixels da imagemdemarcada para interaçã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 estrutura chama iNode(index node).

Determinar que ação será executada após a identificação de um toque sobre uma região interativaé um problema a ser solucionado pela implementação de um ambiente de autoria. Utilizando apenas oscomponentes implementados neste framework, esta decisão é deixada exclusivamente sobre o desenvolve-dor que o utilizará como uma das ferramentas de sua aplicação. No entanto, disponibiliza-se integrada aoframework uma solução para simples exibição de conteúdo estático em forma de imagem e texto, comoilustrado na Figura 5.5.

Figura 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 controlador de cena ummapeamento entre o conteúdo que se deseja exibir e as cores dos elementos interativos. Este mapeamentoé feito por meio de unidades de conteúdo (ContentUnit), objetos que detém um vetor do R3 com as

46

coordenadas RGB da cor e a referência a um arquivo de texto e outro de imagem que irão compor oconteúdo apresentado ao usuário.

5.2 MICROLOCALIZAÇÃO

A fim de possibilitar a interação entre um ibeacon e um dispositivo com tecnologia BLE a Appleintroduziu novos recursos no seu framework Core Location [18] que, essencialmente, permite ao usuáriodeterminar a localização atual de seu dispositivo utilizando o hardware disponível. Através da implemen-tação de suas classes e protocolos é possível definir regiões geográficas, monitorar quando um usuário asatravessa e enviar notificações para os mesmos.

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 para tratar dos emissores deBluetooth Low Energy. Através desses recursos posteriormente introduzidos pela Apple é possível nãosó monitorar iBeacons, mas também dispositivos que estejam atuando como um. Utilizando recursos doCore Bluetooth Framework [15] é possível desenvolver aplicações de tal tipo para aparelhos com iOS eMacbooks, 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 trabalho assim comoa classe BeaconManager criada a fim de auxiliar a interação entre os dispositivos através da tecnologiaBLE.

5.2.1 CLBEACON

CLBeacon [10] é a classe do framework Core Location [18] que representa o beacon encontradodurante o monitoramento da região. Instâncias dessa classe não são criadas diretamente. Um objetoda classe CLLocationManager [12] é responsável por reportar os beacons encontrados e suas informaçõespodem ser utilizadas para sua identificação.

Possui seis propriedades que permitem identificar e localizar cada dispositivo, sendo elas:• ProximityUUID : representa o UUID do beacon ou de um grupo de beacons;• Major e Minor : valores opcionais utilizados para auxiliar na identificação dos beacons, geralmente

utilizado para separar um grupo de beacons representado pelo mesmo UUID 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.

47

5.2.2 CLBEACONREGION

Um objeto da classe CLBeaconRegion [11] define uma região baseada na proximidade com um dispo-sitivo emissor de sinal Bluetooth, essa região estará basicamente buscando dispositivos cuja identificaçãocoincida com a informação fornecida pelo usuário.

Essa identificação funciona da seguinte maneira: cada região definida possui, assim como os beacons,um UUID, um major e um minor e utilizará essas propriedades para verificar se o aparelho encontradoestá entre os que devem ser monitorados.

A priori, não é de interesse do aplicativo desse trabalho enviar notificações para o usuário de acordocom seu posicionamento relativo ao emissor de sinal bluetooth, mas apenas determinar sua localização.Todavia, as notificações são vistas na verdade como o grande avanço obtido com os beacons quandocomparado com outros tipos de tecnologias, dado que mesmo com a aplicação estando em backgroundé possível que um usuário as receba. Visto isso, foi implementado apenas o envio dessas notificaçõesatravés do método sendNotificationsForRegion. Caso no futuro seja de interesse utilizá-las, é necessárioapenas desenvolver a parte da aplicação na qual essas mensagens são definidas e introduzidas pelo usuáriojuntamente com cada região.

5.2.3 CLLOCATIONMANAGER

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

Existem dois métodos distintos para o gerenciamento da localização, o primeiro deles, startMonito-ringForRegion permite determinar quando um dispositivo entra ou sai da vizinhança de um beacon. Apósregistradas as regiões a serem monitoradas, serão recebidos call-backs constantes de acordo com os méto-dos do protoclo CLLocationManagerDelegate [13] no qual será possível determinar qual o estado efetivodo dispositivo monitorado. Para interromper o monitoramento, utiliza-se stopMonitoringForRegion.

Nessa aplicação, para o controle de localização do beacon, o método desse protocolo que é implemen-tado é o didDetermineState. Existem três tipos de valores de retornos distintos possíveis o primeiro, CL-RegionStateUnknown, utilizado quando o estado da região ainda não é determinado. CLRegionStateInsidee CLRegionStateOutside quando o dispositivo está, respectivamente, dentro ou fora da CLBeaconRegionespecificada.

Apenas quando determinado que o beacon está dentro da região monitorada é possível utilizar osegundo método de gerenciamento, startRangingBeaconsInRegion. Através dele é possível receber notifi-cações quando a distância relativa entre os dispositivos, com isso obtém-se informações mais detalhadase não apenas a simples inferência se o beacon está dentro ou fora da área de atuação. Para o presentetrabalho esse último método é essencial dado que ter informações acerca da proximidade em relação aosbeacons é primordial para a aplicação desenvolvida. Tais dados são recebidos através de três proprieda-des diferentes: proximity, accuracy e RSSI. Analogamente ao anterior, para interromper o rastreamento,utiliza-se stopRangingBeaconsInRegion.

48

5.2.4 BEACONMANAGER

Essa classe foi criada a fim de permitir que o componente de visualização do aplicativo esteja sempreatualizado em relação a qual dispositivo emissor deve ser considerado como referência, e dessa formagarantir uma melhor experiência ao usuário.

Para tanto, foi modelada uma máquina de estados finitos com N+1 estados, em que N é o númerode beacons que estão sendo monitorados em um determinado instante. As passagens de um estado paraoutro acontecem de acordo com a força do sinal recebido. Na Figura 5.6 temos um exemplo de diagramapara três estados.

Figura 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 estado monitora-se aárea ao redor do usuário a fim de encontrar algum dispositivo dentro da região de ativação, que para ocaso de teste deste trabalho foi definida como a área compreendida pelas regiões Immediate e Near pré-definidas pelo padrão da Apple. Enquanto em um estado diferente de S0, monitora-se o sinal recebidodo beacon de referência e apenas quando o beacon estiver fora da região de ativação pré-estabelecida,retorna-se ao estado S0.

Através do método startLookingForReferenceBeacons, implementado de acordo com a modelagemdescrita acima, o aplicativo recebe informações a respeito da distância relativa entre o usuário e todos osbeacons 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 que a 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ção do 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 dessas informações, éimplementado o protocolo BeaconClient que o permite, através do BeaconDidChangeID receber notifi-cações sempre que o valor de referência for atualizado. Dessa maneira, ele terá a informação necessáriapara decidir qual panorama deve ser exibido pela aplicação. Para o caso de encontrar-se no estado S0,isto é, sem nenhum beacon de referência, será exibido, no caso de testes elaborado, uma planta baixa

49

com a disposição dos emissores e dos objetos com que a pessoa poderá interagir, a fim de aprimorar aexperiência do usuário.

50

6 O FRAMEWORK

O framework projetado constitui uma infraestrutura para o desenvolvimento de aplicações móveisbaseadas em imagens panorâmicas e que queiram fazer uso dos sensores de atitude, da câmera e da telasensível ao toque para interação e ou visualização com a cena proposta. O framework não trata, portanto,do domínio da aplicação, sendo esta definição de responsabilidade do decisor do projeto. Embora a pro-posta de imagens panorâmicas em dispositivos móveis possa parecer bastante específica, há uma variedadede aplicações que podem ser desenvolvidas sobre esta infraestrutura, tais como games, guias virtuais paraambientes in-doors como hotéis, restaurantes e museus, além de simuladores. Notavelmente, aplicaçõescentradas em realidade aumentada indireta podem fazer uso de mais componentes do framework e sebeneficiarem da microlocalização para tornar a experiência mais agradável, principalmente em ambientesfechados.

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

A nomenclatura dos componentes segue um padrão em que antes do nome de cada classe adiciona-seduas letras para indicar o framework de origem, servindo também como uma forma de modularização emnamespace. Este padrão é adotado por diversos frameworks comerciais, inclusive os próprios frameworksdisponíveis por padrão no ambiente de desenvolvimento da Apple, tais como Core Motion (CM), CoreLocation (CL) e Core Foundation (CF). As iniciais escolhidas foram LP (Layered Panorama) por repre-sentar panorama com camada.

A documentação dos componentes bem como o diagrama de classes do framework encontram-se naseção de apêndices deste trabalho. A documentação encontra-se em inglês, assim como o código fonte,para facilitar o entendimento por desenvolvedores de outros países que desejem, eventualmente, utilizaro framework.

6.1 ESTRUTURA DOS COMPONENTES

Nosso objetivo é prover ao usuário do framework os componentes necessários para que seja possíveldescrever uma cena utilizando uma imagem omnidirecional, especificar áreas interativas dentro desta cenae responder às interações do usuário com conteúdo específico à cena em questão. Para atingir este objetivo,o framework possui componentes de modelagem e visualização, de interação e de microlocalização. AFigura 6.1 ilustra o relacionamento entre os componentes.

51

Figura 6.1: Relação entre os componentes

O controlador de cena (SceneViewController) é responsável por gerenciar os eventos que ocorremna tela do dispositivo, como toques e gestos, além de gerenciar o ciclo de renderização da OpenGL, desdea configuração de estados na inicialização, passando pelos ciclos de atualização e de desenho de cadaquadro em tela e também pela liberação dos recursos de hardware nos momentos em que o aplicativo écolocado em segundo plano ou finalizado. É o controlador de cena que gerencia a interação do usuáriocom a cena, gerando os raios, recebendo as respostas de intersecções e utilizando as unidades de conteúdopara acionar outros gerenciadores.

O controlador de cena, portanto, age como mediador [44] de vários subsistemas que devem serintegrados. Os componentes de modelagem e visualização foram implementados na linguagem C++,por questões de portabilidade e de eficiência, enquanto os demais componentes foram implementadosem 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 linguagensdiferentes, sendo o controlador de cena o único componente em Objective-C++.

O gerenciador de sensores (SensorManager), monitora os dados dos sensores de atitude que sãorecebidos já de forma integrada através da API do framework Core Motion, e os dados da detecção defaces, tratados pelo gerenciador de translação (TranslationManager). Este componente é responsável porintegrar estas fontes de informações sobre a direção de observação do usuário e calcular uma matriz queserá utilizada pela câmera como a ViewMatrix. Durante o ciclo de renderização, o controlador de cenasolicita a transformação da ViewMatrix 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 por toda a apli-cação, mesmo quando a cena 3D não é a tela corrente em exibição. Esta característica se deve ao fato deque aplicações que utilizam beacons o fazem para determinar qual conteúdo será exibido e/ou como eleserá exibido, podendo a situação ser modificada constantemente de acordo com a localização do usuáriono ambiente.

52

O controlador de cena possui uma referência para a cena corrente. Todos os elementos que serãodesenhados na tela são nós descendentes da cena corrente. Portanto, para se comunicar com algumelemento da cena, lançando um raio, por exemplo, o controlador de cena tem que encaminhar umarequisição para a cena e aguardar a resposta. A cena realiza o redirecionamento dessa requisição enquantofor necessário, segundo o padrão de projeto Cadeia de Responsabilidade (Chain of Responsability) [44] e,quando obtém uma resposta, 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 fixa do framework,de forma que não há necessidade de especializá-los para utilizá-los. Estes componentes podem ter o seucomportamento configurado pelo cliente e se comunicam com ele por meio de protocolos.

Dentro do grafo de cena há bastante espaço para adições personalizadas pelo usuário. O frameworkfornece apenas elementos básicos para manter estados e realizar operações sobre camadas de panoramas,tais como uma malha poligonal de esfera, um nó desenhável de uma esfera ou uma panorama com camadas.Caso seja necessário, o usuário pode implementar outras formas geométricas derivando uma malha a partirda classe Mesh e 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 de interseções comum raio.

Uma cena é um componente que deve ser especializado em quaquer aplicação. Por conta disso,a classe LPScene foi transformada em uma classe abstrata. Dessa forma, é necessário escrever umaespecialização de LPScene para cada aplicação, pois é nessa classe que define-se os componentes da cenae o estado em que eles serão inicializados no programa. Definir a estrutura de uma cena e organizartodo o conteúdo para visualização ou interação pode ser uma tarefa custosa de se realizar manualmente.A criação de um ambiente de autoria para ser integrado ao framework poderia solucionar este probemacomo será abordado na seção 6.3.

A diferença da utilização do framework para aplicações em realidade aumentada e aplicações quenão considerem a realidade aumentada está, basicamente, na navegação dentro da cena e entre as cenasgeradas para a aplicação. Em uma aplicação de realidade aumentada, é necessário que o usuário estejapresente fisicamente no ambiente em que as interações serão propostas. Dessa forma, há determinadosconteúdos que fazem sentido serem exibidos quando o usuário se localiza próximo a determinados pontos,que podem ser identificados por beacons, e há outros conteúdos que devem ser omitidos até o momentooportuno para que não haja prejuízo da experiência. Naturalmente, aplicações de realidade aumentadautilizam mais componentes do framework, relizando mais trabalho de processamento em tempo real.

Em uma aplicação cujo objetivo não seja alcançado somente por meio da realidade aumentada,como, por exemplo um jogo ou um aplicativo utilizado para promover ou vender um espaço comercialou residencial, pode-se permitir ao usuário ter acesso ao mesmo conteúdo em uma cena independente deonde ele se encontre fisicamente. Várias cenas podem ser interligadas de modo a permitir a navegaçãodo usuário entre elas.

53

6.3 AMBIENTE DE AUTORIA

Este trabalho detém-se à implementação de cada componente apresentado para este framework.Contudo, para um uso efetivo do framework na concepção e disseminação de aplicações móveis, é de-sejável que hava um esforço na implementação e integração de um ambiente de autoria para facilitara geração e a organização de conteúdo em representações compatíveis com o que foi proposto. Assim,desenvolvedores sem conhecimentos específicos sobre os conceitos apresentados neste trabalho poderiamconstruir aplicações completas mais facilmente.

Neste projeto, para a relização de testes dos componentes do framework, realizou-se a autoria ma-nualmente, isto é, codificando-se cada elemento necessário para a composição de uma cena. Após esseprocesso, levantou-se as seguintes necessidades para um ambiente de autoria:

1. Segmentação de uma imagem panorâmica em camadas e definição da prioridade entre 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 tridimensionais nacena.

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

5. Cadastramento dos beacons e dos eventos iniciados em cada região de microlocalização.

A construção de um ambiente de autoria, portanto, passa pela automatização de alguns processos comoo cadastramento dos beacons para microlocalização e a definição de regiões interativas, e também pelodesenvolvimento de recursos complexos como a segmentação de uma imagem em camadas. Para inserçãode outros modelos 3D dentro das cenas, pode-se criar mecanismos para suportar a leitura de arquivosnos formatos mais populares para se exportar modelos (.obj, .wrl, .off, .blen etc).

6.4 ANÁLISE DOS RESULTADOS

Na perspectiva dinâmica, algumas dificuldades foram detectadas referente à detecção de faces. Re-alizar a detecção de faces é custoso e, portanto, gera latência. Além disso, os algoritmos de visão paraacompanhar a posição e o tamanho rosto são inerentemente ruidosos, nos quais pequenas mudanças noformato do rosto e da iluminação pode produzir sinais inesperados. Isso pode ser superado através do usode algoritmos de filtragem temporal, ainda que ao preço de mais de latência. O algoritmo escolhido parasolucionar o problema do ruído foi o filtro de média móvel [43], o qual é obtido calculando-se a médiade um conjunto de valores, sempre descartando o valor mais antigo e adicionando o valor mais recentea cada iteração. Quando maior a janela escolhida, número de valores que irão compor a média, maissuave será a variação dos valores recebido dos sensores, porém mais tempo de processamento é necessário.Experimentalmente foi detectado um valor de janela que permite a suavização do sinal e não prejudica aexperiência na visualização da paralaxe na cena.

54

Um outro problema observado com o recurso de perspectiva dinâmica foi o deslizamento dos objetospor sobre o chão quando tentamos observá-los sobre outra perspectiva. Este efeito pode ser observadoao compararmos as posições dos pés da mesa na Figura 6.2a e na Figura 6.2b. Isto se deve à modelagemde esferas concêntricas escolhida para as camadas. Nesta modelagem, não estamos considerando asprofundidades dos pontos da cena, então as camadas definem apenas uma ordem de prioridade paradesenho. Desta forma, objetos que se encontrem em uma mesma camada encontram-se a uma mesmadistância do observador e objetos que estejam em camadas diferentes encontram-se em profundidadesdiferentes, mesmo que eles tenham alguma superfície em comum.

(a) (b)

Figura 6.2: Deslizamento aparente dos objetos sobre o chão

Esse resultado mostra que para cenas onde há um acoplamento entre as camadas, isto é, em queelementos de camadas diferentes estão dispostos de forma a encostar uns nos outros, um modelo maiselaborado, que considere a profundidade dos pontos é necessário. Mesmo que a profundidade real decada região da cena não possa ser recuperada, é preciso que haja consistência entre as profundidades dosobjetos.

Em particular, é natural que em praticamente qualquer cena haja objetos apoiados sobre o chão. NaFigura 2.2, por exemplo, há um sofá, uma mesa, dentre outros móveis, que estão apoiados sobre o chãoda sala. O trabalho [42] utiliza imagens panorâmicas com cartas de profundidade para reconstruir ummodelo do ambiente e realizar experimentos de realidade aumentada. Uma representação similar poderiaser utilizada para a obtenção de camadas com profundidades consistentes e tratamento desta situaçãoparticular de objetos que, mesmo apoiados sobre o chão, apresentam movimento aparente em relação aele.

Unindo-se esta informação de profundidade para a reconstrução das malhas das camadas mais in-ternas, pode-se modelar o chão da cena como um plano que tangencia todos os objetos apoiados. Aimplementação e teste desta abordagem segue como uma proposta de trabalho futuro.

55

7 CONCLUSÃO

Há, ainda, muito o que se explorar no campo das imagens panorâmicas. A experiência proporcionadapor imagens interativas pode ser explorada tanto para a imersão em ambientes virtuais, quanto paraaplicações em realidade aumentada. A arquitetura baseada em camadas contribui para a exploração decaracterísticas tridimensionais da imagem ao considerar uma profundidade relativa entre os elementosda cena. Os dispositivos móveis atuais possuem poder computacional e recursos adequados para umaexperiência interativa e de realidade aumentada utilizando imagens.

Como propostas de trabalhos futuros, sugere-se a integração de um método para obtenção da re-presentação de imagem necessária como entrada para as aplicações, isto é, panoramas segmentadas emcamadas. Isto poderia passar pela pesquisa de um método automatizado baseado na captura de pano-ramas com profundidade ou na estimação da profundidade dos elementos na cena a partir de técnicasde estereografia. Uma outra abordagem poderia ser a criação de uma interface de usuário para que estasegmentação fosse realizada 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áriodo framework definiria, como etapa preliminar da aplicação, onde e como segmentar a imagem.

O suporte à geração de animações por sobre as imagens originais também constitui um enriqueci-mento aos recursos do framework. Estas animações poderiam ser utilizadas na geração de imagens comum aspecto vivo, contribuindo, por exemplo, na formulação de simuladores. Em uma aplicação paramuseus, por exemplo, poder-se-ia animar olhos de personagens em quadros famosos dando característicaslúdicas à aplicação.

Embora o enfoque deste projeto tenha sido a visualização e interação com imagens, em particularimagens omnidirecionais, não se exclui a possibildiade de uma abordagem mista. A modelagem tridi-mensional possibilita interações mais flexíveis com os objetos, pois modelos 3D podem ser manipuladoslivremente por transformações projetivas e podem ser visualizados sob qualquer direção. Uma abordagemmista, em que utiliza-se panoramas e modelos 3D dentro da mesma cena poderia se beneficiar do menorcusto de modelagem das imagens e da maior flexibilidade dos modelos. Esse experimento poderia serrealizado por meio da extensão do grafo de cena do framework.

A integração de um ambiente de autoria que abrangesse os componentes desenvolvidos, facilitaria aconstrução de cenas e a organização de conteúdo pelos usuários do framework.

56

8 REFERÊNCIAS BIBLIOGRÁFICAS

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

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

[3] ADELSON, Edward H.; BERGEN, James R. The Plenoptic Function and the Elements ofEarly Vision, Cambridge, MA: MIT Press, 1991.

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

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

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

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

[8] Apple Developer. CIDetector Class Reference: https://developer.apple.com/library/ios/ DO-CUMENTATION/CoreImage/Reference/CIDetector_Ref/index.html - acessado em 25 de julho de2014

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

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

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

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

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

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

[15] Apple Developer. Core Bluetooth. https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetooth_concepts.pdf - aces-sado em 25 de julho de 2014

57

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

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

[18] Apple Developer. Core Location Framework Reference. https://developer.apple.com/ li-brary/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/index.html — aces-sado em 25 de julho de 2014.

[19] Apple Developer. Core Motion Framework Reference. https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CoreMotion_Reference/index.html — acessado em 23 de ju-lho de 2014.

[20] Apple Developer. Detecting Faces in an Image: https://developer.apple.com/library/ios/ docu-mentation/graphicsimaging/conceptual/coreimaging/ci_detect_faces/ci_detect_faces.html - aces-sado em 25 de julho de 2014

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

[22] Apple developer. iOS Dev Center: https://developer.apple.com/devcenter/ios/index.action - aces-sado em 23 de julho de 2014.

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

[24] Apple Developer. UIAcceleration Class Reference: https://developer.apple.com/library/ios/documentation/uikit/reference/uiacceleration_class/Reference/UIAcceleration.html — acessado em23 de julho de 2014.

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

[26] AZUMA, Ronald; BISHOP, Gary. Improving Static and Dynamic Registration in an OpticalSee-through HMD. Department of Computer Science - University of North Carolina at ChapelHill, 1994.

[27] AZUMA , Ronald T. - A Survey of Augmented Reality - Presence: Teleoperators and VirtualEnvironments 6, 4 (August 1997).

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

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

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

[31] Bluetooth Technology. Bluetooth Smart Technology: Powering the Internet of things.http://www.bluetooth.com/Pages/low-energy-tech-info.aspx — acessado em 17 de abril de 2014.

58

[32] BROOKS, Frederick P. Jr. - The Computer Scientist as Toolsmith II. CACM 39, 3 (March1996).

[33] CARVALHO, Paulo Cezar; VELHO, Luiz; MONTENEGRO, Anselmo Antunes; PEIXOTO, Ade-lailson; SÁ, Asla; SOARES, Esdras. Fotografia 3D. IMPA: 25° Colóquio Brasileiro de Matemática,2005.

[34] CHANG, Yu-Hsuan, CHU, Chung-Hua, CHEN, Ming-Syan. A General Scheme for ExtractingQR Code from a non-uniform background in Camera Phones and Applications, SimpósioInternacional de Multimídia - IEEE, 2007.

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

[36] CRAIG, Alan B. Understanding Augmented Reality - Concepts and Applications.Waltham, EUA: Elsevier, 2013.

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

[38] Erick-nl – https://www.flickr.com/photos/erik-nl/185125112/in/set-1001899 – acessado em 18 demaio de 2014.

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

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

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

[42] FELINTO, D.; ZANG, A. R.; VELHO, L. Production framework for full panoramic sceneswith photo-realistic augmented reality. XXXVIII Conferencia Latinoamericana en Informática,2012.

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

[44] GAMMA, Erich; HELM, Richard ; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Ele-ments of Reusable Object-Oriented Software. Pearson Education, 1995.

[45] GROHS, Emanuel Motta, MAESTRI, Patrick Renan Bernardes. Realidade Aumentada paraInformações Geográficas. Pontifícia Universidade Católica do Rio Grande do Sul, 2002.

[46] ISO/IEC 18004:2006. Information technology - Automatic identification and data capturetechniques-QR Code 2005 bar code symbology specification, 2006.

[47] JOSHI, Neel; KAR, Abhishek; COHEN, Michael. Looking At You: Fused Gyro and FaceTracking for Viewing Large Imagery on Mobile Devices. SIGCHI, 2012.

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

59

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

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

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

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

[53] NOSOWITZ, Dan. Everything you need to know about near field communication. PopularScience Magazine. Popular Science, 2011.

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

[55] OLSSON, Carl; KAHL, Fredrik; OSKARSSON, Magnus. The Registration Problem Revisited:Optimal Solutions From Points, Lines and Planes. Centre for Mathematical Sciences LundUniversity: Sweden, 2006.

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

[57] 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 de 2014.

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

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

[60] SHUM, Heung-Yeung; HE, Li-Wei. Rendering with Concentric Mosaics. In Proceedings SIG-GRAPH, 1999.

[61] SNYDER, John; LENGYEL, Jed. Visibility sorting and compositing without splitting forimage layer decompositions. In Proceedings SIGGRAPH, 1998.

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

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

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

[65] VERMEER, Edwin. EVFaceTracker: https://github.com/evermeer/EVFaceTracker - acessado em28 de julho de 2014

60

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

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

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

[69] Windows 8: http://windows.microsoft.com/pt-br/windows-8/meet - acessado em 25 de julho de2014.

[70] Windows Phone: http://www.windowsphone.com/pt-BR - acessado em 25 de julho de 2014.

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

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

61

APÊNDICEA TECNOLOGIAS DE TRANSMISSÃO DE DADOS

Esta seção de apêndice aborda mais detalhes relativos às tecnologias de transmissão de dados con-sideradas 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 das atividades éconcentrada no controlador, a fim de permitir que o Host durma durante longos períodos e desperteapenas para executar uma ação específica, minimizando assim o gasto energético.

Para efetuar a interação entre dispositivos, o BLE utiliza os canais de dados e os de anúncio. Sendoque os primeiros ocupam quase a totalidade dos canais, 37 dos 40 disponíveis, e são utilizados nascomunicações bidimensionais entre dispositivos conectados entre si. Já o segundo tipo ocupa apenas ostrês restantes e possui como objetivos detectar outros aparelhos que estejam nas proximidades e realizartransmissão em broadcast.

A comunicação BLE consiste em dois eventos principais: Anúncio e Conexão. No primeiro deles oaparelho anunciador envia, em modo Broadcast, pacotes de dados em intervalos regulares de tempo quevariam de 20ms a 10s. Já no segundo, o dispositivo iniciador aguarda eventuais anunciadores nos canaisde anúncio e, ao encontrar, envia uma requisição de conexão P2P entre ambos, na qual, possuirá poderde interrompê-la a qualquer momento.

De acordo com informações oficiais disponíveis no website do desenvolvedor da tecnologia, o BLEpossui as seguintes especificações técnicas: [30, 31]

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

• Frequency Hopping: Utiliza o AFH ou Adaptative Frequency-Hopping spread spectrum, o mesmoutilizado em todas as versões da tecnologia Bluetooth padrão para minimizar a interferência deoutras tecnologias que utilizem a mesma frequência;

• Latência: Possui suporte para latências de estabelecimento de conexão e transferência de dados de3ms;

• 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 todos os pacotes paragarantir uma forte robustez contra interferência;

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

62

• Topologia: Possui um endereço de acesso de 32 bits em todos os pacotes para cada dispositivoescravo, permitindo dessa forma que bilhões de dispositivos estejam conectados ao mesmo tempoutilizando a topologia estrela, entretanto a tecnologia é otimizada para conexões entre dois dispo-sitivos apenas.

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

A.2 NEAR FIELD COMMUNICATION

A Near Field Communication (NFC) [52] ou, em português, Comunicação por Campo de Proxi-midade é uma tecnologia de transmissão de dados de forma segura e sem fio a pequenas distâncias,geralmente menores do que 10 centímetros. Um dispositivo, conhecido como iniciador, utiliza induçãomagné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 tecnologia são: o modode leitura e escrita que permite a dispositivos lerem e escreverem em outros dispositivos passivos comouma etiqueta NFC e o modo P2P que permite a dispositivos NFC trocar dados uns com os outros, umexemplo de aplicação que realiza sua comunicação dessa maneira é o Android Beam.

Essa tecnologia possui uma velocidade máxima de transmissão de dados de 0.424 Mbps, bastantebaixa se comparado a outros protocolos sem fio como o Wi-Fi ou o Bluetooth Clássico. Entretanto, seuconsumo energético de 15 mA é menor, além de oferecer uma maior segurança na transmissão de dados,muito devido à baixa área de atuação, e de não precisar de um pareamento prévio como existe em outrosprotocolos. O NFC se destaca principalmente para os tipos de comunicação que exijam apenas doisatores ao mesmo tempo, como, por exemplo, uma transação monetária. Um chip NFC pode facilmenteser configurado para agir como um cartão de crédito ou débito, o que nos dias de hoje já é uma realidadeem larga escala em países como Estados Unidos e Japão, onde é possível comprar passagens de transportepúblico, ingressos de cinema, tickets de estacionamento, entre outros [53].

Para se obter um melhor funcionamento do framework desenvolvido nesse trabalho é necessária umainteração entre dispositivos a distâncias extremamente grandes se comparadas aos poucos centímetrosnas quais é possível utilizar o NFC, portanto, devido a esse motivo foi tomada a decisão de descartar autilização dessa tecnologia.

A.3 QR CODE

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

Um QR Code possui uma capacidade máxima de armazenamento de informação de 4296 caracteresalfanuméricos, entretanto toda sua superfície não é utilizada apenas como área de dados, ela é subdividaem espaços menores voltados para facilitar a leitura, proporcionar outras funcionalidades e melhoraro seu desempenho, são os finder patterns, alignment patterns, timing patterns e a quiet zone. Esses

63

espaços permitem também que o mesmo seja lido em qualquer direção, deformado, danificado, com ascores invertidas ou espelhado [57].

Figura A.1: Estrutura de um QR Code [57]

Os finder patterns consistem em três estruturas idênticas localizadas em três das quatro extremidadesde acordo com a Figura A.1, esses padrões permitem ao software reconhecer o QR Code e determinar aorientação de maneira correta. Já os alignment patterns são responsáveis por auxiliar o software que irádecodificar a imagem a compensar eventuais distorções que possam existir. Os timing patterns são linhasque marcam as direções horizontal e vertical do código bidimensional, também é utilizado na correção dedeformaçõ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 muito grande, como,por exemplo, telões ou outdoors. Devido a esse fato, na maior parte das aplicações, seu uso é restritoa distâncias reduzidas, além disso, essa tecnologia possui a desvantagem de ser necessário direcionar acâmera do aparelho decodificador para o código, visto que ela funcionará como um leitor. Dessa formaessas duas características restringem bastante suas aplicações e foram os principais motivos que fizeramcom que essa tecnologia fosse preterida em relação ao Bluetooth Low Energy.

B INSERÇÃO DE NOVOS ELEMENTOS: BILLBOARDS

Em complemento à utilização de uma camada de interação, como apresentado no capítulo 5, a técnicade billboards poderia ser utilizada para inserir novos elementos dentro da cena. Billboards são polígonosplanos que estão sempre voltados para a câmera, isto é, a direção normal à face do polígono coincidecom a direção de observação (eixo ótico da câmera virtual). Esta técnica é muito utilizada quando sequer representar, de forma simplificada, elementos tridimensionais distantes ou que apresentariam umalto custo computacional devido a um grande nível de detalhes. Sobre o polígono, mapeia-se uma texturaque represente o objeto desejado. Devido à disposição deste elemento na cena (apontando na direçãoda câmera), o observador tem a impressão de que ele é tridimensional. A Figura B.1 ilustra o uso debillboards para representar árvores.

64

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

Como em nossa arquitetura o observador mantém-se fixo no centro de projeção da panorama, o usode billboards pode gerar resultados de alta qualidade a baixo custo computacional.

65

FRAMEWORK PARA APLICAÇÕES EM …lvelho.impa.br/hp/files/Hallison-Monografia.pdfem dispositivos...

Documents

Transcript of FRAMEWORK PARA APLICAÇÕES EM …lvelho.impa.br/hp/files/Hallison-Monografia.pdfem dispositivos...