Infraestructura multiplataforma para el desarrollo de aplicaciones de realidad virtual

Texto completo

(1)INFRAESTRUCTURA MULTIPLATAFORMA PARA EL DESARROLLO DE APLICACIONES DE REALIDAD VIRTUAL.. DANIEL FELIPE MEJIA PADILLA. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA MAGÍSTER EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, COLOMBIA 2004.

(2) INFRAESTRUCTURA MULTIPLATAFORMA PARA EL DESARROLLO DE APLICACIONES DE REALIDAD VIRTUAL.. DANIEL FELIPE MEJIA PADILLA. Tesis de grado para optar al título de: Magíster en Ingeniería de Sistemas y Computación Asesores: Dr. Pablo Figueroa Dr. José Tiberio Hernández. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA MAGISTER EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, COLOMBIA 2004.

(3) Dedicado a mis padres, mi hermano e Isabel .. iii.

(4) AGRADECIMIENTOS El autor expresa sus agradecimientos a: Pablo Figueroa, asesor principal de la tesis, por todo su apoyo, orientación y sus valiosos aportes a lo largo de todo el proyecto. Marcela Hernández, jurado de tesis, por su tiempo, participación y colaboración en el desarrollo de los ejemplos. Silvia Takahashi, coordinadora de la Maestría, por la ayuda que me brindo durante todo el cursar de mi Maestría. Fernando de la Rosa, por su apoyo y colaboración para ayudarme a establecer la idea original del proyecto. Andrea Herrera, por el apoyo y la colaboración que me brindo durante todo el desarrollo del proyecto. Finalmente, al Departamento de Ingeniería de Sistemas y Computación, por la oportunidad brindada para la realización de la Maestría.. iv.

(5) CONTENIDO 1.. INTRODUCCIÓN.................................................................................................... 10. 1.1.. Objetivos Generales.............................................................................................. 11. 1.2.. Objetivos Específicos ........................................................................................... 11. 1.3.. Justificación .......................................................................................................... 12. 2.. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE DESARROLLO DE. SOFTWARE DE RV............................................................................................................ 14 2.1.. Herramientas de Software .................................................................................... 14. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.1.7. 2.1.8.. SYSYGY .............................................................................................................. 14 DICELIB: Distributed Cave Engine Library........................................................ 16 VrJuggler .............................................................................................................. 17 Performer .............................................................................................................. 18 CAVELIB............................................................................................................. 18 VRPN: Virtual-Reality Peripheral Network......................................................... 19 Alice ..................................................................................................................... 19 WTK: World Toolkit ............................................................................................ 20. 2.2.. Plataformas ........................................................................................................... 22. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7.. ARSBOX .............................................................................................................. 22 Sara Virtual Reality facilities ............................................................................... 22 VISBOX ............................................................................................................... 23 SGI Reality Center ............................................................................................... 23 FAKESPACE ....................................................................................................... 24 BARCO ................................................................................................................ 24 MULTIGEN ......................................................................................................... 24. 2.3.. Metodologías de desarrollo para Realidad Virtual ............................................... 25. 2.3.1. 2.3.2.. MARYGOLD ....................................................................................................... 25 PMIW ................................................................................................................... 25. 2.4.. Arquitecturas de desarrollo para Realidad Virtual ............................................... 26. 2.4.1. 2.4.2. 2.4.3.. MVC & PAC ........................................................................................................ 26 MARYGOLD Toolset .......................................................................................... 28 InTml: Interaction Techniques Markup Language............................................... 28. v.

(6) 2.5. 3.. Requerimientos..................................................................................................... 29 DEFINICIÓN DE LA PROPUESTA DEL AMBIENTE DE DESARROLLO....... 31. 3.1.. Hardware .............................................................................................................. 32. 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. 3.1.6.. Servidor de dispositivos ....................................................................................... 33 HMD..................................................................................................................... 33 Fish Tank Desktop................................................................................................ 34 Stereo Pc ............................................................................................................... 36 PC ......................................................................................................................... 36 GEOWALL .......................................................................................................... 36. 3.2.. Software................................................................................................................ 37. 3.2.1.. Integración de Librerías........................................................................................ 47. 3.3.. Procedimientos ..................................................................................................... 52. 3.3.1. 3.3.2. 3.3.3.. Configuración (Conexión HW y Calibración)...................................................... 52 Desarrollo ............................................................................................................. 55 Demos................................................................................................................... 58. 4.. EJEMPLOS .............................................................................................................. 67. 4.1.. Visualizador Performer......................................................................................... 67. 4.2.. Visualizador Performer con Posición de Cabeza ................................................. 78. 4.3.. Visualizador DCom .............................................................................................. 80. 5.. CONCLUSIONES Y TRABAJO FUTURO............................................................ 87. 6.. BIBLIOGRAFÍA ...................................................................................................... 90. APÉNDICES ........................................................................................................................ 96 Pasos para configurar un ambiente fish tank en Linux......................................................... 96 Archivo de Configuración XFREE86 .................................................................................. 97 Árbol de Directorios CD Anexo......................................................................................... 100 Arquitectura InTml ............................................................................................................. 103. vi.

(7) LISTA DE IMÁGENES Imagen 1 Plataforma de SYSYGY [SYS 03]....................................................................... 15 Imagen 2 Arquitectura de VrJuggler [VRJ 03] .................................................................... 17 Imagen 3 Configuración del Laboratorio ............................................................................. 32 Imagen 4 Fish Tank Desktop................................................................................................ 35 Imagen 5 Diagrama de Capas de Configuración del Software............................................. 37 Imagen 6 Infraestructura de Software .................................................................................. 39 Imagen 7 Diagrama de Clases Framework InTml (Información) ........................................ 40 Imagen 8 Diagrama de Clases Framework InTml (Puertos) ................................................ 42 Imagen 9 Diagrama de Clases Framework InTml (Filtros).................................................. 43 Imagen 10 Diagrama de Clases Framework InTml (Sistema) ............................................. 44 Imagen 11 Diagrama de Clases Framework Intml (VRJUGGLER + PERFORMER) ....... 45 Imagen 12 Diagrama de Clases Framework Intml (Ambiente de Ejecución)..................... 46 Imagen 13 Instalación de los Dispositivos ........................................................................... 53 Imagen 14 Mesa para calibración de los Trackers ............................................................... 54 Imagen 15 Descripción de un nuevo filtro de Interacción (Key2RGB) ............................... 57 Imagen 16 Descripción de un nuevo filtro de dispositivos .................................................. 57 Imagen 17 Descripción de un nuevo filtro de visualización ................................................ 58 Imagen 18 Filtro de Visualización Cube .............................................................................. 60 Imagen 19 Filtro para un dispositivo.................................................................................... 60 Imagen 20 Filtro de Interacción............................................................................................ 61 Imagen 21 Aplicación Ejemplo ............................................................................................ 61 Imagen 22 Aplicación de Ejemplo Modificada con interacción 1 ....................................... 63 Imagen 23 Cambio en Filtro de Interacción ......................................................................... 64 Imagen 24 Aplicación de Ejemplo Modificada con interacción 2 ....................................... 64 Imagen 25 Filtro representativo de un Gamepad.................................................................. 65 Imagen 26 Aplicación de Ejemplo Modificada para el Gamepad........................................ 65 Imagen 27 Imágenes de la Aplicación Visualizador Performer ........................................... 67 Imagen 28 Visualizador de Objetos Performer .................................................................... 68 Imagen 29 Diagrama de Clases Filtro FobTracker............................................................... 68 Imagen 30 Diagrama de Clases Filtro IsInZone................................................................... 70 Imagen 31 Comportamiento basado en proyección de vectores .......................................... 72 Imagen 32 Diagrama de Clases Filtro OrbitZoom ............................................................... 72 Imagen 33 Diagrama de Clases Filtro PerformerFile........................................................... 74 Imagen 34 Imágenes de la Aplicación en Ambiente Fish Tank Desktop............................. 78 Imagen 35 Visualizador de Objetos Performer en un Fish Tank ......................................... 79 Imagen 36 Imágenes de la Aplicación Visualizador DCom................................................. 80 Imagen 37 Visualizador de Imágenes DCOM...................................................................... 81 Imagen 38 Diagrama de Clases Filtro Slide3D .................................................................... 82 Imagen 39 Diagrama de Clases Filtro SlideObject .............................................................. 82. vii.

(8) Imagen 40 Diagrama de Clases Filtro VTKDComImage .................................................... 83 Imagen 41 Ejemplo de un filtro (SelectByTouching) [FIG 04] ......................................... 103 Imagen 42 Modelo de Ejecución de INTML [FIG 04] ...................................................... 104 Imagen 43 Entidades y Relaciones en INTML [FIG 04] ................................................... 106 Imagen 44 Arquitectura de una implementación INTML [FIG 02]................................... 107. viii.

(9) LISTA DE TABLAS Tabla 1 Comparación de las Herramientas........................................................................... 21 Tabla 2 Método main de la Clase MainInTmlLoader .......................................................... 46 Tabla 3 Método SetApp de la Clase VRJPFApp.................................................................. 48 Tabla 4 Archivo XML de Configuración para VrJuggler habilitando VRPN...................... 48 Tabla 5 Archivo XML de Configuración para Habilitar el administrador de Entradas ....... 49 Tabla 6 Ejemplo de VTK mace.cxx ..................................................................................... 51 Tabla 7 Uso de VtkActorToPF............................................................................................. 51 Tabla 8 Configuración de Dispositivos ................................................................................ 53 Tabla 9 Archivo InTml ......................................................................................................... 62 Tabla 10 Creación de los Puertos en el Filtro FobTracker ................................................... 69 Tabla 11 Método Execute de FobTracker ............................................................................ 69 Tabla 12 Metodo CreatePorts de IsInZone........................................................................... 70 Tabla 13 Metodo execute de IsInZone ................................................................................. 70 Tabla 14 Método createPorts de OrbitZoom ........................................................................ 73 Tabla 15 Metodo execute de OrbitZoom.............................................................................. 73 Tabla 16 Método createPorts de PerformerFile.................................................................... 74 Tabla 17 Metodo execute de PerformerFile ......................................................................... 75 Tabla 18 Código de la Aplicación Generic Performer Viewer ............................................ 76. ix.

(10) 10. 1. INTRODUCCIÓN. Un objetivo importante desde los inicios de la computación gráfica ha sido lograr imitar la realidad por medio de modelos gráficos y de simulación. Con la propuesta de Sutherland (Espada de Damocles)1 se abrió un nuevo concepto, ya no sólo se quiere imitar la realidad sino que se quiere engañar a la mente, haciéndole creer que el usuario esta en el mundo y puede interactuar con él. A pesar de la simplicidad de la propuesta original de Sutherland, lograba que la persona se compenetrara con el mundo virtual de una manera aceptable, sin embargo ésta tenia una gran desventaja, la construcción de toda una infraestructura mecánica para sostener el dispositivo de visualización. Esta construcción no sólo tenía un costo muy elevado sino que además limitaba la interacción del usuario. Estas limitantes han ido desapareciendo con la evolución de la tecnología, debido a la aparición de sistemas de visualización y dispositivos de interacción como cascos y guantes, que permiten crear ambientes mucho más complejos y fáciles de usar que el planteado por Sutherland. En la actualidad existen diferentes opciones de software y de hardware que permiten crear ambientes de Realidad Virtual (RV), particularmente los ambientes de inmersión. Ya no sólo se consiguen los dispositivos independientemente del software sino que existen opciones en el mercado de ambientes completos y empresas dedicadas especialmente a la creación de éstos, pero con costos aun muy elevados. Todo este conjunto de elementos (hardware y software), busca facilitar el desarrollo de aplicaciones de RV, dándole herramientas a los desarrolladores para la elaboración de una 1. Primer casco visor de RV, constaba de tubos de rayos catódicos en un armazón de alambre [PER 03].

(11) 11. nueva aplicación. Se busca transformar el desarrollo en un proceso de adaptación, el cual se logra a través de la interacción de los elementos de la infraestructura. En la actualidad, todos estos elementos requieren de un conocimiento altamente técnico y no permiten el desarrollo de una aplicación rápidamente, dado que se debe cumplir con la curva de aprendizaje de las herramientas. Es por esto que el objetivo de este trabajo es generar una infraestructura que permita, interactuar con la mayor cantidad de tecnología de RV, realizar desarrollos de software en un menor tiempo y disminuir los costos de montaje del ambiente de desarrollo.. 1.1.. Objetivos Generales. Los Objetivos Generales de este Trabajo son los siguientes:. •. Generar un plataforma2 de trabajo lo suficientemente completa que permita el desarrollo de aplicaciones de RV.. •. Evaluar la plataforma por medio del desarrollo de demos útiles para la investigación y el grupo de Informática gráfica de departamento.. 1.2.. •. Objetivos Específicos Analizar el estado actual de los elementos de software, hardware, metodologías y procedimientos para el desarrollo de aplicaciones de RV.. • Sintetizar la información recopilada para escoger los elementos más útiles para la generación de la plataforma de software de la infraestructura planteada. • Generar una primera versión de la infraestructura a ser utilizada en el laboratorio de computación gráfica y realidad virtual de la Universidad de los Andes. 2. Conjunto de elementos de hardware y software unidos en una misma infraestructura.

(12) 12. •. Establecer los procedimientos necesarios para el uso efectivo de la infraestructura montada.. •. Desarrollar dos demos particulares sobre la infraestructura montada, para la reconstrucción de imágenes médicas y la visualización de objetos gráficos en Performer [SGI 04], motivados en las necesidades del grupo de informática gráfica... 1.3.. Justificación. En la actualidad existen diferentes áreas que han demostrado la importancia de la tecnología de RV y las ventajas que está puede brindar. Como por ejemplo las excavaciones petroleras, disminuyendo los riesgos en sus perforaciones, por medio de la toma de decisiones mas certeras y efectivas, el diseño CAD3 buscando una mejor interacción con los modelos y el entretenimiento con nuevas opciones de diversión, evidenciando que esta tecnología que pareció desvanecerse en algún momento ofrece un apoyo útil en cada una de estás. Es por esto que la Universidad de los Andes está retomando sus investigaciones en el área de Realidad Virtual, como por ejemplo técnicas de interacción o configuraciones para ambientes de inmersión. Estas investigaciones dan comienzo al proyecto “Low Cost Cave”, buscando fortalecer el laboratorio para facilitar este tipo de desarrollos. Estas aplicaciones son un poco complejas en su desarrollo, debido a que el tiempo requerido para la instalación y configuración de las herramientas es alto, tiempo que se incrementa con el aprendizaje de las mismas y que se ve reflejado en desarrollos lentos y poco estables. Para intentar resolver en una primera medida estos problemas se puede utilizar diferentes ambientes de trabajo, evitando todo el proceso de configuración e instalación, pero estos ambientes son complicados de usar, requieren de un conocimiento. 3. CAD: Diseño Asistido por Computador.

(13) 13. técnico importante; están dirigidos a cierto tipo de configuración computacional; y en algunos casos tienen un costo muy elevado. Es por esto que nace la idea de crear una infraestructura que permita el desarrollo de aplicaciones de Realidad Virtual a un costo menor, utilizando los dispositivos con los que cuenta la universidad, las instalaciones y el software disponible de libre acceso (GNU), para crear un ambiente de trabajo lo suficientemente completo y flexible para la creación de este tipo de aplicaciones..

(14) 14. 2. ESTADO DEL ARTE DE LAS HERRAMIENTAS DE DESARROLLO DE SOFTWARE DE RV. Durante la evolución de la computación grafica y la realidad virtual se han desarrollado diferentes tecnologías tanto de software como de hardware que permiten crear con mayor facilidad este tipo de software. Como consecuencia de este proceso, actualmente existe una gran cantidad de herramientas útiles para el desarrollo de una aplicación de RV. Cada una de las herramientas tiene sus beneficios, hay unas herramientas mucho mas completas que otras, pero en general se busca que el desarrollo de una aplicación no sea tan traumático; se busca encapsular cada uno de los componentes que involucra la RV y ofrecerlos como un elemento mas del API (application programming interface), de desarrollo. A continuación, se realizará un breve resumen sobre las herramientas de software, plataformas de desarrollo, metodologías y procedimientos, la cual servirá para establecer los elementos apropiados para la propuesta desarrollada en está investigación.. 2.1.. Herramientas de Software. Como se comentó anteriormente, existe una gran diversidad de herramientas de software que nos ofrecen diferentes opciones a la hora de desarrollar una aplicación de RV, por lo cual se intenta mostrar las más representativas y una breve descripción de su utilidad.. 2.1.1. SYSYGY. La herramienta SYSYGY [SCH 03, SYS 03], fue desarrollada por el ISL (Integrated.

(15) 15. Systems Laboratory) de la Universidad de Illinois. Su principal objetivo es soportar la mayor cantidad de aplicaciones de RV en un sistema distribuido, obteniendo con esto un mayor rendimiento que el obtenido por una máquina SGI Onyx4. La idea es montar un sistema distribuido heterogéneo que pueda utilizar cualquier configuración de máquinas y cada una de ellas pueda cumplir con alguna labor. Por ejemplo, máquinas como las x86 o las MIPs puedan ser útiles nuevamente. Este sistema está basado en una capa de mensajes con los cuales se puede establecer la comunicación entre diferentes elementos distribuidos que se están procesando, tales como gráficos, sonido, administración y acceso a los datos, y dispositivo I/O. SYSYGY permite centralizar la configuración y administración de los diferentes elementos, siendo ésta su fortaleza. Como se ve el la siguiente imagen (Imagen 1), SYSYGY divide toda su estructura en cuatro capas:. Application Frameworks Media Objects Media Protocols. I/O Drivers Phleet. I/O Framework. Communications Layer. Imagen 1 Plataforma de SYSYGY [SYS 03]. 4. Servidor Ofrecido por Silicon Graphics..

(16) 16. •. Primera Capa: Conocida como la “communications layer”, es la capa más baja y está relacionada con los protocolos de comunicación y con la manipulación de la conexión, desconexión y reconexión de las máquinas en el sistema distribuido.. •. Segunda Capa: Está dividida en tres partes, la “media protocols” encargada de la creación de protocolos, incluyendo opciones de sincronización y comunicación entre dispositivos, el “Phleet” que simula un sistema distribuido y ofrece opciones de administración para los procesos que están registrados en el, y por ultimo “I/O framework” encargado de la administración de los dispositivos de entrada y salida.. •. Tercera Capa: La componen los “media objects” y los “I/O Drivers”, que permiten la manipulación de los dispositivos, por ejemplo, trackers, guantes, cascos, etc…. •. Cuarta Capa: Está última capa conocida como la “Application Frameworks” es el la interfaz del ambiente de desarrollo.. 2.1.2. DICELIB: Distributed Cave Engine Library. Creado en la Universidad de Sao Paulo por Bruno Barberi Gnecco, Dicelib [BAR 03], es una librería para trabajar sistemas distribuidos que requieren una taza de actualización alta, como aplicaciones gráficas o sistemas CAVE5. Tiene como ventajas que está completamente implementada en C++ sobre sockets, lo que permite soportar los protocolos de comunicación más comunes (TCP, UDP, XTP). Ésta implementación es demasiado técnica y requiere de un conocimiento relativamente amplio del lenguaje C.. 5. CAVE: sigla establecida para referirse a un sistema de Realidad Virtual basado en proyecciones, que logra una inmersión completa del usuario al mundo.

(17) 17. 2.1.3. VrJuggler. Vrjuggler [VRJ 03], es un API creado en la Universidad de Iowa, para el desarrollo de aplicaciones gráficas. Su objetivo es abstraer todos los componentes que están involucrados en una aplicación gráfica, tales como sonido, trackers, dispositivos de entrada y salida, etc. Este API es hecho completamente en código libre y permite la configuración de cada uno de los dispositivos por medio de archivos XML, los cuales son posibles de editar en cualquier editor de texto o con una aplicación en java suministrada con el software, la cual a diferencia de los demás elementos de este API, no es muy estable porque se encuentra en un desarrollo muy temprano. En la actualidad la comunidad de programadores en VrJuggler es la más activa frente a los demás grupos de desarrollo sobre aplicaciones de RV, principalmente por medio de los foros de discusión. La última versión estable de Vrjuggler es la 1.1 y en desarrollo se encuentra la 2.0 alpha 4, dentro de la cual se tiene la posibilidad de crear un ambiente distribuido, llamado Cluster Juggler. La arquitectura de VrJuggler se muestra en la imagen (Imagen 2) a continuación.. Imagen 2 Arquitectura de VrJuggler [VRJ 03].

(18) 18. Simultáneamente con el desarrollo de VrJuggler hay otros desarrollos que apoyan el sistema con el modelamiento de diferentes aspectos, y son los subproyectos patrocinados por el mismo grupo, dentro de estos se encuentran los que se mencionan a continuación.. •. JCCL (Librería de configuración para VrJuggler).. •. Gadgeeter (Soporte a dispositivos I/O).. •. VPR (VR Juggler Portable Runtime Layer).. •. Sonix (Objetos de Sonido).. •. Tweek (Aplicaciones Graficas Portables).. 2.1.4. Performer. Performer [SGI 04], es un potente API creado por SGI basado en la manipulación y visualización de grafos de escena. Performer está diseñado para aplicaciones de alto rendimiento, como visualización en tiempo real o animaciones 3D. Permite sincronización entre diferentes máquinas a un alto rendimiento. En la actualidad existen implementaciones para diferentes sistemas operativos y su ejecución tiene como base la comunicación por medio de pipes. Es un software comercial, pero permite el trabajo con una versión de evaluación la cual cuenta con todas las capacidades de la versión completa.. 2.1.5. CAVELIB. CAVELIB [VRC 04], es la primera librería creada por Carolina Cruz Neira y Dave Pape en el EVL (Electronic Visualization Laboratory), es mostrada al público en la presentación del primer ambiente tipo CAVE en el congreso SIGGRAPH92. Ayudó a sus desarrolladores a.

(19) 19. utilizar de manera más fácil los dispositivos de entrada, los sistemas de visualización y a independizar el procesamiento de los dispositivos. En la actualidad esta librería es propiedad de VRCO6, por esta razón es necesario adquirir la versión comercial para obtener todo su potencial.. 2.1.6. VRPN: Virtual-Reality Peripheral Network. VRPN [VRP 04], es un “framework” desarrollado en C++, que busca independizar los dispositivos de RV de la aplicación. Cuenta con una gran variedad de implementaciones para diferentes dispositivos, los cuales se pueden extender por medio de la creación de clases. Los dispositivos son identificados con un nombre y un índice; la información se puede acceder por medio de una red TCP-UDP/IP. Está implementada sobre una arquitectura cliente servidor, donde cada cliente es capaz de obtener la información de cada uno de los dispositivos conectándose al puerto establecido por el servidor.. 2.1.7. Alice. Desarrollado por la Universidad de Carnegie & Mellon y la universidad de Virginia, Alice [ALI 04], es un ambiente de programación con una interfaz amigable para el usuario, está pensado para aplicaciones sencillas y una simple interacción como un clic en el Mouse o utilizar algún carácter del teclado.. 6. VRCO: Compañía que surge en 1996 y desde ese momento se convierte en la pionera en comercialización de hardware y software que permita I3D (interactive 3D).

(20) 20. Permite crear aplicaciones de RV con mucha facilidad sin necesidad de tener un amplio conocimiento del objeto 3D, dado que este proporciona un conjunto de objetos predefinidos que pueden ser agregados a la escena que se está creando. Una vez se tienen una escena completa se pueden agregar pequeños scripts asociados a estos objetos, para generar animaciones o comportamientos sencillos.. 2.1.8. WTK: World Toolkit. Es una librería desarrollada en C/C++, para el desarrollo de aplicaciones portables, soporta una gran variedad de hardware y diferentes formatos para la descripción de la geometría de los objetos a representar. La portabilidad de las aplicaciones, es soportada por una optimización para cada una de las plataformas dentro de las cuales se encuentran SGI, Solaris, HP, DEC, Intel, y Linux. La última versión soporta un ambiente distribuido, así como corrección a varios errores de sus versiones anteriores. 2.1.10 Comparación de Herramientas Cada una de las herramientas anteriormente descritas tiene una fortaleza en alguno de los aspectos que involucra la computación gráfica y los ambientes de realidad virtual. Este capítulo se complementará con un pequeño cuadro que analiza las herramientas en diferentes aspectos y su importancia en cada uno de estos. La tabla describe el lenguaje de programación sobre la cual fue desarrollada la herramienta y su importancia en cada una de las áreas relevantes (representado por un número en donde el 3 es el más significante y el 1 menos significante, adicionalmente habrán casillas con el valor 0 para las herramientas que no de facilidades en esa área)..

(21) 21. Tabla 1 Comparación de las Herramientas. HERRAMIENTA. Lenguaje. FU. SD. IC. AD. DG. C. CAVELIB. C. 1. 3. 3. 3. 0. 1. PERFORMER. C++. 1. 1. 3. 2. 3. 2. ALICE. Python. 3. 1. 0. 0. 1. 3. VRJUGGLER. C++. 1. 3. 3. 3. 0. 3. SYSYGY. C++. 1. 2. 2. 3. 0. 3. DICELIB. C++. 1. 1. 3. 2. 0. 3. VRPN. C++. 1. 3. 3. 0. 0. 3. WTK. C++. 1. 3. 3. 2. 3. 3. Los campos de la primera fila en la tabla son abreviaciones que representan las siguientes áreas de interés.. •. (FU) Facilidad de uso. •. (SD) Soporte de Dispositivos. •. (IC) Instalación y Configuración. •. (AD) Ambiente Distribuido. •. (DG) Detalles en la Geometría. •. (C) Costo. Como se puede observar una de las herramientas más equilibradas es VrJuggler, por lo cual se decide que está sea la base de integración de la plataforma.. Existen otras herramientas de software para el apoyo de aplicaciones de RV, pero esta investigación se basa en las nueve anteriormente mencionadas, por considerarse como las mas relevantes y utilizadas..

(22) 22. 2.2.. Plataformas. Así como existen en la actualidad una diversidad de software especializado para la generación de aplicaciones de RV, existen a su vez diferentes opciones en el mercado de plataformas completas para este fin. Sin embargo, estas opciones son comerciales y la información que se encuentra es incompleta y altamente técnica. A continuación se muestran un subconjunto representativo de ellas y una descripción de sus cualidades.. 2.2.1. ARSBOX. El ARSBOX [ARS 03],. es una solución comercial desarrollada por Ars Electronica,. definida como una solución CAVE, está basada en computadores personales (PC) sin un hardware especializado solo usando tarjetas de video comerciales como son las de NVDIA. Este sistema permite visualizar hasta 64 proyecciones simultaneas, se puede adaptar para un sistema CAVE donde se obtiene una visualización estéreo lograda utilizando 2 equipos por proyección. La interacción con el usuario es lograda a través de una IPAQ (Agenda digital Compaq) con la cual es posible administrar todas y cada una de las visualizaciones del ARSBOX.. 2.2.2. Sara Virtual Reality facilities. Sara [SAR 03], es una empresa Holandesa dedicada a proveer diferentes plataformas tecnológicas en diferentes ámbitos. Dentro de los productos que ofrece la compañía se encuentra la categoría de Virtual Reality Facilities, dentro de la cual ofrece diferentes tipos de infraestructuras para el desarrollo de aplicaciones de realidad virtual..

(23) 23. Existen diferentes opciones como equipos SGI Onyx, inmersa desk2 y en particular ofrece el servicio de CAVE, el cual incluye toda la infraestructura de software y de hardware necesaria. El CAVE está dividido en tres subsistemas, procesamiento, visualización e interacción.. •. Procesamiento: Logrado por medio de un equipo SGI Onyx 2 Reality Monster.. •. Visualización: La proyección está basada en espejos de reflexión y proyectores (Electrohome Marquee 8500) capaces de dar resolución 1280 x 1024 a 120 Hz, lo que permite la visualización estéreo.. •. Interacción: De acuerdo a la necesidades del usuario se ofrecen diferentes posibilidades como trackers de movimiento (flock of birds), guantes (Cybergloves) o un joystick (wand mouse 3d).. 2.2.3. VISBOX. Esta solución [VIS 03] busca la inmersión por medio de una pantalla con visualización estéreo. La plataforma está compuesta por una pantalla de 10 pies de diagonal un servidor SGI Onix 2 requerido para el procesamiento y viene equipado con un paquete de software para desarrollo, ejemplos y documentación.. 2.2.4. SGI Reality Center. Dentro de los servicios que ofrece SGI se encuentra un grupo que está encargado de la generación de espacios de RV, entre los que se encuentran ambientes tipo CAVE, Fish Tank Desktop, etc….

(24) 24. 2.2.5. FAKESPACE. FAKESPACE Systems [FAK 04] es una empresa dedicada a proveer diferentes soluciones involucradas con la computación gráfica y la realidad virtual. Dentro de sus productos tienen las soluciones más completas para estos ambientes como lo son las tipo CAVE y las POWERWALL7. A diferencia de otras empresas, está cuenta con su propio software para trabajar con su plataforma, FakeSpace Interaction Engine es el motor que permite integrar todos los dispositivos que suministran y centralizar todas las entradas en un servidor, el cual se encarga de enviar la información a todas los elementos del sistema que la necesiten.. 2.2.6. BARCO. BARCO [BAR 04], es una empresa dedicada a ofrecer soluciones relacionadas con visualización a diferentes niveles. Las mas relacionadas con el tema de realidad Virtual y computación grafica son “Large screen visualization” y “Visualization for life-critical decision making”, destacándose en esta última las soluciones que ofrecen para el despliegue de imágenes médicas.. 2.2.7. MULTIGEN. Formada en septiembre de 1998, MultiGen Paradigm [MUL 04] surge como resultado de la unión entre de dos compañías, MultiGen INC y Paradigm Simulation INC. Esta compañía está enfocada en los desarrollos que involucran simulación o que necesiten procesamiento gráfico en tiempo real.. 7. Esta configuración consiste en una pantalla de cristal líquido de grandes dimensiones, en la cual se puede interactuar con dispositivos no convencionales.

(25) 25. Dentro de sus soluciones ofrecen diferentes configuraciones de hardware y software y lo dividen en cuatro categorías: Database, Runtime, 3DGis y Standard, dentro de las cuales se clasifican los diferentes requerimientos de cada uno de los ambientes.. En la actualidad existen empresas dedicadas a temas puntuales de la Realidad Virtual, como visualización, dispositivos, infraestructuras, etc. Las plataformas anteriormente descritas se consideraron como las más completas, por lo cual permiten dar una aproximación a la configuración de la infraestructura a la que se desea llegar.. 2.3.. Metodologías de desarrollo para Realidad Virtual. En la actualidad no existen muchas metodologías para el desarrollo de software de RV, Por lo cual se hará una breve descripción de las más importantes.. 2.3.1. MARYGOLD. MARYGOLD [WIL 04], fue desarrollada por James William y Michael Harrison en la Universidad de York con el objetivo de entender, modelar, y crear los prototipos de la dinámica en los ambientes virtuales. Esta metodología se basa en la división de los ambientes virtuales en dos tipos de componentes dinámicos: las técnicas de interacción y los objetos del mundo, los primeros relacionados con los dispositivos de entrada manipulados por el usuario y los segundos los objetos que el usuario percibe y puede manipular.. 2.3.2. PMIW. En 1999 Robert Jacob, encabeza la propuesta de PMIW [JAC 99], la cual describe una aplicación como una combinación de dos elementos: un flujo de datos que describe el flujo.

(26) 26. de información desde los dispositivos de entrada y una máquina de estados que describe los diferentes modelos de ejecución. El comportamiento de las aplicaciones está dado por eventos desde la interfase y la ejecución de cada nodo en el flujo de datos depende de la máquina de estados. Esta notación proporciona bastante detalle para representar una técnica de interacción, pero requiere de muchos conceptos técnicos. Los modelos probados en ese momento eran relativamente sencillos y faltaría validar este modelo en aplicaciones mucho más complejas que las utilizadas.. 2.4.. Arquitecturas de desarrollo para Realidad Virtual. Las metodologías de desarrollo promueven la aparición de diferentes arquitecturas las cuales permiten un desarrollo de software estructurado y esto logrado a través de una serie de patrones que se establecen en la arquitectura, a continuación se mostraran diferentes arquitecturas que se pueden adaptar para el desarrollo de aplicaciones de RV. 2.4.1. MVC & PAC. Estas dos arquitecturas no son propias para el desarrollo de software de realidad virtual sino para cualquier tipo de software, pero contienen los elementos necesarios para adaptarse al desarrollo del tipo de aplicaciones que se desean. Ambas metodologías están enfocadas en la interfaz del usuario, y las aplicaciones de realidad virtual son un caso en particular de esto. La primera arquitectura, Modelo Vista Controlador (MVC) [VIC 04], como su nombre lo indica está dividida básicamente en tres elementos que representan el sistema:.

(27) 27. •. Modelo: Este primer elemento es el encargado de generar el modelo, todos los elementos que componen el mundo 3D, por lo cual debe permitir formas de manipularlo.. •. Controlador: Este elemento se encarga de recopilar todos los cambios que los diferentes actores desean hacerle al mundo y realizarlos ordenadamente, adicionalmente se debe encargar de mantener la sincronización entre el mundo y todas sus visualizaciones.. •. Vista: Este último elemento es el encargado de mostrar el estado del mundo por medio de alguna visualización, permitiendo así que existan diferentes vistas del mismo modelo. Como se observa se tiene una separación entre el comportamiento del mundo y las visualizaciones, es por esto que esté modelo se puede aplicar en el desarrollo de este tipo de aplicaciones, separando el procesamiento que conllevan los cambios en el modelo, de la visualización final que obtiene el usuario. La otra arquitectura “Presentation Abstraction Control” (PAC) [VIC 04], se basa en la definición de agentes que se responsabilizan en el desarrollo de alguna tarea específica en la aplicación, clasificándolos en 3 tipos:. •. Abstracción: Son los agentes que se encargan de obtener la información, en el caso de las aplicaciones de realidad virtual, se obtienen los datos de los diferentes dispositivos de entrada.. •. Control: A diferencia de los anteriores agentes, estos buscan modificar la información que reciben por medio de mensajes y enviarla modificada nuevamente.. •. Presentación: Estos Agentes son los encargados de la visualización, si se compara contra el modelo MVC serian los encargados de las vistas..

(28) 28. Las características propias de las metodologías mencionadas se prestan para que la visualización este separada del procesamiento de la información, elemento primordial en la optimización de las aplicaciones de RV.. 2.4.2. MARYGOLD Toolset Para poder trabajar con la metodología establecida en MARIGOLD [WIL 04], se ofrece una herramienta que la soporta, ésta esta dividida en tres utilidades las cuales se mostraran a continuación:. •. Hybrid specification builder (HSB): Esta utilidad permite desarrollar diagramas de flujo que especifican la dinámica del sistema, uniendo los componentes que se definieron (dentro de estos se encuentran las técnicas de interacción).. •. Complex object builder (COB): Ya que se tiene la dinámica del sistema, es posible generar los modelos geométricos que van a ser visualizados por medio de esta utilidad. Dentro de las opciones que permite, se encuentra la utilidad de obtener modelos de terceros, en particular obtener modelos de 3D Studio.. •. Prototype builder (PB): Esta utilidad es la encargada de integrar la visualización generada en COB con las técnicas de interacción generadas por en HSB. 2.4.3. InTml: Interaction Techniques Markup Language InTml [FIG 04], es un lenguaje para la descripción de diferentes aplicaciones de realidad virtual como presentaciones de escritorio 3D, realidad aumentada y en general cualquier aplicación que involucre dispositivos de entrada, de salida y técnicas de interacción. InTml permite describir de una manera sencilla las clases para interacción 3D y la administración de dispositivos. A su vez permite que los desarrolladores combinen estos elementos para lograr la creación de una aplicación..

(29) 29. Esta descripción es posible dado que las aplicaciones de RV pueden ser vistas como un conjunto de filtros que por medio de sus entradas y salidas pueden estar interconectados. Una descripción mas completa de esta arquitectura se hará el apéndice Arquitectura InTml. Como se puede apreciar InTml es una metodología lo suficientemente completa y estructurada, porque establece una clara división entre el desarrollo de una aplicación y la infraestructura que la soporta, estableciendo parámetros bien definidos en cada una de ellas. Adicionalmente, al dividir el desarrollo de las aplicaciones RV en capas esta metodología se convierte en una herramienta útil para alcanzar uno de los objetivos de esta investigación, como es el facilitar el trabajo de los diseñadores de aplicaciones de RV, ya que no necesitan tener un conocimiento técnico del hardware y software utilizado.. 2.5.. Requerimientos. En la actualidad, no existe ningún estándar de requerimientos para seguir en el desarrollo, uso y mantenimiento de aplicaciones de realidad virtual. Dentro de los desarrollos del laboratorio de computación gráfica y realidad virtual de la Universidad de los Andes se han logrado definir una serie de elementos que deben tenerse en cuenta durante el desarrollo y uso de las aplicaciones. por lo tanto se desean tener en cuenta para el ambiente de. desarrollo propuesto. Los requerimientos que se han logrado identificar en desarrollos anteriores del laboratorio se mostraran a continuación. •. Deben existir mecanismos de calibración para los diferentes dispositivos con los que se cuenta.. •. Es necesario que el conjunto de dispositivos de entrada y salida de una aplicación sean fácilmente configurables.. •. Debe ser posible utilizar dispositivos remotos, así como simular un dispositivo mediante otros, o cambiar totalmente la interfaz hardware de una aplicación..

(30) 30. •. Se debe permitir el cambio de técnicas de interacción, como un mecanismo para probar diversas alternativas en el diálogo con el usuario y como forma de adaptar de manera óptima nuevos dispositivos de interacción.. •. Debe poderse elegir la calidad de las gráficas mostradas dependiendo de las capacidades computacionales de la máquina donde corra la aplicación.. •. Se debe poder contar con una librería de acceso a diversos dispositivos de entrada/salida, así como diversos tipos de contenido y diversas técnicas de interacción.. La lista anterior contempla los elementos mínimos que deben ser establecidos en los procedimientos de desarrollo, uso y mantenimiento de aplicaciones RV, que han surgido con la experiencia del laboratorio de informática gráfica y realidad virtual de la Universidad de los Andes, sin embargo estos elementos puede complementarse en la medida en que se valla madurando la infraestructura o con el intercambio de experiencias con otros laboratorios. Hasta el momento, se han mostrado los diferentes elementos que en la actualidad ayudan a los desarrollos de aplicaciones de realidad virtual y su estado. En la siguiente sección, se dará inicio a la especificación de todos los elementos que se han decidido utilizar para conformar la infraestructura que esta investigación propone y una descripción detallada de su funcionamiento en la infraestructura..

(31) 31. 3. DEFINICIÓN DE LA PROPUESTA DEL AMBIENTE DE DESARROLLO. Como se mostró en la sección anterior en la actualidad existe una gran variedad de plataformas y software para el desarrollo de aplicaciones de RV, que permiten crear diferentes configuraciones. Esto es posible gracias al intento de las herramientas por abstraer los dispositivos y aunque este intento es muy útil aun persisten ciertos problemas, tanto en las plataformas como en el software, que se mencionaran más adelante y que buscan ser solucionados con la propuesta de la infraestructura. El problema principal de las plataformas existentes son los costos, dado que la mayoría están basadas en equipos de procesamiento gráfico con grandes capacidades, es el caso de las configuraciones como el Sara Cave o VISBOX mostradas anteriormente. Estos costos pueden ser superiores a los US$500.000, por lo cual en la realidad colombiana no son viables. El sistema que se plantea debe buscar alternativas mucho más económicas que las plataformas actuales en el mercado, utilizando equipos con menores características, pero que permitan obtener buenos resultados. Por otra parte, el software para el desarrollo de aplicaciones de realidad virtual tiene como problema que para la generación de una aplicación se necesita el conocimiento de un API o de un lenguaje de programación específico. Es por esto, que se desea crear una separación entre la tecnología usada y el desarrollo de una aplicación, lo cual se logro por medio de InTml. Basados en la identificación de los problemas anteriores, este capitulo muestra la descripción del hardware disponible en el laboratorio que hace parte de la infraestructura y la configuración de software que soporta este hardware y que intenta solucionar estas.

(32) 32. dificultades. Por último se especificarán todos los procedimientos necesarios para el uso de la plataforma.. 3.1.. Hardware. La infraestructura planteada debe permitir configurar diferentes ambientes en los que las aplicaciones de RV pueden llegar a utilizarse, en particular los ambientes con los que cuenta el laboratorio de informática gráfica de la universidad de los Andes. A continuación se mostrará la configuración de los dispositivos independizándolos del sistema y se hará una breve descripción de los ambientes con los que cuenta la Universidad mostrando algunas de sus características, el grafico a continuación muestra la estructura actual del laboratorio (Imagen 3).. ella. homero. Linux. Linux. HMD. Proye 1. HMD Proyec 2 Gafas Polari zacion. GeoWall Guantes. Fish Tank Desktop Gafas Muestreo. PC. Linux girardot. FOB. win guaduas. Gamepad. Joystick. Servidor Dispositivos. Imagen 3 Configuración del Laboratorio.

(33) 33. 3.1.1. Servidor de dispositivos. El sistema que se crea debe ser extensible y uno de los principales elementos para permitir esto es la posibilidad de agregar nuevos dispositivos de entrada en el banco de trabajo. Para esto se decidió independizar el sistema de procesamiento de los dispositivos, montando un servidor de dispositivos. Cuando se configura el servidor de dispositivos es posible acceder a la información generada por medio de una red convencional TCP/IP. En la actualidad el software utilizado como servidor de dispositivos es VRPN, el cual fue descrito en la sección 2.1.6, y se tienen registrados los siguientes elementos:. •. trackers. •. guantes. •. joystick’s. •. gamepad’s.. Se desea poder configurar todos los dispositivos del laboratorio en un conjunto de máquinas destinadas específicamente para esta labor, permitiendo distribuir las cargas entre los diferentes dispositivos.. 3.1.2. HMD. Dentro de los ambientes mas utilizados en aplicaciones de RV, se encuentran los basados en dispositivos HMD (Head Mounted Display), debido a que logran una buena inmersión de los usuarios en el mundo simulado. Este ambiente es complementado con elementos de interacción, dentro de los cuales se encuentran principalmente los joystick, los guantes y.

(34) 34. los gamepad, permitiendo al usuario comunicarse con el mundo, ya sea navegándolo o modificando. Los HMD están basados en el concepto de parallax, este nombre se le da a la diferencia entre los ángulos de visualización generados por dos puntos de vista ligeramente diferentes. La idea de estos dispositivos es generar dos versiones diferentes del mundo y ubicarlas en frente de cada ojo, manteniendo estas visualizaciones sincronizadas y logrando con esto engañar a la mente, ya que está genera una visión de profundidad en el modelo, en la actualidad el laboratorio cuenta con unas virtual I/O glasses, pero solo se genera una imagen, por lo cual este efecto no se utiliza. Aunque este ambiente es muy completo tiene una serie de problemas, el más importante es generado por el dispositivo como tal, debido a que el usuario debe soportar el peso del casco, el usuario se fatiga mas rápidamente por la carga adicional y en algunas ocasiones puede llegar a sentir mareo. Adicionalmente a estos problemas, se tiene que el sistema está conectado por medio de cables al computador, por lo que el desplazamiento es limitado por la longitud de los cables, sin tener en cuenta que el usuario puede pisar o enredarse con los cables al momento de caminar [PER 04].. 3.1.3. Fish Tank Desktop. A diferencia del anterior, este ambiente es basado en una pantalla CRT (Tubo de Rayos Catódicos) con muy buenas características, como su nombre lo indica se busca convertir el monitor en una pecera, es decir utilizar el monitor como una ventana al mundo virtual 3D. Esta visualización se logra por medio de una buena tarjeta gráfica pero no se logra una inmersión completa del usuario al mundo virtual. El laboratorio actualmente cuenta con un computador equipado de una tarjeta grafica nvidia gforce 3000 para la visualización y dos procesadores Xeon para el procesamiento..

(35) 35. Al igual que el anterior ambiente éste debe ser complementado por medio de dispositivos de interacción, en la actualidad el dispositivo conectado a este ambiente son tres trackers FOB (Flock of Birds) que permiten interactuar de diferentes maneras con el mundo virtual, uno para la dirección de la cabeza y los otros dos para interactuar. El problema principal de este ambiente es que no se logra inmersión del usuario en el mundo, primero por que no se logra tener el efecto de proyección 3D y segundo los marcos del monitor rompen la realidad. La Imagen 4 muestra el ambiente fish tank que utilizamos en el laboratorio.. Imagen 4 Fish Tank Desktop.

(36) 36. 3.1.4. Stereo Pc. A diferencia del anterior ambiente este no cuenta con el punto de vista del usuario, pero si se busca utilizar la visión en stereo, lo cual se logra por medio de una gafas de muestreo, estas gafas permiten filtrar las imágenes de acuerdo a un patrón de frecuencia y permiten engañar de una manera mas rustica al ojo humano. Las características con las que debe contar el monitor que es utilizado en este tipo de ambiente es un refresco mayor a 120 Hz (60 Hz para cada ojo). El laboratorio actualmente cuenta con el sistema “X3D Extreme 3D System”, el cual se conecta a la tarjeta de video y sirve de puente entre tarjeta y monitor. 3.1.5. PC. Es necesario generar un ambiente que permita hacer diferentes pruebas durante el desarrollo de una aplicación, este ambiente consiste en el uso de un computador convencional, el cual permite desarrollar las pruebas pertinentes a la aplicación sin la necesidad de montar el ambiente completo, en donde finalmente se desea mostrar la aplicación.. 3.1.6. GEOWALL Este tipo de ambiente consiste en la configuración de computadores, proyectores y gafas de polarización, el laboratorio se encuentra configurando un cluster de dos maquinas, las cuales proyectaran las imágenes en dos proyectores NEC LT 240K con un filtro de color (azul y rojo), permitiendo que se puede lograr el efecto de volumen, por medio de unas gafas de polarización..

(37) 37. 3.2.. Software. La infraestructura que se ha desarrollado, está soportada sobre un conjunto de herramientas de software descritas anteriormente las cuales permiten integrar cada uno de los elementos disponibles en el laboratorio. El sistema tiene como núcleo de integración VrJuggler (Imagen 5), dado que éste ofrece interacción con otro tipo de tecnologías como Performer y el acceso a diferentes dispositivos tanto de entrada como de salida, en particular la conexión con un servidor de dispositivos VRPN. Toda la configuración del sistema es dada por medio de archivos XML que contienen la información de cada uno de los dispositivos a usar. Esta facilidad de configuración nos permite generar diferentes ambientes por medio de la creación de archivos que representen cada uno de los dispositivos. InTml App InTml. Framework InTml Framework. VrJuggler Integración. VTKActorToPF Performer. VTK Objetos. VRPN Dispositivos. Imagen 5 Diagrama de Capas de Configuración del Software. Dado que el desarrollo de una aplicación requiere de un alto conocimiento en lenguaje C++ (sobre el que cual está implementado Vrjuggler) al igual que un conocimiento del API, se busca facilitar el desarrollo de las aplicaciones por medio de un framework InTml adaptado para esta configuración (Vrjuggler + VRPN + Performer), este framework consta de un sistema configurable, que permite acceder a los distintos recursos por medio de archivos de.

(38) 38. configuración, los cuales permiten que las aplicaciones cambien entre diferentes configuraciones de ambientes de RV, de acuerdo a las necesidades de la aplicación. Dada la metodología propuesta por InTml el diseñador que desea utilizar el framework, ya no necesita desarrollar la aplicación completamente sino que la transforma en la unión de diferentes filtros (componentes) los cuales representan dispositivos, técnicas de interacción o contenidos (Modelos 3D). Aunque este es el objetivo final, la implementación actual solo está en la posibilidad de permitir cambios en la aplicaciones con facilidad, ya sea de un ambiente a otro o modificar alguna aplicación para lograr obtener otra, el objetivo final se logrará a medida que se desarrollen más filtros para el sistema, ya que los filtros en la actualidad son limitados y están siendo modificados constantemente para cumplir nuevos requerimientos. Como se mencionó anteriormente se desea crear un servidor de dispositivos, y aprovechando el soporte con el que cuenta Vrjuggler poderse comunicar con un servidor VRPN, toda la infraestructura está montada sobre una red TCP/IP, en donde los dispositivos se encuentran configurados en una arquitectura cliente – servidor y se pueden acceder desde cualquier máquina del laboratorio. Logrando que éstos sean independientes de la infraestructura de desarrollo. A continuación se muestra un diagrama (Imagen 6) que ilustra lo descrito anteriormente..

(39) 39. TCP/IP Servidor de Dispositivos. Ambiente de Desarrollo. VrJuggler. VRPN. Aplicación. config.conf. vrpn.cfg Joystick Guantes Gamepad. FrmInTml. Config INTML. VRPN VTK vrpn.cfg Trackers. VtkActorToPf. Performer Fob Trackers Software Archivos de Configuración Dispositivos. Imagen 6 Infraestructura de Software. Para validar la infraestructura se tomó como caso de estudio uno de los desarrollos actuales en el laboratorio, que está relacionado con la reconstrucción de imágenes médicas y en particular las imágenes obtenidas por medio de escáner.. Para esta reconstrucción es. utilizada una herramienta llamada VTK [VTK 04], la cual permite de una manera relativamente sencilla realizar esta reconstrucción utilizando un conjunto de patrones de gris. La reconstrucción del modelo en VTK tuvo que ser transformada a un modelo en Perfomer, por lo cual se utilizó una clase implementada por Paul Rajlick conocida como VtkActorToPf [RAJ 04]. La cual transforma el modelo creado por VTK a un nodo en el grafo de escena Performer, siendo así posible integrarlo con VrJuggler de una manera transparente..

(40) 40. Todo este conjunto de herramientas de RV fueron complementadas con un framework InTml, basándose en una versión existente desarrollada por Pablo Figueroa, la cual estaba completamente en C++ y se adaptó para poder soportar la configuración actual del laboratorio VrJuggler + Performer + VRPN. A continuación se mostrará la estructura utilizada en el framework y se especificará el funcionamiento de las clases principales del desarrollo. El framework se puede dividir en 4 grandes partes, filtros, puertos, información y sistema, los cuales tienen una función específica:. •. Filtros: Encargados del comportamiento de los nodos en el sistema.. •. Información: Modelan los objetos y los datos que transmitirán los filtros.. •. Puertos: Modelan el medio por el cual se comunicarán los filtros.. •. Sistema: Encargado de hacer funcionar todo el framework.. A continuación se mostrará a grandes rasgos cada uno de estos. RefCounter { From intmlRT_frmSrc } Attributes. # count : unsigned int Operations. + RefCounter() : + ~RefCounter() : + addRef() : void + delRef() : void. T. T. AbsInfo. Info. { From intmlRT_frmSrc }. { From intmlRT_frmSrc }. Attributes. # step : long # currentStep : long. InfoVal { From intmlRT_frmSrc } Attributes. # info : T Operations. + InfoVal( i : T ) : + InfoVal( i : T, d : long ) : + getInfo() : T + cloneDelayed( delay : long ) : AbsInfo*. Operations. + ~AbsInfo() : + AbsInfo() : + AbsInfo( moreSteps : long ) : + nextStep() : void + getCurrentStep() : long + restart() : void + getStep() : long + print( os : ostream& ) : void + cloneDelayed( delay : long ) : AbsInfo*. Attributes. # info : T* Operations. + Info( i : T* ) : + Info( i : T*, d : long ) : + ~Info() : + getInfo() : T* + cloneDelayed( delay : long ) : AbsInfo*. Imagen 7 Diagrama de Clases Framework InTml (Información).

(41) 41. Información: Como se puede ver en la gráfica anterior el framework define dos templates: Info e InfoVal. InfoVal representa tipos básicos como un entero o un flotante, mientras que Info representa cualquier tipo en el que sea mas eficiente referenciarlo que contenerlo, esta información es la que los filtros transmiten cuando el sistema está en funcionamiento. Adicionalmente para optimizar el proceso de creación y destrucción de la información se utiliza la clase RefCounter, la cual permite conocer si la información debe ser destruida o no. Para esto, cada vez que un filtro transmite la información incrementa el contador, y cuando la recibe se decrementa, en el momento en que éste llegue a cero significa que la información deja de ser usada. Se podría decir que es el sistema de recolección de basura de todo el framework8.. 8. En este documento solo hace referencia RefCounter, no se especificara todo el funcionamiento de este..

(42) 42. AbsPort { From intmlRT_frmSrc } Attributes. # name : string # policy : PortPolicy Operations. + + + + + + + + + + + + + + +. AbsPort( o : Filter*, n : char*, p : PortPolicy ) : getOwner() : Filter* ~AbsPort() : getName() : string isConnected() : bool addPort( conn : AbsPort* ) : v oid remov ePort( conn : AbsPort* ) : v oid getConnected() : list < AbsPort* > * push( i : AbsInf o* ) : v oid apply Policy () : v oid clearInf o() : v oid clearAllInf o() : v oid hasInf o() : bool pop() : AbsInf o* print( os : ostream& ) : v oid. T info. conns. owner. IPort { From intmlRT_frmSrc }. <<aliasedtype>>. <<aliasedtype>>. <<aliasedtype>>. list < AbsInfo* >. list < AbsPort* >. Filter*. Attributes. { From intmlRT_frmSrc }. { From intmlRT_frmSrc }. { From intmlRT_frmSrc }. Operations. + IPort( o : Filter*, n : char*, p : PortPolicy ) : + push( i : AbsInf o* ) : v oid + popTy ped() : T*. AbsOPort { From intmlRT_frmSrc } Attributes Operations. + AbsOPort( o : Filter*, n : char* ) : + sendInf o() : v oid + print( os : ostream& ) : v oid. Filter { From intmlRT_frmSrc }. ports. Attributes. # name : string Operations. PortList { From intmlRT_frmSrc } Attributes Operations. + + + + + + + + +. add( p : AbsPort* ) : v oid get( name : char* ) : AbsPort* getConnectedFilter( name : string ) : Filter* getPorts() : list < AbsPort* > * sendInf o() : v oid clearInf o() : v oid clearAllInf o() : v oid apply Policies() : v oid print( os : ostream& ) : v oid. oports. iports. + + + + + + + + + + + + + + + + + + + + # #. setSy stem( sy stem : InTmlSy stem* ) : v oid getSy stem() : InTmlSy stem* print( os : ostream& ) : v oid collectImpl() : v oid collect() : v oid execute() : v oid send() : v oid clearInput() : v oid clearOutput() : v oid ~Filter() : Filter() : getName() : string setup( p : ) : v oid addIPort( ip : AbsIPort* ) : v oid addOPort( op : AbsOPort* ) : v oid getIPorts() : list < AbsPort* > * getOPorts() : list < AbsPort* > * getIPort( name : string ) : AbsIPort* getOPort( name : string ) : AbsOPort* isListener( nameFilter : char* ) : bool clearIPorts() : v oid clearOPorts() : v oid. T. OPort { From intmlRT_frmSrc } Attributes Operations. + OPort( o : Filter*, n : char* ) : + push( i : AbsInf o* ) : v oid + popTy ped() : T*. Imagen 8 Diagrama de Clases Framework InTml (Puertos). Puertos: Como se mencionó anteriormente los filtros se pueden comunicar por medio de puertos, en la gráfica anterior (Imagen 8) se observa esta relación, la clase Filter tiene dos conexiones con un listado de puertos (iports y oports), los cuales a su vez por medio de la clase AbsPort obtienen la relación con la información...

(43) 43. InT { From intmlRT_frmSrc }. + + + + + +. Attributes. Filter. Operations. { From intmlRT_frmSrc }. InT() : print( os : ostream& ) : void loadProperties() : void addAFilter( : Filter* ) : void addGObject( : GObject* ) : void connect() : void. Com posedFilter. IPort<AbsInfo>. { From intmlRT_frmSrc }. { From intmlRT_frmSrc }. Attributes Operations. + ComposedFilter() : + print( os : ostream& ) : void + getIPort( portname : string ) : AbsPort* + getOPort( portname : string ) : AbsOPort* + numComposedFilters() : int # addFilter( : Filter* ) : void # getFilter( filtername : string ) : Filter*. GObject { From intmlRT_frmSrc } Attributes. # filename : string. Device. Operations. + GObject() : + setup( p : ) : void + execute() : void + print( os : ostream& ) : void + loadProperties() : void + addGObject( : GObject* ) : void. Attributes. # name : string Operations. + setSystem( system : InTmlSystem* ) : void + getSystem() : InTmlSystem* + print( os : ostream& ) : void + collectImpl() : void + collect() : void + execute() : void + send() : void + clearInput() : void + clearOutput() : void + ~Filter() : + Filter() : + getName() : string + setup( p : ) : void + addIPort( ip : AbsIPort* ) : void + addOPort( op : AbsOPort* ) : void + getIPorts() : list < AbsPort* > * + getOPorts() : list < AbsPort* > * + getIPort( name : string ) : AbsIPort* + getOPort( name : string ) : AbsOPort* + isListener( nameFilter : char* ) : bool # clearIPorts() : void # clearOPorts() : void. { From intmlRT_frmSrc } Attributes Operations. + + + +. Device() : print( os : ostream& ) : void loadProperties() : void addDevice( : AddEdges ) : void. IPort<Info> { From intmlRT_frmSrc }. Imagen 9 Diagrama de Clases Framework InTml (Filtros). Filtros: Esta es la parte más importante del sistema, dado que todo en el framework InTml es representado por filtros. Se comentó anteriormente que el sistema constaba de tres tipos de filtros, dispositivos, objetos y técnicas de interacción. En el diagrama anterior (Imagen 9) es posible distinguir la diferencia de estos tres en el sistema, por medio de las clases InT, GObject y Device, las cuales a su vez están ligadas directamente con la clase Filter. Dentro de los métodos de la clase Filter se debe resaltar el método execute, ya que como se verá más adelante este método le da el comportamiento a cada uno de los filtros, y se encarga de mantener la circulación de la información por todo el sistema..

(44) 44. Info<GObject>. TSApp. { From intmlRT_frmSrc }. { From intmlRT_frmSrc }. collectedInfo. Attributes. # isOrdered : bool. ObjectHolder { From intmlRT_frmSrc } Attributes Operations. + ObjectHolder() : + setup( p : ) : void + execute() : void + print( os : ostream& ) : void # Connect( oport : AbsOPort*, iport : AbsPort* ) : void # Unconnect( p1 : AbsOPort*, p2 : AbsPort* ) : void objectChangedPort. OPort<Info < GObject> { From intmlRT_frmSrc } viewpointChanged. InTm lSyste m { From intmlRT_frmSrc } Attributes Operations. <<aliasedtype>>. AbsApp* { From intmlRT_frmSrc }. app. + InTmlSystem() : + setup( p : ) : void + start() : void + execute() : void + getViewpointChanged() : GObject* + print( os : ostream& ) : void + setApp( a : AbsApp* ) : void. Operations. + addIDevice( dev : Filter* ) : void + addODevice( dev : Filter* ) : void + addInT( i : Filter* ) : void + addObject( obj : Filter* ) : void + addConstant( id : string, value : string, type : string ) : void + addObjectHolder( oh : MainInTmlLoader ) : void + TSApp( n : char* ) : + findFilter( name : char* ) : Filter* + findOrder() : void + getOrder() : list < Filter* > * + findCycles( f : Filter*, visited : map < Filter*, Node * >, cycles : list < Cycle* > * ) : void + executeStep() : void + executeStepExec() : void + executeStepClean() : void + Connect( o : Filter*, op : char*, d : Filter*, ip : char* ) : void + Connect( oport : AbsPort*, iport : AbsPort* ) : void + Unconnect( p1 : AbsPort*, p2 : AbsPort* ) : void + Push( input : AbsInfo*, d : Filter*, ip : char* ) : void + sizeIDevices() : int + sizeODevices() : int + sizeInTs() : int + sizeObjects() : int + sizeConstants() : int + sizeObjectHolders() : int + print( os : ostream& ) : void + tsToString() : string + load() : void # getNextDelayingFilter() : int # createDelayingFilter( op : AbsPort*, ip : AbsPort* ) : Filter* # add2Graph( g : Graph* ) : void. ints. <<aliasedtype>> ts. objects. list < Filter* >. { From intmlRT_frmSrc }. idevices odevices. <<aliasedtype>>. list < Device* > { From intmlRT_frmSrc }. AbsApp { From intmlRT_frmSrc } Attributes. # name : string Operations. + AbsApp( n : char* ) : + getName() : string + load() : void + findFilter( name : char* ) : Filter* + executeStep() : void + print( os : ostream& ) : void. Imagen 10 Diagrama de Clases Framework InTml (Sistema). SISTEMA: El sistema consta de dos partes fundamentales, el sistema como tal y la aplicación, representado por medio de las clases InTmlSystem y TsApp (Imagen 10). El primero encargado de establecer todo el sistema y el segundo encargado de ejecutar todo el flujo de la aplicación por medio de la función executeStep(); Para poder utilizar el framework en la infraestructura que se plantea se realizaron las siguientes adaptaciones en el sistema Intml..

(45) 45. AbsApp { FromintmlRT_frmSrc }. InTm lSystem. Attributes. { From intmlRT_frmSrc }. # name : string. Attributes. Operations. Operations. + + + + + + +. + + + + + +. InTmlSy stem() : setup( p : ) : v oid start() : v oid execute() : v oid getViewpointChanged() : GObje... print( os : ostream& ) : v oid setApp( a : AbsApp* ) : v oid. AbsApp( n : char* ) : getName() : string load() : void f indFilter( name : char* ) : Fil... executeStep() : void print( os : ostream& ) : v oid. TSApp { From intmlRT_frmSrc }. VRJPFSystem ts. Attributes. + kernel : Kernel* - dsp : AddEdges - chan : pf Channel* - x : int - y : int - width : int - height : int - conf Files : string Operations. + VRJPFSy stem() : + setup( p : ) : v oid + start() : v oid + execute() : v oid + getViewpointChanged() : GObject* + print( os : ostream& ) : v oid + setApp( a : VRJPFApp* ) : v oid + getKey Ev ents() : v oid + sav eDef aultProperties() : v oid + loadProperties() : v oid - createSceneStr() : v oid. Attributes. # isOrdered : bool <<aliasedtype>>. Operations. list < Filter* >. + + + + + + + + + + + + + + + + + + + + + + + + + + + # #. { From intmlRT_frmSrc } objects. ints app. <<aliasedtype>>. AbsApp* { From intmlRT_frmSrc }. <<aliasedtype>>. idevices. list < Device* > { From intmlRT_frmSrc }. odevices. addIDev ice( dev : Filter* ) : v oid addODev ice( dev : Filter* ) : v oid addInT( i : Filter* ) : v oid addObject( obj : Filter* ) : v oid addConstant( id : string, v alue : string, ty pe : string ) : v oid addObjectHolder( oh : MainInTmlLoader ) : v oid TSApp( n : char* ) : f indFilter( name : char* ) : Filter* f indOrder() : v oid getOrder() : list < Filter* > * f indCy cles( f : Filter*, v isited : map < Filter*, Node * >, cy cles : list < Cy cle* > *... executeStep() : v oid executeStepExec() : v oid executeStepClean() : v oid Connect( o : Filter*, op : char*, d : Filter*, ip : char* ) : v oid Connect( oport : AbsPort*, iport : AbsPort* ) : v oid Unconnect( p1 : AbsPort*, p2 : AbsPort* ) : v oid Push( input : AbsInf o*, d : Filter*, ip : char* ) : v oid sizeIDev ices() : int sizeODev ices() : int sizeInTs() : int sizeObjects() : int sizeConstants() : int sizeObjectHolders() : int print( os : ostream& ) : v oid tsToString() : string load() : v oid getNextDelay ingFilter() : int createDelay ingFilter( op : AbsPort*, ip : AbsPort* ) : Filter*. VRJPFApp Attributes. # rootNode : pf Group* Operations. + + + + + + + + + + + + + + +. VRJPFApp( n : string ) : VRJPFApp() : ~VRJPFApp() : load() : void lookAndAssignSy stem() : InTmlSy stem* setSy stem( s : InTmlSy stem* ) : v oid init() : v oid initScene() : v oid getScene() : pf Group* apiInit() : v oid preForkInit() : v oid preDrawChan( chan : pf Channel*, chandata : MainInTmlLoader ) : v oid preSy nc() : v oid preFrame() : v oid intraFrame() : v oid. Imagen 11 Diagrama de Clases Framework Intml (VRJUGGLER + PERFORMER). Como se observa en el diagrama anterior (Imagen 11) se crearon generalizaciones para las clases existentes, generando el sistema en particular. Las nuevas clases heredan del sistema en el framework, y permiten crear el ambiente de ejecución MainInTmlLoader este es el encargado de iniciar las aplicaciones (Imagen 12)..