Desarrollo de aplicaciones de RV

PID_00150757
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

1.Guionaje y diseño de interacción

Al igual que ocurre con el resto de los medios de comunicación audiovisual, en el planteamiento de una nueva experiencia de realidad virtual se da la disyuntiva sobre cómo iniciar el proceso, es decir, bien por el guionaje o bien por el diseño de la interacción o diseño interactivo (Ribas, J. Ignasi y otros, 1998). Pensar la RV en palabras (guión) o pensarla en imágenes (diseñando un storyboard) son, a nuestro juicio, procesos paralelos que se complementan y que deben mantenerse comunicados en el equipo durante todo el proceso de conceptualización y en las fases iniciales del desarrollo.
En el presente apartado aportaremos una adaptación y ampliación de los principios básicos de diseño de interacción y del guión multimedia descritos por Carles Sanabre (Sanabre, C., 2000) a las peculiaridades de la realidad virtual.

1.1.Principio de usabilidad

Invertir el orden de prioridades en lo que se refiere al guionaje y diseño es imprescindible para poner en práctica este principio, según el cual la toma de decisiones parte de la comprensión de los intereses del usuario y no de la "genialidad" del diseñador. Podríamos afirmar que este principio permite distinguir entre dos generaciones de diseñadores y guionistas en el mundo de la comunicación audiovisual: la generación de la comunicación de masas en la que se acentúa la subjetividad y se premia la originalidad del diseñador y la generación de la comunicación interactiva en la que se acentúa el estudio del destinatario final y se premia la innovación si ésta facilita el desarrollo del factor humano. El diseño centrado en el usuario y la personalización que permiten ciertas aplicaciones interactivas es una muestra de los logros de este principio.

1.2.Principio de adecuación

Según este principio no hay aplicaciones buenas ni malas sino adecuadas e inadecuadas. La adecuación tiene que ver con la usabilidad en tanto que la aplicación ha de orientarse hacia las necesidades y habilidades de cada persona pero se refiere, sobre todo, al criterio que permite decidir si la RV es el medio más adecuado de resolver nuestra aplicación. El espíritu de complementariedad de medios y el conocimiento de las propiedades específicas de cada medio son garantías para la adecuación.

1.3.Principio de accesibilidad

Se trata de aplicar criterios de ergonomía para evitar que las experiencias de RV repitan los errores de discriminación cometidos por la arquitectura, el medio impreso y hasta la publicación electrónica. Si se piensa en una RV sin barreras para discapacitados se pueden llegar a construir prototipos de espacios públicos digitales que, como Internet, deberían ser accesibles para todos. Para más detalles consultar Web Accessibility Initiative http://www.w3.org/WAI/

1.4.Principio de múltiple entrada

Se trata de tener presente los factores cognitivo, afectivo y de experiencia previa que determinan nuestra metacognición, es decir, la forma en la que aprendemos. La observación de la forma en la que tomamos decisiones, de cómo un color, un sonido o un movimiento desatan nuestras emociones y de cómo establecemos relaciones con nuestro conocimiento previo son las claves de este principio.

1.5.Principio de interactividad

Tener en cuenta que la RV se parece más al fútbol que al cine es importante. Si somos capaces de ofrecer unas reglas justas, un terreno de juego en condiciones y una serie de posibilidades de acción atractivas, estaremos sacando provecho de la más destacable de las características de este medio. Cuando la influencia recíproca entre la persona y el sistema fluye como si de una charla amigable o de un paseo en moto se tratara, estamos frente al mayor logro de la correcta aplicación de este principio. Del mismo modo en que la música se basa en el tiempo, y la arquitectura en el espacio, la RV se basa en la interactividad entre persona y ordenador.

1.6.Principio del placer

De momento, por fortuna, la realidad virtual es algo en lo que una persona entra voluntariamente. Las expectativas con las que se accede suelen ser altas en lo que se refiere a emoción, intensidad y entretenimiento más físico que intelectual, es decir, la gente que lo prueba está esperando "sentir algo distinto". Aunque la RV no tenga por qué siempre responder a esta expectativa, creemos oportuno destacar el principio de placer donde se unen el factor afectivo y el principio de interactividad. Del mismo modo en que una pluma estilográfica puede convertir el hecho de escribir en una experiencia rica en matices emotivos, o que una cierta prenda puede trascender la necesidad de abrigo para procurarnos sensaciones agradables que revierten en nuestra autoestima, la interacción en la RV debe tener presente este principio de placer.

1.7.Principio de interés

Del mismo modo en el que nuestro principio de placer hace referencia al cómo, más que al qué, del principio de interés se basa también en cómo se plantea algo y no tanto en qué se plantea. La capacidad de seducción intelectual por encima del tamaño de las ideas.

1.8.Principio de dinamismo

Pensar la RV como un medio y jugar con el tiempo. Dejar que las cosas sucedan de la manera que decide el usuario pero sin que tengamos la sensación de estar en un mausoleo. El principio del dinamismo promueve la sensación de vitalidad. La RV permite la introducción de ciertos grados de aleatoriedad y otros factores que diversifican las experiencias. Conseguir que alguien acabe una experiencia de RV con la sensación de que no ha agotado sus posibilidades sería el reto de este principio de dinamismo.

1.9.Principio de necesidad

Sea producto o servicio, una aplicación de RV responde a una necesidad. El producto suele partir de un diseño centrado en llenar el hueco que es la necesidad, mientras que el servicio suele partir del guión de cómo saciar la necesidad. En ambos casos (producto y servicio) la dificultad de guionaje y diseño se presenta en el compromiso entre la eficiencia y el placer con el que se cubre la necesidad.

1.10.Principio de consistencia

Como suele suceder en los videojuegos, en los que de pronto estamos en situación límite y desconocida: hemos llegado más lejos que nunca pero hemos llegado sin vidas. Las situaciones que estamos a punto de afrontar nos parecerían del todo absurdas y frustrantes si no se respetara mínimamente este principio de consistencia, según el cual, las acciones semejantes tienen consecuencias parecidas.

1.11.Principio de especificidad

La prueba de fuego para este principio es preguntarse si lo que se ha guionado y diseñado podría hacerse mejor sin la RV. Si lo que hemos elaborado se resuelve mejor con una película, un texto, un partido de fútbol o un cajero automático (por poner cuatro ejemplos) hemos fallado en nuestro proceso de toma de decisiones y en consecuencia hemos faltado al principio de especificidad.
La aplicación de estos principios es lo que distingue un buen guionaje y diseño de interacción en una aplicación de realidad virtual. Pero no se trata de aplicarlos todos siempre como un conjunto de mandamientos que hay que observar, sino más bien de ir familiarizándose con los mismos e ir madurando un criterio personal que nos permita saber qué tenemos entre manos y cuáles de estos principios debemos priorizar en cada caso.
No somos partidarios de las guías de estilo que pretenden ser leyes universales. Si las hubiera, no haría falta este curso. Lo cierto es que la realidad virtual evoluciona como medio en gran medida gracias a la suma de experiencias de las personas que, atentas a estos principios generales, toman decisiones de guionaje y de diseño que empujan los límites de lo que es y no es aceptable. Tal y como hemos visto en el ámbito de producción de nuestro esquema general de la realidad virtual, cada programador, cada guionista y cada diseñador aporta sus conocimientos, sus vivencias, sus aptitudes y sus visiones del mundo. Fruto de las diferencias entre estos puntos de vista surge la diversidad que debemos valorar como uno de los factores más gratificantes del sistema de trabajo en equipo y de autoría compartida que caracteriza a la realidad virtual.
Dada su relativa juventud, la realidad virtual es un medio que ofrece al guionista y al diseñador de interacción una amplísima vía de trabajo y grandes oportunidades de innovación. Pero es esa misma juventud del medio la que obliga a dar pasos que nadie nunca ha dado y a desarrollar un trabajo donde la intuición y el estudio juegan un papel decisivo. Estudiar la realidad virtual no es, por supuesto, como estudiar derecho canónico. Existe un número limitado de textos en castellano y, de éstos, apenas alguno se refiere a los procesos de toma de decisiones implícitos en el guionaje y el diseño.
Hemos empezado el presente apartado refiriéndonos a la disyuntiva sobre cómo iniciar el proceso, es decir, bien por el guionaje o bien por el diseño de la aplicación. Hemos dicho que el guionista tiende a pensar la RV en palabras y que el diseñador tiende a pensarla en imágenes, sonidos, etc. Para los dos es imprescindible tener en cuenta que el éxito de su trabajo en equipo depende de saber comunicarse entre sí y, sobre todo, de ser capaces de comunicarse con el ingeniero informático que se encargará paralelamente del análisis y la programación de la aplicación. Si pensamos en esta triple relación de trabajo, quizá descubriremos que existen motivos para que el guionista tenga una mejor comunicación con el ingeniero que el diseñador, ya que ambos comparten la necesidad de escribir y que, de algún modo, escribir código no es algo tan distinto a escribir un guión como lo es el pensar en estímulos. Obviamente, esta afirmación debe ser tomada con cautela, ya que el guionista escribe según una tradición humanística en la que lo que se escribe es tan importante como lo que se deja sin escribir, mientras que en el caso del escritor de código (el ingeniero informático) parte de una tradición científica donde las expresiones son estrictas, unívocas y no hay lugar para lo implícito. En este sentido, al guionista y al diseñador les une su trabajo en los matices y en lo implícito, en los silencios y los en los huecos. El diseñador a menudo desconfía del guionista, en parte por el principio de especificidad, según el cual si una experiencia de RV pudiera ser sustituida por un buen guión, ya no haría falta desarrollarla. En este sentido, el guionista debe admitir que su trabajo tiene más que ver con saber poner en pie una base estructural sobre la cual desarrollar eventos y relaciones, y no tanto con construir una narración detallada de hechos. El guionista que piensa experiencias de RV debe hacer un gran esfuerzo para aportar con su escritura elementos que sirvan como pistas sensoriales que puedan ser tomadas por el diseñador. El guionista debe estar familiarizado con las reglas del hipertexto (Kahn, P.; Peters, R., Landow, G.P. 1995) y explorar su relación con un medio multisensorial como la RV. El diseñador debe a su vez, tener muy presente que el efectismo que conlleva el uso de herramientas estándar de modelado, texturado, iluminación, síntesis y espacialización de audio, etc, debe tener un contrapunto en la sutileza de las relaciones entre objetos que forman el entorno, el sujeto virtual y la persona que interactúa con el sistema. Partir de la base de que "todo significa" es una excelente premisa para el diseñador; nada puede ponerse de forma gratuita, porque todo lo que se pone de más acaba mermando la atención que se presta a lo esencial.
Diseño de interacción y diseño de información van juntos en la realidad virtual. La interactividad no es un vehículo para obtener o depositar información en un sistema de RV, sino que es la base misma de la experiencia. No se trata, pues, de diseñar unos contenidos y luego ver cómo se meten en una aplicación de RV. Se trata más bien de que la interacción misma sea significativa y eso no es fácil de conseguir.
En el caso de que el trabajo de equipo entre guionista y diseñador de interacción esté bien coordinado, se puede intentar empezar por hacer sesiones de brainstorming en las que, según un límite de tiempo previamente establecido, se aportan ideas en torno al trabajo que se quiere realizar, pero con el compromiso de no descalificar ninguna vía de trabajo hasta no haber agotado el tiempo. En las primeras sesiones se puede seguir una metodología de "blue sky thinking", o sea, tener una mente abierta y sin obstáculos ni límites de ningún tipo, dejar que las ideas fluyan y no esperar que estén maduras y correctamente estructuradas para proponerlas. En este apartado inicial sólo deberían tenerse en cuenta los principios de placer, interés y especificidad. Las ideas se pueden ir apuntando en un papel de forma muy escueta y por orden de aparición. Estos documentos de trabajo pueden tener un formato informal, pero es importante que aparezcan los nombres de los participantes en la tormenta de ideas y la fecha y lugar en la que se ha llevado a cabo. Estos memorándums de las sesiones se irán archivando, ya que son una buena referencia interna de documentación: en ellos se puede rastrear la evolución de los conceptos fundamentales, de los referentes y de las intenciones que ha ido tomando el trabajo. En esta primera fase de conceptualización, el guionista y el diseñador de interacción pueden ir aportando referentes de todo tipo y organizar sesiones de visionado de imágenes, videos, escucha de música o lecturas que puedan aportar alguna pista de qué dirección se pretende dar al trabajo. Todos estos referentes culturales, sean propiamente referentes de la realidad virtual o no, tienen un gran valor en tanto que aportan un sustrato o caldo de cultivo donde irán germinando las ideas. En este punto es ya aconsejable mantener entrevistas con el ingeniero informático que se ocupará del desarrollo de la aplicación. La intervención de dicho ingeniero en calidad de analista es muy provechosa ya desde estos momentos tempranos de conceptualización. Esta primera fase terminará cuando se haya pactado un título provisional para el proyecto y se haya redactado un par de líneas con la descripción de la aplicación de RV que se va a desarrollar.
Más adelante, en las sesiones intermedias se debe cambiar de metodología y entrar en una dinámica más estructurada, en la que las aportaciones ya llevan una dirección concreta y donde no es bueno cuestionar el título y la primera descripción del trabajo, sino que se debe procurar hacer esquemas y descripciones más detalladas, en las que se pueda comprobar si las ideas iniciales son susceptibles de ser desarrolladas satisfactoriamente en el plazo de entrega fijado y con los medios y conocimientos tecnológicos disponibles. Sin abandonar los tres principios con los que se ha iniciado la conceptualización (placer, interés y especificidad), en este nuevo apartado se debe prestar mucha atención a los principios de usabilidad, adecuación y necesidad. En este apartado se puede seguir trabajando en sesiones conjuntas, pero es importante que entre éstas exista una buena dedicación de los equipos de guionaje y diseño de interacción a sus labores de taller y de estudio. En las sesiones de trabajo conjunto de este apartado hay un objetivo principal que es el de consensuar un plan de trabajo pautado por un calendario que todos puedan asumir. Si el calendario es demasiado exigente o no es asumido por todas las partes implicadas, es muy probable que todo termine en un fracaso general o, por lo menos, que alguien del equipo se desentienda de sus obligaciones y genere contratiempos. Esta fase culmina, pues, con la redacción del plan de trabajo en el cual se detallan las distintas actuaciones de cada integrante del equipo, esto es: a partir de la definición ampliada de la propuesta se reparten las tareas en el tiempo, empezando por un primer nivel de bocetos de objetos que formarán los distintos entornos, con ideas de sus formas, funciones y comportamientos. Un primer guión general de interacción que puede hacerse en base a un esquema de interacción persona-ordenador (IPO) que se desarrolla en función del tipo de aplicación, el contexto de aplicación, el tipo de plataforma que se ha de utilizar para el desarrollo (ámbito de producción) y para el uso (ámbito de recepción), etc. En la definición de este plan de trabajo es ya imprescindible haber tenido reuniones con el ingeniero informático responsable, quien garantizará la viabilidad.
Como ya hemos ido repitiendo en distintos módulos anteriores, la RV es una experiencia basada en la generación de estímulos, a diferencia del multimedia que es una aplicación basada en la integración de medios. Esta diferencia es muy notoria en la tercera fase del guionaje y diseño de interacción ya que, a diferencia de otros medios en los que se pueden separar las tareas de guionaje y diseño, en el caso de la RV es aconsejable mantener una dinámica de trabajo conjunto en reuniones en las que se ponen en juego mentalmente o con sencillas maquetas los elementos que se van definiendo. Todas las estrategias de trabajo son aplicables en esta fase: desde nuevos brainstormings sobre aspectos concretos, hasta representaciones basadas en las situaciones que se están trabajando en el guión, pasando por toda clase de bocetos, maquetas y esquemas que ayuden al equipo a tener claro en todo momento el espíritu del proyecto y el progreso de trabajo de los distintos implicados. Esta etapa termina cuando el guión está perfectamente concretado en los distintos aspectos que implica la definición de los entornos detallada con las cualidades de cada objeto, las leyes que rigen el conjunto, la definición de los sujetos virtuales que se proponen al usuario, etc. Toda esta fase viene marcada por los principios de interactividad, dinamismo y consistencia, que se suman al resto para ir cerrando el guionaje y diseño de interacción y pasar a las fases de diseño de interfaces, programación de comportamientos y modelado, de las que consta la producción de realidad virtual propiamente dicha.

2.Interfaces

Tal y como se ha descrito en el módulo 2, 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 por qué 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 el casco, como ya se ha venido describiendo, 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 de 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 vistas en el módulo 5:

  • una aplicación de visualización: el túnel de viento virtual (TVV),

  • una aplicación médica: la de cirugía laparoscópica (CLP),

  • una aplicación lúdica: la atracción de Aladdin de Disney (ALA),

  • una aplicación artística: la de "El Ball del Fanalet o Lightpools" (BFL).

2.1.Premisas de perfil de usuario

Para empezar por un elemento que se sabe seguro que 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:

  • ¿será el usuario el público en general que se acercará a la aplicación sin conocimiento alguno del tema de la aplicación y sin ningún tipo de experiencia en aplicaciones de realidad virtual?

  • ¿será un experto en el tema, de modo que conocerá perfectamente los elementos, las acciones y las cuestiones implícitas?

  • ¿será un experto en aplicaciones de realidad virtual, aunque no del tema, pero se le podrán proponer periféricos sofisticados?

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

  • ¿podrá pasar el usuario un cierto tiempo de aprendizaje y adaptación a la aplicación?

  • ¿será el usuario un transeúnte casual en un lugar público que tendrá que hacer cola para acceder a la aplicación y tendrá que poder interactuar inmediatamente en el momento en que le toque?

  • ¿dispondrá el usuario de varias sesiones de uso de la aplicación, de forma que se irá convirtiendo en experto?

También el perfil del usuario determina si las interfaces podrán ser delicadas respecto a su 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 parte inicialmente, tal y como se ha ido viendo a lo largo de esta asignatura.

2.2.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án 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 y delicadas como sea necesario.

  • CLP: En este caso el usuario 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 éste 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 éste pase por un entrenamiento específico.

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

2.3.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ónn 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 de 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 se ven afectados los ejemplos que se están siguiendo por estas premisas, encontramos que:
2.3.1.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á a las interfaces en el sentido de 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 como 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 sólo 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 difiere del anterior. En lo que sí 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 cabe 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 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.

2.4.Premisas de entrada/salida 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.
2.4.1.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, éstas 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 es 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.

2.5.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. Éstas 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.
2.5.1.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í, 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 debe ser, asimismo, 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 hecho 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 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í.

2.6.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.
2.6.1.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 requiere 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 tienen 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, sí 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 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.

3.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.

3.1.Comportamientos pasivos

Hay comportamientos que son pasivos en el sentido de 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 que se quiere asegurar que el objeto debe pasar. Estas funcionalidades se acostumbran a asociar al objeto y se actualizan a cada ciclo del bucle principal de la aplicación.

3.2.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 sólo una rotación).
Comportamiento definido por una fórmula (en este caso tan sólo una rotación).

3.3.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 qué tasa de actualización de la animación habrá (por ejemplo 20 frames por segundo); se decide cuántos 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.
Izquierda: puntos y direcciones de los key frames del comportamiento; centro: interpolación lineal; derecha: otro tipo de interpolación: Interpolación de Bezier.
Izquierda: puntos y direcciones de los key frames del comportamiento; centro: interpolación lineal; derecha: otro tipo de interpolación: Interpolación de Bezier.

3.4.Comportamientos por reglas

Los comportamientos realmente interesantes y complejos son aquellos que reaccionan ante el 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:

  • si "el objeto se encuentra en un contexto C" y "ocurre un evento E"entonces "realizar la acción A";

  • si "el objeto se encuentra en un contexto C" y "ocurre un evento E"entonces "cambiar a contexto C1".

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 a un niño virtual que caminará al lado del usuario (el padre) donde quiera que éste vaya. Para simplificar diremos que el usuario siempre camina en línea recta hacia delante.
Digamos que las reglas que rigen este comportamiento son:

  • si {niño piernas juntas} y {distancia niño a usuario} es mayor que máximo entonces {niño avanza pierna derecha};

  • si {niño pierna izquierda delante} y {distancia niño a usuario} es mayor que máximo entonces {niño avanza pierna derecha};

  • si {niño pierna derecha delante} y {distancia niño a usuario} es mayor que máximo entonces {niño avanza pierna izquierda};

  • si {niño pierna izquierda delante} y {distancia niño a usuario} es menor que máximo entonces {niño junta piernas};

  • si {niño pierna derecha delante} y {distancia niño a usuario} es menor que máximo entonces {niño junta piernas}.

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).
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, éstos 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.

4.Modelado de objetos

Aunque ya se han visto herramientas de modelado en el módulo sobre Fundamentos tecnológicos, 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, ésta 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.
Modelado con una herramienta 3D.

4.1.Modelado algorítmico

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.
Dos árboles fractales.
Tres montañas fractales.
Tres montañas fractales.

4.2.Objetos de librerías

Finalmente, también existe 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 LOD. 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.
Librerías de figuras humanas.
Librerías de plantas.
Librerías de plantas.
Librerías de vehículos militares.
Librerías de vehículos militares.
Librerías de vehículos civiles.
Librerías de vehículos civiles.

5.Fases de desarrollo

El desarrollo de aplicaciones de realidad virtual ha evolucionado claramente de las estrategias de desarrollo de aplicaciones informáticas en general. Las fases de desarrollo parecen claras cuando el contenido del tema en el cual se basa la aplicación, guía todo el proceso de desarrollo (Kalawsky, 1993; Waxelblat, 1993; Loeffler, Anderson, 1994; Bryson, 1995; Earnshaw, Vince, Jones, 1995). El tema define un contexto y el contexto es determinante en la elección de la metáfora utilizada, en los elementos de interacción y en la interfaz (Erickson, 1990). Esta estrategia, llamada content-driven (o dirigida por el contenido) se adapta de forma natural al desarrollo de aplicaciones de realidad virtual en un amplio abanico de ámbitos: desde simulaciones científicas hasta diseños arquitectónicos.
No obstante la aproximación content-driven presenta limitaciones cuando se experimenta con nuevas aproximaciones al diseño de interfaces o cuando se exploran las propiedades específicas de la realidad virtual como medio de producción audiovisual (y artística) (Parés, Parés, 1993; 1994a,b; 1995; 1996a,b; 1997). Restricciones que veremos más adelante, pero que para superarlas se ha definido una estrategia llamada interaction-driven (o dirigida por la interacción) (Parés, Parés, 2000; Parés, 2001) que plantea el análisis de la aplicación partiendo del tipo de interacción que el desarrollador desea conseguir y de la forma como el usuario se relacionará con la experiencia.
En este apartado se definirán las fases de desarrollo de una aplicación de realidad virtual según las estrategias content-driven e interaction-driven, y posteriormente se compararán y se analizarán las diferencias entre ambas.
Pero antes se explicarán las fases para después poderlas ordenar según cada estrategia. Algunas ya se han visto con anterioridad y por lo tanto sólo se listarán. Otras, en cambio, no se han visto aún y por eso se explicarán con más detalle. Unas de estas últimas se engloban dentro de una estructura esencial de cualquier aplicación.

5.1.El bucle principal de la aplicación (simulation loop)

Esta estructura es la que repite una serie de acciones a lo largo de la vida de una experiencia de realidad virtual. La repetición de las acciones tiene un significado muy importante, ya que puede determinar la medida temporal de la aplicación definiendo ciclos de una cierta duración; o bien estos ciclos del bucle pueden adaptarse a un reloj interno concreto que determina la evolución temporal de la aplicación. Estas acciones gestionan el control de toda la aplicación a cada ciclo, es decir, en cada unidad de tiempo. Las partes esenciales son:

  • Gestión de sensores: lectura de los datos de entrada provenientes de los sensores que detectan los movimientos y decisiones del usuario.

  • Renovar estado del usuario: modificar las propiedades, situación y estado general del sujeto virtual, a partir de los datos captados por los sensores.

  • Renovar estado de los objetos: modificar las propiedades, situación y estado general de los objetos virtuales, a partir de sus algoritmos de comportamiento y las decisiones que ocurran.

  • Determinar interacciones: detectar si en las modificaciones del usuario y de los objetos virtuales ha ocurrido alguna interacción que provoque una modificación del estado de la aplicación y sus elementos.

  • Gestión de las salidas sensoriales: generar todos los estímulos que intervengan en la experiencia (imágenes, sonidos, movimientos, etc.) para que el usuario reciba el feedback adecuado que el contexto instantáneo pida.

Esta estructura se mantiene constante en cualquier tipo de aplicación de realidad virtual y se estructura en torno a un conjunto de fases importantes de desarrollo que incluye:

  • identificar los tipos y procedencias de los datos utilizados,

  • identificar los procesos involucrados en la aplicación.

Con respecto a las fases que ya se han visto con anterioridad, se tiene:

  • Diseño de las interfaces (físicas, lógicas y mapeos)

  • El modelado de los objetos

  • El diseño de comportamientos y el diseño de estímulos

5.2.Aproximación por contenido

Teniendo claras las fases de desarrollo vistas, se puede apreciar que son fases de relativamente bajo nivel, en el sentido en que describen acciones ya muy a nivel de producción final, y que no incluyen toda la estructuración del contenido, del contexto ni del guionaje. Las fases que sí lo estructuran son fases de alto nivel que suelen realizarse antes que las de bajo nivel, y debido a esta organización definen una estrategia llamada content-driven. Es decir, precisamente porque se empieza por un nivel de abstracción alto: analizando el contenido y el contexto de la aplicación, y va bajando hasta la implementación y puesta en marcha. En esta estrategia la secuencia de fases que define el proceso de desarrollo es el siguiente:

  • Definición del tema concreto de la aplicación: por ejemplo, entrenamiento de vuelo de un airbus, entrenamiento de cirugía laparoscópica, análisis de las turbulencias generadas por un perfil de ala, etc.

  • Definición del tipo de aplicación: interacción explorativa, manipulativa o contributiva.

  • Identificación del tipo de usuario: por ejemplo, experto en el tema, parcialmente conocedor, público en general, etc.

  • Identificación de los objetos virtuales necesarios: por ejemplo, objetos del paisaje (vegetación, edificios, etc.), órganos internos, modelo de un ala, etc.

  • Identificación de los datos de trabajo: datos de entrada, resultados intermedios, resultados finales, tipo de datos, etc.

  • Identificación de los procesos: algoritmos, cálculos, comportamientos, leyes subyacentes, etc.

  • Identificación de los tipos de interfaces de entrada: tipos de sensores, interfaces de usuario, enlaces y mapeos, etc.

  • Identificación de los tipos de interfaces de salida: presentación de los resultados, tipos de periféricos de visualización, audición, etc.

  • Identificación de las herramientas de modelado de objetos: modelado geométrico, algoritmos generativos, herramientas CAD, escáner, etc.

  • Identificación de las herramientas de desarrollo: librerías de programación, entornos de desarrollo, drivers de periféricos, etc.

Este tipo de desarrollo se adapta perfectamente a toda aplicación informática basada en un cierto contenido o tema, debido a que: (a) se ajusta al análisis de toda la aplicación informática en general, (b) tiene un parecido notable con las fases de diseño de una simulación y (c) porque está guiado por un objetivo concreto: el tema de la aplicación.
Cabe resaltar que estos pasos no son necesariamente secuenciales. Algunos pueden realizarse en paralelo con otros que se encuentran en su entorno inmediato en la lista.

5.3.Aproximación por interacción

Aunque muchas aplicaciones de realidad virtual, una gran mayoría de hecho, siguen la estrategia content-driven, existen muchos casos en los que puede ser útil desarrollar una aplicación concentrándose en cómo el usuario deberá interactuar con la aplicación. Es decir, analizando las interfaces, la interacción con los objetos, la exploración/manipulación/contribución del usuario, de forma que los resultados obtenidos permitan que aflore de forma espontánea el tema, el contenido, la atmósfera, el tono, el "aroma", etc., de la experiencia.
Este puede ser el caso cuando, por ejemplo, los desarrolladores están interesados en comprobar ciertas teorías de interacción a través de una serie experimentos. Las experiencias resultantes son contextualizadas solamente cuando la aplicación ya debe ser formateada para ser presentada a los usuarios. Otro caso en que esta estrategia puede ser de utilidad es en producciones artísticas donde el artista desea exponer conceptos y relaciones a través de la interacción propuesta, en lugar de exponer un tema concreto o trabajar un cierto valor estético.
Esta estrategia interaction-driven es, en cierto modo, una inversión de la content-driven, ya que empieza identificando interfaces, sensores y mapeos, así como procesos y comportamientos, en lugar de empezar por la definición del tema de la aplicación.
Así pues, los pasos de la estrategia de desarrollo interaction-driven están organizados en el siguiente orden:

  • Identificación de los tipos de interfaces de entrada: tipos de sensores, interfaces de usuario, enlaces y mapeos, etc.

  • Identificación de los tipos de interfaces de salida: presentación de los resultados, tipos de periféricos de visualización, audición, etc.

  • Identificación del tipo de usuario: por ejemplo, experto en el tema, parcialmente conocedor, público en general, etc.

  • Definición del tipo de aplicación: interacción explorativa, manipulativa o contributiva.

  • Definición del tema concreto de la aplicación: analizando el tipo de interacción, se encuentra una metáfora relacionada.

  • Identificación de los procesos: algoritmos, cálculos, comportamientos, leyes subyacentes, etc.

  • Identificación de los objetos virtuales necesarios: objetos relacionados con la metáfora de interacción, aunque estos pueden ser completamente abstractos.

  • Identificación de los datos de trabajo: datos de entrada, resultados intermedios, resultados finales, tipo de datos, etc.

  • Identificación de las herramientas de modelado de objetos: modelado geométrico, algoritmos generativos, herramientas CAD, escáner, etc.

  • Identificación de las herramientas de desarrollo: librerías de programación, entornos de desarrollo, drivers de periféricos, etc.

Esta estrategia facilita el diseño de interfaces lógicas que no necesariamente representan interfaces físicas, ya que no hay un conjunto que las determine a priori. Esto también abre la posibilidad de definir mapeos que no correspondan a modelos de eventos de nuestro entorno físico.
La libertad de diseño de estos dos elementos de una aplicación de realidad virtual facilita el desarrollo de interacciones innovadoras, incluso al extremo de diseñar experiencias con estímulos que no estén formados como sistema coherente en el sentido en que una aplicación content-driven forzaría.
En este caso, la metáfora y el contexto de la aplicación para la interacción debería emerger a partir de un estudio detallado de la interacción propuesta, que esboza analogías trazadas desde esta interacción hasta el contexto del cual la metáfora ha sido extraída.

5.4.Evaluando la diferencia

La idea que late tras la estrategia interaction-driven es la de concentrarse en la interacción del usuario en vez de concentrarse en un contenido especificado por el tema de la aplicación. De hecho, en la estrategia interaction-driven no existe a priori un tema para la aplicación. Esto aporta una gran libertad de diseño de interfaces y relaciones de interacción a los desarrolladores, con lo cual se pueden estudiar las formas en que los usuarios se aproximan y reaccionan a las aplicaciones de realidad virtual.
Utilizando los cuatro ejemplos del apartado de interfaces:

  • una aplicación de visualización: el túnel de viento virtual (TVV),

  • una aplicación médica: la de cirugía laparoscópica (CLP),

  • una aplicación lúdica: la atracción de Aladdin de Disney (ALA),

  • una aplicación artística: la de "El Ball del Fanalet o Lightpools" (BFL).

se puede ver claro en las tres primeras, cómo el contenido guía el diseño.
5.4.1.TVV

  • Definición del tema concreto de la aplicación: La simulación de un túnel de viento.

  • Definición del tipo de aplicación: interacción contributiva.

  • Identificación del tipo de usuario: experto en el tema.

  • Identificación de los objetos virtuales necesarios: modelo de un ala o un fuselaje.

  • Identificación de los datos de trabajo: datos sobre el flujo del viento, sobre las posiciones de emisión de los hilos de humo, datos de forma del modelo.

  • Identificación de los procesos: algoritmos de dinámica de fluidos, cálculos de aerodinámica, comportamientos de los hilos de humo, leyes subyacentes de resistencia y dinámica de partículas.

  • Identificación de los tipos de interfaces de entrada: sensores de posición de la mano (como posicionador de los emisores de hilos de humo y como modificadora del perfil del modelo), emisores de hilos de humo virtual como interfaces de usuario.

  • Identificación de los tipos de interfaces de salida: visualización sobre un boom de todos los procesos de aerodinámica.

  • Identificación de las herramientas de modelado de objetos: modelado geométrico para el modelo de ala o de fuselaje, algoritmos generativos para los hilos de humo.

  • Identificación de las herramientas de desarrollo: librerías de programación.

5.4.2.CLP

  • Definición del tema concreto de la aplicación: La simulación de una operación quirúrgica por laparoscopia.

  • Definición del tipo de aplicación: interacción contributiva.

  • Identificación del tipo de usuario: experto en el tema.

  • Identificación de los objetos virtuales necesarios: modelo de un cuerpo humano con órganos internos.

  • Identificación de los datos de trabajo: datos sobre forma, consistencia y posición de los órganos internos, datos sobre la posición de las herramientas virtuales, datos sobre el daño a reparar, etc.

  • Identificación de los procesos: comportamientos de deformación, incisión etc., leyes subyacentes de resistencia.

  • Identificación de los tipos de interfaces de entrada: sensores para las herramientas físicas y mapeos a las herramientas virtuales.

  • Identificación de los tipos de interfaces de salida: visualización sobre un monitor, como ocurre en las operaciones reales.

  • Identificación de las herramientas de modelado de objetos: modelado geométrico para todos los objetos.

  • Identificación de las herramientas de desarrollo: librerías de programación.

5.4.3.ALA

  • Definición del tema concreto de la aplicación: Un recorrido por el poblado de Aladdin.

  • Definición del tipo de aplicación: interacción explorativa.

  • Identificación del tipo de usuario: público en general.

  • Identificación de los objetos virtuales necesarios: modelos de los edificios del poblado, de los personajes que se encuentran, de la alfombra mágica, etc.

  • Identificación de los datos de trabajo: datos sobre los ámbitos del poblado (donde ocurren cosas distintas).

  • Identificación de los procesos: algoritmos de movimiento de la alfombra mágica, comportamientos de los personajes.

  • Identificación de los tipos de interfaces de entrada: sensores para que el usuario controle la alfombra mágica, sensores de orientación de la cabeza.

  • Identificación de los tipos de interfaces de salida: visualización sobre un casco.

  • Identificación de las herramientas de modelado de objetos: modelado geométrico para todo el entorno.

  • Identificación de las herramientas de desarrollo: librerías de programación.

En cambio, en el caso del último, aunque parezca que el tema del "El baile del farolillo" (un baile de fiesta típico catalán, en el que las parejas bailan con un farolillo de papel con una vela encendida) sea el que guió el desarrollo, esta aplicación fue desarrollada mediante la estrategia interaction-driven. Es decir, no se tenía ningún tema de fondo, sino que en base a la interacción diseñada, el tema apareció de forma espontánea. Debido a que esta estrategia es menos conocida que la content-driven, analizaremos el siguiente ejemplo con más detenimiento:
5.4.4.BFL
Identificación de los tipos de interfaces de entrada y salida: El objetivo principal era el de diseñar una aplicación multiusuario que permitiese entablar interacción social entre los usuarios y les aislase como hacen la mayoría de aplicaciones de realidad virtual multiusuario.
De este modo se desarrolló una interfaz donde el entorno fuera proyectado sobre el suelo desde el techo y fuese, asimismo, lo suficientemente grande como para contener hasta cuatro usuarios. Los usuarios deberían explorar el entorno teniendo una visión parcial de éste y viéndose forzados a moverse por todo el espacio para descubrir los elementos. Por lo tanto, serían necesarios unos sensores de posicionamiento espacial, inalámbricos.
Al mismo tiempo, las interfaces lógicas debían ser una "ventana" de exploración a través de la cual cada usuario pudiese descubrir el entorno. La idea de exploración y de "ventana" dio lugar a la interfaz lógica de un foco de luz virtual.

  • Identificación del tipo de usuario: público en general.

  • Definición del tipo de aplicación: interacción contributiva: se deseaba que los usuarios pudiesen modificar el entorno de forma que sus acciones afectasen a los demás usuarios.

  • Definición del tema concreto de la aplicación: Hasta este punto, el tema de fondo no aparece en la aplicación. Basándose en los razonamientos de las fases anteriores se encontró apropiada la metáfora de la pista de baile para esta experiencia multiusuario. Se eligió el baile de fiesta catalán "El Ball del Fanalet" por las siguientes razones:

    • Es un baile social → promovía la interacción entre los usuarios.

    • La pareja sostiene un farolillo de papel con una vela encendida → aporta la metáfora adecuada para el foco de luz virtual o lightpool, con el cual los usuarios pueden explorar el entorno.

    • La luz virtual del fanalet serviría como energía para desencadenar cambios en el entorno, actuando de elemento de interacción

  • Identificación de los procesos: los algoritmos principales son los de los comportamientos de los lightpools y de los objetos del entorno. Éstos fueron desarrollados a partir de una descripción a través de autómatas finitos.

  • Identificación de los objetos virtuales necesarios: aunque los objetos del entorno no pretendían representar nada en concreto (formas abstractas), éstos fueron modelados en un modelador 3D. No obstante, estos objetos sufren transformaciones en tiempo real dentro del entorno.

  • Identificación de los datos de trabajo: los datos de entrada son principalmente los datos de posición de los sensores, mediante los cuales el usuario puede explorar y alterar el entorno.

  • Identificación de las herramientas de modelado de objetos: como ya se ha comentado, se utilizó un modelador 3D estándar.

  • Identificación de las herramientas de desarrollo: se utilizaron librerías de programación para lenguaje C.

De este modo se puede ver cómo la metáfora y el contenido temático de la aplicación aparecen a medio camino del desarrollo, una vez se ha especificado y diseñado la interacción y las interfaces.
Queda claro que se trabaja sobre marcos de referencia muy diferentes cuando se está en content-driven, con respecto a cuando se está en interaction-driven. Prácticamente todo el planteamiento se invierte. No se puede decir que una estrategia sea mejor que la otra en general. Cada estrategia es adecuada en situaciones distintas en función de lo que se quiera priorizar: el tema y contenido o la interacción y las interfaces.
Resulta importante recalcar que éstas no son las únicas estrategias que se podrían utilizar. Simplemente decir que son las únicas que hasta el momento se han formalizado.

6.Equipo de producción

La complejidad de producción de una aplicación de realidad virtual (una producción audiovisual digital interactiva, generada en tiempo real) es en muchos casos del orden de complejidad de una producción cinematográfica. Por ejemplo, la producción de un videojuego puede durar entre uno y dos años, con una cantidad de personal y recursos involucrados realmente impresionante.
Una producción de una experiencia de realidad virtual compleja es inaccesible a un solo desarrollador o a un solo creativo. Es necesario montar un equipo realmente interdisciplinario para poder conseguir controlar los múltiples aspectos que se han visto a lo largo de esta asignatura. Los distintos expertos deben trabajar coordinados bajo una estrategia de desarrollo y las órdenes de un director de proyecto.
Este equipo debería constar, de los siguientes expertos:

  • Guionista/s: Quien define el sentido general de la experiencia y/o el tema principal. Define aquello que el usuario podrá hacer, ver, oír, etc. Define los elementos que intervienen, objetos, entornos, comportamientos, etc., a nivel descriptivo.

  • Coordinador técnico: Quien conoce toda la tecnología y tiene una visión global de todo lo que se ha de desarrollar. Debe tener capacidades de análisis de problemas, de diseño de algoritmos y de coordinación de equipo. También debe entender los conceptos de contenido de la producción y entenderse con el coordinador artístico.

  • Coordinador artístico: Quien controla que la experiencia consiga los objetivos de concepto y estética (en el sentido de "look" o percepción) que se habían marcado. Debe tener buenas nociones de la tecnología y entenderse bien con el coordinador técnico.

  • Programador/es: Quien conoce a fondo el entorno de desarrollo para poder desarrollar eficientemente el código de los algoritmos diseñados, extrayendo toda su potencia.

  • Diseñador/es: Quien sabrá imaginar y consolidar el diseño de la experiencia, tanto a nivel interno de contenidos con los objetos y entornos virtuales, como a nivel externo de la instalación.

  • Modelador/es: Quien conoce a fondo las herramientas de modelado para poder generar y optimizar los objetos necesarios en la experiencia.

  • Sonorizador/es: Aquel que conoce a fondo el diseño de sonidos y su incorporación o generación en tiempo real en la experiencia.

  • Experto en Interfaces: Aquel que sabe diseñar la mejor forma de interacción para la experiencia concreta. Debe ser experto en interacción persona-ordenador y tener buenos conocimientos de ergonomía y antropometría.

  • Experto en Electrónica: Quien sabe diseñar toda el circuito y parte eléctrica de las interfaces físicas para darles la funcionalidad necesaria, adaptarlas a las necesidades especificadas por el experto en interfaces y poderlas conectar al sistema.

En producciones medianas y pequeñas, no todas las figuras serán personas distintas, pero es realmente muy difícil que una única persona pueda realizar todas las tareas ella sola. Evidentemente, esto pone en una situación difícil al científico o técnico puro, o al artista o diseñador puro que deseen aproximarse a este medio para realizar una aplicación o experiencia de realidad virtual que les permita conseguir sus objetivos.

Actividades

Se propone aplicar las fases de desarrollo descritas en este módulo a la aplicación de realidad virtual seleccionada en la primera práctica, analizando y desarrollando los siguientes puntos:

  • Qué aproximación de guionaje sería adecuada.

  • Qué estrategia de desarrollo se adaptaría mejor.

Bibliografía

Austakalnis, S.; Blatner, D. (1992). El Espejismo de Silicio. Arte y ciencia de la Realidad Virtual. Barcelona: Página Uno, S.L.
Bryson, S. (1995). "Approaches to the successful design and implementation of VR applications". En: Earnshaw, R.A.; Vince, J.A.; Jones, H. (ed.).Virtual Reality Applications. Londres: Academic Press Ltd.
Burdea, G.C.; Coiffet, P. (1994). Virtual Reality Technology. Nueva York: John Wiley & Sons Inc.
Earnshaw, R.A.; Gigante, M.A.; Jones H.(ed.) (1993). Virtual Reality Systems. Londres: Academic Press Ltd.
Earnshaw, R.A.; Vince, J.A.; Jones, H.(ed.) (1995). Virtual Reality Applications. Londres: Academic Press Ltd.
Erickson, T.D. (1990). "Working with Interface Metaphors" (11.ª ed., 1998, pág. 65-73). En: Laurel, B. (ed.).The Art of Human Computer Interface Design. Reading, MA: Addison Wesley.
Fisher, S. (1990). "Virtual Interface Environments" (11.ª ed., 1998, pág. 423-438). En: Laurel, B. (ed.).The Art of Human-Computer Interface Design. Reading, MA: Addison-Wesley.
Hoberman, P.; Parés, N.; Parés, R. (1999). "El Ball del Fanalet or Lightpools" (pág. 270-276). En:Proceedings of International Conference on Virtual Systems and Multimedia. Dundee, UK: VSMM'99.
Hoberman, P.; Parés, N.; Parés, R. (1999). "Lightpools o El Ball del Fanalet". En:CEIG'99. IX Congreso Español de Informática Gráfica. Jaén: Universidad de Jaén.
Hopcroft, J.E. (1979). Introduction to Automata Theory, Languages and Computation. Reading, MA: Addison-Wesley Inc.
Kahn, P.; Peters, R., Landow, G.P. (1995). "Three Fundamental Elements of Visual Rhetoric in Hypertext".Designing User Interfaces for Hypermedia, Research Reports ESPRIT. Springer Verlag.
Kalawsky, R.S. (1993). The Science of Virtual Reality and Virtual Environments. Reading, MA: Adison-Wesley Ltd.
Laurel, B.(ed.) (1990). The Art of Human-Computer Interface Design(11.ª ed., 1998). Reading, MA: Addison-Wesley.
Loeffler, C.E.; Anderson, T.(ed.) (1994). The Virtual Reality Casebook. Nueva York: Van Nostrand Reinhold.
Magnenat-Thalmann, N.; Thalmann, D. (1993). "The Artificial Life of Synthetic Actors" (vol. J76-D-II, núm. 8). En:IEICE Transactions. Japón.
Magnenat-Thalmann, N.; Thalmann, D.(ed.) (1994). Artificial Life and Virtual Reality. Londres: John Wiley & Sons Inc.
Magnenat-Thalmann, N.; Thalmann, D.(julio, 1995). "Digital Actors for Interactive Television". En:Proceedings IEEE, Special Issue on Digital Television, Part 2.
Mandelbrot, B.B. (1982). The Fractal Geometry of Nature. Mountain View, CA: W.H. Freeman & Co.
Motion Factory.Motivate Intelligent Digital Actor System[Softwarede diseño de comportamientos].http://www.motion-factory.com/
Mullet, K.; Sano, D. (1994). Designing Visual Interfaces: Communication Oriented Techniques. Mountain View. CA: SunSoft Press.
Multigen-Paradigm, Inc.MultiGen[Softwarede modelado y optimización de objetos virtuales].
Noser, H.; Thalmann, D.(junio, 1996). "The Animation of Autonomous Actors Based on Production Rules". En:Proceedings Computer Animation '96. IEEE Computer Society Press.
Parés, N.; Parés, R. (1993). "Galeria Virtual". En:Proceedings First Eurographics Workshop on Virtual Environments. Barcelona: Eurographics.
Parés, N.; Parés, R. (1994). "Galeria Virtual: a platform for non-limitation in contemporary art?". En:Proceedings Virtual Reality and Applications. Leeds, UK: Computer Graphics Society.
Parés, N.; Parés, R. (1994). "Galeria Virtual". En:Anys 90. Disitància Zero. Barcelona: Generalitat de Catalunya. Departament de Cultura.
Parés, N.; Parés, R. (1995). "Galeria Virtual: a platform for non-limitation in contemporary art?". En: Earnshaw, R.A.; Vince, J.A.; Jones, H. (ed.).Virtual Reality Applications. Londres: Academic Press Ltd.
Parés, N.; Parés, R. (1996). "Galeria Virtual". En: Atherton, K. (ed.). Virtual Reality and the Gallery. Londres: Chelsea College of Art & Design y Tate Gallery [CD-ROM].
Parés, N., Parés, R. (1996). "Interacción con estímulos digitales en tiempo real". En: Lebrero, J.Tecnología punta y disidencia cultural. Donostia: Arteleku.
Parés, N.; Parés, R. (1997). "Galeria Virtual" (vol. 1). En:FORMATS. Revista de Comunicació Audiovisual. Barcelona: Universitat Pompeu Fabra. Sección Documents [Revista Digital en Internet:http://www.iua.upf.es/formats/]
Parés, N.; Parés, R. (2000). "Interaction-driven virtual reality application design. A particular case: ‘El Ball del Fanalet or Lightpools'". En:Presence: Teleoperators and Virtual Environments. Cambridge, MA: MIT Press.
Parés, N. (2001). "Aproximació informàtica a les propietats específiques de la Realitat Virtual, com a mitjà audiovisual digital interactiu generat a temps real, a través del projecte interdisciplinari GALERIA VIRTUAL". Universitat Pompeu Fabra [Tesis doctoral].
Ribas, J. Ignasi; Freixa, Pere; Julià, Daniel; Berenguer, Xavier; Parés, R. (1998). Modelos de interactividad en el CD-ROM. Formats, Universitat Pompeu Fabra.
Rowley, T.W. (1993). "Virtual Reality Products". En:Earnshaw, R.A.; Gigante, M.A.; Jones, H. (ed.).Virtual Reality Systems. Londres: Academic Press Ltd.
Sanabre, C. (2000). Pensando en multimedia, mucho más que usabilidad. Antipasta.
Shneiderman, B. (1998). Designing the User Interface. Strategies for Effective Human-Computer Interaction(3.ª. ed). Reading, MA: Addison-Wesley Longman, Inc.
Viewpoint Digital. 3D Geometries[Empresa de objetos 3D].http://www.viewpoint.com/
Vince, J. (1995). Virtual Reality Systems. Londres: Addison-Wesley.
Voss, R.F. (1985). "Random fractal forgeries" (pág. 805). En: Earnshaw, R.A. y otros (ed.).Fundamentals for Computer Graphics. Berlin: Springer-Verlag.
Waxelblat, A.(ed.) (1993). Virtual Reality Applications and Explorations. Londres: Academic Press Inc.
http://www.w3.org/WAI/Web Accessibility Initiative (WAI)