Prototipado de aplicaciones de realidad virtual

Texto completo

(1)Prototipado de aplicaciones de realidad virtual. Trabajo de Tesis presentado al Departamento de Ingeniería de Sistemas y Computación por. Christian Orlando Benavides Asesor: Pablo Figueroa. Para optar al título de Magíster en Ingeniería de Sistemas y Computación. Ingeniería de Sistemas y Computación Universidad de Los Andes Enero 2011.

(2) Prototipado de aplicaciones de realidad virtual. Aprobado por:. Pablo Figueroa, Asesor. Fecha de Aprobación.

(3) A mi familia por haberme apoyado todos estos años.. iii.

(4) Reconocimientos Agradezco a mis padres por su apoyo que ha sido motivación para alcanzar este logro. Además agradezco a mi asesor Pablo Figueroa por haber apoyado esta idea de trabajo y de su constante retroalimentación alrededor del proceso. Además hablo en general a todo el grupo IMAGINE por haberme abierto los puertas y ayudarme a creer que esta mata era posible.. iv.

(5) Tabla de Contenido Dedicatoria. iii. Reconocimientos. iv. Lista de Tablas. vi. Lista de Figuras. vii. Resumen. viii. I. Introducción. 1. II. Trabajo Previo. 3. 2.1.. Herramientas de visualización temprana (sketching). . . . . . . . . .. 3. 2.2.. Prototipado rápido. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. III. Metodología. 8. IV. Estrategias de apoyo al desarrollador. 10. 4.1.. Estrategias de apoyo al diseñador. . . . . . . . . . . . . . . . . . . .. 12. 4.2.. Estrategias de apoyo al programador . . . . . . . . . . . . . . . . . .. 14. V. Herramientas de apoyo al diseñador 5.1.. 16. Mecanismo de soporte al diseñador . . . . . . . . . . . . . . . . . . .. 17. 5.1.1.. Línea de tiempo . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 5.1.2.. Herramientas de representación . . . . . . . . . . . . . . . . .. 21. 5.1.3.. Herramientas de manipulación del entorno. 23. . . . . . . . . . .. VI. Framework InTml 6.1.. 25. DSL InTml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. v. 25.

(6) 6.2.. Generación de código a partir del DSL InTml . . . . . . . . . . . . .. 27. 6.3.. Implementación en ActionScript 3. . . . . . . . . . . . . . . . . . . .. 28. VII.Arquitectura soporte a dispositivos. 36. 7.1.. La librería de dispositivos . . . . . . . . . . . . . . . . . . . . . . . .. 36. 7.2.. Arquitectura de comunicación. 38. . . . . . . . . . . . . . . . . . . . . .. VIII.Herramientas de apoyo al programador. 42. 8.1.. Simulación de dispositivos . . . . . . . . . . . . . . . . . . . . . . . .. 42. 8.2.. Grabado y reproducción de eventos. 45. . . . . . . . . . . . . . . . . . .. IX. Análisis 9.1.. 51. Herramienta de visualización previa. . . . . . . . . . . . . . . . . . .. 51. 9.1.1.. Escenario de prueba . . . . . . . . . . . . . . . . . . . . . . .. 51. 9.1.2.. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. 9.1.3.. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. 9.2.. Prototipado rápido. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 9.3.. Otras herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56. X. Conclusiones. 62. vi.

(7) Lista de Tablas 1.. Características del prototipado rápido . . . . . . . . . . . . . . . . . .. 2.. Características apoyo al desarrollo. 3.. Características de interfaz. 5. . . . . . . . . . . . . . . . . . . .. 54. . . . . . . . . . . . . . . . . . . . . . . . .. 54. 4.. Características del prototipado rápido . . . . . . . . . . . . . . . . . .. 57. 5.. Características del prototipado rápido(Continuación). . . . . . . . . .. 58. 6.. Atributos de calidad. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. 7.. SourceBinder versus InTml [31]+ herramientas prototipado rápido . .. 60. 8.. Virtool versus InTml [31]+ herramientas prototipado rápido. 61. vii. . . . . ..

(8) Lista de Figuras 1.. Proceso de implementación de mecanismos de prototipado. . . . . . .. 2.. Modelo de interacción entre el programador y el diseñador aplicacio-. 8. nes 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 3.. Características de interacción en un conjunto de 31 aplicaciones. . . .. 14. 4.. Herramientas para el diseñador. . . . . . . . . . . . . . . . . . . . . .. 18. 5.. Aplicación para el diseñador . . . . . . . . . . . . . . . . . . . . . . .. 19. 6.. Arquitectura de línea de tiempo. . . . . . . . . . . . . . . . . . . . .. 19. 7.. Línea de tiempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 8.. Retroalimentación de dispositivos al diseñador. 9.. Herramientas de representación. 10.. Herramientas de construcción de un mundo virtual. 11.. Retroalimentación de dispositivos al diseñador. . . . . . . . . . . . .. 21. . . . . . . . . . . . . . . . . . . . . .. 21. . . . . . . . . . .. 22. . . . . . . . . . . . .. 24. 12.. Ejemplo de prototipo en InTml. . . . . . . . . . . . . . . . . . . . . .. 26. 13.. Estructura del patrón DeviceObjectBehavior en ActionScript 3.. . . .. 30. 14.. Estructura del patrón InTmlDataow en ActionScript 3.. . . . . . . .. 31. 15.. Estructura del patrón ComponentHolder en ActionScript 3. . . . . . .. 32. 16.. Arquitectura de paquetes de InTml [31]para ActionScript 3.. . . . . .. 32. 17.. Ejemplo de ltro de comportamiento en InTml.. . . . . . . . . . . . .. 34. 18.. Denición de un dispositivo Gamepad y un Joystick.. . . . . . . . . .. 37. 19.. Denición de un dispositivo WiiMote y un SpaceMouse. . . . . . . . .. 37. 20.. Denición de un dispositivo Phantom y un Tracker. . . . . . . . . . .. 38. 21.. Arquitectura para comunicación . . . . . . . . . . . . . . . . . . . . .. 40. viii.

(9) 22.. Wizard de InTml. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41. 23.. Vista de ujo de información para InTml . . . . . . . . . . . . . . . .. 43. 24.. Arquitectura InTml [31]+ Servidor de Dispositivos. 44. 25.. . . . . . . . . . .. Flujo de información para InTml [31]soportado por un servidor de contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 26.. Arquitectura de grabado de eventos . . . . . . . . . . . . . . . . . . .. 46. 27.. Ejemplo del comportamiento de grabado. . . . . . . . . . . . . . . . .. 47. 28.. Conguración del grabado dispositivos. . . . . . . . . . . . . . . . . .. 48. 29.. Ejemplo de un simulado de dispositivo. . . . . . . . . . . . . . . . . .. 50. 30.. Formato de evaluación de herramienta de visualización temprana. . .. 53. 31.. Datos estadísticos de encuesta de ambiente de visualización temprana. 54. ix.

(10) Resumen. Este trabajo muestra la implementación de mecanismos que apoyan el desarrollo de una aplicación de realidad virtual, vista desde la perspectiva de un desarrollador que usualmente cuenta con el rol de un diseñador y un programador de aplicaciones. Es así que, por una parte se muestra como apoyar el trabajo del diseñador de aplicaciones a través de una herramienta de visualización temprana basada en características del entorno, proponiendo un mecanismo para tomar decisiones de arquitectura o de diseño que eviten riesgos antes del desarrollo, ayudando así a los procesos de prototipado rápido. Por otra parte, para el programador de aplicaciones se muestra el uso de InTml, un lenguaje para la denición de aplicaciones de realidad virtual, del cual se provee integración con ActionScript 3, buscando ventajas al prototipado rápido de aplicaciones interactivas 3D, apoyándose en una robusta arquitectura de comunicación que se compone de un mecanismo transparente de manipulación de dispositivos físicos y acceso eciente a la información, además se unen herramientas sobre los eventos producto de interacción que hacen portable el trabajo fuera del entorno de los dispositivos. Finalmente, se presentan detalles de la implementación y evaluación frente a usuarios de la propuesta planteada.. x.

(11) Capítulo I Introducción Cada vez más la tecnología va dirigida a brindar servicios interactivos en 3D que van desde la manipulación directa con el mouse hasta el manejo de grandes y complejas representaciones de información en los mundos virtuales, tratando de envolver a una comunidad consumista del mundo virtual, que busca enseñanza, ayuda o entretenimiento y distribuye su modo de operación en aplicaciones convencionales para computador o recorriendo la red internet. Teniendo en cuenta esto se denota un auge y demanda de información interactiva 3D [47] en aplicaciones tanto stand-alone como para la web, donde prestar más servicios interactivos es el reto de los desarrolladores que modelan este tipo de información, para los cuales el concepto de tiempo y satisfacción en el usuario nal es determinante ya que diferencia su competitividad en el mercado. En consecuencia, el entorno del desarrollador de aplicaciones interactivas 3D se ve enfrentado a mayor productividad en tiempos considerablemente pequeños y en el caso empresarial a tratar de aprovechar las ventajas de los integrantes involucrados en el proceso de desarrollo. Es por ello, que se requiere de mecanismos que soporten el proceso rápido de desarrollo de aplicaciones interactivas 3D y de herramientas que permitan un canal de comunicación entre los roles que representan el desarrollo, donde sea posible tener en cuenta todos los elementos que inuye en el entorno, por ejemplo, el soporte a usuarios no experimentados o el soporte a dispositivos. Por lo tanto, con base en las características del problema planteado se encuentra por una parte la aproximación a procesos de visualización temprana (Sketching). 1.

(12) como una herramienta soporte a los procesos de comunicación que permite una denición a alto nivel de los requerimientos de la aplicación. Y por otra parte, se encuentra las herramientas de apoyo al desarrollador que permiten facilidades de uso y ahorro en tiempo en el proceso de implementación, como es el caso de InTml [31] (Interaction Techniques Markup Language) un framework que a través de su DSL gráco (lenguaje de dominio especico) permite denir modularmente la forma de interacción con la información 3D (dispositivos, objetos y comportamientos) permitiendo una arquitectura adaptable, rápida y bien denida que mejora considerablemente los tiempos de desarrollo. Estas características permiten oportunidades de integración de mecanismos que colaboran ecientemente al trabajo sobre la información 3D. Es así, que frente a estas características nace el propósito de este trabajo, que aprovechando la visualización temprana y el concepto de InTml [31] se intenta ofrecer un conjunto de mecanismos independientes del lenguaje que posibiliten la arquitectura rápida de una idea de desarrollo, basándose primordialmente en herramientas de fácil uso a un alto nivel, que permitan la separación de roles en la metodología de desarrollo. Por último, gracias a que InTml [31] permite la traducción de su especicación a lenguajes de propósito general orientados a objetos, se logra potencializar algunas de las características frente al desarrollo. Es así que complementado esta característica nace como un segundo producto de este trabajo la propuesta de utilizar Flash con ActionScript 3 [5] tecnología de multimedia actualmente escrita y distribuida por Adobe Systems [40] que a través de sus motores 3D como Papervision. [7] [4],. Away3D [12] [13] o Alternativa3D [8] se posibilita satisfactoriamente la gestión de la información 3D, además unido a su modelo eciente de proxy, la integración con WebGL [47] y su visualizador Flash Player casi tan común en cualquier plataforma lo hacen ideal como una estrategia de desarrollo que soporta las necesidades actuales de presentación de información.. 2.

(13) Capítulo II Trabajo Previo El prototipado de aplicaciones de realidad virtual se centra en el apoyo de herramientas para el desarrollador de aplicaciones y de mecanismos de canales de comunicación entre los roles que representan el desarrollo. Por ello, a continuación se muestra un estado del arte enfocado en estas dos vías.. 2.1.. Herramientas de visualización temprana (sketching). Comúnmente la interacción de los roles del desarrollador de una aplicación de realidad virtual implica la tarea de comunicar requerimientos y objetivos previa ejecución de los prototipos, para ello se deben buscar mecanismos que establezcan canales de comunicación entre los participantes, es así que actualmente se han implementado mecanismos de previsualización que ayudan a la concepción de ideas, al modelaje rápido y a la comprensión en un alto nivel. Este tipo de herramientas son comúnmente empleadas en el mundo de los videojuegos haciendo énfasis en la previsualización de bocetos (game sketching), los cuales permiten que con un esfuerzo mínimo a alto nivel se dé el descubrimiento de reglas, establecer los estados de los usuarios (jugadores) y principalmente la eliminación de costos innecesarios del desarrollo, es así que aparecen herramientas como BIPED [51] que tras la organización visual de componentes evento se logre denir alrededor de ellos las reglas que permiten la transición a componentes estado, lo cual permite una visualización de los posibles caminos dentro del juego. Durante su ejecución el sistema realiza diferentes cuestionamientos que le permiten dar al usuario una aproximación al comportamiento a partir de un estado base, siendo la. 3.

(14) desventaja de este sistema la falta de escenarios reales de prueba en el tiempo, unido a la falta de mayores instrumentos grácos que apoyen la visualización. Otra herramienta importante de resaltar es sketch-it-up [41] la cual permite la previsualización de escenarios de juego, que basados en una construcción previa con objetos grácos de fácil interacción sobre la pantalla se puede crear un mundo virtual compartido por los desarrolladores. Su modelo de ejecución permite a varios usuarios tomar un rol denido basado en un objeto del escenario e interactuar en un caso de juego, por medio del teclado o el mouse, con los demás participantes que conforman la idea de desarrollo logrando de esta forma la denición de reglas y los estados posibles de los usuarios. Su desventaja consiste en la falta de herramientas que posibiliten la representación de tareas comunes como es el caso de la interpolación de movimiento, además no queda un registro de los eventos realizados que permitan una retroalimentación o redenición futura. Ahora bien, es importante reconocer las nuevas propuestas de prototipado de aplicaciones de realidad virtual delimitadas por tecnologías como Flash, sobre las cuales toman popularidad los motores 3D de Papervision [4] o Away3D [13], que a través de sus herramientas como Prefab3D [10] y VizualPV3D [9] respectivamente, caracterizan sobre una base de modelos 3D, animación basada en línea de tiempo que unida a deniciones básicas de abstracción del mundo virtual se puede generar un prototipo previo de un mundo virtual deseado. Aparece con las mismas características anteriores, los entornos de previsualización comerciales como swift 3D [50] que tras implementar versiones más recientes de Papervision [4] logra una clara denición de estrategias y facilidades de entendimiento al desarrollador, que nalmente tras características de alta calidad con muy bajos recursos se vuelve ideal en el mercado. Todas estas propuestas nales proveen ventajas para la arquitectura de una aplicación generando al mismo tiempo bases al programador, pero aun así, se presentan problemas de interoperabilidad o portabilidad y en situaciones cuando se requiere más información del entorno se quedan cortas.. 4.

(15) 2.2.. Prototipado rápido. A través del tiempo la propuesta de prototipado rápido es una meta que trata de cautivar al desarrollador de aplicaciones, brindándole mecanismos que gestionen el proceso y permitan una muy buena separación y comunicación de los roles que sostienen la metodología de desarrollo, esta meta soportada en el entono de las aplicaciones de realidad virtual debe cubrir en el desarrollador la necesidad de nuevas aplicaciones que conlleven a modelos de interacción 3D tanto stand-alone como en la web. Esta iniciativa de prototipado especialmente para las aplicaciones de realidad virtual a llevado a la propuesta de características básicas que se han ido complementado en el tiempo y dejan un marco de referencia válido para la construcción de las mismas, así como se puede ver en el tabla 1 basado en el resumen de denición de Bowman [18]. Tabla 1: Características del prototipado rápido. Mecanismo. Descripción. Aplicación y denición para un dominio general.. Debe tener una aplicación que permita la denición de componentes abstractos y reusables del mundo 3D.. Generalidad de tareas.. Debe contener un conjunto de componentes predenidos que permita ocultar la complejidad al usuario nal.. Generalidad de dispositivos.. Se debe proveer de mecanismos para interactuar con múltiples dispositivos de entrada de una manera fácil.. Generalidad para el usuario desarrollador.. Se debe proveer de herramientas que no necesiten de un desarrollador experimentado.. Es así que han ido apareciendo iniciativas y recursos que buscan satisfacer fácilmente las necesitadas actuales frente a la manipulación de la información 3D, de. 5.

(16) esta forma es que aparecen desarrollos anteriores pero similares a InTml[31] (base de la propuesta de este documento) como Contigra [25] un modelo de arquitectura para el desarrollo de aplicaciones 3D que abstrae en componentes las principales características del mundo virtual para nalmente representarlas en estándar X3D [27] (Extensible 3D), su losofía al igual que InTml [31] se basa en reunir atributos de calidad de software que unido a una especicación del problema y una plataforma especica, se garantiza la reutilización de componentes, pero no soluciona los problemas de escalabilidad producto de x3D [27], la interacción con dispositivos, la curva de aprendizaje alta ni la falta de división de roles. Paul Holleis et al [38] con la idea de losofía de Contigra [25] y considerando algunos de los problemas denotados anteriormente propone un modelo de desarrollo de aplicaciones 2D o 3D bajo las ventajas de la tecnología Flash y ActionScript 2, para lo cual construye componentes Flash congurables clasicados en tipos objeto que abstraen las características de los MovieClip y componentes tipo dispositivo que gracias a una arquitectura cliente-servidor por XMLSocket [46] se abstrae y oculta la complejidad de conexión con dispositivos de entrada congurados sobre el servidor; más adelante Katarína áková [42] y Janina Garrigós Sabaté [33] mejoran la comunicación cliente-servidor soportándola sobre DTD y Regina Bernhaupt [16] propone algunas deniciones de dispositivos estándar. Consecuentemente para esta metodología cada objeto puede instanciar un dispositivo o compartirlo con otros, dando así ventajas en interacción de información, una cierta disminución en complejidad y algunas opciones para el diseñador (características que serán tomadas para el desarrollo este trabajo), pero por otro lado, cabe destacar la desventaja de intervención de programadores experimentados al momento de manipular las variables y los tipos de objetos dispuestos por los componentes esto unido a las carencias de extensibilidad y grandes fallas en escalabilidad representadas en la adaptabilidad a los diferentes entornos virtuales. Ya en el mundo comercial nos encontramos con herramientas como SourceBinder [43] un soporte al prototipado rápido más cercano a InTml su funcionalidad basada en el desarrollo de aplicaciones de realidad virtual no complejas para las plataformas stand-alone o web, brinda un modelo de programación en dataow y un. 6.

(17) modelo de vista en tiempo real que unido a un conjunto de librerías de componentes reusables logran representar sin uso de código los principales componentes de interacción de una aplicación. Entre sus características importantes están sus facilidades de uso a alto nivel, portabilidad y en cierta medida la supresión del programador haciendo del desarrollo más rápido y soportable, pero esto limita la implementación de aplicaciones complejas o robustas, unido a la falta visible de interacción con dispositivos y la imposibilidad de realización de escenarios de prueba. VirTools [56] es otra herramienta de prototipado rápido similar SourceBinder [43] pero más robusta en librerías y en la denición de interacciones, ya que su modelo dataow permite que por medio de la implementación de subcomponentes se denan las operaciones, además posibilita la exportación fácil a múltiples formatos automáticamente y la integración y denición de múltiples dispositivos. Pero es aquí donde las ventajas se conviertan en desventajas para el desarrollador, ya que además del alto costo se mantiene atado a un número de compontes dados por la aplicación que para una denición sucientemente robusta sería difícil de implementar, no obstantes además está enfrentado a carencias en extensibilidad aunado a su baja portabilidad.. 7.

(18) Capítulo III Metodología. Figura 1: Proceso de implementación de mecanismos de prototipado. Este trabajo presenta el resultado de la implementación de una propuesta de prototipado rápido para aplicaciones de realidad virtual, para esto se hace uso de InTml, un conjunto de herramientas que soporta su losofía y un soporte de uso basado en ActionScript 3. El proceso (gura 1) comprende una implementación de características de la mano del rol de programador y diseñador de aplicaciones que integran funciones de portabilidad, el manejo rápido de las posibilidades de interacción de la información 3D y la representación de la misma. De este modo el desarrollo estará integrado por una serie de aplicaciones y librerías que soportan fácilmente la consecución de aplicaciones de realidad virtual atadas a las características y ventajas de InTml y. 8.

(19) los mecanismos de visualización previa. . En este orden de ideas los puntos que se tratarán son:. Presentación del modelo de apoyo al desarrollador (programador y diseñador). Herramienta de prototipado soporte al diseñador. Presentación del Framework InTml. Herramientas de soporte al programador sobre InTml. Implementación del modelo soporte al desarrollador. Análisis. 9.

(20) Capítulo IV Estrategias de apoyo al desarrollador A través de los años y tratando de denir una mejor forma de ayudar a la tarea del desarrollador de aplicaciones interactivas 3D se han concluido características básicas [18] que denidas dan soporte a la reusabilidad, a la consecución de librerías, a los dispositivos y a los usuarios no especializados. Estas características han dado la inclusión a pautas [45] [22] [25] [38] [17] complementarias y especicas que mejoran y aceleran el ujo de trabajo, la calidad y considerablemente el tiempo de desarrollo, es así que considerando la tarea del desarrollador, en este trabajo se pueden denir un conjunto de características deseables a resumir según su funcionalidad: .. Mecanismos de soporte al desarrollo:. Estos mecanismos hacen referencia a. estrategias que sobre la base del lenguaje soportan el desarrollo de una aplicación de realidad virtual, entre estos se encuentran: Soporte al manejo de cualquier interacción y dependencia entre objetos. Soporte a la reusabilidad. Soporte a mecanismos que permitan la separación del las interacciones de la información 3D versus las características de modelado gráco. Ofrecer un lenguaje accesible que permita un alto nivel de abstracción. Soporte al manejo automático de los recursos y las características de calidad de software.. 10.

(21) Ofrecer un lenguaje de fácil descripción del mundo 3D y herramientas que faciliten su programación. Soporte a escenarios de prueba rápidos. Manejo de múltiples dispositivos e invisible interacción a través de protocolos de comunicación. Soporte a poder interactuar sobre las tareas complejas a un alto nivel separado del lenguaje. Soporte a un canal de comunicación entre los roles del desarrollo (Mecanismo de canal de comunicación).. Atributos de calidad: Estas características representan ideales que el conjunto de herramientas anteriormente denidas deben posibilitar al prototipado rápido como estrategias al desarrollo, las cuales se pueden listar: Portabilidad (En herramientas y datos de la aplicación). Distribución. Adaptabilidad (vista desde la perspectiva de poder implementar cualquier tipo de aplicación de realidad virtual). Para este conjunto de características se espera una separación de roles [54] [34]. Un. programador. capaz de implementar acciones y reglas que denen los. casos de uso de la aplicación. Un. diseñador. que permite la arquitectura de los requerimientos tras una. concepción de la ideal del modelo. Un. desarrollador de dispositivos que aparece bajo ciertos escenarios e imple-. menta hardware de interacción y lo pone a disposición del modelo.. 11.

(22) Esta interpretación deja de lado el modelado 3D de la aplicación, de la cual se supone herramientas sucientemente maduras y rápidas por parte del rol del artista que desarrolla los elementas grácos del modelo requerido. Entonces desde esta perspectiva cuando se habla de dar a apoyo al desarrollador de aplicaciones de realidad virtual se está enfrentado a dividir principalmente el concepto hacia el programador y el diseñador de aplicaciones, dos de los roles mejores denidos sobre las metodologías de desarrollo de aplicaciones 3D actuales [35] [44] [20]. Estos roles representan durante la fase de implementación un modelo de mutua retroalimentación hacia el prototipado de los requerimientos (gura 2), alcanzado de esta manera un estado de calidad sobre lo desarrollado.. Figura 2: Modelo de interacción entre el programador y el diseñador aplicaciones 3D.. 4.1.. Estrategias de apoyo al diseñador. Cuando se habla del diseñador se busca una clara concepción a modelar sobre todos los componentes que hacen parte de la aplicación sin necesidad de conocer sobre la plataforma tecnológica sobre la cual se va desarrollar, haciendo uso así,. 12.

(23) de herramientas básicas que a alto nivel permitan denir y manipular el entorno, brindando de esta forma una perspectiva clara al programador sobre el concepto de los requerimientos. Basado en esta denición se intenta en este trabajo mostrar una aplicación que a alto nivel permita la denición y manipulación de objetos, que unidos a la noción de eventos dados por los dispositivos (eventos pregrabados), y relacionados por una línea de tiempo y unas característica básicas de un mundo de interacción 3D, se posibilite una visión deseable a ser desarrollada por el programador. Como una forma de identicar las necesidades de un diseñador, se analizaron 31 aplicaciones interactivas 3D [17] [6] actuales, denidas en diferentes campos de acción, de las cuales se dedujo un conjunto de características básicas de interacción, así como se muestra en la gura 3a. De esta forma, se agrupa la información en abstracciones básicas y se implementan herramientas para el diseñador dependiendo de su importancia (gura 3b), la cuales se han agrupado en:. Carga de objetos: Carga de modelos 3D cuya representación denota mundos, avatars u otros elementos de denición del entorno.. Carga de cámaras:. Objetos representados por un punto de vista y una. cámara que ofrecen al usuario diseñador una perspectiva de visión.. Interpolación de movimiento:. Animación representada en la generación. de caminos de movimiento entre dos puntos en el tiempo, para un objeto o cámara bajo diferente posiciones en el entorno.. Carga de sonidos: Objetos representados por archivos de audio, denidos en formato mp3.. Reacción a eventos: Acciones. posibles sobre un objeto o cámara denidos. en un momento en la línea de tiempo por un dispositivo externo.. Manejo de Vistas: Denición de cámaras predenidas globalmente para el observador, diferentes a los objetos cámara utilizados.. 13.

(24) Finalmente, queda por fuera herramientas dependientes de hardware limitadas por la tecnología, pero de posible investigación para versiones futuras.. Figura 3: Características de interacción en un conjunto de 31 aplicaciones.. 4.2.. Estrategias de apoyo al programador. Desde la perspectiva del programador y el conjunto de características deseables ya denidas se supone un modelo ágil y de fácil integración de los requerimientos dados por el diseñador, que están denidos en modelos de interacción y ujo de acciones sobre la aplicación, de tal manera que se propone herramientas que abstraigan la complejidad de la programación y apoyen atributos de calidad en el programador. Es así que para este trabajo se dene:. Un modelo de programación fácil que denido a través de InTml [31] y la abstracción delimitada por los componentes del mundo 3D, se permite la accesibilidad, la extensibilidad y través de su DSL gráco (dataow) la interacción fácil de la información. Finalmente, gracias a la implementación (traducción) para ActionScript 3 [5] sobre el framework de Papervision [4] como se desarrolla para este trabajo, se posibilita un modelo de codicación que abstrae la complejidad de interacción de la información 3D que posteriormente unido a sus características de soporte para aplicaciones multiplataforma stand-alone o web, se convierte en un apoyo al modelo de desarrollo.. 14.

(25) Una arquitectura soporte de dispositivos, la cual. consiste en la encap-. sulación de la captura de dispositivos externos dada por VRPN [53] y otros modelos de comunicación que junto con el modelo XMLSocket [46] de intercambio de mensajes se hace posible brindar servicios sobre dispositivos conocidos y algunos poco convencionales. Esto constituye separar las dependencias del hardware de la programación haciendo posible la interacción independiente del modelo de comunicación, lo que implica un soporte al desarrollador de dispositivos. Finalmente, mecanismos en InTml [31] soportan el uso y la traducción de estos componentes.. Herramientas de portabilidad, que haciendo uso de la portabilidad en aplicación de InTml se denen herramientas de grabación de eventos y reproducción bajo simulación de dispositivos que posibilitan el trabajo bajo entornos de difícil acceso, evitando pérdidas de tiempo frente a un entorno de desarrollo. Cabe resaltar que aunque la propuesta presentada es una gran aproximación a las necesidades de apoyo de un programador de aplicaciones interactivas 3D, quedan por fuera conceptos de ayuda dirigidos hacia al lenguaje, conceptos propuestos para versiones posteriores de este trabajo.. 15.

(26) Capítulo V Herramientas de apoyo al diseñador El ciclo de desarrollo de una aplicación de realidad virtual, es un conjunto de actividades que entre sus características importantes se encuentra: la noción de los requerimientos, la denición de normas de uso y la idea de un desarrollo visual, que permita a un usuario nal de la aplicación sentir cobertura y facilidades frente a sus necesidades de interacción. Es así que además del programador aparece el rol del diseñador de aplicaciones que tras dar soporte a la denición de los requerimientos, retroalimenta el proceso del desarrollo. Entre las características del diseñador está la retroalimentación del proceso al programador en pos de cumplir los objetivos (capítulo 4), pero regularmente este canal es uno de los problemas más citados en la industria [49] [26] [18] del desarrollo de aplicaciones con información 3D, debido principalmente a que los estándares de comunicación son diferentes, los limites son equívocos, la concepción en el tiempo varía y en muchos casos, por la noción errónea de un trabajo al no tener todos los componentes del entorno de desarrollo. Así nacen mecanismos de apoyo como encuestas de requerimientos o intermediarios (desarrollador programador-diseñador) que terminan acomodando las ideas al entorno, pero usualmente implican costos, curvas de aprendizaje (si se habla de nuevos elementos al modelo) y constantemente no cubren totalmente la idea del desarrollo. Y entonces, cuándo se plantea un modelo rápido diferenciador en el mercado las desventajas competitivas son fehacientes, es así que se sigue requiriendo mejorar el canal de comunicación que permita un fácil entendimiento. Por lo tanto,. 16.

(27) en este trabajo se plantea como solución la construcción de un mecanismo que asistido por computador represente fácilmente la concepción del diseñador basado en las reglas del entono y permita al programador un fácil entendimiento del modelo a desarrollar.. 5.1.. Mecanismo de soporte al diseñador. Con base en lo anterior, se habla de herramientas soporte al diseñador ya que es quién comunica la idea y la convierte a una manera que sea compresible para el programador. El concepto de comunicar una idea para el diseñador [18] se convierte mentalmente en un escenario especial donde conuyen los posibles casos de uso base de los requerimientos y las limitaciones de la aplicación, en este sentido hablar de una herramienta o mecanismo asistido por computador, desde la vista del diseñador, implica un modelo a alto nivel independiente del lenguaje y herramientas que soporten tareas comunes que permitan mostrar un escenario de la aplicación en el tiempo. Es así que con estas características y la abstracción de elementos del mundo virtual, como se denió en el capítulo IV, se desarrolla una aplicación que se puede generalizar bajo la gura 4.. 17.

(28) Figura 4: Herramientas para el diseñador. Como se puede ver (gura 4) la aplicación desarrollada esta enmarcada sobre tres características principales: la línea del tiempo, herramientas de representación y herramientas de manipulación del entorno. Las cuales en conjunto denotan un escenario que facilita la comunicación entre el diseñador y el programador de aplicaciones (gura 5).. 18.

(29) Figura 5: Aplicación para el diseñador. 5.1.1. Línea de tiempo. Figura 6: Arquitectura de línea de tiempo. Cuando un diseñador plantea la denición de una aplicación de realidad virtual, en primera instancia centra su denición en un escenario, el cual está denido bajo un tiempo determinado donde es posible modelar los casos de uso y denir las. 19.

(30) principales normas frente al usuario nal. De esta forma, se plantea como elemento parte de la aplicación la línea del tiempo que dene en intervalos de segundos el quehacer de la aplicación en el tiempo(gura 6). Con la línea de tiempo denida, salta a la vista la concepción de dispositivos ya que su interacción en el tiempo proporciona un modelo de los casos de uso en la aplicación, por lo tanto teniendo como base la necesidad de un escenario particular de trabajo se relaciona la línea de tiempo con los archivos que registran los eventos (capítulo VI), posibilitando así una muestra en tiempo y una referencia de eventos frente a la aplicación (gura 7).. Figura 7: Línea de tiempo. Entra las características de ayuda al diseñador se identican: Múltiples dispositivos. Presentación de un escenario completo sobre una misma línea tiempo, evitando así confusiones sobre la escena global. Tiempo global denido por el escenario de prueba con mayores recursos. Eventos seleccionables de posición sobre la barra de tiempo. Manejo de efectos de saturación de eventos en un intervalo de tiempo y mecanismo de ampliación por intervalos (para estos casos se implementa una barra de perspectiva sobre el tiempo total). Finalmente para completar la retroalimentación al diseñador se integran dispositivos virtuales (capítulo VIII), que previsualizan su comportamiento en escena (gura 8).. 20.

(31) Figura 8: Retroalimentación de dispositivos al diseñador. 5.1.2. Herramientas de representación. Figura 9: Herramientas de representación. Este tipo de herramientas son el producto de abstracciones básicas representadas sobre aplicaciones de realidad virtual (capítulo IV) que denen las características y los elementos que formarán parte del escenario a proponer(gura 9), es por tanto su aplicación sobre la línea de tiempo ya denida permitiendo interactuar con ellos en cualquier momento(gura 10).. 21.

(32) Figura 10: Herramientas de construcción de un mundo virtual. 5.1.2.1.. Carga de objetos. Este mecanismo proporciona la carga de una o muchas representaciones geométricas 3D sobre el escenario (para este trabajo denidos en archivos Collada [23]), para lo cual se dispone de una línea de tiempo para cada objeto que le permite denir cuando estará disponible para su uso.. 5.1.2.2.. Carga de Sonidos. Este mecanismo proporciona la carga de uno o muchos elementos (para este trabajo denidos en archivos mp3) auditivos sobre una posición en el tiempo, para lo cual se dispone de una línea de tiempo para cada elemento que permite denir la disponibilidad de estos.. 5.1.2.3.. Carga de Cámaras. Esta herramienta proporciona la carga de puntos de vista en el tiempo manipulables por el diseñador, los cuales están caracterizados por una cámara y un objetivo.. 22.

(33) Este tipo de herramienta puede mantener múltiples deniciones cada una con su propia línea de tiempo logrando denir su disponibilidad y conguración. Finalmente, como la escena no soporta más de una cámara se dispone la posibilidad de tener una cámara maestra.. 5.1.2.4.. Interpolación de movimiento. Esta herramienta permite denir un camino entre dos posibles representaciones de objetos o cámaras que dieren en posición u orientación. La interpolación de movimiento se da por la selección de dos objetos sobre la línea de tiempo del objeto particular a interpolar.. 5.1.2.5.. Vistas. Las vistas son representaciones de cámaras predenidas para el diseñador entre las que se encuentran: frente, arriba, abajo, izquierda y derecha.. 5.1.2.6.. Mecanismos de posición y orientación. Estas herramientas representan el cambio de posición y orientación de los objetos o cámaras en los escenarios, su funcionalidad se da sobre una barra de propiedades que permite la modicación de estas características tras tener selección de los objetos.. 5.1.3. Herramientas de manipulación del entorno Cuando un diseñador se enfrenta a tareas de desarrollo rápido, en algunas ocasiones el manejo de los objetos en el escenario suele ser complicado, por razones como el desconocimiento de la unidad de medida, en otras ocasiones sólo se requiere aproximaciones del estado de la posición de los objetos en el canvas. Unido a esto, para el diseñador surge la posibilidad del empleo de herramientas de ejecución rápida que permitan tomar los datos del entorno y visualizar su escenario, que no requiera de conguraciones extras o manipulación excesiva de herramientas. Es así que se implementan este tipo de características, por un lado se da la posibilidad al diseñador de manipular los objetos y las cámaras (cámara y objetivo). 23.

(34) sobre el canvas de la aplicación basándose en una posición de tiempo donde se denen estos componente, y por otro lado, se posibilitan las herramientas de ejecución rápida que permiten la ejecución del prototipo de visión del diseñador y la ejecución de los eventos sobre los dispositivos simulados, logrando así herramientas reconocibles en el entorno de la aplicación (gura 11).. Figura 11: Retroalimentación de dispositivos al diseñador. 24.

(35) Capítulo VI Framework InTml Una de la tareas del desarrollo de este trabajo es la integración de ActionScript 3 al framework de InTml [31] como se mostró en el capítulo IV, apoyando así a la tarea del programador de aplicaciones. Entonces con base en este ítem particular a continuación se dene el DSL InTml [31] y cómo se integra a ActionScript 3, para su modelo de generación de código.. 6.1.. DSL InTml. . InTml [31] representa un lenguaje gráco de tipo dataow que dene su entorno en elementos comprendidos por: ltros, puertos y conexiones. Los ltros son entidades independientes que no comparten estado con otros ltros y sobre los cuales se implementa un conjunto de puertos que pueden representar entradas de ujo de datos o una generación de ujos de datos de salida. Finalmente, a través de conexiones entre puertos de salida y entrada se genera el movimiento de información o ujo de datos. Tras esta representación y tratando de abstraer las características o elementos más importantes que soportan el ujo de información en una aplicación interactiva 3D, los ltros son clasicados en objetos, comportamientos o dispositivos, los cuales producen salidas de tipos de datos especícos que pueden ser simples (enteros, otantes, booleanos, cadenas de caracteres) o complejos (referencia a objetos). Además, se cuenta con tipos de datos compuestos, donde usualmente el uso de un identicador sobre un tipo especíco de dato puede diferenciar las salidas de distintos ltros.. 25.

(36) Esta estructura general dene para InTml [31] el desarrollo de una aplicación en dos fases:. El desarrollo de librerías:. En esta fase se modelan los componentes que. serán base de la aplicación a desarrollar, aquí cada componente se dene en un ltro dependiendo de su aplicación junto con un grupo de puertos tanto de entrada como de salida que posibilitan el ujo de datos requeridos por la aplicación. Además, cabe resaltar que InTml ya mantiene un conjunto de librerías preestablecidas denidas en dispositivos y técnicas de interacción [21] que apoyan ya el prototipado rápido de aplicaciones sin pesar en la implementación. La importancia nal de estos componentes es que reejan reusabilidad y tras su integración en una aplicación, dependiendo de su disponibilidad, da soporte total de interacción que elimina las falencias de operatividad y código.. El desarrollo de la aplicación:. En esta fase se modela la forma de in-. teracción de la información sobre la librería de componentes y se realiza la generación de código.. Un prototipo particular se puede observar en la gura 12.. Figura 12: Ejemplo de prototipo en InTml.. 26.

(37) Para el ejemplo, se ha propuesto la selección por rayos de objetos del escenario, lo cual produce retroalimentación en la pantalla de la posible selección de objetos manipulables, en este diseño para una mayor identicación se han denido ltros compuestos en: dispositivos representados con color azul, objetos representados con color rojo y comportamientos representados con color naranja. En este sentido es fácil reconocer la funcionalidad de la aplicación, para lo cual se ha cargado un escenario (componente cargarEscena) compuesto de objetos seleccionables y un dispositivo Tracker que comparte su información y la hace visible para el entorno virtual, para este caso particular, por medio del handSelector (transforma coordenadas) y el handOset (da ubicación en el espacio); consecuentemente, las coordenadas transformadas son usadas por un objeto rayo que representa un vector de colisión cuya funcionalidad unida al comportamiento RayCaster (que recibe además referencia de los objetos interactivo), posibilita detectar colisión que retroalimenta (componente Feedback) información en la pantalla. Desde esta perspectiva cabe denotar que el rol del programador de aplicaciones hasta este punto se limita a la generación del mapa mental de la relaciones de los componentes que actuarán en la aplicación, para después materializarlas en librerías y en un modelo de prototipo que más adelante será la base para la generación de código y dará pautas para un desarrollo fácil y uido.. 6.2.. Generación de código a partir del DSL InTml. Después de implementar la fase de librerías y la fase de desarrollo de la aplicación, el framework de InTml [31] posibilita la generación de código para diferentes plataformas de desarrollo (actualmente denido para C++ y Java) [30]. Su modo de funcionamiento se realiza bajo el IDE Eclipse [19] de la mano de tecnologías como OpenArquitectureWare Xtext y Xpad [28] que permiten la generación de plantillas y la traducción, respectivamente. Además, esta implementación tecnológica está apoyada por la tecnología de Eclipse Modeling Framework o EMF [52] que a través de la denición de metamodelos y de reglas de especicación UML2 [32], se denen las bases del desarrollo. 27.

(38) de software basado en modelos [55]; por la tanto, InTml [31] dene un metamodelo de aplicaciones que se comporta como dataow, cumpliendo con las reglas que establece. A partir del metamodelo se denen los modelos de librerías y aplicación que son la base de las aplicaciones de realidad virtual que propone esta herramienta. Finalmente cabe destacar que gracias a este modelo y a su conjunto de deniciones tecnológicas se permite la portabilidad e interoperabilidad, evitando así los obstáculos que se le presentan al programador de aplicaciones en su función de operatividad.. 6.3.. Implementación en ActionScript 3.. Como se ha venido denotando el desarrollo nal de la aplicación está basado en ActionScript 3 como un ejemplo de adaptabilidad a InTml [31]y como una propuesta que potencializa algunas ventajas del prototipado rápido de cara el programador [24]. Es asi que manejando esta idea se hace uso ActionScript 3 soportado por el motor 3D de Papervision, debido a su portabilidad, su interoperabilidad y fácil manejo de la información 3D como se justico en el capítulo IV. Es entonces la tarea de denir la integración de ActionScript 3 al framework de InTml [31] que basado en su modelo de ejecución cuenta con la decion de tres patrones básicos [30] que deben ser soportados por cualquier lenguaje (ActionScript 3) que se acople al desarrollo de aplicaciones de realidad virtual en función de la ejecución. Los patrones de esta aplicación fueron implementado en base a la propuesta desarrollada en Java debido al parecido con el lenguaje de ActionScript 3 (no se profundiza en detalles puntales de implementación ya denidos [21]) , deniendo de esta manera: Como se ha venido observando, el desarrollo nal de la aplicación está basado en ActionScript 3 como un ejemplo de adaptabilidad a InTml [31] y como una propuesta que potencializa algunas ventajas del prototipado rápido de cara al programador. Adicional a ello, cuenta con un lenguaje de fácil entendimiento, un modelo de programación en 3D nativo que puede ser potencializado con motores 3D estables y de. 28.

(39) funcionalidades que permiten administrar de una mejor manera los recursos tanto en plataformas stand alone como web, características que lo ubican como herramienta de gran aceptación en el mercado [24]. Una vez empleado ActionScript 3, éste es soportado por el motor 3D de Papervision, debido a su portabilidad, su interoperabilidad y fácil manejo de la información 3D como se justico en el capítulo IV. Es entonces que se da la tarea de denir la integración de ActionScript 3 al framework de InTml [31], que basado en su modelo de ejecución cuenta con la denición de tres patrones básicos. [30] que deben ser soportados por cualquier. lenguaje que se acople al desarrollo de aplicaciones de realidad virtual en función de la ejecución. Los patrones de esta aplicación fueron implementado con base en la propuesta existente desarrollada en Java, debido al parecido con el lenguaje de ActionScript 3 (no se profundiza en detalles puntales de implementación ya denidos) [30], de esta manera:. DeviceObjectBehavior:. Este patrón dene los componentes de la aplicación. en términos reconocibles (objetos, comportamientos o dispositivos) facilitando un modo de reconocimiento y encapsulación de las características que inuyen en el desarrollo de una aplicación, en este caso mediante la agrupación de los componentes denidos en ltros que soportan el desarrollo de la aplicación. Durante su proceso de adaptabilidad a ActionScript 3 (gura 13) cabe denotar la implementación de componentes en función de capas Sprite [5], que permite la unión con el canvas de aplicación.. 29.

(40) Figura 13: Estructura del patrón DeviceObjectBehavior en ActionScript 3.. InTmlDataow: Este patrón provee los mecanismos para integrar los eventos al dataow, deniendo su funcionalidad en componentes que representan la entrada y salida de información, donde esta se clasica como invariante, modicable o externa. Finalmente, los componentes proveen deniciones de puertos , que mantienen la información identicable y disponible. Durante la integración a ActionScript 3 (gura 14) se tuvo en cuenta el manejo de los componentes en función de ShareObjetc para mantener así, la información de los eventos de manera disponible dentro de la aplicación.. 30.

(41) Figura 14: Estructura del patrón InTmlDataow en ActionScript 3.. ComponentHolder: Este patrón (gura 15) es una extensión de la denición de componente del modelo InTmlDataow, el cual representa la propagación de la información que se ve reejada desde los comportamientos hacia los objetos, posibilitando de esta forma los cambios dinámicos en el dataow.. 31.

(42) Figura 15: Estructura del patrón ComponentHolder en ActionScript 3.. Consecuentemente el concepto de patrones esta soportado por una arquitectura, que de manera simplicada se puede observar en la gura 16.. Figura 16: Arquitectura de paquetes de InTml [31]para ActionScript 3.. 32.

(43) Con base en la arquitectura de la gura 16, es importante denir los siguientes paquetes:. InTmlCore: Este paquete presenta el núcleo de InTml, y es aquí donde está el manejo del ujo de ejecución y la denición de servicios que serán prestados a los ltros.. InTmlLoader:. Es el cargador de InTml, que tras un conjunto de posibles. implementaciones de grafos de escena, se elige cual se va a usar.. InTmlFilters:Es la denición de los ltros que harán uso de los servicios de InTmlCore tras la ejecución de la aplicación.. InTmlPapervision: Es el servicio que será expuesto por InTmlCore y prestado a los ltros para su denición bajo ActionScript 3 y Papervision. Finalmente, gracias a los conceptos construidos y a la denición de plantillas que soportan el modelo ya planteado (sección 6.2) junto con la denición del comportamiento gráco dado por el dataow de InTml, se obtiene la generación de código; un ejemplo de ello se puede apreciar en el ltro de la gura 17. Cabe resaltar que el modelo es exible y permite la integración de servicios que posibiliten diferentes grafos de escena, que aunque para este trabajo solo se escoge Papervision por su madurez, estabilidad y aceptación, queda abierta la expectativa de integración de nuevos grafos como los propuestos por Away3D [13] , Five3D [11] , Sandy3D [29] o Alternativa 3D [8] que por su estado de desarrollo o falta de documentación fueron descartados de la concepción de apoyo al programador.. 33.

(44) Figura 17: Ejemplo de ltro de comportamiento en InTml.. Listing 6.1: Implementacion del comportaminetoPrueba para ActionScript 3. package { // *** Librerias de Papervision y // *** del Canvas de ActionScript 3 import org . papervision3d . core .*; import flash . display . Sprite ; // *** Definicion de clases tipo intmlRT . GObject , // *** intmlRT . Device , intmlRT . InT // *** dependiendo de la deficion del filtro public class ComportamientoPrueba extends intmlRT . InT { // Definicion de Puertos // *** Tipo de dato Integer public var puertoSalida : puerto = new puerto () ; // *** Tipo de dato empilado Integer public var puertoEntrada : puerto = new puerto () ; // *** Constructor del filtro public function ComportamientoPrueba () { creacionPuertos () ; // *** Definicion de acoplamiento al // *** canvas de ActionScript 3+ PaperVision 3 D 34.

(45) // *** predefinido por la generacion de codigo . so . flush () ; this . graphics . beginFill (0 xFFFFFF ) ; this . graphics . drawCircle (1 ,1 ,1) ; this . graphics . endFill () ; this . addEventListener ( Event . ADDED_TO_STAGE , init ) ; } // Setup de aplicacion private function init ( e : Event , nombre : String ) : void { super ( nombre ) ; stage . addEventListener ( Event . ENTER_FRAME , onEnterClip ) ; } // *** Escucha de eventos public function onEnterClip ( event : Event ) : void { actualizarup () ; // *** Funciones sobre eventos actualizardown () ; } // *** Definicion de las acciones de actualizacion public function actualizarup () : void { if ( so . data . puertoSalida . haydatos () ) { puertoSalida = so . data . puertoSalida ; } } public function actualizardown () : void { so . data . puertoSalida = puertoSalida ; } // *** Definicion de creacion de puertos public function creacionPuertos () : void { so . data . puertoEntrada = puertoEntrada ; } } }. 35.

(46) Capítulo VII Arquitectura soporte a dispositivos Cuando se habla de aplicaciones interactivas en programas tradicionales desarrollados para computadores de escritorio, dispositivos móviles o consolas de juego, usualmente utilizan una entrada unicada de datos, provenientes de dispositivos tales como un mouse, un teclado, una cámara web o incluso un Joystick. Pero el entono comercial e industrial proporciona al usuario nal una amplia gama de dispositivos que ya no son tan generales pero son más utilizados, es así que nace la necesidad de acoplar la tecnología al entorno de las aplicaciones interactivas, surgiendo así otro problema para el desarrollador de aplicaciones, ya que se debe convertir en un modelador de dispositivos y un programador de interfaces del mismo, lo cual implica altas curvas de aprendizaje que posibilitan un mayor tiempo de desarrollo. Es entonces y gracias al ámbito de investigación de este trabajo, que se proporciona una arquitectura genérica y unas herramientas que posibiliten la conexión con las solicitudes de diversos dispositivos de entrada.. 7.1.. La librería de dispositivos. Como se observa en el capítulo V , InTml [31] cuenta con la posibilidad de generar librerías reutilizables que conservan el concepto de encapsulamiento, es así que existe para InTml [31] una librería de dispositivos. [21]de constante retroalimen-. tación, que reúne la información suministrada por el framework VRPN [53] y los distribuye en un formato reconocible. Esta librería permite al usuario desarrollador la posibilidad de retroalimentación frente a dispositivos de entrada preestablecidos,. 36.

(47) evitando así conguraciones y evaluación de información que generen costo de tiempo considerable en el proceso de desarrollo. Entre los dispositivos reconocibles se encuentran:. Figura 18: Denición de un dispositivo Gamepad y un Joystick.. La gura 18 muestra la denición de un Gamepad y un Joystick, dos dispositivos convencionales donde se puede reconocer la entrada de conguración de VRPN [53] y un conjunto de salidas representadas en: eventos del clic, eventos dados por los análogos (tipo de dato compuesto) e información del dispositivo.. Figura 19: Denición de un dispositivo WiiMote y un SpaceMouse.. La gura 19 muestra la denición de un dispositivo WiiMote [48] y un SpaceMouse de la familia de los 3DConnection [1] un poco menos convencional, los cuales se caracterizan por ser más complejos tras el aumento de grados de movimiento. Estos dispositivos denen además de las salidas convencionales como en el caso del WiiMote, el muestreo de la posición y orientación denida por el posicionamiento de los puntos infrarrojos o los efectos de presión denidos por el SpaceMouse.. 37.

(48) Figura 20: Denición de un dispositivo Phantom y un Tracker.. La gura 20 muestra la denición de dos dispositivo no convencionales un Phantom [2] y un Tracker. El dispositivo Phantom [2] representa un joystick háptico que reconoce y retroalimenta fuerza, y aunque se necesita de mayor información acerca del modelo y de sus restricciones, es muy útil por sus grados de movimiento y botones. Por otro lado, los dispositivos denidos por VRPN [53] como Tracker permiten la retroalimentación de un marcador de posición y una orientación en el espacio. A este conjunto de dispositivos se les une otros no convencionales como: el dispositivo plataforma de actuadores [39] que permiten la simulación del movimiento mecánico, el dispositivo Falcon [3] que representa las características de un joystick háptico, y el P5Glove un dispositivo que manipula un guante. Como se observa, de esta forma se pueden superar los obstáculos de integración de dispositivos que gracias al modelo de separación frente a la aplicación, hace posible la denición de nuevos dispositivos y el acoplamiento al modelo de reutilización. Esta ventaja particular abre las puertas al rol del desarrollador de dispositivos que aunque no es muy común, puede tras un modelo de conguración y una referencia en la librería de dispositivos permitir la reutilización y fácil manejo de lo construido, sin que para ello implique conocer el lenguaje de desarrollo utilizado.. 7.2.. Arquitectura de comunicación. Uno de los problemas de los desarrolladores frente a los dispositivos es la forma de intercambiar información con la aplicación, un trabajo usualmente delegado al programador de aplicaciones, lo cual genera alto tiempo de desarrollo. Es así, que basándose en la estrategia de generalidad de InTml [31] soporte de la aplicación,. 38.

(49) la librería de dispositivos y el desarrollador de los mismos, se debe disponer un mecanismo de intercambio de mensajes con los dispositivos, que permita una fácil integración y un fácil manejo por parte del programador. Uno de los mecanismos mas aceptados y de soporte a la mayoría de tecnologías es la utilización del modelo de XMLSocket [46] para intercambio de mensajes a baja latencia, lo cual implica un modelo de canalización de mensajes, pero que de la mano del programador en pos de cumplir el objetivo planteado debe ser invisible. Esto lleva a crear una aplicación que este oculta al programador y que permita ejecutar el servidor VRPN [53] o la conexión de dispositivos fuera de esta metodología(OtherServiceDevice), soportando el envío de mensajes en formato XML reconocibles, que para el caso objeto de estudio se emplearía AccionScript 3 o cualquier otra tecnología. La aplicación creada es soportada por java gracias a sus ventajas de distribución y puede ser llevada a un servidor independiente bajo otro equipo, dando oportunidades a la manipulación con múltiples dispositivos. En la gura 21 se puede observar una arquitectura posible.. 39.

(50) Figura 21: Arquitectura para comunicación. Para el ideal funcionamiento del intercambio de mensajes con los ltros dispositivo bajo InTml [31] se acopla a la plantilla de traducción la denición del socket y de ser posible, gracias al reconocimiento del dispositivo, los llamados a eventos. Como puede verse uno de los problemas a tener en cuenta hasta este punto es el manejo de la conguración de la arquitectura de comunicación, denida en la asignación de servidores y puertos, ya que conlleva a la manipulación del entorno de red de la arquitectura, que puede producir confusiones y en ciertos casos curvas de aprendizaje innecesarias en el programador. Es así que nace la idea de la integración de un Wizard (ayudante) de conguración a InTml que permite antes de la ejecución de la aplicación, tras un muestreo de los dispositivos presentes, la denición de la conexión y los posibles modelos de interacción con la aplicación . Una vista inicial a este Wizard se detalla en la gura 22. 40.

(51) Figura 22: Wizard de InTml. Tras la vista del Wizard se puede localizar la conguración propia del servidor XMLSocket (gura 22a) y la denición del enrutamiento de mensajes de los diferentes dispositivos (gura 22b) que harán uso de la aplicación. Finalmente, se congura la aplicación con lo identicado por el Wizard para la puesta en marcha del producto desarrollado. Esta implementación lograda, basa sus pruebas en artículos previos [15] [14] de versiones preliminares de esta arquitectura.. 41.

(52) Capítulo VIII Herramientas de apoyo al programador Tras tener solucionado un entorno práctico al programador de aplicaciones de realidad virtual (capítulo VI) y darle una arquitectura relativamente sencilla del manejo de los dispositivos (capítulo VII), queda abierta la pregunta ¾Qué sucede en entornos donde la falta de dispositivos es visible?, obviamente esto pone en riesgo el desarrollo de prototipos y por ende de la aplicación. Desde esta perspectiva, el programador no cuenta con las herramientas que le posibiliten escenarios de prueba o dependen de la disponibilidad de esta en sitio, perdiendo así totalmente la portabilidad, característica que ya posee InTml [31]. Concluyendo así, en altos costos de tiempo o en el peor de los casos de un desarrollo incompleto de la aplicación. Desde esta problemática es entonces que se anima al desarrollo de herramientas que de cara al prototipado rápido y especialmente a la portabilidad brinden servicios al programador de aplicaciones. Es así que se propone el concepto e implementación de tres herramientas básicas: simulación de dispositivos, grabado y reproducción.. 8.1.. Simulación de dispositivos. Muchas veces los desarrolladores de aplicaciones de realidad virtual están atados al hardware de los dispositivos y cuando estos ya no son disponibles se prevén grandes pérdidas de tiempo en el desarrollo, es así que se promueve un simulador de dispositivos que unido a la losofía de portabilidad de InTml se logre la emulación de las deniciones de la librería de dispositivos. De esta forma el modelo de simulación debe expresar de manera interactiva y visual la generalización de un dispositivo, lo cual implica el desarrollo virtual del. 42.

(53) dispositivo y un mecanismo de emulación frente a la aplicación, usualmente un trabajo delegado al rol del desarrollador de dispositivos. Entonces para lograr el objetivo propuesto se provee de la creación virtual de dispositivos a través de tecnología de Flash, ya que brinda mecanismos de fácil integración de cara a la manipulación, sobre estos desarrollos se condicionan los posibles eventos emulados para la salida de información. Consecuentemente, este desarrollo está unido a un servidor temporal(TempServer) que emula VRPN [53](gura 21), haciendo invisible la forma de comunicación con la aplicación (gura 23). Cabe resaltar que para el presente trabajo se tomó como base la librería de dispositivos, por lo tanto frente a la inclusión de un nuevo hardware de interacción, surge para el desarrollador de dispositivos la tarea de denir dispositivos virtuales y sus posibles formas de interacción.. Figura 23: Vista de ujo de información para InTml. Seguidamente la tarea del modo de uso con la aplicación es dado por el Wizard (sección 7.2) de InTml, adecuando de ser posible la emulación de los dispositivos propuestos en la aplicación (gura 24).. 43.

(54) Figura 24: Arquitectura InTml [31]+ Servidor de Dispositivos. Finalmente, un servidor de contenidos o un directorio local son los encargados de distribuir las representaciones virtuales de los dispositivos, dando al desarrollador ventajas frente a las posibilidades de actualización sobre los modelos de posible emulación (gura 25).. Figura 25: Flujo de información para InTml [31]soportado por un servidor de contenidos. 44.

(55) 8.2.. Grabado y reproducción de eventos. Cuando un desarrollador de aplicaciones de realidad virtual se enfrenta al problema de disponibilidad de recursos de hardware, está afrontando el trabajo de desarrollo sin retroalimentación de los dispositivos, lo que deja ver una falta de escenarios de prueba. Esto supone un trabajo de portabilidad de la información y mecanismos que la reconozcan, y la presenten lo más comprensible posible para el desarrollador. Es entonces que se deja ver la necesidad de un grabador de eventos que permita a los dispositivos guardar su interacción durante un posible escenario de uso. De esta forma, para lograr el objetivo se propone rescatar la información recurrente de InTml [31] sobre el componente de los dispositivos (librería de dispositivos) ya que es aquí donde realmente se tiene la certeza de que he eventos han ocurrido, fuera de los posibles problemas por el comportamiento de la red. Bajo estas condiciones iniciales y buscando facilidades de uso para el programador se implementa una librería bajo InTml [31] denominada como InTmlRecorded, en la cual se prevé la inclusión de comportamientos que consideran las mismas entradas de un dispositivo denido sobre una librería particular o la librería de dispositivos, permitiendo bajo estos datos una arquitectura que estructura la información y una posterior representación sobre archivo. Cabe resaltar que para el caso particular se está trabajando sobre la librería de dispositivos. Por lo tanto, para las nuevas implementaciones de hardware, se requiere de la actualización de las librerías por parte del desarrollador de dispositivos. Un acercamiento a la arquitectura se puede observar en la gura 26.. 45.

(56) Figura 26: Arquitectura de grabado de eventos. Como se puede ver en la arquitectura (gura 26) para un comportamiento de guardado, se tiene en cuenta la referencia del manejo de una interfaz con funciones de almacenamiento y un tipo de referencia cola (Queue) que mantiene la información. Además, se identica un límite de almacenamiento que indica el momento de liberación de la información de la memoria a un estado recuperable, esto se tiene en cuenta porque manejar una estructura innita pude causar desbordamientos de información y dicultades de ejecución; por recomendaciones de adobe para el caso de desarrollo, el límite se ha denido en 64Kb y se habilita desde este comportamiento a un objeto sobre el canvas que permite guardar información de los eventos en un instante dependiendo de la necesidad del usuario. Un ejemplo de la implementación del comportamiento de grabado desde la técnica de interacción Camera-In-Hand (navegación) [21] se puede ver en la gura 27.. 46.

(57) Figura 27: Ejemplo del comportamiento de grabado. Desde este panorama ya lo único que basta por desarrollar es el formato de salida, pero antes es necesario hablar del reproductor de eventos ya que este presenta condiciones básicas para armar el formato de salida. De esta forma se dene el reproductor de eventos como una aplicación que basada en un archivo de información de los eventos de un dispositivo es capaz de interactuar completamente con una aplicación de InTml de realidad virtual [31]. El reproductor de eventos debe ser capaz de retroalimentar y de acercarse lo más posible a la realidad [37], ganando de esta forma comodidades frente al programador. Esto conlleva a pensar en un modelo gráco de retroalimentación, situación que es compensada con el modelo de emulación ya desarrollado, es así que para lograr el objetivo se complementa el entorno de simulación del dispositivo con un sistema que permite la carga, la traducción, la ejecución automática y la representación en pantalla de los eventos como si fuese un usuario que gestiona manipulación. Pero hablar de integración al simulador de eventos es permitir trabajar con dispositivos genéricos, lo cual implica dicultades con algunos dispositivos diferentes de un mismo tipo. Es así que nace la idea de integrar un traductor de eventos que permita representar cualquier dispositivo perteneciente a una misma categoría sobre un dispositivo genérico; para este desarrollo se propone un sistemas visual (gura 28) que basado en un dispositivo físico se le asigne a su igual en el entorno virtual y guarde una conguración que tras reproducción permita vericar de manera el la interacción y comunique realmente el evento ejecutado.. 47.

(58) Para efectos de conguración de la representación virtual se tomará el Wizard de InTml, sobre la selección de los dispositivos que hacen parte de la aplicación y son objeto de conguración, para lo cual se cuenta con un archivo de conguración que contiene los posibles eventos virtuales a ejecutar, tareas que seguirán siendo parte de las funciones del desarrollador de dispositivos.. Figura 28: Conguración del grabado dispositivos. De esta forma con un modelo de traducción para dispositivos ya se puede generar un formato completo de grabado, sobre el cual se especica para un dispositivo determinado, unas características para sus eventos relacionados, así:. Tipo de evento (name):. Este campo dene quien ejecuta el evento sobre. el dispositivo físico, por ejemplo, un botón, un análogo, un cambio posición u orientación.. Identicador (id):. Este campo dene las posibles las diferencias entre los. eventos, por ejemplo, el botón la separación de un botón derecho y de un izquierdo.. Valor(value):. Es el valor sobre un evento diferenciado. Puede presentar un. prendido o apagado(0,1), o un valor visible de cambio, como una orientación, con más de dos valores separados por :.. Ocurrencia (Time):. Este campo indica en milisegundos en qué momento. ocurre el evento, tomando como referencia que tiempo de inicio de la aplicación.. 48.