Interacción natural mediante Leap Motion: edición de modelos en 3D

UNIVERSIDADE DE SANTIAGO DE COMPOSTELA ESCOLA T´ ECNICA SUPERIOR DE ENXE ˜ NAR´ IA Interacci´on natural mediante Leap Motion Edici´on de modelos en 3D Autor: Pablo Dobarro Pe˜na Tutor: Juli´an Flores Gonz´alez Grao en Enxe˜nar´ıa Inform´atica Febreiro 2018 Traballo de Fin de Grao presentado na Escola T´ecnica Superior de Enxe˜nar´ıa da Universidade de Santiago de Compostela para a obtenci´on do Grao en Enxe˜nar´ıa Inform´atica D. Juli´an Flores Gonz´alez, Profesor do Departamento de Electr´onica e Computaci´on da Universidade de Santiago de Compostela, INFORMA: Que a presente memoria, titulada Interacci´on natural mediante Leap Motion: Edici´on de modelos en 3D, presentada por D. Pablo Dobarro Pe˜na para superar os cr´editos correspondentes ao Traballo de Fin de Grao da titulaci´on de Grao en Enxe˜nar´ıa Inform´atica, realizouse baixo mi˜na direcci´on no Departamento de Electr´onica e Computaci´on da Universidade de Santiago de Compostela. E para que as´ı conste aos efectos oportunos, expiden o presente informe en Santiago de Compostela, a 6/2/2018: O director, O alumno, i ii ´ Indice general 1. Introduci´on 3 1.1. Objetivos ............................... 3 1.2. Estadodelarte ............................ 4 1.3. El sensor Leap Motion . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Aplicaciones.............................. 8 2. An´alisis 9 2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1. Requisitos de dise˜no . . . . . . . . . . . . . . . . . . . . . 18 2.2.2. Requisitos de interfaz . . . . . . . . . . . . . . . . . . . . . 19 2.2.3. Requisitos de rendimiento . . . . . . . . . . . . . . . . . . 20 2.2.4. Requisitos de proyecto . . . . . . . . . . . . . . . . . . . . 21 2.3. Gesti´on de la configuraci´on . . . . . . . . . . . . . . . . . . . . . . 22 2.3.1. Control de versiones . . . . . . . . . . . . . . . . . . . . . 22 2.4. Alcance ................................ 22 2.4.1. Definici´on del alcance del proyecto . . . . . . . . . . . . . 23 2.4.2. Criterios de aceptaci´on . . . . . . . . . . . . . . . . . . . . 23 2.4.3. Entregables .......................... 23 2.4.4. Exclusiones .......................... 23 2.4.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5. Costes ................................. 24 2.5.1. Hardware ........................... 24 2.5.2. Recursos humanos . . . . . . . . . . . . . . . . . . . . . . 24 2.6. Metodolog´ıa.............................. 25 2.7. Planificaci´on.............................. 26 2.8. Riesgos................................. 31 2.8.1. Riesgos de gesti´on del proyecto . . . . . . . . . . . . . . . 32 2.8.2. Riesgos de disponibilidad . . . . . . . . . . . . . . . . . . . 33 2.8.3. Riesgos de desarrollo . . . . . . . . . . . . . . . . . . . . . 33 2.8.4. Riesgos de recursos humanos . . . . . . . . . . . . . . . . . 34 2.9. An´alisis de tecnolog´ıas . . . . . . . . . . . . . . . . . . . . . . . . 36 2.9.1. Criterios de selecci´on . . . . . . . . . . . . . . . . . . . . . 36 iii 2.9.2. Implementaci´on propia . . . . . . . . . . . . . . . . . . . . 36 2.9.3. Unity2017........................... 37 2.9.4. Unreal Engine 4 . . . . . . . . . . . . . . . . . . . . . . . . 38 2.9.5. GodotEngine3........................ 39 2.9.6. Conclusi´on........................... 40 3. Dise˜no 43 3.1. Sprint 1: Dise˜no general . . . . . . . . . . . . . . . . . . . . . . . 44 3.1.1. An´alisis de otras aplicaciones . . . . . . . . . . . . . . . . 44 3.1.2. Paradigmas de interacci´on . . . . . . . . . . . . . . . . . . 47 3.1.3. Dise˜no de la implementaci´on . . . . . . . . . . . . . . . . . 48 3.1.4. Mockups............................ 51 3.2. Sprint 2: Interfaz con Leap Motion . . . . . . . . . . . . . . . . . 51 3.3. Sprint 3: Viewport . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.1. Analisis de otras aplicaciones . . . . . . . . . . . . . . . . 52 3.3.2. Interacci´on .......................... 54 3.4. Sprint4:Men´us............................ 57 3.5. Sprint 5 - 8: Operadores . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.1. Escena operator . . . . . . . . . . . . . . . . . . . . . . . . 60 3.6. Sprint9:Iconos............................ 62 4. Implementaci´on 63 4.1. Sprint 2: Interfaz de Leap Motion . . . . . . . . . . . . . . . . . . 64 4.1.1. GDNative ........................... 64 4.2. Sprint 3: Viewport . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3. Sprint4:Men´us............................ 69 4.3.1. Navegaci´on .......................... 69 4.3.2. Widgets ............................ 70 4.4. Sprints 5 - 7: Operadores . . . . . . . . . . . . . . . . . . . . . . . 71 4.5. Sprint 8: Algoritmos de edici´on . . . . . . . . . . . . . . . . . . . 72 4.5.1. Conversi´on entre formatos . . . . . . . . . . . . . . . . . . 73 4.5.2. Separaci´on y Uni´on . . . . . . . . . . . . . . . . . . . . . . 74 4.5.3. Lectura y escritura . . . . . . . . . . . . . . . . . . . . . . 75 4.6. Sprint 9: Barra de estado . . . . . . . . . . . . . . . . . . . . . . . 76 5. Pruebas 77 5.0.1. Pruebas de sprints . . . . . . . . . . . . . . . . . . . . . . 78 5.0.2. Pruebasfinales ........................ 83 5.0.3. Estudio de usabilidad . . . . . . . . . . . . . . . . . . . . . 86 6. Conclusiones y posibles ampliaciones 89 6.1. Conclusiones.............................. 91 6.2. Ampliaciones ............................. 93 iv A. Manuales t´ecnicos 95 A.1. Estructura de archivos . . . . . . . . . . . . . . . . . . . . . . . . 95 A.2.Operadores .............................. 97 A.3.Interacci´on............................... 98 B. Manual de usuario 99 B.1.Interfaz ................................ 99 B.2.Acciones................................ 99 B.3. Soluci´on a problemas comunes . . . . . . . . . . . . . . . . . . . . 102 C. Licencia 103 Bibliograf´ıa 105 v vi ´ Indice de figuras 1.1. Software Tiltbrush para HTC Vive . . . . . . . . . . . . . . . . . 5 1.2. Demo de interacci´on con un espacio 3D con Leap Motion . . . . . 5 1.3. Dog of Wisdom, animado en tiempo real . . . . . . . . . . . . . . 6 1.4. SensorLeapMotion.......................... 7 1.5. Esquema del proceso de puesta a punto de sensor Leap Motion . . 7 2.1. EDTdelproyecto........................... 27 2.2. Diagrama de Gantt del proyecto . . . . . . . . . . . . . . . . . . . 28 2.3. Editor del motor Unity 5 . . . . . . . . . . . . . . . . . . . . . . . 37 2.4. Editor de Unreal Engine 4 . . . . . . . . . . . . . . . . . . . . . . 39 2.5. Editor de Godot Engine 3 . . . . . . . . . . . . . . . . . . . . . . 40 3.1. Inspector de las propiedades de un objeto de Blender . . . . . . . 45 3.2. Modificador EditPoly de 3DS Max . . . . . . . . . . . . . . . . . 45 3.3. Lista de subtools en ZBrush . . . . . . . . . . . . . . . . . . . . . 46 3.4. Diagrama de escenas del proyecto . . . . . . . . . . . . . . . . . . 50 3.5. Mockup final de la aplicaci´on . . . . . . . . . . . . . . . . . . . . 51 3.6. Mockup de una versi´on del deslizador para seleccionar opciones no implementada............................. 51 3.7. Interfaz principal de Zbrush con una Tool cilindro . . . . . . . . . 53 3.8. Blender en modo objeto con los gizmos del operador grab visible. 54 3.9. Viewport de la aplicaci´on mostrando a Suzane . . . . . . . . . . . 55 3.10. Men´u principal de la aplicaci´on . . . . . . . . . . . . . . . . . . . 57 3.11. Submen´u de opciones de la escena de la aplicaci´on . . . . . . . . . 58 3.12. 3DS Max con la herramienta extrude activa . . . . . . . . . . . . 59 3.13. Panel de opciones del operador extruir de Blender . . . . . . . . . 59 3.14. Diagrama de secuencia para la ejecuci´on de un operador . . . . . 61 3.15. Iconos dise˜nados para la aplicaci´on . . . . . . . . . . . . . . . . . 62 4.1. ´ Arbol de nodos de la escena Viewport . . . . . . . . . . . . . . . . 67 4.2. Iluminaci´on de la escena siendo editada con el operador RotateLights 67 4.3. Modelo siendo editado con un ´unico objeto activo. El resto se muestrantransparentes. .......................... 69 4.4. ´ Arbol de nodos de la escena MainMenu . . . . . . . . . . . . . . . 70 vii 4CAP´ ITULO 1. INTRODUCI ´ ON Implementar un sistema de importaci´on y exportaci´on para poder cargar archivos en el programa. Implementar diferentes algoritmos de edici´on de una malla 3D. 1.2. Estado del arte La interacci´on persona-ordenador es un campo de investigaci´on que se centra en estudiar la relaci´on entre los seres humanos y la tecnolog´ıa. Para ello, intenta entender las reglas que un humano podr´ıa usar para comunicarse con un ordenador y en base a estas dise˜na nuevos paradigmas de interacci´on. Estos nuevos modelos de interacci´on pueden tener un gran rango de aplicaciones, ya sean industriales, educativas o como entretenimiento. En los ´ultimos a˜nos la industria del videojuego, buscando experiencias m´as interactivas, ha desarrollado nuevas tecnolog´ıas que permiten una interacci´on m´as natural que un mando o un teclado y rat´on. Estos dispositivos, como el Kinet o el WiiMote permiten reconocer los movimientos del cuerpo y gestos del jugador integr´andolos en el juego, lo que aumenta la sensaci´on de inmersi´on. Todas estas tecnolog´ıas e ideas se han llevado m´as all´a del campo de los videojuegos, como por ejemplo a la educaci´on o a la industria creativa, dando lugar a la aparici´on de diversos dispositivos que permiten una interacci´on natural con el software. Un ejemplo es el programa TiltBrush de Google [7] para HTC Vive [6]. Este software es capaz de mostrar en realidad virtual los trazos de pintura que se realizan con los mandos del HMD (dispositivo que se coloca en la cabeza con una pantalla en frente de cada ojo). Esto permite una visualizaci´on en 3D real del modelo que se est´a realizando, proporcionando al artista la sensaci´on de tener un pincel real en su mano y d´andole mayor control y expresividad (Figura 1.1) Otro tipo de dispositivo dise˜nado para una interacci´on natural es el rat´on 3D fabricado por 3DConnexion. Este hardware permite el control del viewport de muchas aplicaciones 3D tradicionales con 6 ejes de movimientos simult´aneos. Esto posibilita el movimiento de la c´amara por la escena de una forma m´as precisa y directa que mediante un mecanismo de entrada de 2 ejes como un rat´on un una tableta gr´afica. El sensor Leap Motion, capaz de detectar el movimiento de las manos sin necesidad de tocarlo, ha conseguido bastante notoriedad dentro del campo de la interacci´on natural debido a su facilidad de desarrollo y a la gran cantidad de software disponible compatible con ´el. El m´as reciente es el project Orion[9], un intento de acoplar el Leap Motion a un HMD para integrar las manos del usuario en el espacio de realidad virtual y as´ı poder interactuar con los objetos que contiene. Tambi´en existe software disponible para este sensor de car´acter m´as tradicional, como la demo que incluye en su proceso de configuraci´on. Esta 1.2. ESTADO DEL ARTE 5 Figura 1.1: Software Tiltbrush para HTC Vive Figura 1.2: Demo de interacci´on con un espacio 3D con Leap Motion 6CAP´ ITULO 1. INTRODUCI ´ ON Figura 1.3: Dog of Wisdom, animado en tiempo real permite interactuar con unos mu˜necos mediante una representaci´on de la mano del usuario como se muestra en la figura 1.2. La principal finalidad de este software es familiarizar al usuario con el funcionamiento del sensor de forma que pueda coordinar mejor sus movimientos para interactuar con un entorno 3D. Otro tipo de interacci´on con la que se ha experimentado usando el Leap Motion se basa en controlar directamente los huesos de un rig de un personaje animado para generar animaciones en tiempo real (figura1.3). Los movimientos de los personajes del corto Dog of Wisdom est´an controlados mediante el Leap Motion como si fueran marionetas, acelerando de forma considerable el proceso de animaci´on. Esta t´ecnica tambi´en puede aplicarse para animar las manos de personajes 3D copiando directamente los movimientos de la manos del usuario [10]. A pesar de todas estas alternativas, muchas de ellas son muy poco ´utiles en un entorno de producci´on en 3D real, donde no se prioriza una interacci´on natural con el software, a pesar de que este modo de interacci´on podr´ıa integrarse para acelerar procesos como la animaci´on o el prototipado. Salvo el uso de un rat´on 3D en ocasiones puntuales, el resto de hardware es poco funcional, contiene demasiados errores y una precisi´on insuficiente como para su uso en proyectos serios, por lo que se limita a su uso como juguetes o demos t´ecnicas. 1.3. El sensor Leap Motion Leap Motion, Inc. es una compa˜n´ıa americana que manufactura y comercializa el sensor Leap Motion [8] (figura 1.4), un dispositivo que permite usar las manos como m´etodo de entrada de un ordenador, sin necesidad de tocarlo. En 2016, esta empresa public´o un software para integrar este dispositivo con aplicaciones de realidad virtual. 1.3. EL SENSOR LEAP MOTION 7 Figura 1.4: Sensor Leap Motion Figura 1.5: Esquema del proceso de puesta a punto de sensor Leap Motion El sensor Leap Motion es un peque˜no dispositivo USB que fue originalmente dise˜nado para colocarse en la mesa del escritorio, delante del monitor, orientado hacia arriba. Este dispositivo permite la interacci´on con el ordenador mediante la utilizaci´on de las manos como entrada sin la necesidad de interacci´on directa (figura 1.5). Su funcionamiento est´a basado en dos c´amaras infrarrojas junto a unos LEDs para capturar 200 im´agenes por segundo de las manos del usuario. Estas im´agenes se mandan al ordenador por el cable USB y este ejecuta una serie de algoritmos matem´aticos no liberados al p´ublico para determinar la posici´on de las manos. El software que ejecuta estos algoritmos cuenta con un visualizador de diagn´ostico para comprobar que el sensor est´a funcionando correctamente. 8CAP´ ITULO 1. INTRODUCI ´ ON 1.4. Aplicaciones Un software de edici´on y visualizaci´on de modelos en 3D puede beneficiarse del uso del Leap Motion y un paradigma de interacci´on natural obteniendo informaci´on espacial en tiempo real del usuario, imposible de conseguir mediante el uso del teclado y rat´on. En base a estas caracter´ısticas el software que se desarrollar´a en este proyecto podr´a tener aplicaciones en las siguientes ´areas: Visualizaci´on de modelos en 3D en entornos en los que el usuario no pueda estar en contacto directo con un ordenador, como en un entorno m´edico o en salas esterilizadas de laboratorios [12]. Prototipado de modelos en 3D m´as r´apido, permitiendo manipular objetos en todos sus ejes al mismo tiempo Uso adecuado para personas con movilidad reducida, permitiendo realizar m´as acciones con una sola mano respecto a un software de edici´on 3D tradicional [13]. Uso en la industria del entretenimiento para crear juegos o simuladores Educaci´on, ya que proporciona un sistema de interacci´on mucho m´as sencilla e intuitiva para un ni˜no que el uso de un teclado y rat´on [11]. Cap´ıtulo 2 An´alisis En este cap´ıtulo se establecer´an las caracter´ısticas del software a desarrollar identificando sus requisitos funcionales y no funcionales. Tambi´en se tratar´an aspectos relacionados con la gesti´on del proyecto y su planificaci´on, como sus riesgos o su alcance. Por ´ultimo, se har´a un estudio y comparativa de las tecnolog´ıas disponibles para empezar a dise˜nar e implementar el proyecto, procurando escoger la opci´on que mejor se adapte a las caracter´ısticas de este. Contents 2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . 11 2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . 17 2.2.1. Requisitos de dise˜no . . . . . . . . . . . . . . . . . . . 18 2.2.2. Requisitos de interfaz . . . . . . . . . . . . . . . . . . 19 2.2.3. Requisitos de rendimiento . . . . . . . . . . . . . . . . 20 2.2.4. Requisitos de proyecto . . . . . . . . . . . . . . . . . . 21 2.3. Gesti´on de la configuraci´on . . . . . . . . . . . . . . . 22 2.3.1. Control de versiones . . . . . . . . . . . . . . . . . . . 22 2.4. Alcance ........................... 22 2.4.1. Definici´on del alcance del proyecto . . . . . . . . . . . 23 2.4.2. Criterios de aceptaci´on . . . . . . . . . . . . . . . . . . 23 2.4.3. Entregables........................ 23 2.4.4. Exclusiones........................ 23 2.4.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . 24 2.5. Costes ............................ 24 2.5.1. Hardware ......................... 24 2.5.2. Recursos humanos . . . . . . . . . . . . . . . . . . . . 24 2.6. Metodolog´ıa......................... 25 9 10 CAP´ ITULO 2. AN ´ ALISIS 2.7. Planificaci´on ........................ 26 2.8. Riesgos............................ 31 2.8.1. Riesgos de gesti´on del proyecto . . . . . . . . . . . . . 32 2.8.2. Riesgos de disponibilidad . . . . . . . . . . . . . . . . 33 2.8.3. Riesgos de desarrollo . . . . . . . . . . . . . . . . . . . 33 2.8.4. Riesgos de recursos humanos . . . . . . . . . . . . . . 34 2.9. An´alisis de tecnolog´ıas . . . . . . . . . . . . . . . . . . 36 2.9.1. Criterios de selecci´on . . . . . . . . . . . . . . . . . . . 36 2.9.2. Implementaci´on propia . . . . . . . . . . . . . . . . . . 36 2.9.3. Unity2017 ........................ 37 2.9.4. Unreal Engine 4 . . . . . . . . . . . . . . . . . . . . . 38 2.9.5. Godot Engine 3 . . . . . . . . . . . . . . . . . . . . . . 39 2.9.6. Conclusi´on ........................ 40 2.1. REQUISITOS FUNCIONALES 11 2.1. Requisitos funcionales A continuaci´on se recoger´an los requisitos funcionales del producto software que generar´a el proyecto. Dichos requisitos definen la funcionalidad de la aplicaci´on final, por lo que el objeto es documentarlos de la forma m´as precisa posible para que el producto satisfaga las necesidades del cliente. En software de este proyecto est´a pensado para que un ´unico usuario lo use al mismo tiempo, siendo irrelevante el rol de dicho usuario. Por lo tanto, siempre que en el documento se refiera a ’usuario’, se est´a refiriendo al ´unico actor que interactuar´a con el software. Sus casos de uso tambi´en vendr´an dados por los requisitos funcionales listados a continuaci´on. Para definir los requisitos funcionales usar´an los siguientes campos: RF## - Requisito funcional Nombre: Nombre del requisitos funcional Descripci´on: Descripci´on del requisito funcional Prioridad: Prioridad para organizar la implementaci´on y dise˜no de los requisitos funcionales. Precondiciones: Descripci´on del estado del sistema antes de la ejecuci´on de la funcionalidad. Postcondiciones: Descripci´on del estado del sistema una vez se ejecuta la funcionalidad. La prioridad vendr´a definida por: Alta: Es esencial que el requisito funcional est´e implementado cuanto antes. El proyecto fracasar´a en caso de no conseguir implementarlo Media: El requisito ha de implementarse, pero no pone en peligro la viabilidad del proyecto Baja: El requisito es deseable pero no esencial para el proyecto. Los requisitos funcionales del software a desarrollar son los siguiente: 12 CAP´ ITULO 2. AN ´ ALISIS RF1 - Requisito funcional Nombre: Interpretar posici´on y rotaci´on de la mano Descripci´on: El programa deber´a ser capaz de interpretar la posici´on y rotaci´on de la mano cuando se encuentra sobre el sensor para poder responder adecuadamente. Prioridad: Alta Precondiciones: El sensor Leap Motion deber´a estar conectado al ordenador con el driver ejecut´andose y una mano del usuario deber´a colocarse sobre el sensor. Postcondiciones: El programa deber´a reconocer la posici´on y rotaci´on de la mano del usuario respecto al sensor. RF2 - Requisito funcional Nombre: Interpretar estado de la mano Descripci´on: El programa deber´a ser capaz de diferenciar una mano abierta de una cerrada cuando est´an colocadas sobre el sensor. Prioridad: Alta Precondiciones: El sensor Leap Motion deber´a estar conectado al ordenador con el driver ejecut´andose y una mano del usuario deber´a colocarse sobre el sensor. Postcondiciones: El programa deber´a interpretar la mano como abierta o cerrada, respondiendo adecuadamente seg´un el contexto en el que se encuentre. RF3 - Requisito funcional Nombre: Renderizar objeto Descripci´on: Una malla almacenada en la memoria del programa deber´a ser visible por pantalla. Prioridad: Alta Precondiciones: Una malla formada por tri´angulos deber´a estar almacenada en la estructura de datos interna del programa. Postcondiciones: La malla deber´a ser mostrada por pantalla, en perspectiva y con un shading b´asico con una ´unica luz. RF4 - Requisito funcional Nombre: Mover vista de la escena Descripci´on: El usuario deber´a poder manipular la vista de la escena, de forma que los objetos que contiene sean visibles desde diferentes ´angulo, posiciones y distancias. Prioridad: Alta Precondiciones: La escena deber´a tener al menos un objeto. Postcondiciones: El objeto se mostrar´a en la pantalla desde una nueva vista. 2.1. REQUISITOS FUNCIONALES 13 RF5 - Requisito funcional Nombre: Reiniciar vista Descripci´on: El usuario deber´a poder restablecer en cualquier momento la vista de la escena, devolviendo el origen de esta al centro de la pantalla. Prioridad: Baja Precondiciones: La escena deber´a tener al menos un objeto. Postcondiciones: El origen de la escena se establecer´a en el centro del viewport. RF6 - Requisito funcional Nombre: Configurar iluminaci´on Descripci´on: El usuario deber´a poder rotar la iluminaci´on direccional de la escena con el fin de facilitar la visualizaci´on de los objetos que contiene. Prioridad: Baja Precondiciones: La escena deber´a tener al menos un objeto. Postcondiciones: La iluminaci´on rotar´a siguiendo la entrada del usuario. RF7 - Requisito funcional Nombre: Importar archivo Descripci´on: El usuario deber´a poder cargar una malla de un archivo .obj en el programa de forma que esta sea a˜nadida a la escena como un objeto. Prioridad: Alta Precondiciones: Al menos deber´a existir un archivo en la carpeta /models desde la cual se ejecuta la aplicaci´on que contenga una malla compuesta por tri´angulos en formato obj. Postcondiciones: Existir´a un nuevo objeto en la escena que contendr´a la malla almacenada en el archivo .obj. RF8 - Requisito funcional Nombre: Exportar escena Descripci´on: El usuario deber´a poder exportar la escena a un archivo .obj como una ´unica malla, conservando todas las transformaciones realizadas en los objetos. Prioridad: Media Precondiciones: La escena deber´a tener al menos un objeto. Postcondiciones: Se crear´a un nuevo archivo llamado export.obj en la carpeta /models conteniendo las mallas unidas de todos los objetos de la escena. En caso de que este archivo ya exista, se sobreescribir´a. 20 CAP´ ITULO 2. AN ´ ALISIS RN9 - Requisito No Funcional Nombre: Interfaz no dependiente del color Descripci´on: La aplicaci´on no depender´a del color para distinguir funcionalidades o transmitir informaci´on al usuario. Esto har´a el software m´as accesible para personas dalt´onicas que tenga problemas para distinguir ciertos colores. Prioridad: Deseable Criterio de aceptaci´on : El programa debe ser usable y no presentar opciones ambiguas tras aplicar un filtro de blanco y negro al monitor en el que se est´a usando. 2.2.3. Requisitos de rendimiento Los siguientes requisitos afectan al rendimiento del proyecto, buscando el el producto final se pueda ejecutar con un rendimiento deseable para la mayor´ıa de usuarios. RN10 - Requisito No Funcional Nombre: Carga de mallas Descripci´on: La aplicaci´on deber´a ser capaz de visualizar mallas de alta densidad. Prioridad: Esencial Criterio de aceptaci´on : El programa tarda como m´aximo 20 segundos en cargar una malla en .OBJ de con un mill´on de v´ercites y mostrarla en pantalla en un ordenador con un i7 6700, una GTX 1080 y un SSD Samsung EVO Pro. RN11 - Requisito No Funcional Nombre: 60 frames por segundo en el viewport Descripci´on: La aplicaci´on deber´a tener una tasa de frames estable para facilitar su uso Prioridad: Esencial. Criterio de aceptaci´on : El programa es capaz de mantener 60 frames por segundo con una malla de 50k v´ertices en el viewport con una ´unica luz direccional sin sombras en un ordenador con un i7 6700, una GTX 1080 y un SSD Samsung EVO Pro. 2.2. REQUISITOS NO FUNCIONALES 21 RN12 - Requisito No Funcional Nombre: Separaci´on de mallas Descripci´on: El rendimiento a la hora de separar una malla en sus componentes deber´a ser el adecuado. Prioridad: Deseable Criterio de aceptaci´on : El programa es capaz de partir en sus componentes la malla de Suzane por defecto que incorpora Blender exportada como malla triangular y 2 niveles de subdivisi´on en un ordenador con un i7 6700, una GTX 1080 y un SSD Samsung EVO Pro en menos de 2 segundos. 2.2.4. Requisitos de proyecto Estos requisitos afectan a los aspectos relacionados con el proyecto y a las tecnolog´ıas que usaran en el desarrollo del mismo: RN13 - Requisito No Funcional Nombre: Software libre Descripci´on: Se usar´a software libre en la medida de lo posible para realizar el proyecto. Prioridad: Opcional Criterio de aceptaci´on : Todos los componentes usados en el desarrollo del producto ser´an compatibles con la licencia MIT. 22 CAP´ ITULO 2. AN ´ ALISIS 2.3. Gesti´on de la configuraci´on En esta secci´on se identificar´an los elementos que forman la configuraci´on del proyecto con el fin de mantener la integridad y evitar cambios no controlados en los mismos. En el proyecto se pueden identificar los siguientes elementos de la configuraci´on: C´odigo fuente asociado al proyecto. Documentaci´on. Motor de desarrollo y plantillas de exportaci´on. SVG de iconos. 2.3.1. Control de versiones El control de versiones del c´odigo de la aplicaci´on se har´a mediante un repositorio de git local. Cada vez que se a˜nada un cambio significativo en el c´odigo o se a˜nada una funcionalidad nueva se har´a un nuevo commit explicando los cambios. Al finalizar la jornada de trabajo se har´a un push al servidor local, de forma que siempre haya una copia del c´odigo en dos ordenadores distintos. La documentaci´on est´a escrita en Latex. Ya que no tiene una relaci´on fuerte con la versi´on del c´odigo que se est´a manejando se almacenar´a en Google Drive. Dicho servicio almacena los cambios en la nube y guarda diferentes versiones de los archivos para poder volver a un estado de la documentaci´on anterior si fuera necesario. El proyecto usar´a una versi´on en desarrollo de un motor de juegos, por lo que es importante almacenar la versi´on en la que se encuentra su desarrollo para evitar incompatibilidades. Dicha versi´on del ejecutable del motor se sincronizar´a con el repositorio de git local. Los iconos se almacenar´an en un SVG, tambi´en almacenado en Google Drive. Los iconos exportados una vez incluidos en el proyecto estar´an incluidos tambi´en en el repositorio de git junto con el c´odigo de la aplicaci´on. 2.4. Alcance En esta secci´on se detallar´a el alcance del proyecto, necesario para realizar una planificaci´on correcta y centrar los esfuerzos en las ´areas necesarias en cada momento para generar el producto software deseado. 2.4. ALCANCE 23 2.4.1. Definici´on del alcance del proyecto El proyecto generar´a un software para PC compatible con Linux que permitir´a la visualizaci´on y manipulaci´on de objetos 3D. Dicho software deber´a poder cargar e importar objetos desde un archivo, moverlos, rotarlos, escalarlos y modificar su malla para poder cortarlos y separarlos en sus componentes. Este software deber´a ser controlado enteramente mediante el sensor Leap Motion, por lo tanto es fundamental dise˜nar unos paradigmas de interacci´on y una interfaz adaptada al software que se va a realizar. 2.4.2. Criterios de aceptaci´on Para ser aceptado, el producto final deber´a cumplir con los requisitos marcados con prioridad alta en la especificaci´on de requisitos del proyecto. El tiempo sobrante se dedicar´a a implementar los requisitos restantes. 2.4.3. Entregables El proyecto generar´a los siguientes entregables: C´odigo fuente del proyecto producido a lo largo del mismo. Ejecutable del proyecto para la plataforma Linux. Memoria del proyecto en la que se detallar´an los detalles de la gesti´on del proyecto, sus caracter´ısticas de dise˜no e implementaci´on. Manual de usuario del software destinada al usuario final del mismo. 2.4.4. Exclusiones A lo largo del proyecto ser´a necesario usar modelos 3D y mallas para desarrollar y probar las diferentes funcionalidades. La creaci´on de estos modelos no forma parte del proyecto, por lo que se usar´an modelos ya disponibles. Estos archivos tampoco se distribuir´an con el producto final. Dado que el proyecto ser´a publicado con una licencia MIT la biblioteca para el acceso al Leap Motion ni su driver podr´an ser distribuidas con el mismo. Estos archivos son gratuitos y se podr´an descargar desde la p´agina de Leap Motion para que el proyecto se ejecute. El proyecto ser´a desarrollado para Linux. En caso de que sea necesario unos archivos binarios compilados para una plataforma diferente no se establecer´an los pasos para su compilaci´on en dichas plataformas. 24 CAP´ ITULO 2. AN ´ ALISIS Leap Motion 80e Ordenador de desarrollo 4500e TOTAL: 4580e Cuadro 2.1: Costes asociados al hardware del proyecto 2.4.5. Restricciones Para realizar el proyecto se tendr´an en cuenta las siguientes restricciones: El tiempo m´aximo para desarrollar el proyecto es de 410 horas. El proyecto se realizar´a en Linux, concretamente en su distribuci´on Manjaro 17. No se atender´an a problemas de compatibilidad con otras plataformas. Toda la funcionalidad especificada en los requisitos deber´a ser accesible mediante el uso del sistema Leap Motion. 2.5. Costes En esta secci´on se recoger´an los costes del proyecto. 2.5.1. Hardware En la tabla 2.1 se muestra la lista del hardware usado en la realizaci´on del proyecto, indicando su coste. 2.5.2. Recursos humanos El proyecto ha sido realizado por una sola persona, la cual ha cumplido diferentes roles en diferentes partes del ciclo de vida del proyecto. Para calcular el coste asociado a los recursos humanos se asumir´a que una persona ejerciendo los siguientes roles cobra las siguientes cantidades de euros a la hora: Gestor de proyecto: 35e/hora. Dise˜nador gr´afico: 30e/hora. Analista/Programador: 40e/hora. Una jornada de trabajo de este proyecto equivale a 5 horas. Trabajando de lunes a viernes durante 17 semanas se obtienen los resultados mostrados en la tabla 2.2. Por lo tanto, sumando los costes del hardware y los recursos humanos el proyecto tendr´a un coste total de 20705e. 2.6. METODOLOG´ IA 25 Semanas Horas Precio/Hora Precio Gestor de proyecto 5 125 35e4375e Dise˜nador gr´afico 1 25 30e750e Analista/programador 11 275 40e11000e Total:16125e Cuadro 2.2: Costes asociados a los recursos humanos del proyecto 2.6. Metodolog´ıa Una vez de definido los requisitos y el alcance del proyecto se definir´a la metodolog´ıa a seguir para realizarlo. La metodolog´ıa elegida deber´a ser compatible con las caracter´ısticas del proyecto, de forma que aumente su probabilidad de ´exito. Dadas las caracter´ısticas de este proyecto se descarta el uso de una metodolog´ıa predictiva a favor de una metodolog´ıa ´agil por las siguientes razones: El cliente est´a disponible, por lo que puede ser consultado en caso de dudas o para la evaluaci´on de los requisitos que est´an siendo implementados en cada momento. No se cuenta con la suficiente experiencia en determinadas ´areas de la tecnolog´ıa a utilizar, por lo que no es posible hacer una predicci´on exacta del desarrollo de proyecto de forma global. Los requisitos ya especificados est´an sujetos a cambio, especialmente los requisitos no funcionales relativos al rendimiento del proyecto. Se ha elegido scrum como metodolog´ıa para ejecutar el proyecto, ya que es compatible con los puntos mencionados anteriormente. La metodolog´ıa scrum define tres fases diferenciadas en el desarrollo del proyecto: 1. La primera fase se dedica al an´alisis del proyecto. En esta fase se identifican los requisitos, se toman decisiones generales de dise˜no y se crea un boceto de la arquitectura del software que se va a desarrollar. 2. La segunda fase consisten en la realizaci´on consecutiva de sprints para desarrollar el producto software. Cada sprint incremental tendr´a una duraci´on de 1 a 2 semanas. Estos periodos cuentan con una fase de planificaci´on, en la que se identifican las tareas a realizar, una de ejecuci´on y una revisi´on por parte del cliente. 3. En la ´ultima fase se crean la documentaci´on y manuales, finalizando as´ı el proyecto. 26 CAP´ ITULO 2. AN ´ ALISIS 2.7. Planificaci´on La figura 2.2 muestra el diagrama de Gantt de la planificaci´on del proyecto. La figura 2.1 muestra la descomposici´on del trabajo del proyecto. En este proyecto se ha llevado a cabo una fase de planificaci´on inicial en la que se ha determinado el contenido de cada sprint. A continuaci´on se detalla el trabajo realizado en cada sprint: Sprint 1: An´alisis de tecnolog´ıas Descripci´on: En el primer sprint del proyecto se har´a un an´alisis y valoraci´on de las tecnolog´ıas disponibles para implementarlo, as´ı como un primer boceto de su interfaz y funcionalidad general. Requisitos relacionados: RN1, RN2, RN3, RN4, RN5, RN10, RN12 Sprint 2: Lectura de datos desde el sensor Leap Motion Descripci´on: En este sprint, el primero dedicado a desarrollo, se trabajar´a con el SDK de Leap Motion para poder acceder a los datos del sensor desde la tecnolog´ıa usada para desarrollar el proyecto. Una vez finalizado este sprint se debe poder acceder a la posici´on y estado de cada una de las manos desde el entorno de desarrollo elegido para el proyecto, estado el Leap Motion ya integrado en el mismo. Requisitos relacionados: RF1, RF2, RN1 Sprint 3: Viewport Descripci´on: En este sprint se pretende mostrar una malla sencilla en pantalla y desarrollar el movimiento del viewport. Tambi´en se analizar´an diferentes alternativas a los algoritmos para el movimiento de la c´amara del viewport y se calibrar´a para un funcionamiento ´optimo con el sensor. Requisitos relacionados: RF3, RF4, RF9, RF10 Sprint 4: Men´u b´asico Descripci´on: Este sprint consite en codificar la estructura b´asica para realizar el men´u de la aplicaci´on, as´ı como los algoritmos que permitan usar el Leap Motion para navegar de forma c´omoda por el men´u. Requisitos relacionados: RN1 2.7. PLANIFICACI ´ ON 27 Figura 2.1: EDT del proyecto 28 CAP´ ITULO 2. AN ´ ALISIS Figura 2.2: Diagrama de Gantt del proyecto 2.7. PLANIFICACI ´ ON 29 Sprint 5: Men´us secundarios y operadores Descripci´on: En este sprint se finaliza el men´u y se codificar´a el sistema de operadores, de forma que se puede lanzar un operador sencillo. Esto completa la estructura para seguir ampliando el programa a˜nadiendo m´as operadores los siguientes sprints. Requisitos relacionados: RF5, RF6, RF7, RF8, RF11, RF12, RF13, RF14, RF15, RF16, RF17, RF18 Sprint 6: Listas y estado de los objetos Descripci´on: En este sprint se desarrolla los men´us especiales que listen objetos en la escena, as´ı como funcionalidades que modifiquen el estado de los objetos del viewport, su creaci´on o eliminaci´on. Requisitos relacionados: RF9, RF10, RF12, RF13, RF14, RF15 Sprint 7: Operadores de transformaci´on y control de escena Descripci´on: En este sprint se a˜naden los operadores relacionados con el escalado de objetos y el control general del viewport, por lo que es necesario experimentar con formas de interacci´on que permitan un uso satisfactorio de los mismos. Requisitos relacionados: RF5, RF6, RF11, RN1 Sprint 8: Operadores de modificaci´on de la malla y acceso a archivos Descripci´on: Este sprint consiste en desarrollar los algoritmos relacionados con la edici´on directa de la malla. Para ello es necesario experimentar con la API que proporciona la tecnolog´ıa elegida para el proyecto y evaluar su rendimiento. Tambi´en se implementan los operadores de carga y guardado de archivos. Requisitos relacionados: RF7, RF8, RF16, RF17, RN10, RN12 Sprint 9: Dise˜no gr´afico y animaciones Descripci´on: En el ´ultimo sprint se dise˜nan los iconos para los men´us y se a˜naden animaciones a los mismos para hacer la interfaz m´as agradable. Tambi´en se a˜nade la barra de estado para facilitar el uso de la aplicaci´on por parte del usuario. Requisitos relacionados: RF18, RN7, RN8, RN9 36 CAP´ ITULO 2. AN ´ ALISIS 2.9. An´alisis de tecnolog´ıas En este apartado se analizar´an diferentes soluciones tecnol´ogicas a la hora de implementar el proyecto. Dichas opciones deber´an ser compatibles con los requisitos del proyecto y facilitar su desarrollo e implementaci´on en la medida de lo posible. Al ser un proyecto basado en su mayor parte en su parte gr´afica, esta ser´a la que mayor tiempo de desarrollo consumir´ıa. Por lo tanto, se valorar´a tanto la opci´on de programar un renderizador de cero adaptado al proyecto como la de usar un renderizador ya existente disponible en un motor de juegos. 2.9.1. Criterios de selecci´on Se decidir´a una tecnolog´ıa para desarrollar el proyecto. Para ello se tendr´an en cuenta las siguientes cuestiones: El proyecto cuenta con una parte 3D (viewport) y una 2D (interfaz gr´afica). La tecnolog´ıa elegida deber´a soportar ambos modos de funcionamiento y facilitar en la medida de lo posible el desarrollo. La tecnolog´ıa elegida deber´a ser compatible con el SDK de Leap Motion de forma que cumpla con los requisitos RF1, RF2, RN3 y RN6 De cara a la posible expansi´on del programa o posibles problemas de rendimiento, la tecnolog´ıa elegida deber´a soportar tecnolog´ıas de desarrollo que no supongan problemas adicionales en este aspecto. Esto afectar´ıa a los requisitos RF14 y RF15 relacionados con la manipulaci´on de mallas, as´ı como a los requisitos RN10, RN11 y RN12. 2.9.2. Implementaci´on propia Esta opci´on consistir´a en programar un renderizador en OpenGL 3.0 adaptado a las necesidades del proyecto. Para cumplir con los requisitos del proyecto, este renderizador deber´ıa contar con las siguientes funcionalidades: Dibujado de mallas en 3D Dibujado de sprites 2D Dibujado de texto Soporte para materiales, al menos para modificar su color con un valor fijo. Ventajas El renderizador estar´ıa completamente adaptado a las funcionalidades del proyecto, por lo que tendr´ıa un rendimiento optimo Leap Motion cuenta con un SDK compatible con gran cantidad de lenguajes de programaci´on, entre ellos C++, Java o Python 2.9. AN ´ ALISIS DE TECNOLOG´ IAS 37 Figura 2.3: Editor del motor Unity 5 Mayor flexibilidad a la hora de estructurar y programar el resto del proyecto Inconvenientes Programar un renderizador de cero aumentar´a el coste y duraci´on del proyecto No se dispone de ning´un framework base para la creaci´on de la interfaz. Las opciones restantes ser´ıan programar uno o genar una interfaz suficientemente sencilla como para no necesitar framework. No se cuenta con un editor gr´afico para visualizar el proyecto mientras se desarrolla Ninguna ayuda a la hora de tratar otros aspectos del proyecto, como la lectura de archivos o la gesti´on de las ventanas de la aplicaci´on. 2.9.3. Unity 2017 Unity es un motor gr´afico multiplataforma orientado a videojuegos y aplicaciones interactivas. Cuenta con las herramientas b´asicas para realizar juegos en 2D y 3D, un potente editor y una gran comunidad de usuarios. El lenguaje principal para programar proyectos en el motor es C#, y este est´a implementado en C y C++ de forma cerrada. Su funcionamiento se basa en el modelo entidad-componente. A pesar de su fama, muchos estudios no lo consideran como una opci´on seria a la hora de realizar sus proyectos porque su estructura interna no est´a preparada para soportar juegos de gran complejidad, por lo que se considera un motor gr´afico de juguete para realizar peque˜nos proyectos independientes o iniciarse en el mundo del desarrollo de videojuegos. Ventajas Es un motor gr´afico muy usado, por lo que cuenta con una buena documentaci´on y un gran soporte de la comunidad 38 CAP´ ITULO 2. AN ´ ALISIS Cuenta con un buen soporte con el SDK de Leap Motion, ya que se puede descargar un proyecto ya preparado para empezar a usar el sensor sin necesidad de modificar el motor. A pesar de contar ´unicamente con un renderizador 3D que usa en modo ortogr´afico para generar una imagen 2D, cuenta con unas herramientas suficientemente potentes para poder generar una interfaz de usuario compleja. Inconvenientes Es de c´odigo cerrado, por lo que no habr´ıa posibilidad de modificar el motor en caso de que generara alg´un problema durante el desarrollo del programa. No permite el control del bucle principal del motor, por lo que no es posible determina el orden de ejecuci´on de los componentes de los objetos. Esto puede dificultar el desarrollo del proyecto. Adem´as es conocido que muchos estudios que trabajan con Unity necesitaron pedir el c´odigo del motor para solucionar este problema. El rendimiento del motor es terrible incluso en escenas muy sencillas, supuestamente por la alta cantidad de plataformas que soporta Solamente cuenta con C# como lenguaje de programaci´on. A pesar de que esto no es un factor limitante para programar la interfaz gr´afica del programa, puede serlo para crear los algoritmos de edici´on de la malla debido al recolector de basura. El mal dise˜no de su estructura interna impide usar correctamente un control de versiones con sus archivos, ya que no soporta que dos usuarios modifiquen una escena al mismo tiempo. En caso de necesitar esta funcionalidad es necesario el uso de plugins. 2.9.4. Unreal Engine 4 Unreal Engine 4 es un motor de juegos multiplataformas orientado a t´ıtulos que requieren un alto rendimiento y calidad. Cuenta con uno de los mejores renderizadores 3D en tiempo real disponibles actualmente en el mercado, as´ı como otras herramientas como editor gr´afico de materiales, f´ısicas o sistema de AI. El c´odigo del motor est´a disponible, pero es demasiado complejo como para poder hacer modificaciones en el desarrollo de este proyecto. Su lenguaje de programaci´on m´as integrado con el editor es Blueprints, un sistema de scripting visual. Adem´as, tambi´en soporta C++. Ventajas Tiene una buena documentaci´on y una gran comunidad de usuarios Cuenta con uno de los mejores motores gr´aficos disponibles al p´ublico actualmente, tanto en calidad como en rendimiento 2.9. AN ´ ALISIS DE TECNOLOG´ IAS 39 Figura 2.4: Editor de Unreal Engine 4 Su lenguaje de programaci´on principal es C++, por lo que no habr´ıa ning´un tipo de problema con el rendimiento del programa Cuenta con un soporte directo del SDK de Leap Motion mediante un proyecto ya creado Inconvenientes No es la mejor opci´on para desarrollar en 2D y esto podr´ıa suponer un problema dado que gran parte del desarrollo del proyecto consistir´a en la creaci´on de los men´us adaptados para el Leap Motion. A lo largo del proyecto no ser´a necesario usar la gran mayor´ıa de opciones que ofrece el renderizador del motor C++ no es el mejor lenguaje para prototipar interfaces gr´aficas 2.9.5. Godot Engine 3 Godot Engine 3 es un motor de juegos multiplataforma de c´odigo abierto. La versi´on 1.0 se ha liberado al p´ublico en el a˜no 2015 tras 10 a˜nos de desarrollo. La versi´on estable disponible a la hora de empezar el proyecto es la 2.1. Esta opci´on no se contempla ya que tiene muy pocas funcionalidades a la hora de desarrollar en 3D y no ser´ıa suficiente para cumplir con los requisitos de la aplicaci´on que se desarrollar´a. Para la nueva versi´on 3.0 el renderizador y editor 3D se ha vuelvo a programar y ya cuenta con unas funcionalidades y calidad similares a las otras opciones disponibles en el mercado. Esta versi´on se encuentra en alpha y est´a planificado que la versi´on final ya est´e disponible en las ´ultimas etapas de este proyecto. La versi´on alpha es perfectamente usable y sus desarrolladores han dicho que no generar´a ninguna incompatiblidad seria con la versi´on final. Su lenguaje principal es GDScript, un lenguaje especialmente dise˜nado para el motor y altamente integrado con su editor que se ejecuta en una m´aquina de bytecodes. 40 CAP´ ITULO 2. AN ´ ALISIS Figura 2.5: Editor de Godot Engine 3 Adem´as en su versi´on 3.0 soporta C++, un lenguaje de VisualScript y C# mediante Mono. Ventajas Es de c´odigo abierto y es f´acilmente modificable. Se podr´ıan a˜nadir nuevas funcionalidades al motor en caso de que fuera necesario para el proyecto Cuenta con un renderizador 2D y 3D por separado, por lo que facilitar´a tanto la creaci´on de la interfaz gr´afica como del viewport del programa El renderizador 3D que incorpora cuenta con una calidad y rendimiento suficientes para el proyecto Soporta varios lenguajes de programaci´on simult´aneos en un mismo proyecto, pudiendo elegir entre rendimiento o facilidad de uso seg´un convenga. Inconvenientes La versi´on m´as reciente (3.0) del motor se encuentra en alpha a la hora de iniciar el proyecto, por lo que puede hacer que ciertas partes del programa a desarrollar sean incompatibles con la versi´on final del motor. No tiene ning´un tipo de soporte directo con el Leap Motion por lo que habr´ıa que desarrollar esta parte. A pesar de esto, cuenta con las funcionalidades necesarias para poder incorporar f´acilmente al motor cualquier biblioteca ya disponibe. Muchas partes del motor no tienen documentaci´on. 2.9.6. Conclusi´on Despu´es de evaluar todas las opciones detenidamente y teniendo en cuenta la experiencia desarrollando proyectos con estas plataformas, considero que la mejor opci´on para realizar el proyecto es Godot Engine 3 por las siguientes razones: 2.9. AN ´ ALISIS DE TECNOLOG´ IAS 41 Cuenta con herramientas independientes y optimizadas para el desarrollo 3D y 2D por separado. A pesar de que no dispone integraci´on directa con Leap Motion, cuenta con una funcionalidad para usar bibliotecas de C++ de forma sencilla con el motor, por lo que el desarrollo de esta parte del proyecto no ser´ıa demasiado compleja. En caso de que esta opci´on no sea suficiente, se podr´ıa a˜nadir el m´odulo al motor en un tiempo razonable. Soporta diversas opciones a la hora de programar proyectos en el motor. GDScrit est´a orientada a sencillez y velocidad de desarrollo, mientras que se podr´ıa usar C++ en cualquier momento para partes del proyecto en las que el rendimiento no sea suficiente- 42 CAP´ ITULO 2. AN ´ ALISIS Cap´ıtulo 3 Dise˜no Este cap´ıtulo se centrar´a en el dise˜no de la aplicaci´on, tanto a nivel de interacci´on, interfaz y estructura. En primer lugar se analizar´an otras aplicaciones de edici´on 3D para detectar los conceptos y paradigmas con los que un usuario habitual de las misma estar´a familiarizado. Posteriormente estos conceptos se adaptar´an a su uso con un Leap Motion para usarlos en esta aplicaci´on. Por ´ultimo se dise˜nar´a una estructura para el proyecto siguiendo los patrones de dise˜no que se pueden aplicar en Godot Engine de forma que la aplicaci´on pueda ser f´acilmente ampliable con nuevos requisitos funcionales en un futuro. Contents 3.1. Sprint 1: Dise˜no general . . . . . . . . . . . . . . . . . 44 3.1.1. An´alisis de otras aplicaciones . . . . . . . . . . . . . . 44 3.1.2. Paradigmas de interacci´on . . . . . . . . . . . . . . . . 47 3.1.3. Dise˜no de la implementaci´on . . . . . . . . . . . . . . 48 3.1.4. Mockups ......................... 51 3.2. Sprint 2: Interfaz con Leap Motion . . . . . . . . . . . 51 3.3. Sprint 3: Viewport . . . . . . . . . . . . . . . . . . . . . 52 3.3.1. Analisis de otras aplicaciones . . . . . . . . . . . . . . 52 3.3.2. Interacci´on . . . . . . . . . . . . . . . . . . . . . . . . 54 3.4. Sprint 4: Men´us . . . . . . . . . . . . . . . . . . . . . . 57 3.5. Sprint 5 - 8: Operadores . . . . . . . . . . . . . . . . . 58 3.5.1. Escena operator . . . . . . . . . . . . . . . . . . . . . 60 3.6. Sprint 9: Iconos . . . . . . . . . . . . . . . . . . . . . . 62 43 44 CAP´ ITULO 3. DISE ˜ NO 3.1. Sprint 1: Dise˜no general En este Sprint se definir´an las caracter´ısticas generales del programa, su funcionamiento y estructura de datos, as´ı como en los conceptos que estar´a basada su interacci´on. Para ello se analizar´an otras aplicaciones de dise˜no 3D y posteriormente se establecer´a una serie de comportamientos generales que deber´an cumplir las acciones del Leap Motion dentro de la aplicaci´on para poder interactuar con la interfaz. 3.1.1. An´alisis de otras aplicaciones En este apartado se analizar´an las caracter´ısticas que comparten la mayor´ıa de programas de edici´on 3D para poder hacer una adaptaci´on lo m´as correcta posible en el producto software que se est´a desarrollando. Este an´alisis se lleva a cabo durante el primer sprint del ciclo de vida del proyecto, ya que sus conclusiones afectan directamente a la estructura interna del programa. Para ello se usar´an dos grandes grupos de aplicaciones. Por una parte, las orientadas a una edici´on 3D tradicional basada en la modificaci´on directa de los componentes de una malla (Blender, Maya, 3DSMax y Cinema4D). Por otra, las optimizadas para escultura y trabajo con mallas de alta densidad, que no requieren acceso a los componentes de la malla (Zbrush o Mudbox). Una vez detectadas sus similitudes y diferencias se proceder´a a seleccionar las caracter´ısticas que m´as se adecuan a este proyecto. Las aplicaciones de edici´on 3D se basan en el uso de objetos como principal entidad para abstraer los datos de una malla situados en una posici´on en el espacio. Estos objetos son contenedores de datos que, adem´as de contener los datos de la malla, son responsables de almacenar posiciones, estado de visualizaci´on, caracter´ısticas para el render o flags y m´ascaras para las simulaciones f´ısicas (figura 3.1). Para ilustrar el concepto en diferentes softwares se muestran los siguientes ejemplos: En Blender, el modo por defecto de la aplicaci´on es el modo objeto. En este modo se pueden acceder a las caracter´ısticas del objeto mencionadas anteriormente mediante el panel de propiedades del objeto en el inspector. Al seleccionar un objeto se puede entrar en su modo edici´on para acceder a los componentes de su malla individualmente y poder modificarlos. Es importante notar que las transformaciones que se realizan en la malla y en el objeto son independientes, ya que el origen del espacio en el que se representar´an las coordenadas de los v´ertices de la malla se almacenan a nivel de objeto. En 3DSMax tampoco se puede acceder a los componentes de la malla por defecto. Estos datos son visibles tras usar un modificador EditPoly(figura 3.2) , conservando tambi´en los dos niveles en la estructura de datos. Este funcionamiento tambi´en aporta la posibilidad de almacenar diferentes estados de la edici´on de la malla en varios modificadores EditPoly. Adem´as, lo com´un de este tipo de programas es permitir las jerarqu´ıas de objetos. Un objeto hijo de otro hereda todas sus transformaciones y su espacio. Esto es ´util para rigging o para la organizaci´on de objetos. 3.1. SPRINT 1: DISE ˜ NO GENERAL 45 Figura 3.1: Inspector de las propiedades de un objeto de Blender Figura 3.2: Modificador EditPoly de 3DS Max 52 CAP´ ITULO 3. DISE ˜ NO contar´a con los siguientes m´etodos: get hand transform(hand): devuelve la matriz de transformaci´on de la mano deseada. is hand visible(hand): devuelve true si la mano deseada es visible para el sensor. get hand status(hand): permite saber si la mano deseada est´a abierta o cerrada. is leap connected(): permite acceder al estado del sensor y saber si est´a preparado para su funcionamiento. 3.3. Sprint 3: Viewport Este sprint est´a dedicado al dise˜no del funcionamiento del viewport del programa, as´ı como a definir de forma m´as precisa su forma de interacci´on mediante el Leap Motion. Para ello se analizar´a el funcionamiento de otras aplicaciones de edici´on 3D, de forma similar a lo realizado en los sprints anteriores. 3.3.1. Analisis de otras aplicaciones El viewport es el espacio de trabajo en el que se muestran los objetos en 3D que se est´an editando. Estos objetos se representan a trav´es de una proyecci´on que viene dada por una c´amara que no pertenece a la escena. Las propiedades de esta c´amara se pueden modificar para poder cambiar la vista o la proyecci´on de la escena y poder trabajar sobre los objetos m´as c´omodamente. Las principales transformaciones que se pueden hacer en estos softwares sobre la posici´on de la c´amara son las siguiente: Rotaci´on: la c´amara rota sobre un punto no visible en la escena que se puede establecer manualmente o de forma autom´atica dependiendo de la ´ultima selecci´on. En la mayor´ıa de los softwares se puede elegir entre mantener la rotaci´on fija en el eje Z (turntable) o rotar libremente en todos los ejes (trackball). Panning: el origen de la c´amara se desplaza en un plano paralelo al plano de proyecci´on de la c´amara. Esto permite poder desplazar la escena lateralmente. Zoom: La c´amara var´ıa su distancia a un punto invisible situado en la escena. Una vez se alcanza la posici´on de este punto no se puede hacer m´as zoom y la c´amara se bloquea. Para activar este tipo de movimientos en la c´amara la mayor´ıa de los softwares de edici´on 3D usan las teclas modificadoras, la pulsaci´on de un bot´on del rat´on y el movimiento del mismo. Tambi´en es bastante com´un usar la rueda del rat´on con o sin tecla modificadora para controlar el zoom de la c´amara. Normalmente esta opci´on puede desactivarse para facilitar la interacci´on del programa con tableta gr´afica. En el caso de Zbrush, la c´amara se controla haciendo clic es espacios del viewport en los que no hay ning´un objeto dibujado (figura 3.7). Esto se debe a que es un programa que se 3.3. SPRINT 3: VIEWPORT 53 Figura 3.7: Interfaz principal de Zbrush con una Tool cilindro usa principalmente con tableta gr´afica, por lo que es mucho m´as r´apido interactuar con la posici´on de la c´amara de esta forma. En todos los softwares tambi´en se pueden modificar propiedades de la c´amara como su su tipo de perspectiva o campo de visi´on, as´ı como poder activar m´ultiples vistas simultaneas. Tambi´en se permite restablecer la posici´on de la c´amara para que el origen de coordenadas de la escena quede en el centro de la pantalla o centrar la c´amara directamente sobre uno de los objetos. A pesar de que este tipo de interacci´on ya est´e muy establecida en el mundo de la edici´on 3D, para este sofware puede ser necesario una modificaci´on para facilitar su uso con el Leap Motion. Dichas modificaciones se basan en las siguientes puntos: A pesar de que un usuario espera mover la c´amara cuando est´a interactuando mediante un dispositivo se˜nalador (rat´on o tableta gr´afica), esta no es la situaci´on esperada cuando el usuario necesita mover la mano en el espacio para interactuar con la vista de la escena. Las personas est´an acostumbradas a que los objetos que est´a en sus manos se muevan en relaci´on a su vista cuando desplazan sus manos por el espacio, no a que el objeto se mantenga fijo y su punto de vista sea modificado. Por lo tanto, la aplicaci´on se dise˜nar´a de forma que los objetos sean siempre los que se mueven en relaci´on a la c´amara, no la c´amara en relaci´on a los objetos. No se incluir´a la opci´on de alterar el campo de visi´on de la c´amara. En este programa es de vital importancia que el usuario mantenga una imagen 3D mentalmente de la escena para poder interactuar de forma c´omoda con la misma, por lo que alterar par´ametros de la perspectiva puede confundirlo a la hora de calcular distancias y relaciones de tama˜no entre objetos. No se incluir´a una opci´on para activar una vista ortogr´afica. Al estar usando un dispositivo de entrada que permite el uso de las tres dimensiones no tendr´ıa sentido eliminar la informaci´on de uno de los ejes en el viewport. 54 CAP´ ITULO 3. DISE ˜ NO Figura 3.8: Blender en modo objeto con los gizmos del operador grab visible. 3.3.2. Interacci´on La mayor´ıa de estas aplicaciones se basan en el uso de gizmos para la transformaci´on de elementos en la escena. Estos son peque˜nas indicaciones en forma de flechas que realizan la transformaci´on deseada al seleccionarlas y arrastrarlas con el rat´on (figura 3.8). A pesar de que este m´etodo aporta una gran precisi´on a la hora de realizar transformaciones, en un entorno de interacci´on con un Leap Motion presentar´ıa las siguientes desventajas: El uso de gizmos est´a basado en el uso de un dispositivo se˜nalador para interactuar con los mismos. No ser´ıa problema implementar un cursor en el espacio 3D que siguiera los movimientos de la mano, pero ser´ıa muy poco gratificante para el usuario tener que seleccionar un elemento en un espacio 3D de un tama˜no relativamente peque˜no cada vez que tiene que realizar una tansformaci´on. El tama˜no de los gizmos, su representaci´on en 3D y la representaci´on de los elementos como el cursor tendr´ıan que tener un tama˜no y unas caracter´ısticas que los har´ıan poco pr´acticos a la hora de visualizar el resto de la escena. El uso de gizmos limita las transformaciones a uno o dos ejes simult´aneos. Esto es ´util en el caso del uso del rat´on ya que como m´aximo se pueden controlar dos ejes a la vez. Usando este tipo de interacci´on con un dispositivo como el Leap Motion en el que se permite una entrada de todos los ejes simult´aneos ser´ıa no aprovechar sus posibilidades. 3.3. SPRINT 3: VIEWPORT 55 Figura 3.9: Viewport de la aplicaci´on mostrando a Suzane El uso de un gizmo para modificar las transformaciones de los objetos no est´a extendido fuera de los programas de edici´on 3D. Las personas est´an acostumbradas a usar sus manos para poder manipular los objetos en el mundo real y ver sus transformaciones acorde al movimiento de las mismas. Por lo tanto, teniendo en cuenta los paradigmas de interacci´on definidos anteriormente y las conclusiones del primer sprint, el funcionamiento del viewport de esta aplicaci´on ser´a el siguiente: Los objetos y la escena se mover´an siempre en relaci´on a la c´amara. La escena solamente se mover´a cuando el usuario tenga su mano derecha cerrada sobre el sensor, en cuando el usuario abra la mano la escena quedar´a bloqueada. Esto har´a que el usuario perciba el movimiento que realiza como si estuviera agarrando un objeto en el mundo real. El movimiento ser´a siempre relativo a la mano del usuario, no al objeto. El usuario no deber´a tener la mano en ninguna posici´on en concreto para mover la vista del viewport, por lo que puede desplazarse por el mismo con mayor velocidad y sin estar pendiente de la posici´on de su mano (de la misma forma en la que se puede mover la posici´on de la c´amara en cualquier software 3D independientemente de la posici´on del rat´on). Todos los movimiento se calcular´an respecto a la posici´on en la que la mano se ha cerrado por primera vez. Para resolver el movimiento del viewport la soluci´on es directa: se aplica el vector resultante de restar la posici´on final a la inicial de la mano derecha (´ultima posici´on de la mano abierta menos la primera posici´on de la mano cerrada) al origen de la escena. Si fuera necesario, este vector se escalar´a para compensar la escala por defecto de los objetos en el programa. Este tipo de movimiento resuelve tanto el panning como el zoom de un viewport de un software 3D tradicional, ya que para acercar un objeto a la vista el usuario 56 CAP´ ITULO 3. DISE ˜ NO solamente tendr´a que mover la mano hacia s´ı mismo como si lo estuviera agarrando en el mundo real, dando lugar a una interacci´on m´as natural. A pesar de que el sensor Leap Motion aporta una clara ventaja en este tipo de movimientos, las rotaciones no tienen una soluci´on directa que produzca una sensaci´on agradable al usar el software. Este problema se ha detectado en los primeros prototipos realizados durante el tercer sprint, dando lugar a las siguientes opciones: Copiar la rotaci´on a la escena en espacio local: Con esta configuraci´on, la primera rotaci´on que realice el usuario al rotar su mano se realizar´a correctamente, ya que por defecto los ejes de la mano y del objeto est´an alineados al no haberse realizado ning´un giro previamente. La ventaja de usar el espacio local es que los ejes de la mano se orientar´an autom´aticamente al objeto, no teniendo en cuenta la rotaci´on relativa entre la mano y el sensor (el eje z de la mano ser´a siempre el eje z del objeto al principio de la rotaci´on, independientemente de la rotaci´on en la que se encuentren). Al comportarse de esta manera, las rotaciones se acumulan. Una vez rotado el objeto, la nueva rotaci´on se aplicar´a sobre su rotaci´on actual y ya no corresponder´a con lo que el usuario espera ver realizando su rotaci´on con la mano. Esto da lugar a situaciones en las que si un objeto se encuentra rotado 180 grados en el eje Y (con el eje Z apuntando en direcci´on contraria al eje Z de la mano del usuario), el objeto rotar´a en sentido contrario, como si se viera reflejado en un espejo. Copiar la rotaci´on a la escena en espacio global: Con esta configuraci´on, los objetos rotan siempre de forma consistente, independientemente de la rotaci´on que ya tengan. El problema de rotar en espacio global es que se tiene en cuenta la rotaci´on de la mano con respecto al sensor, por lo que para que la rotaci´on sea la esperada el usuario deber´a tener la mano perfectamente alineada con los ejes del sensor. Esto es algo que raramente pasa, ya que en la mayor´ıa de los casos no se comprueba la orientaci´on del sensor antes de realizar la acci´on, y cualquier error en la alineaci´on entre el sensor y la mano hace que la rotaci´on empiece a realizarse desde un ´angulo incorrecto. Adem´as produce demasiadas inconsistencias, ya que es muy dif´ıcil tener la mano siempre en la misma orientaci´on inicial a la hora de realizar la rotaci´on. Los usuarios est´an familiarizados con este comportamiento en cualquier m´etodo de interacci´on (el rat´on se mueve el cursor teniendo en cuenta sus coordenadas locales, no depende de la orientaci´on entre el rat´on y la pantalla o entre el rat´on y la alfombrilla). Para solucionar este problema ha sido necesario dise˜nar el siguiente proceso: La rotaci´on se realiza en espacio local, de esta forma la orientaci´on inicial de la mano siempre coincide con la orientaci´on del objeto, sin tener en cuenta la orientaci´on del sensor. Esto es lo que el usuario espera. Una vez realizada la rotaci´on, se computa un nuevo espacio para el objeto de forma que su rotaci´on se conserve, pero sus coordenadas globales vuelvan a ser las iniciales. 3.4. SPRINT 4: MEN ´ US 57 Figura 3.10: Men´u principal de la aplicaci´on Al realizar una nueva rotaci´on, esta funcionar´a igual que la primera realizada en espacio local, pero sobre un objeto alterado ya rotado previamente. 3.4. Sprint 4: Men´us El men´u de la aplicaci´on es el lugar desde el cual se accede a las diferentes opciones y se lanzan los operadores para editar el contenido de la escena (figura 3.10). Siguiendo las conclusiones de los apartados anteriores, el men´u se han dise˜nado para que su interacci´on con el Leap Motion sea lo m´as satisfactoria posible en el cuarto sprint del proyecto. Para ello, se ha evitado en todo momento el uso de cursores. En su lugar se ha establecido el siguiente funcionamiento: Al cerrar la mano izquierda se muestra el men´u, al abrirla el men´u desaparece. Cuando se abre la mano el men´u se cierra sin haber seleccionado ning´un operador, de esta forma el usuario puede cancelar la acci´on en cualquier momento, de la misma manera que puede parar un movimiento del viewport abriendo la mano derecha. Los movimientos verticales de la mano izquierda cerrada sirven para cambiar de opci´on resalta en el men´u. Los movimientos horizontales de la mano izquierda cerrada sirven para seleccionar opciones del men´u o seleccionar submen´us (figura 3.11). El acceso a una opci´on del men´u deber´a ser lo m´as breve posible, de forma que se pueda acceder a la opci´on deseada con el m´ınimo movimiento. Atendiendo los puntos mencionados se ha dise˜nado el widget para las opciones del men´u. Este widegt cuenta con las siguientes caracter´ısticas: Su recuadro de selecci´on responde al movimiento vertical de la mano, permitiendo seleccionar otros widgets que se encuentren encima o debajo del mismo. 58 CAP´ ITULO 3. DISE ˜ NO Figura 3.11: Submen´u de opciones de la escena de la aplicaci´on Su deslizador responde al movimiento horizontal de la mano. Contiene dos opciones por widget, reduciendo la longitud de los men´us. Responde a movimientos sutiles de la mano del usuario, de forma que este puede identificar el movimiento que est´a realizando antes de finalizarlo y confirmar su selecci´on. Adem´as, el men´u se ha dise˜nado de forma que el mismo gesto en el espacio resulte siempre en la misma opci´on seleccionada. Una vez que un usuario se sienta c´omodo con la aplicaci´on no tendr´a que leer las opciones del men´u para poder llegar hasta ellas, ya que, por ejemplo, el gesto cerrar mano, mover a la derecha mover a la izquierda, abrir mano equivale siempre a seleccionar todos los objetos, independientemente de donde se encuentre la mano izquierda en ese momento. 3.5. Sprint 5 - 8: Operadores Durante los sprints 5, 6, 7 y 8 ser´a necesario implementar la mayor parte de funcionalidad de la aplicaci´on. En el sprint 5 se definir´an los principios base para implementar todas estas funcionalidades, dejando los sprints restantes para terminar la implementaci´on de las mismas. Para ello, el primer paso es decidir una forma para organizar dichas funcionalidades de forma que facilite el desarrollo y sea intuitivo para el usuario. A la hora de organizar y establecer el funcionamiento de las diferentes herramientas de edici´on que incorporan los software de edici´on en 3D se han seguido diferentes enfoques. La gran mayor´ıa de softwares disponibles en el mercado usan el concepto de herramienta, cuyas caracter´ısticas son las siguientes: El usuario selecciona una herramienta. Esta se mantiene activa hasta que el usuario selecciona una herramienta diferente (figura 3.12). 3.5. SPRINT 5 - 8: OPERADORES 59 Figura 3.12: 3DS Max con la herramienta extrude activa Figura 3.13: Panel de opciones del operador extruir de Blender El usuario realiza las ediciones correspondientes en la escena usando la herramienta activa, por lo que el comportamiento de la interfaz del programa depende directamente de la herramienta activa. El software suele tener una herramienta activa por defecto, generalmente la herramienta de selecci´on. Por otra parte est´a el enfoque de Blender. En este software las herramientas son llamadas operadores (figura 3.13). Se diferencian de las herramientas de los softwares tradicionales en los siguientes puntos: El software se encuentra siempre en el mismo estado cuando no hay ning´un operador activo, respondiendo siempre a la entrada del usuario de la misma forma. Cuando se activa un operador, el comportamiento del software se altera para poder realizar la edici´on. Esta alteraci´on dura hasta que la edici´on finaliza, posteriormente el software vuelve a su estado por defecto. 60 CAP´ ITULO 3. DISE ˜ NO Para continuar realizando ediciones del mismo tipo es necesario seleccionar el operador de nuevo. Este enfoque puede no parecer intuitivo a primera vista ya que se necesita realizar una selecci´on de un operador cada vez que se requiere modificar alg´un elemento del espacio de trabajo. No obstante cuenta con las siguientes ventajas: El usuario no tiene que memorizar la herramienta que tiene activa mientras trabaja con el software. En un proceso de modelado 3D es muy raro usar una herramienta m´as de 3 veces seguidas de forma que compense bloquear el software en un estado en el que solo se permita su uso. Los operadores pueden activarse r´apidamente mediante atajos de teclado, pudiendo substituir el clic de selecci´on de una herramienta por la pulsaci´on del atajo que inicia el operador. A la hora de implementar este software se usar´a el enfoque de los operadores. La aplicaci´on tendr´a un estado por defecto sobre el cual se podr´an activar operadores para realizar las ediciones correspondientes. Una vez finalice la edici´on el software volver´a a su estado por defecto. 3.5.1. Escena operator La escena operator ser´a la base para la implementaci´on de los operadores en este software.Es la escena base para todos los operadores que permiten realizar ediciones en el programa. Todos los operadores deber´an implementar los siguientes m´etodos en su script de su nodo principal (que tambi´en hereda del script operator). begin(params): inicia el operador con determinados par´ametros. process(delta): en caso de que el operador necesite m´as de un frame para aplicarse, la actualizaci´on de su estado se realizar´a en este m´etodo teniendo en cuenta el par´ametro delta. end(): finaliza el operador, haciendo los ajustes que sean necesarios en la escena antes de ser eliminado. Adem´as este script ha de implementar una forma de acceder al viewport para que sea m´as sencillo realizar modificaciones sobre el mismo. La escena operator tambi´en contiene un nodo que almacena el icono y el nombre del operador, que se mostrar´a en la barra de estado una vez el operador est´e instanciado y activo. El caso de uso m´as com´un es iniciar un operador. En la figura 3.14 se ilustra el funcionamiento de la aplicaci´on y la interacci´on de sus componentes a la hora de realizar esta acci´on. 3.5. SPRINT 5 - 8: OPERADORES 61 Figura 3.14: Diagrama de secuencia para la ejecuci´on de un operador 68 CAP´ ITULO 4. IMPLEMENTACI ´ ON Cuando se quiere bloquear un nodo que contenga una malla, este se copia como hijo de FixedScene y se borra como hijo de Model. El nodo Lights contiene la iluminaci´on de la escena, en este caso una ´unica luz direccional. Tambi´en contiene una malla con un gizmo para indicar su direcci´on al manipularla. Los nodos Gizmo y DirectionalLight son hijos de DirLightA para poder manipular su transformaci´on conjuntamente (figura 4.2). El nodo Scene almacena la trasformaci´on de la escena mientras se manipula usando la mano derecha sobre el Leap Motion. Una vez finalizada la transformaci´on, esta se copia al nodo Model y se restablece su posici´on inicial, haciendo que nuevas transformaciones se realicen en espacio local con las coordenadas iniciales. En el siguiente fagmento de c´odigo se actualiza la matriz de transformaci´on de nodo Scene calculando la diferencia entre las dos ´ultimas transformaciones de la mano. Scene . transform . origin = $Scene. transform . origin + ( current_hand_transform . origin - last_hand_transform . origin ); var current_rotation = Quat ( $Scene . transform . basis ) var last_hand_rotation = Quat ( last_hand_transform . basis ) var current_hand_rotation = Quat( current_hand_transform . basis ) var rotation_diference = current_hand_rotation. inverse () * last_hand_rotation var final_rotation = current_rotation * rotation_diference . inverse () $Scene . transform . basis = Basis ( final_rotation ) A continuaci´on, una vez abierta la mano y confirmada la transformaci´on, esta se aplica al nodo Model y se restablecen las bases de la matriz del nodo Scene. var scene_rotation = Quat ( $Scene . transform . basis ) var model_rotation = Quat ( $Scene / Model . transform . basis ) $Scene / Model . transform . basis = Basis ( scene_rotation * cube_rotation ) $Scene. transform .basis = Basis () Este nodo tambi´en restablece autom´aticamente su posici´on en caso de que el nodo Model no contenga ning´un hijo, de forma que cuando se a˜nade un objeto a una escena vac´ıa este se sit´ua siempre en el centro de la pantalla. Los materiales de las mallas de los objetos tambi´en se ajustan en el script de la escena haciendo que los modelos bloqueados tengan un material transparente (figura 4.3). 4.3. SPRINT 4: MEN ´ US 69 Figura 4.3: Modelo siendo editado con un ´unico objeto activo. El resto se muestran transparentes. 4.3. Sprint 4: Men´us La escena MainMenu implementa el men´u principal de la aplicaci´on desde el cual se puede acceder a la mayor parte de su funcionalidad. Su ´arbol de nodos se muestra en la figura 4.4 Las principales funciones de esta escena son las siguientes: Procesar la entrada de la mano izquierda capturada por el LeapMotion y traducirla a eventos de movimiento. Mostrar y ocultar el men´u principal en funci´on del estado de la mano izquierda. Establecer unas reglas para la distribuci´on de los widgets del men´u, proporcionando contenedores en los cuales los widgets pueden instanciarse. 4.3.1. Navegaci´on El nodo LeapAction contiene un script responsable de emitir se˜nales cada vez que detecta un movimiento significativo de la mano izquierda en el plano XY respecto a su posici´on de origen. Tambi´en es responsable de detectar cuando la mano se abre o cierra para que los men´us puedan responder adecuadamente. El nodo LeapAction emite las siguientes se˜nales: signal leap action(dir) : Se emite cuando la mano se mueve en uno de los ejes m´as de lo especificado en unos l´ımites configurables en el script. Dicha se˜nal incorpora la direcci´on en la que la mano se ha movido. signal op selection begin: Se emite cuando se cierra la mano izquierda. signal op finish: Se emite cuando se abre la mano izquierda. 70 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.4: ´ Arbol de nodos de la escena MainMenu Los nodos que heredan de la escena Menu se suscriben a estas se˜nales para determinar su comportamiento. Estas escenas son responsables de guardar la configuraci´on de cada men´u, as´ı como de informar a cada widget cuando tiene que ejecutar su acci´on establecida. El nodo LeapAction tambi´en proporciona una funci´on para obtener el porcentaje de offset respecto a la ´ultima posici´on en la que se ha emitido la se˜nal leap action. Esto sirve para que otros nodos ajusten ligeramente su posici´on, proporcionando al usuario una mejor experiencia y usabilidad. 4.3.2. Widgets El ´arbol de nodos del widget que representa cada opci´on del men´u se representa en la figura 4.5. Esta escena es la escena base para todas las opciones del men´u. Sus funciones son las siguiente: Cargar un operador que tenga asignado en el nodo Operator de la escena principal con unos par´ametros determinados. Mostrar un men´u secundario en alguno de los laterales en un contendedor asignado. Reproducir las animaciones correspondientes en la interfaz. 4.4. SPRINTS 5 - 7: OPERADORES 71 Figura 4.5: ´ Arbol de nodos de la escena MenuItem Figura 4.6: ´ Arbol de nodos de un operador Este nodo contiene gran cantidad de nodos duplicados. Dichos nodos se inician con los par´ametros correctos cuando la escena se carga. Estos nodos modulan su opacidad seg´un el offset que se obtiene del nodo LeapAction, proporcionando unas animaciones m´as suaves en la interfaz y un men´u m´as usable. 4.4. Sprints 5 - 7: Operadores El c´odigo de la gran mayor´ıa de funcionalidades del programa est´a encapsulado en operadores. En el sprint 5 se implementa el modelo necesario para poder ejecutar un operador dentro del programa, dejando los sprints 6 y 7 para implementar los operadores correspondientes a los requisitos funcionales del mismo. Todos los operadores del programa heredan de la escena operator. Por esto, todos incluyen un nodo base y un icono para mostrar en la barra de estado. En la figura 4.6 se muestra el ´arbol de nodos de la escena que implementa el operador AddSphere. La funcionalidad de este operador requiere que se incluya tambi´en un recurso de tipo Mesh para que se a˜nada a la escena. Todos los operadores tienen un script base que hereda del script operator. Proporciona los siguientes m´etodos: 72 CAP´ ITULO 4. IMPLEMENTACI ´ ON extends Node onready var viewport = get_tree () . get_root (). get_node ("Main / Viewport "); export (String) var export_params func _ready(): pass func begin ( params ): pass func update ( delta ): pass func end (): pass Las funciones begin(), update() y end() representan el ciclo de vida del operador, siendo la funci´on update() la que reemplaza a la funci´on process() que usa Godot internamente para actualizar los nodos en cada frame. Los items del men´u indican al nodo Operator de la escena principal el operador a instanciar. Esta lo instancia y llama a su m´etodo begin(params) con los par´ametros correspondientes. Una vez realizado esto, pueden ocurrir dos cosas: El operador realiza las operaciones correspondientes y finaliza, solicitando al nodo padre que llame a su funci´on end(). El operador se mantiene activo llamando en cada frame a su m´etodo update(), este finaliza cuando el padre recibe la se˜nal del nodo LeapAction y llana a su m´etodo end(), ejecutando en este las acciones necesarias para finalizar el operador satisfactoriamente. Adem´as, el nodo Operator de la escena Main es responsable de guardar el estado del viewport y a˜nadirlo como hijo al nodo UndoStack antes de llamar al m´etodo begin() de cada operador, de forma que cuando se ejecute el operador deshacer este pueda recuperar el ´ultimo estado y reemplazarlo por el contenido actual del viewport. 4.5. Sprint 8: Algoritmos de edici´on La funcionalidad de edici´on del software est´a implementada de diferentes formas seg´un el tipo de dato al que afecta (figura 4.7). Los operadores de edici´on que afectan a objetos usan m´etodos del motor para hacer estas transformaciones. Por ejemplo, el operador ScaleLocal utiliza la propiedad scale del nodo que contiene la malla para escalarla. 4.5. SPRINT 8: ALGORITMOS DE EDICI ´ ON 73 Figura 4.7: Men´u mostrando las opciones de algoritmos de edici´on de la malla Otro tipo de ediciones que requieren modificaciones en la malla han sido implementadas a parte. Para ello se ha creado el script MeshUtils, que aporta las siguientes funcionalidades: Leer y escribir una malla triangular a un archivo Obj. Extraer una lista de v´ertices y caras de un recurso tipo Mesh del motor y crear un recurso Mesh a partir de una lista de v´ertices y caras. Separar y unir listas de v´ertices y caras por componentes no conectados entre s´ı. Dicha funcionalidad est´a implementada en las siguientes funciones del script: func vertex_data_from_mesh(var mesh, var transform ): func mesh_from_vertex_data(var vertex_data): func split_vertex_data(var vertex_data): func join_vertex_data(var vertex_data_array): func obj_to_vertex_data ( var path): func vertex_data_to_obj ( var vertex_data , var path ): 4.5.1. Conversi´on entre formatos Godot almacena las mallas en un recurso interno de tipo Mesh. Este recurso est´a optimizado para guardar mallas triangulares de forma que el renderizador pueda usarlas con una implementaci´on m´as sencilla. 74 CAP´ ITULO 4. IMPLEMENTACI ´ ON Para la creaci´on del recurso Mesh a partir de una lista de v´ertices y caras Godot facilita la clase SurfaceTool. Esta permite una construcci´on de la malla similar a la API de OpenGL para el dibujado en pantalla. La clase SurfaceTool tambi´en proporciona un m´etodo para generar las normales de la malla que se est´a creando una vez finalizada. var mesh = Mesh.new () surfTool . begin ( Mesh . PRIMITIVE_TRIANGLES ) for face in faces : surfTool . add_uv ( Vector2 (0 ,0)) surfTool . add_vertex ( vertex [ face .z]) surfTool . add_uv ( Vector2 (0 ,0)) surfTool . add_vertex ( vertex [ face .y]) surfTool . add_uv ( Vector2 (0 ,0)) surfTool . add_vertex ( vertex [ face .x]) surfTool . generate_normals () surfTool . index () surfTool . commit (mesh ) Para extraer los datos sobre los v´ertices y caras almacenados en un recurso Mesh Godot proporciona la clase MeshUtils. Est´a clase no est´a correctamente documentada ya que no es com´un usarla en el desarrollo de juegos. Para conseguir la informaci´on sobre los v´ertices y caras se ha consultado la implementaci´on en C++ de la misma, descubriendo que tiene un m´etodo para extraer las coordenadas de un v´ertice dado su ´ındice y otro para extraer el ´ındice del v´ertices que forma una cara, dado su ´ındice y su posici´on. Combinando la informaci´on de estos dos m´etodos se puede conseguir reconstruir las listas de v´ertices y caras con las que se ha creado la malla. El algoritmo que se usa para reconstruir esta lista combina autom´aticamente los v´ertices dobles. Por lo tanto, cualquier edici´on que se haga sobre una malla con v´ertices dobles, estos se eliminar´an a la primera transformaci´on. A esta funci´on tambi´en se le puede pasar como argumento unas bases, de forma que los v´ertices se generen con las coordenadas correctas, como se se aplicaran las transformaciones del objeto sobre la malla. 4.5.2. Separaci´on y Uni´on La separaci´on de la malla en componentes es el proceso m´as complejo de la clase MeshUtils. Para realizarse, el programa crea una nueva lista para guardar el estado de cada v´ertice durante la ejecuci´on del algoritmo (no comprobado o asignado a determinado fragmento de la malla final). Una vez hecho esto, el programa interpreta la malla como un grafo y ejecuta un algoritmo recursivo para encontrar las componentes conexas del mismo. Para ello se utilizan las funciones get connected vertex() y set vertex status(). Una vez identificadas las componentes conexas y habiendo guardando la informaci´on sobre la componente a la que pertenece cada v´ertice en la lista de estados, dicha lista es usada para reconstruir diferentes mallas en funci´on de estos ´ındices. 4.5. SPRINT 8: ALGORITMOS DE EDICI ´ ON 75 Este proceso puede causar p´erdida de frames en la visualizaci´on del viewport ya que la m´aquina de bytecodes en la que se ejecuta el c´odigo de GDSCript no est´a optimizada para el uso de funciones recursivas (la llamada a una funci´on de GDScrit es el proceso que m´as penaliza al movimiento del motor). Si llegado a un punto este rendimiento no es suficiente el programa puede actualizarse ejecutando el mismo algoritmo en C# o C++, codific´andolo de nuevo y siguiendo los pasos explicados en el apartado anterior. La uni´on es un proceso directo, simplemente se concatenan las listas de v´ertices y caras: var final_vertex = [] var final_faces = [] var offset = 0 for vertex_data in vertex_data_array: for vertex in vertex_data . vertex : final_vertex . append ( vertex ) for face in vertex_data . faces : final_faces . append ( Vector3(face.x + offset , face .y + offset , face .z + offset )) offset += vertex_data . vertex . size () return {"vertex": final_vertex , " faces ":final_faces} 4.5.3. Lectura y escritura La lectura y escritura del programa se hace en formato .obj. Se ha elegido este formato porque es una representaci´on directa de la estructura de lista de v´ertices y de caras que se usa en el resto del programa para tratar con los datos de una malla. La lectura y escritura de datos en formato .obj es trivial, simplemente se escribe o lee linea a linea el contenido del archivo siguiendo los contenidos de las listas, ayud´andose de la API de Godot para la lectura y escritura de archivos: file . open (path , File . WRITE ) for v in final_vertex: file . store_line ("v"+ str (v.x) + ""+ str(v.y) + ""+ str(v.z)) for f in final_faces: file . store_line ("f"+ str (f.x+1) + "// " + str(f.y +1) + " // " + str (f.z+1) + "//") file . close () En el formato .obj, los v´ertices se preceden con una ”v 2 las caras con una ”f”. No se incluyen las normales de los v´ertices ya que la mayor´ıa de programas 3D son capaces de recalcularlas a la hora de importar un archivo, pero su inclusi´on ser´ıa trivial. El ´ındice de los v´ertices se incrementa en 1 ya en en el formato .obj las listas empiezan en 1, no en 0. 76 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.8: ´ Arbol de nodos de la escena StatusBar 4.6. Sprint 9: Barra de estado En el ´ultimo sprint se implementa la barra de estado del programa. La barra de estado representa el operador que se est´a ejecutando y el estado del LeapMotion. Su ´arbol de nodos se representa en la figura 4.8. Esta escena contiene un script que oculta o muestra sprites en funci´on del estado que obtenga de la clase Leap y del operador instanciado como hijo del nodo Operator de la escena Main. Tambi´en puede instanciar mensajes de error o informaci´on para el usuario como hijos del nodo HUD, situ´andose estos en la esquina inferior derecha de la pantalla. Cap´ıtulo 5 Pruebas En este cap´ıtulo se documentan las pruebas que se han realizado para comprobar el estado de la aplicaci´on a lo largo de su desarrollo, as´ı como las pruebas finales usadas para verificar que la aplicaci´on cumple con los requisitos establecidos en el an´alisis del proyecto. Las pruebas se han ido dise˜nando para evaluar el desempe˜no del trabajo en cada sprint, por lo que las comprobaciones son incrementales. Contents 5.0.1. Pruebas de sprints . . . . . . . . . . . . . . . . . . . . 78 5.0.2. Pruebas finales . . . . . . . . . . . . . . . . . . . . . . 83 5.0.3. Estudio de usabilidad . . . . . . . . . . . . . . . . . . 86 77 84 CAP´ ITULO 5. PRUEBAS Prueba 25 Nombre: ´ Unico usuario Descripci´on: La aplicaci´on deber´a ser dise˜nada para ser usada por un ´unico usuario. Requisitos involucrados: RN5 Validaci´on: La aplicaci´on no contiene ninguna funcionalidad para soportar roles o m´ultiples usuarios. Estado: Completado Prueba 26 Nombre: Usable con Leap Motion Descripci´on: La aplicaci´on deber´a ser usable mediante un sensor Leap Motion. Requisitos involucrados: RN6 Validaci´on: Se pueden comprobar todos los requisitos funcionales usando solamente el sensor Leap Motion, sin usar rat´on o teclado. Estado: Completado Prueba 27 Nombre: Iconos para las opciones del men´u Descripci´on: Se dise˜nar´an iconos para los men´us de la aplicaci´on de forma que su usabilidad aumente. Requisitos involucrados: RN7 Validaci´on: Todas las opciones del men´u tienen una representaci´on en forma de icono. Estado: Completado Prueba 28 Nombre: Ingl´es Descripci´on: La aplicaci´on tendr´a su interfaz en ingl´es. Requisitos involucrados: RN8 Validaci´on: Todas las opciones del men´u tienen sus descripciones en ingl´es. Estado: Completado Prueba 29 Nombre: Interfaz no dependiente del color Descripci´on: La aplicaci´on no depender´a del color para distinguir funcionalidades o transmitir informaci´on al usuario. Esto har´a el software m´as accesible. Requisitos involucrados: RN9 Validaci´on: El programa debe ser usable y no presentar opciones ambiguas tras aplicar un filtro de blanco y negro al monitor en el que se est´a usando. Estado: Completado 85 Prueba 30 Nombre: Carga de mallas Descripci´on: La aplicaci´on deber´a ser capaz de visualizar mallas de alta densidad. Requisitos involucrados: RN10 Validaci´on: El programa tarda como m´aximo 20 segundos en cargar una malla en .OBJ de con un mill´on de v´ercites y mostrarla en pantalla en un ordenador con un i7 6700, una GTX 1080 y un SSD Samsung EVO Pro. El programa consigue importar el .OBJ en 14 segundos. Estado: Completado Prueba 31 Nombre: 60 frames por segundo en el viewport Descripci´on: La aplicaci´on deber´a tener una tasa de frames estable para facilitar su uso. Requisitos involucrados: RN11 Validaci´on: El programa es capaz de mantener 60 frames por segundo con una malla de 50k v´ertices en el viewport con una ´unica luz direccional sin sombras en un ordenador con un i7 6700, una GTX 1080 y un SSD Samsung EVO Pro. Se usa el profiler de Godot y se obtiene una media de 220fps en una GTX 1080. Estado: Completado Prueba 32 Nombre: Separaci´on de mallas Descripci´on: El rendimiento a la hora de separar una malla en sus componentes deber´a ser el adecuado. Requisitos involucrados: RN12 Validaci´on: El programa es capaz de partir en sus componentes la malla de Suzane por defecto que incorpora Blender exportada como malla triangular y 2 niveles de subdivisi´on en un ordenador con un i7 6700, una GTX 1080 y un SSD Samsung EVO Pro en menos de 2 segundos. El programa consigue realizar dicha operaci´on en 0.3 segundos seg´un el profiler de Godot. Estado: Completado Prueba 33 Nombre: Software libre Descripci´on: Se usar´a software libre en la medida de lo posible para realizar el proyecto. Requisitos involucrados: RN13 Validaci´on: Todos los componentes usados en el desarrollo del producto son compatibles con la licencia MIT. El ´unico componente no compatible es el SDK de Leap Motion, pero este no se distribuir´a con el proyecto. Estado: Completado 86 CAP´ ITULO 5. PRUEBAS 5.0.3. Estudio de usabilidad Una vez finalizada la aplicaci´on se han hecho pruebas con diferentes usuarios para valorar su usabilidad. La aplicaci´on se ha probado con 5 personas diferentes, todas ellas sin experiencia previa en el uso del Leap Motion. Observando su comportamiento a la hora de interactuar con la aplicaci´on y los comentarios posteriores, se ha llegado a las siguientes conclusiones: Los movimientos de la mano no son completamente naturales, ya que los usuarios han necesitado un periodo de adaptaci´on hasta poder controlar correctamente la aplicaci´on. Esto es debido a la precisi´on del propio sensor y a sus algoritmos de reconocimiento de imagen. Los usuarios est´an conformes con la calidad de los gr´aficos y dise˜no del programa. Algunas acciones se necesitan alg´un tipo de atajo. Algunos usuarios notan que acciones t´ıpicas de un entorno 3D, como girar un objeto 180 grados, son muy lentas con este sistema. Tambi´en se ha llevado a cabo un estudio formal sobre la usabilidad del software, basado en los principios heur´ısticos de Nielsen: Visibilidad de estado del sistema: el sistema cuenta con una barra de estado para comprobar el operador que se est´a ejecutando en cada momento, as´ı como el estado del sensor y las manos. Utilizar el lenguaje de los usuarios: el programa usa t´erminos comunes a muchos otros softwares de edici´on 3D, por lo que cualquier persona familiarizada con los mismo no deber´ıa tener problema al usarlo. Control y libertad para el usuario: Todas las acciones del sistema pueden cancelarse en cualquier momento abriendo la mano. Adem´as, el sistema cuenta con un operador para deshacer el ´ultimo cambio realizado. Consistencia y est´andares: Los iconos de la aplicaci´on son consistentes con lo que representan y solo tienen un uso dentro de la aplicaci´on. El lenguaje de los men´us es adecuado para una aplicaci´on de este tipo. Prevenci´on de errores: El sistema no puede entrar en un estado de error. De todas formas, todos los cambios realizados pueden deshacerse y el viewport puede devolverse a su posici´on inicial en cualquier momento. Memorizar la carga de memoria: Los objetos cambia de material seg´un su estado para evitar comprobar las listas de objetos seleccionados. Flexibilidad y eficiencia de uso: Los movimientos requeridos para activar las opciones del men´u son siempre los mismos por lo que un usuario avanzado puede acceder a dichas opciones de forma r´apida sin tener que leer todos el men´u. 87 Est´etica y dise˜no minimalista: La aplicaci´on muestra los objetos de la escena de la forma m´as limpia posible, sin ning´un tipo de elemento que distraiga o impida su correcta visualizaci´on. Ayudar a reconocer y recuperarse de errores: Se informa al usuario cuando el sensor no est´a conectado o no reconoce bien las manos. Adem´as, ning´un cambio en el programa es permanente ya que se puede deshacer. Ayuda y documentaci´on: El software incluye documentaci´on. Los operadores son suficientemente intuitivos y responden al movimiento para que el usuario pueda entenderlos nada m´as ejecutarlos. 88 CAP´ ITULO 5. PRUEBAS Cap´ıtulo 6 Conclusiones y posibles ampliaciones En este cap´ıtulo se recogen las conclusiones del desarrollo del proyecto y se enumera una serie de ampliaciones que se le podr´ıan a˜nadir al software en un futuro. Contents 6.1. Conclusiones ........................ 91 6.2. Ampliaciones ........................ 93 89 90 CAP´ ITULO 6. CONCLUSIONES Y POSIBLES AMPLIACIONES 6.1. CONCLUSIONES 91 6.1. Conclusiones En este apartado se recogen las conclusiones del desarrollo del proyecto. El resultado del proyecto es un producto software que permite la interacci´on y edici´on con modelos en 3D mediante el uso del Leap Motion, as´ı como su memoria y documentaci´on asociada. Para ello, se ha realizado un an´alisis de requisitos y una gesti´on del proyecto. Tambi´en se ha llevado a cabo un an´alisis para determinar la tecnolog´ıa m´as adecuada para desarrollarlo, en este caso Godot Engine 3. Posteriormente se han analizado diversas aplicaciones de edici´on 3D, extrayendo conclusiones sobre sus similitudes y diferencias para poder afrontar el dise˜no de la interfaz de este software con la mayor informaci´on posible. Tambi´en se han dise˜nados los paradigmas adaptados al uso del Leap Motion para facilitar la interacci´on con el mismo. El proyecto se ha implementado en Godot Engine 3, siendo necesaria la inclusi´on de una biblioteca de GDNative para permitir el uso del Leap Motion dentro del motor. Una vez resuelto el problema de compatibilidad mediante el uso de dicha biblioteca se ha desarrollado la aplicaci´on en GDScript, adaptado su estructura al funcionamiento de Godot. Esto permitir´a que la aplicaci´on sea f´acilmente ampliable en el futuro. Para llevarlo a cabo se ha usado la metodolog´ıa scrum, en la que se han ido cumpliendo los requisitos del proyecto de forma progresiva en diferentes sprints hasta llegar al producto final. En la tabla 6.1 se muestran como las pruebas dise˜nadas durante el proyecto cubren los requisitos del mismo: 92 CAP´ ITULO 6. CONCLUSIONES Y POSIBLES AMPLIACIONES Cuadro 6.1: Matriz de trazabilidad: Requisitos funcionales y pruebas P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18 P19 P20 RF1 X X RF2 X X RF3 X X RF4 X X RF5 X X RF6 X RF7 X X RF8 X RF9 X RF10 X X X RF11 X RF12 X X X RF13 X RF14 X X RF15 X X RF16 X RF17 X X RF18 X X 6.2. AMPLIACIONES 93 6.2. Ampliaciones En este apartado se citan una serie de ampliaciones que se le podr´an a˜nadir al software. El software actualmente permite la visualizaci´on de modelos y la edici´on sencilla de los mismos, as´ı como a˜nadir objetos r´apidamente y modificarlos para probar composiciones o vol´umenes. Su arquitectura hace que se puedan a˜nadir nuevas funcionalidades muy f´acilmente con solo programar m´as operadores. Adem´as, se puede mejorar su rendimiento pasando partes del c´odigo de la aplicaci´on de GDNative a C++. Entre otras, al programa final se le podr´ıan a˜nadir las siguientes caracter´ısticas: Operador de escalado global para permitir escalar todos los elementos a la escena a la vez sin necesidad de combinar sus mallas. Operadores booleanos para permitir obtener la uni´on o intersecci´on de dos mallas Permitir ocultar o mostrar objetos Permitir acceder a una biblioteca de mallas primitivas para la creaci´on de modelos en lugar de los operadores de a˜nadir malla disponibles actualmente Como conclusi´on, es un software b´asico pero que permite visualizar e interactuar con los modelos mediante el Leap Motion de forma correcta y satisfactoria, pero sin funcionalidades de edici´on avanzadas que necesitan una herramienta de control de precisi´on para poder realizarse con ´exito. 100 AP´ ENDICE B. MANUAL DE USUARIO Figura B.1: Interfaz del programa Moverse por los men´us: 1. Colocar la mano izquierda abierta sobre el sensor 2. Cerrar levemente la mano izquierda hasta que el men´u principal aparezca 3. Desplazar la mano izquierda cerrada hacia arriba o hacia abajo para moverse por las opciones del men´u 4. Desplazar la mano izquierda hacia la derecha o hacia la izquierda para seleccionar la opci´on correspondiente dentro del men´u 5. Abrir la mano izquierda para cancelar la operaci´on. Importar Modelo: 1. Colocar el modelo en formato obj en la carpeta Models del programa 2. Dentro del programa, seleccionar el modelo correspondiente en el desplegable que aparece al seleccionar la opci´on Import del men´u principal Exportar Modelo: 1. Dentro del programa, seleccionar la opci´on Export del men´u principal. El modelo se exportar´a a la carpeta Models. Seleccionar y deseleccionar objeto 1. En el men´u principal, seleccionar el objeto deseado bajo la opci´on Select Object 2. Para anular la selecci´on, usar la opci´on Select All dentro del mismo men´u Escalar Objeto B.2. ACCIONES 101 1. Seleccionar la opci´on Transform/Scale Local del men´u principal 2. Sin abrir la mano izquierda, cerrar la mano derecha 3. Juntar o separar ambas manos 4. Abrir la mano izquierda para confirmar la operaci´on A˜nadir Objeto 1. Seleccionar la opci´on Add Object del men´u 2. En el men´u que de despliega seleccionar el objeto deseado 3. Sin abrir la mano izquierda, posicionar el objeto en la escena 4. Abrir la mano izquierda una vez el objeto se encuentre en la posici´on deseada Eliminar Objeto 1. Seleccionar la opci´on Add Object del men´u 2. En el men´u que de despliega seleccionar el objeto deseado 3. Sin abrir la mano izquierda, posicionar el objeto en la escena 4. Abrir la mano izquierda una vez el objeto se encuentre en la posici´on deseada Separar Objetos 1. Seleccionar la opci´on Edit Mesh/Split del men´u 2. Los objetos seleccionados se separar´an Unir Objetos 1. Seleccionar la opci´on Edit Mesh/Merge del men´u 2. Todos los objetos de la escena se juntar´an en un ´unico objeto Restaurar vista 1. Seleccionar la opci´on Scene Options/Reset viewport del men´u 2. La escena volver´a al centro de la pantalla 102 AP´ ENDICE B. MANUAL DE USUARIO B.3. Soluci´on a problemas comunes Aparece un error en pantalla y no aparecen los iconos de las manos en la barra de estado Asegurarse de que el sensor est´e conectado al equipo Comprobar que la versi´on instalada del diver de Leap Motion es la versi´on 2.0 Comprobar que el hilo del sensor Leap Motion se est´a ejecutando en el equipo. En caso contrario ejecutar el comando leapd El movimiento es poco preciso Limpiar la parte superior del sensor Apagar todas las fuentes de luz que se encuentren directamente encima del sensor La malla no se importa correctamente Probar a exportar el modelo en una escala diferente Comprobar que la malla es una malla triangular, no puede contener otro tipo de pol´ıgonos para que el programa la interprete correctamente. Ap´endice C Licencia Copyright (c) 2018 Pablo Dobarro Pe˜na Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ”Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED .AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 103 104 AP´ ENDICE C. LICENCIA Bibliograf´ıa La bibliograf´ıa citada a continuaci´on es de car´acter general. [1] Leap Motion SDK (https://developer.leapmotion.com/documentation). [2] Unity C# API (https://docs.unity3d.com/ScriptReference). [3] Blender developer portal (https://wiki.blender.org/index.php/Main Page). [4] Godot 3.0 documentation (https://docs.godotengine.org/en/latest). [5] Mischa Spiegelmock, Leap Motion Development Essentials, Packt Publishing, 2013. [6] HTC Vive (https://www.vive.com/us/). [7] TiltBrush (https://www.tiltbrush.com/). [8] Leap Motion (https://www.leapmotion.com/) visitada el 3 de febrero de 2018. [9] Project Orion (https://developer.leapmotion.com/orion/) visitada el 2 de febrero de 2018. [10] Leap Motion Rig in Three.js (http://blog.leapmotion.com/manipulating-riggedhand-with-leap-motion-in-three-js/) visitada el 2 de febrero de 2018. [11] How to build a Leap Motion education app (http://blog.leapmotion.com/buildworld-class-education-app/) visitada el 2 de febrero de 2018. [12] 5 Medical and Assistive Technologies Being Transformed with Leap Motion(http://blog.leapmotion.com/5-medical-and-assistive-technologies-beingtransformed-with-leap-motion-tech/) visitada el 2 de febrero de 2018. [13] Changing How People Look at Physical Therapy(http://blog.leapmotion.com/changingpeople-look-physical-therapy/) visitada el 2 de febrero de 2018. 105 106 BIBLIOGRAF´ IA