Asistente virtual mediante realidad aumentada

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Ingenier´ ıa de Software Asistente Virtual mediante Realidad Aumentada Autor: Miguel Bay ´ on Sanz Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Ingenier´ ıa de Software Asistente Virtual mediante Realidad Aumentada Autor: Miguel Bay ´ on Sanz Tutora: Irene Lav´ın Perrino Agradecimientos A Irene Lav´ın, por su paciencia conmigo y con este proyecto, por ayudarme a terminarlo despu´es de tanto tiempo. A mi familia, que durante cada d´ıa de este largo y extra˜no camino, han ofrecido siempre su apoyo, orgullo y cari˜no pese a todos los tropiezos que se interpusieron. A mis compa˜neros y amigos de la carrera, que han estado conmigo en todas las situaciones y con los que, en conjunto, hemos formado una base de conocimiento m´as s´olida que cualquier libro t´ecnico a la hora de resolver dudas y proponer soluciones, y con los que he iniciado aventuras que no hubiera comenzado sin ellos. A mi pareja, por ser un apoyo incondicional, darme los empujones necesarios cuando hacen falta y obligarme a no abandonar incluso en los momentos en que la ansiedad supera las ganas de continuar. A Francisco Pe˜na, que durante la realizaci´on de este proyecto, pas´o de ser un compa˜nero m´as de la empresa a un incre´ıble apoyo, una f´abrica imparable de ideas y un amigo. A Alberto S´aenz y a ´ Alvaro Aparicio, que propusieron este proyecto y lo defendieron a capa y espada, observando cada m´ınimo avance con tanta ilusi´on como yo. I II Resumen Mediante este proyecto, se presenta la oportunidad al usuario de atender a una peque˜na charla impartida por un asistente virtual dotado de forma humana que, aplicando la Realidad Aumentada, se ubicar´a en el mundo real a trav´es de las im´agenes captadas por la c´amara del dispositivo m´ovil. De esta manera, y combinando varias tecnolog´ıas de software libre, siendo la interfaz WebXR la m´as destacable, se lograr´a generar una experiencia inmersiva para el usuario que logre captar su atenci´on y le ofrezca una presentaci´on de la web y de la empresa para la que se ha generado distinta a lo que puede encontrar en otros lugares, siendo necesario ´unicamente un dispositivo Android y el navegador Google Chrome para los dispositivos de dicho sistema operativo. IV Abstract Through this project, the user will have the opportunity to attend a short talk given by a virtual assistant with a human form that, applying Augmented Reality, will be located in the real world through the images captured by the camera of the mobile device. In this way, and combining several free software technologies, being the WebXR interface the most remarkable one, it will be possible to generate an immersive experience for the user that will capture his attention and will offer him an introduction to the web and the company for which it has been generated different from what he can find in other places, being necessary only an Android device and the Google Chrome browser for the devices of that operating system. ´ INDICE DE TABLAS XII Cap´ıtulo 1 Introducci´on El Trabajo de Fin de Grado supone el ´ultimo paso para obtener la titulaci´on cursada, y se muestra de manera muy intimidante al alumno. Por mucho que otros compa˜neros de a˜nos anteriores intenten suavizar su dificultad o la necesidad de hacer algo grande, uno no deja de verlo como la culminaci´on de varios a˜nos de aprendizaje en un estudio superior. Por eso, fue dif´ıcil elegir algo que realizar. Durante varios a˜nos, estuve dispuesto a llevar mi propio proyecto con varias ideas que fui reservando para m´as adelante, e incluso fueron varias las revisiones que hice a las ideas preparadas para distintos trabajos por distintos profesores. Sin embargo, a medida que se iba acercando la fecha de comenzar este proyecto, iba creciendo la necesidad de comenzar a trabajar y tener mis propios ingresos. As´ı, y teniendo el Trabajo de Fin de Grado en mente, comenc´e a buscar empleo planteando a las empresas que me conced´ıan entrevista dos condiciones: media jornada para poder terminar mis estudios y que me ofrecieran un proyecto v´alido para un TFG para poder terminar mi carrera. Fue as´ı como entr´e en SilverStorm, ahora Thirdera, despu´es de su adquisici´on por parte de esta ´ultima. Ellos me concedieron la flexibilidad necesaria para compaginar empleo y estudios, as´ı como facilidades a la hora de realizar los ex´amenes de la Universidad. Adem´as, al entrar en el equipo de innovaci´on, sab´ıa que me podr´ıan ofrecer un proyecto que se distinguiese de los que ofrec´ıan al resto de estudiantes que trabajaban en la empresa. Thirdera, al igual que SilverStorm en su momento, es una empresa dedicada a la digitalizaci´on y automatizaci´on de procesos a trav´es de la herramienta ServiceNow, en la que est´a especializada. El trabajo con esta herramienta consiste en ayudar a sus clientes a implantarla y adaptarla al uso que necesiten de la misma, de manera que el impacto para los usuarios sea el m´ınimo y la optimizaci´on de procesos de negocio se ampl´ıe paulatinamente. Por otro lado, ServiceNow permite tambi´en la creaci´on de plugins que pueden ser lanzadas al mercado. 1.1. Motivaci´on Tras un tiempo, y despu´es de comentarles que quer´ıa comenzar a desarrollar mi Trabajo de Fin 1 CAP´ ITULO 1. INTRODUCCI´ ON de Grado, me ofrecieron el proyecto que se explicar´a en esta memoria. Por aquel entonces, la p´agina web de SilverStorm desarrollada en WordPress contaba con un estilo sencillo y familiar para que los usuarios que entrasen conociesen la empresa y pudieran obtener la informaci´on que desearan de ella: a qu´e nos dedicamos, c´omo y con qu´e trabajamos, qu´e clientes tenemos o hemos tenido, de qu´e ofertas de trabajo disponemos, etc. No obstante, esta no lograba destacar sobre otras webs corporativas: sus animaciones eran aquellas que ofrec´ıa WordPress, los dibujos utilizados eran de una colecci´on de im´agenes de stock retocadas y su sencillez implicaba una cierta monoton´ıa. La idea del proyecto era a˜nadir un peque˜no detalle a esta p´agina que hiciera que esta destacara un poco m´as. La propuesta consist´ıa en generar un peque˜no avatar que pudiese contar, en cada una de las secciones, lo que el usuario pod´ıa encontrar. Este avatar aparecer´ıa en el plano real mediante Realidad Aumentada, una tecnolog´ıa en pleno auge [5] que reforzar´ıa la idea de que la empresa se mantiene en contacto con las ´ultimas tendencias tecnol´ogicas. Adem´as, para facilitar el uso de la c´amara para ofrecer im´agenes del mundo real, era imprescindible que el usuario accediese a esta experiencia a trav´es del m´ovil. 1.2. Objetivos El objetivo general consiste en desarrollar una aplicaci´on web de Realidad Aumentada capaz de mostrar modelos tridimensionales con animaci´on y sonido sincronizados en el entorno real del usuario. Esta aplicaci´on debe ser soportada en los dispositivos m´oviles actuales. Para conseguir esto, los objetivos se desglosaron en varios puntos. Debido a que el trabajo con estas tecnolog´ıas era nuevo para nuestro equipo y carec´ıamos de experiencia al respecto, el primer punto a abordar fue la investigaci´on sobre estas tecnolog´ıas. En primer lugar, se tomaron como referencia algunas aplicaciones publicitarias que utilizaban unas versiones algo m´as rudimentarias de Realidad Aumentada donde, escaneando un c´odigo QR, aparec´ıa en pantalla una persona comentando promociones sobre la imagen grabada por la c´amara del m´ovil. Nuestra intenci´on era investigar qu´e tecnolog´ıa se us´o en ese caso o en otros casos donde el resultado fuese mejor que el de partida. Por supuesto, y dado que el proyecto mayoritariamente trabajar´ıa sobre la tecnolog´ıa utilizada, el siguiente objetivo ser´ıa aprender a utilizarla y generar una estructura eficaz y escalable que permitiese futuras mejoras. Para complementar la experiencia inmersiva de la aplicaci´on, se a˜nadir´ıa sonido espacial al mismo sistema. Esto permitir´ıa que un usuario con auriculares pudiera reconocer, sin mirar a la pantalla, la direcci´on de la que proced´ıa el sonido y la distancia que le separaba del origen de este. 2 CAP´ ITULO 1. INTRODUCCI´ ON Tambi´en tendr´ıamos que desarrollar un modelo en 3D que funcionase como nuestro avatar. Para ello, habr´ıa que buscar herramientas de creaci´on, dise˜no y modelado en 3D, adem´as de aprender a utilizarlos para obtener un resultado satisfactorio. Para que diese la impresi´on de que el modelo fuese el que dijera todo lo mencionado en la grabaci´on, ser´ıa necesario sincronizar la voz con los gestos faciales y los labios del modelo. Para esta ((sincronizaci´on labial)), ser´ıa m´as eficiente buscar una aplicaci´on o herramienta que fuese f´acil de configurar e hiciese gran parte del trabajo. Por lo tanto, este objetivo se podr´ıa dividir en buscar una herramienta de sincronizaci´on labial, aprender a utilizarla y desplegar su funcionalidad sobre el proyecto. Ser´ıa necesario tambi´en generar una animaci´on para el resto del cuerpo del modelo 3D, de manera que este no resultara demasiado est´atico al hablar y diese una impresi´on algo m´as realista. El sistema tiene que ser accesible a trav´es de la web, por lo que ser´ıa necesario tambi´en alojarlo en un servidor que almacenase toda la funcionalidad, as´ı como los protocolos necesarios para que la conexi´on fuese fiable y segura. A mayores, otro punto a analizar en el proyecto era la accesibilidad del usuario a esta aplicaci´on. Debido a la finalidad de la web, con obvias intenciones comerciales y laborales, el equipo encargado de desarrollar originalmente esta consider´o que la mayor parte de los usuarios que visitaban la p´agina acced´ıan desde ordenadores, siendo una menor proporci´on los usuarios que acced´ıan desde m´oviles o tablets. Por esta raz´on, se consider´o que la mejor forma de hacer que un usuario pasara de un ordenador a un m´ovil era introduciendo un c´odigo QR que enlazase directamente a este sistema. En caso de que el usuario navegase desde el m´ovil, el mismo c´odigo funcionar´ıa a la vez como un bot´on con la capacidad de redirigir. 1.3. Conceptos de Realidad Aumentada Antes de comenzar a explicar en qu´e consiste este proyecto, es importante fijar algunos conceptos de Realidad Aumentada tal y como se van a utilizar en este tema, de manera que no queden ambig¨uedades a partir de este punto. 1.3.1. Realidad El concepto m´as importante y a la vez b´asico a dejar claro es el concepto de Realidad. Para nuestro sistema, se considera Realidad al conjunto de objetos, informaci´on y est´ımulos, principalmente visuales, que componen nuestro entorno y que percibimos a trav´es de nuestros sentidos. As´ı, si nos encontr´asemos en nuestra casa, podr´ıamos percibir varios elementos a trav´es de la Realidad: una televisi´on, un sof´a, una temperatura c´alida, una iluminaci´on baja, el ruido de un ventilador... 3 CAP´ ITULO 1. INTRODUCCI´ ON 1.3.2. Realidad Aumentada y Realidad Virtual La Realidad Aumentada y la Realidad Virtual son dos conceptos que a menudo se confunden por ser relativamente nuevos y por sus puntos en com´un. Sin embargo, los resultados pueden llegar a ser muy distintos o incluso opuestos en algunos casos. En ambos existe informaci´on generada a trav´es de sistemas inform´aticos, pero las diferencias son ampliamente notables [52]. Figura 1.1: Espectro entre un entorno real y un entorno virtual. Fuente: Realidad aumentada. Wikipedia La diferencia m´as destacable es el concepto de Realidad anteriormente mencionado, as´ı como su uso: en la Realidad Virtual, todos los elementos son generados digitalmente, de manera que la Realidad percibida es totalmente distinta a nuestro entorno ((real)). Para esto, com´unmente se hace uso de las gafas de Realidad Virtual, que a´ıslan la visi´on del usuario para que solo pueda captar la informaci´on generada y transmitida por las gafas. Sin embargo, en el caso de la Realidad Aumentada, la intenci´on es ampliar en tiempo real los datos captados de la Realidad, por lo que la base en estas tecnolog´ıas siempre ser´an im´agenes e informaci´on de nuestro entorno. A esto se le debe sumar todo aquello que a˜nada el sistema para ((ampliar)) la Realidad: figuras, texto, im´agenes, etc. Estas ´ultimas se encontrar´an superpuestas sobre lo captado del entorno de manera fidedigna y que ofrezca m´as valor a lo naturalmente captado. Figura 1.2: Meta Quest 2 para RV (izq.) y Microsoft Hololens para RA (der.). Fuentes: Meta Quest 2yMicrosoft HoloLens 4 CAP´ ITULO 1. INTRODUCCI´ ON Otra gran diferencia se puede encontrar en los dispositivos utilizados para aplicar ambas tecnolog´ıas. Como se coment´o antes, la Realidad Virtual utiliza unas gafas que a´ıslan al usuario de la Realidad. Cabe mencionar tambi´en que estas gafas son de uso exclusivo para dicha tecnolog´ıa, as´ı como su elevado coste, ya que son una tecnolog´ıa que, pese a que ya lleva varios a˜nos de desarrollo y mejora, a´un necesita asentarse correctamente en el mercado. La Realidad Aumentada, en cambio, se apoya generalmente en dos tecnolog´ıas dependiendo de su uso: por un lado, para los usos m´as cotidianos (aunque a veces tambi´en se encuentran en este grupo usos profesionales), se suele implementar en dispositivos m´oviles, donde la c´amara capta las im´agenes del entorno y el propio dispositivo m´ovil a˜nade la informaci´on pertinente; por otro lado, y para usos exclusivamente profesionales, muchas empresas han comenzado a utilizar gafas de Realidad Aumentada donde, mediante un juego de espejos, el usuario es capaz de ver informaci´on a˜nadida a su entorno. Por ´ultimo, pese a que ya se ha adelantado este punto previamente, por lo menos hasta el d´ıa de hoy la Realidad Virtual se est´a especializando m´as en el ´area l´udica, al ser los desarrolladores de videojuegos los principales interesados en esta tecnolog´ıa, aunque no se descarta que en el futuro pueda aplicarse para motivos m´as profesionales. La Realidad Aumentada tambi´en se utiliza para este fin, pero ha conseguido entrar en el ´area profesional como herramienta para varios sectores, como es el del marketing, donde aplicaciones como la de Ikea [31] permiten al usuario colocar muebles de la tienda en su propia casa para probarlos y, as´ı, impulsar las ventas. 1.3.3. Sonido espacial Para ampliar la sensaci´on de que los elementos que a˜nadamos mediante nuestra aplicaci´on forman parte de nuestro entorno, las voces de los asistentes virtuales dispondr´an de una propiedad denominada sonido espacial, que es la propiedad por la cual somos capaces de identificar la posici´on, orientaci´on y distancia del origen de un sonido [65]. Utilizando como ejemplo el sonido emitido por nuestra televisi´on. Si cerr´aramos los ojos, ser´ıamos capaces de interpretar varios datos ´unicamente por el sonido: no solo de d´onde procede o a cu´anta distancia est´a, sino que tambi´en podr´ıamos percibir informaci´on de nuestro entorno seg´un el eco que produce, como por ejemplo si estamos en una habitaci´on o al aire libre o el tama˜no de la habitaci´on en el primer caso. Toda esta informaci´on se percibe gracias a c´omo el cerebro interpreta los fen´omenos f´ısicos a trav´es de los cu´ales se transmite el sonido [22, 65]. Por ejemplo, somos capaces de interpretar si un sonido viene desde nuestra derecha o desde nuestra izquierda a trav´es de la diferencia de tiempo interaural: si un sonido tarda m´as en llegar a nuestro o´ıdo derecho que a nuestro o´ıdo izquierdo, quiere decir que el sonido procede de nuestra izquierda. Adem´as, la diferencia de tiempo entre ambos o´ıdos nos indicar´a tambi´en si el sonido est´a totalmente a nuestra izquierda o, en cambio, est´a situado en un ´angulo distinto. 5 CAP´ ITULO 1. INTRODUCCI´ ON Figura 1.3: Representaci´on de la diferencia de tiempo interaural (izq.) y representaci´on de la diferencia de nivel interaural (der.). Fuente: ((Spatial audio for networked music performances)) Otra forma que tiene nuestro cerebro de detectar la posici´on de un sonido es utilizando los cambios sutiles que se generan en las altas frecuencias cuando las ondas son interceptadas por la forma de nuestra oreja o de nuestra cabeza, conocidos como diferencia de nivel interaural. Por ejemplo, un ruido no nos llegar´a de la misma manera si se origina delante de nosotros o detr´as de nosotros. En el primer caso, el sonido ser´a parcialmente tapado por el trago de la oreja. Pero en el segundo caso, el sonido ser´a interceptado por gran parte del pabell´on auricular. En el segundo caso, las frecuencias m´as altas pueden llegar a perderse, por lo que nuestro cerebro interpretar´ıa que el origen del ruido se ha producido detr´as de nosotros, mientras que en el primer caso, al mantenerse m´as altas frecuencias, interpretar´ıamos que la posici´on se genera delante de nosotros. Esto, en combinaci´on con la inferencia anteriormente comentada, nos permitir´ıa ubicar un sonido en el plano horizontal. Por ´ultimo, cabe mencionar que estas t´ecnicas usadas por nuestro cerebro para ubicar sonidos en el plano horizontal son muy similares a las que utiliza para ubicarlos en el vertical o incluso para determinar la distancia a la que est´a dicho sonido, ya est´e est´atico o en movimiento. 1.4. Tecnolog´ıas utilizadas Para elaborar nuestra aplicaci´on de Realidad Aumentada, nos hemos apoyado principalmente en tres librer´ıas, todas ellas orientadas en su uso para aplicaciones web, que ser´a el caso de esta aplicaci´on. Tambi´en hemos utilizado algunas herramientas para el desarrollo e implementaci´on de c´odigo y modelos tridimensionales generados para la propia aplicaci´on. 6 CAP´ ITULO 1. INTRODUCCI´ ON 1.4.1. Herramientas de Realidad Aumentada La primera librer´ıa a comentar es WebXR [77]. Esta es una interfaz para generar entornos tanto de Realidad Aumentada como de Realidad Virtual y tiene una labor cr´ıtica ya que facilita al desarrollador la interacci´on con el hardware para utilizar funcionalidades del mismo. Aunque su uso se prepar´o para generar estos entornos en dispositivos de Realidad Virtual exclusivamente, m´as tarde se actualiz´o para poder ser utilizado en el navegador Google Chrome (versi´on 79) para m´oviles Android. Gracias aWebXR, podremos acceder a aspectos b´asicos para esta tecnolog´ıa, como el acceso a la c´amara del dispositivo, la ubicaci´on y orientaci´on del mismo, la creaci´on de una sesi´on interactiva... Para poder modificar y manipular los modelos en 3D que comentaremos en el desarrollo de esta memoria, hemos recurrido a la librer´ıa Three.js [68], una librer´ıa centrada en la generaci´on de modelos y gr´aficos 3D para navegadores web para JavaScript. Esta puede utilizar varios formatos de modelos 3D como FBX, Collada o OBJ, pero la documentaci´on recomienda encarecidamente utilizar el formato glTF por estar m´as centrado en su uso en tiempo de ejecuci´on: es un formato muy compacto y r´apido de cargar. WebXR se apoya en esta librer´ıa para mostrar estos modelos en im´agenes del mundo real (Realidad Aumentada) o en entornos totalmente generados (Realidad Virtual). La ´ultima librer´ıa utilizada es Resonance Audio [59], la cual permite ampliar las funcionalidades b´asicas de sonidos que contiene HTML en conjunto con JavaScript. En concreto, Resonance Audio permite simular sonidos espaciales recreando las caracter´ısticas que permiten a nuestro cerebro posicionar un sonido a nuestro alrededor. Adem´as, dispone de personalizaciones para el sonido emitido, como la simulaci´on de eco en interiores dependiendo de los materiales de las paredes, techo y suelo que rodeen al foco del sonido. La idea es combinar el uso de estas tres librer´ıas para generar una aplicaci´on web accesible desde el navegador m´ovil Google Chrome que aplicar´a la ((t´ecnica)) de Realidad Aumentada. Para ello, cada una de estas partes se implicar´a de una manera distinta: 1. WebXR se ocupar´a de interactuar con el hardware para obtener las im´agenes de la c´amara del dispositivo y las coordenadas de posici´on y movimiento. Tambi´en ser´a capaz de controlar si el m´ovil soporta las funcionalidades ofrecidas por la aplicaci´on. 2. Three.js permitir´a manejar modelos tridimensionales para controlar sus movimientos, posici´on, orientaci´on, etc. De esta manera, junto con la herramienta anterior, seremos capaces de mostrar objetos virtuales en im´agenes reales y compensar el movimiento del dispositivo con la posici´on y orientaci´on del modelo para generar la ilusi´on de que los gr´aficos en 3D insertados en las im´agenes captadas por c´amara se encuentran en un lugar fijo y cobran vida al animarse o moverse, produciendo as´ı la Realidad Aumentada. 3. Por ´ultimo, Resonance Audio se ocupar´a de replicar las propiedades del sonido espacial, consiguiendo con esto generar la ilusi´on de que los sonidos deseados surgen del modelo tridimensional, con la intenci´on de que este parezca que habla. As´ı, el usuario sentir´a una diferencia en el audio 7 CAP´ ITULO 1. INTRODUCCI´ ON si se encuentra m´as lejos o m´as cerca o si el modelo se encuentra a su izquierda, a su derecha, frente a ´el o tras ´el, coincidiendo el efecto del audio con la forma en que se escuchar´ıa este mismo si se produjera en la realidad. Combinado con todo lo anterior, obtendremos el efecto de Realidad Aumentada que buscamos. 1.4.2. Herramientas de trabajo y desarrollo El desarrollo del c´odigo de la aplicaci´on se apoy´o principalmente en Eclipse [20], concretamente en su versi´on Eclipse IDE for Enterprise Java and Web Developers. Esta versi´on del conocido entorno de desarrollo ofrece una gran variedad de facilidades para el desarrollo de aplicaciones web as´ı como ayuda para la escritura en lenguajes Java,Javascript oJSP, entre otros. Adem´as, nos apoyamos en GitHub [24] para aplicar un control de versiones seguro. Con este, pod´ıamos aplicar una rama para cada tarea y combinarla con la rama principal de desarrollo cuando todos los cambios estuviesen listos. Esto favorec´ıa tambi´en que, en un momento dado en que entrase una tarea prioritaria, se pudiese dejar otra a medias sin que los cambios en desarrollo de ambas tareas se afectasen entre ellas. M´as tarde, al obtener un servidor para pruebas y otro para los cambios definitivos, se aplicar´ıa en el primero la rama de desarrollo y en el segundo la rama maestra con las versiones finales. Para realizar las subidas desde la m´aquina al repositorio de GitHub, en lugar del cliente para escritorio ofrecido por la misma empresa, se decidi´o utilizar GitKraken [25]. Esta es una herramienta de escritorio que facilita la gesti´on de repositorios, simplificando las operaciones y comandos git y mostrando los cambios y ramas de manera muy visual. Para la prueba y depuraci´on del c´odigo se utiliz´o el ya mencionado navegador Google Chrome para dispositivos m´oviles [18]. Es importante mencionar que este no dispone de por s´ı de herramientas de desarrollo incorporadas como s´ı lo tiene su hom´ologo para ordenadores, por lo que para muchas de estas tareas era necesario conectar el m´ovil al ordenador para ver desde este ´ultimo los posibles mensajes de error o para poder utilizar la consola de comandos. Para el desarrollo de esta memoria, se ha utilizado en todo momento la aplicaci´on web de Overleaf [49], un editor de composici´on de textos L A T EX que permite la compilaci´on de archivos autom´atica, ayuda a la escritura reconociendo errores en texto y en comandos y una interfaz sencilla donde se muestra el c´odigo, los ficheros utilizados y el documento resultante tras la compilaci´on. Overleaf ofrece, adem´as, integraci´on con GitHub, de manera que esta memoria tambi´en ha contado por su lado con su propio control de versiones. Para la generaci´on de diagramas se ha utilizado Draw.io [19], una aplicaci´on de generaci´on de diagramas gratuita que permite generar diagramas de flujo, de clases, de componentes, etc. Draw.io 8 CAP´ ITULO 1. INTRODUCCI´ ON cuenta con una versi´on online y una de escritorio, tiene una interfaz sencilla y permite la integraci´on con plataformas de almacenamiento en la nube como Google Drive,Dropbox oOneDrive. Por ´ultimo, para desarrollar los modelos en 3D, se utilizaron, por separado, dos aplicaciones: MakeHuman [40] y Blender [11]. Sin embargo, de estas dos herramientas se hablar´a de manera m´as detallada en el cap´ıtulo 4. 9 CAP´ ITULO 2. PLANIFICACI´ ON RSK6 Documentaci´on del software a utilizar deficiente o m´ınimo Las librer´ıas, las herramientas y el lenguaje de programaci´on a utilizar en el proyecto no resultan de la ayuda adecuada para resolver las dudas o problemas que puedan surgir durante el proyecto Mod. Mod. Mod. RSK7 Baja o ausencia del personal El personal se ausenta del proyecto durante un tiempo significativo por causas de fuerza mayor Bajo Mod. Bajo RSK8 P´erdida del hardware del proyecto Debido a fallos en los equipos o en los dispositivos m´oviles utilizados para desarrollar y probar el proyecto, alguno o todos estos dejan de funcionar Bajo Mod. Bajo RSK9 Actualizaciones de las librer´ıas utilizadas Las librer´ıas implementadas en el proyecto reciben actualizaciones mayores que cambian parte de su implementaci´on Bajo Mod. Bajo Tabla 2.5: Presentaci´on de los riesgos Una vez presentados los riesgos se muestra la tabla 2.6, donde cada riesgo aparece acompa˜nado por c´odigo, su nombre, su plan de mitigaci´on y su plan de contingencia. Aqu´ı, los planes de mitigaci´on intentan minimizar el da˜no del riesgo mientras este no se haya cumplido, mientras que los planes de contingencia abordan el riesgo en caso de haberse cumplido. C´od. Nombre Mitigaci´on Contingencia RSK1 Cambios en el alcance del proyecto Revisar semanalmente el alcance y necesidades del proyecto en relaci´on al producto en el momento Replanificar las tareas del proyecto, analizando cu´ales son las nuevas tareas m´as prioritarias para obtener el producto m´ınimo viable RSK2 Estimaci´on del tiempo inadecuada Revisar semanalmente las tareas pendientes y analizar su complejidad en relaci´on con la experiencia obtenida sobre el mismo proyecto Modificar y aumentar la dedicaci´on semanal al proyecto para poder alcanzar la fecha de entrega. De ser necesario, aplazar la fecha de entrega RSK3 P´erdida del progreso del proyecto Realizar copias de seguridad tras cada cambio en un sistema de control de versiones Buscar opciones o software de recuperaci´on de datos. En su defec- to, reducir y replanificar los objetivos del proyecto. Contin´ua en la siguiente p´agina Tabla 2.6: Planes de mitigaci´on y contingencia sobre los distintos riesgos 16 CAP´ ITULO 2. PLANIFICACI´ ON RSK4 La tecnolog´ıa utIlizada no ofrece la calidad esperada Revisar durante la planificaci´on casos pr´acticos en los que se hayan utilizado las librer´ıas a utilizar Buscar un nuevo software que reemplace el de baja calidad y replanificar objetivos dando prioridad a las tareas necesarias para el producto m´ınimo viable RSK5 Falta de experiencia con las librer´ıas a utilizar Aumentar la dedicaci´on a formaci´on e investigaci´on de las tecnolog´ıas utilizadas A˜nadir personal de apoyo en el desarrollo del producto RSK6 Documentaci´on del software a utilizar deficiente o m´ınimo Aumentar la dedicaci´on a formaci´on e investigaci´on de las tecnolog´ıas utilizadas y revisar tutoriales profesionales previamente al desarrollo del producto Buscar informaci´on relativa a las consultas necesarias en foros dedicados o en fuentes alternativas RSK7 Baja o ausencia del personal Plantear las tareas con un ”buffer”que pueda compensar la posible ausencia del personal Replanificar el proyecto dando prioridad a las tareas necesarias para el producto m´ınimo viable RSK8 P´erdida del hardware del proyecto Asegurar el almacenamiento de todo lo necesario para el proyecto en la nube o en copias de seguridad para poder continuar con distintos dispositivos Adquirir nuevo hardware de desarrollo RSK9 Actualizaciones de las librer´ıas utilizadas Revisar mensualmente novedades sobre el software utilizado para prever posibles cambios Estudiar los cambios en la actualizaci´on del software y pruebas sobre el producto desarrollado para comprobar que todo funcione correctamente Tabla 2.6: Planes de mitigaci´on y contingencia sobre los distintos riesgos 2.1.4. Recursos Dentro del proyecto se han utilizado principalmente los recursos ofrecidos por la empresa, a mayores de una serie de recursos de uso libre o de posesi´on propia. Todos estos se pueden desglosar en hardware y software: Hardware: se ha utilizado para el desarrollo del c´odigo el equipo ofrecido por la empresa (Dell Vostro 3400), a mayores del dispositivo m´ovil personal para pruebas de desarrollo (Xiaomi Redmi Note 9 Pro). Tambi´en, como apoyo al desarrollo, se incluyen los perif´ericos ofrecidos por la empresa (pantalla, teclado y rat´on) a mayores del sistema de internet inal´ambrico montado en las oficinas. Tambi´en entran en esta categor´ıa el cable de carga del ordenador port´atil y el 17 CAP´ ITULO 2. PLANIFICACI´ ON cable USB tipo C para conectar el m´ovil al port´atil. Software: comenzando por el sistema operativo, ofrecido por la empresa en conjunto con el equipo, este es un Windows 10 Pro. En el dispositivo m´ovil, se ha utilizado en sistema operativo Android. En ambos sistemas operativos se ha instalado el navegador Google Chrome, cada uno en su respectiva versi´on. Para el desarrollo, se ha utilizado el IDE Eclipse en su versi´on para desarrollo web para soportar el lenguaje JavaScript. Todo el c´odigo ha sido almacenado en GitHub, y para las cargas se ha utilizado GitKraken. Para el desarrollo de la memoria se ha utilizado Overleaf , para la generaci´on de diagramas se ha utilizado Draw.io y para la creaci´on de objetos 3D se ha utilizado tanto Blender como MakeHuman. Por ´ultimo, se ha utilizado Amazon Web Services para poder ubicar la aplicaci´on en un servidor y para poder utilizar sus servicios web. No conviene olvidar como recursos humanos al equipo formado por ´ Alvaro Aparicio, Alberto S´aenz y Miguel Bay´on, adem´as de todo el equipamiento b´asico de trabajo que ofrece una empresa como las oficinas, aspectos b´asicos atados a esta (luz, gas y agua), silla y mesa, entre otros. 2.1.5. Estimaci´on de costes Dado que este proyecto est´a asociado a una empresa y son datos altamente confidenciales, no es posible ofrecer datos reales con respecto a este apartado. Sin embargo, se pueden hacer una serie de estimaciones en relaci´on a los costes medios de cada elemento a plantear. Dicho esto, se pueden plantear tres categor´ıas de gastos distintos (material, personal y espacio de trabajo), tras los cu´ales se puede plantear un total estimado. Para todo el material se ha utilizado el precio en Amazon en el momento de escritura de esta memoria, adem´as de productos similares a los utilizados para casos en que no se puedan mencionar. Producto Coste estimado Dell Vostro 3400 407,48€ Pantalla Asus VZ129HT 23” 149,00€ Rat´on Amazon basics 8,14€ Xiaomi Redmi Note 9 Pro 204,99€ Switch TP-Link LS105G 19,99€ Cable USB tipo A a tipo C 7,99€ Total 797,59€ Tabla 2.7: Estimaci´on de costes de materiales Para los salarios de los empleados, se ha utilizado la media estimada por la web Jobted [33]. 18 CAP´ ITULO 2. PLANIFICACI´ ON Rol Salario medio por hora estimado Total por proyecto Desarrollador 14,33 €/hora 4.299,00 € Project Manager 22,21 €/hora 4.442,00 € Product Owner 21,11 €/hora 2.111,00 € Total 57,65 €/hora 10.852,00 € Tabla 2.8: Estimaci´on de costes de personal Para los gastos medios de un espacio de trabajo se han utilizado los datos ofrecidos por Alegria Real State [7], a pesar de que estos datos pueden estar muy alejados de la realidad del consumo en una oficina. Adem´as, debido a la forma de pago de los servidores de Amazon Web Services, se ha incluido aqu´ı su precio. Los precios de estos servidores se calculan en base a su uso y a su memoria, por lo que se ha estimado en relaci´on a las horas de trabajo dedicadas al d´ıa. Se contrataron dos servidores, uno de tama˜no nano y otro small para desarrollo y producci´on, respectivamente. Recurso Consumo por mes Consumo total Agua 7,60 €/mes 91,20 € Luz 35,00 €/mes 420,00 € Gas 25,00 €/mes 300,00 € Internet 20,00 €/mes 240,00 € Servidor AWS nano 0,94 €/mes 11,28 € Servidor AWS small 3,77 €/mes 45,24 € Total 92,31 €/mes 1.107,72 € Tabla 2.9: Estimaci´on de costes por el espacio de trabajo Con todo lo anterior, podr´ıamos obtener los costes estimados totales. Categor´ıa Coste Material 797,59 € Personal 10.852,00 € Espacio de trabajo 1.107,72 € Total 12.757,31 € Tabla 2.10: Estimaci´on de costes totales 2.2. Descripci´on de las fases Como se defini´o anteriormente en el cronograma de la tabla 2.1, el proyecto se define en 3 fases, cada cual con su propia entidad y alcance. Mediante esto se busca organizar los resultados mientras 19 CAP´ ITULO 2. PLANIFICACI´ ON se observa el desv´ıo de la planificaci´on del proyecto. Las fases definidas son las siguientes: 1. Prueba de concepto (PoC). a) Concepto y estudio de su viabilidad. Se define la funcionalidad y el alcance del asistente para dos tipos de usuarios, que son los potenciales clientes compradores de tecnolog´ıa y los consultores preventas de dicha tecnolog´ıa. Se definen las tecnolog´ıas a utilizar: •Realidad Aumentada basada en la web. •Soluci´on de Realidad Aumentada WebXR. •C´odigo Polyfill. •Sistema operativo Android. Se estudia si estas tecnolog´ıas pod´ıan solucionar las necesidades de los usuarios hasta comprobar la viabilidad t´ecnica del proyecto. b) Estudio y especificaci´on de requisitos m´ınimos. Se estudiaron y definieron los requisitos m´ınimos de la nueva soluci´on: •La soluci´on lanzar´a una p´agina desde el navegador Google Chrome de un dispositivo Android que arranque la c´amara del dispositivo. •La p´agina lanzada cargar´a un modelo 3D animado o no que se posicionar´a en el entorno que est´e enfocando la c´amara del dispositivo. c) Dise˜no de la arquitectura del PoC. Se estudiaron y definieron los componentes de la PoC y se dise˜n´o la arquitectura del mismo d) Desarrollo del del PoC. Se desarrolla un sistema de carga de figuras 3D. Se desarrolla un sistema capaz de presentar figuras 3D en la Realidad Aumentada. 2. Dise˜no y desarrollo del Producto M´ınimo Viable (MVP). a) An´alisis de especificaciones del MVP. Se analiza el dise˜no, usabilidad, fiabilidad y funcionalidad del MVP. Se estudian y redefinen los requisitos m´ınimos, que son: •Inclusi´on en la p´agina de SilverStorm de un link que llevar´a a una p´agina con un mensaje de bienvenida y un bot´on que al pulsarlo iniciar´a la c´amara del m´ovil y la soluci´on de Realidad Aumentada. 20 CAP´ ITULO 2. PLANIFICACI´ ON •La p´agina lanzada cargar´a un modelo 3D animado de apariencia humana que se posicionar´a en el entorno que est´e enfocando la c´amara del dispositivo. •El modelo de apariencia humana presentar´a movimiento del cuerpo y de la boca. •El modelo animado contar´a una introducci´on de SilverStorm mientras realiza los movimientos. b) Dise˜no y arquitectura del MVP. Se estudian y definen los componentes del MVP y se dise˜na la arquitectura del mismo. c) Desarrollo incremental del MVP. Se desarrolla un asistente animado 3D con apariencia humana validado en una p´agina web. Se desarrolla una animaci´on sincronizada con la grabaci´on de un texto narrado. Se desarrolla un sistema capaz de mover un modelo 3D y de reproducir sonidos. Se desarrolla un software para ejecutar los modelos de 3D de Realidad Aumentada. d) Integraci´on, pruebas y validaci´on del MVP. Se integran todos los componentes en una versi´on del asistente animado en 3D Se realizan algunas de las pruebas identificadas en la tabla 6.1. 3. Desarrollo del Producto Final (FP). a) An´alisis del FP. Se analiza el dise˜no, usabilidad, fiabilidad y la funcionalidad del PF. Se estudian y redefinen los requisitos m´ınimos del PF ubicados en la secci´on An´alisis de requisitos del cap´ıtulo 3. b) Dise˜no y desarrollo incremental del FP. Se desarrolla un asistente animado 3D con apariencia humana validado en una p´agina web. Se utiliza la herramienta MakeHuman en combinaci´on con la herramienta Blender para generar y animar modelos 3D propios. Se utiliza la herramienta Blender para eliminar errores visuales generados por la herramienta MakeHuman. Se desarrolla un sistema capaz de combinar WebXR con Three.js para aplicar la Realidad Aumentada en la aplicaci´on. Se desarrolla un sistema capaz de ubicar sonidos mediante Resonance Audio. Se documenta el producto. c) Integraci´on, pruebas y despliegue del FP. Se integran todos los componentes en una versi´on animada del asistente en 3D. Se realizan todas las pruebas identificadas en la tabla 6.1. Se valida una tercera versi´on de asistente animado en 3D. El resultado obtenido ha sido una versi´on final validada del asistente animado 3D en un entorno web. 21 CAP´ ITULO 2. PLANIFICACI´ ON 2.3. Planificaci´on final La planificaci´on final ha ido sufriendo varios cambios a lo largo del proyecto. El primero y m´as impactante es la cantidad de horas semanales dedicadas al mismo, debido a que la dedicaci´on deb´ıa repartirse con otros proyectos a lo largo del a˜no, llegando a juntarse hasta 3 proyectos a la vez, por lo cual lo que inicialmente se plante´o como un 15 % de la jornada lleg´o a bajar hasta a un 10 % en las temporadas m´as notorias. Esto influy´o en algunas de las tareas planteadas para el producto final: algunas tareas de investigaci´on como la mejora de la iluminaci´on din´amica o la capacidad de ocultar los modelos 3D tras objetos de la realidad fueron descartadas debido a la falta de tiempo. Esto, a pesar de no ser estrictamente el caso, estaba estrechamente relacionado con el riesgo RSK1, y las medidas a tomar fueron manejadas tal y como se contempla en la tabla 2.6 Otro de los riesgos localizados que tambi´en impact´o sobre el proyecto es el RSK6. Tal y como se define en la tabla 2.5, la documentaci´on de algunas librer´ıas era insuficiente para resolver muchas dudas y fue necesario recurrir a foros dedicados y discusiones en los respectivos repositorios para resolver muchos problemas. Esto complic´o el trabajo y result´o en un c´odigo de una calidad algo menor de lo esperado. Tambi´en, el riesgo RSK5 ha sido un punto clave a mitigar durante todo el proyecto debido a que nadie del equipo ten´ıa ning´un tipo de experiencia sobre el producto a desarrollar. Durante el dise˜no de la arquitectura de la Prueba de Concepto (tabla 2.1) este se hizo especialmente notable, y debido a eso se estableci´o m´as tiempo para dicha tarea, por lo que el tiempo de formaci´on fue el necesario para poder completar de manera correcta el periodo dedicado a la PoC. Finalmente, pese a los problemas encontrados, el proyecto finaliz´o el 28 de septiembre de 2022, por lo que se cumpli´o el tiempo estimado para este. Sin embargo, como se mencion´o acerca del RSK1, el alcance sufri´o reducciones en cuanto a los requisitos menos importantes para poder cumplir con las fechas. Por otro lado, algunas decisiones de mitigaci´on fomentaron considerablemente el progreso del proyecto. Una de ellas es la decisi´on de realizar copias de seguridad en un sistema de control de versiones, herramienta que finalmente nos sirvi´o para poder acceder al c´odigo fuente desde diferentes sistemas, tanto los ordenadores de los diferentes componentes del equipo como desde el servidor en el que se lanzar´ıa finalmente la aplicaci´on web. Por otro lado, el aumento de dedicaci´on en formaci´on sobre las diferentes tecnolog´ıas y herramientas permiti´o salvar muchos de los problemas t´ecnicos encontrados durante el desarrollo. Durante la Prueba de Concepto, se llevaron a cabo los desarrollos necesarios para obtener una base en la que pudi´eramos basarnos para saber si el proyecto era viable. Esta era la fase en la que m´as pod´ıa variar la planificaci´on del proyecto debido a que en esta el desconocimiento de las herramientas era absoluto, y de hecho esta se retras´o, aunque no mucho m´as de lo esperado: a pesar de que se pretend´ıa tener una Prueba de Concepto para mediados de diciembre, finalmente esta se obtuvo el 28 de enero. 22 CAP´ ITULO 2. PLANIFICACI´ ON La fase que m´as se retras´o fue la fase del Producto M´ınimo Viable: esta deb´ıa estar terminada en marzo, plazo en el que se deb´ıa haber conseguido desarrollar modelos tridimensionales propios con sonido, sin necesidad de que estos fuesen perfectos. Adem´as, todo esto deb´ıa cargarse desde el servidor de pre-producci´on. Sin embargo, todo esto se consigui´o en junio, debido tambi´en a que la grabaci´on de las voces se aplaz´o y los modelos propios fueron m´as dif´ıciles de obtener de lo esperado debido a la complejidad de la herramienta Blender. Tambi´en, algunos requisitos del Producto Final se movieron al Producto M´ınimo Viable debido a una revisi´on de estos, lo que est´a estrechamente relacionado con el RSK1 y a su plan de contingencia. Por lo consecuente, el MVP se aplaz´o hasta el 6 de junio de 2022. Ya terminada la fase anterior, el Producto Final tuvo que adaptarse lo m´aximo posible a las fechas. Debido a los retrasos acumulados, se opt´o por obtener las caracter´ısticas m´as importantes principales, obviando detalles m´as finos como los comentados en relaci´on al RSK1 y que podr´ıan abordarse en el trabajo futuro. Para poder alcanzar las fechas de finalizaci´on, tambi´en se adapt´o el tiempo dedicado al proyecto, aumentando hasta el 30 % en lugar del 15 % planteado inicialmente. 2021 2022 Oct Nov Dic Ene Feb Mar Abr May Jun Jul Ago Sep Estimado PoC Real Estimado MVP Real Estimado FP Real Tabla 2.11: Comparativa de la planificaci´on estimada y la real 23 CAP´ ITULO 2. PLANIFICACI´ ON 24 Cap´ıtulo 3 An´alisis y dise˜no 3.1. An´alisis de requisitos A continuaci´on se enumerar´an los requisitos del proyecto que se han obtenido a trav´es de diferentes sesiones de estudio de diferentes productos similares en el mercado. A trav´es de estos, se puede obtener una idea b´asica del producto a obtener. 3.1.1. Requisitos funcionales Los requisitos funcionales son los casos pr´acticos que se implementar´an en el sistema a trav´es de distintas funcionalidades del mismo: desde respuestas al usuario hasta interacciones espec´ıficas con otros sistemas [58]. En este proyecto se han identificado los siguientes: C´odigo Descripci´on RF01 El sistema ser´a capaz de obtener im´agenes de la c´amara de un dispositivo m´ovil RF02 El sistema ser´a capaz de cargar modelos tridimensionales RF03 El sistema ser´a capaz de insertar renderizaciones de modelos tridimensionales sobre otras im´agenes RF04 El sistema ser´a capaz de detectar el movimiento del dispositivo utilizado RF05 El sistema ser´a capaz de iniciar una sesi´on de Realidad Aumentada RF06 El sistema ser´a capaz de reproducir pistas de audio con efecto espacial RF07 El sistema ser´a capaz de animar modelos tridimensionales RF08 El sistema ser´a capaz de detectar superficies en im´agenes captadas por el dispositivo m´ovil RF09 El sistema ser´a capaz de ubicar figuras tridimensionales en superficies encontradas en im´agenes Contin´ua en la siguiente p´agina Tabla 3.1: Requisitos funcionales del sistema 25 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO La primera secci´on a comentar ser´ıa el Modelo. En esta aplicaci´on, tal y como se ha planteado el desarrollo y teniendo en cuenta qu´e librer´ıas externas se han incorporado y c´omo se han utilizado, se ha tratado a estas como si fueran el propio Modelo. As´ı, nuestra informaci´on es en s´ı las librer´ıas externas a˜nadidas, que ser´an adem´as las que se encarguen de cargar los datos est´aticos de servidor: los modelos en 3D y las grabaciones de las voces de estos. La segunda secci´on ser´ıa la Vista. En este caso, la Vista de esta aplicaci´on constar´ıa ´unicamente de un HTML llamado index, que ser´ıa adem´as la landing page de la aplicaci´on. Sobre esta misma p´agina ser´a sobre la que se colocar´a m´as tarde un ((canvas)), que es el elemento HTML que permite mostrar elementos gr´aficos de manera din´amica a trav´es de JavaScript. Utilizando este ´ultimo podremos mostrar las im´agenes captadas a trav´es de la c´amara del dispositivo m´ovil y mezclarlas con los modelos en 3D para generar nuestra Realidad Aumentada. Por ´ultimo, la secci´on restante ser´ıa el Controlador. En este, se procesan todos los eventos generados por el usuario, adem´as de tratar toda la informaci´on que se recibir´a de los sensores del dispositivo para poder generar las im´agenes de manera veros´ımil. En este se ubicar´a un bucle que se ocupar´a de obtener la imagen a mostrar, mezclarla con el modelo en 3D, renderizar la imagen y situarla en la vista, todo esto de la manera m´as fluida posible para que el espectador no tenga impresiones que entorpezcan la experiencia de usuario. Adem´as, esta almacenar´a tambi´en informaci´on de la Sesi´on necesaria para el correcto procesamiento del sistema, tales como los modelos en 3D cargados, la referencia al objeto de JavaScript con el ((canvas)) antes mencionado, la posici´on del usuario y otros datos necesarios para el funcionamiento del sistema que ser´an mencionados a lo largo de esta memoria. Es importante mencionar que, a pesar de que se ha tratado a este sistema como un Modelo-Vista- Controlador y se le ha presentado como tal, ser´ıa m´as justo tratar a la aplicaci´on como si utilizara el patr´on Modelo-Vista-Presentador [66] por varias razones. La primera es que no tenemos constancia de c´omo almacenan estas librer´ıas las pocas referencias que se le entregan a la Vista y, a´un manteniendo esta referencia como si lo tratara como la Vista en este tipo de patrones, no parece realizar cambios sobre esta de manera directa. La segunda es que las actualizaciones se realizan directamente desde el Controlador, siendo necesario realizar desde este ´ultimo acciones expl´ıcitas para actualizar la apariencia de la vista, como por ejemplo el renderizado de la imagen a mostrar en pantalla. Por ´ultimo y m´as importante, es necesario que todos los cambios est´en revisados en el bucle que se genera en el Controlador, el cual se tratar´a m´as adelante. Esto obliga a este ´ultimo a solicitar informaci´on continuamente a las librer´ıas, hacer c´alculos y mostrarlos en pantalla, mientras est´a atento a los eventos de los usuarios. 32 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO Figura 3.2: Representaci´on gr´afica del patr´on Modelo-Vista-Presentador. Fuente: Model–view–presenter. Wikipedia Por todo esto, y dado que la l´ogica de negocio est´a separada de la interfaz de usuario, la estructura se corresponde con el patr´on Modelo-Vista-Presentador. Sin embargo, dado que desde el inicio del proyecto se trat´o cada parte como el cl´asico Modelo-Vista-Controlador, y dado que el Modelo-Vista- Presentador proviene de este ´ultimo, cada parte ser´a nombrada como si lo fuera, a´un siendo conscientes de las diferencias. Cabe destacar que el patr´on Modelo-Vista-Presentador, al igual que el Modelo-Vista-Controlador, implementa en cierto modo el patr´on Observer [23], que define una dependencia de forma que cuando un objeto cambie de estado se notifica y se actualizan autom´aticamente todos los objetos que dependen de ´el. En este caso, la vista actuar´ıa a modo de Observador, lanzando las acciones adecuadas para que se actualice el Modelo del sistema. 3.4. Modelo de dominio Figura 3.3: Modelo de dominio 33 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO El proyecto Asistente Virtual mediante Realidad Aumentada consta, en verdad, de un modelo de dominio muy sencillo, al mantener centralizada la funcionalidad en el controlador, tal y como se coment´o en la secci´on anterior. Por ello, el apartado m´as complejo se encuentra en este, siendo todo lo dem´as mucho m´as sencillo. El modelo, por otro lado, est´a formado por las interfaces de las herramientas externas utilizadas mencionadas en la secci´on 1.4.1. La vista se controla a su vez a trav´es de la interfaz HTMLCanvasElement proporcionada por JavaScript. 3.5. Diagrama de componentes Mediante el diagrama de componentes, podemos ver que gran parte del sistema se basa en el uso de herramientas externas, las cu´ales han implicado un estudio profundo para implicarlas de la manera correcta en la aplicaci´on. Figura 3.4: Diagrama de componentes 3.6. Diagrama de despliegue El diagrama de despliegue muestra la relaci´on entre los diferentes elementos de software y el hardware que los contiene. En este caso, al ser una aplicaci´on web, la comunicaci´on est´a planteada para que se impliquen en todo momento navegadores (en nuestro caso, espec´ıficamente el navegador Google Chrome para dispositivos Android) con el servidor Amazon Web Services. 34 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO Figura 3.5: Diagrama de despliegue 3.7. Diagrama de m´aquinas de estado El asistente virtual, dentro de la sesi´on de Realidad Aumentada, tiene un comportamiento b´asico y reproducible que puede verse reflejado en el diagrama de m´aquinas de estado, que a su vez deja ver la relaci´on entre estos comportamientos y la interacci´on del usuario. Figura 3.6: Diagrama de m´aquinas de estado 35 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO 3.8. Diagrama de actividades Para relatar la manera en que se ejecutar´ıa un flujo b´asico, se muestra tambi´en un diagrama de actividades con la forma m´as normal en que se ejecutar´ıa la aplicaci´on. Figura 3.7: Diagrama de actividades 36 Cap´ıtulo 4 Dise˜no y modelado en 3D Para dise˜nar los dos modelos tridimensionales con los que contamos, tuvimos que hacer una peque˜na investigaci´on sobre herramientas de dise˜no y modelado en 3D, ya que nuestra empresa no est´a especializada en este tipo de trabajos. Adem´as, nuestro equipo de Marketing no pod´ıa ocuparse de estos desarrollos debido a que solo trabaja con dise˜nos bidimensionales y a que el tiempo necesario a invertir en formaciones y en el propio modelado era considerablemente alto, por lo que no pudimos contar con su ayuda. La mayor parte de las webs que hacen comparaciones entre distintas herramientas de dise˜no y modelado 3D mostraban las mismas herramientas, que son las que barajamos en un principio: Blender [11], Unreal Engine [71] y Unity [70]. Blender es una de las herramientas m´as famosas que existen hoy en d´ıa para dise˜no de modelos 3D por su potencial y por ser gratuita. Se trata de una aplicaci´on de c´odigo libre muy extendida que dispone tambi´en de un manual de uso y tutorial [12] a disposici´on de todos los usuarios, adem´as de una de las comunidades m´as grandes para resoluci´on de dudas. Sus funcionalidades cubr´ıan todas nuestras necesidades (modelado, animaci´on, creaci´on...), aunque la interfaz no es considerada de las mejores. Unreal Engine era otra de nuestras opciones, debido a que cuenta con una gran trayectoria tanto en series y pel´ıculas de animaci´on como en videojuegos, aunque tambi´en se utiliza en ocasiones para arquitectura y dise˜no. Esta aplicaci´on es una de las m´as potentes del mercado y cuenta adem´as con cursos online, documentaci´on y tutoriales [36], as´ı como foros para consulta de dudas [72]. Esta aplicaci´on tiene como gran desventaja que la cantidad de funcionalidades al estar adaptado a esta gran variedad de usos hace de ella que sea m´as compleja de utilizar. Adem´as, para poder exportar los modelos en el formato que necesitamos (glTF oGLB), requer´ıamos de un plugin a mayores [26]. Por ´ultimo, hab´ıamos barajado tambi´en la posibilidad de utilizar Unity, una herramienta inicialmente creada para dise˜no de videojuegos, pero que tambi´en cubre todas las necesidades de modelado y animaci´on que necesit´abamos. Esta aplicaci´on es algo menos potente que la anterior opci´on, pero tambi´en es una de las herramientas m´as utilizadas del mercado, pudiendo darnos una soluci´on m´as que aceptable. Unity tambi´en requiere de una extensi´on para poder exportar modelos a GLB o a glTF [34]. 37 CAP´ ITULO 4. DISE˜ NO Y MODELADO EN 3D Finalmente, de entre las distintas herramientas, nos decantamos por Blender, siendo una de las principales razones la econ´omica: la libertad de uso de Blender est´a definida por una licencia GNU General Public License [13, 28], por lo que no tendr´ıamos ning´un problema al utilizarlo como empresa. Las otras dos herramientas, al contrario, requieren de licencias si se van a utilizar en entornos profesionales [51, 37], por lo que podr´ıa suponernos un gasto a mayores para una diferencia que, por nuestra baja experiencia en esta materia, no sabr´ıamos encontrar. Adem´as, encontramos a un compa˜nero en nuestra empresa que hab´ıa usado Blender anteriormente para crear peque˜nos videojuegos a modo de afici´on y que pod´ıa aconsejarnos y ayudarnos a la hora de usar dicha herramienta, punto que ser´ıa definitivo a la hora de tomar la decisi´on. Una vez decidimos la herramienta a utilizar, contemplamos tambi´en la idea de utilizar una aplicaci´on a mayores que estuviese especializada en generar figuras humanas desde cero, debido a que su creaci´on a trav´es de las herramientas anteriormente expuestas es muy costosa y requiere de personal m´as experimentado para obtener unos resultados que nos pareciesen aceptables para el proyecto. Inicialmente, optamos por buscar herramientas que generasen modelos 3D a partir de m´ultiples fotograf´ıas de una misma persona desde distintos ´angulos: aplicaciones como Meshroom [42] est´an orientadas a generar, no solo figuras humanas, sino tambi´en elementos del entorno como ´arboles, estatuas, edificios, etc. mediante fotogrametr´ıa, concepto que ellos mismos definen como la ciencia de tomar medidas a partir de fotograf´ıas. Tambi´en valoramos la posibilidad de utilizar un banco de modelos 3D previamente generados y que pudi´eramos modificar a nuestro placer, como lo que ofrece Renderpeople [57]. Esto, en combinaci´on con Blender, nos permitir´ıa modificar los aspectos necesarios del modelo y ahorrarnos un costoso trabajo de generaci´on desde cero. Sin embargo, y tambi´en bajo recomendaci´on del mismo compa˜nero antes mencionado, finalmente nos decantamos por usar la aplicaci´on MakeHuman [40]: una herramienta de c´odigo abierto y libre uso orientado a la generaci´on de modelos 3D humanoides que permite un ampl´ısimo abanico de caracter´ısticas a personalizar en estos: desde aspectos b´asicos como su altura hasta detalles min´usculos como el tama˜no del l´obulo de la oreja. Todo esto, adem´as, lo ofrece mediante una interfaz completamente sencilla de utilizar, a lo que adem´as hay que sumar que permite utilizar, tambi´en de manera sencilla, texturas personalizadas para el personaje, por lo que podr´ıamos dotarlo de elementos que pudi´eramos hacer completamente nuestros. Uniendo todo esto, podemos comenzar con el trabajo de modelado. 4.1. Creaci´on mediante MakeHuman La herramienta MakeHuman nos ofrece, desde un inicio, una serie de pesta˜nas que nos van informando de qu´e conjuntos de caracter´ısticas podemos modificar. Para el desarrollo de este modelo, nos 38 CAP´ ITULO 4. DISE˜ NO Y MODELADO EN 3D Figura 4.1: Pantalla inicial de MakeHuman vamos a centrar en solo algunas de estas pesta˜nas. La aplicaci´on ofrece las siguientes opciones: Modelado: para definir las proporciones y caracter´ısticas de la figura humana del modelo. Geometr´ıas: para modificar la forma de algunas de las estructuras del modelo, como dentadura, ojos, ropa, pelo, etc. Materiales: para modificar las texturas de las que estar´an formadas las mallas que componen la figura. Pose/Animaci´on: para establecer las opciones relacionadas con estas, como el esqueleto o la posici´on en la que reposa la figura. En el caso de la aplicaci´on desarrollada, interesaba tener dos modelos 3D distintos, siendo una figura una mujer y otra figura un hombre. Para esto, a trav´es de la primera opci´on del modelado, MakeHuman permite seleccionar conceptos m´as globales, como el sexo, la edad o la musculatura. A trav´es del resto de categor´ıas dentro de la pesta˜na principal, la herramienta permite personalizar el resto de secciones del cuerpo, como son la cara, el torso, los brazos y las piernas, cada una de estas con sus propias subcategor´ıas. En la pesta˜na de geometr´ıas, se establecen algunos detalles alternos a las caracter´ısticas corporales. Concretamente, se definen formas que van por encima del cuerpo (camisetas, sombreros, pantalones, etc.) o aquellas estructuras corporales que, por su variabilidad, se dise˜nan paralelamente a este (ojos, pelo, dientes, etc.). En este ´ultimo caso, a pesar de que MakeHuman ofrece muchas opciones, los modelos finalmente utilizados fueron creados con algunos de los recursos generados por 39 CAP´ ITULO 4. DISE˜ NO Y MODELADO EN 3D la comunidad, concretamente, los ojos, dientes y lengua utilizados. Esta decisi´on se tom´o debido a la necesidad de reducir el peso de la figura todo lo posible para su uso en la web, raz´on por la cual se opt´o por escoger recursos de baja resoluci´on para partes del cuerpo que, generalmente, no van a ser visibles o necesitan poco detalle para el uso dado. Estos ´ultimos, sin embargo, no pod´ıan omitirse debido a que la figura, al hablar, iba a mostrar tanto lengua como dientes. Para los ojos, por otro lado, se utiliz´o tambi´en una geometr´ıa de baja resoluci´on debido a que la diferencia entre esta opci´on y la de alta resoluci´on no era distinguible en la aplicaci´on de Realidad Aumentada. Figura 4.2: Detalle facial del modelo Para descargar los recursos que publica la comunidad, existen dos opciones: a trav´es de la web de la aplicaci´on o a trav´es de la propia aplicaci´on, en la pesta˜na ((Community)), donde el recurso seleccionado se descargar´a en la carpeta indicada. Sin embargo, este segundo m´etodo es muy lento debido a la propia aplicaci´on, por lo que se opt´o por descargar los recursos directamente de la web. Mediante la pesta˜na de selecci´on de materiales, previa elecci´on de ropa de los modelos en la anterior pesta˜na, se retocaron dos elementos: la piel del modelo, donde usamos una de las opciones que ven´ıan en la aplicaci´on evitando as´ı la piel seleccionada por defecto ya que resulta poco natural; y la textura de la ropa del modelo, donde utilizamos una opci´on personalizada por nosotros. Para este ´ultimo, se modific´o la propia textura original de la ropa que se seleccion´o en la aplicaci´on, siendo este un archivo en formato .png que se puede modificar f´acilmente mediante aplicaciones como GIMP. En esta modificaci´on probamos varios colores para la camiseta e introdujimos el logotipo de la empresa 40 CAP´ ITULO 4. DISE˜ NO Y MODELADO EN 3D para darle un aire m´as ((corporativo)). Figura 4.3: Modificaci´on de la textura de la ropa del modelo Finalmente, a trav´es de Pose/Animaci´on, se establece el elemento principal para la posterior animaci´on a trav´es de Blender: el esqueleto. MakeHuman ofrece cuatro opciones distintas de esqueletos, donde cada una de estas opciones tiene m´as o menos huesos, dependiendo del uso que se le quiera dar. Las opciones m´as b´asicas controlan ´unicamente las extremidades, siendo un esqueleto que podr´ıa ser ´util para animaciones muy b´asicas. Sin embargo, en este caso, queremos controlas tanto extremidades como m´usculos faciales, y para este caso, existen dos opciones de esqueletos: ((Default)) y((Default no toes)). Dado que la ´ultima opci´on descarta una serie de huesos que no se van a utilizar en la animaci´on de nuestra aplicaci´on, ser´a la opci´on que escogeremos, puesto que es algo m´as ligera. Figura 4.4: Detalle de los huesos del modelo 41 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA 1if (! navigator . xr) window . polyfill = new WebXRPolyfill () ; 2 3navigator .xr. isSessionSupported ("immersive -ar"). then( 4this.#checkSessionSupported 5); C´odigo 5.1: Uso de isSessionSupported en la aplicaci´on Esta funci´on (l´ınea 3) est´a integrada en el par´ametro xr, que est´a a su vez contenido en Navigator, objeto que contiene informaci´on acerca del navegador utilizado por el usuario. Este ´ultimo contendr´a el par´ametro mencionado ´unicamente si cumple con el segundo requisito de la librer´ıa WebXR. En caso contrario, al no existir, podr´ıa generarse un error. Para estos casos, se utiliza WebXRPolyfill [79], una librer´ıa utilizada para la retrocompatibilidad en los navegadores compatibles, pero que tambi´en a˜nade el mencionado par´ametro y, con este, la funcionalidad que comprueba si se soporta la Sesi´on. La l´ınea 3 del c´odigo anterior termina en una llamada as´ıncrona mediante el uso de .then() a la funci´on privada checkSessionSupported. Esta funci´on es la que se encarga de avisar al usuario en caso de que la Sesi´on no se pueda levantar. Sin embargo, en el caso afirmativo, se ocupa de preparar el entorno para el momento en que el usuario comience la sesi´on de Realidad Aumentada, cuyos detalles se explicar´an m´as adelante. 1# checkSessionSupported = (isSupported ) => { 2if ( isSupported ) { 3 4// Prepara el entorno 5 6}else { 7 8document.getElementById(" arButton "). disabled = true; 9alert ("Tu navegador no permite una sesi\ xF3n de Realidad Aumentada ."); 10 11 } 12 }; C´odigo 5.2: Control de la Sesi´on, dependiendo de si es o no soportada Esta estructura de funciones, tan com´un en JavaScript, es la que se utilizar´a en este proyecto para las funciones callback [16], funciones pasadas a otras funciones en forma de argumento de forma que puedan ser llamadas una dentro de la otra. As´ı, en este caso, la funci´on de la librer´ıa calcular´a si el sistema soporta o no la Sesi´on y, una vez lo sepa, llamar´a a nuestra funci´on (checkSessionSupported) pas´andole como argumento el resultado de sus c´alculos. Teniendo en mente estas condiciones, se plante´o que la Vista deb´ıa ser una interfaz sencilla que contuviese un bot´on que debiera accionar el usuario para iniciar la Sesi´on, siendo en las versiones m´as prematuras un bot´on simple sin ning´un tipo de customizaci´on. En las versiones m´as avanzadas, se gener´o un fichero CSS que personalizara la landing page de manera que, adem´as de tener los colores de la empresa, tuviese un aspecto m´as amigable para el usuario. Antes de que este bot´on pudiera ser 48 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Figura 5.3: Imagen de la landing page definitiva de la aplicaci´on web pulsado, el sistema deber´ıa haber calculado previamente si el sistema puede soportar la sesi´on, as´ı que con la carga de la Vista deb´ıa cargarse tambi´en el archivo Main.js, que consta ´unicamente de una l´ınea de c´odigo: 1window . arController = new Controller (); C´odigo 5.4: Inicializaci´on del Controlador Esta l´ınea lanzar´a el Constructor del Controlador, que contendr´a la construcci´on del WebXRPolyfill y la consulta al par´ametro xr con la funci´on isSessionSupported. De esta manera, el sistema est´a previamente preparado a cualquier acci´on del usuario, favoreciendo la carga de objetos m´as pesados de manera as´ıncrona mientras el usuario reacciona antes de pulsar el bot´on de lanzamiento de Sesi´on de Realidad Aumentada. Ahora, una vez se ha comprobado que el sistema es compatible con Realidad Aumentada, el usuario puede ejecutar su acci´on consciente para iniciar la Sesi´on. Es importante tener en cuenta que, cuando se construye el objeto, tambi´en puede detectar si la acci´on es consciente o no, por lo que la construcci´on de este tambi´en debe estar sujeta a un evento de usuario. Debido a esto, la construcci´on de este objeto no se puede incrustar en el mismo sitio que hemos incrustado la carga de objetos m´as pesados, junto al lanzamiento de la p´agina, sino que debe ir en la funci´on que se lance al pulsar el bot´on que se muestra en la Figura 5.3. Este bot´on lanzar´a la funci´on as´ıncrona startLoop (cuyo significado revelaremos m´as adelante), que cargar´a los datos restantes para poder ejecutar el grueso de la aplicaci´on, siendo la Sesi´on uno de ellos, como ya se ha comentado. En esta aplicaci´on, la sesi´on se lanza de la siguiente manera: 1// Constantes 2# GLOPTIONS = { xrCompatible : true }; 3# SESSIONOPTIONS = { requiredFeatures : [’hit - test ’] }; 49 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA 4// ... 5 6async startLoop () { 7this.# canvas = document . createElement ("canvas"); 8document .body . appendChild (this.# canvas ); 9this.# gl = this.# canvas . getContext (" webgl " ,this.# GLOPTIONS ); 10 11 // ... 12 13 this.# session = await navigator . xr . requestSession (" immersive -ar",this.# SESSIONOPTIONS); 14 this.# session . updateRenderState ({ 15 baseLayer : new XRWebGLLayer(this.# session , this.# gl ) 16 }); 17 18 // ... 19 } C´odigo 5.5: Funci´on de preparaci´on del bucle En el c´odigo se puede observar que, en la l´ınea 13, no se est´a construyendo un objeto utilizando el constructor cl´asico new, sino que se est´a solicitando un objeto XRSession (Sesi´on de WebXR) al par´ametro xr previamente mencionado mediante la funci´on requestSession [86]. Esta es la manera que tiene WebXR de asegurarse de que la sesi´on se lanza mediante un evento de usuario, debido a que es precisamente esa funci´on la que recoge la informaci´on necesaria y hacer las comprobaciones correspondientes al respecto. Tambi´en se puede observar que la funci´on recibe dos par´ametros: la cadena de texto “immersive-ar” en primer lugar y this.#SESSIONOPTIONS en el segundo. El primero es un par´ametro obligatorio que aclara a la funci´on qu´e tipo de Sesi´on se pretende lanzar (Realidad Aumentada,Realidad Virtual oinline, una opci´on que no nos ocupa ahora), siendo el valor presente en el c´odigo el necesario para indicar que queremos solicitar una Sesi´on de Realidad Aumentada. El segundo valor, opcional en este caso, sirve para especificar la configuraci´on que se establecer´a en nuestra sesi´on, en caso de que no queramos utilizar los valores por defecto. En esta aplicaci´on se establece una ´unica opci´on, definida en la constante de la l´ınea 2, que indica las caracter´ısticas que ser´an requeridas durante la sesi´on. En este caso, se indica que ser´a necesaria la caracter´ıstica Hit Test o, como lo llamaremos para esta aplicaci´on, ((c´alculo de superficies)), aunque eso es algo que explicaremos m´as adelante. Justo despu´es de solicitar la Sesi´on, se utiliza a esta misma para lanzar la funci´on updateRenderS- tate [84] en la l´ınea 15. Esta funci´on solicita cambios de configuraci´on a partir del siguiente fotograma que se cargue. Sin embargo, como a estas alturas a´un no se ha cargado ning´un fotograma, se entiende que estos ((cambios en la configuraci´on)) son para el primero y para los siguientes fotogramas (es decir, para todos, dado que esa configuraci´on no va a cambiar en esta aplicaci´on). 50 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA La configuraci´on que se solicita cambiar para los fotogramas es la que se prepara en las l´ıneas 7, 8 y 9 junto con la constante de la l´ınea 2: en la l´ınea 8, estamos generando un canvas, que es un objeto de HTML generado a partir de JavaScript cuya finalidad es albergar objetos gr´aficos, como ya se mencion´o en la secci´on 3.3. Para insertar este objeto en nuestra Vista, se ejecuta la acci´on de la l´ınea 8, momento a partir del cu´al este objeto ocupar´a la pantalla completa de nuestro dispositivo m´ovil. Si no a˜nadi´esemos m´as funcionalidad, ver´ıamos que nuestra pantalla no mostrar´ıa nada m´as que una pantalla en negro. Esto se debe a que a´un no hemos insertado ning´un objeto gr´afico en nuestro canvas, para lo que a´un quedan unos pasos. Por ´ultimo, en la l´ınea 9 se solicita al objeto canvas un ((contexto)) a trav´es de la funci´on getContext. El contexto de un canvas es una interfaz a trav´es de la cu´al se puede interactuar y generar gr´aficos e im´agenes desde el c´odigo de JavaScript [76], por lo que nos resulta imprescindible para trabajar con este ((lienzo)). Primero, a la funci´on le indicamos qu´e tipo de im´agenes vamos a utilizar para que nos devuelva el objeto de contexto correcto (en nuestro caso, el contexto va a ser la inserci´on de im´agenes en 3D). Eso lo hacemos mediante el primer par´ametro (“webgl”), mientras que en el segundo, tal y como ocurri´o al solicitar la sesi´on de WebXR, le establecemos una serie de opciones que queremos que sean distintas a las predeterminadas. En este caso, queremos activar la opci´on ((xrCompatible)), que indica que indica al canvas que el contexto que nos devuelva tiene que ser compatible con WebXR [30]. Esta configuraci´on es la que se almacena en la constante de la l´ınea 2. Una vez entendido esto, solo queda a˜nadir esta configuraci´on a la funci´on updateRenderState. A trav´es del objeto XRWebGLLayer, generaremos un objeto que enlace el contexto del canvas (es decir, la interfaz para poder dibujar sobre este) y la Sesi´on WebXR que mantendremos para aplicar nuestra Realidad Aumentada [89]. Esto lo asociaremos con la opci´on ((baseLayer)) a la misma Sesi´on a partir del momento en que comiencen a lanzarse los fotogramas con la sencilla intenci´on de indicarle a la Sesi´on cu´al ser´a el objeto que le renderizar´a las im´agenes obtenidas desde la c´amara del dispositivo. Esto significa que el contexto, a trav´es del enlace creado con el objeto XRWebGLLayer, obtendr´a la informaci´on de la c´amara del dispositivo y lo traducir´a en la colecci´on de p´ıxeles que plantaremos en el ((lienzo)). De esta manera tendr´ıamos iniciada la forma m´as b´asica de Sesi´on, aunque a´un no ser´ıamos capaces de ver nada a trav´es de la pantalla de nuestros dispositivos. Para esto, vamos a necesitar lanzar un bucle en el que procesemos y mostremos los fotogramas que captemos con la c´amara de nuestro m´ovil. 5.2. Procesado iterativo Para poder mostrar por pantalla cada fotograma, as´ı como hacer los c´alculos relacionados con las figuras que vamos a insertar llegado el momento, es necesario crear un bucle que dure tanto tiempo como el usuario vaya a permanecer en la Sesi´on. En cada una de las iteraciones, la aplicaci´on solicitar´a al hardware del dispositivo m´ovil la imagen captada a trav´es de su c´amara. 51 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Este bucle funcionar´a de una manera un tanto especial: a diferencia de los bucles for owhile, donde se ejecuta un c´odigo de manera secuencial y sin tener nada m´as en cuenta que lanzar la siguiente iteraci´on cuando la anterior haya terminado, en este bucle se ((solicita)) al navegador que ejecute una funci´on callback en cuanto est´e preparado, lo que permite que la aplicaci´on se adapte a la capacidad del dispositivo, debido a que no todos ser´an capaces de procesar igual de r´apido la misma informaci´on. En esta funci´on callback, que definiremos nosotros, ser´a en la que se le indicar´a al sistema que muestre por pantalla la informaci´on que queramos. Esto, a efectos pr´acticos, es lo que determinar´a los fotogramas por segundo: si un sistema, desde que se solicita la ejecuci´on de la funci´on hasta que muestra el fotograma en pantalla, tarda 0,025 segundos de media, entonces mostrar´a en un segundo alrededor de 40 fotogramas (es decir, 40 fotogramas por segundo). Esta capacidad para solicitar la ejecuci´on de una funci´on callback cuando el sistema est´e disponible la tiene la funci´on requestAnimationFrame de la Sesi´on de WebXR [83]. Por esto, es imprescindible que la Sesi´on se haya iniciado previamente. En esta aplicaci´on, la funci´on se lanza en dos puntos dentro del Controlador. 1async startLoop () { 2 3// ... 4// Solicitud del primer fotograma 5this.# session . requestAnimationFrame ( this.#loopFunction); 6 7} C´odigo 5.6: Funci´on que solicita la carga del siguiente fotograma La primera llamada a dicha funci´on se realiza al final de la funci´on startLoop, que es la funci´on llamada por el bot´on de la Vista y que, como su propio nombre indica, es la que inicializa este bucle, haciendo ciertas preparaciones antes como el inicio de la Sesi´on, como ya sabemos. Al lanzar la funci´on requestAnimationFrame, es necesario indicarle cu´al va a ser la funci´on callback que se va a poner ((en cola)) de ejecuci´on. En nuestro caso, esta funci´on es loopFunction, donde ejecutaremos nuestro procesamiento de im´agenes: 1# loopFunction = (time , frame) => { 2 3// ... 4// Solicitud de siguiente fotograma 5this.# session . requestAnimationFrame ( this.#loopFunction); 6 7// Enlazado de imagen de camara con modelo 8this.# gl . bindFramebuffer ( this.# gl. FRAMEBUFFER , this.# session . renderState . baseLayer . framebuffer ); 9// ... 10 11 }; C´odigo 5.7: Funci´on bucle con el contenido m´ınimo 52 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Para poder generar el bucle que se encargar´a de procesar y mostrar la imagen, es necesario que en alg´un punto se solicite de nuevo al navegador que se vuelva a lanzar esta misma funci´on. Para ello, el mejor sitio es la propia funci´on loopFunction, que solicitar´a al navegador que se vuelva a lanzar cuando este est´e preparado (l´ınea 5), form´andose as´ı un bucle infinito, en el que se realizar´a el procesado que definamos en la funci´on por cada iteraci´on y que terminar´a cuando el usuario decida, como se explicar´a m´as tarde. En esta funci´on callback, podemos ver que se reciben dos par´ametros generados desde la Sesi´on al llamarla: time yframe [83]. El par´ametro time es una variable de tipo Double que representa la diferencia de tiempo en milisegundos desde que se ha iniciado la Sesi´on hasta que se ha ejecutado la funci´on indicada en requestAnimationFrame. Esta es una herramienta ´util para calcular la posici´on id´onea en la animaci´on de un modelo en 3D, pero en esta aplicaci´on se utiliza una herramienta distinta por conveniencia, al pertenecer a la librer´ıa Three.js, de la que se tratar´a m´as adelante. Por otro lado, el segundo par´ametro, frame, es el objeto en que WebXR nos almacena informaci´on que, m´as tarde, nos ser´a crucial para poder hacer los procesamientos que queremos, como por ejemplo la posici´on y orientaci´on del usuario en el momento de la iteraci´on. Ahora, antes de comenzar cualquier procesamiento, vamos a decir al sistema c´omo obtener la imagen obtenida a trav´es de la c´amara en nuestro canvas. Esto se realiza mediante la funci´on de la l´ınea 7, [75], que pertenece al contexto del canvas e que implanta en su Framebuffer la informaci´on que le indiquemos. El Framebuffer es un espacio de memoria utilizado para almacenar la informaci´on necesaria para generar la salida visual en la pantalla. Entre otros datos, en el Framebuffer se almacenar´a informaci´on como los valores de color, de transparencia y brillo de cada p´ıxel [21], as´ı como la proporci´on de la imagen a generarse. En este caso, el Framebuffer destino pertenece al contexto del canvas, por lo que al almacenar en este la informaci´on de una imagen, el contexto se encargar´a de pintarlo en el ((lienzo)). La funci´on bindFramebuffer recibe dos argumentos. En el primero, se indica el buffer que se va a utilizar mediante una enumeraci´on contenida en el mismo contexto. El objeto ofrece varias opciones seg´un el tipo de operaci´on que se pretenda utilizar, pero nosotros utilizaremos #gl.FRAMEBUFFER, que es el ´unico buffer que existe para WebGL, siendo el resto para contextos WebGL 2. En el segundo argumento, se indica de d´onde debe extraer la informaci´on sobre la imagen que se generar´a en el lienzo. En este caso, lo extraeremos del objeto Sesi´on. Este contiene una propiedad de solo lectura que provee informaci´on sobre la imagen a renderizar llamado renderState, de donde podremos adquirir el objeto baseLayer que contendr´a su propio Framebuffer para almacenar la imagen captada por la c´amara del dispositivo. De esta manera, estaremos indicando al sistema que pinte en el ((lienzo)) la imagen captada por la c´amara. Con esto, ya tendr´ıamos una aplicaci´on capaz de captar las im´agenes de la c´amara del dispositivo m´ovil y que nos ofrecer´ıa informaci´on del dispositivo como la posici´on u orientaci´on del mismo. Ahora, podemos trabajar en insertar los modelos en 3D para generar nuestra Realidad Aumentada b´asica. 53 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Figura 5.8: Ejemplo de renderizado de un modelo en 3D extra´ıdo de la biblioteca de modelos 3D de la aplicaci´on de Windows Visor 3D 5.3. Modelo en 3D y Three.js A partir del sistema b´asico generado en la secci´on anterior, podemos empezar a a˜nadirle complejidad a nuestro sistema. El primer elemento que a˜nadiremos es un modelo en 3D que utilizaremos como base en esta aplicaci´on. Para la carga, inserci´on, control y movimientos de los modelos en 3D se ha utilizado en esta aplicaci´on la librer´ıa Three.js.Three.js es una librer´ıa ligera preparada para su uso en aplicaciones web compatible con JavaScript [69]. Adem´as, este est´a especializado en el control de modelos en 3D en formato GLB yglTF, que son dos formatos basados en JSON y que est´an creados para ser ´optimos en tiempo de ejecuci´on (el formato GLB es el equivalente en binario a glTF) [39]. La librer´ıa Three.js basa su funcionalidad en el uso de Escenas o Scenes, el objeto que utiliza esta librer´ıa para almacenar y presentar sus modelos en 3D, la iluminaci´on o focos de luz que los alumbrar´an y las c´amaras virtuales que observar´an a estos mismos [63]. Aplicando un s´ımil sencillo, la Escena de Three.js podr´ıa equivaler a una escena de cine, donde los actores equivaldr´ıan a los modelos en 3D, los focos equivaldr´ıan a la iluminaci´on y las c´amaras equivaldr´ıan a las c´amaras virtuales. Este ´ultimo concepto es muy importante, debido a que afectar´a continuamente al renderizado de los modelos en 3D. La c´amara virtual es la que simula el punto de vista del espectador, ya sea en Realidad Aumentada, en Realidad Virtual o en otras virtualizaciones que utilicen modelos en 3D como son las simulaciones, los videojuegos o las pel´ıculas de animaci´on [73]. A alto nivel, una c´amara virtual, adem´as de la posici´on del espectador, definir´ıa tambi´en lo que este va a poder observar de manera que, cuando se va a renderizar una imagen, solo tiene que generarse la parte visible de los modelos que entren en el rango de visi´on de la c´amara virtual. 54 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Visualizando esto ´ultimo con un ejemplo, en la figura 5.8 se ha renderizado un modelo 3D de una tortuga marina. En este renderizado, la c´amara virtual se encuentra frente al modelo, pero ligeramente ladeado hacia la parte derecha de la tortuga. Debido a la posici´on de la c´amara, no es necesario que se renderice la pata izquierda trasera de la figura, puesto que lo tapa el resto del cuerpo. Sin embargo, si la c´amara se encontrase detr´as de la tortuga, ser´ıa necesario renderizar ambas patas traseras y la cola, pero no se renderizar´ıa la cara de la figura. De la misma manera, si la c´amara no estuviese apuntando hacia la tortuga, no habr´ıa ning´un modelo 3D que renderizar. Aunque este parezca un concepto obvio, es necesario explicarlo, debido a que ser´a necesario establecer la posici´on y orientaci´on de la c´amara virtual durante el desarrollo. Esto es porque la c´amara virtual coincidir´a con la posici´on de la c´amara del dispositivo m´ovil. Cuando la c´amara apunte hacia una figura en 3D en la Realidad Aumentada, se incrustar´a en la pantalla del m´ovil la parte de la figura que se vea desde la c´amara virtual (es decir, se debe ver por la pantalla lo que se ver´ıa a trav´es de la c´amara si esta figura existiese en nuestra Realidad). Una vez explicado esto, es necesario volver al c´odigo. Siguiendo el orden de carga, el primer lugar donde nos detendremos es en la funci´on callback checkSessionSupported, vista en la secci´on 5.1, que es la funci´on que se lanza desde el constructor del Controlador y que inicializaba los elementos m´as pesados antes de que el usuario pulsase el bot´on de iniciar la Sesi´on de Realidad Aumentada. En esta, ya hab´ıamos visto las acciones que se realizaban en caso de que el navegador no fuese compatible con WebXR, pero ahora vamos a ver algunas de las que se ejecutan en el caso positivo. Ampliando el c´odigo 5.2 al que hacemos menci´on: 1// Constantes 2#RETICLELINK = "http://url_donde_se_aloja_el_modelo_3d"; 3 4# checkSessionSupported = ( isSupported ) => { 5if ( isSupported ) { 6 7// Scene y Loader 8this.# scene = new THREE . Scene () ; 9this.#loader = new THREE . GLTFLoader () ; 10 // ... 11 12 // Modelo en 3D: Reticula 13 this.# loader . load (this.#RETICLELINK , function (gltf ) { 14 // Figura 15 this.# reticle = gltf . scene ; 16 this.#reticle.visible = false ; 17 this.# scene . add ( this.# reticle ); 18 }. bind (this)); 19 // ... 20 21 }else { 22 55 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Figura 5.10: Muestra de la ret´ıcula utilizada en esta aplicaci´on. Modelo obtenido del repositorio webxr del perfil de Immersive Web at W3C, en GitHub 23 document.getElementById(" arButton "). disabled = true; 24 alert ("Tu navegador no permite una sesi\ xF3n de Realidad Aumentada ."); 25 26 } 27 }; C´odigo 5.9: Carga de elementos de Three.js si se soporta la sesi´on Aqu´ı ya podemos ver tres elementos de cierto peso que se est´an cargando previamente antes de iniciar la Sesi´on: la Escena, una instancia de GLTFLoader y, desde una funci´on de esta ´ultima, un modelo 3D al que llamaremos a partir de ahora, ((ret´ıcula)), sencillamente porque es el nombre del modelo original alojado en la librer´ıa de modelos de ejemplo de WebXR en GitHub. Este modelo en 3D, que podemos ver en la figura 5.10 ser´a el que utilicemos como base para el funcionamiento de esta aplicaci´on, haciendo las veces de ((puntero)) m´as adelante, cuando queramos se˜nalar un punto en el suelo para ubicar el avatar que desarrollemos. En primer lugar, inicializamos la Escena en la l´ınea 8 para poder introducir la ret´ıcula m´as adelante (volviendo al s´ımil anteriormente utilizado, es como si el actor ((ret´ıcula)) entrara en escena). Sin embargo, esto no lo podemos hacer hasta que se haya cargado el modelo. Para esto, utilizamos el objeto GLTFLoader de Three.js [27], que es inicializado en la l´ınea 9 para poder ser usado a continuaci´on. Este objeto contiene la funci´on load(), que permite cargar un modelo 3D (en este caso, en formato glTF oGLB, dado que este objeto es una especializaci´on del objeto Loader y solo permite cargar archivos de dichos formatos) y lanzar una funci´on callback una vez obtiene un resultado. Mediante la funci´on de GLTFLoader,Three.js hace la traducci´on del contenido del fichero a objetos de Three.js que sean manejables desde c´odigo. Aunque la documentaci´on no sea muy extensa sobre el objeto que ofrece esta funci´on, s´ı se puede encontrar que, mediante la funci´on callback que creemos para esto, recibiremos un objeto (que en la l´ınea 13 hemos llamado gltf ) que contiene los siguientes atributos [38]: animations: devuelve un array con las animaciones (THREE.AnimationClip) que contenga el 56 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA archivo con el modelo 3D. Estas animaciones, aunque ya entraremos m´as en detalle m´as adelante, no son m´as que conjuntos de posturas que, agrupados de la manera correcta, dan la sensaci´on de movimiento si se van recorriendo a una velocidad adecuada. scene: aunque el sistema llame al atributo tambi´en ((Escena)), en verdad el objeto contenido es de tipo THREE.Group. Este objeto se puede definir como un conjunto de mallas de tri´angulos, que son los que formar´an las superficies de los objetos tridimensionales. Al recoger todas las mallas del archivo de manera unida como un solo grupo, estaremos recogiendo en verdad el modelo 3D al completo. cameras: en caso de que el archivo contenga una c´amara virtual preestablecida, podremos encontrarlo en este atributo, que nos devolver´a un array de objetos THREE.camera. Estas c´amaras no nos servir´an para la Realidad Aumentada, porque nosotros queremos solamente una c´amara que se encuentre en todo momento en el punto de vista de la c´amara del dispositivo m´ovil. Este atributo es mucho m´as ´util cuando se pretende utilizar la librer´ıa para aplicaciones web de visualizaci´on de este tipo de figuras tridimensionales, como pueda ser Babylon.js Sandbox. Estos son los atributos m´as importantes, aunque tambi´en contiene otros que son de menor importancia para el desarrollo hasta ahora de este proyecto: asset: objeto de JavaScript sin tipo (Object) que contiene metadatos del archivo, com´unmente generados de forma autom´atica por la herramienta de dise˜no utilizada para la construcci´on del modelo. parser: objeto GLTFParser que contiene la informaci´on del objeto que se ha utilizado internamente para transformar el archivo. scenes (no confundir con scene): de manera similar a scene, contiene un array de objetos de tipo THREE.Group. Esto se debe a que los archivos glTF pueden contener varios grupos separados de mallas, aunque no ser´a el caso en este proyecto. userData: objeto sin tipado que contiene informaci´on customizada por parte del creador del archivo. Esta no est´a estandarizada, por lo que la informaci´on podr´ıa estar de cualquier manera. Como se puede comprobar, son muchos los elementos que se cargan de un solo archivo, aparte del propio modelo en 3D. Esto se debe a que, como se ver´a m´as adelante, al dise˜nar un modelo en 3D se pueden a˜nadir distintas propiedades preestablecidas. M´as adelante, en la secci´on 5.5, veremos como, desde el mismo archivo del modelo, podremos acceder tambi´en a las animaciones predefinidas que se encuentren contenidas en este. Sin embargo, durante este dise˜no tambi´en se pueden preestablecer otros elementos y guardarlos en el mismo archivo como iluminaciones y c´amaras virtuales. Una vez sabemos esto, y volviendo al c´odigo 5.9, podemos ver que, en la l´ınea 15, se est´a almacenando en el atributo privado reticle del Controlador el grupo de mallas que formar´an el modelo 3D de 57 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Figura 5.15: Hit Test devuelve la posici´on de la superficie que se encuentre en el centro de la pantalla 5.4. C´alculo de superficies, Hit Test Results La siguiente caracter´ıstica a desarrollar es la capacidad del usuario para ubicar el avatar en el lugar que desee, estando siempre encima de una superficie, de manera que d´e la sensaci´on de estar esta reposando sobre el plano que hayamos seleccionado. Para ello se utilizar´a las herramientas proporcionadas por WebXR en conjunto con Three.js para poder encontrar superficies y apuntar hacia estas. En este punto, ser´a de gran importancia la ret´ıcula, la figura que se ha estado usando como ejemplo de modelo 3D para la carga y la inserci´on en este sistema de Realidad Aumentada. Esta figura se utilizar´a como puntero para que el usuario sepa en todo momento hacia d´onde est´a apuntando, situ´andose esta en el punto de la superficie que se muestre exactamente en el centro de la pantalla. Para encontrar las coordenadas de dicho punto en la superficie, se utiliza Hit Test. Hit Test es una t´ecnica que consiste en encontrar intersecciones entre superficies de objetos 3D y un rayo imaginario que, en el caso de esta aplicaci´on, surgir´a desde el dispositivo m´ovil. En el caso de los sistemas que utilizan Realidad Virtual, el c´alculo se realiza teniendo en cuenta que se conocen previamente los objetos que generar´an las intersecciones, pero a la hora de utilizar Realidad Aumentada, este proceso resulta algo m´as complejo, al ser necesario encontrar la forma que tienen los objetos de nuestro alrededor para poder realizar los c´alculos. Afortunadamente, la interfaz WebXR cuenta con las herramientas adecuadas para hacer estos c´alculos internamente, de forma que los desarrolladores solo tengan que ocuparse de tratar la informaci´on que devuelvan los resultados del 64 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Hit Test. Es importante tener en cuenta que los resultados del Hit Test pueden depender de la calidad de los sensores y c´amaras del dispositivo. Adem´as, la experiencia puede variar en diferentes entornos y condiciones de iluminaci´on, por lo que las coordenadas obtenidas a trav´es de esta t´ecnica puede variar ampliamente dependiendo de cada casu´ıstica. Conociendo ya esto, vamos a su aplicaci´on en el sistema desarrollado. Para comenzar, es necesario indicar a la Sesi´on, cuando esta est´e siendo creada, que se va a utilizar las opciones de Hit Test y que se requerir´a cargar la configuraci´on necesaria para su utilizaci´on. Para ello, se utiliza el objeto SESSIONOPTIONS que contiene informaci´on sobre c´omo deber´a ser la Sesi´on creada. En este caso, como ya se mostr´o anteriormente en el c´odigo 5.5, la opci´on a indicar es requiredFeature, y dentro de esta indicaremos mediante String que queremos que la sesi´on use ’hit-test’. Despu´es de esto, dentro de la funci´on startLoop, tendremos que obtener un espacio de referencia que pueda utilizar el sistema para poder calcular las intersecciones. En este caso, se utilizar´a un espacio de referencia de tipo viewer [78], ya que es un espacio de referencia centrado en ubicar el suelo. Con esto, podemos solicitar a la sesi´on que nos ofrezca un Hit Test Source. El Hit Test Source nos permitir´a, cuando nos encontremos en el bucle, encontrar en nuestro espacio de referencia las coordenadas del punto de la superficie al que apuntamos con la c´amara, tal y como se hace en la imagen 5.15 [82]. En el c´odigo 5.16, en la l´ınea 18, justo despu´es de la solicitud del espacio de referencia que va a utilizar y junto al otro espacio de referencia utilizado por la aplilcaci´on, se muestra la solicitud de dicho objeto, que se realiza a trav´es de una llamada as´ıncrona, raz´on por la cual se utiliza el comando await. 1async startLoop () { 2 3// ... 4 5// Session 6this.# session = await navigator . xr . requestSession (" immersive -ar",this.# SESSIONOPTIONS); 7this.# session . updateRenderState ({ 8baseLayer : new XRWebGLLayer(this.# session , this.# gl ) 9}); 10 11 // Reference space 12 this.#referenceSpace = await this .# session . requestReferenceSpace (’local ’); 13 14 // Viewer space 15 this.# viewerSpace = await this .# session . requestReferenceSpace (’viewer’); 16 17 // Hit test source 18 this.# hitTestSource = await this .# session . requestHitTestSource ({ space : this .# viewerSpace }); 65 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA 19 20 // ... 21 22 this.# session . addEventListener ("select",this.#onTouchEvent); 23 24 // ... 25 26 } C´odigo 5.16: Solicitud de Hit Test Source a la Sesi´on y creaci´on de evento Antes de terminar con la funci´on startLoop, prepararemos un evento que servir´a para aplicar la funcionalidad de la aplicaci´on que funciona gracias a Hit Test. Como vemos en la l´ınea 22 del c´odigo 5.16, mediante la funci´on addEventListener de la Sesi´on, solicitaremos que se fije un evento de tipo ((select)), lo que significa que cada vez que se pulse la pantalla con la sesi´on iniciada, se lanzar´a la funci´on de tipo callback especificada en el segundo par´ametro llamada onTouchEvent. Concretamente, como respuesta a este evento, el sistema lanzar´a el siguiente c´odigo: 1# onTouchEvent = ( event ) => { 2if (this.# model ) { 3this.# scene . remove ( this.# model ) 4this.# model . position . copy ( this.# reticle . position ); 5this.# scene . add ( this.# model ); 6 7// ... 8} 9}; C´odigo 5.17: Respuesta al evento de tipo ((select)) En el c´odigo 5.17, lanzado cada vez que el usuario toca la pantalla, eliminaremos del Escenario la ret´ıcula mediante la l´ınea 3. A efectos pr´acticos, esto significa que la ret´ıcula desaparecer´a por completo de nuestra Realidad Aumentada, siendo imposible volver a encontrarla. Sin embargo, esto solo ocurrir´a si se cumple la condici´on de la l´ınea 2, que comprueba si se ha cargado la variable model. Esta variable contiene otra figura 3D, que en este caso es el modelo de nuestro asistente virtual. Esta se comenzar´a a cargar a la vez que la ret´ıcula, pero debido a que este modelo 3D pesa mucho m´as y su carga se realiza de manera as´ıncrona, es necesario comprobar que se ha terminado de cargar antes de utilizarlo. Por esta raz´on, se lanza la comprobaci´on de la l´ınea 2: debido a que JavaScript interpreta las variables vac´ıas como false y cualquier contenido (no booleano) como true [14], al leer esa condici´on, el sistema solo pasar´a por el condicional si la variable ha sido cargada. Esta carga as´ıncrona se realiza en la funci´on checkSessionSupported() y se explicar´a con m´as detalle en la secci´on 5.4. Una vez se eval´ua afirmativamente la condici´on de la l´ınea 2, como ya se ha dicho, se quitar´a la ret´ıcula del Escenario. Pero para continuar con la funcionalidad de la aplicaci´on, se procede tambi´en con las otras dos l´ıneas: nuestra aplicaci´on debe mostrar el modelo cargado en la variable model 66 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA en el mismo punto exacto en el que se encontraba la ret´ıcula en el momento en que el usuario puls´o sobre la pantalla, por lo que el asistente virtual deber´a tener exactamente la misma que la ret´ıcula con respecto a la posici´on. Para eso, se usa la funci´on de la l´ınea 4, que se encarga de copiar completamente dicha informaci´on. Por ´ultimo, como queremos que aparezca el asistente virtual en nuestra pantalla, utilizaremos la funci´on de la l´ınea 5 para que esta sea a˜nadida a la Escena y, por tanto, el sistema se encargue de renderizarlo en pantalla. Esta es la manera en que intercambiaremos un modelo por otro. Una vez obtenido todo lo necesario para iniciar nuestro Hit Test Source, comenzaremos con la implementaci´on en el bucle de la funci´on loopFunction. En el c´odigo 5.13, se sustituy´o contenido del script original por las l´ıneas 24 y 25 para poder explicar mejor su funcionamiento, pero ahora que se ha explicado lo necesario para llegar a esto, mostraremos en el c´odigo 5.18 el contenido que originalmente va en esas l´ıneas: 1// ... 2// Calculo de superficies 3const hitTestResults = frame . getHitTestResults (this.# hitTestSource ); 4if ( hitTestResults . length > 0 && this.# reticle ) { 5 6const hitPose = hitTestResults [0]. getPose ( this.#referenceSpace); 7 8// muestra la reticula solo si esta cargado el modelo y no esta hablando 9if (this.# model && ! this.# clipAction . isRunning ()) 10 this.#reticle.visible = true; 11 else 12 this.#reticle.visible = false ; 13 14 this.# reticle . position . set ( hitPose . transform . position .x , hitPose . transform . position .y, hitPose . transform . position .z) 15 this.# reticle . updateMatrixWorld ( true); 16 17 } 18 // ... C´odigo 5.18: Obtenci´on de valores captados a trav´es del Hit Test Source En primer lugar, en la l´ınea 3, se solicita al objeto frame que devuelva el resultado de los c´alculos usando el Hit Test Source mediante la funci´on getHitTestResults. Los resultados ser´an unas coordenadas que indicar´an la posici´on aproximada del punto de la superficie a la que se est´e apuntando con la c´amara del dispositivo. Una vez realizada esta funci´on, se comprueba si ha devuelto alg´un valor mediante la condici´on de la l´ınea 4. Esto se hace porque es posible que comience el bucle pero el sistema todav´ıa no haya captado correctamente el sistema de referencia y, por tanto, todav´ıa no pueda obtener resultados de superficies. Adem´as, al igual que se hizo en el c´odigo 5.17, tambi´en se comprueba que se haya terminado de cargar la ret´ıcula para poder mostrarla en pantalla. Si ambas condiciones se dan, se pasa a dar a la ret´ıcula sus coordenadas: en la l´ınea 6 se obtiene, del objeto 67 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA ((resultados)), las coordenadas que queremos asignar a cualquier modelo tridimensional a trav´es de la funci´on getPose. En las l´ıneas 9 y 11 se establecen las condiciones que indicar´an si la ret´ıcula es o no visible durante la sesi´on del usuario y, finalmente, a trav´es de la funci´on de la l´ınea 14, se establece la posici´on de la ret´ıcula cogiendo las coordenadas recibidas anteriormente del objeto ((resultados)). Esta acci´on se realizar´a en cada iteraci´on para asegurar que la ret´ıcula aparece siempre en la posici´on hacia la que est´a apuntando el usuario. Con todo esto, el usuario ya podr´ıa ubicar objetos en superficies del mundo real a trav´es de la Realidad Aumentada. El siguiente punto ser´a animar dichos objetos. 5.5. Animaci´on de modelos La creaci´on de animaciones de cada modelo, en el caso de este TFG, se hace durante el propio dise˜no del modelo, punto que ser´a tratado en el cap´ıtulo 4. Sin embargo, es importante conocer esto, ya que algunos formatos de modelos en 3D como GLB oglTF permiten almacenar dichas animaciones de manera que, al cargar los modelos, se puede utilizar tambi´en estas animaciones. En nuestra situaci´on, son los modelos humanos los que contienen animaciones, debido a que la ret´ıcula no necesita ninguna. Para comenzar con la animaci´on de modelos, es necesario volver otra vez a la carga de los modelos, en la funci´on checkSessionSupported. En este caso, trataremos concretamente la animaci´on de los modelos humanos que, como se ve en el c´odigo 5.19, es algo distinto a la carga de la ret´ıcula. 1#MODELLINKARRAY = [" resources / model / stormy - male . glb "," resources / model / stormie - female . glb "]; 2# ANIMATIONLOOP = false ; 3// ... 4 5# checkSessionSupported = ( isSupported ) => { 6if ( isSupported ) { 7// Model 8this.# modelSelected = Math . floor ( Math . random () * this.#MODELLINKARRAY. length); 9this.# modelLink = this.# MODELLINKARRAY [ parseInt ( this.# modelSelected ) ]; 10 11 // Scene y Loader 12 this.# scene = new THREE . Scene () ; 13 this.#loader = new THREE . GLTFLoader () ; 14 this.# clock = new THREE . Clock ( this.#CLOCKAUTOSTART); 15 16 // ... 17 18 // Modelo 19 this.# loader . load (this.#modelLink , function ( gltf) { 20 // Figura 21 this.# model = gltf . scene ; 68 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA 22 this.# model . name = this.# MODELNAME ; 23 this.# model . scale . set( this.# MODELSCALE .x, this.# MODELSCALE .y , this.# MODELSCALE .z); 24 25 // Animacion 26 this.# mixer = new THREE.AnimationMixer(this.# model ); 27 28 let jsonAnimations = gltf . animations ; 29 this.# clipAction = this.# mixer . clipAction ( jsonAnimations [ this.# MODELANIMATIONNUMBER]); 30 if (! this.# ANIMATIONLOOP ) { 31 this.# clipAction . setLoop ( THREE . LoopOnce ); // playing the clip once 32 this.# clipAction . clampWhenFinished = true; 33 this.# clipAction . enable = true; 34 } 35 }. bind (this)); 36 } 37 // ... 38 }; C´odigo 5.19: Carga de modelo humano Una peculiaridad de la carga de los modelos humanos es que, de los dos modelos que tenemos, se cargar´a uno de ellos de manera aleatoria, sin aplicar ning´un tipo de decisi´on m´as all´a del uso de un n´umero calculado aleatoriamente. Esto se realiza de la siguiente manera: en la l´ınea 1, se almacena la constante con las ubicaciones de los dos modelos en un array de cadenas de texto. M´as tarde, justo antes de realizar las cargas, se decide qu´e modelo se va a utilizar, usando para ello en la l´ınea 7 la librer´ıa Math para calcular un n´umero entero de manera aleatoria y que permita seleccionar, en la l´ınea 8, la posici´on del array (en este caso, la posici´on ser´a 0 o 1). Una vez calculado qu´e modelo se va a utilizar, se pasa a la funci´on load ya comentada en la secci´on 5.3 donde, a trav´es de una funci´on callback, se obtiene un objeto con el que se podr´a manipular el modelo 3D. Ya obtenido este, se comienza a configurar: se almacena la Escena devuelta, se le asigna un nombre reconocible a su atributo name y se le da el tama˜no deseado en el atributo scale. Una vez tenemos el objeto del modelo, comenzamos con el trabajo de tratamiento de la animaci´on. Para ello, utilizamos un objeto de la librer´ıa Three.js,AnimationMixer [9], que contiene utilidades b´asicas de control de la animaci´on, como la velocidad de reproducci´on de esta misma o, la m´as importante, la capacidad de buscar el momento exacto de la animaci´on que debe mostrarse en relaci´on al tiempo. De este objeto obtendremos tambi´en el objeto AnimationAction [8] almacenado en la variable clipAction en la l´ınea 29, que permite un control de la animaci´on m´as parecido a los controles globales de reproducci´on de v´ıdeo: pausar, reanudar, establecer un bucle, establecer la duraci´on de la animaci´on, etc. Para poder utilizar este ´ultimo, tendremos que pasarle la animaci´on que se va a usar. Una vez obtenido, podremos configurarlo como se hace a partir de la l´ınea 31, donde en este 69 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA caso se establece que la animaci´on no se ejecute continuamente en bucle, se indica que la animaci´on se desactive al terminar y, finalmente, se activa dicha animaci´on. Por ´ultimo, antes de lanzar la funci´on load de la l´ınea 19, se prepara un objeto llamado Clock [17]. Este objeto sirve para contar los segundos que lleva la animaci´on reproduci´endose y, en el momento de renderizar la figura, AnimationMixer la actualice para que se encuentre en la posici´on en la que debe estar en el tiempo indicado por el reloj. Este objeto es necesario debido a que, tal y como se coment´o anteriormente en la secci´on 5.2, cada fotograma se lanza ´unicamente cuando el sistema est´a preparado para lanzarlo en lugar de lanzarse todos los fotogramas posibles uno tras otro. Por lo tanto, debe haber un control que tenga en cuenta los segundos de ejecuci´on que se llevan durante cada iteraci´on y que, con esto, sepa qu´e instante exacto de la animaci´on debe renderizarse. Una vez est´an estos objetos preparados, se puede comenzar a utilizar en el propio trabajo de renderizado. El primer lugar en el que se utiliza es en onTouchEvent: 1# onTouchEvent = ( event ) => { 2if (this.# model ) { 3this.# scene . remove ( this.# model ); 4this.# model . position . copy ( this.# reticle . position ); 5this.# scene . add ( this.# model ); 6// ... 7if (! this.# clipAction . isRunning ()) { 8this.# clipAction . setDuration ( this.# audioElement . duration ); 9this.# clipAction . reset (); 10 this.# clipAction . play () ; 11 } 12 } 13 }; C´odigo 5.20: Evento onTouchEvent junto con las acciones relacionadas con la animaci´on Aqu´ı, cuando el usuario pulsa sobre la pantalla, despu´es de ejecutarse las acciones comentadas anteriormente en el c´odigo 5.17, se comprueba primero que el modelo est´e ejecutando su animaci´on (l´ınea 10) y, de no ser as´ı, comienza con esta (l´ınea 13). Antes de reproducirse, se realizan dos acciones: la primera, en la l´ınea 11, establece la duraci´on de la animaci´on en relaci´on con el audio que sonar´a a su vez. Esto se hace para, por un lado, fijar la velocidad a la que se ejecutar´a la animaci´on (y asegurarse de que siempre va a ser la misma) y, por otro lado, para que cuadre con el mismo audio, ya que la animaci´on se ha dise˜nado en relaci´on a esta, como se comentar´a m´as adelante. La segunda acci´on, en la l´ınea 12, se asegura de que, en caso de que la animaci´on se haya detenido porque ya se hab´ıa ejecutado y terminado por completo, la pr´oxima vez que se inicie la animaci´on se ejecute desde el punto de inicio en lugar de iniciarse desde el final o desde alg´un punto intermedio. De esta manera, el evento se ocupar´ıa de iniciar la animaci´on tanto si el usuario acaba de entrar en la Realidad Aumentada como si ha terminado la animaci´on y quiere volver a reproducirla. 70 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA Por ´ultimo, durante el bucle de renderizado, para actualizar la posici´on de la animaci´on a la conveniente en el momento de ser renderizado, ser´ıa tan sencillo como ejecutar el siguiente fragmento de c´odigo al inicio del m´etodo: 1# loopFunction = (time , frame) => { 2 3let delta = this.#ANIMATIONSPEED * this.# clock . getDelta (); 4if (this.# mixer ) 5this.# mixer . update ( delta ); 6 7// ... 8}; C´odigo 5.21: Actualizaci´on de la posici´on del modelo 3D antes de renderizar La funci´on de la l´ınea 5 se asegura, sin necesidad de ejecutar m´as acciones, de actualizar la posici´on del modelo. Para poder ser ejecutado, se extrae en la l´ınea 3 el valor delta del objeto Clock, que es el tiempo en segundos que ha pasado desde que se inici´o el reloj. Adem´as, en la l´ınea 4 se comprueba que este c´odigo se ejecute ´unicamente si de manera previa se ha generado el objeto mixer durante las acciones as´ıncronas en la preparaci´on del bucle, como se vio en el fragmento de c´odigo 5.19. Con todo esto, ya dispondr´ıamos de una aplicaci´on de Realidad Aumentada que, a partir de las acciones del usuario, ser´a capaz de posicionar modelos 3D con movimiento en superficies reales. Por ´ultimo, quedar´ıa a˜nadir la ´ultima capa de verosimilitud mediante el sonido espacial. 5.6. Sonido espacial Para aplicar el sonido espacial al sistema, como se mencion´o en la secci´on 1.4, se ha utilizado la librer´ıa Resonance Audio [59]. Esta librer´ıa est´a especializada en la simulaci´on de sonidos espaciales, de manera que un usuario con auriculares podr´ıa reconocer de d´onde provienen las voces que escuchar´a a trav´es de la aplicaci´on. Otra funcionalidad que, adem´as, se percibe sin necesidad de auriculares, es la ((p´erdida de volumen)) en relaci´on con la distancia al origen del sonido, con lo que seremos capaces de escuchar mejor a nuestro modelo si este est´a ubicado en nuestros alrededores, mientras que si se ubica a una gran distancia no seremos capaces apenas de escucharlo. El uso de Resonance Audio es bastante similar al uso de la librer´ıa Three.js en cuanto al uso de modelos y animaciones, debido a que ambos requieren ubicar un elemento en el espacio y, adem´as, reproducirlo. En el caso del audio, el proceso de carga de archivos es mucho m´as sencillo. 1async startLoop () { 2 3// ... 71 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA 4 5this.#audioContext = new AudioContext(); 6 7this.#resonanceAudioScene = new ResonanceAudio(this.#audioContext); 8this.# resonanceAudioScene . output . connect ( this.# audioContext . destination ); 9this.# resonanceAudioScene . setRoomProperties (this.#ROOMDIMENSIONS , this.# ROOMMATERIALS ); 10 11 this.# audioElement = document . createElement (’audio ’); 12 this.#audioElement.src = this.# audioLink ; 13 this.# audioElement .loop = this.# AUDIOLOOP ; 14 15 this.# audioElementSource = this.# audioContext . createMediaElementSource ( this.# audioElement); 16 17 this.# audioSource = this.# resonanceAudioScene . createSource () ; 18 this.# audioElementSource . connect ( this.# audioSource . input ); 19 this.# audioSource . setPosition (0.0 , 0.0 , 0.0) ; 20 21 // ... 22 23 this.# session . requestAnimationFrame ( this.#loopFunction); 24 } C´odigo 5.22: Preparaci´on del sonido espacial El proceso de carga y configuraci´on del audio comienza en la funci´on startLoop, donde se van preparando los objetos de la librer´ıa y especificando las opciones que se van a utilizar. Para empezar, se requiere del objeto AudioContext [10], que forma parte de la funcionalidad b´asica de JavaScript y permite cargar y reproducir elementos de audio. Este ser´a inicializado en la l´ınea 5 del c´odigo 5.22 para despu´es poder inicializar en la l´ınea 7 el propio objeto ResonanceAudio [61] incluyendo al primero como argumento del constructor. Mediante el uso de este ´ultimo, la aplicaci´on ser´a capaz de generar el efecto de distancia y movimiento del sonido espacial. Para asignarle una salida de audio, utilizaremos la funci´on de la l´ınea 8. En la l´ınea 9, se establecen las propiedades de la habitaci´on: largo, ancho, altura del techo y materiales de cada una de las superficies [60] (suponiendo que la habitaci´on est´a formada por cuatro paredes paralelas, suelo y techo y omitiendo formas que no sean hexa´edricas). En este caso, dado que no queremos simular el efecto de eco, se establece como dimensiones 0x0x0, que es la forma de decirle al sistema que la habitaci´on no tiene una forma definida; y como materiales de paredes y techo se asigna el valor ((transparent)), lo que significa que no hay un material solido en dichas estructuras, mientras que para el suelo se establece ((marble)). A continuaci´on, en la l´ınea 11, se crea un HTMLAudioElement [29] a trav´es de la funci´on createElement del propio documento. Este elemento es una interfaz que permite insertar un audio en un 72 CAP´ ITULO 5. IMPLEMENTACIONES SOBRE EL SISTEMA DE REALIDAD AUMENTADA documento HTML y que, a su vez, ofrece funciones de manipulaci´on del mismo. Sobre este, estableceremos dos propiedades: la primera, src (l´ınea 12), servir´a para ubicar el origen del archivo de audio que se reproducir´a en la aplicaci´on; la segunda, loop (l´ınea 13), indicar´a a la aplicaci´on si, al terminar el audio, debe volver a reproducirse desde el principio autom´aticamente. Finalmente, mediante el c´odigo de las l´ıneas 15 y 17, terminamos de ((conectar)) el HTMLAudio- Element con el objeto de Resonance Audio para que el primero sea el origen del sonido del segundo, y mediante la funci´on de la l´ınea 19, establecemos una posici´on provisional para el origen del sonido. De esta manera, tenemos preparada la configuraci´on del sonido espacial, con lo que se puede comenzar a desarrollar la funcionalidad aplicada a esta aplicaci´on. En primer lugar, se definir´a lo que ocurre en los casos en los que emisor y receptor del sonido se muevan. Esto se puede ver en el c´odigo 5.23, donde la funcionalidad se divide en dos partes: en la primera, representada por las filas 12, 13 y 14, se calcula la posici´on del usuario (que se extrae de view.transform.matrix) y se inserta en el objeto THREE.Matrix4 [41], objeto que almacena una matriz de 4x4 y que representa la posici´on, orientaci´on y rotaci´on de una figura. Esta posici´on del usuario nos servir´a para establecer la posici´on del receptor utilizando la funci´on setListenerFromMatrix, de manera que Resonance Audio sepa desde d´onde se est´a escuchando el audio reproducido. En la segunda parte, representada por la fila 17, se establece el origen del sonido utilizando la posici´on del modelo. A pesar de que en el bucle se est´en estableciendo coordenadas, hay que tener en cuenta que todo esto no afecta en la reproducci´on o pausa de los sonidos cargados. Por lo tanto, durante varias iteraciones de este, Resonance Audio tendr´a definidas estas coordenadas a modo de ((preparaci´on)) para cuando comience la reproducci´on. 1# loopFunction = (time , frame) => { 2 3// ... 4 5const pose = frame . getViewerPose ( this.#referenceSpace); 6if ( pose) { 7const view = pose . views [0]; 8 9// ... 10 11 let userPosition = new THREE . Matrix4 (); 12 userPosition . elements = view . transform . matrix ; 13 this.# resonanceAudioScene . setListenerFromMatrix ( userPosition ); 14 15 // ... 16 17 this.# audioSource . setFromMatrix (this.# model . matrix ); 18 this.# renderer . render ( this.# scene , this.#camera) 73 CAP´ ITULO 6. PUESTA EN MARCHA Y PRUEBAS DESARROLLADAS Durante el proyecto se prepar´o un documento de pruebas utilizado para detallar cada aspecto a probar, d´andose el producto final en el caso de que todos estos puntos fueran correctos. Estos puntos cubren, de manera general, todos los requisitos descritos inicialmente en el cap´ıtulo 3.1. C´odigo Nombre Paso Descripci´on del paso Resultados esperados FP0010 Arranque de la animaci´on desde Android S010 Acceder a https://silverstorm.com desde un m´ovil con SO Android Se abre la p´agina web de Silver-Storm S020 Seleccionar idioma espa˜nol Se cambia el idioma a espa˜nol y aparece un c´odigo QR S030 Pulsar sobre la imagen QR Se abre una p´agina nueva con un bot´on Start S040 Pulsar sobre el bot´on Start Se arranca la c´amara del m´ovil con un puntero para posicionar el avatar FP0020 Arranque de la animaci´on desde un m´ovil no Android S010 Acceder a https://silverstorm.com desde un m´ovil con SO no Android Se abre la p´agina web de Silver-Storm S020 Seleccionar idioma espa˜nol Se cambia el idioma a espa˜nol y aparece un c´odigo QR S030 Pulsar sobre la imagen QR Se abre una p´agina nueva con un mensaje ”Tu navegador no permite una sesi´on de Realidad Aumentada” FP0025 Arranque de la animaci´on mediante QR S010 Acceder a https://silverstorm.com desde un ordenador Se abre la p´agina web de Silver-Storm S020 Seleccionar idioma espa˜nol Se cambia el idioma a espa˜nol y aparece un c´odigo QR Contin´ua en la siguiente p´agina Tabla 6.1: Plan de pruebas desarrollado 80 CAP´ ITULO 6. PUESTA EN MARCHA Y PRUEBAS DESARROLLADAS S030 Desde un m´ovil escanear el c´odigo QR Si el m´ovil tiene SO Android se abre una p´agina nueva con un bot´on Start y si no es Android con el mensaje ”Tu navegador no permite una sesi´on de Realidad Aumentada” FP0030 Carga de modelo 3D aleatorio S010 Dado el Test FP0010, pulsar en una zona lisa y aparentemente alejada 2 ´o 3 metros del usuario Se posicionar un avatar humano que aleatoriamente pude ser un hombre o una mujer punto seleccionado con las proporciones de una persona posicionada a dicha distancia FP0040 Posicionar y redimensionar el modelo S010 Dado el Test FP0030, volver a pulsar sobre una zona situada a unos 4 ´o 5 metros del usuario El avatar se posiciona en el punto seleccionado cambiando la proporci´on al nuevo punto FP0050 Animaci´on del esqueleto S010 Dado el Test FP0030 El avatar inicia una secuencia de movimientos del esqueleto que va en consonancia con los puntos que explica el audio FP0060 Animaci´on de la boca S010 Dado el Test FP050 El avatar inicia una secuencia de movimientos de la boca similar a la pronunciaci´on del audio FP0070 Audio acompasado por los movimientos S010 Dado el Test FP030 Se inicia la locuci´on grabada que va acompasada con los movimientos del cuerpo y de los labios Tabla 6.1: Plan de pruebas desarrollado Todas las pruebas comentadas en esta tabla resultaron exitosas, hecho por el cual se pudo obtener el producto final, en relaci´on a lo comentado anteriormente en esta misma secci´on. Adem´as, al cubrir estas pruebas los requisitos funcionales descritos en la secci´on 3.1 y, a su vez, los casos de uso definidos en la secci´on 3.2, se confirma que la aplicaci´on cumple con los puntos expuestos durante el an´alisis del proyecto. 81 CAP´ ITULO 6. PUESTA EN MARCHA Y PRUEBAS DESARROLLADAS 6.3. Problemas y errores A lo largo del desarrollo de la aplicaci´on, han ido surgiendo m´ultiples errores, algunos m´as f´aciles y otro m´as dif´ıciles de depurar. La depuraci´on de estos errores result´o generalmente complicada debido a que la aplicaci´on debe ser abierta siempre a trav´es de m´ovil, lo que obliga a configurar el m´ovil y conectarlo a trav´es de cable a un ordenador para poder utilizar la consola del navegador. Adem´as, los errores de programaci´on que se encontrasen dentro del bucle principal ser´ıan especialmente problem´aticos, porque no existe forma perfecta de ver la informaci´on necesaria de manera sencilla. Sin embargo, la mayor´ıa de los problemas que m´as bloquearon el desarrollo de la aplicaci´on no estaban relacionados con bugs surgidos durante el proceso y se acercaban bastante a los riesgos analizados en la secci´on 2.1.3. Despu´es de un an´alisis de los problemas, estos son los considerados como m´as graves: La documentaci´on de la librer´ıa Three.js resulta, en la gran mayor´ıa de casos, insuficiente o deficientemente explicada, tal y como se previ´o en el riesgo RSK6. Esto ha afectado m´ultiples veces al avance del desarrollo, debido a que hay objetos que pertenecen a la librer´ıa pero que no se explica qu´e representan o c´omo funcionan. Un caso muy particular es la funci´on de carga de modelos glTF, que solo viene explicada a trav´es de un ejemplo, pero no hay ning´un detalle sobre los objetos que devuelve dicha funci´on. La falta de detalles en esta documentaci´on ha obligado a descubrir muchos aspectos de esta librer´ıa a base de ensayo y error o a trav´es de foros no oficiales y de dudosa calidad en Internet. De manera similar, y tambi´en relacionado con el riesgo RSK6, la documentaci´on de Resonance Audio tambi´en ha resultado ser muy escasa, constando solo de una p´agina con el objeto principal y una lista de atributos y funciones de esta con una descripci´on muy b´asica y sin detallar, obligando pr´acticamente a basarse en los ejemplos que a˜nade la p´agina para poder obtener informaci´on m´ınima ´util. Un problema relacionado con el c´odigo y que requiri´o de amplia y constante depuraci´on fue la compatibilidad entre Three.js yResonance Audio a trav´es de los objetos de representaci´on de posiciones en tres dimensiones. Cada librer´ıa utiliza su propio objeto de posici´on y requiere de sus propias conversiones, lo que oblig´o a buscar la forma de compatibilizarlo, pero la dificultad para depurar objetos que se encuentran en el bucle de procesado de im´agenes y la escasez de documentaci´on al respecto hizo que los pasos para hacer compatible la informaci´on de ambas librer´ıas fuera extremadamente lenta. Dado que este problema hubiera sido m´as liviano de haber tenido m´as experiencia, este puede relacionarse con el riesgo RSK5. De nuevo relacionado con el riesgo RSK6, y a pesar de que WebXR s´ı cuenta con documentaci´on fiable y muy extensa a trav´es de la web de desarrolladores de Mozilla, la explicaci´on para lanzar un sistema b´asico por parte de la web oficial de Google resulta muy escasa en muchos aspectos, omitiendo informaci´on que puede ser crucial en desarrollos m´as complejos. Un ejemplo de esto 82 CAP´ ITULO 6. PUESTA EN MARCHA Y PRUEBAS DESARROLLADAS es la totalmente inexistente explicaci´on de cu´ando se solicita la imagen a la c´amara y c´omo se env´ıa al canvas generado. Adem´as, Google dispone de varios tutoriales distintos para lanzar un sistema b´asico a trav´es de WebXR donde se ve informaci´on distinta y, a veces, contradictoria, lo que tampoco ayud´o a lanzar una primera versi´on de la aplicaci´on. En todos estos casos, la soluci´on final fue desarrollos a base de ensayo y error apoy´andose en blogs y webs de desarrolladores independientes de los que se pod´ıan extraer datos que podr´ıan ser importantes, tal y como se plante´o en el plan de contingencia del riesgo RSK6, a pesar de que el riesgo RSK5 planteaba incluir personal de apoyo. 83 CAP´ ITULO 6. PUESTA EN MARCHA Y PRUEBAS DESARROLLADAS 84 Cap´ıtulo 7 Conclusiones y trabajo futuro 7.1. Conclusiones A pesar de las diferentes dificultades encontradas y que llegaron a modificar el plan inicial del proyecto, tal y como se vio en la secci´on 2.3, el producto final fue concluido con ´exito dentro del tiempo esperado. Finalmente, mientras la web estuvo activa, pudo accederse a la aplicaci´on de Realidad Aumentada tal y como se pretend´ıa, cumpliendo todos los requisitos buscados para el proyecto. Adem´as, se ha obtenido experiencia acerca de los desarrollos relacionados con la Realidad Aumentada, de manera que para pr´oximos proyectos que requieran de habilidades similares se puede aprovechar este conocimiento adquirido, ya sea por utilizar la misma aplicaci´on o por buscar las equivalencias entre las diferentes aplicaciones que tienen las mismas finalidades. Cabe mencionar que la empresa guarda un documento t´ecnico del desarrollo de esta misma aplicaci´on explicada a bajo y alto nivel para casos de futura necesidad. Con todo esto, podr´ıa considerarse que se ha cumplido el objetivo general del proyecto definido en la secci´on 1.2. Concretamente, y analizando punto por punto cada objetivo espec´ıfico: Se investig´o acerca de las diferentes tecnolog´ıas relacionadas con la Realidad Aumentada que pudieran servirnos para una aplicaci´on web. Concretamente, como se ve en el diagrama de componentes de la figura 3.4, se utilizaron en conjunto WebXR yThree.js para la imagen y Resonance Audio para el sonido. Se gener´o una estructura, visible en los diagramas del cap´ıtulo 3, que asent´o las bases de la aplicaci´on y permitir´ıa ampliar m´as tarde el sistema con nuevas voces y animaciones. Como se ha comentado en el punto anterior, se utiliz´o sonido espacial para ampliar la sensaci´on de Realidad Aumentada mediante el uso de Resonance Audio. Mediante el uso de Rhubarb, se sincroniz´o la animaci´on de los labios de los modelos con los ficheros de audio utilizados para despu´es utilizarlos en la aplicaci´on. 85 CAP´ ITULO 7. CONCLUSIONES Y TRABAJO FUTURO A trav´es de Blender, se anim´o el resto del cuerpo de los modelos para eliminar la sensaci´on est´atica de estos al hablar. Todo el sistema se aloj´o en un servidor de Amazon Web Services, de manera que cualquier usuario pudiera acceder a este. Para acceder a esta aplicaci´on, se insert´o un c´odigo QR dentro de la web de SilverStorm. Actualmente, tal y como se coment´o en la secci´on 6.1, la web est´a de baja y no se encuentra accesible. 7.1.1. Limitaciones Es importante remarcar que este trabajo forma parte de una colaboraci´on con la empresa Thirdera, originalmente SilverStorm, y que algunos recursos fueron ofrecidos por esta misma para favorecer el curso del desarrollo y su correcta finalizaci´on, as´ı como asegurar el producto m´ınimo viable. Dicho esto, tambi´en hay que tener en cuenta que la empresa no est´a especializada en desarrollos de este tipo, y por lo tanto todos ´eramos nuevos usando las tecnolog´ıas aplicadas en el proyecto. Por eso, pese a haber gestionado riesgos y organizado el trabajo, inevitablemente surgieron problemas que no pudimos abordar por diferentes motivos. Los m´as importantes fueron los siguientes: Aunque se pens´o desde un primer momento en la compatibilidad entre distintos dispositivos m´oviles, lo cierto es que fue un punto que no se consigui´o. Originalmente se pens´o que el uso de WebXRPolyfill permitir´ıa utilizar la Realidad Aumentada en diferentes navegadores debido a que hacen menci´on a compatibilidad en navegadores en su documentaci´on [79] (a pesar de que no hacen mucho ´enfasis en ello). Pero, finalmente, result´o que esta actuaba como una ((extensi´on)) para aplicar retrocompatibilidad en caso de que el usuario utilizara un navegador Google Chrome para m´oviles con una versi´on antigua. La compatibilidad con otras plataformas fue finalmente descartada debido a que no encontramos una soluci´on alternativa. A la hora de generar las animaciones corporales de los modelos, se plante´o utilizar la herramienta web Kinetix: una aplicaci´on que capta los movimientos de una persona, los traduce a movimientos en el esqueleto de un modelo 3D y devuelve el modelo con la animaci´on completa [35]. Por desgracia, esta aplicaci´on no reconoce correctamente los esqueletos de modelos 3D que no hayan sido generados por la misma aplicaci´on, por lo que el resultado finalmente era totalmente incorrecto y no se pod´ıa considerar utilizable. Debido al consumo de tiempo que implicaba buscar otra herramienta y aprender a utilizarla, se cambi´o este paso por el desarrollo ((a mano)) de las animaciones corporales del modelo a trav´es de Blender. Cuando se generaron originalmente los modelos, se crearon directamente con la pose de reposo que tienen actualmente cuando no se est´an moviendo. Sin embargo, en numerosas webs de dise˜no de modelos 3D se recomienda encarecidamente generarlos en pose A o en pose T, es decir, con todas las extremidades estiradas y con los brazos estirados hacia las piernas (pose A) 86 CAP´ ITULO 7. CONCLUSIONES Y TRABAJO FUTURO o estirados en pose de cruz (pose T). Esto se hace para que los movimientos de los huesos sean mucho m´as precisos a la hora de mover cada miembro. Adem´as, en este caso, hubiera favorecido que las mallas de los modelos se deformaran menos, ya que MakeHuman, al generar un modelo con una pose concreta, tambi´en reestructura las mallas para acomodarlas a la postura elegida. El elegir una postura distinta a las poses A y T como postura de reposo ha generado algunas deformidades en brazos y dedos a la hora de moverlos y la imposibilidad de mover de manera normal los labios de los modelos. Una de las caracter´ısticas que contiene WebXR y que no aparec´ıa en ninguno de los tutoriales de primeros pasos de Google era las capas de renderState. Estas capas est´an preparadas para que cada una contenga una imagen, de manera que se superpongan las distintas capas y se genere el efecto de Realidad Aumentada. Esto favorecer´ıa un desarrollo m´as limpio y organizado del c´odigo, pero no se utiliz´o debido al desconocimiento del mismo. En su lugar, se utiliz´o una sola capa en la que se implantaban todas las im´agenes de manera ordenada. 7.2. Futuros pasos Durante el desarrollo y despu´es de finalizar el mismo, se encontraron muchos puntos que necesitan una correcci´on o que pueden evolucionar. Algunos de estos requieren de mejoras en las propias interfaces utilizadas, por lo que su mejora pasar´ıa por esperar a actualizaciones o sustituir completamente la interfaz, pero otras son puntos mejorables que se han ido encontrando durante el proyecto y posponiendo hasta despu´es de obtener un producto m´ınimo viable. Algunos de los puntos encontrados son los siguientes: En el c´odigo original, se utiliza la opci´on preserveDrawingBuffer como una de las opciones a a˜nadir al renderizador. Esto se utiliz´o debido a que viene as´ı explicado en varios tutoriales, pero en un issue del repositorio de GitHub de WebXR indican que esta opci´on es totalmente ignorada por la herramienta, por lo que no tiene ning´un sentido mantener esa opci´on en el objeto.[81]. Este hilo es el ´unico lugar donde se indica esta informaci´on, hecho por el cu´al cost´o tanto encontrar este dato. La detecci´on de superficies resulta muy imprecisa y depende, como se coment´o en la secci´on 6.2, de la iluminaci´on y del tipo de superficie. Seg´un parece, la detecci´on de superficies se puede configurar, por lo que es posible que se pueda mejorar manualmente, aunque esto requiere de mucha investigaci´on. Como se coment´o en la secci´on anterior, la aplicaci´on no es multiplataformas, sino que funciona solo en determinados navegadores espec´ıficos determinados por la propia librer´ıa WebXR. En futuros pasos, ser´ıa ideal ampliar esta compatibilidad, ya sea configurando el sistema actual de la manera adecuada o cambiando de librer´ıa de Realidad Aumentada. Los pasos para a˜nadir nuevos modelos, animaciones y voces se encuentran muy medidos y son reproducibles. Sin embargo, ser´ıa ideal simplificarlos a´un m´as para poder minimizar el esfuerzo 87 CAP´ ITULO 7. CONCLUSIONES Y TRABAJO FUTURO de generar nuevo contenido para la aplicaci´on. A pesar de que el c´odigo del sistema est´a repartido para repartir responsabilidades, hubiera sido posible diferenciarlo m´as de manera que los diferentes trabajos, especialmente en el bucle de procesado, estuviesen mucho m´as diferenciados y fuese m´as legible. Esto requerir´ıa de una refactorizaci´on intensa, pero que puede afectar positivamente en el mantenimiento de la propia aplicaci´on. Algunos sistemas basados en WebXR son capaces de detectar objetos que se encuentran entre el modelo y la c´amara. Al reconocer esto, dichos sistemas son capaces de ((ocultar)) el modelo detr´as del objeto, cosa que el sistema actual no es capaz de hacer. Ser´ıa ideal encontrar la manera de que los modelos se puedan ((esconder)) detr´as de objetos reales. La orientaci´on inicial del modelo, a d´ıa de hoy, depende del momento de carga del mismo: este mirar´a siempre hacia el punto en que se encontraba el usuario en el momento exacto de carga. El sistema ser´ıa mucho m´as vistoso si, cada vez que se pulsara sobre la pantalla, el modelo se girase hacia la c´amara del usuario. Como ´ultimo punto detectado, la accesibilidad de la aplicaci´on mejorar´ıa si esta mostrase al usuario las instrucciones para su uso en el momento correcto. Es decir: que la aplicaci´on mostrase mensajes como ((mueva la c´amara para detectar superficies)),((toque la pantalla para comenzar la animaci´on)) o((toque de nuevo la pantalla para reiniciar la aplicaci´on)) en los momentos indicados para que, en todo momento, el usuario sepa c´omo utilizar este sistema. 88 Ap´endice A: Manual de uso El caso de uso principal del usuario ser´a, generalmente, el siguiente: Figura 7.1: El usuario accede a la landing page. Nada m´as entrar en la aplicaci´on, como se explic´o anteriormente, el usuario podr´a ver la landing page, una p´agina est´atica sencilla donde aparecer´a un bot´on que servir´a para cargar los modelos necesarios y lanzar la sesi´on de Realidad Aumentada (figura 7.1). 89 BIBLIOGRAF´ IA [59] Resonance Audio.url:https://resonance-audio.github.io/resonance-audio/. [60] Resonance Audio Unity SDK API Reference: Utils. Resonance Audio.url:https://resonanceaudio.github.io/resonance-audio/reference/web/Utils. [61] Resonance Audio Unity SDK API Reference. ResonanceAudio.url:https://resonanceaudio.github.io/resonance-audio/reference/web/ResonanceAudio. [62] Rhubarb Lip Sync.url:https://github.com/DanielSWolf/rhubarb-lip-sync. [63] Scene. Three.js.url:https://threejs.org/docs/index.html?q=sce#api/en/scenes/ Scene. [64] Mike Shuttleworth. Risk Matrix Sizing: Does size really matter?. Project Risk Management. url:https://github.com/jgraph/drawio. [65] Sound localization. Wikipedia.url:https://en.wikipedia.org/wiki/Sound_localization# Human_auditory_system. [66] The Model-View-Presenter (MVP) Pattern. Microsoft Learn.url:https://learn.microsoft. com/en-us/previous-versions/msp-n-p/ff649571(v=pandp.10). [67] The Potential of Virtual Reality. A Principal’s Reflections.url:https : / / esheninger . blogspot.com/2016/12/the-potential-of-virtual-reality.html. [68] Three.js.url:https://threejs.org/. [69] Three.js. Wikipedia.url:https://es.wikipedia.org/wiki/Three.js. [70] Unity.url:https://unity.com/. [71] Unreal Engine.url:https://www.unrealengine.com/. [72] Unreal Forum. Epic Developer Community Forums.url:https://forums.unrealengine. com/categories?tag=unreal-engine. [73] Viewpoints and viewers: Simulating cameras in WebXR. Virtual cameras. MDN Web Docs. url:https : / / developer . mozilla . org / en - US / docs / Web / API / WebXR _ Device _ API / Cameras#virtual_cameras. [74] WebGLRenderer. Three.js.url:https://threejs.org/docs/#api/en/renderers/WebGLRenderer. [75] WebGLRenderingContext: bindFramebuffer() method. MDN Web Docs.url:https://developer. mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/bindFramebuffer. [76] WebGLRenderingContext. MDN Web Docs.url:https://developer.mozilla.org/en- US/docs/Web/API/WebGLRenderingContext. [77] WebXR.url:https://immersiveweb.dev/. [78] WebXR Device API - Spatial Tracking: Reference spaces. W3C.url:https://immersiveweb.github.io/webxr/spatial-tracking-explainer.html#reference-spaces. [79] WebXR Polyfill.url:https://github.com/immersive-web/webxr-polyfill?tab=readmeov-file#webxr-polyfill. 96 BIBLIOGRAF´ IA [80] WebXR requirements. MDN Web Docs.url:https://developers.google.com/ar/develop/ webxr/requirements. [81] WebXR: Clarify semantics of preserveDrawingBuffer. GitHub.url:https://github.com/ immersive-web/webxr/issues/891. [82] XRHitTestSource. MDN Web Docs.url:https://developer.mozilla.org/en-US/docs/ Web/API/XRHitTestSource. [83] XRSession: requestAnimationFrame() method. MDN Web Docs.url:https://developer. mozilla.org/en-US/docs/Web/API/XRSession/requestAnimationFrame. [84] XRSession: updateRenderState() method. MDN Web Docs.url:https://developer.mozilla. org/en-US/docs/Web/API/XRSession/updateRenderState. [85] XRSession. MDN Web Docs.url:https://developer.mozilla.org/en-US/docs/Web/API/ XRSession. [86] XRSystem: requestSession() method. MDN Web Docs.url:https://developer.mozilla. org/en-US/docs/Web/API/XRSystem/requestSession. [87] XRView. MDN Web Docs.url:https://developer.mozilla.org/en-US/docs/Web/API/ XRView. [88] XRViewerPose. MDN Web Docs.url:https://developer.mozilla.org/en-US/docs/Web/ API/XRViewerPose. [89] XRWebGLLayer. MDN Web Docs.url:https://developer.mozilla.org/en- US/docs/ Web/API/XRWebGLLayer. 97