El propósito es crear mundos virtuales, que puedan ser
accesados a través de Internet, para lograr ésto se cuenta con
VRML, que combina las tecnologías Realidad Virtual e Internet.
VRML no es un lenguaje de programación, es un lenguaje de
especificación de mundos virtuales. Esta tecnología aún es muy
reciente como para contar con una filosofía de trabajo conocida
y aceptada formalmente (como ocurre con la programación
convencional), sin embargo en la metodología que se describirá
a continuación se encontrarán fases análogas a las encontradas
en la Ingeniería de Software. Sin embargo conviene precisar que
esta metodología puede no estar exenta de errores u omisiones, y
que dado el dinamismo existente en la comunidad VRML es muy
probable que a la fecha de publicación de este trabajo se
encuentren metodologías más completas o eficaces.
La metodología que se describirá a continuación es parte
del proyecto final de carrera realizado por Diego Álvarez,
alumno de Licenciatura en Informática de la Universidad
Politécnica de Valencia, denominado "Realidad Virtual por
Internet" el cual puede ser referenciado a través de
http://www.arrakis.es/~dalvarez/. Conviene aclarar que esa
metodología ha sido diseñada para la especificación 1.0 de
VRML, por lo tanto deja afuera todas las posibles interacciones
que puedan existir entre los objetos que pueblan el mundo VRML a
construir, por otro lado se aprecia una fuerte tendencia hacia
los proyectos arquitectónicos en la descripción del método,
sin considerar que ese tipo de proyectos es sólo un caso
particular. Sin embargo ha sido la única metodología encontrada
que se aparta del hecho de responder a una herramienta en
particular, otros casos de metodologías encontradas eran sólo
una guía para el correcto desarrollo de las aplicaciones con una
herramienta en particular.
En virtud a que la metodología de desarrollo encontrada sólo
respondía a VRML 1.0, debió ser completada para abarcar los
casos de dinamismo existente entre los objetos, además se la
provee de una notación que permita un adecuado manejo de los
conceptos VRML descritos en el capítulo anterior. Cada una de
las etapas fue revisada con el propósito de rescatarla tal cual,
o agregar o quitar elementos de acuerdo al enfoque adoptado por
este trabajo, vale decir tener una metodología independiente de
la herramienta que permita desarrollar proyectos VRML de acuerdo
a su especificación 2.0, y dejar abierto el camino a que pueda
ser completada en caso que aparezcan nuevas especificaciones para
VRML.
Posteriormente a describir la metodología será usada en una
aplicación concreta.
Un proyecto VRML, de cualquier envergadura, puede ser dividido
en 7 etapas:
A continuación se procederá a la descripción de cada una de ellas:
Aquí se decide qué es lo que se va a construir. Siempre en
cualquier proyecto de SW es el usuario quien establece (o
idealmente debería establecer) claramente los requisitos o
funcionalidades específicas que desea para el SW que está
solicitando. En un proyecto VRML se presentan algunas
particularidades importantes frente a este respecto:
En primer lugar hay un elemento artístico-técnico muy
importante a la hora de pensar en la satisfacción plena ante el
usuario. Se puede tener un proyecto VRML relacionado con el
modelamiento de un monumento histórico, por ejemplo las ruinas
de San Pedro de Atacama, pudo haberse hecho un trabajo muy
completo relacionado con recopilación adecuada de antecedentes,
y estudio histórico, sin embargo es muy probable que nunca quede
satisfecho plenamente quien encarga el proyecto (un arqueólogo,
o un profesor de historia), ya que a la hora de construir siempre
habrán ciertos detalles precisos que puedan pasar por alto. En
el caso de las ruinas puede ocurrir que una momia haya sido
tratada con cierto tipo de técnica de embalsamiento que hace que
su color sea de cierta característica, la cual no haya sido
percibida adecuadamente por el modelador, o simplemente no
lograda a través de una combinación RGB.
Además de lo anterior se debe tener en cuenta que los mundos
VRML en resumen son realidad virtual, que puede ser accesada por
Internet, vale decir, su característica primordial es su
divulgación a través de la red. Puede existir un proyecto
relacionado por ejemplo con la confección de una super base
militar estratégica, en donde es necesario tener todos los
elementos ubicados en forma precisa. Está muy claro que aquí
nadie del Estado Mayor querrá que eso se vea por Internet, o que
al menos se sepa que tiene esa característica, ni aunque se les
diga que se establecerán todos los tipos de técnicas
criptográficas o "restricciones al dominio".
Una vez visto lo anterior se puede proceder a la
especificación del proyecto VRML, considerando dos tipos
fundamentales de proyecto:
Una vez decidido qué es lo que se va a construir se debe
establecer cual va a ser la finalidad de la construcción, en
este sentido no es lo mismo construir un espacio que modele un
edificio real con el propósito de ser visitado por personas en
sillas de ruedas que quieran saber si éste es accesible en su
totalidad o hacer un espacio dedicado al entretenimiento, donde
el atractivo será su principal fin.
En el primer caso la fidelidad al modelo original debe ser la
máxima a seguir, en el segundo caso se pueden permitir ciertas
licencias constructivas. Las cuales por supuesto deben ser
consistentes, por ejemplo se puede modelar un carrusel, pero no
debería ocurrir que éste tuviera además de movimiento de
rotación, uno de traslación.
Es importante por lo tanto decidir el nivel de detalle a
alcanzar en el proyecto (ej. número de edificios y nivel de
detalle de los mismos). Por ejemplo si se decide hacer sólo la
fachada de un edificio sin la posibilidad de acceder a su
interior, o decidir que locaciones incluir y cuales no (ej.
representar sólo el primer piso y dentro de éste el hall,
salón de actos y laboratorio). Como ya se ha dicho el elemento
artístico dentro de un proyecto VRML, y de realidad virtual en
general, es muy importante, por lo que el hecho de abarcar
detalles que sean efectivamente relevantes a la hora del diseño
y construcción del modelo es vital. Sin embargo, si este nivel
de detalle es refinado a niveles muy rigurosos, se pueden abarcar
aspectos que simplemente el usuario nunca va a considerar a la
hora de explorar el mundo virtual, por lo que simplemente se
habrá perdido tiempo y recursos en su implementación
Dado el análisis hecho en los puntos anteriores se tendrá un
documento de especificación de proyecto VRML, el cual contendrá
los siguientes puntos:
1.- DESCRIPCIÓN: Se dice en qué consiste el
proyecto (profesional o artístico) así como el nivel de detalle
a alcanzar, locaciones a modelar y finalidad del proyecto. Cuando
se habla de locaciones, significa cualquier tipo de escenario
posible de modelar, por lo tanto puede ser una locación tanto un
escenario arquitectónico, como uno biológico, químico,
imaginario, etc.
2.- USUARIOS Y CLIENTES: Se describe el perfil
del usuario de ésta aplicación, así cómo quien encarga el
proyecto. Ambas descripciones son importantes a la hora de
establecer los requisitos de funcionalidad propios del proyecto.
3.- RECURSOS NECESARIOS: Se indican los recursos
a ocupar en el desarrollo de la aplicación (Software modelador,
especificación de VRML, editores, Software de aplicaciones
gráficas, elementos gráficos, etc.).
4.- REQUERIMIENTOS FUNCIONALES: Aquí se
establece el modo de interacción con el usuario, que en estos
casos está limitada a la interfaz del visualizador VRML que
posea el usuario, en general es conveniente recomendar al usuario
un visualizador específico. Junto con esto se establece el
siguiente tipo de restricciones:
Una vez decidido lo anterior debe verse cómo se dibuja, o
sea, se usarán texturas para cubrir los objetos o no. Si los
objetos son perfectamente identificables mediante colores RGB, el
uso de texturas puede relegarse sólo para entregar información
adicional (un escudo, alguna superficie planetaria, etc.).
Con todos estos antecedentes se tiene un dominio conocido en
el cual se podrá trabajar a través de VRML.
En esta etapa se decide cuando y cómo construir.
El cuando dependerá del número de personas implicadas en el
proyecto, así como de limitaciones impuestas por los receptores
del proyecto (las que pueden ser plazos y/o de presupuesto),
quienes serán los que fijen las condiciones temporales del
proyecto. Es importante tener en cuenta lo siguiente: Lo más
relevante dentro del trabajo VRML es crear un modelo que deje
plenamente satisfechos a sus usuarios en torno a lo que ellos
esperan de su modelo (sobretodo si se habla de algún
modelamiento que simule algún proceso ya sea biológico,
mecánico, de exploración espacial, o simplemente una maqueta),
por lo tanto sería conveniente que las faces de la
planificación aquí expuestas sean planteadas de acuerdo a ese
planteamiento, vale decir, si se necesita que el comportamiento
del objeto en torno a su interacción con los demás sea
correctamente modelado se deberá de tener una etapa de diseño
muy rigurosa, con el propósito de llegar a un nivel adecuado de
comprensión en torno a ese asunto; por otro lado si se está
frente a un proyecto en donde la apariencia final del objeto es
muy importante deberá de tenerse una fase de construcción lo
suficientemente detallada que permita ese resultado.
El cómo construir dependerá de la complejidad del proyecto
La diferencia entre proyecto simple y complejo irá dada por
el hecho del adecuado nivel de detalle precisado por los
usuarios. Un proyecto simple sería entonces, para el caso de un
edificio, hacer una caja; se transformaría en complejo si
además de la caja se requiere que se note la diferencia entre
los pisos, visita por dentro, funcionamiento del ascensor, etc.
Una adecuada planificación permitirá también poder evaluar
económicamente el proyecto, desde el punto de vista de quien
encarga el trabajo. En este sentido una evaluación adecuada de
este tipo de proyectos debe de considerar un seguimiento de los
costos involucrados en cada fase del proyecto así como los
plazos de entrega, en este sentido es importante definir la
complejidad del proyecto, ya que en la medida que ésta crece, su
costo también aumenta.
Un proyecto complejo exige SW de modelado 3D de alta calidad,
junto a HW especialmente dedicado a la computación gráfica,
desde este punto de vista los costos tanto en HW como en SW son
mucho mayores que para el caso de un proyecto simple que pueda
ser realizado en un PC sin necesidad de HW de aceleración
gráfica. La complejidad del proyecto debe estar totalmente
definida en la etapa de especificación, ya que en este punto
(planificación), los recursos tanto HW/SW, así como de Recursos
Humanos, deben estar plenamente establecidos para cada una de las
etapas restantes del proyecto (muestreo, diseño, construcción,
pruebas, publicación).
Por lo tanto los ítems a considerar para la evaluación de
costos en un determinado proyecto VRML son:
Todos estos ítems pueden ser resumidos en lo siguiente:
CT = HW+SW+RRHH+CAP+OTR
Donde CT representa los costos totales incurridos, HW
representa el costo en HW, SW representa el costo en SW, RRHH
representa el costo en recursos humanos y CAP el costo de
capacitación y OTR representa los otros ítems a considerar.
La estimación de los ingresos que se puedan obtener, debido a
la realización de aplicaciones de este tipo debe ir dada por el
cubrimiento de los costos estipulados anteriormente así como por
una estimación acerca de lo que ganan quienes encargan el
proyecto, vale decir si una empresa de turismo encarga modelar
ciertas locaciones que ésta incluye en alguno de sus planes debe
de estimarse cuanto gana esta empresa por concepto de publicidad
(y también prestigio) al tener este tipo de visita estipulada.
Se sugiere el uso de Software de gestión de proyectos con el
propósito de hacer un seguimiento preciso y continuo de las
fases establecidas para la realización del proyecto así como un
seguimiento de costos y plazos de entrega.
De todo lo anterior se desprende que la complejidad de los
proyectos VRML incide en forma directa en el costo involucrado
para su desarrollo, esta relación complejidad-costo podría ser
establecida por medio de alguna relación matemática, sin
embargo la poca experiencia en el ámbito del desarrollo de
aplicaciones VRML aún no permite realizar esta relación, por lo
que cualquier medición de este tipo sólo podrá ser realizada
de acuerdo al criterio de los analistas durante la revisión de
la especificación, durante la etapa de planificación.
Del análisis anterior se obtendrá una pauta de trabajo, que
puede ir dada por una carta Gantt, en donde se tendrán las
etapas involucradas en el desarrollo de las aplicaciones VRML
(Especificación, muestreo, diseño, construcción, pruebas y
publicación), junto a su duración (en semanas).
Durante esta etapa se recaban todos los antecedentes acerca
del objeto a modelar.
Esta forma de recopilación variará de acuerdo al objeto, si
se trata de modelar un ente biológico ( ej. el cuerpo humano) se
tomarían fotografías de diversos ángulos o también podrían
hacerse tomas de video, las cuales posteriormente serían
revisadas durante la etapa de construcción.
Otra forma de muestreo es para el caso de modelar objetos
geométricos estáticos (muebles, casas, una ciudad), en donde se
puede pasar de un croquis simple (para el caso de un proyecto
simple); a la recopilación de planos (elevaciones, de planta,
cortes), trabajos previos en Autocad, fotografías digitales,
tomas de video (para el caso de un proyecto complejo).
Finalmente se tiene el caso para los objetos dinámicos, vale
decir aquellos que pueden ir cambiando en el tiempo, ya sea en
respuesta a eventos internos (un objeto cuyo movimiento afecte a
otro) o externos (un click). En este caso además de los
antecedentes ya nombrados se requiere tener un pleno conocimiento
de los mecanismos que gobiernan el movimiento de cada uno de los
componentes. Por ejemplo se puede estar frente al hecho de
modelar un nuevo tipo de prótesis para un brazo humano, por lo
que es necesario conocer todos aquellos principios que gobiernan
el movimiento de la prótesis.
Para el caso de un proyecto arquitectónico el uso de planos
de las diversas construcciones y/o locaciones comprometidas es
muy útil por las siguientes razones:
En resumen, en esta etapa se obtiene toda aquella información
que sea necesaria para un adecuado modelamiento de los objetos
que poblarán el mundo virtual a construir.
Una vez conseguidos todos los antecedentes acerca de las
diversas locaciones a modelar, por medio del proceso de muestreo,
se debe proceder al diseño del modelo virtual.
Antes de iniciar cualquier proceso de diseño, conviene revisar la sintaxis y estructura básica de un archivo VRML, la que se puede apreciar en el siguiente esquema:
En un mundo VRML determinado se pueden apreciar componentes
estáticos y dinámicos. Los componentes estáticos son todas
aquellas figuras geométricas que dan forma al objeto u objetos
que se están modelando. Los componentes dinámicos en cambio son
todos aquellos eventos transmitidos entre los objetos que forman
el mundo virtual, a través de una ruta, que permiten a éstos
presentar interacciones traducidas en movimientos, sonidos, o
algún otro fenómeno perceptible para el usuario. Estos eventos
pueden ser tanto internos, como externos.
Ahora es necesario comprender bien la estructura de un mundo
VRML. Un mundo VRML está compuesto por una ó más escenas
gráficas, cada una contenida en un archivo VRML. Las escenas
gráficas están compuestas por un grupo de nodos, los cuales
contienen campos y eventos. Los nodos representan el componente
esencial en un archivo VRML, pueden ser de distinto tipo, nodos
pueden agrupar otros nodos. Los eventos son mensajes enviados
entre los nodos a través de rutas, estos eventos permiten
otorgar dinamismo a los componentes de un mundo VRML.
Los siguientes pasos son importantes a la hora de poder
efectivamente lograr una emulación adecuada del comportamiento
modelado:
A continuación se procederá a describir cada uno de estos
pasos.
La identificación de objetos en el caso del modelamiento para
VRML sigue un camino similar al análisis orientado a objetos. En
primer lugar los objetos serán identificados a partir del
análisis hecho a la especificación del modelo, y de los
antecedentes recogidos a partir del muestreo. De ambos pasos se
aprecia que los objetos se pueden manifestar de las siguientes
formas (dentro del marco VRML):
Esta identificación permite tener un punto de partida hacia el modelamiento definitivo.
Extrapolando esto a VRML los objetos aquí identificados
serán posteriormente modelados a partir del uso de nodos, de
cualquiera de sus tipos dependiendo de la naturaleza del objeto.
Una vez identificados los objetos que van a poblar el
escenario virtual, es hora de distinguir sus atributos, vale
decir aquellos datos que le otorgan al objeto cualidades
relevantes a ocupar para su modelamiento posterior. En este
sentido los atributos son características físicas propias del
objeto a modelar, por ejemplo para el modelamiento de una
radio-cassete serán alto, largo y ancho; color, volumen máximo
y mínimo de sonido.
Para encontrar una lista adecuada de atributos nuevamente se
deben recabar los antecedentes recopilados tanto en la
especificación como en el muestreo, para que con los objetos ya
identificados, hacer una lista de sus atributos más relevantes
para la finalidad del proyecto a realizar.
Extrapolando esto a VRML los atributos aquí especificados
pasarán a ocupar el lugar de los campos de los nodos, aunque
esta equivalencia no debe ser considerada directa totalmente ya
que en VRML, como ya se ha mencionado, está el concepto nodo
padre, nodo hijo, donde los hijos están agrupados bajo el campo children, por lo que son objetos
al igual que el padre. La extrapolación atributo-campo, sólo es
aplicable en los niveles más bajos de descomposición de la
estructura jerárquica.
Un evento involucrará cambios en el objeto sobre el que se le
aplica, más bien se producen cambios en los valores de uno o
más de los atributos que están contenidos en él. Estos cambios
pueden ser de posición, color, tamaño, sonido, etc.
Para lograr identificar los eventos, nuevamente se debe hacer
un análisis tanto de los datos entregados en la especificación
como en el muestreo, de manera de conseguir una clasificación
satisfactoria.
Extrapolando esto a VRML, los eventos permiten el cambio de
valores de los campos en los nodos. Estos eventos (que inducen
operaciones) pueden ser internos como externos, ejemplo de un
evento interno es la detección de colisiones, ejemplo de un
evento externo es la activación del sonido de una radio por
medio del click con el mouse.
Los objetos se comunicarán por medio de mensajes, estos
mensajes deben ir encaminados por una ruta. En VRML cambios en
los nodos, producto de su interacción, son posibles gracias al
envío de mensajes por medio de eventos que son encaminados vía
una ruta (ROUTE).
El análisis de la especificación y los datos recabados del
muestreo, deberán de indicar la existencia de estas
interacciones, sobre todo en aquellos escenarios dinámicos en
donde los objetos presenten variaciones en su movimiento y
características físicas.
Ya se han visto los conceptos claves a tener en cuenta a la
hora de hacer un diseño adecuado (Escena gráfica, nodos,
campos, eventos, rutas), es importante poder tener un tipo de
notación adecuada para seguir adelante en esta etapa. La
notación que se propone es la ocupada por la Silicon Graphics
durante un seminario acerca de VRML realizado el 6 de agosto de
1996, en ella integran nodo, campo, evento como se ve en la
figura siguiente:
Esta notación permite el hecho de poder analizar más
gráficamente la interacción entre los diversos objetos.
Supóngase un escenario mediante el cual el usuario al
acercarse a un objeto hasta llegar a la colisión, ocasiona que
se produzca un ruido producto de esa colisión. Esto involucra un
mensaje entre el objeto colisionado y la fuente de sonido, para
que ésta emita el correspondiente ruido. Hay un evento de salida
por parte del nodo Collision,
el cual ocasionará un accionar por parte del nodo AudioClip. La situación
gráficamente sería la siguiente:
Las flechas indican que se ha seguido una ruta, por lo tanto a
la hora de codificar tentativamente debería de escribirse algo
como:
ROUTE Nodo1.collideTime TO
Nodo2.startTime
En un modelamiento real un escenario determinado puede tener
cientos de objetos y una buena cantidad de estructuras, por lo
que es necesario lograr una representación concisa de estos
conceptos. Para el propósito de abreviar un objeto se puede
considerar representarlo con un rectángulo indicando su nombre
en el interior, esta representación es útil sobre todo cuando
se está definiendo la organización estructural de la escena
gráfica.
Una vez vista esta notación se pasará a estructurar los
conceptos ya analizados.
Como ya se ha mencionado, dentro del diseño para VRML se
puede apreciar que un objeto identificado en las etapas primarias
del análisis puede ser descompuesto en varias partes
constitutivas, que pueden también ser definidas en sí mismas
como objetos. Estructuras de este tipo son denominadas
estructuras de ensamblaje y se pueden definir con la siguiente
notación:
En donde el rectángulo significa un objeto y el triángulo
implica la relación de ensamblaje existente.
La pregunta que surge a continuación es ¿qué ocurre con las
instancias que se puedan presentar para un objeto o nodo
determinado, vale decir, qué ocurre cuando frente a una
determinada estructura se está claramente frente a una
situación que para VRML se debería tomar como DEF/USE?.
En este caso debería de anotarse nuevamente la instancia con
los respectivos valores de los campos modificados, lo más usual
es que se halla modificado la posición, por lo que los valores
en ese atributo deban ser especificados para la instancia,
pudiéndose obviar el resto de los valores por ser iguales.
Extrapolando a VRML, se tendría un nodo Transform,
con valor especificado de campo translation
y con campo children que
tendría la referencia USE.
Sin embargo la posición de la instancia en el diagrama de
ensamblaje puede ser manejado de tres diferentes formas, cada una
de ellas tendrá un significado distinto dentro del contexto
VRML. Se analizarán estos casos tomando un caso sencillo en el
cual se tiene un portal acompañado por dos columnas, una a cada
lado de la puerta.
Colocar la instancia en el mismo nivel del objeto, esto
implicaría que la instancia estaría supeditada solamente al
movimiento que realizará el portal. Para señalar que Columna1
es instancia de Columna se unen por una línea de flechas, con la
flecha apuntando hacia el objeto que es instanciado.
Colocar la instancia un nivel más abajo que el
objeto, esto implicaría que la instancia está supeditada al
movimiento del objeto, el cual a su vez está supeditado al
movimiento del nodo padre. Esto significa que si Columna se mueve
2 unidades de desplazamiento, Columna1 también lo hará. Columna
puede desplazarse ya sea porque su propio atributo de posición
ha cambiado, o porque el atributo de desplazamiento de portal lo
ha hecho, en ambos casos Columna1 se desplazará en la misma
proporción.
En este caso la situación se plantea de la siguiente forma:
crear un objeto Columna el cual tenga a Columna1 como subobjeto y
Columna2 como instancia de Columna1. De esta forma al desplazarse
Columna, desplazará a ambas en la misma proporción, y al
desplazarse una de ellas, no afectará la posición de la otra.
En los tres casos descritos se ha obviado la información de
atributos como una manera de abreviar la notación y sólo se ha
anotado el nombre del nodo. También puede ocurrir que se esté
frente a la posibilidad de múltiples instancias para un objeto
determinado, se puede abreviar esta situación, sólo en el caso
que se esté en el mismo nivel de jerarquía, de la manera en la
que se ve para el caso del Partenón griego:
En donde la línea segmentada indica que se están
referenciando los objetos desde Columna1 a Columna100, vale decir
que existen 100 columnas con los mismos atributos.
Hasta el momento se ha considerado a los objetos en el mundo
VRML como entes ensamblados y organizados jerárquicamente. Sin
embargo también se puede enfrentar la posibilidad de dinamismo
existente en estos objetos, vale decir, el hecho que éstos
pueden interactuar, por medio del envío de mensajes y también
efectuar movimiento sin que medie alguna acción externa por
parte del usuario.
Estas acciones involucran un cambio en el estado de los
objetos, por lo que cada objeto en el cual se pueda apreciar esta
capacidad dinámica debe tener un diagrama de transición de
estados que refleje esta situación. Los eventos originarán
cambios en el estado de los objetos, por lo que es muy importante
tenerlos bien identificados.
Por otro lado, como se ha dicho, los objetos interactúan
entre ellos, por medio del envío de mensajes (o eventos) a
través de rutas, por lo que es importante, también, tener un
diagrama de interacciones del mundo VRML, que permita modelar
esto adecuadamente.
Ambos tipos de diagrama son los que se procederá a analizar a
continuación, usando nuevamente, el ejemplo del objeto que emite
un sonido al ser colisionado.
Por medio de este diagrama se puede ver el tipo de estados por el que puede pasar un objeto determinado, junto con los eventos que ocasionan la transición de un estado a otro. De esta manera se puede capturar el comportamiento dinámico de los objetos del mundo VRML a modelar.
En el caso del ejemplo del sonido activado por la colisión se
tiene que los estados para Nodo2 (el que lleva a la activación
del sonido) son: Silencio y Sonido, el posible diagrama sería:
Las flechas indican una transición de estado, en tanto sobre
ellas se da un nombre simbólico a los eventos involucrados.
Un diagrama de interacciones permite realizar una traza de
todos aquellos sucesos de carácter dinámico que se puedan
presentar en un determinado escenario VRML.
Para el ejemplo de la colisión detonadora de un sonido, el
diagrama de interacciones sería el siguiente:
En donde los objetos van acompañados por una línea de
segmentos vertical y los eventos van acompañados por una flecha.
Aquí simplemente se ejemplifica que Nodo1 (que es un nodo de
tipo Collision) al detectar
que se ha realizado una colisión envía un mensaje a Nodo2 (del
tipo Sound), para que éste
se active y de esta manera se emita un sonido. La posterior
traducción de ésto a VRML (ROUTE),
vendrá dada en la etapa de construcción.
Se debe tener presente los sinónimos que han sido usados en
este capítulo y que son absolutamente naturales: Nodo es
sinónimo de objeto, atributo es sinónimo de campo, mensaje es
sinónimo de evento.
Tanto de la etapa de especificación como de la de muestreo se
ha obtenido un cúmulo de información acerca del mundo virtual a
construir, sin embargo mucha de esta información puede llegar a
ser un estorbo a la hora de construir, puesto que se puede ocupar
un buen porcentaje de tiempo en detalles sin importancia que el
visitante de la aplicación ni siquiera vaya a tomar en cuenta,
por lo que es necesario siempre rescatar lo esencial y saber
detectar lo superfluo, siempre lo que se busca en una
representación virtual de un elemento del mundo real es lograr
una adecuada aproximación que lo permita ser reconocible, no
necesariamente sacar una fotocopia exacta.
Por lo tanto en esta etapa es importante responder a preguntas
tales como:
Junto con ésto, al ya poseer todos los antecedentes
recopilados en el muestreo, se puede decidir qué elementos
incluir y cuales eliminar, por lo tanto otro set de preguntas
sería:
Aquí es importante la capacitación de los integrantes del
equipo de desarrollo, con el fin de que las preguntas anteriores
sean respondidas en forma satisfactoria. Por lo tanto es vital
formar equipos con experiencia en los distintos campos
necesarios:
Es importante también incluir distintas cámaras en los
archivos VRML, de forma de guiar al usuario a puntos concretos
dentro de la escena sin necesidad que él tenga que hacer
desplazamientos.
En resumen de la etapa de diseño se obtiene la organización
jerárquica de los objetos a modelar, por medio de los diagramas
de ensamblaje; mientras que todo lo relacionado con el aspecto
dinámico e interacción entre los objetos que pueblan el mundo y
éstos con el usuario, se obtiene mediante los diagramas de
transición de estados y de interacciones.
En caso de haberse hecho con cuidado los pasos anteriores,
ésta fase se debe hacer con facilidad y sin ninguna dificultad
imprevista.
Se puede construir de cuatro maneras:
A continuación se comentarán cada una de éstas formas:
El digitar el código completo puede resultar una buena o mala
idea dependiendo del tipo de objeto a modelar y de los
requerimientos previamente establecidos: Si se trata de un
proyecto en el que se busca más que nada un énfasis pedagógico
hacia VRML, sin importar lo que represente la aplicación final,
queda claro que aprender el código es importante; si se trata de
un proyecto profesional en el que los plazos de entrega son
importantes y en donde hay formas muy complejas, que con la
digitación completa del código pueden llegar a ser
inmanejables, la idea anterior no es la mejor. En realidad un fin
mucho más útil para un profesional de la informática en el
sentido de conocer la especificación VRML es lograr que se pueda
crear SW modelador de VRML en base a la especificación
entregada, y también el poder ser capaz de comprender y modelar
los fenómenos de dependencia de movimientos y organización de
componentes en forma jerárquica presentes en un desarrollo de
proyectos de realidad virtual, ya sea usando VRML o no.
Las herramientas de desarrollo VRML presentan una interfaz al
usuario que no necesariamente está relacionada con los conceptos
puros de VRML, por ejemplo se dice: "copiar un objeto",
cuando en realidad lo que se está haciendo es nombrar un nodo, y
posteriormente instanciarlo (DEF/USE).
En este sentido las herramientas están más orientadas a
personas dedicadas al diseño asistido por computador, más que a
un informático. Pero la ayuda que entregan al permitir que
formas complejas puedan ser llevadas a VRML con solo
"arrastrar y soltar", las hacen completamente
imprescindibles a la hora de construir un proyecto complejo.
En caso de trabajar con herramientas de desarrollo es muy
importante elaborar una correcta estrategia para elegir las
mejores, ya que en este caso se puede presentar una clara falta
de interoperatibilidad entre las distintas herramientas. Es
imposible asegurar compatibilidad completa entre todas las
herramientas, vale decir, lograr que la salida de una sea una
entrada válida para otra.
Para determinar las herramientas en la fase de construcción
se puede tomar un modelo simple y aplicarle todas las
herramientas a utilizar, y de esta manera advertir cualquier
dificultad de conversión que surja en el proceso. El resultado
ideal sería aquel en donde los objetos pasarán herramienta por
herramienta sin ningún cambio perceptible. En este sentido
existen ciertos detalles interesantes, por ejemplo para dibujar
una caja roja con código VRML bastaría con digitar:
#VRML V2.0 utf8
Shape{
appearance Appearance{
material Material{diffuseColor 1.0 0.0 0.0}
}
geometry Box{
size 2.0 2.0 2.0
}
}
Si es pasado por Internet3D Space Builder, el resultado
sería:
#VRML V2.0 utf8 (Created By ISB 2.1)
# This file was created with Internet3D Space Builder v2.1.
# According to License Agreement, you may not remove or modify this notice.
# Internet3D Space Builder (C) 1996, 1997 ParaGraph International, Inc.
# http://www.paragraph.com
# Last modification: [Thu Jul 17
23:26:55 1997]
WorldInfo {
info [
"LastSaveBy: Jose Emilio"
]
}
DirectionalLight {
direction -0.2 -0.6 -0.8
}
Group { # children: 2
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 1 0 0
}
}
geometry IndexedFaceSet { # faces: 6
convex FALSE
colorPerVertex FALSE
coord DEF Label_000 Coordinate {
point [
-1 1 1,
1 1 1,
1 1 -1,
-1 1 -1,
-1 -1 -1,
1 -1 -1,
1 -1 1,
-1 -1 1
]
}
coordIndex [
0, 1, 2, 3, -1,
4, 5, 6, 7, -1,
7, 6, 1, 0, -1,
6, 5, 2, 1, -1,
5, 4, 3, 2, -1,
4, 7, 0, 3, -1
]
}
}
]
}
# Faces total: 6
# Facesets total: 1
Lo único que se hizo fue abrir el archivo original, guardarlo
tal cual y cerrar el programa, sin embargo el cambio tanto en
tamaño, como en aplicación de código es radical. Mientras en
el primer archivo se usa un nodo predeterminado por el estándar
VRML para dibujar una caja (Box),
el SW construye la caja a partir de caras (polígonos), definidas
por un conjunto de puntos, además de agregarle luz, la que
incluso puede llegar a ser perjudicial, más que beneficiosa,
dependiendo del tipo de utilidad que se le quiera dar al modelo.
Es importante señalar que no existe herramienta VRML
"perfecta", cualquier proyecto VRML complejo que se
precie requerirá un adecuado ajuste "a mano", en los
archivos VRML generados por éstas. Por ejemplo en el caso
anterior de la caja, si la luz molesta para contemplar el color
rojo del cuadro, lo que hay que hacer es quitar las líneas de
código del nodo DirectionalLight
y se podrá ver normalmente.
Hasta el momento se ha trabajado pensando que se debe de
modelar todo, partiendo de cero. Sin embargo existe la
posibilidad que ya exista un trabajo 3D acerca de lo que se desea
modelar y que por lo tanto sólo sea necesario hacer una adecuada
transformación de ese archivo a VRML. En este sentido existen
herramientas (una de las cuales se detallará en el capítulo
siguiente), que permiten a partir de un formato estándar (ej.
dxf, 3ds), transformar el archivo a VRML directamente, sin
necesidad de ningún paso adicional. Con esto se permite un gran
ahorro en tiempo ya que después sólo bastaría refinar
detalles.
La combinación de los tres enfoques, o de dos cualesquiera de
éstos, resulta ser la mejor elección en caso de tratarse de un
proyecto profesional, ésto porque se usa todo el potencial de
las herramientas, junto con arreglar "a mano" algunos
detalles que la herramienta no haya dejado a nuestra plena
satisfacción. Por lo tanto dependerá de la habilidad del
constructor el poder crear una correcta amalgama de éstos
enfoques y de esa manera optimizar los resultados.
Por lo tanto de esta etapa se obtiene el modelo virtual descrito en la etapa de especificación.
Como se ha dicho VRML no es un lenguaje de programación, por
lo tanto no se compila antes de lanzarlo. Por lo tanto cualquier
detección de errores en la sintaxis de estos archivos se
conocerá recién cuando éstos se estén cargando en memoria. En
este sentido es importante que el browser a usar permita la
detección de errores de sintaxis.
Cosmoplayer de Silicon Graphics, es el browser que presenta
mejor comportamiento en este sentido, ya que al detectar un error
de sintaxis lo comunica en una ventana indicando el número de
línea.
También pueden haber problemas por nodos que no sean soportados por los browsers, por ejemplo Cosmoplayer aún no detecta el nodo Text, por lo que cualquier mención de éste en un archivo no es considerada.
En cuanto al color es importante comprobar los colores tras
aplicar las luces, pues los objetos reflejan la luz de manera
distinta en función de las fuentes de luz que sobre ellos
incidan.
En resumen las pruebas permitirán apreciar si el resultado obtenido es el esperado o no y si efectivamente se ha logrado una representación reconocible con el modelo original.
Aquí simplemente se coloca el archivo VRML en un servidor
web.
Aquí se puede presentar una contradicción en la que se tenga
un mundo simple pero con un Mbyte de mapas de textura, lo que
retarda enormemente la carga del archivo, estos aspectos
deberían ya haberse tratado tanto en las etapas de
especificación como en la de diseño.
Finalmente se debe tomar en cuenta que un mundo VRML debe
estar completamente cargado en la memoria del computador para su
adecuada visualización, por lo que el exceso en el tamaño de un
archivo VRML puede producir distintos resultados como el hecho
que el browser no cargue el escenario virtual o que el computador
se quede "pegado". Existen browsers que en este aspecto
presentan la facilidad de poder cargar archivos VRML previamente
comprimidos en formato gzip.
En resumen se obtiene un sitio web que tiene una
característica muy particular, el hecho de ser realidad virtual
la cual puede interactuar con el usuario en tiempo real.
Desde el muestreo en adelante se puede considerar al proceso
de desarrollo VRML como un ciclo iterativo.
Aquí es importante destacar que la duración de estas etapas
es variable dependiendo del tipo de proyecto y los recursos que
se dispongan. Por ejemplo si del muestreo se han obtenido
trabajos previos de modelamiento 3D en Autocad para un proyecto
arquitectónico la construcción se limitará a transformar estos
archivos a VRML y acomodarlos adecuadamente, por lo tanto esa
etapa sería relativamente breve. Por el contrario si no
existiera nada previo, se necesita obligatoriamente modelar todo,
y dependiendo del nivel de detalle exigido, la etapa de
construcción sería la más larga.
Igualmente en el caso del diseño, si se está frente a un
proyecto arquitectónico modelando una casa, el diseño se
limitaría solamente al diagrama de ensamblaje, ya que una casa
es un elemento estático; y al mismo tiempo las relaciones
jerárquicas entre sus componentes son fáciles de detectar. Sin
embargo si correspondiera proceder a modelar el comportamiento de
un volcán en erupción, sería necesario además del diagrama de
ensamblaje, hacer un diagrama de interacciones que permita
entender los eventos involucrados en el escurrimiento de lava
volcánica y cómo ésto afectaría al entorno circundante. Por
lo tanto aquí el estudio debe ser muchísimo más detallado y
por lo tanto se requerirá más tiempo.
Es importante recalcar que al diseñar un mundo virtual se
debe efectivamente cumplir con lo que se espera, o lo que es lo
mismo, crear un espacio que se comporte como si fuera real, es
importante no perder el sentido de la frase realidad virtual.
En la gran mayoría de los mundos VRML que están poblando la
red se puede apreciar el entrar a un universo aparentemente
ingrávido, en donde un mundo está flotando. Un piso, por muy
humilde que sea, ayuda grandemente a lograr una referencia
natural para una exploración más elegante del mundo virtual.
Como ya se ha señalado, es importante el uso de cámaras para
guiar al usuario hacia los puntos de interés, o ayudarlo a
encontrarse cuando se encuentre perdido.
Conviene tener una introducción hacia los mundos virtuales
mediante una página HTML que explique qué es lo que va a
encontrar, con qué browser se consigue un mejor resultado para
explorarlo, y en qué versión del VRML está hecho. Todo esto le
permitirá al usuario no cargar mundos que a la postre le
resulten poco interesantes, o intentar cargar un mundo usando un
browser incompatible con la versión para la cual éste ha sido
modelado (ej. al intentar cargar un archivo VRML 2.0, con Live3D,
el archivo bajará, pero no se apreciará nada, ya que ese
browser ha sido creado para VRML 1.0).
Una ventaja clara de VRML es que son archivos escritos en
formato de texto, por lo que al comprimirlos se pueden reducir
hasta en un 80% del original, en general para archivos de más de
50 Kbyte conviene realizar esta compresión la cual se realiza
por medio del formato gzip, que es el que reconocen los browsers
VRML.