Desarrollo de una aplicación de realidad virtual completa (II)

Interfaces

Tal y como se ha descrito con anterioridad, los estadios de diseño de una interfaz se dividen en tres partes esenciales:

  1. decidir qué canales externos se comunicarán con los internos y en qué forma lo harán: lo que se conoce como mapeo
  2. establecer los elementos que actuarán de enlace en el exterior de la aplicación: las interfaces físicas o interfaces de hardware
  3. determinar los elementos que actuarán de enlace en el interior de la aplicación: las interfaces lógicas o interfaces de software.

La elección de las interfaces no es en absoluto trivial. Aunque estamos muy acostumbrados a ver los ratones y teclados, los monitores, los joysticks, y no nos paramos a pensar en porqué se usan y si son adecuados o no para las aplicaciones más utilizadas, esto no quiere decir que sean unas interfaces universales que valgan para todo. Tampoco, como ya se ha venido describiendo, el casco no es la solución óptima para todas las aplicaciones de realidad virtual.

Es muy importante tener una buena especificación de la aplicación que se va a desarrollar, ya sea por el tema concreto sobre el cual se basará la aplicación, o bien por el tipo de interacción deseado. A partir de una buena especificación se pueden evaluar una serie de puntos relacionados con el diseño de interfaces para la aplicación. De todas formas, no existen fórmulas mágicas ni recetas milagrosas para determinar las interfaces adecuadas para una aplicación. Por esta razón se aprecia tanto cuando se encuentra una aplicación con una interfaz adecuada.

Por otro lado, el desarrollador debe ser consciente que no existe la intuición o la interfaz intuitiva de la que tanto se habla. Esta noción de intuición es totalmente dependiente del contexto cultural y social de los usuarios y una aplicación que puede funcionar muy bien en un lugar del mundo, puede ser un fracaso en otro.

A continuación se analizan algunas de las premisas necesarias para un buen diseño de interfaces. En cada caso se verá cómo se aplican a cuatro aplicaciones concretas de las que se detallan en la sección de Aplicaciones de RV:

 

Premisas de perfil de usuario

Para empezar por un elemento que se sabe seguro intervendrá en la experiencia, siempre es bueno empezar por el usuario. Es necesario saber definir perfectamente el tipo de usuario al que irá dirigida la aplicación y esto dará una buena visión del tipo de interfaces físicas y lógicas que se podrán usar.

Por ejemplo, es imprescindible determinar la experiencia del usuario, es decir:

Otro tipo de preguntas que se pueden realizar respecto al usuario hacen referencia al tiempo que este podrá dedicar a la aplicación:

También el perfil del usuario determina si las interfaces podrán ser delicadas de manipulación o tendrán que ser robustas y pensadas para uso intensivo. Una interfaz puede ser muy adecuada a la aplicación en cuanto a funcionalidad de interacción y al contenido, pero en cambio, si ante un uso intensivo o masivo se estropea en poco tiempo, dejará de ser útil.

Finalmente también es importante conocer el contexto cultural, social y laboral de los usuarios de la aplicación. Como se ha avanzado ya, la utilización de la aplicación, de sus interfaces y el éxito del conjunto puede depender en gran medida de que este conjunto esté adaptado y preparado a las convenciones culturales, a las imágenes icónicas de cada contexto, a las cualidades laborales, a la cuestiones prácticas de cada sociedad, etc.

Las respuestas que se obtengan empezarán a restringir las muchas opciones de las que se parten inicialmente, tal y como se ha ido viendo a lo largo de esta asignatura.

Ejemplos:

TVV: En este caso, el usuario es seguramente experto en realidad virtual, ya que por el tema de la aplicación deben ser conocedores de las tecnologías avanzadas. También será usuarios expertos en el tema de la aplicación y dispondrán de tiempo de entrenamiento y, sobre todo, mucho tiempo de utilización de la aplicación realizando pruebas y experimentos. Por estas razones, las interfaces pueden ser tan complejas i delicadas como sea necesario.

CLP: En este caso el usuario será seguramente será un experto en el tema de la aplicación, pero no en temas de realidad virtual. No obstante, será un usuario cuidadoso, que podrá pasar una fase de entrenamiento y la utilizará durante periodos bastante largos. En este caso, las interfaces le tienen que recordar sus herramientas habituales para que este se sienta dentro de su contexto de trabajo.

ALA: En el caso de una atracción, el tipo de usuario es lo más abierto e indefinido posible. Por esta razón, las interfaces deben ser pensadas de forma que sean a prueba de vandalismos, malos usos o simples accidentes. Habitualmente los usuarios no dispondrán de un tiempo de entrenamiento, tampoco lo utilizarán durante períodos largos y, debido a las colas, seguramente repetirán pocas veces la utilización. Esto obliga a utilizar interfaces que sean muy sencillas, que se puedan entender en poco tiempo, que no tengan demasiada carga de un cierto contexto y que sean muy robustas.

BFL: En el caso de esta aplicación artística, el perfil de usuario es bastante abierto ya que se muestra en espacios de museos con público muy heterogéneo, pero el contexto de un museo o sala de exhibiciones, en principio, no da lugar a usos indebidos. El tipo de usuario habitualmente tendrá bastante tiempo para interactuar con la aplicación, aunque no se puede pretender que pase por un entrenamiento específico. En este contexto es probable que el usuario no vuelva a probar la aplicación más de una vez. Así, el tipo de interfaces puede ser relativamente complejo ya que el usuario tiene tiempo para explorarlas aunque no se pueda pretender que este pase por un entrenamiento específico.

De este modo se puede ver cuatro perfiles distintos de usuario que ya determinan cuatro filosofías distintas de diseño de interfaces.

 

Premisas técnicas

Por lo que se refiere a las cuestiones técnicas de orden general, se pueden analizar dos cuestiones básicas. En primer lugar si se sabe si la aplicación estará basada en una serie de propiedades físicas, entonces se deben encontrar los modelos subyacentes a estas propiedades para poder disponer de los mapeos adecuados. En caso de no conocerse el modelo o de estar diseñando una aplicación que no se base en propiedades físicas, entonces se tendrán que inventar los mapeos.

Una segunda cuestión importante es estudiar los grados de libertad requeridos por la aplicación a lo largo de su utilización. Por ejemplo, si se sabe que el usuario tendrá que navegar en un espacio 3D, no parece adecuado utilizar una interfaz física tipo ratón que sólo aporta 2 grados de libertad. Esto que parece tan lógico, por lo general no se cumple cuando se trabaja con herramientas de modelado 3D. En efecto, habitualmente, se modelan objetos en espacio 3D en aplicaciones tipo 3D Studio MAX utilizando un ratón y el teclado. De esta forma es necesario utilizar todo tipo combinaciones de teclas y botones del ratón para poder ganar grados de libertad de un modo poco práctico. En cambio sería realmente útil poder disponer siempre de un ratón 3D tipo Magellan o tipo Spaceball con los que los seis grados de libertad de transformaciones geométricas en el espacio 3D están garantizados.

Analizando cómo los ejemplos que se están siguiendo se ven afectados por estas premisas, encontramos que:

Ejemplos:

TVV: En este caso está muy claro que se están simulando procesos y fenómenos físicos y por lo tanto se deben tener muy claros los modelos que la ciencia ha ido determinando. Esto afectará las interfaces en el sentido que, de algún modo, deberán permitir controlar las variables involucradas en estos modelos: en este caso concreto la interfaz lógica será el elemento que generará los hilillos de humo virtuales que revelan si hay irregularidades en los modelos aerodinámicos. Por otro lado, los grados de libertad vienen determinados principalmente por la forma en que se deberá manipular esta interfaz lógica: en este caso concreto seis grados de libertad en el espacio 3D. Una consideración más es que en este caso la interfaz física no necesariamente debe tener ninguna relación de parecido con la interfaz lógica. Esta interfaz física tan solo debe permitir el correcto posicionamiento y orientación de la interfaz lógica.

CLP: Aquí también se están simulando procesos físicos. En este sentido este ejemplo no diefiere del anterior. En lo que si difiere es en que las interfaces físicas deben ser análogas a las lógicas, y a las que utiliza el cirujano en condiciones de operación real, ya que es imprescindible dar al cirujano la funcionalidad y las sensaciones que tendrá en una operación real.

ALA: Aquí no se está simulando nada en concreto ya que una alfombra mágica no existe. Por lo tanto lo único que se puede tener en cuenta es que la interfaz nos ha de remitir a aquello que la fantasía ha inventado y llamado una alfombra mágica. Los grados de libertad en este caso son muy triviales ya que la interfaz que controla el movimiento de la alfombra debe permitir subir, bajar, girar a derecha y a izquierda; es decir dos grados de libertad. Así pues, la interfaz es extremadamente simple, cumpliendo con lo que ya hemos observado como restricciones en el apartado anterior con las observaciones del perfil del usuario.

BFL: En este caso, aunque se verá más en detalle en la sección de “Fases de desarrollo”, decir que aquí tampoco se está simulando ningún fenómeno físico. Por esto, todo lo que sean metáforas y referentes para las interfaces, serán inventados o contextualizados a partir de un caso particular. Por otro lado se observa que los usuarios deben de interactuar a partir de una exploración del entorno proyectado en el suelo. En esta exploración se controla un foco de luz virtual (el Lightpool) y por lo tanto se requieren los tres grados de libertad de las traslaciones 3D.

 

Premisas de entrada/salidad de datos

La adecuación al formato de los datos de entrada y salida que se utilizarán en la aplicación, también es una buena forma de analizar los tipos de interfaces físicas y lógicas que pueden ser de utilidad. Por ejemplo, en el caso de tener que captar la voz del usuario para hacer un reconocimiento del habla, resulta evidente utilizar un micrófono como interfaz física. La adecuación, no obstante, no siempre es tan obvia. Por ejemplo, cuando se tiene que decidir si las imágenes de la aplicación se presentarán al usuario mediante un monitor, una pantalla de gran formato, un casco de visualización, etc. En estos casos la discriminación de las interfaces deberá hacerse por otras vías. Además, a veces estas entradas y salidas no vienen determinadas a priori, sino que vienen determinadas por la elección de interfaz. En estos casos este estudio no tiene sentido.

Ejemplos:

TVV: Está claro que en este caso los datos de entrada son los datos de manipulación de los hilillos de humo virtual. El solo hecho de hablar de manipulación ya nos remite a unos tipos concretos de interfaces físicas que permitan al usuario trabajar con la mano. Por ejemplo, para detectar la posición de la mano algún tipo de sensor de posicionamiento espacial (por ejemplo magnético). En lo que se refiere a las salidas, está claro que siendo una aplicación de visualización científica, estas tienen que ser principalmente visuales, pero aún no se tienen elementos de juicio para saber de qué tipo.

CLP: Por lo que se refiere a los datos de entrada, analizarlos ya no aporta nada nuevo, ya que antes se ha visto que las interfaces deben ser análogas a las que usa en una operación real. En cambio, en lo que se refiere a las salidas se observan unas cuestiones interesantes. Aunque la salida de imágenes se puede apreciar que és importante en esta aplicación, se observa que una importante cantidad de información que recibe el usuario cirujano viene del tacto más que de la imagen. Por esta razón es muy importante que las interfaces físicas tengan una salida de force feedback.

ALA: En este caso, tampoco aporta nada nuevo el análisis de los datos de entrada, que no haya aportado el análisis de las premisas anteriores. En cuanto a las salidas, se observa que podría ser conveniente aislar al usuario de su entorno físico, por un lado, y permitirle mirar en la dirección que desee sin tener que utilizar las manos. Por esta razón parece adecuado utilizar una interfaz tipo casco con un sensor de orientación. De esta forma tiene las manos libres para poder navegar y controlar la alfombra mágica.

BFL: Del mismo modo que en el apartado anterior se ha introducido que este es un caso especial que ya se verá en detalle más adelante, aquí tampoco podemos analizar este ejemplo con las mismas premisas. De hecho, se puede observar que ni los datos de entrada ni los de salida nos aportan realmente nada nuevo.

 

Premisas de contenido

Cuando se analiza el tema de fondo de la aplicación es muy lógico intentar adecuar las interfaces a los elementos protagonistas de la aplicación. Es lo que se conoce por metáfora. Estas pueden definir ciertas propiedades de las interfaces que ayuden a definirlas. Aunque las metáforas pueden ser tanto un estorbo como una ayuda. Una ayuda ya que nos permiten contextualizar las interfaces y nos dan una representación en el entorno virtual y una analogía con la interfaz física.

Ejemplos:

TVV:  Aunque esta aplicación tiene un contenido muy claro, este ejemplo no se beneficia de la metáfora utilizada. En efecto, por el hecho de ser una simulación, más que una metáfora se tiene una representación literal: maqueta de avión o ala -> modelo de avión o ala, viento físico -> viento virtual, hilos de humos físicos -> hilos de humo virtuales. Así pues, la interfaz debe ser también literal.

CLP: Este ejemplo también tiene un contenido claro pero también está planteando una situación de simulación, con lo que la interfaz también debe ser literal. Y de hecho, así como la literalidad en el ejemplo anterior se daba con respecto a la interfaz lógica, en este ejemplo se tiene tanto respecto a la interfaz lógica como a la física.

ALA: El caso de la alfombra voladora también está contextualizado en un contenido muy definido: la historia de Aladdín. Por otro lado, la alfombra como soporte de vuelo y sus dos extremos delanteros (según la dirección del usuario) dan lugar a que la metáfora de conducción no tenga como interfaz física adecuada un volante (que nos remite más a un coche) ni un joystick (que nos remite a la palanca de vuelo de un helicóptero). Así pues, la interfaz física debe parecer más el hacho de coger las dos puntas de la alfombra y estirar en una dirección u otra. Para esto se puede ver que se necesita una interfaz hecha a medida.

BFL: Tal y como veremos más adelante, en el proceso de desarrollo de esta aplicación, no se disponía de un contenido concreto a priori. Por esta razón no resulta relevante este análisis aquí.

 

Premisas de interacción:

El análisis del tipo de interacción es esencial en ciertas aplicaciones para poder determinar cómo deben ser las interfaces. Por ejemplo saber si la interacción será de un usuario o multiusuario. También saber si la interacción será sobre una mesa o en un entorno reducido, o bien si será una interacción en un espacio abierto. Esto se relaciona con cuestiones de motricidad del usuario (o usuarios). El desplazamiento virtual vendrá determinado por un desplazamiento físico o no. Finalmente también es importante saber si la interacción con los objetos virtuales será una interacción directa o una observación a distancia.

Ejemplos:

TVV: Las características de la visualización en esta aplicación son principalmente que, el usuario debe poder tener la percepción de profundidad para saber exactamente dónde está situando los elementos y para poder detectar fácilmente dónde se producen las turbulencias. Esto determina que la visualización que se ha dejado pendiente en apartados anteriores aquí se vea claro que debe ser estereoscópica. Pero además debe poder mover el punto de vista con facilidad para poder ver el conjunto desde el ángulo más adecuado. De este modo, hacer una visualización con monitor o proyección requiera de una interfaz extra que le permita navegar. En cambio, si la visualización se hace con un sistema tipo boom, que ya lleva incorporada la interfaz de navegación de forma natural, se tiene las dos cualidades en un solo dispositivo. El hecho de que la interacción se realice en un laboratorio de pruebas, hace que aunque no sean necesarios unos desplazamientos físicos muy grandes para realizar los experimentos, si sea posible hacer los desplazamientos que requiere un sistema tipo boom.

CLP: Aunque en la visualización de la interacción con el cuerpo virtual sería muy útil poder ofrecer al usuario una visualización en estéreo, esto sería falsear el tipo de visualización del caso real. Así, debido a que las salidas visuales del caso real son en formato vídeo sobre un monitor sin capacidad estéreo, las de la aplicación deben ser iguales. Por otro lado, la interacción en esta aplicación se desarrolla con el usuario estático en un mismo lugar. Esto determina que no sea necesaria ningún tipo de interfaz inalámbrica.

ALA: Si analizamos cuestiones como que el tipo de interacción del usuario con el entorno y la distancia media a que los objetos estarán respecto al punto de vista virtual, se puede ver que en este caso, aunque parece efectivamente necesario utilizar un casco, no es necesario que la visualización sea estereoscópica. También se puede observar que el usuario estará sentado durante toda la interacción. Por lo tanto tampoco aquí se requiere una atención especial a los dispositivos inalámbricos.

BFL: En esta aplicación el análisis de la interacción es esencial. Por un lado no hay un solo usuario sino que puede haber hasta cuatro simultáneos. En segundo lugar, los usuarios realizan desplazamientos físicos relativamente grandes (se mueven en un círculo de 6 metros de diámetro). Esto determina que en su exploración del espacio físico y virtual, la posición del usuario debe ser detectada constantemente y que los sensores deberán ser inalámbricos por cuestiones de tamaño de espacio, como por razones de posibles enredos con los otros usuarios.

 

Comportamientos

La definición de comportamientos en una aplicación de realidad virtual es de vital importancia tanto para proveer la funcionalidad necesaria a los objetos del entorno, como para describir las potencialidades del sujeto virtual. Los comportamientos son los que describen cómo se desarrollan los objetos dentro de la experiencia, cómo se interrelacionan con otros objetos y cómo reaccionan a las acciones del usuario.

Comportamientos pasivos:

Hay comportamientos que son pasivos en el sentido que son meros bucles de movimiento totalmente ajenos a lo que pueda estar pasando en el entorno. Por ejemplo si se tiene un entorno en el que aparece un molino de viento dentro de un paisaje y este molino es una mera decoración, entonces sus aspas se pueden ir moviendo para dar la sensación de que el entorno no está “muerto”, pero este movimiento no estará respondiendo o reaccionando a un viento virtual. Este tipo de comportamientos están regidos por fórmulas matemáticas que describen el movimiento con respecto al paso del tiempo, o bien son interpolaciones de posiciones y orientaciones definidas por las cuales se quiere asegurar el objeto debe pasar. Estas funcionalidades se acostumbran a asociar al objeto y se actualizan a cada ciclo de el bucle principal de la aplicación.

Por fórmulas:

El ejemplo del molino es muy claro en este sentido. La fórmula que rige su movimiento está basada en la rotación de las aspas de forma directa. Es decir, que la geometría de las aspas debe sufrir una transformación de rotación de X grados cada vez.

 
Comportamiento definido por una fórmula (en este caso tan solo una rotación).

Por interpolación:

Un ejemplo de este tipo de comportamientos es el movimiento de un coche por una trayectoria definida. Este tipo de comportamientos se acostumbra a definir exactamente igual que en las animaciones hechas con cualquier herramienta de animación tipo 3D Studio MAX. Es decir, se decide que tasa de actualización de la animación habrá (por ejemplo 20 frames por segundo); se decide cuantos frames durará toda la animación; se marcan unos frames clave o key frames que especifican puntos concretos de la animación en que el objeto debe adoptar una posición y/o orientación concreta. Entonces se pone en marcha la animación la cual realiza la interpolación en los frames que se encuentran entre dos key frames.


Puntos y direcciones de los key frames del comportamiento.

 
Interpolación lineal.


Otro tipo de interpolación: Interpolación de Bezier.

Comportamientos por reglas:

Los comportamientos realmente interesantes y complejos son aquellos que reaccionan al entorno. Serían comportamientos activos que describen el contexto instantáneo del objeto y definen una serie de acciones a seguir dependiendo de cómo se ven afectados por factores externos. Este tipo de comportamientos pueden ser definidos de diversas formas, de las cuales aquí se describirán las dos principales: por reglas y por autómatas.

En este tipo de definición de comportamientos, el desarrollador define una serie de reglas a seguir según se esté en una situación o en otra. Este sistema es en cierta forma muy intuitivo ya que obedece en gran medida a la forma en que nosotros razonamos. Las reglas tienen una estructura de entre las siguientes:

A continuación se da un ejemplo que ilustra esta forma de describir comportamientos.

Ejemplo: Comportamiento de un niño que sigue a su padre.

En este ejemplo tenemos un niño virtual que caminará al lado del usuario (el padre) donde quiera que este vaya. Para simplificar diremos que el usuario siempre camina en línea recta hacia delante.

Digamos que las reglas que rigen este comportamiento son:

Estas reglas entonces se han de programar en la aplicación mediante algún lenguaje.

Este tipo de descripción de comportamientos es muy poco claro para alguien que no tenga experiencia programando. Pero además resulta bastante fácil olvidarse de especificar alguna de las opciones posible, especialmente cuando el comportamiento es complejo y el conjunto de reglas es muy grande.

Posiblemente una mejor forma de describir comportamientos es mediante un diagrama de autómata finito (Hopcroft, 1979). Un autómata finito es un conjunto de estados en los que un objeto/personaje se puede encontrar. Estos estados se enlazan con aristas que describen las transiciones de un estado a otro. Las transiciones se realizan cuando se cumple una condición o ocurre algún evento concreto. El objeto/personaje se mantiene en un estado mientras no se cumpla alguna de las condiciones o ocurra alguno de los eventos que producen una transición de salida y le fuerce a cambiar a otro estado. Estos estados y aristas forman lo que se conoce por un grafo dirigido. Esto significa que las transiciones son unidireccionales, es decir, definen una transición en una dirección, de un estado a otro, pero no a la inversa.

De este modo, el ejemplo anterior descrito mediante un grafo de estados de un autómata finito sería:


Autómata de ejemplo: Dniño es la distancia del niño virtual al usuario (padre)

La descripción por reglas y la de autómatas finitos son equivalentes. Se puede apreciar en el ejemplo que las reglas están implícitas en el contexto de un estado y en una transición desde ese estado hasta otro.

Aunque los grafos también tienen que ser programados en la aplicación mediante algún lenguaje de programación, estos tienen la ventaja de ser muy compactos como herramienta de diseño. Por esta razón es más fácil detectar posibles transiciones olvidadas, fallos en la evolución del objeto/personaje, inconsistencia de estados, etc.

Además, al ser una representación tan visualizable del comportamiento, se prestan a ser utilizados como metáfora de descripción de comportamientos en aplicaciones de desarrollo de experiencias de realidad virtual. Por ejemplo el Motivate de Motion Factory provee un lenguaje visual que utiliza estados y transiciones para describir los comportamientos de los objetos del entorno. Una vez el desarrollador ha descrito visualmente el comportamiento Motivate se encarga de traducirlo de forma automática a un lenguaje de programación y ponerlo en marcha.

 

Modelado de objetos

Aunque ya se han visto, en el módulo sobre fundamentos tecnológicos, herramientas de modelado, sus propiedades y el tipo de optimizaciones que son necesarias en gráficos generados en tiempo real, aquí se desea resaltar estas optimizaciones en el proceso de desarrollo. En efecto, debido a que el modelado de objetos resulta tan crítico y delicado en cuanto a la adecuación de los modelos a las capacidades de cálculo y generación del sistema, esta resulta una parte muy importante del proceso de desarrollo de una aplicación de realidad virtual y se debe tener en cuenta que absorberá una buena parte del tiempo y recursos del desarrollo.

 
Modelado con una herramienta 3D.

Por otro lado, existe la posibilidad de modelar los objetos de forma algorítmica. Es decir, no mediante una herramienta de modelado, sino mediante algoritmos que, sin tener el objeto pre-modelado, lo modelan en tiempo real a través de fórmulas. Este es el caso de objetos “naturales” que pueden ser modelados, por ejemplo, mediante geometría fractal. Estos objetos fractales pueden ser montañas, árboles, nubes, etc., y se caracterizan por el hecho de ser todos distintos los unos de los otros. De este modo, si se tuviese que modelar un bosque de árboles mediante una herramienta de modelado, sería una tarea laboriosa y lenta. En cambio, si se modelan en tiempo real mediante algoritmos fractales, se le puede definir a cada árbol unas propiedades distintas de forma aleatoria y generar el bosque de forma mucho más rápida.

             
Dos árboles fractales.



    
Tres montañas fractales.

Finalmente, también exista la posibilidad de utilizar objetos de librerías. En efecto, existen librerías extensas de objetos premodelados por expertos modeladores. Modelos que ya están optimizados, probablemente con distintos LODs. De este modo el desarrollador puede escoger del catálogo el objeto que mejor se ajuste a sus necesidades, pudiendo modificarlo después para acabar de darle el detalle que acabará por adecuarlo a la aplicación. Evidentemente los tipos de objetos premodelados acostumbran a ser objetos extraídos de nuestro entorno físico: coches, aviones, edificios, animales, árboles, muebles, personas, paisajes, etc. Esto hace que la utilización de librerías sea más fácil en aplicaciones de tipo simulación, que en aplicaciones donde el entorno no tiene ningún referente físico o natural.

     
Librerías de figuras humanas.
(http://www.3-d-models.com/)

 
Librerías de plantas.

             
Librerías de vehículos militares.

 
Librerías de vehículos civiles.