Desarrollo de una aplicación de realidad aumentada para dispositivos móviles

Desarrollo de una aplicación de realidad aumentada para dispositivos móviles PROYECTO FINAL DE CARRERA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA UNIVERSIDAD POLITÉCNICA DE VALENCIA Autor: Miguel Medina Carda Director: Antonio Cano Gómez Titulación: Ingeniería Informática Fecha: Octubre de 2011 ÍNDICE DE CONTENIDOS 1.- RESUMEN..............................................................................................4 2.- INTRODUCCIÓN..................................................................................5 2.1.- OBJETIVOS Y MOTIVACIÓN.......................................................5 2.2.- REALIDAD AUMENTADA...........................................................5 2.2.1.- DESCRIPCIÓN.........................................................................6 2.2.2.- APLICACIONES.......................................................................8 3.- DISPOSITIVO NOKIA N900...............................................................11 3.1.- CARACTERÍSTICAS....................................................................11 3.2.- MODO PASTILLA ROJA..............................................................12 3.3.- ADMINISTRADOR DE APLICACIONES Y REPOSITORIOS..12 3.4.- CONEXIÓN Y TRANSFERENCIA DE ARCHIVOS...................15 4.- HERRAMIENTAS DE REALIDAD AUMENTADA..........................18 4.1.- ARTOOLKIT..................................................................................20 4.2.- ARTOOLKITPLUS........................................................................24 5.- APLICACIÓN ARAPP.........................................................................25 5.1.- DESCRIPCIÓN..............................................................................25 5.2.- INSTALACIÓN..............................................................................26 5.3.- USO Y FUNCIONAMIENTO.......................................................28 5.4.- FORMATO WAVEFRONT OBJ....................................................32 5.4.1.- HISTORIA...............................................................................32 5.4.2.- DESCRIPCIÓN.......................................................................33 5.4.3.- MODELADO DE UN DADO.................................................37 5.4.3.1.- FORMATO Y DESCRIPCIÓN.........................................38 5.4.3.2.- VÉRTICES........................................................................39 5.4.3.3.- NORMALES.....................................................................39 5.4.3.4.- TEXTURAS......................................................................39 5.4.3.5.- CARAS..............................................................................40 5.4.4 CREANDO UN OBJ CON BLENDER.....................................42 6.- CONCLUSIONES................................................................................49 7.- REFERENCIAS Y BIBLIOGRAFÍA...................................................50 8.- APÉNDICES.........................................................................................53 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 1.- RESUMEN El trabajo realizado en este proyecto se enmarca dentro del ámbito de los dispositivos móviles y de la realidad aumentada. La memoria de este proyecto final de carrera puede servir para hacerse una idea de cual es el estado actual del uso de esta tecnología, que se puede esperar de ella en un futuro y que herramientas están al alcance de los desarrolladores para poder usarla en sus aplicaciones. Sobre todo nos ha interesado como está influyendo en los dispositivos móviles y que utilidades puede tener para los usuarios. En el siguiente documento se explicará, por tanto, de que se trata esta tecnología, como funciona y qué usos se le puede dar. A continuación, veremos también cuales son las herramientas actuales de las que disponen los programadores, centrándonos en aquellas que se difunden bajo la Licencia Publica General de GNU. Éste es el denominado software libre cuya principal característica es que el código fuente de las aplicaciones está disponible para ser modificado y distribuido, bajo unas ciertas condiciones. En cuanto al tema de los dispositivos móviles nos centraremos en el Nokia N900, ya que es el modelo del terminal con el que hemos estado trabajando. Se incluye en este documento una descripción de sus características y prestaciones, así como la explicación de como portar algunas de las herramientas a este dispositivo para hacerlas funcionar. En concreto, haremos hincapié en la instalación, uso y funcionamiento de una aplicación de realidad aumentada para este dispositivo llamada “Araap”. Página 4 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 2.- INTRODUCCIÓN 2.1.- OBJETIVOS Y MOTIVACIÓN El objetivo principal del proyecto es investigar la situación actual de la realidad aumentada en el mundo de los dispositivos móviles, centrándonos en el Nokia N900. Hoy en día los teléfonos móviles nos ofrecen una serie de servicios que van mucho más allá de poder hacer y recibir llamadas. Sobre todo los smartphones disponen de una serie de características como la conexión a Internet o la localización geográfica que, teniendo en cuenta que podemos llevarlos encima a todas horas, están llamadas a revolucionar la forma en que vivimos y percibimos la realidad. Por su parte, la realidad aumentada es una tecnología muy llamativa a nivel visual y que provoca curiosidad en cada usuario que la utiliza. Por eso está popularizándose cada vez más. Además de eso, el imaginar todas las utilidades que puede tener y de que manera nos puede facilitar la vida hacen de este campo un área muy atrayente para los desarrolladores de software. Por tanto, poder basar el PFC en la realidad aumentada sobre un dispositivo móvil es una gran oportunidad ya que se está actuando sobre un área de futuro pero de actual expansión. Se podría decir que este proyecto pretende ser un primer paso para el desarrollo de aplicaciones de realidad aumentada para el N900, sirviendo de guía inicial de cara a futuros proyectos que puedan aprovechar la información aquí presente. Más concretamente, se analizará la aplicación Arapp para conocerla, saber como funciona y analizar que posibles utilidades puede tener su futuro desarrollo. Consideramos un aspecto importante el hecho de trabajar con software libre ya que proporciona una mayor libertad para los programadores. Además, el tener acceso al código fuente de una aplicación y la posibilidad de modificarla permite el desarrollo de nuevos productos o mejoras de los ya existentes sin la necesidad de comenzar todo el proceso partiendo de cero. Sin olvidar, por supuesto, las ventajas económicas que proporciona el software libre que hacen que, generalmente, la expansión de un producto sea mayor que la de uno de software propietario. 2.2.- REALIDAD AUMENTADA La investigación y creación de software donde se hace uso de la realidad aumentada está creciendo en los últimos tiempos. Sus múltiples aplicaciones y su atractivo aspecto visual está provocando que cada vez más los desarrolladores del campo de la informática y de las nuevas tecnologías se interesen por ella y la incluyan en sus proyectos. Por otro lado, el aumento de, no sólo el número de dispositivos móviles existentes en la actualidad, sino también de sus prestaciones hacen que las aplicaciones disponibles sean cada vez mejores y más numerosas. Teniendo en cuenta además que la práctica totalidad de estos dispositivos disponen de cámaras de vídeos de buena calidad, es inevitable pensar que adaptar la realidad aumentada a los dispositivos móviles es un campo de gran interés y de grandes oportunidades. Página 5 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles De hecho así se está produciendo pues ya podemos encontrar algunas aplicaciones interesantes que, aunque aún lejos de ofrecer lo que se puede esperar de una tecnología de estas características, ya nos permiten comprobar que no es una utopía el hecho de pensar que en un futuro no muy lejano la realidad aumentada estará muy presente en nuestra vida diaria. El campo donde, probablemente, haya progresado más su uso es en el de los videojuegos y entretenimiento. Las videoconsolas ya ofrecen la posibilidad de interactuar (incluso con el propio cuerpo del jugador) con objetos que parece que se mueven sobre el escenario que capta la cámara, viendo además el resultado de sus acciones en una pantalla donde se mezclan la imagen real y la virtual. Por supuesto, el uso de la realidad aumentada en los dispositivos móviles también irá encaminado hacia el ocio pero no de manera exclusiva. No hay que olvidar que una de las principales ventajas de estos dispositivos es que podemos hacer uso de ellos en cualquier lugar. Por tanto, se pueden crear aplicaciones donde el principal interés sea el mostrar una interacción del mundo virtual con el mundo real, teniendo en cuenta la movilidad que un dispositivo móvil proporciona. Por ejemplo, se podría sobreimprimir en la pantalla información sobre un edificio famoso que estás grabando o dibujar la forma de las constelaciones mientras enfocas a un cielo estrellado. La mayoría de los dispositivos de última generación incluyen también un receptor GPS que permite ubicar la localización del aparato. Esta cualidad puede ser utilizada por aplicaciones que hagan uso, también, de la realidad aumentada y que mediante la utilización de la cámara pueden mostrar información sobre el lugar donde te encuentras dependiendo incluso de la orientación espacial que tenga el dispositivo. Por ejemplo, una aplicación de navegación que nos indica la ruta a seguir en tiempo real hacia un destino podría hacerlo mostrando las indicaciones sobreimpresas en la propia imagen real que vas captando de la carretera. Estos son sólo algunos de los usos que una aplicación de realidad aumentada puede tener. Muchas de estas aplicaciones ya comienzan a ser una realidad. Gracias a la incipiente expansión en el desarrollo de esta tecnología y al interés de un público que cada vez dispone de más facilidades para acceder a ella, el crecimiento está asegurado. 2.2.1.- DESCRIPCIÓN La realidad aumentada consiste en sobreponer una capa de contenido virtual sobre la imagen del mundo real, complementándolo así con información del entorno que estamos visualizando[1]. Entonces, lo primero que necesitamos será un dispositivo capaz de captar la información del mundo real. Esto puede ir desde una simple cámara Web conectada a un PC hasta un dispositivo móvil con todo tipo de sensores (además de la cámara) que sean capaces de medir cosas como la inclinación, ubicación, orientación o aceleración del dispositivo. Existe una gran variedad de sistemas de este tipo en el mercado, aunque nosotros nos centraremos en el teléfono N900 de la marca Nokia. En el caso de los dispositivos móviles, el propio aparato lleva incorporado también el dispositivo de salida donde se visualizan los resultados y que no es más que la pantalla del teléfono. En el caso de un ordenador será el monitor donde se muestra, generalmente en tiempo real, la mezcla de la información real y virtual. Página 6 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Para poder realizar este proceso se hace necesario un software de realidad aumentada capaz de, a partir de los datos de entrada del mundo real, generar los datos virtuales que se van a mostrar entremezclados. En el cuarto punto del documento se enumeran algunas de estas herramientas. En muchos de los casos, este software de realidad aumentada se apoyará en los llamados marcadores, que no son más que símbolos que ayudan al programa de realidad aumentada a interpretar la información del mundo real indicándole, por ejemplo, donde debe ubicar una imagen tridimensional o un texto informativo. La realidad aumentad es una tecnología emergente, pero con multitud de aplicaciones en muy diversos campos. Desde, como se comentó anteriormente, el mundo de los videojuegos y entretenimiento hasta el de la educación o el ámbito militar. Según un estudio de 2010 de la consultora tecnológica Gartner sobre tecnologías emergentes, la realidad aumentada es una de las tecnologías por la cual se tiene una mayor expectativa de cara al futuro y será dentro de 5 o 10 años cuando alcance su nivel óptimo de productividad[2]. En el gráfico se puede apreciar el contexto en que se encuentra la realidad aumentada. La expansión de la tecnología será, principalmente, en los dispositivos móviles ya que podemos observar que otra tecnología con un fuerte futuro impacto será el estándar 4G, usada para la conexión de alta velocidad en los teléfonos móviles. Página 7 Figura 1: Ciclo de expectativas para tecnologías emergentes. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 2.2.2.- APLICACIONES En este punto vamos a describir algunas de las aplicaciones que ya existen actualmente y que hacen uso de la realidad aumentada. Es una manera de ver el punto de partida de la tecnología, sus primeros usos y sus distintos campos de aplicación. Nos centraremos sobre todo en aplicaciones para dispositivos móviles ya que son más útiles y accesibles para el usuario. Algunas son, además, de código abierto lo que facilita a los desarrolladores su mejora y expansión Una interesante y popular aplicación es el Layar Reality Browser[3]. Se trata de una aplicación multiplataforma disponible para la mayoría de teléfonos móviles que dispongan de GPS, acelerómetro y brújula digital. Consiste en un navegador que, a partir de tu ubicación, te muestra las aplicaciones de realidad aumentada de su catálogo disponibles para la zona donde te encuentres. Se puede decir que esta tecnología es un soporte para hacer llegar distintas aplicaciones (en el programa se refieren a ellas como capas) de realidad aumentada basadas en el posicionamiento espacial a los usuarios. Encontramos de distintos ámbitos, la mayoría de ellas para indicarnos la posición de lugares de interés cercanos como restaurantes, paradas de metro, farmacias, etc... Sin embargo, existen otras con algunas funciones más. Como por ejemplo, en el campo de la arquitectura existe una capa llamada UAR (Urban Augmented Reality) cuya función es mostrar modelos 3D de edificios de Amsterdam y Rotterdam. Esta guía arquitectónica del Instituto de Arquitectura de Holanda te permite, enfocando hacia una localización de estas ciudades, observar como era un edificio antiguamente antes de ser reformado, visualizar como sería una construcción que se planeó pero nunca se llegó a edificar o como se verá un edificio que aún tiene que terminar de construirse. Como se puede comprobar, es una aplicación de gran utilidad para fines turísticos. Otra aplicación útil para turistas, esta vez disponible sólo para iPhone es Nearest Tube[4]. En este caso lo que obtenemos es información sobre el metro de Londres (existen versiones paralelas para otras ciudades como Washington, París, Tokio o Madrid) de una manera tridimensional. Utilizando la cámara y la orientación del dispositivo, el programa nos sobreimprime en la pantalla información sobre la distancia a la parada más cercana y que dirección hay que tomar para llegar a ella. Página 8 Figura 2: Futura construcción vista en UAR. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Como se puede apreciar, la combinación entre realidad aumentada y localización por GPS es de gran utilidad y de ahí la ventaja de los dispositivos móviles. Otro ejemplo de ello es TwittARound[5] para iPhone que nos muestra, enfocando hacia una dirección, los mensaje publicados en la red social Twitter de personas que se encuentren cerca en esa dirección. Se puede elegir la distancia a rastrear y veremos sobreimpresa la información correspondiente a cada usuario sobre la pantalla. En el ámbito del entretenimiento encontramos LevelHead[6]. Se trata de un juego de plataformas que hace uso de la realidad aumentada para mostrar habitaciones sobre cubos, de manera que el usuario tiene que mover un personaje a través de ellos para conseguir completar el puzzle. Cada cubo representa un nivel con distintas puertas y escaleras y para completar el juego el jugador ha de pasar el personaje de una habitación a otra descubriendo donde está la puerta que las conecta. El juego está desarrollado para plataformas Linux, aunque a día de hoy no existen ejecutables disponibles para ningún sistema. El autor proporciona libremente el código fuente e invita a los desarrolladores expertos a intentar compilarlo para el dispositivo que deseen. Se trabaja para que en el futuro dispongamos de una versión final completa para alguna plataforma concreta. También en el ámbito del ocio encontramos un juego llamado ARQuake[7], que viene a ser una versión del popular juego Quake pero donde se usa la realidad aumentada. Cada uno de los jugadores va equipado con un equipo que incorpora, entre otros elementos, un visor, un acelerómetro y un localizador GPS. Entonces, al ir caminando normalmente, vas viendo los enemigos que vienen hacia ti sobreimpresos en la pantalla. Página 9 Figura 3: Usuario jugando a LevelHead. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Para realizar la conexión seguiremos los siguientes pasos. En primer lugar, hay que conectar el Nokia N900 al PC utilizando el cable USB que viene disponible en la compra del terminal. Al realizar la conexión, nos pregunta el modo de conexión. Tenemos que seleccionar Modo PC Suite. Después, hay que abrir el Mad-developer en el dispositivo y pulsar en botón Edit para así asignar una IP a la conexión. Si aparecen correctamente los números, entonces se pulsa Configure para fijar los valores. En la imagen se pueden ver los valores que se utilizan usualmente. Entonces ya podremos conectarnos, pero dado que lo vamos a hacer en modo desarrollo es necesario primero obtener el password. Como Mad-Developer es un programa pensado especialmente para crear una conexión robusta de los desarrolladores al dispositivo, nos permite obtener una clave válida para la cuenta developer. Página 16 Figura 8: Selección del modo de conexión. Figura 9: Edición de la dirección IP. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Para ello, pulsamos el botón Developer Password y se nos proporcionará contraseña a utilizar. Es importante siempre obtener primero la clave y luego realizar la acción de conexión puesto que si lo hacemos en orden inverso, la contraseña no servirá. Solamente es válida desde el momento en que se visualiza en la pantalla. Una vez realizado el paso anterior, conectaremos desde una terminal del PC mediante la orden SSH de la siguiente manera. ssh [email protected] Estamos conectando a la IP 192.168.2.15 (que corresponde al Nokia) como desarrollador. Introducimos el password y se completa la conexión. Ahora ya estamos trabajando sobre el dispositivo en el directorio de desarrollo. Solamente falta identificarnos como usuario root, ya que necesitamos tener los permisos adecuados para realizar algunas acciones. Todos los comandos y acciones realizadas que se describen en este documento se suponen hechos en modo root. Así que será lo primero que tenemos que hacer nada más conectarnos. Para ello, tecleamos la orden siguiente orden sudo: sudo gainroot Para cuando tengamos la necesidad de transmitir archivos desde el PC al teléfono podemos utilizar la orden SCP. Secure Copy o SCP es un medio de transferencia segura de archivos informáticos entre un host local (el PC en nuestro caso) y otro remoto (N900), usando el protocolo Secure Shell (SSH). Un ejemplo de su uso desde la terminal del PC sería el siguiente: scp imagen.png [email protected]:imagen.png Si en algún momento pasamos algún archivo ZIP comprimido necesitaremos instalar alguna utilidad para descomprimir ese tipo de archivos ya que no viene incluida ninguna por defecto. Por ejemplo, podemos conseguir del Administrador de aplicaciones InfoZip[17] y ya tendremos una orden de comando para comprimir y descomprimir archivos ZIP. Página 17 Figura 10: Clave para desarrollador. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 4.- HERRAMIENTAS DE REALIDAD AUMENTADA Las funciones básicas que una aplicación de realidad aumentada debe realizar son dos. En primer lugar, es necesario un reconocimiento de imágenes. Bien sea para poder localizar un marcador o para detectar alguna particularidad en la imagen que nos indique qué estamos viendo y donde se debe proyectar la parte virtual. Es necesario pues, disponer de una herramienta de reconocimiento y orientación espacial. En segundo lugar, hay que superponer en tiempo real las imágenes virtuales sobre las reales. Por ello, listamos a continuación una serie de herramientas software que se hacen necesarias para las dos tareas nombradas anteriormente. Muchas de estas herramientas son de código abierto, lo que permiten una sencilla difusión y utilización, lo que está provocando que la realidad aumentada esté entrando en una era de importante crecimiento. Se nombran las más conocidas y accesibles, pero nos centraremos en dos de ellas para explicar, además, su uso e instalación dentro del marco que supone este proyecto. –El SDK para realidad aumentada de la compañía Qualcomm[18] es un kit de desarrollo de software para los sistemas operativos móviles Android e iOS. En un principio fue lanzado en 2010 para Android 2010 y posteriormente, en julio de 2011, la versión para iOS fue publicada. Este kit pretende ser una herramienta de ayuda para desarrolladores que quieren construir aplicaciones de realidad aumentada para estos sistemas sin tener que crear todo el código desde cero. –Atomic Authoring Tool[19] es un software para la creación de escenas de realidad aumentada cuyo funcionamiento es el mismo que el de la mayoría de aplicaciones de RA; el programa detecta el patrón del marcador y muestra el objeto 3D. Su principal ventaja es que es multiplataforma, ya que está disponible tanto para Ubuntu, Windows y Mac. Hace uso de ArToolKit para la parte de reconocimiento y salida de vídeo. Página 18 Figura 11: Aplicación Atomic funcionando. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles –Atomic Web Authoring Tool[20] es un proyecto derivado del anterior, cuya particularidad reside en que está enfocado a la creación de aplicaciones de realidad aumentada para insertarlas en sitios Web. Su objetivo principal es proporcionar a la comunidad una herramienta, de código abierto, que se pueda modificar con facilidad y que no exija demasiados conocimientos técnicos para integrar la tecnología de la realidad aumentada dentro de cualquier sitio Web. Disponible para Windows y Ubuntu, su código está escrito en el lenguaje de programación Processing[21], especialmente pensado para el desarrollo de animaciones, imágenes e interacciones. Hace uso de una librería GPL, también basada en ArToolKit, llamada FLARToolKit[22]. –Look![23] es un framework para el desarrollo de aplicaciones de RA para Android. De código abierto, contiene herramientas para el dibujado de objetos simples con colores y texturas. Además, permite utilizar la conexión Wi-Fi del móvil para obtener la localización exacta en un espacio cerrado donde, en ocasiones, el GPS no es lo suficientemente preciso. Es un software de reciente creación y, por tanto, pocas aplicaciones lo han utilizado pero permite a los desarrolladores de Android ahorrar trabajo en la creación de sus aplicaciones. –SSTT[24] es una biblioteca para el posicionamiento en la realidad aumentada mediante marcadores, creada por Hartmut Seichter y cuya principal ventaja es la versatilidad que tiene, ya que está disponible para Windows, Mac y Linux. Además, tiene versiones optimizadas para plataformas móviles como Android, Maemo o iOS (SSTT Mobile). En el ejemplo de la siguiente figura, creado con SSTT, se ve como se puede utilizar la realidad aumentada para poder visualizar en 3D un edificio cuya información estás viendo en un libro sobre arquitectura. Página 19 Figura 12: Realidad aumentada con SSTT. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles –Osgart[25] es una biblioteca que mezcla ArToolKit con OpenSceneGraph[26] para intentar simplificar el desarrollo de las aplicaciones de RA. La herramienta GNU GPL OpenSceneGraph se usa para realizar gráficos en 3D de alta calidad, de manera que Osgart aprovecha sus ventajas y las de ArToolKit para crear una herramienta de desarrollo para aplicaciones que combine las ventajas de las dos herramientas. Dispone también de una versión profesional paralela, enfocada para la creación de aplicaciones comerciales. 4.1.- ARTOOLKIT ArToolKit[27] es una librería software que se emplea en el desarrollo de aplicaciones de realidad aumentada. Tal y como se ha podido comprobar en la descripción de las anteriores, es usada en multitud de proyectos de diversa índole. Su desarrollo inicial fue realizado en 1999 por el Doctor Hirokazu Katoe, mientras que su mantenimiento actual está respaldado por el Laboratorio Tecnológico de Interfaz Humana de la Universidad de Washington[28], el HIT Lab NZ de la Universidad de Catenbury de Nueva Zelanda y la compañía ARToolworks[29] de Seattle. Además de que su código completo sea distribuido bajo licencia GNU, otra ventaja de ArToolKit es que tiene distribuciones para Linux, IRIX, Windows y Mac. Lo cual, unido a sus múltiples funciones, hace que sea una de las herramientas más utilizadas. Como función principal ArToolKit permite calcular, en tiempo real, la posición y orientación de la cámara respecto a un marcador que aparece en la imagen. También posee algunas funciones de calibrado. Dado que ARToolKit no tiene una versión específica para Maemo, hemos intentado portar la versión de Linux disponible en su Web. Tras pasar el código descargado al dispositivo N900, y antes de instalarlo, hay que asegurarse de que tenemos las dependencias de paquetes necesarios. Página 20 Figura 13: Visualización de objetos con Osgart. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles La mayoría de ellos los podremos instalar mediante la orden apt-get install y el nombre del paquete. Son los siguientes: •freegult3 •freegult3-dev •libxi-dev •libxmu-dev •libv4l-dev •libgstreamer0.10-dev Si tenemos algún problema con los catálogos o alguno de los paquetes no está disponible en los repositorios también podemos instalarlo manualmente. Para ello hay que buscar el nombre del paquete en la página oficial de Maemo y descargar el fichero en formato .deb disponible. Para instalar un paquete basta con teclear: dpkg -i nombre_del_paquete También necesitamos instalar OpenGL, pero el problema es que no lo tenemos disponible para Maemo. En su lugar, haremos uso de OpenGL-ES[30], que es una variante simplificada de OpenGL desarrollada por el Grupo Khronos y diseñada específicamente para dispositivos empotrados como teléfonos móviles, PDAs, videoconsolas, etc... Afortunadamente, de OpenGL-ES si disponemos una versión en Maemo lista para instalar. La instalación de los paquetes requeridos para compatibilidad tanto con la versión OpenGL-ES 2.0 como con la 1.0 y 1.1 es la siguiente: apt-get install libgles2-sgx-img-dev apt-get install opengles-sgx-img-common-dev apt-get install libgles1-sgx-img-dev apt-get install libgles1-sgx-img libgles2-sgx-img opengles-sgx-img-common Tras esto, encontramos un par de errores más al hacer el make de la aplicación. Pese a haber instalado anteriormente el paquete freeglut3, el proceso de compilación nos indica que se necesitan un par de ficheros de cabecera más: glut.h y egl.h. Al igual que ocurre con OpenGL, tenemos que descargar la versión paralela para dispositivos portables llamada Glut-ES[31]. Podemos hacerlo desde su página oficial y tras ello, copiar el contenido de la carpeta “Inc” en “/usr/include”. Este directorio es la ruta donde los programas de compilación buscan las bibliotecas incluidas y los ficheros de inclusión que le son necesarias. En el caso de C++, vienen indicadas en el código mediante la línea #include<nombre_de_la _biblioteca> El egl.h lo bajamos[32] de la página de Khronos y lo copiamos en el mismo directorio dentro de la carpeta EGL. Después de todo este proceso, ya podremos compilar ARToolKit sin problemas. Para ello, en primer lugar, es recomendable utilizar la orden “make clean” para eliminar ficheros sobrantes que puedan ocasionar algún conflicto. Después ya podemos escribir “./Configure”, tras lo cual nos hará algunas preguntas previas de configuración. Página 21 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Select a video capture driver. 1: Video4Linux 2: Video4Linux+JPEG Decompression (EyeToy) 3: Digital Video Camcoder through IEEE 1394 (DV Format) 4: Digital Video Camera through IEEE 1394 (VGA NONCOMPRESSED Image Format) 5: GStreamer Media Framework Elegiremos la opción 5, ya que hemos instalado la librería multimedia Gstreamer. En las siguientes dos preguntas respondemos afirmativamente con la opción “y”. Do you want to create debug symbols? (y or n) Enter : y Build gsub libraries with texture rectangle support? (y or n) GL_NV_texture_rectangle is supported on most NVidia graphics cards and on ATi Radeon and better graphics cards Enter : y Si todo ha ido bien, podemos ejecutar la orden “make” y el proceso de instalación de ARToolKit se completará sin problemas. Adicionalmente, podemos utilizar gstreamer para comprobar si éste procesa correctamente la entrada desde la cámara y si ArToolKit sabe como tratar la fuente de vídeo. Con el siguiente comando se verifican todos los parámetros y se abre una ventana donde se visualiza el vídeo final mostrado por gstreamer: gst-launch-0.10 v4l2src device=/dev/video0 ! ffmpegcolorspace ! identity name=artoolkit ! xvimagesink En lo referente a la manera de funcionar de esta herramienta, podemos distinguir una serie de etapas en su proceso de funcionamiento hasta que se visualiza el objeto virtual sobre la imagen real. En primer lugar, la fuente de vídeo desde la cámara llega al ordenador donde el software analiza la imagen en busca de algún marcador. Estos marcadores son unas imágenes cuadradas de color negro sobre las que hay un código formado por cuadros blancos correctamente posicionados para formar una identidad reconocible por el programa. Se analiza cada fotograma de vídeo entrante transformándolo en imagen binaria para buscar en ella alguna forma cuadrada. Dentro de cada cuadrado hay un símbolo identificativo que va asociado al objeto a representar. Suelen ser símbolos bastante simples que simplemente ayudan a discernir entre los objetos que tengamos cargados en memoria. Página 22 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Una vez localizado un marcador, se realizan una serie de cálculos matemáticos para calcular la posición y orientación de la cámara respecto al cuadrado detectado. Se utiliza el sistema de matrices de OpenGL para representar la posición del marcador y realizar las transformaciones necesarias para adaptarlo al sistema de coordenadas de la cámara. El siguiente paso, una vez reconocido el marcador, es dibujar el modelo 3D de manera que tenga la misma orientación y posición que el patrón. Tras aplicarle las transformaciones 3D, el objeto queda dibujado directamente sobre la imagen de vídeo real, creando así la realidad aumentada. Todo este proceso se realiza en tiempo real mientras se va procesando el flujo de vídeo recibido de la cámara. Página 23 Figura 14: Marcadores utilizados por Arapp. Figura 15: Sistemas de coordenadas. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 4.2.- ARTOOLKITPLUS ArToolKitPlus[33] nace como una extensión al código de ArToolKit, al que no sólo se le añaden nuevas características, sino que además se optimiza para dispositivos móviles. Fue desarrollado por el Christian Doppler Laboratory de la Universidad Tecnológica de Graz como parte de sus proyectos “Handheld AR” que pretenden acercar la realidad aumentada a los dispositivos móviles. Debido a las peticiones recibidas, ArToolKitPlus fue hecho publico bajo licencia GPL, aunque sus creadores advierten que no está pensado para desarrolladores que se están iniciando en la realidad aumentada, sino que está recomendado para programadores avanzados en C++. Pese a que es una mejora de ArToolKit y aporta nuevas funcionalidades, la creación de una nueva interfaz de programación de la aplicación (API) respecto al original hace que no todas las funciones de ArToolKitPlus sean compatibles con las de su predecesor. Además, es importante destacar que esta librería lleva desde junio de 2006 sin ser actualizada, lo que puede aumentar las incompatibilidades y hacer que, con el paso del tiempo, algunas de sus funciones vayan quedando obsoletas. Aún así, es una librería muy utilizada debido a sus prestaciones. Por ejemplo, la aplicación arapp tratada en el quinto punto de este documento hace uso de ArToolKitPlus para el cálculo de la posición y orientación de la cámara respecto a los marcadores. A la hora de instalar ARToolKitPlus en el N900 no encontramos los mismos problemas de compatibilidad que con QtCreator, porque el mismo autor de la aplicación de arapp se ha encargado de mantener la versión de la librería de ArToolKitPlus para Maemo[34], eliminando así las posibles incompatibilidades. Podemos encontrar el programa en el repositorio de Extras-devel y descargarlo mediante apt-get con la orden: apt-get install artoolkitplus-dev Con esto, la herramienta quedará instalada en el sistema. Página 24 Figura 16: Resumen de los pasos que realiza ARToolKit. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 5.- APLICACIÓN ARAPP. 5.1.- DESCRIPCIÓN Arapp[35] (Augmented Reality APPlication) es el nombre de una aplicación desarrollada por Pavel Rojtberg[36]. Está escrita utilizando Qt[37] y se encuentra todavía en fase de desarrollo. Qt es una biblioteca multiplataforma, desarrollada por la empresa de telefonía móvil Nokia, que mediante el uso del lenguaje C++ da soporte a la creación de aplicaciones. Está enfocado hacia el desarrollo de programas con interfaz gráfica de usuario, pero también se puede usar para programas sin interfaz gráfica que funcionen mediante consola. Esta aplicación de realidad aumentada posee una interfaz táctil de manera que el usuario puede interactuar con los objetos virtuales y otros parámetros del sistema. Los objetos virtuales son representados en tiempo real en relación con el entorno físico utilizando la cámara del dispositivo. Todo ello con una iluminación realista y la representación de modelos de alta resolución virtual, lo cual se logra a través de aceleración hardware para los gráficos y sus mapas de sombra. En cuanto a su programación, nos centraremos ahora en describir de que se encarga cada una de las clases que encontramos en el código. La aplicación utiliza la biblioteca Qt de C++, por lo que lo primero que se hace en el main es crear una Qapplication que es la clase que maneja la interfaz gráfica del usuario. A partir de ahí, tenemos dos clases principales: View y Scene. El main se encarga de crear una escena vacía y se la pasa al constructor de la clase View. La clase View es la que se encarga de los menús, de gestionar los eventos que se producen y de llamar a los métodos de la clase Scene para indicar cuando se tiene que generar cada cosa. Entre sus funciones está, además, la de inicializar la librería gráfica y detectar cuando el usuario pulsa en algún punto de la pantalla o realiza alguna interacción utilizando las teclas. Por su parte, la clase Scene es la que se encarga de gestionar lo que vemos y representar los gráficos que conforman la realidad aumentada sobre la imagen real. Para ello, en primer lugar hay que crear el sistema de coordenadas y adaptarlo a la imagen de vídeo con la que se está trabajando. Se calculan los vectores de rotación y la distancia de la cámara a los marcadores detectados. En esta fase es donde arapp hace uso de la librería ARToolKitPlus mediante el uso de la clase TrackerSingleMarker. Con los métodos de esta clase se obtiene también la matriz de proyección, necesaria para representar los objetos correctamente acorde a la perspectiva que tenga la cámara respecto a los marcadores en ese instante. En la clase Scene también se indican las rutas donde se encuentran los modelos 3D definidos en archivos externos, se cargan los datos y se representa toda la escena incluyendo los objetos y las anotaciones que el usuario haya podido realizar. Existe una clase Object para las operaciones relacionadas con los objetos donde están los métodos para cargar las texturas, almacenar y modificar la matriz de transformación, etc... En la clase ObjReader es donde se lee línea a línea los ficheros OBJ y MTL para obtener todos los datos necesarios para el renderizado del objeto. Página 25 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Estas anotaciones son temporales y se eliminan al terminar la ejecución de la aplicación. 5.4.- FORMATO WAVEFRONT OBJ Algunos de los inconvenientes que nos podemos encontrar a la hora de usar la aplicación araap, pueden venir a la hora de querer personalizar la representación de los objetos para cambiar los que vienen por defecto por otros. Si son modelos 3D de objetos que ya tenemos, puede que tengamos que adaptarlos a las necesidades que la aplicación nos exige. Mientras que si la intención es integrar objetos propios, éstos deben ser creados siguiendo unas pautas que permitan que el formato con que se definan sea leído por el programa. Para ello, se define a continuación el formato .OBJ, tanto sus características generales como los requisitos propios necesarios para que sea aceptado por la aplicación. 5.4.1.- HISTORIA El formato de definición de geometrías en tres dimensiones Wavefront OBJ[40] fue desarrollado en 1989 por la compañía de gráficos por computador “Wavefront Technologies” para su paquete de software gráfico “The Advanced Visualizer”. En sus orígenes, este software era un conjunto de programas independientes que hacían uso del formato OBJ. Entre ellos, había un modelador 3D, un visor, un editor de imágenes de mapa de bits y un programa de renderizado. Al usar todos el mismo archivo de formato, se podía transferir la información geométrica de unos programas a otros. Fue un paquete precursor en la tecnología de gráficos por computador y fue usado para la elaboración de algunas películas como “Aladdín”, “Stargate: Puerta a las estrellas” o “Estallido”. En palabras del director de efectos especiales de Electronic Arts, Richard Taylor, los programas de Wavefront estaban “tan bellamente diseñados que incluso una persona sin conocimientos técnicos podría aprenderlos. Wavefront fue la principal razón de que los gráficos por computador dieran un paso adelante”[41]. Página 32 Figura 22: Variación de la anotación según la perspectiva de la cámara. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles En 1995 “Wavefront Technologies” fue comprada por “Silicon Graphics”[42] y fusionada con “Alias Research”, otra empresa del sector de los gráficos 3D, formando así “Alias Systems Corporation”. Esta nueva empresa creo el famoso programa de modelado 3D y animación “Maya”, usado en multitud de efectos visuales, videojuegos, películas animadas y series de televisión. Tal es así, que el 1 de Marzo del 2003, la compañía fue galardonada por la Academia de las Artes y las Ciencias[43] de EEUU con un Oscar por logros científicos y técnicos por su desarrollo del software Maya. Los fundadores de “Wavefront Techonologies”, Bill Kovacs y Roy A. Hall ya habían recibido en 1997 un premio de la academia por el que se les reconocía su trabajo en el desarrollo del visualizador avanzado de Wavefront. En 2005, “Alias Systems Corporation” fue comprada por el creador de AutoCad y 3DS Max, Autodesk[44]. Por su parte, el formato de archivo OBJ está abierto y ha sido adoptado por muchos otros proveedores de aplicaciones gráficas en 3D. En la actualidad, se puede considerar como un formato universalmente aceptado aunque cada aplicación lo haya adaptado a sus necesidades. En el siguiente punto se va a describir el funcionamiento del formato centrándose en la variante que acepta la aplicación arapp. 5.4.2.- DESCRIPCIÓN La descripción en este formato se realiza en un fichero ASCII con extensión .obj, en el que viene definida la geometría del objeto. Dentro de esta definición podemos distinguir varias secciones que conforman cada uno de los aspectos que son necesarios para la especificación. En primer lugar se define la información referente a los vértices, teniendo en cada línea las características de cada uno de ellos, acorde al siguiente formato: v x y z w Con la 'v' indicamos que se está definiendo un vértice, mientras que la 'x', 'y' y 'z' son número reales con las coordenadas geométricas del vértice en cuestión. La 'w' hace referencia a un peso necesario para la definición de curvas y superficies racionales. Es un campo no obligatorio cuyo valor por defecto es 1.0. Para curvas o superficies paramétricas también se pueden definir vértices siguiente el patrón: vp u v w Los campos 'u' y 'v' son los valores de los puntos de control de la curva o superficie, mientras que 'w' es, al igual que antes, el peso. Este tipo de vértices no los encontramos en los ficheros OBJ de la casa y la granja que vienen con la aplicación, ya que dichos objetos están definidos con geometría poligonal. Hay también que definir los vectores normales que son necesarios para un correcto renderizado. Vienen definidos acorde al formato: vn i j k Los tres parámetros son los números reales que forman la normal. Al igual que los vértices normales, hay que indicar uno por línea. Página 33 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Respecto a la textura del objeto, hay que definir las coordenadas (generalmente en dos dimensiones) de los vértices dentro del fichero de imagen. De esta manera, al definir las caras cada uno de los vértices que la formen tendrá su correspondiente coordenada en la textura. El patrón para los vértices de la textura es: vt u v w Con 'vt' se indica que se está definiendo una coordenada en la textura, mientras que 'u', 'v' y 'w' son los valores de las coordenadas de dicho vértice. Si la textura es unidimensional solamente será necesario el primer parámetro, mientras que si es 2D será necesario que aparezca tanto el valor de 'u' como el de 'v'. Si la textura con la que trabajamos tiene profundidad, ésta viene indicada en el valor de 'w'. Por defecto vale 0. Si el objeto representado tiene varios fichero de textura, se definen aquí todas las coordenadas de los vértices de todos los archivos. Al definir la cara ya se indica a que archivo de imagen hace referencia el vértice utilizado. Usando listas de índices de los vértices, de las coordenadas de textura y de las normales podemos definir las caras. Al igual que con el resto de elementos, cada cara viene representada en una línea que comienza, en este caso, con la letra 'f'. Se usa el siguiente formato: f v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3 ... Observamos que tenemos una serie de elementos separados con barras, que a su vez se separan unos de otros con espacios. Cada uno de estos bloques de elementos entre espacios representa un vértice de la cara, donde (para el primer trinomio) 'v1' es el índice de un vértice definido anteriormente, 'vt1' es el índice de una coordenada de textura y 'vn1' el índice de la normal correspondiente, también ya definida. Estos índices son independientes según el tipo de elemento (vértice, vértice de textura o normal) y van desde 1 hasta tantos elementos del tipo como hayan definidos en el fichero. Después viene un espacio y la información de otro vértice. Y así sucesivamente para tantos vértices como formen la cara. Según la especificación del formato OBJ no existe ningún límite en cuanto al número de vértices que puede tener una cara. Sin embargo, la variación del formato aceptada por la aplicación arapp para representar los objetos solo acepta caras formadas por tres vértices. Si incluimos en la definición caras con cuatro o más vértices solamente tomará los tres primeros, despreciando el resto. Si queremos incluir en la aplicación un modelo OBJ independiente ya creado o que generemos con algún programa de diseño, uno de los problemas que podemos tener al obtener un fichero mediante este método es que, como se ha indicado, la aplicación arapp solamente acepta caras triangulares y en la especificación obtenida es posible que existan caras definidas con más de tres vértices. En el apartado de caras del siguiente punto se presenta una posible solución para arreglar este problema. Página 34 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Además, es posible definir caras que no contengan información de texturas o de normales simplemente omitiendo el dato en la línea. Las barras separadoras no se quitan y es necesario respetar el orden de la especificación aunque no se hayan completado todos los datos. Por ejemplo; f 1 2 3 f 3/1 4/2 5/3 f 3//2 4//1 5//4 f 6/4/1 3/5/3 7/6/5 Observamos aquí cuatro formas distintas de definir una cara de tres vértices. En la primera se hace simplemente indicando los vértices, mientras que en la segunda se añade también información de textura para cada vértice. En la tercera opción se han omitido las coordenadas de textura y se ha añadido la información de la normal (Nótese que las barras separadoras persisten pese a faltar el vértice de la textura). Por último, la cuarta fila nos muestra una cara definida con todas sus propiedades. Esta última opción es la aceptada por la aplicación arapp para la representación de la información. Si a las caras les falta información no se podrá representar correctamente el objeto. Con todo esto tenemos definida la geometría de la figura, pero para indicar algunas opciones sobre la apariencia y las características del material hay que utilizar una serie de etiquetas que hacen referencia a un fichero ASCII externo llamado MTL[45]. Éste contiene la información necesaria sobre el sombreado de las superficies para hacer el renderizado y en él viene también indicado el nombre del fichero de la textura a la que hacen referencia los vértices de coordenadas de textura. Cada fichero MTL puede contener una o más definiciones de materiales. Para indicar el nombre de este fichero que acompaña al OBJ se utiliza la etiqueta mtllib seguida del nombre del archivo MTL. Esta línea viene escrita al comienzo del OBJ. Cada material especificado en el MTL (Material Template Libray) define las propiedades de reflexión de la luz en una superficie según el modelo de reflexión de la luz de Phong. Antes de ver como se indica el uso de estos materiales en el OBJ, vamos a pasar a describir el contenido de los ficheros MTL. Cada una de las definiciones de los materiales que se definen comienzan por una línea donde pone newmtl, un espacio y el nombre que se le quiera dar a ese material. En las siguientes líneas (hasta el siguiente newmtl o el fin del fichero) se indican los cantidades propias del material que se está definiendo y que vienen a ser los parámetros del modelo de iluminación de Phong. La primera palabra de la línea indica la característica y a continuación vienen los valores. Para el color ambiente: Ka r g b Donde 'r', 'g' y 'b' son las números reales que representan las componentes de color rojo, verde y azul para esta propiedad del material. El valor por defecto, por si no se indica ninguno, es 0.2,0.2,0.2. Para definir el ratio de reflexión de la componente difusa de la iluminación se usa: Kd r g b Página 35 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles El valor por defecto en este caso es 0.8,0.8,0.8. Para la componente especular: Ks r g b Este valor afectará a las zonas donde la intensidad de la luz sea más alta. Su valor predeterminado es 1.0,1.0,1.0. El siguiente parámetro es para indicar cual es la transparencia del material: d alfa El valor de alfa iría de 0.0 a 1.0, siendo 0.0 un material totalmente transparente y 1.0 completamente opaco (valor por defecto). Algunas implementaciones del formato Wavefront OBJ usan Tr en lugar de d como constante para indicar el valor de transparencia. Arapp utiliza la d. Para el definir el brillo del material se utiliza: Ns s El valor predeterminado para s es 0. Con los parámetros que estamos añadiendo, podemos apreciar que el modelo de iluminación de Phong esta formado por varios niveles de iluminación. Para calcular el color que se tiene que visualizar en un punto se tienen un cuenta la intensidad provocada por la luz ambiente, por la luz difusa y por la especular. Podemos indicar en las propiedades del material si queremos o no que se utilice la componente especular del modelo de iluminación: illum n En el caso de que n valga 1 estamos definiendo un material plano sin reflejos especulares. Por tanto, no será necesario haber definido un valor para el parámetro Ks. Si por el contrario el valor de n es 2, estamos ante el modelo de iluminación completo y si es necesario que exista la línea de Ks. Por último, se pueden utilizar mapas de texturas que se encuentren en ficheros externos para indicar como se debe visualizar el material del siguiente modo: map_Ka lenna.tga map_Kd lenna.tga map_Ks lenna.tga map_d lenna_alpha.tga map_bump lenna_bump.tga Con cada una de estas líneas se indica el nombre del fichero externo donde se encuentre un mapa de textura para la luz ambiente (map_Ka), un mapa de textura para la componente difusa (map_Kd), la especular (map_Ks), un mapa de textura para la transparencia (map_d) o un mapa de textura donde se indiquen relieves (map_bump). En la mayoría de los casos en que se usan, el de la luz ambiente y el de la luz difusa suelen coincidir. Página 36 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles En estas líneas es donde indicamos el nombre del archivo de imagen externo que se usa como textura para el objeto. Por ejemplo, en la definición de un material empleado en la casa que viene con arapp, se indica el uso de una imagen PNG como textura de la siguiente forma: map_Kd white_file1.PNG Por tanto, teniendo los distintos materiales definidos en el fichero MTL falta saber como indicar en el OBJ que material se usa. Habiendo previamente incluido el nombre del fichero MTL con mtllib, hay que poner en la definición de las caras una línea con el siguiente formato: usemtl nombre En nombre aparece el nombre del material definido en el MTL y dicho material se aplicará a todas las caras que vengan definidas a continuación de esta línea y hasta que aparezca otro usemtl. Otra etiqueta que se puede utilizar en la definición de las caras es: g nombre del grupo Sirve para ponerle un nombre al grupo de caras de la figura que viene a continuación. Generalmente se usa para agrupar un conjunto de polígonos que pertenecen a la misma parte del objeto o que tienen unas mismas propiedades de visualización. Tanto en el fichero OBJ como en el MTL, podemos insertar comentarios haciendo que la línea comience con el símbolo #. Todo lo que venga a continuación en esa misma línea sera tomado como una anotación que no afecta a la definición del modelo 3D. 5.4.3.- MODELADO DE UN DADO Para poder aprender a introducir un nuevo objeto en la aplicación, se expone a continuación la definición e integración de un dado. La creación de este objeto simple puede servir como base para conocer como se ha de realizar la definición de manera correcta de cara a otros objetos más complejos que se puedan crear en el futuro. Tal y como se puede observar en la siguiente figura el nuevo objeto consiste en un cubo con una textura correctamente ajustada, de manera que quede un número para cada una de las caras. El modelo ha sido totalmente diseñado manualmente escribiendo la definición en los ficheros de texto. Página 37 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles También se puede apreciar como, a diferencia de la casa de la derecha, el dado rojo no aparece centrado en el marcador sino que comienza desde una de las esquinas. Esto se debe a que en la especificación del cubo uno de los vértices de la esquina coincide con el punto (0,0,0) del sistema de coordenadas. Por tanto, si quisiéramos que el objeto se mostrase centrado habría que escribir las coordenadas correspondientes acorde con el tamaño del objeto para que quedara posicionado en el lugar deseado. Una vez tenemos los ficheros con la definición del dado creados, hay que modificar el código de la función setupObjects de la clase Scene para sustituir uno de los objetos que vienen por defecto por el propio. Basta cambiar la ruta del que se desee para hacer referencia al archivo OBJ del dado, tal y como queda en el código que se muestra en el apéndice 4. 5.4.3.1.- FORMATO Y DESCRIPCIÓN Tal y como indica la especificación, hemos trabajado creando dos ficheros ASCII con las extensiones .OBJ y .MTL donde se indican la descripción del objeto y del material, respectivamente. Como el dado es un objeto único y está envuelto todo por la misma textura sólo ha sido necesaria la definición de un material en el fichero MTL. El contenido de los archivos cubo.mtl y cubo.obj puede consultarse en los apéndices 5 y 6 del final del documento. Página 38 Figura 23: Visualización del dado y la casa Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 5.4.3.2.- VÉRTICES El objeto consta de ocho vértices y, dado que se definen independientemente uno del otro mediante sus coordenadas, no es necesario seguir ningún orden concreto para su definición. La siguiente figura muestra las coordenadas de cada uno de ellos acorde a la definición realizada en el fichero OBJ: Así que basta indicar en el OBJ las coordenadas de los ocho vértices, uno por línea. 5.4.3.3.- NORMALES Dado que las caras del dado son planas todos los vértices de una misma cara tendrán el mismo vector normal. Por tanto, sólo es necesario definir estas seis normales: (0,-1,0), (0,1,0), (0,0,1), (1,0,0), (0,0,-1), (-1,0,0). Estos vectores unitarios se asociarán a cada uno de los vértices de una cara en su definición y nos servirán para indicar la parte exterior de la misma. Este detalle es indispensable para una correcta visualización de la textura del objeto. 5.4.3.4.- TEXTURAS En el MTL viene indicado el nombre del archivo de textura que se utiliza, mientras que en el OBJ hay que definir los vértices de textura para ese mismo archivo (uno por línea). En el caso del dado se utiliza una imagen donde vienen todo los puntos dibujados para formar las distintas caras. Por la manera de definir los vértices, es recomendable que la imagen que se utilice sea cuadrada. Página 39 Figura 24: Distribución del los vértices del dado. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Observando la textura se aprecia que va a ser necesario definir 14 vértices, los cuales van a ir ubicados justo en los bordes de la imagen para separar los números unos de otros y luego asociar cada uno de estos puntos a una de las esquinas del cubo que conforma el dado. Las coordenadas varían entre 0 y 1, siendo (0,0) la esquina superior izquierda y (1,1) la esquina inferior derecha. 5.4.3.5.- CARAS Con la definición de las caras pondremos en común los vértices, las normales y las texturas. Se definen ocho caras, una en cada línea del fichero, indicando sus tres vértices espaciales con sus vértices de textura y normales correspondientes. Las caras deben ser triangulares para poder ser representadas. En la siguiente figura podemos apreciar tanto la ubicación de los vértices de textura en la imagen como su distribución para formar las caras. Es imprescindible que cada uno de estos vértices se asocie junto al vértice del cubo correspondiente para que la textura encaje con el modelo. Página 40 Figura 25: Imagen usada como textura. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles La definición de las caras se ha hecho siguiendo el sentido antihorario para el orden de los vértices. Par el caso de que se disponga de la definición de un modelo OBJ cuyas caras están formadas por más de tres vértices, hemos creado un script en AWK para intentar adaptarlo al formato correcto. AWK es un lenguaje de programación para procesar cadenas de texto. En los sistemas Unix viene integrado un programa (invocado mediante la orden awk) para interpretar programas escritos en este código. La idea es procesar un fichero .obj, de manera que cada vez que encuentre una línea de definición de cara la divida en tantas como sean necesarias para que, al final, todas las caras vengan definidas con sólo tres vértices. El código propuesto sirve para transformar caras de cuatro, cinco y seis vértices en caras de tres, pero es fácilmente ampliable para caras de más vértices. Página 41 Figura 26: Vértices de textura del dado formando las caras. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles Al igual que con los demás, podemos aplicar a los objetos las opciones de interacción ya vistas para modificar su escala o la dirección con la que proyectar la sombra. Página 48 Figura 37: Visualización de la Tierra junto al dado. Figura 38: Visualización de la Tierra. Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 6.- CONCLUSIONES El desarrollo de este proyecto ha supuesto para el autor un importante aprendizaje no solo en el campo de la realidad aumentada, sino también en el manejo de los sistemas operativos Maemo y la distribución Ubuntu de Linux. Se ha trabajado con ambos en profundidad conociendo sus detalles de funcionamiento y administración. El sistema operativo Maemo va a ser fusionado con el proyecto Moblin de Intel dando lugar al que será el sustituto natural en los futuros dispositivos móviles de Nokia y que se llamará MeeGo[48]. También es un sistema basado en Linux y que hace uso de las librerías de Qt. Por lo tanto, es de suponer que no se encontrarán grandes problemas de compatibilidad con las herramientas aquí expuestas. En cuanto a la aplicación Arapp, su desarrollo continua a día de hoy y es probable que en el futuro mejore en sus prestaciones y funcionalidades o que sirva de base para otras aplicaciones de realidad aumentada para el N900 o sus sucesores. Página 49 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 7.- REFERENCIAS Y BIBLIOGRAFÍA [1] “Realidad aumentada: Lo que la realidad esconde”, Blog Consultec, 2009-11-19: http://blog.consultec.es/index.php/2009/11/realidad-aumentada-lo-que-la-realidadesconde [2] 2010 Hype Cycle for Emerging Techonologies, Gartner, 2010-09-07: http://blogs.gartner.com/hypecyclebook/2010/09/07/2010-emerging-technologieshype-cycle-is-here [3] Layar Reality Browser: http://www.layar.com/browser/ [4] Nearest Tube: http://www.acrossair.com/apps_nearesttube.htm [5] TwittARound: http://i.document.m05.de/?page_id=700 [6] LevelHead: http://selectparks.net/~julian/levelhead/ [7] Proyecto ARQuake: http://wearables.unisa.edu.au/projects/arquake/ [8] Nokia N900: http://www.nokia.es/productos/moviles/nokia-n900-maemo-pantallatactil-teclado-qwerty [9] Página oficial de Maemo: http://www.maemo.org [10] Red Pill Mode: http://wiki.maemo.org/Red_Pill_mode [11] Repositorios de Maemo: http://repository.maemo.org/ [12] Catálogo Maemo Extras: http://repository.maemo.org/extras/install/extras.install [13] Catálogo Extras-testing: http://my-maemo.com/download/repos/extras-testing.install [14] Catálogo Extra-devel: http://repository.maemo.org/extras/install/extras-devel-fremantle.install [15] Actualizar el firmware del N900: http://wiki.maemo.org/Updating_the_firmware [16] Open SSH: http://www.openssh.org/ [17] Info-Zip: http://www.info-zip.org/ [18] Qualcomm AR SDK: https://developer.qualcomm.com/develop/mobile-technologies/augmented-reality [19] Atomic Authoring Tool: http://www.sologicolibre.org/projects/atomic/es/ [20] Atomic Web Authoring Tool: http://www.sologicolibre.org/projects/atomicweb/es/ [21] Lenguaje de programación Processing: http://processing.org/ Página 50 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles [22] FLARToolKit: http://www.libspark.org/wiki/saqoosha/FLARToolKit/en [23] Look!: http://www.lookar.net [24] SSTT - Augmented Reality Tracking Library: http://technotecture.com/projects/sstt [25] Osgart: http://www.artoolworks.com/community/osgart/ [26] OpenSceneGraph website: http://www.openscenegraph.org/projects/osg [27] ArToolKit: http://www.hitl.washington.edu/artoolkit/ [28] HITLab de la Universidad de Washington: http://www.hitl.washington.edu/ [29] ARToolworks, Inc: http://www.artoolworks.com/ [30] ARToolKitPlus para Maemo: http://maemo.org/packages/package_instance/view/fremantle_extrasdevel_free_armel/artoolkitplus-dev/2.2.0-0maemo1/ [31] OpenGL-ES: http://www.khronos.org/opengles/ [32] Glut-ES: http://glutes.sourceforge.net/ [33] EGL: http://www.khronos.org/egl/ [34] Web de la aplicación Arapp: https://launchpad.net/arinterface [35] ARToolKitPlus: http://handheldar.icg.tugraz.at/artoolkitplus.php [36] Qt: http://qt.nokia.com [37] Scratchbox: http://www.scratchbox.org/ [38] Arapp en Paquetes de Maemo: http://maemo.org/packages/source/view/fremantle_extrasdevel_free_source/arapp/1.0~beta1-0maemo5/ [39] Pavel Rojtberg: http://www.rojtberg.net/ [40] Especificación del formato OBJ: http://www.martinreddy.net/gfx/3d/OBJ.spec [41] Ellen Wolff 2006-06-01. "Remembering CG Pioneer Bill Kovacs". [42] Silicon Graphics International: http://www.sgi.com [43] The Academy Of Motion Pictures Arts And Sciences: http://www.oscars.org/ [44] Autodesk: http://www.autodesk.com/ [45] People.sc.fsu.edu 2004-06-14. “MTL Files - Material Definitions for OBJ Files": Página 51 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles http://people.sc.fsu.edu/~jburkardt/data/mtl/mtl.html [46] Blender: http://www.blender.org [47] Repositorio de modelos 3D para Blender: http://e2-productions.com/repository/modules/PDdownloads/ [48] MeeGo: https://meego.com/ [49] El blog de Parq: Compilando ARToolKit en Ubuntu. http://elblogdeparq.blogspot.com/2010/11/artollkit-271-ubuntu-1004-funciona.html [50] Lee G., Nelles C., Billinghurst M. & Kim G. J. 2004. "Immersive Authoring of Tangible Augmented Reality Applications" Proceedings of the International Symposium on Mixed and Augmented Reality 2004: http://home.postech.ac.kr/~endovert/ismar04-ppt.pdf [51] Tatzgern M., Kalkofen D., Schamalstieg D., 2010. “Multi-perspective compact explosion diagrams”, Computers & Graphics; extended papers from NPAR 2010. [52] Wagner D., Schmalstieg D., 2007. “ARToolKitPlus for Pose Tracking on Mobile Devices”, Graz University of Technology. Página 52 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 8.- APÉNDICES 1.- Variante de TrackerSingleMarker.h para arreglar el problema de las clases virtuales: #ifndef __TRACKERSINGLEMARKER_HEADERFILE__ #define __TRACKERSINGLEMARKER_HEADERFILE__ //#include <ARToolKitPlus/TrackerSingleMarkerImpl.h> #include <ARToolKitPlus/Tracker.h> #include <ARToolKitPlus/Logger.h> #include <vector> namespace ARToolKitPlus { class TrackerSingleMarker : public Tracker { public: void cleanup(); bool setPixelFormat(PIXEL_FORMAT nFormat) ; bool loadCameraFile(const char* nCamParamFile, ARFloat nNearClip, ARFloat nFarClip) ; void setLoadUndistLUT(bool nSet) ; void setLogger(ARToolKitPlus::Logger* nLogger) ; int arDetectMarker(ARUint8 *dataPtr, int thresh, ARMarkerInfo **marker_info, int *marker_num) ; int arDetectMarkerLite(ARUint8 *dataPtr, int thresh, ARMarkerInfo **marker_info, int *marker_num); ARFloat arMultiGetTransMat(ARMarkerInfo *marker_info, int marker_num, ARMultiMarkerInfoT *config); ARFloat arGetTransMat(ARMarkerInfo *marker_info, ARFloat center[2], ARFloat width, ARFloat conv[3][4]); ARFloat arGetTransMatCont(ARMarkerInfo *marker_info, ARFloat prev_conv[3] [4], ARFloat center[2], ARFloat width, ARFloat conv[3][4]) ; ARFloat rppMultiGetTransMat(ARMarkerInfo *marker_info, int marker_num, ARMultiMarkerInfoT *config); ARFloat rppGetTransMat(ARMarkerInfo *marker_info, ARFloat center[2], ARFloat width, ARFloat conv[3][4]); int arLoadPatt(char *filename) ; int arFreePatt(int patno) ; int arMultiFreeConfig(ARMultiMarkerInfoT *config); ARMultiMarkerInfoT *arMultiReadConfigFile(const char *filename); void activateBinaryMarker(int nThreshold); void setMarkerMode(MARKER_MODE nMarkerMode); void activateVignettingCompensation(bool nEnable, int nCorners=0, int nLeftRight=0, int nTopBottom=0); void changeCameraSize(int nWidth, int nHeight) ; void setUndistortionMode(UNDIST_MODE nMode) ; bool setPoseEstimator(POSE_ESTIMATOR nMethod); void setBorderWidth(ARFloat nFraction) ; void setThreshold(int nValue) ; Página 53 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles int getThreshold() const; void activateAutoThreshold(bool nEnable) ; bool isAutoThresholdActivated() const ; void setNumAutoThresholdRetries(int nNumRetries) ; const ARFloat* getModelViewMatrix() const ; const ARFloat* getProjectionMatrix() const ; const char* getDescription() ; PIXEL_FORMAT getPixelFormat() const ; int getBitsPerPixel() const ; int getNumLoadablePatterns() const ; void setImageProcessingMode(IMAGE_PROC_MODE nMode) ; Profiler& getProfiler() ; Camera* getCamera() ; void setCamera(Camera* nCamera) ; void setCamera(Camera* nCamera, ARFloat nNearClip, ARFloat nFarClip) ; ARFloat calcOpenGLMatrixFromMarker(ARMarkerInfo* nMarkerInfo, ARFloat nPatternCenter[2], ARFloat nPatternSize, ARFloat *nOpenGLMatrix) ; ARFloat executeSingleMarkerPoseEstimator(ARMarkerInfo *marker_info, ARFloat center[2], ARFloat width, ARFloat conv[3][4]) ; ARFloat executeMultiMarkerPoseEstimator(ARMarkerInfo *marker_info, int marker_num, ARMultiMarkerInfoT *config); void selectDetectedMarker(const int id); //Constructor añadido porque no existía aquí, solo en el Impl.h TrackerSingleMarker(int nWidth=DEF_CAMWIDTH, int nHeight=DEF_CAMHEIGHT); virtual ~TrackerSingleMarker() {} /* nCamParamFile is the name of the camera parameter file * nLogger is an instance which implements the ARToolKit::Logger interface*/ bool init(const char* nCamParamFile, ARFloat nNearClip, ARFloat nFarClip, ARToolKitPlus::Logger* nLogger=NULL) ; int addPattern(const char* nFileName); /// calculates the transformation matrix /* pass the image as RGBX (32-bits) in 320x240 pixels. * if nPattern is not -1 then only this pattern is accepted * otherwise any found pattern will be used. */ std::vector<int> calc(const unsigned char* nImage, int nPattern=-1, bool nUpdateMatrix=true,ARMarkerInfo** nMarker_info=NULL, int* nNumMarkers=NULL); /// Sets the width and height of the patterns. void setPatternWidth(ARFloat nWidth); /// Provides access to ARToolKit' patt_trans matrix void getARMatrix(ARFloat nMatrix[3][4]) const; /// Returns the confidence value of the currently best detected marker. ARFloat getConfidence() const; }; }; // namespace ARToolKitPlus //#include <ARToolKitPlus/TrackerSingleMarkerImpl.h> #endif //__TRACKERSINGLEMARKER_HEADERFILE__ Página 54 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles 2.- Modificaciones realizada en el fichero Makefile de Arapp: CC = gcc CXX = g++ DEFINES = -DQT_GL_NO_SCISSOR_TEST -DQT_DEFAULT_TEXTURE_GLYPH_CACHE_WIDTH=1024 -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED CFLAGS = -pipe -O3 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib2.0/include -I/usr/include/libxml2 -Wall -W -D_REENTRANT $(DEFINES) CXXFLAGS = -pipe -O3 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib2.0/include -I/usr/include/libxml2 -Wall -W -D_REENTRANT $(DEFINES) INCPATH = -I/usr/share/qt4/mkspecs/linux-g++-maemo5 -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtOpenGL -I/usr/include -I. -I/usr/X11R6/include -I. […] DIST = /usr/share/qt4/mkspecs/common/unix.conf \ /usr/share/qt4/mkspecs/common/linux.conf \ /usr/share/qt4/mkspecs/qconfig.pri \ /usr/share/qt4/mkspecs/features/qt_functions.prf \ /usr/share/qt4/mkspecs/features/qt_config.prf \ /usr/share/qt4/mkspecs/features/exclusive_builds.prf \ /usr/share/qt4/mkspecs/features/default_pre.prf \ /usr/share/qt4/mkspecs/features/release.prf \ /usr/share/qt4/mkspecs/features/default_post.prf \ /usr/share/qt4/mkspecs/features/link_pkgconfig.prf \ /usr/share/qt4/mkspecs/features/warn_on.prf \ /usr/share/qt4/mkspecs/features/qt.prf \ /usr/share/qt4/mkspecs/features/unix/opengl.prf \ /usr/share/qt4/mkspecs/features/unix/thread.prf \ /usr/share/qt4/mkspecs/features/moc.prf \ /usr/share/qt4/mkspecs/features/resources.prf \ /usr/share/qt4/mkspecs/features/uic.prf \ /usr/share/qt4/mkspecs/features/yacc.prf \ /usr/share/qt4/mkspecs/features/lex.prf \ /usr/share/qt4/mkspecs/features/include_source_dir.prf \ arapp.pro QMAKE_TARGET = arapp DESTDIR = TARGET = arapp first: all ####### Implicit rules .SUFFIXES: .o .c .cpp .cc .cxx .C .cpp.o: $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<" .cc.o: Página 55 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<" .cxx.o: $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<" .C.o: $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<" .c.o: $(CC) -c $(CFLAGS) $(INCPATH) -o "$@" "$<" ####### Build rules all: Makefile $(TARGET) $(TARGET): $(OBJECTS) $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS) Makefile: arapp.pro /usr/share/qt4/mkspecs/linux-g++-maemo5/qmake.conf /usr/share/qt4/mkspecs/common/unix.conf \ /usr/share/qt4/mkspecs/common/linux.conf \ /usr/share/qt4/mkspecs/qconfig.pri \ /usr/share/qt4/mkspecs/features/qt_functions.prf \ /usr/share/qt4/mkspecs/features/qt_config.prf \ /usr/share/qt4/mkspecs/features/exclusive_builds.prf \ /usr/share/qt4/mkspecs/features/default_pre.prf \ /usr/share/qt4/mkspecs/features/release.prf \ /usr/share/qt4/mkspecs/features/default_post.prf \ /usr/share/qt4/mkspecs/features/link_pkgconfig.prf \ /usr/share/qt4/mkspecs/features/warn_on.prf \ /usr/share/qt4/mkspecs/features/qt.prf \ /usr/share/qt4/mkspecs/features/unix/opengl.prf \ /usr/share/qt4/mkspecs/features/unix/thread.prf \ /usr/share/qt4/mkspecs/features/moc.prf \ /usr/share/qt4/mkspecs/features/resources.prf \ /usr/share/qt4/mkspecs/features/uic.prf \ /usr/share/qt4/mkspecs/features/yacc.prf \ /usr/share/qt4/mkspecs/features/lex.prf \ /usr/share/qt4/mkspecs/features/include_source_dir.prf \ /usr/lib/libQtOpenGL.prl \ /usr/lib/libQtGui.prl \ /usr/lib/libQtCore.prl $(QMAKE) -unix -o Makefile arapp.pro /usr/share/qt4/mkspecs/common/unix.conf: /usr/share/qt4/mkspecs/common/linux.conf: /usr/share/qt4/mkspecs/qconfig.pri: /usr/share/qt4/mkspecs/features/qt_functions.prf: /usr/share/qt4/mkspecs/features/qt_config.prf: /usr/share/qt4/mkspecs/features/exclusive_builds.prf: /usr/share/qt4/mkspecs/features/default_pre.prf: /usr/share/qt4/mkspecs/features/release.prf: /usr/share/qt4/mkspecs/features/default_post.prf: /usr/share/qt4/mkspecs/features/link_pkgconfig.prf: /usr/share/qt4/mkspecs/features/warn_on.prf: /usr/share/qt4/mkspecs/features/qt.prf: Página 56 Desarrollo de una aplicación de realidad aumentada para dispositivos móviles /usr/share/qt4/mkspecs/features/unix/opengl.prf: /usr/share/qt4/mkspecs/features/unix/thread.prf: /usr/share/qt4/mkspecs/features/moc.prf: /usr/share/qt4/mkspecs/features/resources.prf: /usr/share/qt4/mkspecs/features/uic.prf: /usr/share/qt4/mkspecs/features/yacc.prf: /usr/share/qt4/mkspecs/features/lex.prf: /usr/share/qt4/mkspecs/features/include_source_dir.prf: /usr/lib/libQtOpenGL.prl: /usr/lib/libQtGui.prl: /usr/lib/libQtCore.prl: [...] 3.- Fragmento modificado de View.cpp para la interacción por pulsación de teclas: void View::keyPressEvent(QKeyEvent *e) { if (e->key() == Qt::Key_Left) { s.angle += 10; } else if (e->key() == Qt::Key_Right) { s.angle -= 10; } else if (e->key() == Qt::Key_A) { s.activeOb->scale += 0.1; } else if (e->key() == Qt::Key_S) { s.activeOb->scale -= 0.1; } else if (e->key() == Qt::Key_C) { s.bg = s.bg == QColor(0,0,0,0) ? Qcolor(255,255,255,128) : QColor(0,0,0,0); } e->accept(); } 4.- Contenido de la función setupObjects en Scene.cpp: void Scene::setupObjects() { objects[0].setup(ObjReader("models/casa/casa.obj")); // 7 fps objects[0].id = 0; //objects[1].setup(ObjReader("models/farm/farm.obj")); // 10fps objects[1].setup(ObjReader("models/dado/dado.obj")); objects[1].id = 1; activeOb = &objects[0]; vq.setup(); sq.setup(); intf.setup(); } Página 57