Visualização de dados em realidade aumentada

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciências

Departamento de Informática

VISUALIZAÇÃO DE DADOS EM REALIDADE

AUMENTADA

José Manuel da Graça Nunes Pedrosa

PROJETO

MESTRADO EM INFORMÁTICA

2013

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciências

Departamento de Informática

VISUALIZAÇÃO DE DADOS EM REALIDADE

AUMENTADA

José Manuel da Graça Nunes Pedrosa

PROJETO

Trabalho orientado pela Profª. Doutora Maria Beatriz Duarte Pereira do Carmo e coorientado pela Profª. Doutora Ana Paula Boler Cláudio

MESTRADO EM INFORMÁTICA

2013

Agradecimentos

Com a conclusão deste trabalho termina uma fase árdua da minha carreira académica. Nunca teria sido possível chegar onde cheguei sem o apoio incondicional da minha família, de toda a dedicação e sacrifício a que os meus pais se submeteram ao longo de mais de duas décadas para assegurar que a minha jornada educativa pudesse ser cumprida com o maior êxito possível.

Agradeço ainda a todos os meus amigos, aos mais próximos e mais afastados, que me proporcionaram momentos de grande alegria e empatia e me deram forças para que continuasse a seguir em frente mesmo mas fases mais difíceis da minha vida.

Obrigado a todos os meus colegas de trabalho, com quem me cruzei ao longo dos anos, e com quem partilhei experiências magníficas que nos fizeram crescer e definir enquanto pessoas, e nos ensinaram a encarar as adversidades com força e otimismo. Juntos, partilhámos sucessos e fracassos e quebrámos barreiras que individualmente não teríamos conseguido.

Obrigado também a todos os professores que me acompanharam e que me deram apoio e incentivo extra quando mais precisei, pois com eles aprendi as minhas verdadeiras forças e fraquezas, aprendi a nunca desistir e a conseguir sempre mais e melhor do que antes.

Quero igualmente agradecer à Faculdade de Ciências da Universidade de Lisboa, ao seu Departamento de Informática e ao LabMAg por terem proporcionado a oportunidade e os meios para que pudesse completar a minha formação académica, abrindo portas para uma futura carreira de sucesso, bem como à Fundação para a Ciência e Tecnologia pelo apoio financeiro prestado. Por fim, um grande obrigado a todos os que colaboraram na realização deste projeto, e a todos os envolvidos na realização de testes, pois sem a vossa contribuição o mesmo não teria sido possível.

i

Resumo

A Realidade Aumentada (RA) consiste na combinação, em tempo real, de gráficos gerados em computador com imagens do mundo real, sendo uma tecnologia que tem vindo a atingir grandes desenvolvimentos na última década, em grande parte graças à expansão da indústria de aparelhos móveis, tais como telemóveis, smartphones, mini-PCs e mais recentemente tablets. Estes revelam grande potencial e utilidade para o desenvolvimento de aplicações de RA devido ao bom compromisso que apresentam entre a portabilidade e o bom desempenho e riqueza de recursos. Em particular, componentes como a câmara de alta resolução, sensores como acelerómetros, bússola e giroscópios, sistema de geolocalização e conectividade em rede, contribuem para proporcionar aos programadores uma plataforma de hardware ideal ao desenvolvimento de aplicações RA. É apresentado neste documento um projeto de expansão de uma biblioteca para o sistema operativo Android, designado RUBI Glare, que permite visualizar dados científicos em RA, e com base na qual foi desenvolvida uma aplicação para tablets que apresenta níveis de radiação solar sobre os edifícios que compõem a FCUL. Os dados são projetados em tempo real com diferentes modos de visualização, como superfícies ou glifos, e com a possibilidade de serem exibidas até duas variáveis em simultâneo, bem como transições animadas que facilitam comparações entre dados relacionados. São expostos com detalhe os desafios e opções tomadas no desenvolvimento do projeto e as funcionalidades implementadas, bem como os algoritmos de geração de gráficos desenvolvidos. São ainda apresentados os resultados dos testes realizados com utilizadores para avaliação da usabilidade da aplicação e utilidade da biblioteca, e para recolha de sugestões de melhoramento.

Palavras-chave: realidade aumentada, visualização, dados científicos, computação

iii

Abstract

Augmented Reality (AR) refers to the real-time combination of computer-generated graphics and real world images, and is a technology which has reached a high level of development within the last decade, mostly thanks to the expanding industry of mobile devices, such as cell phones, smart phones, mini-PCs and, more recently, tablets. The latter reveal a great potential for the development of augmented reality applications due to their good compromise between portability and good performance and resource plentifulness. Particularly, components such as a high resolution camera, sensors such as accelerometer, compass and gyroscope, geo-location systems and network connectivity, all together contribute to deliver programmers an ideal hardware platform for the development of AR applications.

This document describes a project that comprised the extension of an Android library, called RUBI Glare, which allows visualization of scientific data in AR and served as the basis for the development of a tablet application that presents solar radiation levels over the buildings encompassing FCUL. This data is projected in real time with different visualization modes, such as surfaces or glyphs, and with the possibility of displaying up to two variables simultaneously. It also includes animated transitions that facilitate the comparison of related datasets. The document exposes in detail the challenges faced, decisions made in the project’s development and functionalities implemented, as well as the algorithms for generating of graphics. The results from user testing for measuring usability, evaluating the library’s usefulness and gathering improvement suggestions are also shown.

v

Conteúdo

Lista de Figuras vii Lista de Tabelas xi

Lista de Acrónimos e Siglas ... xiii

Capítulo 1 Introdução ... 1

1.1 Objetivos ... 2

1.2 Planeamento e Contribuições ... 3

1.3 Estrutura do Documento ... 5

Capítulo 2 Trabalho Relacionado ... 7

2.1 Projetos de RA Relevantes ... 7

2.1.1 Soluções de Alinhamento ... 7

2.1.2 Visualização em Espaços Urbanos ... 8

2.1.3 Carregamento e Processamento dos Dados ... 10

2.1.4 Realidade Aumentada em Android... 11

2.2 A Biblioteca RUBI ... 12

Capítulo 3 A Biblioteca RUBI Glare ... 15

3.1 Análise e Desenho ... 15 3.2 Material Utilizado ... 18 3.3 Implementação... 20 3.3.1 Motor de Gráficos ... 20 3.3.2 Escalas de Cor ... 28 3.3.3 Carregamento de Dados... 29 3.3.4 Georreferenciação e Orientação ... 30

Capítulo 4 Aplicação de Visualização de Radiação Solar ... 31

4.1 Modos de Visualização ... 32

4.2 Opções Adicionais ... 34

4.3 Interface com o Utilizador ... 36

vi

4.5 Desempenho e Fiabilidade... 39

Capítulo 5 Testes com Utilizadores ... 41

5.1 Metodologia ... 41

5.2 Perfil dos Utilizadores ... 43

5.3 Análise dos Resultados ... 44

5.3.1 Carregamento e alinhamento dos gráficos... 44

5.3.2 Visualização de uma variável ... 45

5.3.3 Visualização de duas variáveis ... 48

5.3.4 Utilização de transições animadas ... 49

5.3.5 Questões adicionais ... 50

Capítulo 6 Conclusões e Trabalho Futuro ... 53

Bibliografia 55 Anexo A: Diagramas UML ... 59

Anexo B: Mapa dos Pontos de Observação ... 61

Anexo C: Guião de Testes com Utilizadores ... 63

Anexo D: Capturas de Ecrã ... 75

vii

Lista de Figuras

Figura 2.1 Demonstração do posicionamento de objetos KML, e imagem do dispositivo mini-PC utilizado [Honkamaa07] ... 8

Figura 2.2 Exemplo da interface do SiteLens, suportando diferentes formatos de glifos 3D, incluindo “nuvens” (c) de diferente densidade [White09]. ... 9

Figura 2.3 Captura de ecrã da visualização em RA de correntes de ar em torno do(s) edifício(s) [Heuveline11]. ... 10

Figura 2.4 Imagens das aplicações de RA para Android: Mixare (à esquerda) e AndAR (à direita). ... 12

Figura 2.5 Esquema da arquitetura da biblioteca RUBI [SilvaP11b]. ... 13 Figura 2.6 Captura de ecrã do RUBI versão 1.0. ... 13 Figura 3.1 Arquitetura modular da biblioteca RUBI Glare (vista de alto nível). ... 17 Figura 3.2 Demonstração de Gráficos OpenGL translúcidos sobre a imagem da câmara. ... 20

Figura 3.3 Sistema de coordenadas utilizado pelo OpenGL no seu espaço de desenho 3D [Chua]. ... 21

Figura 3.4 Representação da comunicação cliente-servidor estabelecida entre o processador principal e o processador gráfico, realizada a cada chamada ao OpenGL, incluindo na função de draw() [GLProg]. ... 22

Figura 3.5 Esquema da lógica de desenho de uma superfície quadrangular... 22 Figura 3.6 Exemplos de grelhas estruturadas geradas pelo algoritmo da classe GLPlane, estas podem ser de geometria irregular (esquerda) ou regular (direita). ... 24

Figura 3.7 Demonstração da geração de superfícies coloridas e deformadas com diferentes níveis de densidade. ... 25

Figura 3.8 Cálculo do vetor normal unitário a um plano. ... 26 Figura 3.9 Especificação do espaço de desenho dos gráficos através da função gluPerspective(). ... 27

Figura 3.10 Exemplo da descrição em código de uma escala de cores de arco-íris. ... 28 Figura 4.1 Exemplo dos quatro modos de visualização, aplicados sobre a mesma superfície do conjunto de dados. ... 32

viii

Figura 4.2 Comparação da visualização de glifos em diferentes dimensões. ... 33 Figura 4.3 Escalas de cor utilizadas na aplicação. De cima para baixo: rainbow, blue-white-red e temperature... 34 Figura 4.4 Dados sobrepostos à imagem da câmara, com transparência a 50% e oclusão ativada. ... 34

Figura 4.5 Interface com o utilizador, com a vista de RA em execução. ... 36 Figura 4.6 Imagem do navegador de ficheiros integrado (acima), e do menu de definições (abaixo). ... 37

Figura 4.7 Menu de controlo de animação. ... 38 Figura 5.1 Exemplo dos diferentes tipos de perguntas realizadas nos testes com utilizadores. ... 42

Figura 5.2 Secção do edifício C6 utilizada nos testes com utilizadores. ... 42 Figura 5.3 Gráficos da distribuição dos utilizadores de teste por sexo, profissão e níveis de experiência em visualização de dados, software de vis. de dados e utilização de tablets, numa escala de 1 (pouca) a 5 (muita). ... 43

Figura 5.4 Distribuição das respostas relativamente à facilidade do alinhamento manual, e à existência ou não de imperfeições na sobreposição dos gráficos sobre a imagem de fundo. ... 44

Figura 5.5 Distribuição das respostas quanto à clareza e compreensibilidade das opções do menu relativas ao alinhamento. ... 45

Figura 5.6 Distribuição das respostas quanto à clareza das opções do menu relativas a glyphs, e quanto à facilidade em ajustar essas mesmas opções. ... 46

Figura 5.7 Distribuição das respostas quanto à satisfação com o seletor de escalas de cor, e quanto à escala de cores preferida segundo a profissão. ... 46

Figura 5.8 Distribuição das respostas relativamente à facilidade em alternar entre modos de visualização e em ajustar as opções de oclusão e opacidade. ... 47

Figura 5.9 Escolha dos utilizadores quanto ao modo de visualização preferido, e separação das respostas obtidas segundo a idade e o sexo dos utilizadores. ... 48

Figura 5.10 Classificação atribuída pelos utilizadores à facilidade de utilização do modo de Glyphs + Surfaces e à clareza das opções de configuração desse modo. ... 48

Figura 5.11 Classificação atribuída pelos utilizadores à clareza das opções de configuração do modo de superfícies deformadas, e quanto à utilidade de um modo destes na visualização dos dados. ... 49

ix

Figura 5.12 Classificação atribuída pelos utilizadores à facilidade de utilização da animação, e à facilidade de ajuste das opções de animação. ... 50

Figura 5.13 Classificação atribuída pelos utilizadores à visibilidade quer dos gráficos de RA quer da interface de utilizador, e classificação global da aplicação. ... 51

xi

Lista de Tabelas

Tabela 3.1: Características de hardware do dispositivo móvel utilizado. ... 19 Tabela 4.1 Intervalos de tempo aproximados para carregamento dos dados e geração e modificação dos elementos gráficos no ecrã, para cada modo de visualização. ... 39

Tabela 4.2 Taxa de refrescamento da imagem para cada um dos modos de visualização. ... 39

xiii

Lista de Acrónimos e Siglas

API Application Programming Interface CPU Central Processing Unit

CSV Comma-Separated Values DDR3 Double Data Rate Type 3 GPS Global Positioning System GPU Graphics Processing Unit GUI Graphical User Interface

IDE Integrated Development Environment POI Point Of Interest

RA Realidade Aumentada

SDRAM Synchronous Dynamic Random Access Memory SoC System on a Chip

SSD Solid-State Drive

1

Capítulo 1

Introdução

Realidade Aumentada é uma tecnologia que consiste na sobreposição de gráficos, vídeo ou som gerados por computador à captação de imagens do mundo real, recorrendo a técnicas de registo que permitem integrar ambos de uma forma fluida e natural [Kim12]. A origem do termo “realidade aumentada” remonta a 1990, mas desde meados dos anos 60 do século XX que têm vindo a ser desenhadas aplicações que recorrem a algumas das suas características. No entanto, a quantidade de aplicações com utilidade prática foi durante muito tempo de número reduzido, em parte devido às anteriores limitações tecnológicas e por outro lado devido aos elevados requisitos de software e hardware que estas requerem [Luo11]. Os dispositivos móveis em particular possuíam características que condicionavam fortemente o desenvolvimento de aplicações de realidade aumentada para os mesmos. Nomeadamente, a limitada capacidade das suas baterias, a tipicamente fraca conectividade e rapidez das ligações de rede, e principalmente o fraco poder de processamento que resulta da utilização de chips que são desenhados de modo a serem pequenos e de baixo consumo energético.

Mais recentemente, com o aparecimento de smartphones e, mais tarde, de tablets, abriram-se novas possibilidades ao desenvolvimento de aplicações de realidade aumentada. Estes aparelhos móveis possuem um ecrã de dimensões mais generosas, que permitem uma melhor experiência de visualização sem penalizar muito a portabilidade. Adicionalmente, possuem todo o tipo de sensores que os outros dispositivos móveis já possuíam, como acelerómetros, giroscópios, bússola, localização por GPS e conectividade 3G, Wi-Fi ou Bluetooth e uma câmara fotográfica (ou mais) de alta resolução. O poder destes dispositivos tem vindo a aumentar muito rapidamente, sendo já algo comum encontrar chipsets com dois ou quatro núcleos e altas frequências de processamento, que apesar de tudo são otimizados por forma a reduzir o consumo de energia. Assim, o potencial para aplicações de RA em dispositivos móveis é cada vez maior, existindo atualmente muitas plataformas para o seu desenvolvimento e constatando-se o aumento progressivo de diversas aplicações de grande utilidade nas áreas da ciência, saúde, engenharia ou entretenimento.

2

Assim, é do interesse da comunidade científica desenvolver novas plataformas capazes de proporcionar experiências de RA com recurso a estes dispositivos que tornem possível a visualização de dados, permitindo que a análise de informação passe a poder ser realizada diretamente no local a que dizem respeito. O trabalho apresentado nesta tese parte deste interesse em convergir a visualização de dados científicos com os presentes avanços da RA em dispositivos móveis, procurando desenvolver uma plataforma de desenvolvimento de aplicações que concilie todas estas vertentes. Este trabalho foi realizado no âmbito da disciplina de Projeto de Engenharia Informática do Mestrado em Informática do Departamento de Informática da Faculdade de Ciências da Universidade de Lisboa (FCUL). O trabalho foi desenvolvido no âmbito de um projeto de investigação do LabMAg (Laboratório Modelação de Agentes), uma unidade de investigação associada ao Departamento de Informática da FCUL, e em colaboração com o Departamento de Engenharia Geográfica, Geofísica e Energia (DEGGE).

1.1 Objetivos

O objetivo deste trabalho foi o desenvolvimento de um sistema de visualização de RA para dispositivos móveis que permita a visualização de dados científicos. No contexto do presente trabalho, estes foram definidos como valores numéricos com uma referência espacial ou temporal e sem geometria pré-definida para a sua representação, podendo ter sido obtidos por simulação ou medição. Para a implementação desse sistema foi preciso construir a biblioteca necessária à visualização de dados e, posteriormente, desenvolver uma aplicação exemplificativa das capacidades dessa mesma biblioteca. Por fim, através de uma implementação cuidada, procurou-se que a aplicação executasse sem grandes falhas de desempenho e sem consumo excessivo de recursos da máquina (nomeadamente a bateria).

Os dados para a aplicação foram fornecidos pelo DEGGE e consistem em informação sobre os níveis anuais de radiação solar sobre o edifício C6 da FCUL. A aplicação desenhada utiliza informação geográfica e imagens captadas pela câmara para visualizar esses mesmos dados sobre as imagens do edifício.

3

1.2 Planeamento e Contribuições

No decorrer do projeto foi elaborada uma nova biblioteca de visualização de dados científicos em RA, designada RUBI Glare. Em particular, foi desenvolvido um motor gráfico capaz de gerar diferentes modos de visualização, representando uma ou duas variáveis escalares em simultâneo, e com execução em tempo real. A biblioteca foi construída de forma modular podendo ser estendida com novas funcionalidades. A capacidade de realizar transições animadas sobre os dados está também implementada, podendo a interface de animação ser estendida no futuro por forma a suportar a análise da evolução temporal desses dados. Como caso de estudo, foi desenvolvida uma aplicação para visualização de dados sobre a radiação solar relativa ao edifício C6 da FCUL, que permitiu também realizar uma validação experimental da biblioteca desenvolvida.

Existem algumas limitações como a falta de precisão dos mecanismos de geolocalização e orientação para conseguir o alinhamento rigoroso dos gráficos com a imagem real de fundo, o que levou à necessidade de implementar opções de ajuste manual. Foram ainda realizados testes com utilizadores no sentido de recolher feedback sobre a usabilidade da aplicação e a utilidade da biblioteca, do qual resultaram algumas melhorias e aperfeiçoamentos ao atual sistema, bem como propostas de trabalho futuro.

Funcionalidades adicionais implementadas:

 Carregamento de dados da memória do tablet.  Localização baseada em GPS.

 Possibilidade de alinhar a visualização manualmente (para além do alinhamento automático).

 Possibilidade de configurar e gerar transições de dados animadas.

 Possibilidade de “trancar” a captura de imagem, para visualizar os dados sem ter de apontar constantemente para o edifício.

Relativo ao presente trabalho, foi ainda elaborado o artigo Realidade Aumentada com Dados Científicos em Dispositivos Móveis, da autoria de José Nunes Pedrosa, Maria Beatriz Carmo, Ana Paula Cláudio, Ana Paula Afonso, António Ferreira, Paula Redweik e Cristina Catita. Este artigo foi aceite para publicação na conferência Interação 2013, a decorrer de 7 a 8 de Novembro de 2013 na Universidade de Trás-os-Montes e Alto Douro (UTAD), em Vila Real.

4

De seguida apresenta-se o plano de trabalhos estipulado no início do projeto, contrastando as dadas inicialmente previstas com as datas efetivas da realização de cada tarefa.

Data prevista: 15 de Setembro - 15 de Novembro Data efetiva: 17 de Setembro – 30 de Novembro

1. Análise do problema e levantamento de requisitos.

2. Familiarização com a plataforma de realidade aumentada já desenvolvida. 3. Pesquisa de trabalhos realizados quer no domínio da Visualização, quer no domínio da Realidade Aumentada.

4. Pesquisa de software de domínio público para visualização de dados e testes de integração ou de exportação de resultados em formatos compatíveis com software de Realidade Aumentada.

5. Escrita do relatório preliminar.

Data prevista: 15 de Novembro - 15 de Abril Data efetiva: 1 de Dezembro – 30 de Julho

6. Concretização de uma componente destinada à visualização de dados, na plataforma de Realidade Aumentada RUBI Glare, que estende a biblioteca RUBI, contemplando:

- A representação de uma ou mais variáveis em simultâneo. - A evolução temporal do valor de uma ou mais variáveis.

- Uma interface adequada para a seleção de parâmetros de visualização. Para este efeito é necessário ter em conta:

a) Implementação do renderer 3D.

b) Integração do renderer com o output dos sensores do RUBI. c) Criação de interface de seleção de dados.

d) Criação de interface para ajuste da visualização (seleção de variável, transições animadas, modos de visualização).

e) Implementação de alinhamento baseado em sensores.

5

Data prevista: 15 de Abril - 15 de Maio Data efetiva: 17 de Junho – 31 de Julho

7. Avaliação e refinamento da componente. a) Testes individuais.

b) Testes com utilizadores.

c) Análise de resultados e feedback.

Data prevista: 15 de Maio - 15 de Junho Data efetiva: 1 de Agosto – 27 de Setembro

8. Escrita do relatório final.

A principal discrepância em relação ao planeamento inicial encontra-se na duração da fase de implementação da biblioteca RUBI Glare, que se revelou muito mais complexa do que inicialmente previsto devido à necessidade de se realizar uma implementação na sua maioria de raiz, e na fase de avaliação e refinamento da componente, em que surgiram problemas pessoais e familiares que atrasaram a procura de utilizadores e a realização de testes com os mesmos. Por fim, foi necessário proceder-se à escrita e submissão de um artigo científico referente ao projeto para a conferência Interação 2013, e posteriormente à submissão de uma versão revista, tarefas que não estava previstas no planeamento inicial. Por todos estes fatores a escrita do relatório final necessitou de mais tempo e foi deslocada para o mês de Setembro.

1.3 Estrutura do Documento

Este documento está organizado da seguinte forma:

 Capítulo 2 – Trabalho Relacionado

Neste capítulo são exploradas as principais abordagens relacionadas com a aplicação de RA. São também apresentados diversos trabalhos de investigação relacionados com a integração de RA em dispositivos móveis, bem como sobre a visualização de

6

dados científicos nesse contexto, que inspiraram o desenvolvimento do presente trabalho. São também listadas diversas plataformas de RA para Android, resumindo as funcionalidades de cada uma. No final é feita uma breve introdução à biblioteca RUBI, que serviu de base ao desenvolvimento deste trabalho.

 Capítulo 3 – Biblioteca RUBI Glare

Neste capítulo é apresentada a biblioteca RUBI Glare. É abordada a sua conceção, os requisitos considerados no desenho da mesma e dificuldades encontradas, o software e hardware utilizados para o seu desenvolvimento e toda a implementação realizada, listando módulos construídos, as relações entre estes e detalhando a lógica de funcionamento.

 Capítulo 4 – Aplicação de Visualização de Radiação Solar

Neste capítulo é apresentada uma aplicação Android que recorre à biblioteca desenvolvida para gerar a visualização em RA dos níveis de radiação solar sobre o edifício C6 da FCUL. Descreve-se a interface com o utilizador, as funcionalidades que a aplicação disponibiliza, as opções de configuração à disposição do utilizador e faz-se uma análise ao desempenho da aplicação, com destaque para a rapidez de execução e precisão das técnicas de alinhamento.

 Capítulo 5 – Testes com Utilizadores

Neste capítulo são apresentados os testes realizados com utilizadores no sentido de recolher feedback sobre a usabilidade da aplicação e capacidades da biblioteca desenvolvidas. É explicada a metodologia aplicada, o perfil dos utilizadores e a análise dos resultados obtidos

 Capítulo 6 – Conclusões e Trabalho Futuro

Neste capítulo são apresentadas as conclusões finais relativas ao trabalho desenvolvido sendo também discutidas algumas possibilidades de trabalho futuro.

7

Capítulo 2

Trabalho Relacionado

Existem diversas questões a considerar quando se procura aplicar RA num dispositivo móvel, as quais têm vindo a ser abordadas por diversos autores. Apresenta-se neste capítulo um conjunto de trabalhos de investigação na área da RA que se focam na correta aplicação desta tecnologia tendo em conta a integração com espaços urbanos, a utilização de dispositivos móveis e as soluções para o carregamento, armazenamento, processamento e visualização de dados. Posteriormente, são apresentadas diversas plataformas de RA desenhadas para dispositivos móveis e compatíveis com o sistema operativo Android [Android], explicando resumidamente as capacidades de cada uma. Finalmente é feita uma breve introdução da biblioteca de RA designada RUBI, que serviu de base ao presente trabalho.

2.1 Projetos de RA Relevantes

2.1.1

Soluções de Alinhamento

Um dos principais problemas da RA é como alinhar as representações virtuais com a imagem real sem recorrer a marcas fiduciais e independentemente do objeto de estudo. Em [Honkamaa07] procurou-se implementar um sistema capaz de ser executado em tempo real em dispositivos móveis de tipo mini-PC. Recorrendo à leitura de valores do acelerómetro, consegue-se gerar uma estimativa do movimento da câmara do utilizador à medida que este se desloca em torno da cena.

Para o posicionamento e alinhamento do objeto tridimensional com a cena, foram consideradas duas abordagens: a semiautomática e a automática. A abordagem semiautomática estabelece que é o utilizador a indicar manualmente a posição do objeto (em particular a distância do observador e a orientação), o que pode ser realizado, por exemplo, através de interação táctil. Posteriormente a aplicação mantém a visualização alinhada através de estimativas de deslocação da câmara. Na abordagem automática, utiliza-se o GPS do aparelho móvel em conjunção com a informação geográfica recolhida do Google Earth para realizar o cálculo da posição do objeto a visualizar. O carregamento do mesmo é feito diretamente a partir de um ficheiro KML, permitindo obter de uma só vez a informação geográfica e geométrica do modelo do edifício a apresentar (Figura 2.1).

8

Estas duas abordagens de alinhamento foram adotadas no nosso trabalho, sendo o alinhamento automático feito com recurso ao GPS e bússola, e o manual realizado através do arrasto dos gráficos com recurso ao ecrã tátil.

2.1.2 Visualização em Espaços Urbanos

São também de particular relevância estudos em espaços urbanos, uma vez que os dados do nosso trabalho são aplicados a edifícios. Em [Hakkarainen09], o trabalho acima referido é expandido no sentido de tornar a aplicação mais modular e reutilizável, abordando ainda a questão do carregamento e armazenamento de dados e da implementação de transições animadas. Neste, o objetivo foi desenvolver uma aplicação para auxiliar em trabalhos de construção civil e edificação no âmbito de um projeto designado Augmented Reality for Building and Construction (AR4BC).

Procurou-se uma implementação que permitisse a visualização do local de construção, bem como a sua evolução ao longo do tempo. Devido ao elevado nível de rigor exigido, recorreu-se a técnicas de localização mais precisas como bússola eletrónica e sensores de inércia. Foi desenhado um novo sistema de visualização, baseado numa arquitetura cliente-servidor, em que ambos os componentes podem ser executados na mesma máquina (se esta possuir capacidades de hardware para tal), ou separadamente em duas máquinas. Neste caso a informação de localização e orientação é enviada do cliente para o servidor, que por sua vez calcula a imagem resultante e a devolve ao cliente para ser apresentada.

Figura 2.1 Demonstração do posicionamento de objetos KML, e imagem do dispositivo mini-PC utilizado [Honkamaa07]

9

Os algoritmos usados para o alinhamento são importados de uma biblioteca de RA designada ALVAR (A Library for Virtual and Augmented Reality). Esta biblioteca foi estendida na tentativa de otimizar o seu funcionamento em dispositivos móveis e encontra-se documentada com maior detalhe em [Woodward11]. Um projeto semelhante é apresentado em [Gimeno10], que procura adicionar uma componente de RA aos tradicionais sistemas de CAD, sendo nesse caso utilizada uma câmara acoplada a uma grua durante a fase de construção.

Um outro projeto, o SiteLens [White09], centra-se no desenvolvimento de uma plataforma e conjunto de técnicas que permitem a chamada situated visualisation, isto é, a visualização de dados relevantes contextualizados num espaço físico. O objetivo é auxiliar nas tarefas de planeamento urbano, em que tipicamente são necessárias visitas ao local para averiguar os níveis de tráfego automóvel, vegetação, ou densidade populacional. O SiteLens dá ao utilizador a capacidade de analisar dados no local, tais como a saúde dos moradores ou as condições do ar. O mecanismo suporta visualização em dispositivos fixos, móveis ou mesmo head-mounted-displays. Recorre-se à conversão de dados no formato KML, permitindo a interoperabilidade com o Google Earth e o Google Maps. A informação que não tiver uma associação espacial é afixada a um canto do ecrã, enquanto a restante informação é sobreposta dinamicamente à vista principal, sendo o alinhamento baseado em marcas fiduciais. No SiteLens foram também desenvolvidas experiências com ícones naturais (exemplo: nuvens de fumo negras para representar a densidade de CO) (Figura 2.2). Existe ainda a opção de “congelar” (ou “trancar”) a imagem, interrompendo a visualização de tempo real para uma melhor consulta da informação, e fazer uma ampliação semântica sobre cada ponto de dados. Estas duas soluções revelaram-se bastante úteis e intuitivas em testes com utilizadores. A opção de “trancar” a imagem foi também adotada no presente trabalho.

Figura 2.2 Exemplo da interface do SiteLens, suportando diferentes formatos de glifos 3D, incluindo “nuvens” (c) de diferente densidade [White09].

10

2.1.3 Carregamento e Processamento dos Dados

Em [Heuveline11] é apresentado um projeto que procura resolver a questão de como selecionar os dados pretendidos de um grande volume de dados, bem como gerar uma visualização que realize uma filtragem inteligente da informação para a tornar mais compreensível para o utilizador. Neste caso, é utilizado um modelo virtual tridimensional de várias ruas e edifícios a analisar, cuja informação geométrica é tida em conta ao fazer a modelação dos dados (nesse caso, correntes de ar). O processamento dos dados e geração de imagens são realizados em servidores remotos de alto desempenho, recorrendo em parte à biblioteca VTK e ao software ParaView. As imagens resultantes são enviadas para o cliente, prontas a ver no local, incluindo já a oclusão causada pelos edifícios, como mostra a Figura 2.3.

Para minimizar os custos de processamento, bem como a latência e consumo da rede na transmissão de dados, a visualização no dispositivo móvel aplica uma técnica detalhada em [Helfrich-Schkarbanenko12], que recorre à criação de imagens com diferentes perspetivas baseadas na posição e orientação da câmara. Assim, para cada posição do utilizador, é recebido um pacote de imagens pré-calculadas que são apresentadas conforme o deslocamento da câmara e o ângulo de visão. Dados os objetivos específicos do presente trabalho, incluindo o facto de no estado atual de ser apenas considerada a visualização dos dados sobre um edifício, optou-se por uma abordagem mais simples, em que todo o processamento é feito no cliente.

Figura 2.3 Captura de ecrã da visualização em RA de correntes de ar em torno do(s) edifício(s) [Heuveline11].

11

2.1.4 Realidade Aumentada em Android

Foi realizada uma pesquisa de plataformas de RA para Android cujas funcionalidades fossem ao encontro das necessidades do presente trabalho, nomeadamente o alinhamento baseado em localização e orientação (sem marcas fiduciais) com suporte para gráficos tridimensionais e o fácil acesso e modificação do código-fonte.

Wikitude

O Wikitude [Wikitude] é uma das aplicações de RA mais conhecidas, disponível para diferentes sistemas operativos móveis, incluindo o Android. Disponibiliza adicionalmente uma API [WDK] que permite o desenvolvimento de aplicações de RA por parte de terceiros. As aplicações resultantes apresentam ao utilizador os pontos de interesse (POI) que estão identificados dentro de um determinado raio de alcance. A aplicação permite o acesso a vários serviços para determinar os seus POI, e a informação destes é transmitida por meio de ligação à Internet. É também possível adicionar POI facultados pelo utilizador, bem como associá-los a um endereço URL que é acedido no decorrer da aplicação.

Metaio

O Metaio [Metaio] é um conjunto de software, plataformas e serviços que permitem o desenvolvimento de aplicações ou sistemas de RA. Em particular, possui um kit de desenvolvimento designado Metaio Creator [MC], que permite a criação de aplicações de RA através de uma interface de utilizador drag-and-drop para a construção de cenários, a possibilidade de importar imagens ou modelos como conteúdo 3D para uma aplicação, o alojamento desta em servidores dedicados Metaio e a exportação para diversos sistemas operativos de desktop ou dispositivos móveis. No entanto, é necessário um registo no Website como programador e a licença de utilização gratuita é limitada com uma marca de água sobre a aplicação.

Layar

Outra aplicação bastante conhecida é o Layar [Layar], lançada em 2009 e também compatível com o sistema Android. À semelhança do Wikitude esta apresenta ao utilizador POI previamente georreferenciados sobre imagens captadas pelo dispositivo. A informação que permite a determinação dos POI é também facultada através de uma ligação à Internet com recurso às mais diversas fontes. A aplicação apresenta a possibilidade de os utilizadores visualizarem os POI através de uma vista de “olho de pássaro” e de um mapa 2D, facilitando desta forma o reconhecimento dos POI no espaço envolvente. O Layar também disponibiliza uma API [LDK] que permite integrar POI na aplicação, sendo que o conjunto de POI fornecido é intitulado de layer (camada). Esta é facilmente integrada na aplicação de modo a que outros utilizadores também possam usufruir dela. Esta possibilidade permite à aplicação apresentar uma quantidade elevada de POI facultados por terceiros.

12

As três plataformas acima expostas suportam georreferenciação e reconhecimento de imagem (ou marcas fiduciais), mas são de código fechado e focadas em pontos de

interesse, em que o suporte de gráficos 3D resume-se à importação de modelos estáticos a representar sobre esses pontos [WDK, MC, LDK]. Dados os objetivos do trabalho, o recurso a estas plataformas não foi considerada viável.

Outras alternativas de código aberto analisadas foram o Mixare, que se baseia exclusivamente na georreferenciação de pontos de interesse [Mixare], e o AndAR, que recorre ao OpenGL ES [OGLES] para carregamento de modelos 3D (Figura 2.4), mas que possui apenas alinhamento baseado em marcas fiduciais [AndAR]. Assim, optou-se por recorrer à biblioteca RUBI [[SilvaP11b], [Montez12]], que tem vindo a ser desenvolvida por anteriores alunos do Departamento de Informática da FCUL, realizando as extensões necessárias para a visualização de dados científicos cumprindo as funcionalidades acima referidas.

2.2 A Biblioteca RUBI

A RUBI é uma biblioteca de visualização de pontos de interesse em RA para o sistema operativo Android [SilvaP11a]. Esta permite a recolha e pré-visualização de imagens por meio da câmara de vídeo e suporta geolocalização, cálculo da orientação e inclinação para conseguir o alinhamento do conteúdo (Figura 2.5). Realiza também o carregamento de dados remotos em formato JSON.

13

O RUBI foi desenvolvido para o Android 2.2 Froyo. O seu objetivo é ser usado para o desenvolvimento de aplicações móveis de RA para visualização de pontos de interesse. A biblioteca segue o padrão modular de aplicações de realidade aumentada exposto em [Luo11] (Figura 2.6). Esta contém um módulo de recolha de dados que carrega a informação que se pretende apresentar ao utilizador. A informação pode ser local ao dispositivo ou ser carregada de um servidor remoto. Existe ainda um módulo de aquisição de contexto que determina o posicionamento geográfico através do sensor de GPS, a orientação através do sensor de bússola digital e inclinação por meio do acelerómetro. Por fim, inclui um componente de visualização que é responsável por gerar a representação dos POI e o seu alinhamento baseado na componente de aquisição de dados. Este incorpora ainda a interface gráfica apresentada ao utilizador.

Figura 2.6 Captura de ecrã do RUBI versão 1.0.

Figura 2.5 Esquema da arquitetura da biblioteca RUBI [SilvaP11b].

14

Esta biblioteca foi posteriormente estendida [Montez12], passando a permitir o ajuste da visibilidade de símbolos em função da imagem de fundo. Esta versão estendida da biblioteca RUBI serviu de base à biblioteca RUBI Glare (GL Augmented REality), que se apresenta no capítulo seguinte.

15

Capítulo 3

A Biblioteca RUBI Glare

Neste capítulo é apresentada a biblioteca RUBI Glare, resultante da extensão da biblioteca RUBI no sentido de suportar a visualização científica e a representação de gráficos tridimensionais. É abordada a sua conceção, os requisitos considerados no desenho da mesma e dificuldades encontradas, e o software e hardware utilizados para o seu desenvolvimento. É ainda feita a listagem dos módulos desenvolvidos, as relações entre estes e expostos os detalhes da sua implementação, bem como a lógica de funcionamento.

3.1 Análise e Desenho

A integração de capacidades de RA em dispositivos móveis costuma seguir determinados padrões [Luo11]. A informação obtida através dos sensores de orientação (bússola, acelerómetro, giroscópio) e de localização (GPS) do aparelho permite que à captação de imagem seja associada uma posição com 6 graus de liberdade (translação e rotação segundo um sistema de coordenadas em 3 eixos). Opcionalmente estes sensores podem servir de suporte para uma interação gestual com a aplicação. Existe também um módulo de input/output que lê dados da memória do aparelho ou de um servidor remoto e que os passa para um módulo de rendering, que os representará no ecrã. Os gráficos são assim combinados com o vídeo em tempo real.

Os requisitos essenciais que estes sistemas procuram atingir são interatividade, fidelidade, escalabilidade e robustez [Luo11]. A representação deve correr em tempo real, e idealmente sem grandes restrições quanto à quantidade e qualidade dos dados representados, bem como ter uma forte tolerância a distúrbios na leitura de dados que possam ser causados por ambientes externos. Também é necessário ter em conta, para aparelhos móveis, certas dificuldades como a diversidade de arquiteturas-alvo, capacidades do hardware limitadas em comparação com desktops e laptops, e requisitos de conservação de energia.

A biblioteca RUBI que serviu de base a este trabalho já possuía capacidades de combinação de imagens da câmara com símbolos virtuais, leitura de dados GPS e de acelerómetro [SilvaP11a, Montez12]. No entanto, ainda não possuía mecanismos para

16

desenhar gráficos 3D e os apresentar sobre a imagem, nem módulos para visualização de dados científicos. Um dos desafios deste trabalho consistiu em desenhar e concretizar esses módulos, tendo já em mente o desenvolvimento de uma aplicação para visualizar dados de radiação solar sobre edifícios. A primeira fase do projeto consistiu na identificação das funcionalidades e componentes necessários para a visualização de dados num formato tridimensional.

Para o desenvolvimento do motor de gráficos considerou-se inicialmente recorrer ao VTK (Visualization Toolkit), por este estar otimizado para a leitura e processamento de dados científicos e por já termos experiência anterior de utilização. O VTK é baseado em OpenGL e implementado na linguagem C++, mas não é compatível com o Android, pois este suporta apenas um subconjunto das funcionalidades correspondentes à especificação OpenGL ES.

Esta incompatibilidade do VTK, e de outras bibliotecas semelhantes do nosso conhecimento, com o Android levou à necessidade de desenvolvermos de raiz um módulo capaz de gerar visualizações tridimensionais de dados. O resultado deste trabalho foi uma extensão da biblioteca RUBI que recorre à implementação OpenGL ES existente no sistema Android, designada RUBI Glare (GL Augmented REality). A Figura 3.1 mostra uma representação de alto nível da estrutura de módulos da biblioteca, identificando os principais componentes e as relações entre estes. Diagramas de classes mais detalhados podem ser consultados no Anexo A.

17

Figura 3.1 Arquitetura modular da biblioteca RUBI Glare (vista de alto nível).

A biblioteca RUBI Glare é uma extensão da biblioteca original RUBI, que aproveita as funcionalidades de leitura de posição e orientação que esta já disponibilizava, bem com a captura de imagens da câmara do dispositivo. Foi implementado um novo conjunto de módulos responsáveis pela leitura, processamento e visualização de gráficos 3D que são acrescentados à vista de RA previamente desenvolvida. Os principais componentes do sistema são:

Gestor de Câmara – Responsável pela abertura e leitura do stream de dados da

câmara fotográfica do dispositivo, ativando e desativando o modo de pré-visualização da câmara que será utilizado como fundo da vista de RA, e ajustando a proporção da imagem de acordo com as dimensões e resolução do ecrã e os formatos de imagem suportados pelo hardware.

Gestor de Posição / Orientação – Responsável por calcular a posição do dispositivo

através de da informação obtida pelo sensor de GPS: latitude, longitude e altitude. Calcula também a orientação (horizontal) e a inclinação (vertical) deste através da leitura da bússola digital e do acelerómetro, respetivamente.

Agregador de Entradas – O módulo que combina o input das imagens da câmara

18

interface gráfica que consiste na preview da câmara combinada com widgets representativos da informação da bússola e do GPS.

Gestor de Dados – Módulo responsável pelo processamento dos dados a serem

visualizados. Encarrega-se de realizar a abertura do ficheiro de dados, a leitura dos mesmos e o seu carregamento e arrumação em memória, para que possam ser acedidos para filtragem e visualização pela restante biblioteca.

Motor de Gráficos 3D – Módulo que gere a criação de geometria tridimensional,

baseado em OpenGL ES. Responsável pela construção da geometria e coloração (com base nos dados processados pelo Gestor de dados), posicionamento e ajuste do viewport e perspetiva do ambiente virtual.

Módulo de Configuração – Módulo que gere todas as configurações e parâmetros

que possam ser ajustados pelo utilizador, tais como a informação a visualizar, o modo de visualização selecionado, etc. Na aplicação final está diretamente associado a uma GUI de seleção de parâmetros.

Vista de RA – O front end da aplicação, a interface de utilizador final que resulta da

combinação da GUI gerada pelo agregador de entradas da biblioteca RUBI com o output do motor de gráficos 3D do RUBI Glare.

Interface de configuração – A interface de utilizador na qual este pode aceder às

opções de configuração que pretender ajustar, sendo as alterações refletidas na vista de RA. Esta interface encontra-se associada a um módulo de configuração que armazena as preferências do utilizador, sendo estas lidas pelo motor de gráficos.

3.2 Material Utilizado

Atendendo ao tipo de aplicação a desenvolver, recorreu-se a um tablet, que possui um ecrã com maiores dimensões que um smartphone e permite uma melhor experiência de visualização, imagens maiores e mais detalhadas, e a capacidade de apresentar mais informação em simultâneo, tornando-se uma escolha lógica para a implementação do projeto. Foi realizada uma análise de vários modelos existentes no mercado e O tablet utilizado no decorrer deste projeto foi um Asus TF300T, sobre o qual a aplicação foi desenvolvida e testada. O código final foi elaborado de forma a suportar qualquer outro dispositivo com características semelhantes, mas o TF300T foi o único modelo no qual se testou a aplicação final. As características detalhadas do tablet são apresentadas na tabela 3.1:

19

Fabricante Asus

Modelo Transformer Pad TF300T

Chipset NVIDIA Tegra 3 (1.3 GHz quad-core, arquitetura ARM)

Memória 1 GB DDR3 SDRAM

Armazenamento interno

32 GB SSD

Sistema operativo Android 4.2.1 Jelly Bean

Ecrã LCD muti-toque, 10.1 polegadas, 1280*800 px de resolução, 16 milhões de cores.

Câmaras Posterior (8 MP) e frontal.

Sensores Acelerómetro, giroscópio, bússola digital, GPS.

Conectividade USB 2.0, Wi-Fi 802.11 b/g/n, Bluetooth

Tabela 3.1: Características de hardware do dispositivo móvel utilizado.

O chipset Tegra 3 permite que o tablet possua um elevado desempenho quer em processamento de gráficos 3D de alta qualidade, quer na paralelização das tarefas em execução [Tegra]. SoC (system on a chip) baseado na arquitetura ARM possui 4 núcleos Cortex A9 para tarefas de alto desempenho, e um 5º núcleo otimizado para poupança energética, que permite conservar energia e aumentar a autonomia do aparelho quando este não requer processamento intensivo. Algumas das vantagens desta arquitetura são o menor consumo de energia e maior desempenho por Watt, carregamento mais rápido de páginas Web, melhor execução de aplicações mais exigentes, maior desempenho no multitasking, e uma melhor experiência e qualidade em videojogos. Estes benefícios encontram-se mais detalhados em [Tegra].

O software utilizado foi o habitual para o desenvolvimento de aplicações para Android.:

 Android SDK.

 Eclipse IDE com o plugin Android Developer Tools (ADT).  Java Development Kit (JDK 7).

20

3.3 Implementação

Nesta secção detalha-se o trabalho desenvolvido na construção dos diferentes módulos da biblioteca RUBI Glare, é explicado o seu funcionamento interno e as funcionalidades que estes módulos proporcionam.

3.3.1 Motor de Gráficos

Após concluir que não era possível incorporar o VTK na aplicação, testou-se a implementação de uma demode OpenGL ES sem recorrer a essa plataforma. Foi possível executar a renderização de gráficos sobre a pré-visualização da câmara, mantendo a visibilidade das duas camadas (Figura 3.2). A simples aplicação de demonstração desenvolvida não só comprovou a capacidade de implementar realidade aumentada com o dispositivo, como mostra a capacidade de ajustar diversos níveis de transparência e de executar sem abrandamentos ou falhas.

Foi necessário desenvolver de raiz o código necessário para gerar gráficos característicos da visualização científica. A construção do motor de gráficos implicou assim a especificação das primitivas geométricas que serão utilizadas para a construção de visualizações mais complexas. Cada primitiva geométrica utilizada pela biblioteca está contida no seu ficheiro Java, o qual inclui toda a informação de que o OpenGL necessita para gerar o respetivo objeto tridimensional e o apresentar no ecrã do dispositivo.

De seguida são apresentadas as principais classes que constituem o do motor de gráficos desenvolvido, explicando a estrutura, propósito e os princípios de funcionamento de cada uma.

Figura 3.2 Demonstração de Gráficos OpenGL translúcidos sobre a imagem da câmara.

21

GLMesh

A classe GLMesh especifica os atributos que constituem uma figura geométrica. Estes incluem uma lista de vértices especificada por um FloatBuffer, uma lista de índices especificada por um ShortBuffer, e quantidade total de índices. O buffer de vértices é preenchido com as coordenadas X, Y e Z de cada vértice que constitui a forma geométrica. O buffer de índices serve para identificar, para cada posição especificada no buffer anterior, a ordem em que esta é desenhada. Existe ainda uma terceira lista que corresponde a cores no formato RGBA, também esta na forma de um FloatBuffer. Esta especifica, para cada vértice listado no buffer de vértices, qual a cor do objeto nesse vértice. Este buffer de cores só é utilizado quando o objeto que queremos mostrar no ecrã tem mais que uma cor, caso contrário é substituído por um único vetor de floats correspondente a uma única cor RGB. Finalmente, são especificadas variáveis que correspondem a valores de rotação e translação nos 3 eixos do espaço de desenho. Este é baseado num sistema de coordenadas cartesiano de “mão direita” (Figura 3.3), em que a rotação em torno dos eixos é medida no sentido direto (sentido contrário ao dos ponteiros do relógio).

A função mais importante da classe GLMesh é a função draw(). Nela está contido o código responsável por realizar as diferentes chamadas ao OpenGL para carregar a informação geométrica e de cor para a memória do GPU, para estre proceder à renderização (geração da imagem final) no ecrã do dispositivo. É estabelecida uma ligação entre o Cliente OpenGL ES presente na CPU e o servidor OpenGL ES presente no GPU (Figura 3.4). Estabelecida a conexão, são estabelecidos apontadores para a transmissão dos buffers do objeto a desenhar. Uma vez terminado o envio, a conexão entre cliente e servidor é terminada.

Figura 3.3 Sistema de coordenadas utilizado pelo OpenGL no seu espaço

22

GLCube

A classe GLCube estende a GLMesh, especificando o vetor de vértices e de índices para gerar um objeto tridimensional em forma de cubo. Ao criar um objeto GLCube o programador tem apenas que especificar a largura da aresta segundo o eixo do X (width), do Y (height) ou do Z (depth). Isto permite ao programador ajustar não só a dimensão como também a forma do objeto como bem entender, podendo gerar por exemplo efeitos de distorção. É possível também aplicar qualquer cor (ou transparência) que se deseje ao objeto, invocando os métodos setColor() ou setColors() herdados da classe GLMesh.

Uma vez que o OpenGL ES, por predefinição, apenas conhece triângulos como primitiva geométrica (uma das grandes limitações face ao OpenGL tradicional), a especificação de um cubo implica a especificação de 6 quadrados, e cada uma desses

Figura 3.4 Representação da comunicação cliente-servidor estabelecida entre o processador principal e o processador gráfico, realizada a cada chamada ao OpenGL,

incluindo na função de draw() [GLProg].

Figura 3.5 Esquema da lógica de desenho de uma superfície quadrangular

23

quadrados resulta de agrupar 2 triângulos. Logo, o motor gráfico interpreta o cubo como uma sequência de triângulos a ser desenhada a partir de uma lista de vértices numa determinada ordem, como mostra a Figura 3.5. Note-se que, uma vez que apenas uma das faces de cada triângulo é visível, e a outra fica virada para o interior do cubo, é realizado o chamado culling de faces, em que se especifica que as faces viradas para dento, por não serem visíveis, não devem ser desenhadas. Caso contrário, estaríamos simplesmente a desperdiçar recursos gráficos.

GLCubeGlyphMap

A classe GLCubeGlyphMap serve para gerar a representação de um conjunto de objetos GLCube dispostos ao longo do espaço de desenho, conforme um conjunto de dados especificado pela classe RubiDataset (ver secção 3.3.3). Para gerar um GLCubeGlyphMap o programador deve passar como argumento um objeto RubiDataset (correspondente aos dados carregados para visualização), o índice correspondente ao subgrupo de pontos que serão representados, o índice correspondente à variável a associar aos cubos, o índice correspondente à escala de cores a utilizar (ver secção 3.3.2) e o nível de opacidade e a dimensão pretendida para o conjunto de Cubos.

Para a construção de uma GLCubeGlyphMap, a biblioteca começa por extrair a lista de pontos pretendida do volume de dados contido no objeto RubiDataset, filtrados de acordo com os parâmetros acima explicados. Para cada ponto desta lista, é extraído o valor da variável e as coordenadas do ponto. Com esta informação é então construído um objeto GLCube em que a posição corresponde às coordenadas, a dimensão corresponde à que é passada como argumento, e a cor é calculada com base no valor da variável e na escala de cores especificada, conforme explicado na secção 3.3.2. Por fim, o GLCube resultante é armazenado numa lista de cubos para posteriormente ser desenhado. Note-se que este processo de geração da lista de cubos a desenhar só é realizado uma vez, correspondente à fase inicial de carregamento dos gráficos.

Quando o programador realiza uma chamada ao método draw(), é estabelecida a conexão entre CPU e GPU previamente explicada, sendo que neste caso os objetos GLCube que constituem o conjunto de cubos são carregados para a memória gráfica e desenhados um a um. Para cada cubo são realizadas 3 chamadas ao GPU: A primeira estabelece a cor, a segunda a posição cartesiana e a terceira a geometria do cubo. Uma vez enviada a totalidade dos cubos, a ligação é terminada.

24

GLPlane

A classe GLPlane estende a GLMesh e especifica a criação de uma malha poligonal. Os parâmetros base para construir um objeto GLPlane são a largura e altura (em unidades OpenGL), bem como o número de segmentos em cada eixo. Assim, quer a dimensão quer o nível de subdivisões poligonais podem ser ajustados individualmente. Estas malhas poligonais devem ser de topologia regular, ou seja, devem ser grelhas estruturadas (o número de pontos na horizontal e na vertical não varia ao longo da grelha). A forma mais rápida de verificar esta regularidade é comparando a quantidade de pontos na primeira linha e primeira coluna com o total da grelha. A topologia é regular se a seguinte regra for verdadeira:

TPontos = NPontosX x NPontosY

Em que TPontos é a quantidade total de pontos na grelha, NPontosX é a quantidade de pontos na primeira coluna e NPontosY é a quantidade de pontos na primeira linha. Esta verificação é bastante rápida computacionalmente e é realizada antes de ser executado o algoritmo de construção da geometria. Apesar disso, note-se que a geometria da grelha não precisa de ser também regular (Figura 3.6), o que permite desenhar superfícies com deformação.

Um exemplo do que é possível realizar com objetos GLPlane é apresentado na Figura 3.7. Aqui, foram gerados planos transparentes (opacidade a 50%), e com cores arbitrárias em cada vértice da grelha. A superfície (a) é plana e tem dimensão 10x10. A (b) é arbitrariamente irregular ao longo do eixo Z, e tem dimensão 10x10. As superfícies (c) e (d) possuem dimensão 100x100. É possível comprovar não só a possibilidade de gerar malhas com uma grande quantidade de vértices (e visualizar dados com elevada resolução) como se pode observar a interpolação de cores que o OpenGL realiza entre cada vértice com base na técnica de shading de Gouraud, ou vertex shading.

Figura 3.6 Exemplos de grelhas estruturadas geradas pelo algoritmo da classe GLPlane, estas podem ser de geometria irregular (esquerda) ou regular (direita).

25

Se pretendermos construir uma superfície colorida (ou deformada) a partir de um conjunto de dados, necessitamos de passar como argumento um objeto RubiDataset, o índice da variável que queremos usar para a coloração e, facultativamente, o índice da variável que queremos utilizar para a deformação. Finalmente, devemos especificar a escala de cores a utilizar, o nível de deformação e o nível de opacidade da superfície.

O algoritmo filtra a partir do objeto RubiDataset os pontos a utilizar para gerar a superfície e verifica a quantidade de pontos e as coordenadas destes para determinar se a topologia resultante é regular. Caso contrário, a geração da superfície é cancelada. Se a topologia for regular, são então gerados o buffer de vértices (a partir das coordenadas dos pontos, o buffer de índices (a partir da informação da topologia da grelha anteriormente calculada) e o buffer de cores (a partir do valor da variável em cada ponto).

Figura 3.7 Demonstração da geração de superfícies coloridas e deformadas com diferentes níveis de densidade.

(a) (b)

26

No caso das superfícies com deformação são necessários cálculos adicionais. É preciso saber, para cada plano, qual a orientação da sua reta normal, pois esta será a orientação da deformação. É também necessário saber a posição relativa ao observador, pois esta permite saber qual o sentido da deformação. A deformação deve ser direcionada, portanto, na perpendicular à orientação do plano, e para o lado que está voltado ao observador. Para determinar uma reta normal ao plano, será necessário determinar primeiro a posição deste. Isto é realizado selecionando 3 pontos aleatórios do plano que não sejam colineares. Desses 3 pontos não colineares ficam definidos 2 vetores que descrevem a posição e orientação do plano. Com estes 2 vetores AB e AC, é possível calcular um vetor normal AN através do seu produto vetorial AN = AB x AC (Figura 3.8). Do vetor normal AN obtém-se o vetor normal unitário ou normalizado (isto é, de norma 1).

Finalmente, para assegurar que a deformação é realizada no sentido do observador, é necessário saber a posição deste no espaço de coordenadas OpenGL. A sua posição é passada como argumento a cada ciclo de refrescamento da imagem, permitindo recorrer ao cálculo do produto interno entre o vetor normal ao plano AN calculado acima e o vetor AO, em que O é a posição do observador. Se o produto for negativo, a normal NA é multiplicada por -1 para que o seu sentido seja invertido, e o objeto GLPlane é redesenhado no sentido correto. O resultado é uma superfície com deformação no sentido do utilizador, que é automaticamente reorientada conforme este mude de posição.

Uma consequência de utilizar a normal ao plano como o sentido da deformação é que, se o plano não for perfeitamente perpendicular ao chão, a deformação também não será. Além disso, se uma parede for muito irregular, a normal obtida pode ter uma orientação estranha, dificultando a análise dos dados. Para evitar estes problemas, existe a opção de forçar as normais a serem paralelas ao chão, ou não. Se a opção for ativada, a normal utilizada manterá a orientação X e Z calculadas pelo algoritmo, mas fixará a orientação Y (eixo vertical) a zero.

Figura 3.8 Cálculo do vetor normal unitário a um plano.

27

RubiGLSurfaceView

Esta classe é efetivamente o coração do motor gráfico do RUBI Glare. Uma extensão da classe GLSurfaceView da API do Android, é responsável por criar e mandar desenhar todos os gráficos OpenGL através da sua subclasse RubiGLRenderer. É ainda responsável por definir o viewport e configurar todos os detalhes da visualização 3D com base nas preferências do utilizador. Por fim, é este módulo que faz o refrescamento da visualização gráfica de acordo com o input recebido dos sensores do dispositivo, atualizando a posição do observador, a orientação e inclinação em tempo real.

Para definir o viewport e o espaço de desenho dos gráficos, recorre-se à função utilitária gluPerspective() (Figura 3.9). Esta função define o ângulo de visão da “câmara” virtual. Este é o ângulo em graus entre dois planos: o plano que passa pela posição da câmara e o topo do ecrã, e o plano que passa pela posição da câmara e fundo do ecrã. É apenas passado como argumento o ângulo vertical da imagem, sendo que o ângulo horizontal é calculado internamente a partir do vertical e da razão de aspeto (aspect ratio). No caso particular das aplicações de RA, o principal objetivo ao chamar esta função é ajustar a largura e altura do viewport de OpenGL para coincidir com o aspect ratio nativo da câmara do dispositivo. Infelizmente, não foi possível descobrir um algoritmo que conseguisse realizar este ajuste automaticamente, pelo que foram experimentados à mão vários valores até conseguir a melhor aproximação possível.

Para ajustar a orientação e inclinação da câmara virtual, recorreu-se a um truque de programação no qual a câmara é fixa na posição (0,0,0) do espaço de visualização e o resto dos objetos sofrem uma rotação e translação inversas às que são recolhidas pela

Figura 3.9 Especificação do espaço de desenho dos gráficos através da função gluPerspective().

28

bússola e acelerómetro do dispositivo. Este truque permite orientar corretamente os gráficos sem a necessidade de calcular o eixo de projeção da câmara.

3.3.2 Escalas de Cor

A biblioteca RUBI Glare suporta a utilização de diferentes escalas de cor. Estas consistem num vetor de cores RGB cuja dimensão e conteúdo são definidas pelo programador. Deve-se apenas ter em atenção que, embora vetor mais extenso permita a criação de escalas de cor mais detalhadas (e com mais cores), pode levar a uma pequena quebra no desempenho pois torna a associação de uma cor a um valor de variável mais demorado. A classe ColorScales armazena toda a informação das escalas de cor, podendo ser alargada com mais conteúdo ao gosto do programador.

Cada escala de cor é identificada na biblioteca por um número inteiro. A escala propriamente dita consiste num vetor bidimensional, em que cada entrada corresponde a um vetor de 3 floats (Figura 3.10), correspondente aos níveis de RGB para cada cor da escala. Estes níveis de RGB podem variar entre 0.0f (preto) e 1.0f (branco), de acordo com os padrões da API do OpenGL.

O procedimento para aplicar uma escala de cor consiste na chamada da função estática RubiDataset.colorize() para cada ponto de dados que se pretende colorir. Esta recebe como argumento o identificador da variável, o valor da variável e o identificador

Figura 3.10 Exemplo da descrição em código de uma escala de cores de arco-íris.

29

da escala de cores desejada. Com essa informação, consulta quais os valores mínimo e máximo existentes para essa variável e dispõe a escala de cores entre os dois, calculando os intervalos de valores a corresponder para cada cor. Finalmente, é escolhida e aplicada a cor correspondente ao valor de variável recebido.

3.3.3 Carregamento de Dados

Os dados científicos a utilizar pela biblioteca são carregados de um ficheiro externo, armazenado em disco no próprio dispositivo. O ficheiro de dados segue o formato CSV, em que cada linha corresponde a um ponto de dados e a informação sobre esse ponto é separada por “;”. Para exemplificar, o ficheiro de dados utilizado para a aplicação de visualização de radiação solar (ver Capítulo 4) segue a seguinte estrutura:

Linha 1 (cabeçalho): "FID_";"ID";"X";"Y";"Zdem";"svf";"cota_ponto";"a_Rdir";"a_Rdif";"a_Rglobal";" a_nhsombra";"a_nhtotal";"Edifico";"cod_fach";"lat";"long_";"Altitude" Linha 2: ;178.000000;-89132.989000;-100755.304000;97.830000;0.306200;82.830000;1358.334800;185932.825000;187291.1 59800;4027.000000;4030.000000;"C6";155.000000;38.756198;-9.158519;136.229995 Linha 3: ;178.000000;-89132.989000;-100755.304000;97.830000;0.306200;83.830000;3958.407900;186193.789300;190152.1 97000;4022.000000;4030.000000;"C6";155.000000;38.756198;-9.158519;137.229995

A primeira linha do ficheiro de dados corresponde ao cabeçalho, e identifica os atributos listados nas seguintes linhas. Na estrutura acima, são definidos identificadores do edifício, da parede e do ponto; coordenadas do ponto (cartesianas e em graus), e os valores de diferentes variáveis nesse ponto.

A classe CSVDataLoader é responsável por abrir um ficheiro de dados e carregar o seu conteúdo para memória ao iniciar uma aplicação. É passado como argumento o path para o ficheiro de dados. Ao invocar a função getData() é aberto um input stream que lê o ficheiro linha a linha, separando cada valor e armazenando o conteúdo numa ArrayList de valores float (uma vez que é o formato numérico suportado pelo OpenGL). Por fim, os dados são armazenados numa classe RubiDataset, que inclui a informação das variáveis existentes e um HashMap que armazena a informação de todos os pontos de