MANUAL DE MUNDOS VIRTUALES-VRML

Referencia: http://wwwdi.ujaen.es/~rsegura/igai/vrml/documentos/tema1.htm

Tema 1 : Introduccin a VRML 2.0

Visualizadores VRML:
Es posible visualizar ficheros VRML mediante dos tipos de aplicaciones diferentes: Mediante visualizadores VRML especificos. Mediante plug-ins instalados en visualizadores HTML. La segunda de las opciones es la ms comn. De este modo, el Netscape Communicator 4.01 incorpora como plug-in de VRML el Cosmo Player de Silicon Graphics. Para averiguar que plug-ins se encuentran instalados en el Netscape basta con desplegar el men Help/About plug-ins. En el caso de no disponer del Cosmo Player, se podra obtener como aplicacin shareware a travs de internet. Una vez obtenido el programa, se ejecutara, instalndose automticamente dentro del Netscape o del Explorer.

Documentos VRML:
Como se ha mencionado anteriormente, VRML es un lenguaje de descripcin de escenas en el que cada escena se compone de un nmero de objetos. Los objetos pueden ser formas slidas situados y orientados de determinada forma u elementos intangibles que afectan a la escena como luces, sonido y distintos puntos de vista. Para crear estos mundos de realidad virtual se utilizan ficheros de texto, cuya extensin ser siempre .wrl, los cuales pueden ser desarrollados mediante cualquier editor o procesador de textos. Adems existe la posibilidad de utilizar programas

de diseo grfico, los cuales generan automticamente ficheros en formato VRML. Todo documento VRML est compuesto por los siguientes elementos:

Cabecera Comentarios Nodos

Cabecera:
La cabecera de todo fichero VRML es siempre la misma:

#VRML V2.0 utf8 donde VRML V2.0 indica el estndar empleado y utf8 autoriza el uso de caracteres internacionales. Es importante resaltar que no debe existir ningn espacio en blanco entre el smbolo "#" y la palabra "VRML".

Comentarios:
En VRML un comentario se escribe en una sola lnea, la cual comienza con el smbolo #. Se pueden tener tantas lneas de comentarios como se desee.

Nodos:

Un nodo es la estructura mnima indivisible de un fichero VRML y tiene como misin la de definir las caractersticas de un objeto o bien las relaciones entre distintos objetos. La mayora de los nodos pueden repetirse tantas veces como sea necesario en una escena, salvo una serie de nodos especiales como los que definen la niebla o la panormica del mundo virtual que aparecen un sola vez. Por otra parte, no todos los nodos afectan al aspecto visual del mundo. Por ejemplo, existen nodos que actan como sensores que detectan acciones del usuario e informan de ellas a otros objetos y otros que se encargan de modelar los sonidos. Los nodos a su vez contienen campos que describen propiedades. Todo campo tiene un tipo determinado y no se puede inicializar con valores de otro tipo. De este modo, cada tipo de nodo tiene una serie de valores predeterminados para todos sus campos, de forma que cuando lo utilicemos en una escena slo debemos indicar aquellos campos que se quieran modificar. Los campos pueden ser simples o campos que indiquen a vectores u otros nodos.

Estilo de escritura de los programas:

VRML es un lenguaje sensible a maysculas y minsculas, lo cual ha de ser tenido en cuenta a la hora de asignar nombres. Todos los nodos han de comenzar siempre con letra mayscula. Los campos de los nodos deben comenzar siempre con letra minscula.

Los campos de los nodos deben comenzar siempre con letra minscula. Los nmeros se escriben en punto flotante. Utilizar una lnea distinta para cada nodo, para cada campo y para cada valor de cada campo. Indentar cada lnea, segn su jerarqua. Colocar cada smbolo de cierre en el nivel de indentacin que le corresponda. Poner las lneas de comentario necesarias al mismo nivel que lo que se comenta. Poniendo nombres propios a los nodos

Un ejemplo de programa VRML sera el siguiente:

#VRML V2.0 utf8 #Esto es una lnea de comentarios Shape{ appearance Appearance{ material Material{} } geometry Cylinder{ height 2.0 radius 1.5 } }

Tema 2 : Construccin de formas primitivas

Las formas (Shapes) son los elementos que nos permiten visualizar los objetos en los mundos VRML. La sintaxis del nodo Shape es la siguiente: Shape{ appearance ... geometry ... } El campo appearance especifica las propiedades en cuanto a textura, material, etc del objeto que se describe en el campo geometry. Hablamos de formas primitivas cuando Shape utiliza nodos geomtricos primitivos para construir una figura. Los nodos geomtricos primitivos son los siguientes:

Box Cone Cylinder Sphere

(Caja) (Cono) (Cilindro) (Esfera)

Mediante la combinacin de estas formas geomtricas bsicas se pueden obtener otras formas de mayor complejidad.

Nodo primitivo Box:

Sintaxis:
Box{ size anchura altura profundidad

Ejemplo:
Box{ size 2.0 0.5 3.0 } Las dimensiones que se manejan en VRML son dimensiones abstractas pero lo normal es suponer que la unidad de medida es el metro. De esta forma, en el ejemplo anterior estaramos definiendo una caja de 2 metros de ancho, 0.5 metros de alto y 3 metros de profundidad.

Nodo primitivo Cone:

Sintaxis:
Cone{ height altura bottomRadius radio_de_la_base bottom valor_lgico side valor_lgico } Mediante los campos bottom y side se indica si se desea dibujar la base y la superfice lateral respectivamente. Por defecto estos campos toman el valor TRUE, lo cual indica que se dibuja el cono completo.

Ejemplo:
Cone{ height 3.0 bottomRadius .75 }

Nodo primitivo Cylinder:

Sintaxis:
Cylinder{ height radius bottom side top } altura radio valor_lgico valor_lgico valor_lgico

Mediante los campos bottom, side y top se indica si se desea dibujar la base inferior,la superfice lateral y la base superior del cilindro. Por defecto estos campos toman el valor TRUE, lo cual indica que se dibuja el cilindro completo.

Ejemplo:
Cylinder{ height 2.0 radius 1.5 }

Nodo primitivo Sphere:

Sintaxis:
Sphere{ radius radio }

Ejemplo:
Sphere{ radius 1.0 }

Sin embargo, la definicin de un nodo primitivo implica la definicin de un objeto, pero no su visualizacin. Es por ello por lo que se han de englobar dentro de un nodo Shape, el cual determina la apariencia de estos objetos.

Ejemplo:
#VRML V2.0 utf8 Shape{ appearance Appearance{ material Material {} } geometry Cylinder{ height 2.0 radius 1.5 } } A este fichero podramos darle el nombre de "cilindro.wrl".

Tema 3 : Construccin de formas de texto

En los mundos virtuales ser a menudo necesario utilizar textos para guiar al visitante Para ello existe un nodo especfico, el nodo Text. Una de las principales caractersticas de los textos es que son planos, es decir, no tienen profundidad.

Nodo Text:
Como en cualquier procesador de textos, se nos permitir indicar el tipo de fuente, su estilo, su tamao, el espaciado entre caracteres, justificacin de los parrafos, etc.

Sintaxis:
Text { string ["linea_texto 1", "linea_texto 2", . . . "linea_texto N",] fontStyle FontStyle { family "Nombre_Fuente", style "Estilo_Fuente", size Tamao_Fuente spacing espaciado_entre_caracteres justify "justificacin_del_texto" } } Como se puede apreciar el nodo Text posee dos campos:

string:
Aqu se introduce el texto que se desea visualizar.

fontStyle:
Este segundo campo es opcional, de forma que si se omite, el texto tendr el estilo de la fuente por defecto. Siempre que aparezca este campo tomar como valor el nodo llamado FontStyle.

Nodo FontStyle:
Sintaxis:
FontStyle { family "Nombre_Fuente", style "Estilo_Fuente", size Tamao_Fuente spacing espaciado_entre_caracteres justify "justificacin_del_texto" } Los posibles valores de los campos del nodo FontStyle son los que se muestran a continuacin:

family:
Determina la fuente que se va a utilizar para el texto. Se puede escoger entre "SERIF", "SANS" o "TYPEWRITER". Obsrvese que los nombres estn en maysculas.

style:
Se puede escoger entre "BOLD" (negrita), "ITALIC" (cursiva), "BOTH" (negrita y cursiva) o "NONE" (tipo de letra normal).

size:
Determina el tamao de la fuente, pero en unidades VRML.

spacing:
Determina la separacin entre lneas, tambin en unidades VRML.

justify:
Determina la justificacin del texto. Puede ser "BEGIN" (Alinear a la izquierda), "MIDDLE" (centrar el texto) o "END" (Alinear a la derecha).

Otros:
Que pensados para idiomas exticos, como el chino (escritura en vertical), el rabe (escritura de derecha a izquierda), etc. Para la lista completa, se puede consultar la RFC 1766. Todos estos campos son opcionales.

Ejemplo:
Text { string ["Esta es la primera fila de texto", "esta es la segunda fila", "etc."] fontStyle FontStyle { family "SERIF", style "BOLD", size 1.0 spacing 1.0 justify "BEGIN" } }

De igual forma que con los nodos geomtricos primitivos, mediante el nodo Text lo nico que se consigue es definir la estructura del texto, sin embargo no se puede visualizar, ya que no hemos indicado como se ha de presentar en el mundo virtual. Para conseguir esto, se integra en el nodo Shape, de la misma manera que se haca con los nodos primitivos:

Shape { appearance ... geometry Text { ... } }

Una vez que el texto se encuentra en el mundo virtual se puede manipular como cualquier otro objeto (girndolo, etc.), ya que lo nico que lo diferencia de los nodos primitivos es que posee dos dimensiones en lugar de tres.

Ejemplo:
#VRML V2.0 utf8 Shape{ appearance Appearance{ material Material {} } geometry Text { string ["Esta es la primera fila de texto", "esta es la segunda fila", "etc."] fontStyle FontStyle { family "SERIF", style "BOLD", size 1.0 spacing 1.0 justify "BEGIN" }

} } A este fichero podramos darle el nombre de "texto.wrl".

Tema 4 : Agrupacin de nodos

Hasta ahora hemos visto los objetos aisladamente. Veamos ahora cmo podemos agruparlos para conseguir formas ms complejas. Existen diversos nodos que nos permiten agrupar objetos:

Nodo Group Nodo Transform Nodo Switch Nodo Billboard

Nodo Group:
El nodo Group permite unir un conjunto de nodos de forma que acten como una entidad nica, pero sin efectuar ninguna transformacin en ellos. La principal caracterstica de este tipo de grupo es que los objetos son creados todos en el mismo punto (en el centro del escenario de realidad virtual).

Sintaxis:
Group { children [ ... ] }

El campo children contiene la lista de los objetos que se quieren agrupar, representados por sus nodos Shape respectivos:

Ejemplo:
Group { children [ Shape { ... }, Shape { ... }, ... ] }

Ejemplo:
#VRML V2.0 utf8 #Ejemplo de agrupacin de una caja y un cono Group { children [ #Aqu empieza la caja: Shape { appearance Appearance { material Material { } } geometry Box { size 2.0 0.5 3.0 } }, #Aqu empieza el cono: Shape { appearance Appearance { material Material { } } geometry Cone { height 3.0 bottomRadius 0.75 } } ]

} El fichero asociado a este ejemplo es "group.wrl"

Nodo Transform:
Por defecto todos los objetos (Shapes) se construyen en el centro del escenario virtual. El nodo transform nos va a permitir evitar esto, indicando la posicin, orientacin y tamao de los diferentes objetos que va a crear.

Sintaxis:
Transform{ translation Eje_X Eje_Y Eje_Z rotation Eje_X Eje_Y Eje_Z ngulo scale Eje_X Eje_Y Eje_Z children[...] } Cada grupo creado mediante el nodo Transform va a poseer su propio sistema de coordenadas, cuyos atributos se determinan a travs de los campos translation, rotation y scale, los cuales son optativos.

El campo translation permite indicar la posicin del origen del nuevo sistema de coordenadas perteneciente al grupo dentro del sistema de coordenadas de nodo que lo engloba (nodo padre). A travs del siguiente ejemplo esta idea quedar ms clara:

Ejemplo:
Transform{ # Ejes: X Y Z translation 2.0 0.0 0.0

children [...] } Mediante este ejemplo se consigue que el grupo creado tenga un sistema de coordenadas idntico a sistema de coordenadas principal, con la nica salvedad de que su origen se encontrara desplazado dos unidades sobre el eje X del sistema principal. Tambin es posible apreciar en este ejemplo que slo se han de contemplar los campos que interesen, ignorndose el resto. Grficamente los pasos seran los siguientes: I) Partimos del sistema de coordenadas del nodo padre:

II) Realizamos la translacin del sistema de coordenadas del grupo:

Un ejemplo sera el siguiente:

El campo rotation nos permite girar el sistema de coordenadas del grupo alrededor de uno de los ejes del sistema de coordenadas del nodo padre. Para ello, adems de indicar sobre que eje se desea realizar el giro, se ha de hacer referencia al grado de inclinacin de dicho giro (en radianes).

Ejemplo:
Transform{ # Ejes: X Y Z ngulo rotation 0.0 0.0 1.0 0.52 children [...] } Con este ejemplo se pretende hacer girar el sistema de coordenadas del grupo sobre el eje Z 0.52 radianes. Ntese que solamente uno de los ejes puede tomar un valor (que ha de ser forzosamente la unidad) mientras el resto ha de permanecer a cero. De esta forma slo hay tres combinaciones posibles con las que rellenar los ejes del campo rotation:

Rotacin sobre el eje X 1.0 0.0 0.0 Rotacin sobre el eje Y 0.0 1.0 0.0

Rotacin sobre el eje Z 0.0 0.0 1.0

Grficamente los pasos seran los siguientes: I) Partimos del sistema de coordenadas del nodo padre:

II) Realizamos la rotacin del sistema de coordenadas del grupo:

Un ejemplo sera el siguiente:

A travs del campo scale podemos aumentar o reducir el tamao de los ejes del sistema de coordenadas del grupo utilizando factores de escala que toman como referencia los ejes de coordenadas del sistema del nodo padre. De esta forma aumentamos o disminuimos el tamao de los objetos que se crean.

Ejemplo:
Transform{ # Ejes: X Y Z scale 0.5 0.5 0.5 children [...] } El ejemplo anterior hace que los ejes del sistema de coordenadas del grupo sean un 50% (0.5) ms pequeos que los ejes del sistema principal y por lo tanto el objeto diseado en estos ejes reducir su tamao a la mitad. Si se hubiese querido que fuesen el doble de grandes, el ejemplo hubiese sido el siguiente:

Ejemplo:
Transform{ # Ejes: X Y Z scale 2 2 2 children [...] }

Grficamente los pasos seran los siguientes: I) Partimos del sistema de coordenadas del nodo padre:

II) Realizamos la translacin del sistema de coordenadas del grupo:

Un ejemplo sera el siguiente:

Por ltimo, se muestra un ejemplo en el que se unen las diferentes modificaciones sobre el sistema de coordenadas de un grupo:

Ejemplo:
Transform{ # Ejes: X Y Z ngulo translation 2.0 0.0 0.0 rotation 0.0 0.0 1.0 0.52 scale 0.5 0.5 0.5 children [...] } Grficamente si se realizasen estas tres operaciones sobre un cilindro obtendramos los siguiente:

Un ejemplo completo se encuentra en el fichero "arcos.wrl".

Nodo Switch:
La principal caracterstica de un nodo Switch es la de mostrar nicamente uno de los nodos hijos del nodo, el cual ha debido ser seleccionado previamente.Se pueden utilizar para conectar o desconectar los efectos de una determinada propiedad o para alternar entre propiedades diferentes. El campo whichChild especifica el hijo choice que se va activar, siendo el 0 el del primer hijo. Su valor por defecto es -1, lo cual indica que ninguno de los hijos est seleccionado. El campo whichChild es una entrada y por lo tanto puede ser modificado por otro nodo.

Sintaxis:
Switch{ whichChoice 0 choice[...] ... choice[...] }

Nodo Billboard:
El nodo Billboard permite crear un grupo con un sistema de coordenadas

especiales, ya que a travs del campo axisOfRotation (eje de rotacin) indicamos el eje sobre el que a de girar el objeto, de forma que, siempre est de cara al espectador:

Todos los hijos agrupados mediante este nodo sern visualizados.

Sintaxis:
Billboard{ axisOfRotation Eje_X Eje_Y Eje_Z children[...] } Al igual que para el campo rotate del nodo transform, nicamente uno de los ejes puede tomar como valor la unidad, permaneciendo el resto a cero:

Rotacin sobre el eje X 1.0 0.0 0.0 Rotacin sobre el eje Y 0.0 1.0 0.0 Rotacin sobre el eje Z 0.0 0.0 1.0

Un ejemplo completo se encuentra en el fichero "robobill.wrl".

Poniendo nombres propios a los nodos:

Hay una solucin prevista para simplificar las repeticiones de objetos dentro de un escenario virtual. Esta solucin consiste en asignar un nombre arbitrario al nodo que se piensa repetir en el cdigo. Supongamos, por ejemplo, que se van a utilizar repetidamente en un escenario unos cilindros exactamente iguales (que podran ser las columnas de una casa).Dichos cilindros tendrn el siguiente cdigo:

Shape { appearance Appearance { material Material { } } geometry Cylinder { height 2.0 radius 0.5 } } (Este es el cdigo de un cilindro con la apariencia por defecto, de 2 unidades de alto y una base de radio 0.5) Se puede definir, para el mbito de un documento VRML, que este tipo de cilindro tenga un nombre arbitrario, por ejemplo ColumnaRepetida (o como se desee, con tal de que comience por mayscula), de la siguiente manera:

DEF ColumnaRepetida Shape { appearance Appearance { material Material { } } geometry Cylinder { height 2.0 radius 0.5 } } Entonces, cada vez que se quiera usar este nodo en otra parte del documento, basta con poner lo siguiente: USE ColumnaRepetida En el ejemplo anterior de la caja y el cono, aparece el nodo Appearance repetido. Vamos a definirlo, en la primera ocasin que se utiliza con el nombre, "PorDefecto" y la segunda vez que se usa lo invocaremos mediante el comando USE: #VRML V2.0 utf8 #Ejemplo de agrupacin de una caja y un cono, #haciendo uso de los comandos DEF y USE. Group { children [ Shape { appearance DEF PorDefecto Appearance { material Material { } } geometry Box { size 2.0 0.5 3.0 } }, Shape { appearance USE PorDefecto geometry Cone { height 3.0 bottomRadius 0.75 }

} ] }

En este caso concreto, la simplificacin no ha sido muy grande (slo un par de lneas menos de cdigo), pero ha servido para ilustrar el concepto.

Tema 5 : El color de los objetos

Anteriormente se ha comentado que el nodo Shape contena dos campos, appearance y geometry, de los cuales el segundo indicaba el tipo de objeto a representar y del que se ha hablado ya ampliamente. Sin embargo la misin del campo appearance apenas se ha comentado, por lo que procederemos a analizarla con ms detalle en este punto. El campo appearance va a permitir seleccionar el color y la textura del objeto que va a ser representado dentro del escenario virtual. Este campo toma como valor un nodo de tipo Appearance, el cual a su vez, posee un campo denominado material que toma como valor un nodo de tipo Material. El nodo Material es el que controla las propiedades del color (seleccin del color, del brillo, del grado de transparencia, etc.) que se van a dar al objeto. Los colores que se le dan a los objetos son colores RGB, es decir, vienen dados por tres valores en coma flotante, cada uno de los cuales representa uno de los colores primarios (Red, Green, Blue ) [ Rojo,Verde y Azul]. El valor 0.0 representa la ausencia de color y el 1.0 la mxima intensidad. Muchos programas de dibujo darn un valor para cada color RGB en un formato 256x256x256. Para poder utilizar estos colores en VRML es preciso convertirlos, dividiendo cada valor por 256 y colocando el resultado

en su campo correspondiente dentro del nodo Material.

Nodo Material:
Con este nodo vamos a determinar el color y grado de transparecia de los objetos.

Sintaxis:
Shape{ appearance Appearance{ material Material{ diffuseColor color_RGB emissiveColor color_RGB specularColor color_RGB ambientIntensity valor transparency valor shininess valor } } geometry ... } Cada uno de los seis campos del nodo Material tiene su propio efecto especfico sobre un objeto.Todos son opcionales.

diffuseColor:
El campo diffuseColor representa lo que la mayora de los usuarios llamaran como el color del objeto.

emissiveColor:
El campo emissiveColor se utiliza para fijar el color del brillo del objeto, cuando dicho objeto necesite ser visible en la oscuridad. De esta forma se consigue un efecto en donde la figura representada parece iluminada desde el interior mediante una luz de un determinado color. La configuracin por defecto de este campo es el negro, ya que la mayora de los objetos normalmente no brillan.

specularColor:
El campo specularColor es un parmetro avanzado que permite indicar qu color de luz refleja el objeto. Por ejemplo, una cama roja no refleja un color rojo, pero una olla rojiza si puede reflejar su color.

ambientIntensity:
Este campo es otro parmetro avanzado que indica la cantidad de luz ambiental (producida por los diferentes focos de luz del escenario virtual) es reflejada por el objeto. Toma valores en coma flotante entre 0.0 y 1.0.

shininess:
El campo shininess controlan el brillo de un objeto. Toma valores en coma flotante entre 0.0 y 1.0.

transparency:
El campo transparency indica el nivel de transparencia del objeto. Toma valores en coma flotante entre 0.0 y 1.0, siendo el 1.0 el nivel mximo de transparencia (objeto invisible) y el 0.0 el nivel mnimo (objeto totalmente opaco). El valor por defecto es el 0.0. Los ficheros "colores1.wrl" y "colores2.wrl" contienen ejemplos completos sobre como cambiar el aspecto de los objetos.

Tema 6 : Objetos almacenados en ficheros

Para facilitar el diseo de mundos virtuales habr ocasiones en las que convendr almacenar cada objeto en su propio fichero. De este modo, si por ejemplo se deseara modelar una habitacin, los diferentes elementos que van a aparecer dentro de ella: paredes, puertas, mesas, sillas, etc, son objetos independientes entre si pero que se engloban dentro de un mismo espacio y, que adems, pueden aparecer varias veces en el diseo de todo mundo virtual. Es por ello por lo que sera de inters crear un fichero donde almacenar el objeto mesa ("mesa.wrl"), otro fichero para el objeto silla ("silla.wrl"), etc. En el fichero "comedor.wrl" se realizan llamadas tanto al fichero que contiene la silla como al que contiene la mesa.

Nodo Inline:

El nodo Inline va a permitir crear un grupo en donde los hijos, almacenados en distintos ficheros VRML, son recuperados indicando su direccin URL.

Sintaxis:
Inline{ url"direccin_url" }

Ejemplo:
... Inline{ url"mesa.wrl" }, ... Transform{ translation ... children [ Inline{url"silla.wrl"} ] } ...

Tema 7 : Adicin de enlaces en el mundo virtual

Nodo Anchor:
El nodo Anchor crea un grupo especial ya que seleccionando cualquier objeto perteneciente a dicho grupo se salta hacia otro lugar del escenario virtual o hacia otro mundo virtual almacenado en un fichero VRML (al cual accedemos a travs de su direccin URL). Cualquier objeto o grupo de objetos se puede convertir en un enlace.

Estos enlaces son los equivalentes en el mundo tridimensional a los enlaces existentes en las pginas Web realizadas mediante HTML. Adems, todo nodo Anchor posee un campo denominado description en el que mediante una cadena de texto se describe brevemente el objeto.

Sintaxis:
Anchor{ url"direccin_URL" description "descripcin_del_enlace" children[...] }

Ejemplo:
Anchor{ url"escalera.wrl" description "Escaleras Flotantes" children[...] } En el fichero "enlace.wrl" se muestra como crear un enlace, el cual va a tener forma de escalera. Este enlace nos llevar hasta el cilindro creado en el tema 2.

Tema 8 : Construccin de formas complejas

Se ha visto en temas anteriores como mediante la superposicin y unin de diferentes nodos geomtricos bsicos es posible construir objetos ms complejos. Sin embargo, si la nica manera de generar formas complejas fuese sta, la construccin de mundos virtuales ser bastante ardua. Es por ello por lo que aparecen una serie de nuevos nodos, los cuales, adems de facilitar el diseo (al tener ms control sobre ellos y al ser ms

flexibles), generan mundos VRML de una forma ms eficiente. Lo ms recomendable a la hora de disear un objeto es describir su geometra en dos pasos aislados: Especificacin de las coordenadas Creacin de la forma geomtrica

Especificacin de las coordenadas:

En este paso se ha de indicar mediante el nodo Coordinate la posicin de los puntos que se van a utilizar para construir el objeto. Estos puntos no son visibles en el escenario virtual.

Nodo Coordinate:
Sintaxis:
Coordinate { point [ Eje_x Eje_Y Eje_Z, Eje_x Eje_Y Eje_Z, ... Eje_x Eje_Y Eje_Z ] } El campo point puede poseer varios puntos, cuyas coordenadas estn separadas por comas.

Ejemplo:
Coordinate { point [ 12.0 11.0 17.1, 20.5 13.8 5.3, 14.0 6.1 22.9 ] }

Creacin de la forma geomtrica:

Una vez definidos los puntos que forman el esqueleto del objeto, se han de conectar. Existen tres maneras de unir estos puntos, cada una de las cuales est asociada a un nodo diferente:

Nodo PointSet Nodo IndexedLineSet Nodo IndexedFaceSet

Estos tres nodos poseen un campo denominado coord que acepta como valor un nodo Coordinate.

Nodo PointSet:
Representa un conjunto de puntos situados en las coordenadas ndicadas dentro del sistema de coordenadas del nodo padre.

Sintaxis:
PointSet { coord Coordinate { point [ . . . ] } color Color { color [ . . . ] } }

"puntos.wrl" El campo coord toma como valor un nodo de tipo Coordinate, el cual define los puntos que se desean representar. El campo color sirve para definir el color de cada uno de los puntos. Este campo toma como valor un nodo Color, que a su vez contiene un campo de tipo color de nuevo. Este ltimo campo describe una lista de colores RGB, de forma que el primer color corresponde al primer punto descrito por el nodo Coordinate del campo coord ; el segundo color corresponde al segundo punto y as sucesivamente.

Ejemplo:
PointSet { coord Coordinate { point [

12.0 11.0 17.1, #1 punto 20.5 13.8 5.3, #2 punto 14.0 6.1 22.9 #3 punto ] } color Color { color [ 1.0 0.0 0.0, # 1 punto rojo 0.0 1.0 1.0, # 2 punto verde 1.0 1.0 0.0 # 3 punto amarillo ] } } Si se incluyese este cdigo, tal como est, en un documento VRML, no podramos ver ninguno de estos puntos, ya que como se ha visto anteriormente, para crear un objeto visible se debe utilizar el nodo Shape. Obsrvese que se ha prescindido del campo appearance del nodo Shape ya que no es necesario, pues los puntos no van a tener la apariencia por defecto, sino la que se determina en el campo color.

Ejemplo:
#VRML V2.0 utf8 #Ejemplo de un grupo de tres puntos con colores Shape { geometry PointSet { coord Coordinate { point [ 12.0 11.0 17.1, #1 punto 20.5 13.8 5.3, #2 punto 14.0 6.1 22.9 #3 punto ] } color Color { color [ 1.0 0.0 0.0, # 1 punto rojo 0.0 1.0 1.0, # 2 punto verde

1.0 1.0 0.0 # 3 punto amarillo ] } } }

Nodo IndexedLineSet:
Permite unir los diferentes puntos especificados en su campo coord mediante lneas poligonales.

Sintaxis:
IndexedLineSet{ coord Coordinate { point [ . . . ] } coordIndex [...] colorPerVertex valor_lgico color Color { color [ . . . ] } colorIndex [...] }

"lineas.wlr" El campo coord toma como valor un nodo de tipo Coordinate, el cual define los puntos que sirven como esqueleto de la figura. El campo coordIndex se utiliza para especificar entre qu puntos se han de trazar las lneas. Una lnea puede ser trazada utilizando ms de dos puntos, de forma que se dibuja una lnea entre el primer y el segundo punto, otra entre el segundo y el tercer punto, y as sucesivamente.Un ndice con valor -1 indica que ha finalizado la lnea actual y que comienza la siguiente. Para indicar el primer punto definido en el nodo Coordinate se utiliza el 0, para el segundo el 1 y as sucesivamente. El campo colorPerVertex indica como se han de aplicar los colores sobre las lneas:

colorPerVertex colorIndex

Accin Se aplican en orden los colores descritos en el nodo Color a cada una de las lneas descritas en coordIndex. Deben existir al menos tantos colores en el nodo Color como lneas haya en coorIndex. Este campo contiene una lista ordenada de nmeros, los cuales representan a los colores definidos en el nodo Color. De esta forma, el 0 representar al primer color definido en el nodo Color, el 1 al segundo,etc. Se hace corresponder cada elemento de la lista con una de las lneas descritas en

VACIO FALSE (Los colores se aplican sobre las lneas)

NO VACIO

coordIndex.
Si el mayor valor que admite el campo colorIndex es N, entonces deben existir en el nodo Color N+1 colores definidos.

Ejemplo:
colorIndex[4,0,3,2] De esta manera se asigna a la primera lnea de coordIndex el tercer color del nodo Color, a la segunda lnea el primer color,etc. Se utiliza el campo coordIndex para elegir los colores definidos en el nodo Color. Si el mayor valor que admite el campo coordIndex es N, entonces deben existir en el nodo Color N+1 colores definidos. Se aplican los colores a cada vrtice. Este campo va a tener ahora la misma estructura que el campo coordIndex, por lo que ha de contener al menos tantos ndices como este ltimo. Tambin ha de poseer los indicadores de fin de lnea (-1) en los mismos sitios que el campo coordIndex. Si el mayor valor que admite el campo colorIndex es N, entonces deben existir en el nodo Color N+1 colores definidos.

VACIO

TRUE (Los colores se aplican sobre los vertices)

NO VACIO

Nodo IndexedFaceSet:
Permite unir los diferentes puntos especificados en su campo coord mediante caras poligonales.

Sintaxis:
IndexedFaceSet{ coord Coordinate { point [ . . . ] } coordIndex [...] colorPerVertex valor_lgico color Color { color [ . . . ] } colorIndex [...] }

"vasija.wrl" El campo coord toma como valor un nodo de tipo Coordinate, el cual define los puntos que sirven como esqueleto de la figura. Utiliza los ndices de su campo coorIndex para especificar las caras poligonales. Un ndice con valor -1 indica que ha finalizado la cara actual y comienza la siguiente. El campo colorPerVertex indica como se han de aplicar los colores:

colorPerVertex colorIndex

Accin

VACIO FALSE (Los colores se aplican sobre las caras)

Los colores se aplican en el orden en el que se han definido dentro del nodo Color. Deben existir al menos tantos colores como caras. Los colores se aplican en el orden indicado por el campo colorIndex. Deben existir al menos tantos ndices en este campo como caras se han definido. Si el mayor valor que admite el campo colorIndex es N, entonces deben existir en el nodo Color N+1 colores definidos. Se utiliza el campo coordIndex para elegir los colores definidos en el nodo Color.

NO VACIO

VACIO

Si el mayor valor que admite el campo coordIndex es N, entonces deben existir en el nodo Color N+1 colores definidos. Se aplican los colores a cada vrtice. Este campo va a tener ahora la misma estructura que el campo coordIndex, por lo que ha de contener al menos tantos ndices como este ltimo. Tambin ha de poseer los indicadores de fin de lnea (-1) en los mismos sitios que el campo coordIndex. Si el mayor valor que admite el campo colorIndex es N, entonces deben existir en el nodo Color N+1 colores definidos.

TRUE (Los colores se aplican sobre los vertices) NO VACIO

A continuacin se muestra un ejemplo de cmo se colorea una figura utilizando sus caras:

"tricaras.wrl" Ahora el ejemplo trata de cmo se colorea una figura utilizando sus vrtices:

Tema 9 : Utilizacin de rejillas de elevacin

Nodo ElevationGrid:
Este nodo crea una cuadrcula rectangular con alturas variables, lo que la hace especialmente til para modelar el terreno y para la creacin de otras superficies en el espacio.

Sintaxis:
ElevationGrid{ xDimension nmero_de_columnas(Eje_X) xSpacing valor_real zDimension nmero_de_filas(Eje_Z) zSpacing valor_real height [altura1, altura2,...,altura(numcolum x numfilas)] color Color[...] colorPerVertext } Los campos xDimension y zDimension especifican el nmero de puntos de la cuadrcula en las direcciones X y Z, definiendo una superficie que contiene un nmero de rectngulos igual a (xDimension-1)*(zDimension-1). Los campos xSpacing y zSpacing determinan la distancia entre los puntos de la cuadrcula en el eje X y en el eje Z respectivamente. El campo height consiste en una ordenacin de valores escalares que representan la altura de cada vrtice sobre la cuadrcula. Los valores se almacenan de modo que la fila 0 es la primera, la fila 1 la segunda, etc. Dentro de cada fila, los valores de altura se almacenan de modo que la columna 0 es la primera, la 1 la segunda, etc. El campo colorPerVertex indica como se han de aplicar los colores:

colorPerVertex
FALSE

Accin Los colores se aplican sobre las cuadrculas de la rejilla. Se han de definir en el nodo Colors al menos ((xDimension-1)*(zDimension-1)) colores. Los colores se aplican sobre los vrtices de la rejilla.Se han de definir en el nodo Colors al menos (xDimension*zDimension) colores.

TRUE

Tema 10 : Utilizacin de texturas

La textura es la posibilidad que tenemos de envolver un objeto con una imgen determinada que se encuentra almacenada en un fichero, al cual accedemos mediante su URL. Los tipos de imagen que soporta VRML son:

JPEG GIF PNG Hasta ahora, para definir un objeto visible se ha utilizado el nodo Shape de la siguiente forma: Shape { appearance Appearance { material ... } geometry ... } en donde el nodo Appearance tiene un solo campo, material, con el que se definen el color y la transparencia, segn se ha visto en temas anteriores. Pero en realidad puede tener tambin otros dos campos: texture (cuyo valor suele ser un nodo de tipo ImageTexture o de tipo MovieTexture) y textureTransform, con los que se define la textura de los objetos: Shape { appearance Appearance { material ... texture ImageTexture{...} textureTransform {...} } geometry ... }

Nodo ImageTexture:
Sintaxis:
ImageTexture{ url "direccion_URL" repeatS valor_lgico repeatT valor_lgico } El campo url contiene la direccin URL del fichero grfico que se va a usar como textura. Los formatos grficos que admite VRML son jpeg,gig y png. Las texturas definen un conjunto de coordenadas 2D (Ejes S y T) que se emplean para trazar texturas sobre la superficie de los objetos. Las coordenadas de textura van de 0 a 1. La coordenada horizontal se denominada S y la coordenada vertical T. El lado inferior de la imgen se corresponde con el eje S y el lado izquierdo con el eje T. La esquina inferior izquierda de la imagen, segn este sistema de coordenadas, vendra dada por el punto (S=0,T=0) y la esquina superior derecha por (S=1,T=1). Los campos repeatS y repeatT determinan como envuelve la textura en las direcciones S y T. Si repeatS es TRUE, la textura se repite (cada vez que S=1) en la direccin S hasta cubrir la superficie del objeto. Si repeatS es FALSE, la textura se adapta a toda la superficie del objeto a lo largo de la direccin S, sin tener en cuenta el valor de las coordenadas S y T. El campo repeatT hara lo mismo sobre el eje T.

Nodo TextureTransform:

Este nodo define una transformacin 2D aplicada a las coordenadas de textura. Esto afecta a la forma en que se aplica la textura a las superficies de los objetos. La transformacin consiste (por orden) en un ajuste de la escala no uniforme sobre un punto central arbitrario, una rotacin sobre ese mismo punto y una translacin. Esto permite al usuario modificar el tamao, orientacin y posicin de las texturas de los objetos.

Sintaxis:
TextureTransform{ center Eje_S Eje_T rotation ngulo scale Eje_S Eje_T translation Eje_S Eje_T } El campo center especifica un punto en el sistema de coordenadas de la textura (S,T) sobre el que los campos rotation y scale van a ser aplicados. Supngase que se comienza a trabajar a partir de la siguiente imagen:

El campo scale contiene dos factores de escala, uno para el eje S y otro para el eje T de la textura. Puede tomar cualquier valor real en ambos ejes.

Ejemplo grfico:

"headsca.wrl" El campo rotation determina la rotacin en radianes de los ejes de coordenadas de la textura con respecto al punto marcado por el campo center, despus de haber aplicado el campo scale.

Ejemplo grfico:

"headrot.wrl" Por ltimo, el campo translation provoca un desplazamiento del sistema de coordenadas de la textura.

Ejemplo grfico:

"headtran.wrl" Es importante destacar que todas estas modificaciones aparecen invertidas cuando la textura se aplica sobre la superficie de un objeto. De esta forma si duplicsemos los ejes S y T de una textura (rotate 2 2) cuando se aplicase sobre un objeto se observara que su tamao se ha reducido a la mitad. De igual modo, si desplazasemos la textura 0.5 unidades con respecto al eje S (translation 0.5 0) cuando se aplicase sobre un objeto se podra apreciar que se ha desplazado -0.5 unidades con respecto a la superficie del objeto.

Imgenes distintas en un mismo objeto:

Puede interesar que un objeto tenga imgenes diferentes en alguna o algunas de sus caras, para ello hemos de disear la figura de forma que cada una de sus caras sean objetos independientes. Supongamos que se desea poner una determinada textura sobre las bases de un cilindro y una textura diferente sobre la superficie lateral, los pasos a seguir seran los siguientes:

Se define un cilindro con la textura de la base, anulando las superficies superior e inferior. Se define otro cilindro idntico con otra textura,anulando la superficie lateral.

Por medio del nodo Group se agrupan ambos cilindros, con lo que el resultado es aparentemente un cilindro con imgenes distintas.

En el fichero "lata.wrl" se encuentra definido un objeto creado mediante los pasos anteriormente mencionados.

MovieTexture:
En lugar de usar imgenes estticas como textura de los objetos, se pueden utilizar videos (pelculas), en formato MPEG, haciendo uso del nodo MovieTexture, en vez de ImageTexture.

Sintaxis:
MovieTexture { url "direccin_URL" speed valor_real loop valor_lgico repeatS valor_lgico repeatT valor_lgico }

Ejemplo:
Shape { appearance Appearance { texture MovieTexture { url "ejemplo.mpg" speed 1 loop FALSE } } geometry ... }

El campo url contiene la direccin URL del fichero que contiene el video.

El campo speed controla la velocidad (1, velocidad normal; 2 doble velocidad, etc.). Con valores negativos el video se ejecutara hacia atrs. El campo loop controla si el video funciona ininterrumpidamente (TRUE) o una sola vez (FALSE). Los campos repeatS y repeatT ya se han descrito en el nodo TextureTransform.

Tema 11 : Iluminando el mundo virtual

La colocacin de luces en un mundo virtual permite obtener un mayor grado de realismo, pudiendo convertir un misma escena virtual en un lugar clido,en un lugar tenebroso y sombro, etc. Adems de la ambientacin, tambin juega un importante papel a la hora de determinar que objetos visualizar el visitante con mayor claridad. Existen tres clases de fuentes de iluminacion, a cada una de las cuales se les asocia un nodo: Nodo PointLight Nodo DirectionalLight Nodo SpotLight

Nodo PointLight:
Define la posicin de una luz que ilumina por igual en todas direcciones.

Sintaxis:

PointLight{ color location radius attenuation on intensity ambientIntensity } Campo color location Indica el color de luz.

color_RGB Eje_X Eje_Y Eje_Z valor_real coeficiente1 coeficiente2 coeficiente3 valor_lgico valor_real valor_real

Accin

Determina la posicin que va a ocupar el foco de luz dentro del escenario tridimensional. Limita la zona (en metros) que va a ser iluminada. Almacena tres valores que se utilizan para calcular la atenuacin de la luz conforme nos alejamos del foco. El factor de atenuacin viene dado por la siguiente ecuacin: 1/(coef1+(coef2*radio)+ (coef3*radio*radio)) Indica si los campos intensity y ambientIntensity estn activos (TRUE) o no (FALSE). Establece la intensidad con la que la luz brilla, siendo el valor 1 la mxima intensidad y 0 la mnima. Determina la luminosidad del entorno del foco.

radius attenuation

on

intensity

ambientIntensity

Nodo DirectonialLight:

Define una fuente de luz orientable que ilumina con rayos paralelos a un determinado vector tridimensional.

Sintaxis:
DirectionalLight{ color color_RGB on valor_lgico intensity valor_real ambientIntensity valor_real direction Eje_X Eje_Y Eje_Z } El campo direction contiene el vector que determina la orientacin de la luz emitida dentro del espacio virtual. El resto de campos tienen la misma misin que en el nodo PointLight.

Nodo SpotLight:
Define una fuente de luz de tipo foco, que se coloca en una posicin fija del espacio tridimensional e ilumina en forma de cono a lo largo de una direccin determinada. La intensidad de la iluminacin desciende de forma exponencial segn diverge el rayo de luz desde esa direccin hacia los bordes del cono.El rgimen de descenso y el ngulo del cono se controlan mediante los campos beamWidth y cutOffAngle.

Sintaxis:
PointLight{ color location radius attenuation on

color_RGB Eje_X Eje_Y Eje_Z valor_real coeficiente1 coeficiente2 coeficiente3 valor_lgico

intensity valor_real ambientIntensity valor_real direction Eje_X Eje_Y Eje_Z beamWidth ngulo cutOffAngle ngulo } El campo beamWidth almacena el radio (en radianes) de la base de un cono donde la luz emitida es uniforme y posee su mxima intensidad. Este cono tendra como base este campo, como altura el campo radius (orientado segn el campo direction) y como vrtice el punto indicado en el campo location. El campo cutOffAngle almacena el radio (en radianes) de la base de un cono que contiene al cono mencionado arriba. Tiene las mismas caractersticas a excepcin de su radio, el cual ha de ser mayor. Este radio determina el lugar donde la luminosidad es nula. Entre el radio almacenado en beamWidth y el almacenado en este campo, la intensidad de la luz va decreciendo conforme nos alejamos del primero de los conos.

Tema 12 : Utilizacin de fondos

La utilizacin de fondos en el mundo virtual, nos permite dotarlos de un cielo y de un suelo, aadiendo realismo de esta forma a la escena que se pretende crear. Estos fondos se van a caracterizar porque siempre le van a dar al visitante la sensacin de que se encuentran a una gran distancia. Por otra parte, su coste es menor que el uso de geometras. Se distinguen dos tipos de fondos:

Backdrop

Este tipo de fondo se caracteriza por definir un cielo y un suelo cuyos colores vienen dados mediante gradientes. Se realiza dentro de una esfera (Sphere). Este tipo de fondo se caracteriza porque define una serie de imgenes que rodean la

Panorama

escena. Se realiza dentro de una caja (Box).

Nodo Background:
Incorpora un plano de suelo sombreado, texturas y cielo escnico. Slo se emplea el primer nodo Background que se encuentre, debindose especificar en el archivo principal.

Sintaxis:
Backgroud{ groundAngle [ ] groundColor [ ] skyAngle [] skyColor [] backUrl "direccin_URL" bottomURL "direccin_URL" frontUrl "direccin_URL" leftUrl "direccin_URL" rightUrl "direccin_URL" topUrl "direccin_URL" } Todos estos campos no se utilizan simultaneamente, sino que su uso depender del tipo de fondo que se desee crear.

Backdrop
Sintaxis:
Backgroud{ groundAngle []

groundColor [ ] skyAngle [] skyColor [] }

Ejemplo:
Backgroud{ groundAngle [.785] # color_RGB1,color_RGB2 groundColor [ .14 .28 0,.09 .11 0 ] skyAngle [.785 ] # color_RGB1,color_RGB2 skyColor [.02 0 .26, .02 0 .65 ] } Grficamente podramos obtener lo siguiente:

"backdrop.wrl" El fondo de tipo Backdrop se construye mediante una esfera incompleta (el suelo) inmersa dentro de otra esfera completa (el cielo), en donde el visitante se situa en el centro de ambas. Estas esferas tienen un radio infinito. El campo skyColor determina el color del cielo en los distintos ngulos de la esfera que lo contiene.El primer valor de este campo determina el color del cielo en los 0.0 radianes de la esfera, es decir, el color que tiene

el cielo en el lugar donde se une con el suelo. El campo skyAngle es utilizado para indicar los ngulos (en radianes) en los que un nuevo color debe aparecer. El campo skyColor debe poseer N+1 colores si en skyAngle se han definido N ngulos, ya que el ngulo 0.0 (que es el que se corresponde con el cielo del horizonte) no se incluye en este ltimo. Los campos groundColor y groundAngle, son equivalentes a skyColor y skyAngle respectivamente, pero referidos a la esfera que representa el suelo. Si se especifica ms de un color, se interpolar el color del suelo entre los colores de 0 a 90 grados en el horizonte (plano X-Z). De forma similar se interpretan los colores del cielo, de 90 a 180 grados en la vertical (plano X-Y).

Panorama
Sintaxis:
Backgroud{ backUrl bottomURL frontUrl leftUrl rightUrl topUrl } "direccin_URL" "direccin_URL" "direccin_URL" "direccin_URL" "direccin_URL" "direccin_URL"

Ejemplo:
Backgroud{ backUrl "ba_image.jpg"

bottomURL frontUrl leftUrl rightUrl topUrl }

"bo_image.jpg" "f_image.jpg" "l_image.jpg" "r_image.jpg" "t_image.jpg"

Grficamente podramos obtener lo siguiente:

"panorama.wrl" El fondo de tipo Panorama consiste en seis imgenes, cada una de las cuales ocupa una de las caras de una inmensa caja centrada en el eje de coordenadas. Las imgenes que ocupan cada una de las caras vendrn determinadas por los valores de los campos backUrl, bottomUrl, frontUrl, leftUrl, rightUrl, topUrl. Todos estos campos toman como valor una direccin URL de un fichero que contiene una imgen en formato jpeg, gif o png.

Tema 13 : Utilizacin de niebla

Mediante la utilizacin de niebla es posible simular fenmenos

atmosfricos, modificando a travs de ella el aspecto de los objetos en funcin de la distancia a la que nos encontremos de estos.

Nodo Fog:
Este es el nodo que permite la simulacin de fenmenos atmosfricos mezclando su color con el de los objetos a su alcance.

Sintaxis:
Fog{ color fogtype visibilityRange } color_RGB "Tipo_niebla" valor_real

Ejemplo:
Fog{ color 1 1 1 fogtype "LINEAR" visibilityRange 1 } La niebla oscurece totalmente los objetos a travs del color definido en su campo color. El campo visibilityRange indica la distancia en metros a la cual los objetos no son visualizados por el visitante. La visibilidad va decreciendo desde el punto donde se encuentra el visitante hasta el lmite indicado por este campo, donde la visibilidad es nula. Los objetos ms cercanos se vern dbilmente afectados por la niebla. El campo fogType controla el grado con el que el color de la niebla afecta al resto de los objetos. El tipo por defecto es LINEAR, lo cual indica que la funcin que se utiliza para ocultar los objetos es lineal. La otra opcin es EXPONENTIAL, con la que se emplea una funcin

exponencial, dando lugar a un efecto de niebla ms realista. A continuacin se muestran una serie de ejemplos para clarificar estos conceptos: I) Escenario sin niebla:

"niebla0.wrl" II) Escenario con niebla (da):

"niebla1.wrl"

III) Escenario con niebla (noche):

"niebla2.wrl"

Tema 14 : Niveles de detalle

Definir objetos con diferentes niveles de detalle va a permitir una mayor optimizacin del escenario virtual, ya que los objetos ms lejanos al visitante se representan mediante formas ms simples de las que tendran si se estuviese junto a ellos. Otra de sus ventajas es que se reduce el tiempo de carga del mundo VRML.

Nodo LOD (Level Of Detail):

Este nodo se utiliza para permitir a los navegadores conmutar automticamente entre varias presentaciones de objetos. Los hijos de este nodo representan generalmente el mismo objeto u objetos, a distintos niveles de detalle, que van variando desde el superior al inferior.

Sintaxis:
LOD{ center range level } Eje_X Eje_Y Eje_Z [valor1,valor2,...,valorN] [Nodo1,Nodo2,...,NodoN,NodoN+1]

El campo center determina la posicin que va a ocupar el objeto LOD dentro del sistema de coordenadas. El campo level contiene una lista de nodos que representan a un mismo objeto con diferentes niveles de detalle, definiendose las representaciones de mayor nivel al principio de la lista y los de menor nivel de detalle al final. El campo range contiene una lista de valores en orden creciente que indican a qu distancia se ha de conmutar entre una representacin u otra. Para calcular esta conmutacin se calcula la distancia que hay entre el visitante y el punto central especificado del LOD; si es menor que el primer valor de la lista range entonces se dibuja el primer hijo de LOD indicado en la lista level; si est entre el primer y el segundo valor de la lista range, se dibuja el segundo hijo, y as sucesivamente. Si en la lista range figuran N valores, la lista level ha de tener N+1 hijos. Cada valor del campo range debe ser menor que su predecesor, ya que de no ser as, los resultados seran indefinidos. No se deben usar estos nodos para emular comportamientos, ya que los resultados pueden no coincidir con el efecto deseado. Por ejemplo, la utilizacin de un LOD para hacer que una puerta se abra cuando se aproxima un usuario es posible que no d resultado en todos los navegadores.

Ejemplo LOD de un objeto mediante reduccin del nmero de detalles:

"lod1.wrl"

Ejemplo LOD de un objeto mediante simplificacin de su geometra:

"lod2.wrl"

Tema 15 : Control de colisiones

Nodo Collision:
Indica al navegador que objetos de la escena no se van a poder atravesar. Esto permite evitar, por ejemplo, que los visitantes traspasen las paredes de un edificio. La respuesta a la colisin la define el navegador ( haciendo que se rebote en el objeto, detenindose simplemente, etc.). Dado que es muy costoso el clculo de una colisin con una geometra compleja, para aumentar la eficacia se puede utilizar un mtodo que consiste en definir una geometra alternativa que sirva como sustituto para colisiones. Esta geometra podra ser tan imperfecta como un simple cuadrado o una esfera. Este volumen alternativo se usa solamente para calcular la colisin con el visualizador. VRML ofrece volmenes alternativos de colisin para objetos mediante el nodo Collision.

Sintaxis:
Collision{ collide proxy children } valor_lgico nodo [ ...]

Si el valor del campo collide es FALSE entonces no se realiza colisin con la geometra afectada; si es TRUE el campo proxy define la geometra contra la que se hace la prueba de colisin. Si el valor de proxy no est definido o es NULL, se colisionar con la geometra real, y si no es NULL, contendr la geometra que se emplea para calcular las colisiones.

Tema 16 : Utilizacin de sonidos

La adicin de sonidos al escenario le aade mayor realismo. Las principales aplicaciones del sonido son: ruidos o msicas de fondo, sonidos localizados en un determinado punto del escenario (como por ejemplo el sonido de una catarata) o sonidos que se activan cuando se realiza una determinada accin (al pulsar un interruptor, saltar una pared,etc.). VRML utiliza dos nodos diferentes para controlar las fuentes de sonido:

Nodo AudioClip Nodo Sound

Nodo AudioClip:
Es utilizado bsicamente para cargar el fichero (en formato .wav o .mid) donde se encuentra almacenado el sonido. Se invoca el fichero a travs de su direccin URL.

Sintaxis:
AudioClip{ url description loop pitch } "direccin_URL" "descripcin_del_sonido" valor_lgico valor_real

El campo url contiene la direccin URL del fichero que contiene el sonido, ya sea en formato .wav o .mid. El campo description es una descripcin textual del sonido.

El campo loop especifica si el sonido se ha de repetir constantemente. Por defecto, el sonido se reproduce una sola vez. Si el sonido no est en modo loop, el tiempo de reproduccin viene dado por la duracin del archivo. El campo pitch controla el tono y la velocidad con la que se reproduce el sonido. Solo admite valores positivos. Si, por ejemplo, este campo tomase el valor 2.0, el sonido se emitira con el doble de su velocidad normal y con un tono una octava superior al del sonido original.

Nodo Sound:
Define una fuente de sonido situado en un lugar especifico 3D.

Sintaxis:
Sound{ source AudioClip{...} intensity valor_real location Eje_X Eje_Y Eje_Z direction Eje_X Eje_Y Eje_Z minFront valor_real minBack valor_real maxFront valor_real maxBack valor_real spatialize valor_real } El campo source toma como valor un nodo de tipo AudioClip, en donde se define el fichero de sonido a reproducir. El campo intensity ajusta el volumen de cada fuente de sonido.Admite nicamente valores entre 0 y 1. Una intensidad 0 es silencio y una intensidad 1, la correspondiente a la contenida en el fichero de sonido.

El campo location determina en el espacio tridimensional la posicin del foco de sonido. El campo direction especifica un vector tridimensional normal, en cuya direccin se emite el sonido. Los campos minFront y minBack determinan, junto con la direccin, la extensin de la regin (hacia delante y hacia atrs respectivamente) donde la intensidad del sonido es mxima. De forma similar, los campos maxFront y maxBack determinan los lmites de la regin a partir de la cual el sonido ya no ser audible. El campo spatialize determina la forma en la que se emite el sonido. Si su valor es TRUE, el sonido parecer provenir de un nico punto ("musica2.wrl"). Por el contrario, si su valor es FALSE, obtendremos un efecto envolvente, lo cual se utiliza para crear sonidos ambientales ("musica1.wrl").

Tema 17 : Descripcin del mundo

Nodo WorldInfo:
Contiene informacin sobre el mundo.

Sintaxis:
WorldInfo{ info [ "comentario1", "comentario2", ... "comentarioN"]

title "nombre_del_mundo" } El ttulo se almacena en el campo title, permitiendo a los navegadores mostrarlo, por ejemplo, en el borde de su ventana. Cualquier otra informacin sobre el mundo se puede almacenar en el campo info, como por ejemplo, el autor de la escena, informacin sobre los derechos de autor e informacin de dominio pblico.

Iluminacin.

Tutorial de VRML97
Existen tres tipos de iluminacin en VRML: luz direccional (node DirectionalLight), luz puntual (node PointLight) y espot de luz (node SpotLight). Cada uno de los tres tipos de luz corresponde a uno de los tres modelos clsicos de luz en grficos per ordenador.
Iluminacin Ambiente

El tratamiento de la luz ambiental es diferente en VRML respecto a otros sistemas grficos. Es decir, tradicionalmente aquella parte de la luz que ilumina los objetos de forma indirecta, por rebotes de luz provinientes de las mltiples reflexiones y radiaciones sobre otros objetos adyacentes, es modelada mediante un nico concepto llamado luz ambiental o luz ambiente. Esta luz ambiente se acostumbra a modelar mediante un valor nico que representa un incremento de intensidad que se aplicar al color de los objetos, de forma uniforme. Esto es una simplificacin de lo que, de otra forma, resultara muy costoso en tiempo de clculo. En VRML no se dispone de un control nico para simular la iluminacin ambiente. En VRML disponemos de un control de emisin de luz ambiente por cada tipo de luz y un control de reflexin de luz ambiente por cada material. Es decir, que cada tipo de luz define su incremento de intensidad (que en caso de haber mltiples luces definidas, se van acumulando sus ilumiaciones ambiente sobre la intensidad de cada objeto), y por otra parte, cada material define en qu proporcin se ver afectado por esa iluminacin ambiente de cada luz. En el node Material se encuentra el field ambientIntesity el cual determina en qu proporcin el material refleja la intensidad ambiente de las luces definidas en el entorno. El valor de este field debe estar dentro del rango [0, 1] y su valor por defecto es 0'2.
node DirectionalLight

Con este tipo de luz podemos iluminar los objetos con rayos paralelos entre s, como si fueran los rayos del sol al llegar a la tierra. En otras palabras, no tenemos un punto de luz del que salen radialmente los rayos, sino que todos los rayos son paralelos entre s y por tanto inciden con el mismo ngulo sobre una superfcie. Veamos un ejuemplo:

Ejemplo1: Definicin de una iluminacin paralela que proviene de arriba a la derecha en direccin hacia abajo a la izquierda.
DirectionalLight {

ambientIntensity 0.5 color 1 1 1 intensity 1 direction -0.5 -0.5 0 } Shape { appearance Appearance { material Material { ambientIntensity 1 diffuseColor 0 0 1 } } geometry Sphere { radius 2 } } Transform { translation 2 5 -5 children [ Shape { appearance Appearance { material Material { ambientIntensity 1 diffuseColor 1 1 0 } } geometry Cone { bottomRadius 2 height 3 } } ] }

En este entorno se ve claramente como la parte superior derecha de los objetos est muy iluminada por la luz direccional y en cambio la zona inferior izquierda est en sombra, solamente ligeramente iluminada por la intensidad ambiente. En este ejemplo hemos definido que la reflexin de la intensidad ambiente de los materiales sea el mximo para as poder apreciar bien la intensidad ambiente generada por la luz direccional. Analizando el cdigo del node DirectionalLight vemos el field ambientIntensity con un valor intermedio. Si ponemos un valor bajo, las sombras se intensifican resultando ms duras o contrastadas. En cambio, si ponemos un valor elevado, las sombras quedan poco notorias y en consecuencia suaves. El field siguiente es el field color donde definimos el color que tendr la luz. Cabe resaltar que no es la intensidad, sino slo el color. El color que hemos definido es totalmente blanco, como la luz del sol al medioda. Si quisiramos simular una puesta de sol, definiramos una luz anaranjada (por ejemplo: RGB = [0.8 0.4 0]). Despus del color viene el field intensity donde se define la potencia con que la luz ilumina. Hemos definido el valor mximo para que se viera claramente la influencia de la luz sobre los objetos.

Finalmente, el field direction es el que determina la direccin de los rayos de luz. Lo que se debe definir es un vector director. En este caso hemos definido el [-0.5 -0.5 0] que significa que si partimos del origen de coordenadas, el rayo sale hacia abajo e izquierda con la misma proporcin, pero no sale ni hacia delante ni atrs. NOTA: Existe una luz que est encendida por defecto y que puede estorbar al hacer pruebas de iluminacin. Es una luz asociada al punto de vista llamada "Headlight" y que viene a ser como una luz de casco de minero. Esta luz puede ser apagada desde el men del browser (o en el CosmoPlayer con el asterisco "*"), pero tambin puede ser totalmente eliminada desde VRML con un comando especial. Nosotros hemos apagado esta luz mediante el comando en el cdigo del ejemplo, aunque no lo hemos incluido arriba. Por lo tanto no veris el efecto de esta luz. El comando para conseguir apagarla es: NavigationInfo { headlight FALSE }. Si quisierais saber como se vera el entorno con esta luz encendida, lo podis hacer desde el men del browser. A continuacin veremos un ejemplo jugando con los colores de luz. Ejemplo2: Definicin de tres luces direccionales con tres colores diferentes sobre una esfera blanca.
DirectionalLight { # Luz Roja ambientIntensity 0.5 color 1 0 0 intensity 1 direction 0.5 -0.5 -0.1 } DirectionalLight { # Luz Verde ambientIntensity 0.5 color 0 1 0 intensity 1 direction -0.5 -0.5 -0.1 } DirectionalLight { # Luz Azul ambientIntensity 0.5 color 0 0 1 intensity 1 direction 0 0.5 -0.1 } Shape { appearance Appearance { material Material { ambientIntensity 1 diffuseColor 1 1 1 } } geometry Sphere { radius 2 } }

Con este ejemplo se puede ver la interaccin entre luces distintas. Las tres luces que hemos definido son de tres colores bsicos de la luz: Rojo arriba a kla izquierda, Verde arriba a la derecha y Azul abajo al centro. De este modo podemos ver la esfera iluminada uniformemente obteniendo zonas donde slo incide una sola luz (y slo se ve el color de esa luz), y otras zonas donde inciden ms de una luz resultando el color de la mezcla de luces (por ejemplo rojo y verde forman amarillo).
node PointLight

las luces puntuales tienen la propiedad de irradiar rayos de luz en todas direcciones a partir de un punto dado en el espacio. Por esta razn no definen una direccin de iluminacin. Lo que si definen es lo que se conoce como atenuacin. Lo que significa es que la luz tiene una cierta fuerza que va menguando conforme nos alejamos de la fuente luminosa. La atenuacin es una propiedad fsica que se manifiesta debido a la prdida de energa de los fotones al alejarse de la fuente de luz. Esta prdida se puede modelar mediante una frmula matemtica que tiene en cuenta la distancia de la fuente de luz a un punto determinado, as como el cuadrado de esta distancia. Aqu no entraremos a ver el funcionamiento de la frmula y solo diremos que en el node PointLight el field attenuation dispone de tres parmetros, los cuales se pueden variar para obtener diversos efectos de atenuacin. Otra propiedad de estas luces es el radio de accin. Se puede definir una distancia a partir de la cual, independientemente de la atenuacin, la luz ya no acta. Esto sirve para hacer ms eficiente el render a tiempo real. Acontinucain damos dos pequeos ejemplos con dos tipos de atenuacin distintos y un mismo radio de accin.

Ejemplo3: Definicin de una luz puntual azul, sin atenuacin sobre una superfcie blanca.
PointLight { # Luz azul sin atenuacin location 8 -3 -10 radius 15 ambientIntensity 0.5 color 0 0 1 intensity 1 attenuation 1 0 0 # Esta combinacin no presenta atenuacin } Transform { translation 0 -5 -10 children Shape { appearance Appearance { material Material {

ambientIntensity 1 diffuseColor 1 1 1 } } geometry Box { size 20 1 10 } } }

Ejemplo4: Definicin de una luz puntual azul, con atenuacin sobre una superfcie blanca.
PointLight { # Luz azul con atenuacin location 8 -3 -10 radius 15 ambientIntensity 0.5 color 0 0 1 intensity 1 attenuation 1 0.5 0 # Presenta una cierta atenuacin } Transform { translation 0 -5 -10 children Shape { appearance Appearance { material Material { ambientIntensity 1 diffuseColor 1 1 1 } } geometry Box { size 20 1 10 } } }

node SpotLight

Este tipo de luz es el ms complejo. La propiedad principal es el hecho que los rayos de luz salen de un punto determinado, en una direccin determinada. Es como una luz de teatro a la cual adems de la direccin en que ilumina, tambin se define el ngulo de apertura del haz de luz. Veamos un ejemplo y estudiemos sus partes: Ejemplo5: Definicin de un espot de luz roja, sin atenuacin sobre una superfcie blanca.
SpotLight { # Spot rojo location 0 0 -10

radius 3 ambientIntensity 0.5 color 1 0 0 intensity 1 attenuation 1 0 0 # Esta combinacin no presenta atenuacin direction 0 -1 0 # apunta directamente hacia abajo cutOffAngle 1.0472 # 60 grados en radianes beamWidth 0.785398 # 45 grados en radianes } Transform { translation -10 -4 -15 children Shape { appearance Appearance { material Material { ambientIntensity 1 diffuseColor 1 1 1 } } geometry ElevationGrid { colorPerVertex FALSE xDimension 20 zDimension 10 xSpacing 1 zSpacing 1 height [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] } } }

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0

NOTA: En este ejemplo, en vez de un Box utilizamos una ElevationGrid como geometra para que sea ms claro el efecto de punto de luz. Este nodo no lo hemos visto en el tutorial, pero no presenta ninguna complicacin. Lo nico que debe entenderse es que es una malla se 20x10 donde cada cuadrado de la malla tiene un teamao de 1x1 unidades y que en realidad no son cuadrados, sino parejas de tringulos. Lo utilizamos para que el sombreado de los tringulos haga ms visible la diferente intensidad que llega a cada uno de ellos. En el ejemplo, todo es anlogo al node PointLight hasta la atenuacin. Lo que vara son los fields direction, cutOffAngle y beamWidth. El field direction permite dar el vector director dhaz de luz, es decir, la direccin en la que dirigimos la luz.

El field cutOffAngle nos determina el ngulo de apertura total del haz de luz (como siempre, definido en radianes). Se debe tener en cuenta que este ngulo hace referencia a la mitad de la apertura y que por lo tanto si queremos una apertura total de 60 grados, debemos especificar un field cutOffAngle de 30 grados. El field beamWidth define un ngulo interno al field cutOffAngle donde la intensidad del haz de luz es mxima y uniforme. Entre el ngulo especificado por field beamWidth y el especificado por field cutOffAngle la intensidad del haz de luz va menguando de dentro a fuera creando una zona difuminada.
Ejercicios propuestos: Diversas luces Definir diversos tipos de lucess iluminando objetos blancos como prctica y experimentacin

Punts de Vista.

Tutorial de VRML97
En VRML97 existe la posibilidad de definir puntos de vista diversos de forma que podemos mostrar al usuario aquellas partes que nos parecen importantes del mundo que hemos definido. El usuario podr continuar navegando con total libertad, poro si definimos una srie de puntos de interes, l podr ir dirctamente a estos sin porderse ni dudar.
node Viewpoint

La forma de definir estos puntos de vista o puntos de interes, es mediante el node Viewpoint.
Posicin y Orientacin Como siempre, veremos un ejemplo y despus lo estudiaremos:

Ejemplo1: Definicin de dos puntos de vista de un mundo sencillo.

Viewpoint { position 0 0 10 orientation 0 0 1 0 description "PVpor_Defecto" }

Viewpoint { position 10 0 10 orientation 0 1 0 0.7854 # 45 grados en radianes description "PV_tres_cuartos" } Shape { appearance Appearance { material Material { diffuseColor 1 0.6 0 } } geometry Sphere { radius 2 } } Transform { translation 0 0 -8 children Shape { appearance Appearance { material Material { diffuseColor 0.4 0 1 } } geometry Sphere { radius 2 } } }

Para escoger otro punto de vista, se utiliza le utilidad que el browser normalmente tiene disponible. El primer punto de vista que se define en el cdigo, pasa a ser el punto de vista de arranque del mundo cuando se abre en un browser. (Tambin es usual poder pasar de un punto de vista a otro con las teclas de avanzar y retroceder pgina del teclado). Ahora si, examinemos las partes. El primer node Viewpoint define un punto de vista idntico al que ya se establece por defecto al entrar al browser. Esto nos sirve para poder volver a la posicin inicial sin tener que volver a cargar el entorno. Los valores por defecto son pus, situar el observador sobre el eje Z positivo a 10 unidades del origen y mirando en direccin del eje Z negativo. La forma en que funciona el field orientation es bastante incmoda ya que no utiliza el modelo conocido como "look at" ("mira a..") sino que utiliza un vector como eje de rotacin y un ngulo de rotacin para desviar el vector director por defecto de la cmara: el [0 0 -1]. En el caso del punto de vista por defecto, el eje de rotacin definido (los tres primeros valores del field orientation), es el eje Z. pero esto en realidad es indiferente ya que el ngulo de rotacin (el ltimo valor del field orientation) es, de hecho, cero grados. Por lo tanto no hay desviacin. En el segundo punto de vista se entendern mejor los conceptos. Aqu definimos la posicin del observador a 10 unidades positivas en el eje X y 10 unidades positivas en el eje Z. Lo que queremos conseguir es una vista tres cuartos de escena y por lo tanto queremos mirar en direccin al origen de coordenadas. Para hacer esto, debemos desviar el vector director por defecto de la cmara, que es el [0 0 -1], es decir, el que mira en la direccin del eje Z negativo. Para desviarlo hacia el origen debemos rotar 45 grados respecto al eje Y (local del punto de vista), tal y com muestra la figura:

Angulo de Visin

As como en una cmara se puede cambiar la lente para tener un ngulo de visin ms o menos amplio, el modelo de punto de vista de VRML97 permite variar este ngulo de visin. El ngulo que se vara es el horitzontal y el vertical se adapta automticamente segn las proporciones de la ventana del browser. Veamos un ejemplo con tres puntos de vista simulando tres tipos de lentes: Ejemplo2: Definicin de tres puntos de vista de un mundo sencillo.
Viewpoint { fieldOfView 2.618 description "Gran_Angular" } Viewpoint { fieldOfView 1.3962667 description "80mm" } Viewpoint { fieldOfView 0.31416 description "Telefoto" } Shape { appearance Appearance { material Material { diffuseColor 1 0.6 0 } } geometry Box { size 30 10 2 } } Shape {

appearance Appearance { material Material { diffuseColor 0.3 0 1 } } geometry Box { size 8 5 5 } } Shape { appearance Appearance { material Material { diffuseColor 0 1 0.5 } } geometry Box { size 1 1 8 } }

Hace falta tener claro que al cambiar de punto de vista, la posicin del observador no se modifica, es decir, el observador no se mueve ni hacia delante ni atrs, sio que es como si tuviese un zoom el cual utiliza para ampliar o reducir lo que cae en su rango de visin.
Paso de un punto de vista a otro

Otra propiedad de los puntos de vista es la de pasar de uno a otro de forma suave o saltando directamente . Trabajando con el Cosmo Player (y en general con todos los browsers) el paso de uno a otro de manera suave es la forma por defecto. Si se desea saltar de golpe, debemos modificar el field jump y ponerlo a TRUE. Si de manera explcita se quiere saltar de manera suave, debemos modificar el field jump y ponerlo a FALSE.

Prototipos, DEF y USE.

Tutorial de VRML97
PROTO

Cuando se modelan objetos para un entorno, nos podemos encontrar que necesitemos definir un tipo de objeto que ser utilizado de formas diferentes en diferentes sitios del entorno. Para poder definir un objeto genrico y poder utilizarlo con parmetros diferentes en diferentes lugares, VRML97 dispone de los prototipos. Debe quedar claro que PROTO no es un node de VRML97, sino un mecanismo para definir nuevos nodes. Lo que se hace al definir un prototipo, es definir un tipo de objeto nuevo para poderlo utilizar de la misma forma en que utilizamos los node Box, node Sphere, node Material, node Appearance, etc. Veamos un ejemplo para entender las diferentes partes. Ejemplo1: Definicin de un prototipo de Paraguas. Se define el nuevo tipo de node Paraguas.

PROTO Paraguas [ field SFColor colorBaston 0.1 0.1 0 field SFColor colorTela 0 0.2 1 ] { Group { children [ Shape { geometry Cylinder { height 3 radius 0.1 } appearance Appearance { material Material { diffuseColor IS colorBaston } } } Transform { translation 0 1.75 0 children Shape { geometry Cone { height 0.5 bottomRadius 3 } appearance Appearance { material Material { diffuseColor IS colorTela } } } } ] } } Paraguas { } #Creamos un objeto Paraguas con los valores por defecto Transform { translation 8 0 0 children Paraguas { colorBaston 0.2 0 0 colorTela 0 0.2 0.1 } } Transform { translation -8 0 0 children Paraguas { colorBaston 0 0 0.3 colorTela 0.4 0 0.1 } }

Analicemos el ejemplo. Comenzamos definiendo el prototipo con la palabra clave PROTO. A continuacin damos el nombre que deseamos que tenga el nuevo tipo de node que definimos, en este caso Paraguas. Entonces debemos definir los parmetros que podremos variar de nuestro prototipo cada vez que necesitemos uno. Nosotros hemos decidido que para el paraguas podremos variar el color de sus piezas pero no podremos variar sus medidas. Para esto definimos dos fields, uno para el color del bastn field SFColor colorBaston y otro para el color de la tela que sirve de tela field SFColor colorTela. Como ambos son colores, los hemos definido de tipo SFColor (single-valued field color, campo de color univaluado). A cada uno le damos el color por defecto porque si alguien define un objeto de tipo Paraguas y no le da valores a los parmetros, el VRML97 tinga unos colores para utilizar. Ahora ya podemos definir como sern las caractersticas generales de nuestro nuevo node Paraguas.

Para empezar, utilizamos un nuevo node que es el node Group. Este node sirve para agrupar en un solo objeto, varios subobjetos. Este node nos agrupar el objeto bastn y el objeto tela de nuestro paraguas. Si no los agrupsemos y definisemos el objeto bastn y a continuacin el objeto tela, el prototipo estara formado por un bastn visible y una tela invisible. En la definicin de un prototipo se pueden poner tantos objetos com se quiera, pero siempre se tomar el primero para determinar el tipo de node que se est definiendo y para visualizarlo. El resto de objetos pueden servir para muchas cosas, pero no sern visualizados. As pus, definimos un cilindro que nos har de bastn. Como se puede observar, la geometra del cilindro est fijada. En cambio, la apariencia es lo que deseamos poder variar. Por lo tanto, definimos una apariencia con un material y con un color. La forma de conseguir que el color sea el que nosotros deseamos al definir un paraguas concreto, es utilizando la palabra clave IS. Esta palabra hace que podamos definir que el field diffuseColor de nuestro objeto sea en realidad (IS) el field colorBaston que hemos definido en los parmetros. De forma anloga se define la parte de la tela que definimos mediante un cono trasladado hacia arriba para que encaje bien con el bastn. Hasta aqu hemos definido el prototipo y como tal, no es un objeto que exista. Si no pusiramos nada ms en el archivo de VRML97, y lo cargsemos en un browser, obtendramos una escena vaca. Esto es por qu un PROTO es tan solo un molde del cual queremos sacar objetos concretos. Para esto lo que hacemos a continuacin es lo que se llama instanciar un objeto a partir del prototipo. Por el solo hecho de poner el nombre del nuevo node Paraguas, ya estamos creando una instancia del prototipo. Como en este primer caso tan solo ponemos unas llaves vacas ({}), no estamos definiendo parmetros para este objeto en concreto. En este caso se utilizan los parmetros por defecto que havamos establecido dentro del prototipo. Las otras dos instanciaciones, se hacen trasladando el paraguas a un lado y otro del primero, y dando colores diferentes de los colores por defecto. Debe quedar claro que al instanciar los tres paraguas obtenemos tres objetos diferenciados y que si modificamos uno los otros no se vern alterados. A continuacin mostramos un ejemplo ms complejo: Ejemplo2: Definicin de un prototipo de banquillo. Se define el nuevo tipo de node Banquillo.
PROTO Banquillo [ field SFColor field SFColor field SFVec3f field SFVec3f ] { PROTO Pata [

colorPatas 1 colorAsiento proporciones posicion 0 0

1 0 0 0 1 1 1 1 0

field SFColor colorPata 1 1 0 field SFVec3f posicion 0 0 0 ] { Transform { translation IS posicion children Shape { geometry Cylinder { radius 0.1 height 1 } appearance Appearance { material Material { diffuseColor IS colorPata } } } } } Transform { translation IS posicion scale IS proporciones children [ Shape { # Asiento geometry Box { size 1 0.2 1 } appearance Appearance { material Material { diffuseColor IS colorAsiento } } } Pata { posicion 0.4 -0.6 0.4 colorPata IS colorPatas } Pata { posicion -0.4 -0.6 0.4 colorPata IS colorPatas } Pata { posicion -0.4 -0.6 -0.4 colorPata IS colorPatas } Pata { posicion 0.4 -0.6 -0.4 colorPata IS colorPatas } ] } } Banquillo { } #Creamos Banquillo { colorPatas Banquillo { colorPatas Banquillo { colorPatas proporciones 3 1 1 } un objeto Banquillo con los valores por defecto 1 0.5 0 colorAsiento 0.5 0 1 posicion -2 0 0 } 0.5 1 0 colorAsiento 1 0.5 0 posicion 2 0 0 } 1 0 0.8 colorAsiento 1 0.5 0 posicion 0 2 0

En este ejemplo vemos un prototipo de banquillo que se ayuda de otro prototipo de pata para definir sus cuatro patas. Recordad que PROTO no es un node y por lo tanto, aunque sea lo primero que se define dentro del PROTO Banquillo, no se toma en cuenta y lo que define al prototipo externo es el node Transform que engloba las piezas del banquillo. Cabe resaltar como los nombres de los fields no se solapan entre el PROTO padre y el hijo. Es decir, que por ejemplo, podemos tener como field el nombre posicion tanto en uno com en el otro, y se sabe perfectamente a quien se est haciendo referencia en cada momento debido al mbito donde se encuentra.

DEF y USE

Cuando queremos definir un objeto que se utiliza en muchos sitios y nos satura el cdigo por el hecho de repetir y repetir un mismo bloque de cdigo, entonces podemos utilizar DEF y USE. No debemos confundir estos dos comandos con PROTO. DEF y USE no definen un objeto genrico que se instanca como objeto particular al llamarlo con unos ciertos parmetros. Lo que estos dos nuevos comandos permiten es dar nombre a un cierto nodo que posteriormente utilizaremos con la misma estructura y definicin en diversos sitios. Veamos un ejemplo: Ejemplo3: Utilizacin de DEF y USE.
DEF MiRojo Appearance { material Material { diffuseColor 0.8 0.2 0.4 } } Transform { translation -2 0 0 children Shape { geometry Box { size 3 3 3 } appearance USE MiRojo } } Transform { translation 2 0 0 children Shape { geometry Sphere { radius 2 } appearance USE MiRojo } }

Aqu vemos como hemos DEFinido una apariencia que despus USEmos en dos objetos diferentes. Lo que hemos hecho en realidad es sencillamente darle el nombre MiRojo a un trozo de cdigo para despus ahorrarnos el escribirlo muchas veces. Y quizs an ms importante que el ahorro en escritura, es la gran ayuda que supone cuando decidimos variar la definicin de color de MiRojo, ya que si tenemos la difinicin de color repetida en distintos lugares, es necesario encontrar todas las repeticiones y modificar cada una de ellas, en cambio si est DEFinido tan solo lo tenemos que variar en este sitio y automticamente se nos modifica en todos los lugares donde lo USEamos. Por ejemplo, si queremos que nuestro color MiRojo en relidad sea ms rojo solo tenemos que variar su DEFinicin: Ejemplo4: Modificamos ejemplo anterior.

DEF MiRojo Appearance { material Material { diffuseColor 1 0.2 0 } } Transform { translation -2 0 0 children Shape { geometry Box { size 3 3 3 } appearance USE MiRojo } } Transform { translation 2 0 0 children Shape { geometry Sphere { radius 2 } appearance USE MiRojo } }

Ejercicios propuestos: Rueda de Coche Definid un prototipo de rueda de coche que pueda ser situada donde se quiera en el espacio 3D, que se pueda orientar y que pueda girar sobre su eje como si rodase en el suelo. Una vez definido, construir un "coche" con las cuatro ruedas, donde las dos delanteras estn orientadas como si el coche girase a la izquierda. Comentarios

Utilizar tan solo primitivas para modelar los objetos. Utilizar transformaciones individuales para cada caracterstica.

Solucin propuesta: roda.wrl.

Materiales II.

Tutorial de VRML97
Ya hemos visto una introduccin a los materiales en el mdulo Primitivas y Materiales I. All hemos visto como tratar con el color bsico de los objetos, es decir el color difuso.

Ahora veremos otras propiedades de color y de textura que se pueden definir en los objetos en VRML.
Materiales Brillantes

El node Material tiene dos fields para poder controlar las caractersticas de brillantez de un material. Estos fields son field specularColor y field shininess. El primero define el color que presenta un objeto al reflejar especularmente la luz. El segundo determina que tan definido o borroso es el reflejo especular. Veamos un ejemplo donde aparecen cuatro esferas cada una con unos parmetros diferentes: Ejemplo1: Definicin de cuatro materiales especulares.
Shape { # Objeto de referenca con material mate. geometry Sphere { radius 1.5 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 } } } Transform { translation -2 2 0 children Shape { geometry Sphere { radius 1.5 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 specularColor 1 0 0 shininess 0 } } } } Transform { translation 2 2 0 children Shape { geometry Sphere { radius 1.5 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 specularColor 1 0 0 shininess 0.05 } } } } Transform { translation -2 -2 0

children Shape { geometry Sphere { radius 1.5 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 specularColor 1 0 0 shininess 0.3 } } } } Transform { translation 2 -2 0 children Shape { geometry Sphere { radius 1.5 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 specularColor 1 0 0 shininess 1 } } } }

La primera esfera (la que queda al centro del conjunto), no tiene definido un material especular para tener una referencia respecto a los otros.

Materiales Autoiluminados

Cuando se desea definir un material para emular que emite luz, como por ejemplo un fluorescente, se puede utilizar el field emissiveColor. Con este field se puede definir el color que emite el material sin necesidad de que haya una fuente de luz que ilumine. Ejemplo2: Definicin de materiales autoiluminados.
Transform { translation -1.5 0 0 children Shape { geometry Cylinder { radius 0.2 height 8 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 } } } } Transform {

translation -0.5 0 0 children Shape { geometry Cylinder { radius 0.2 height 8 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 emissiveColor 1 1 1 } } } } Transform { translation 0.5 0 0 children Shape { geometry Cylinder { radius 0.2 height 8 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 emissiveColor 1 1 0 } } } } Transform { translation 1.5 0 0 children Shape { geometry Cylinder { radius 0.2 height 8 } appearance Appearance { material Material { diffuseColor 0.5 0.5 0.5 emissiveColor 0.6 1 1 } } } }

Materiales Transparentes

La transparencia es otra propiedad a poder modificar mediante un field de material. El field transparency nos permite dar el grado de transparencia del material en el rango [0 1]. Ejemplo3: Definicin de materiales transparentes.
Transform { # Objeto de fondo para referencia translation 0 0 -2 children Shape { geometry Box { size 10 10 0.5 } appearance Appearance { material Material {

diffuseColor 0 0 1 } } } } Transform { translation -3.75 0 0 children Shape { geometry Box { size 2 4 0.5 appearance Appearance { material Material { diffuseColor transparency } } } } Transform { translation -1.25 0 0 children Shape { geometry Box { size 2 4 0.5 appearance Appearance { material Material { diffuseColor transparency } } } } Transform { translation 1.25 0 0 children Shape { geometry Box { size 2 4 0.5 appearance Appearance { material Material { diffuseColor transparency } } } } Transform { translation 3.75 0 0 children Shape { geometry Box { size 2 4 0.5 appearance Appearance { material Material { diffuseColor transparency } } } }

} 0.5 0.5 0.5 0

} 0.5 0.5 0.5 0.33

} 0.5 0.5 0.5 0.66

} 0.5 0.5 0.5 0.9

Texturas

El texturado de objetos no se hace mediante el node Material dentro de la apariencia, sino que se utiliza otro field del node Appearance: el field texture. En este field se pueden insertar tres nodes posibles: node ImageTexture, node MovieTexture o node PixelTexture. Aqu tan solo veremos el primero.
node ImageTexture

En este node se define el URL (es decir, la direccin) de la imagen que ha de servir como textura. La especificacin del VRML97 dice que los formatos estndares son el JPEG y el PNG, pero recomienda que tambin se acepte el GIF incluyendo transparencia . Veamos un ejemplo: Ejemplo4: Aplicacin de una textura a un cubo.
Transform { translation -2 0 0 children Shape { geometry Box { size 3 3 3 } appearance Appearance { texture ImageTexture { url "teapot.gif" } } } } Transform { translation 2 0 0 children Shape { geometry Box { size 3 3 3 } appearance Appearance { material Material { diffuseColor 1 1 1 } texture ImageTexture { url "teapot.gif" } } } }

El cubo de la izquierda (el primero que definimos), tan solo tiene el field texture definido. Esto causa que el cubo no sea iluminado por ninguna de las fuentes de luz del entorno y resta con los colores originales de la textura. En cambio, el de la derecha, tambin tiene definido el field appearance con un color difuso. Esto provoca que si sea iluminado por las fuentes de luz del entorno. Probad de apagar el headlight desde el men de opciones y mirad la diferencia entre uno y otro.

El siguiente ejemplo muestra como queda aplicada la textura sobre cada una de las primitivas: Ejemplo5: Aplicacin de una textura a las primitivas.
DEF Textura Appearance { material Material { diffuseColor 1 1 1 } texture ImageTexture { url "teapot.gif" } } Transform { translation -2 2 0 children Shape { geometry Box { size 3 3 3 } appearance USE Textura } } Transform { translation 2 2 0 children Shape { geometry Sphere { radius 1.5 } appearance USE Textura } } Transform { translation -2 -2 0 children Shape { geometry Cone { height 3 bottomRadius 1.5 } appearance USE Textura } } Transform { translation 2 -2 0 children Shape { geometry Cylinder { height 3 radius 1.5 } appearance USE Textura } }

Para poder variar el tamao y colocacin de la textura sobre el objeto, se puede usar el field textureTransform de aparencia. En este field, se debe utilizar el node TextureTransform que permite escalar, rotar y trasladar la textura. Ejemplo6: Modificacin de una textura en un cubo.

Shape { geometry Box { size 3 3 3 } appearance Appearance { material Material { diffuseColor 1 1 1 } texture ImageTexture { url "teapot.gif" } textureTransform TextureTransform { scale 2 2 rotation 1.5708 # PI/2 } } }

Debemos tener en cuenta que lo que estamos haciendo es escalando, rotando y trasladando las coordenadas de textura y no la textura en si misma, por lo tanto un escalado de [2 2] no la ampla al doble, sino que la reduce a la mitad (y por eso se repite), y una rotacin de PI/2 no rota la textura PI/2, sino -PI/2, etc. A continuacin podeis ver un ejemplo con una textura GIF con transparencia . Esto es til para texturar polgonos con imgenes de objetos los cuales seran complejos de modelar con geometra , como por ejemplo rboles (lo veremos ms adelanteen el mdulo Billboarding). Ejemplo7: Cubo con textura GIF con transparencia .
Transform { # Fondo de referencia translation 0 0 -5 children Shape { geometry Box { size 10 10 0.2 } appearance Appearance { material Material { diffuseColor 0.2 0.8 0.4 } } } } Shape { geometry Box { size 4 2 4 } appearance Appearance { material Material { diffuseColor 1 1 1 } texture ImageTexture { url "teapot2.gif" } } }

Ejercicios propuestos: Diversas Transformaciones de Textura Hacer pruebas con diversos tipos de transformaciones sobre las coordenadas de textura como prctica y experimentacin.

"Billboarding" y Colisiones.

Tutorial de VRML97
"Billboarding"

Esta tcnica se utiliza mucho en grficos 3D a tiempo real para representar objetos que tendran una geometria muy compleja si fueran modelados en polgonos. Lo que se hace es texturar un solo polgono con la textura del objeto en cuestin y se le da la propiedad de "billboard" o "valla publicitaria", con la cual se consigue que el polgono siempre est encarado hacia el observador. Con esto se consigue que nunca se descubra el "truco" porque el usuario nunca ver el polgono de perfil. En VRML97 esto se consigue mediante el node Billboard. Veamos un ejemplo: Ejemplo1: Definicin de un arbol mediante un billboard.
Billboard { axisOfRotation 0 1 0 children Shape { geometry IndexedFaceSet { coord Coordinate { point [ 2 3 0, -2 3 0, -2 -3 0, 2 -3 0 ] } coordIndex [ 0 1 2 3 ] solid FALSE texCoord TextureCoordinate { point [ 1 1, 0 1, 0 0, 1 0 ] } } appearance Appearance { texture ImageTexture { url "redwood.gif" } }

} }

Lo que definimos es un polgono con las proporciones de nuestra textura de arbol (para que no se deforme), le aplicamos la textura del arbol con transparencia en las zonas que no son arbol, y lo definimos como hijo del node Billboard. El otro dato que debemos definir es el eje de rotacin respecto al cual ha de pivotar nuestro polgono. Como el eje que hemos definido es el Y, entonces slo nos seguir si nos movemos en un plano perpedicular a este eje. Si nos movemos hacia arriba o abajo, podemos perder el efecto deseado.
Colisiones

La deteccia de colisiones puede ser muy importante en algunos casos y el VRML97 permite una deteccin parcial. Parcial en el sentido que tan solo da mecanismos para detectar colisiones entre el observador (punto de vista virtual) y los objetos, pero no entre objetos. El mecanismo para activar y desactivar la deteccin de colisiones funciona a partir de un nodo de agrupacin: el node Collision. Este se utiliza de manera que agrupa una lista de objetos los cuales no se desea que el observador pueda atravesar. Veamos un ejemplo: Ejemplo2: Definicin de un grupo de colisin.
Collision { collide FALSE children [ Transform { translation -3 0 0 children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 1 0 0 } } } } ] } Collision { collide TRUE children [ Shape { geometry Sphere { radius 1 } appearance Appearance { material Material { diffuseColor 0 1 0 } } }

Transform { translation 3 0 0 children Shape { geometry Cone { height 1 bottomRadius 1 } appearance Appearance { material Material { diffuseColor 0 0.5 1 } } } } ] }

En este ejemplo, el observador puede atravesar el cubo pero en cambio no puede atravesar ni la esfera ni el cono. Como se puede apreciar, ponemos el cubo dentro del grupo de colisin con la propiedad de colisin FALSE. Esto lo hacemos porqu la especificacin del VRML97 dice que los browsers, por defecto, habrn de detectar colisiones con todos aquellos objetos en que no se haya definido el comportamiento explcitamente.

Ejercicios propuestos: Bosque Disear un Bosque con arboles hechos de billboard. Comentarios

Utilizar el prototipage de objetos.

Solucin propuesta: bosc.wrl.

Eventos II y las Rutas.

Tutorial de VRML97
Aunque ya se ha visto una introduccin a los eventos en el mdulo Nodos, Campos y Eventos, en este mdulo aclararemos los conceptos que hay detrs.
Eventos (Events)

Un evento es como un mensage que puedeser enviado por un objeto y capturado por otro. Pueden haber eventos indicando que un nodo ha cambiado de posicin, o que ha pasado de un estado inactivo a uno activo, o que ha pasado un fraccin de tiempo, etc.

En teora, los browsers tienen un reloj interno que va marcando en tiempo real el paso del tiempo. Los eventos se van produciendo y recibiendo a cada intervalo de tiempo del reloj (en teora de forma contnua), pero en la prctica, normalmente podemos asumir que los browsers marcan el paso del tiempo a cada frame (cuadro o imagen) generado grficamente. As pues, cada evento tiene una especie de sello de tiempo, del instante en que se ha generado (emitido, enviado). Evidentemente, un evento es emitido por un eventOut y debe ser recibido por un eventIn. Pero tambin puede ocurrir que un evento sea emitido o recibido por un exposedField que como recordareis sn fields de entrada y salida. Como es de suponer, tanto el evento que enva como el que recibe, han de ser del mismo tipo. por lo tanto, un evento enviado por un eventOut de tipo SFInt32 (entero 32 bits univaluado) slo puede ser recibido por un eventIn (o exposedField) de tipo SFInt32. La figura siguiente muestra el diagrama de flujo del sistema que hemos descrito.

Puede ocurrir que un objeto (nodo) reciba un evento el cual le fuerce a enviar uno l mismo. En este caso, se genera lo que se conoce por cascada de eventos. En una cascada de eventos, todos los eventos implicados tienen el mismo sello de tiempo.

Pero que pasa si se genera un "loop" (lazo o bucle)? Podria pasar que nunca se acabase de enviar eventos y en consecuencia no avanzase el tiempo. Este problema no puede ocurrir en VRML97 ya que no se permite que un nodo reciba en un eventIn un evento proviniente de un mismo sitio con el mismo sello temporal. Si se detecta un loop, entonces el VRML97 se encarga de convertir el sello temporal del instante ti al ti+1 y retardar su emisin.

Se permite que un eventOut pueda ser encaminado hacia mltiples eventIns, y esto se conoce como Fan Out ("abanico de apertura"). En cambio no es legal encaminar mltiples eventOuts a un solo eventIn, donde esto es conocido como Fan In ("abanico de entrada"). Si se produce un Fan In, se pueden obtener resultados no esperados e indefinidos.
Routing de valores (comando ROUTE)

Pero como podemos decir que un cierto eventOut debe estar enlazado a un cierto eventIn? Para esto, el VRML97 prove un mecanismo llamado rutas, el cual se consigue a travs del comando ROUTE. (Debe resaltarse que no es un nodo, si no tan solo un comando que aporta un mecanismo). Por ejemplo supongamos que, de alguna forma, el color de un material cambia y queremos que el evento (que es de tipo SFColor) lo reciba una luz direccional, modificando as el color de la luz. Entonces los nodos y la ruta en cuestin seran: Ejemplo1: ROUTE para modificar el color de una luz direccional en funcin del cambio del color de un material.
Shape { geometry Sphere { radius 2 } appearance Appearance { material DEF MaterialEsfera Material { diffuseColor 1 0 0 } } } DEF Luz DirectionalLight { color 1 1 1 direction 0.5 0.5 0 intensity 1 } ROUTE MaterialEsfera.diffuseColor TO Luz.color

Como vemos, hemos de asignar un nombre a los nodos que queremos enlazar para poderlos referenciar. Una vez DEFinidos los nombres, podemos establecer el enlace con el ROUTE.

El ROUTE nos dice que los eventos emitidos por el exposedField diffuseColor del Material MaterialEsfera han de ser encaminados a (TO) el exposedField color del DirectionalLight Luz. Como se puede observar, la forma de decir que eventIn, eventOut o exposedField es el que nos interesa tratar de un cierto nodo, es mediante un punto (.) que une el nombre del nodo al del campo (field)seleccionado. NOTA: Este ejemplo, tal y como est, no tendra ningn efecto, ya que no hay nada que pueda hacer que el material enve un evento a la luz. En el siguiente mdulo veremos ejemplos plenamente funcionales.

Interpoladores y el Sensor de Tiempo

Tutorial de VRML97
Sensor de Tiempo

En VRML97 disponemos de una herramienta muy potente, el Sensor de Tiempo ( TimeSensor). Este es un reloj que podemos utilizar a nuestro antojo para poder aprovechar el paso del tiempo como motor para mover objetos, cambiar color de objetos, variar orientaciones, etc. Imaginemos que queremos que un objeto gire alrededor de uno de sus ejes conforme va pasando el tiempo. Tenemos un reloj que a cada "tic-tac" podemos definir que nos ayude a variar alguna cosa de nuestro entorno con una cierta frecuencia. Si de algn modo pudiramos redirigir el paso del tiempo, que ha ocurrido en el reloj, para poder variar la rotacin de un objeto, ya lo tendramos solucionado. Un TimeSensor se basa en el reloj real de sistema, midiendo el tiempo actual en segundos transcurridos a partir de las 00:00 horas del 1 de Enero del 1970. Veamis algunos ejemplos de TimeSensor con efectos distintos: Ejemplo1: Se inicia y realiza un ciclo de 5 segundos.
DEF Infinit TimeSensor{ startTime 0 cycleInterval 5 }

Este TimeSensor se inicia al cargarse el entorno en el visualizador y se para al cabo de 5 segundos. Un TimeSensor da constantemente, como evento de salida (eventOut), la fraccin de ciclo que ha transcurrido. Esto lo hace mediante el eventOut SFFloat fraction_changed que es un valor entre 0.0 y 1.0. La duracin del ciclo se define en

segundos en el exposedField SFTime cycleInterval que en este caso hemos definido a 5 segundos. Es decir, el TimeSensor tardar 5 segundos en pasar el valor de fraction_changed de 0.0 a 1.0. Al haber transcurrido los 5 segundos, y por lo tanto haber llegado a 1.0 el valor de fraction_changed, el TimeSensor dejar de modificar el fraction_changed y se parar. Ejemplo2: Se inicia y va realizando ciclos de 5 segundos sin pararse.
DEF Infinit TimeSensor{ startTime 0 cycleInterval 5 loop TRUE }

Ahora, al haber transcurrido los primeros 5 segundos y haber llegado a 1.0 el valor de fraction_changed, como hemos definido que realice bucles con el loop TRUE, el sensor volver a empezar un nuevo ciclo. Esto lo ir realizando sin pararse hasta que carguemos un entorno nuevo en el visualizador o bien apaguemos el visualizador. Para poder aprovechar el paso del tiempo que nos va dando el TimeSensor, debemos utilizar los interpoladores que pasamos a ver a continuacin.
Interpoladors

La interpolacin lineal (que es la que utiliza VRML97) s un concepto matemtico que permite definir dos puntos (en cualquier dimensin) y calcular un punto intermedio sobre la recta que los une a partir de especificar el tanto porciento del recorrido entre los dos puntos. Para saber que es un interpolador... En VRML97 hay seis tipos de interpoladores:

ColorInterpolator: Interpola colores. CoordinateInterpolator: Interpola coordenadas de vrtices. NormalInterpolator: Interpola normales a superfcies. OrientationInterpolator: Interpola ngulos de rotacin. PositionInterpolator: Interpola posiciones de objetos. ScalarInterpolator: Interpola valores cualesquiera (escalares, es decir, univaluados).

Para ver como funcionan empezaremos por el interpolador de colores. Lo que vamos a hacer es que un objeto vaya cambiando de color de forma gradual, empezando por el rojo y terminando en el verde. Tengamos en cuenta que segun la forma de definir colores RGB (valores entre 0 y 1) el rojo es el (1 0 0) y el verde es el (0 1 0). As pues, definimos nuestro interpolador de colores como:

DEF Rojo_a_Verde ColorInterpolator { key [ 0, 1 ] keyValue [ 1 0 0, 0 1 0 ] }

Con esta definicin, estamos diciendo que queremos que cunado el interpolador empiece (0% del trayecto, key=0) nos d el color rojo, keyValue=(1 0 0), y cuando termine (100% del trayecto, key=1) nos d el color verde, keyValue=(0 1 0). El interpolador deber ir cambiando el valor de key gradualmente y en funcin de este valor, ir calculando el valor del color de keyValue. Por ejemplo, cuando sea key=0.5, obtendr el valor de keyValue=(0.5 0.5 0) que es un tono amarillo medio. Pero no slo se puede dar un tramo de interpolacin. Podramos decir que empiece en rojo, a continuacin pase por verde, despus llegue a azul y finalmente vuelva a rojo. Ahora tenemos tres tramos de cambio de color y por lo tanto definimos nuestro interpolador de colores de la siguiente forma:
DEF Arcoiris ColorInterpolator { key [ 0, 0.3, 0.6, 1] keyValue [ 1 0 0, 0 1 0, 0 0 1, 1 0 0] }

Con esta definicin estamos determinando que cuando el interpolador empiece (0% del trayecto, key=0) nos d el color rojo, keyValue=(1 0 0). Cuando llegue a key=0.3 (aproximadamente un tercio del trayecto) nos d color verde, keyValue=(0 1 0). Al llegar a key=0.6 (aprox. dos tercios) nos de color azul, keyValue=(0 0 1) y, finalmente, cuando termine (100% del trayecto, key=1) nos d color rojo de nuevo, keyValue=(1 0 0). As, si tenemos definido un material que aplicamos a un objeto, podemos hacer que el interpolador vaya modificando el valor del field de este material (ver Materiales) y por lo tanto nos vaya cambiando el color del objeto al que lo aplicamos. As pues, haremos un ROUTE desde un evento de salida del interpolador al evento de entrada diffuseColor del material. Pero qu es lo que hace que el interpolador vaya pasando del valor inicial al final de forma gradual? Pues el paso del tiempo de un TimeSensor como los que hemos introducido arriba. Aqu tambin tendremos que hacer un ROUTE entre el tiempo del TimeSensor y el cambio de tanto por ciento del interpolador (es decir, el key). Las "rutas" que hemos visto en el mdulo anterior nos enlazan los valores que irn modificando nuestro entorno con los sensores de tiempo y los interpoladores. Veamos como funcionara nuestro ejemplo completo de un objeto que va cambiando de color:

Exemple3: Cub cambiando de color.

DEF motorColor TimeSensor{ loop TRUE cycleInterval 5 } DEF Arcoiris ColorInterpolator { key [ 0, 0.3, 0.6, 1] keyValue [ 1 0 0, 0 1 0, 0 0 1, 1 0 0] } DEF CuboColorCambiante Shape { geometry Box { size 2 2 2 } appearance Appearance { material DEF materialColorCambiante Material {} } } ROUTE motorColor.fraction_changed TO Arcoiris.set_fraction ROUTE Arcoiris.value_changed TO materialColorCambiante.diffuseColor

Analicemos que hace este cdigo:

En primer lugar estamos definiendo un TimeSensor al que llamamos motorColor. Este TimeSensor se pondr en marcha al cargar el entorno e ir actuando en ciclos de 5 segundos sin pararse nunca. A continuacin definimos un ColorInterpolator de tres tramos (rojo-verde, verde-azul, azul-rojo) de la misma longitud, aproximadamente un tercio cada uno. En tercer lugar definimos nuestro objeto, el CuboColorCambiante, que como su nombre indica, es un cub que va cambiando de color. Este objeto se define como una geometra que es una caja (Box) que forma un cubo, y por una apariencia con un material. Al material se le ha asignado el nombre materialColorCambiante pero no tiene ningn parmetro definido: Material { }. Esto se debe a que el campo diffuseColor ser tratado como evento de entrada (eventIn). Finalmente, encontramos las rutas: o La primera define que el paso del tiempo del TimeSensor vaya haciendo avanzar el trayecto recorrido por el interpolador de color. Esto se consigue enlazando el evento de salida fraction_changed del TimeSensor motorColor con el evento de entrada set_fraction del ColorInterpolator Arcoiris. Con este enlace, cada "tic-tac" del TimeSensor hace incrementar en una pequea porcin el avance del ColorInterpolator. o La segunda enlaza el nuevo color generado por el ColorInterpolator despus de haber avanzado (debido a la accin del TimeSensor) con el color del objeto. Esto se consigue enlazando el evento de salida, eventOut value_changed, del ColorInterpolator con el evento de entrada, eventIn diffuseColor, del material materialColorCambiante del cubo que hemos definido.

Del mismo modo en que hemos enlazado un TimeSensor a un ColorInterpolator, lo podemos hacer para cualquier otro interpolador.

Ejercicios propuestos: NORIA Disear una noria de parque de atracciones con cuatro cestas. Comentarios

Utilizar tan solo primitivas para modelar las partes. Utilizar el OrientationInterpolator. Aprovechar el prototipage de objetos.

Solucin propuesta: sinia.wrl. Pasos seguidos en la construccin de este entorno: sinia_e.htm CARRUCEL Disear uns carrucel de parque de atracciones con seis cavallitos. Comentarios

Utilizar tan solo primitivas para modelar las partes. Utilizar el OrientationInterpolator y el PositionInterpolator Aprovechar el prototipage de objetos.

Solucin propuesta: cavallts.wrl.

Para acabar mirad estas dos propuestas, una es la unin de la noria y el carrucel, el otro es una versin sofisticada de la noria, la geometria de la cual se ha modelado en 3D Max: park.wrl y siniasof.wrl.

Sensores de Visibilidad y Movimiento

Tutorial de VRML97
Sensor de Visibilidad

Este sensor, en principio, solo sirve para cuestiones de optimizacin. Por ejemplo, si tenemos muchos elementos en movimiento en nuestro entorno, el rendimiento de navegacin puede ser bastante bajo. Pero si hacemos que los objetos solo se muevan cuando entren en nuestro campo de visin, mejoraremos el rendimiento por que solo se mover aquello que realmente es necesario.

Esto se puede hacer, definiendo una zona en forma de caja alrededor de los objetos. El sensor de visibilidad node VisibilitySensor nos permite definir esta caja invisible, centrada en un cierto punto. Cuando esta caja entra en nuestro rango de visin , entonces el sensor de visibilidad se activa y emite un evento. Ejemplo1: Sensor de visibilidad.
Transform { translation -5 8 3 children Shape { geometry Sphere { radius 2 } appearance Appearance { ... } } } VisibilitySensor { center -5 8 3 size 4 4 4 }

Aunque este ejemplo no es funcional, nos muestra como definir la caja de visibilidad alrededor de un objeto. Como la esfera est centrada en el punto (-5 8 3) y tiene un radio de 2 unidades, entonces hemos de centrar la caja de visibilidad en el mismo punto y dar-le unas medidas de 4x4x4 parr que englobe toda la esfera.
Sensores de Movimiento

Estos sensores permiten incidir sobre las traslaciones y rotaciones de objetos directamente e individualmente, sin tener que modificar toda la escena con las interficies del browser. Hay tres tipos de sensores de movimiento (o "drag sensors " en Ingls):

node PlaneSensor: Permite modificar la posicin del objeto, como si se moviese en un plano. node CylinderSensor: Permite modificar la orientacin del objeto, como si rotase alrededor de un eje. node SphereSensor: Permite modificar la orientacin del objeto, como si rotase respecto a su centro.

node PlaneSensor

Este sensor permite mapear los movimientos 2D del cursor de pantalla, en movimientos 2D sobre el plano XY del sistema de coordenadas del sensor. El sensor se activa cuando se oprime sobre el objeto activo y, sin soltar el botn del ratn, se mueve el cursor. Entonces, los movimientos del cursor se pueden aplicar sobre el objeto mediante un ROUTE. Veamos un ejemplo donde un cubo verde es el objeto activo y tenemos un cubo naranja de referencia, inactivo.

Ejemplo1: Sensor de Movimiento en un Plano.

Transform { # Cubo de referencia translation -3 0 0 children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0.7 0.3 0 } } } } Group { children [ DEF Cubo Transform { children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0 0.7 0.3 } } } } DEF PS PlaneSensor { } ] } ROUTE PS.translation_changed TO Cubo.translation

Observad como este sensor se define de forma parecida al sensor de tacto visto en el mdulo anterior, es decir, debe definirse como "hermano" de los objetos que han de ser activos. A continuacin veremos un ejemplo donde el cubo naranja es el activo, pero el que se mueve es el verde. Ejemplo2: Sensor de Movimiento en un Plano, donde el objeto activo es diferente al que se mueve.
Group { children [ Transform { # Cubo activo translation -3 0 0 children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0.7 0.3 0 } } } } DEF PS PlaneSensor { }

] } DEF Cubo Transform { # Cubo que se mueve children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0 0.7 0.3 } } } } ROUTE PS.translation_changed TO Cubo.translation

Como se puede observar, el mapeo hecho con el ROUTE no ha variado, pero hemos puesto el sensor de movimiento en el plano, agrupado con el otro cubo (el naranja).
node CylinderSensor

Este sensor permite mapear los movimientos 2D del cursor de pantalla, en rotaciones alrededor del eje Y del sistema de coordenadas del sensor. El sensor se activa cuando se oprime sobre el objeto activo y sin soltar el botn del ratn, se mueve el cursor. Entonces, los movimientos del cursor se pueden reflejar sobre el objeto mediante un ROUTE. Veamos el ejemplo del cubo verde modificado. Ejemplo3: Sensor de Movimiento Cilndrico.
Transform { # Cubo de referencia translation -3 0 0 children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0.7 0.3 0 } } } } Group { children [ DEF Cubo Transform { children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0 0.7 0.3 } } } } DEF CS CylinderSensor { } ] }

ROUTE CS.rotation_changed TO Cubo.rotation

Observad como este sensor se define de forma parecida al sensor de tacto visto en el mdulo anterior, es decir, debemos definirlo como "hermano" de los objetos que han de ser activos.
node SphereSensor

Este sensor permite mapear los movimientos 2D del cursor de pantalla, en rotaciones alrededor del origen de coordenadas. El sensor se activa cuando se oprime sobre el objeto activo y sin soltar el botn del ratn, se mueve el cursor. Entonces, los movimientos del cursor se pueden reflejar sobre el objeto mediante un ROUTE. Veam el ejemplo del cubo verde modificado. Ejemplo4: Sensor de Movimiento Esfrico.
Transform { # Cubo de referencia translation -3 0 0 children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0.7 0.3 0 } } } } Group { children [ DEF Cubo Transform { children Shape { geometry Box { size 2 2 2 } appearance Appearance { material Material { diffuseColor 0 0.7 0.3 } } } } DEF SS SphereSensor { } ] } ROUTE SS.rotation_changed TO Cubo.rotation

Observad como este sensor se define de forma parecida al sensor de tacto visto en el mdulo anterior, es decir, debemos definirlo como "hermano" de los objetos que han de ser activos.

Ejercicios propuestos: Control de un Objeto Definir tres objetos que sirvan de conos y de sensores de movimiento en el plano, rotacin cilndrica y rotacin esfrica para muver otro objeto que escojais. Comentarios

Utilizad solo primitivas para modelar los objetos.

Solucin propuesta : sensores .wrl.

Nivel de Detalle (LOD)

Tutorial de VRML97
El nivel de detalle (o LOD: Level Of Detail) es una tcnica imprescindible en grficos 3D generados en tiempo real, para poder mantener la velocidad de refresco de pantalla sin gastar tiempo intilmente. De lo que se trata es de tener modelos simplificados (en diferentes grados) de un mismo objeto. Entonces se escoge cual de los modelos se muestra en cada momento segn la distncia a la que est del observador. Esto se hace por que no tiene sentido dibujar un objeto muy complejo con centenares de polgonos si este objeto ocupa 3x3 pixels en pantalla. Si no tuviramos modelos simplificados estaramos malgastando tiempo en dibujar a pleno detalle una cosa que finalmente no se apreciara. La manera en que se trabaja al aplicar el LOD, es a base de definir espacios o rangos delante del observador y asignar uno de los modelos del nivel de detalle adecuado para ser visto en aquella distncia. El node que el VRML implementa para conseguir este efecto es precisamente el node LOD. El siguiente ejemplo nos muestra el efecto de irnos acercando a una silla. Conforme nos vamos acercando el modelo va ganando en definicin. Ejemplo1: Definicin de una silla en niveles de detalle.
LOD { range [ 10 15 20 ] level [ Group { # Niell 1 (mximo nivel): dos cajas y cuatro cilindros children [ Transform { # Respaldo

translation 0 3.5 -1.75 children Shape { geometry Box { size 3.5 3 0.5 } appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } } Shape { # Asiento geometry Box { size 3.5 0.5 3.5 } appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } Transform { # Pata posterior izquierda translation -1.75 0 -1.75 children Shape { geometry Cylinder { radius 0.25 height 10 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } Transform { # Pata posterior derecha translation 1.75 0 -1.75 children Shape { geometry Cylinder { radius 0.25 height 10 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } Transform { # Pata frontal izquierda translation -1.75 -2.5 1.75 children Shape { geometry Cylinder { radius 0.25 height 5 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } Transform { # Pata frontal derecha translation 1.75 -2.5 1.75 children Shape { geometry Cylinder { radius 0.25 height 5 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } ] } Group { # Nivel 2: seis cajas children [ Transform { # Respaldo translation 0 3.5 -1.75 children Shape {

geometry Box { size 3.5 3 0.5 } appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } } Shape { # Asiento geometry Box { size 3.5 0.5 3.5 } appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } Transform { # Pata posterior izquierda translation -1.75 0 -1.75 children Shape { geometry Box { size 0.5 10 0.5 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } Transform { # Pata posterior derecha translation 1.75 0 -1.75 children Shape { geometry Box { size 0.5 10 0.5 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } Transform { # Pata frontal izquierda translation -1.75 -2.5 1.75 children Shape { geometry Box { size 0.5 5 0.5 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } Transform { # Pata frontal derecha translation 1.75 -2.5 1.75 children Shape { geometry Box { size 0.5 5 0.5 } appearance Appearance { material Material { diffuseColor 0.8 0 0.2 } } } } ] } Group { # Nivel 3: dos cajas children [ Transform { # Respaldo translation 0 2.5 -1.75 children Shape { geometry Box { size 4 5 0.5 }

appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } } Transform { # Asiento translation 0 -2.5 0 children Shape { geometry Box { size 4 5 4 } appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } } ] } Shape { # Nivel 4 (ms bajo): una caja geometry Box { size 4 10 4 } appearance Appearance { material Material { diffuseColor 0.8 0.6 0 } } } ] }

Las partes del node LOD son las siguientes. En primer lugar encontramos el field range donde definimos las particiones de distancia donde se ver cada nivel de modelo. Querremos definir cuatro (4) modelos diferentes y para esto definimos tres (3) valores. El primer valor nos indica que se ha de ver el modelo ms detallado si el observador est a menos de 10 unidades del objeto. El segundo valor nos indica que se ha de ver el segundo nivel de detalle si el observador est a menos de 15 unidades ( y a ms de 10 unidades) del objeto. El tercer valor nos indica que se ha de ver el tercer nivel de detalle si el observador est a menos de 20 unidades ( y a ms de 15 unidades) del objeto. Finalmente, no es necesario poner un cuarto valor por que ya se deduce que se ha de ver el cuarto nivel de detalle si el observador est a ms de 20 unidades del objeto. El segundo elemento que encontramos es el field level que es donde indicamos las diferentes versiones del objeto en orden de mayor a menor detalle. Evidentemente, los rangos que hemos tomado en este ejemplo no producen un efecto suave de cambio, y son solamente como ejemplo didctico. Para que os hagais una idea de como son los cuatro elementos, aqu los podris ver todos uno al lado del otro: 4nivels.wrl.

Ejercicios propuestos: Casa Disear una casa en 5 niveles de detalle y definir el comportamiento con el node LOD. Comentarios

Utilizar tan solo primitivas para modelar las partes.

Mundo Misterioso Disear un objeto que tenga un cierto comportamiento como por ejemplo que crezca o se reduzca o rote, y haced que el cambio de comportamiento se active en funcin de la distancia del observador al objeto. Ser como si el objeto reflejase la inmovilidad o movilidad del observador. Comentarios

Utilizar tan solo primitivas para modelar las partes. No utilizar Interpoladores ni Sensores de Tiempo. Aprovechar el prototipage de objetos.

Solucin propuesta: misteri.wrl.

Sonido

Tutorial de VRML97
El sonido en VRML puede ser de dos tipos: espacializado o no espacializado. Por espacializado se entiende que se modela una fuente emisora de sonido y que el observador percibe la posicin de esta fuente en funcin de las posiciones relativas entre ambos Por no espacializado se entiende que la percepcin del sonido por parte del usuario es independiante de cualquier parmetro de posicin u orientacin..
Sonido No Espacializado o Sonido Ambiente

El sonido que no tiene la cualidad de espacializado, es un sonido que se escucha siempre igual, se est en la posicin que sea dentro del entorno. Se le llama tambin sonido ambiente por hacer referencia al hecho que siempre est presente y crea una especie de ambientacin global.

Para definir un sonido en VRML, se utiliza el node Sound. Para que sea un sonido ambiente, debemos definirle un rango de actuacin muy grande (tan grande como sea nuestro entorno). Veamos (o escuchemos) un ejemplo: Ejemplo1: Definicin de un sonido ambiente.
Shape { geometry Sphere { radius 2 } appearance Appearance { material Material { diffuseColor 1 1 0 } } } Sound { minFront 200 minBrack 200 maxFront 200 maxBack 200 spatialize FALSE source AudioClip { url "forest.wav" startTime 1 loop TRUE } }

Aqu aparecen diversos conceptos. En primer lugar, el hecho que el sonido est formado por una fuente (field source). Para poder especificar qu sonido queremos generar, debemos definir un node AudioClip como fuente sonora (tambin se puede definir mediante un node MovieTexture pero no lo veremos aqu). En este node AudioClip definimos el archivo de sonido que deseamos integrar a nuestro entorno (field url) y en este caso definimos que se vaya repitiendo indefinidamente (field loop). Una vez definido el archivo de sonido, debemos establecer las caractersticas de este sonido. Hemos dicho que el sonido ambiente no es espacializado y por esta razn definimos como FALSE esta propiedad (field spatialize). Los otros cuatro fields describen el rango de accin del sonido y, por ahora, diremos que definen una esfera de sonido dentro de la cual se oir el sonido y fuera de ella no. Esta esfera la hemos definido de radio 200 unidades.
Sonido Espacializado

La espacializacin del sonido se basa en el hecho de que los seres humanos tenemos dos orejas (y dos oidos), y por esta razn se manifiesta un decalage en tiempo (y en fase) entre el sonido que llega a cada una desde la fuente sonora. De esta forma, podemos detectar de dnde proviene un sonido. Este es el efecto percibido pero, cmo se definen estos sonidos espacializados en VRML? Para empezar, una fuente sonora tiene una posicin en el espacio desde la cual salen las ondas sonoras y se transmiten por vibracin de las partculas en el aire. Un sonido usualmente no se emite en todas direcciones por igual, y por esta razn presenta una direccin privilegiada. Este "centro" y esta direccin, generan unos volmenes en el

espacio, en que el sonido se percibe de forma distinta segn la posicin del oyente. Estos volmenes no son esfricos por efecto de la direccin privilegiada. Son un tipo de volmenes llamados elipsoides ("esferas alargadas"). Finalmente un sonido pierde intensidad conforme se aleja de la fuente: es el fenmeno conocido como atenuacin. POr esta razn, el oyente nota como va bajando el volmen (la intensidad) del sonido conforme se aleja de del sitio donde se ha producido (la fuente sonora). Pero como hay una direccin privilegiada de emisin, la atenuacin es ms lenta en la direccin principal y ms rpida en la direccin opuesta. La siguiente ilustracin muestra una vista lateral de una persona gritando. El elipse muestra un corte lateral del elipsoide de sonido generado por la fuente sonora (la boca de la persona). La flecha muestra la direccin principal o privilegiada de emisin (la direccin en que la persona est mirando). El tono de gris muestra cmo se atena el sonido (negro = intensidad mxima; blanco = intensidad mnima).

Los valores maxBack y maxFront son las distancias mxima hacia atrs y hacia delante (respectivamente) a las que se llega a oir el sonido. Ms all de estas distancias ya no se oye nada. El modelo del VRML se basa absolutamente en estos principios. El siguiente ejemplo muestra, en 3D, los volmenes generados y las componentes del node Sound que listamos. Este excelente ejxemplo ha sido diseado por la empresa dFORM dentro de su tutorial especfico de udio en VRML. NOTA: Se debe tener un poco de paciencia para bajar todo el ejemplo completo. Una vez est totalmente cargado os podis mover libremente o (de forma recomendada) podis utilizar los puntos de vista predefinidos. NOTA2: Puede ocurrir que aparezca un error avisando que no se reconoce el tipo de compresin de sonido. Ignoradlo y pulsar OK. Sound volumes: Definicin del node Sound con valores por defecto. En el ejemplo, podis ver y escuchar los distintos conceptos al iros moviendo por los puntos de vista

predefinidos.
Sound { location 0 0 0 el origen direction 0 0 1 intensity 1 mximo) minFront 1 sonido regular (o ambiente) minBack 1 sonido regular (o ambiente) maxFront 10 oye el sonido maxBack 10 el sonido spatialize TRUE source AudioClip { ... ... ... } } # Posicin por defecto de la fuente sonora: # Direccin por defecto: eje Z # Intensidad mxima por defecto: 1 (el # Mxima distancia hacia delante en que hay # Mxima distancia hacia atrs en que hay # Mxima distancia hacia delante en que se # Mxima distancia hacia atrsen que se oye # Por defecto espacializar el sonido

Como podis observar, existen dos pares de lmites sonoros. Estos dos lmites forman dos elipsoides concntricos. El menor (el interior), definido por field minFront y field minBack, determina la zona en la que el sonido es totalmente envolvente y presente (por lo tanto, como si fuera sonido ambiente). El mayor (el exterior), definido por field maxFront yi field maxBack, determina la frontera a partir de la cual ya no se oye el sonido porque se supone que se est demasiado lejos de la fuente sonora. El espacio entre los dos elipsoides es la zona en la que se puede apreciar la atenuacin. Tanto ms cercano est el oyente del elipsoide menor, ms fuerte se oir el sonido. Tanto ms lo est al elipsoide exterior, ms bajo se oir el sonido, hasta que en el lmite se deja de oir.

Ejercicios propuestos: El Mosquito Disear un entorno en el que haya un objeto (el mosquito) que vaya girando alrededor de un objeto central (la cabeza de la vctima) y hacer que el mosquito vaya zumbando en su vuelo. Comentarios

Utilizad tan solo primitivas para modelar los objetos. Utilizad el sonido que os damos en la direccin: http://www.iua.upf.es/~npares/docencia/vrml/so/exemples/mosquit.wav Utilizad un interpolador de orientacin. Haced el tamao del elipsoide interno del tamao del mosquito. Haced el tamao del elipsoide externo lo suficientemente grande como para que se oiga desde la "cabeza". Notad que un mosquito es una de las pocas fuentes sonoras que si emiten de forma (bastante) regular en todas direcciones por igual.

Solucin propuesta: mosquit.wrl.

Scripting

Tutorial de VRML97
Aunque el VRML da muchos mecanismos para definir interaccin y comportamientos, hay cosas que no se pueden hacer dirctamente y entonces se debe utilizar la potncia de un lenguaje de programacin externo. Esto se consigue a travs del node Script y los lenguajes que se pueden utilizar son el Java y el JavaScript (o compatible JavaScript). En este tutorial, tan solo entraremos a ver la utilizacin del JavaScript dentro del node Script debido a que es mucho ms sencillo, directo y comn de utilizar. Nota: Partiremos del supsito que el lector ya cuenta con un conocimiento previo del JavaScript como lenguaje y que lo sabe utilizar a nivel bsico para realizar pequeas utilidades en pantallas de HTML.
El node Script

El concepto bsico detrs del node Script es que es un node que permite los siguientes pasos:

captar los eventos que necesitemos conseguir los valores que forman los eventos y procesarlos enviar los resultados de este proceso como eventos de salida (para ser encaminados, mediante ROUTEs, hacia otros nodes)

Un node Script est formado por dos partes principales: las definiciones de campos y eventos, y el cdigo en el lenguaje que hemos escogido. Es importante el hecho que en este node podemos definir campos y eventos segn nuestras necesidades, en contraste con los otros nodes de VRML que ya tienen predefinidos todos sus componentes. El sitio donde se pone el cdigo del lenguaje es en el field url. Este field permite escribir todo el cdigo entre comillas dobles (") o bin referenciar un archivo externo donde figure todo el cdigo. A continuacin vemos un esquema de la estructura del node: Esquema: Estructura del node Script.
Script { field ... . . . . . . field ... eventIn ... . . . . . . eventIn ... eventOut ... . . . . . . eventOut ... url "javascript: function X (v,t){ . . . . . . } . . . . . . function Z (v,t){ . . . . . . } " }

Aqu se pueden observar las dos partes que definamos arriba. Primero se encuentran las definiciones de campos y eventos. Estos no requieren estar ordenados de ningna forma concreta. En segundo lugar, encontramos el field url donde, entre comillas, se define el tipo

de cdigo que se utiliza (en nuestro caso javascript:) y a continuacin todas las funciones que configuran nuestros procesos.
Los eventIns y las functions de JavaScript

Existe una relacin directa entre los nombres de los eventIn y los nombres de las funciones del cdigo. Esta relacin se establece para que cuando llegue un evento de entrada al node Script en custin, l llame a la funcin que tiene el mismo nombre que el eventIn referenciadi y as se pueda capturar el valor que se ha recibido y se pueda procesar. El mecanismo implementado por el node Script hace que toda funcin de JavaScript asociada a un eventIn tenga dos parmetros por defecto: el valor recibido por el eventIn y el instante de tiempo en que se ha generado aquel evento. De esta forma, la funcin puede utilizar el valor del evento que ha recibido e incluso discernirlo de otros eventos gracias al hecho de que tambin se dispone de su sello de tiempo. A continuacin damos un ejemplo donde un ProximitySensor enva un evento de cambio de posicin del punto de vista a un Script que mira si la coordenada X de este punto de vista es mayor que 5 (y no hace nada ms de momento). Ejemplo1: Definimos un ProximitySensor llamado SensorPuntoVista que va detectando el movimiento del punto de vista del usuario por dentro suyo. Este ProximitySensor va generando eventOuts de nombre position_changed, los cuales son encaminados mediante un ROUTE al eventIn de nombre nuevaPosicion del Script llamado SiguePuntoVista.
DEF SensorPuntoVista ProximitySensor { size 100 100 100 } DEF SiguePuntoVista Script { eventIn SFVec3f nuevaPosicion url "javascript: function nuevaPosicion (v,t) { if (v[0] > 5); } " } ROUTE SensorPuntoVista.position_changed TO SiguePuntoVista.nuevaPosicion

Analicemos este cdigo parte por parte:

En primer lugar, tenemos la definicin del ProximitySensor al cual le damos un nombre para referenciarlo en el ROUTE. Despus encontramos el Script al cual tambin damos un nombre. Este node, no tiene ningn campo o evento definido a priori a parte del campo url (despus veremos que si

hay 2 pero de momento quedmonos con esta idea). Por lo tanto, es necesario que nosotros definamos los campos y eventos que nos convienen. De momento, como la nica cosa que queremos hacer es captar el evento de cambio de posicin del punto de vista dentro del ProximitySensor, definimos un eventIn del tipo vector 3D univaluado en coma flotante (SFVec3f, Single-valued Field of Vector 3 components in floating point). A este evento de entrada le asignamos el nombre nuevaPosicion, lo cual implica que tendremos que definir una funcin de JavaScript con el mismo nombre para as poder captar el valor que entre por este evento. En el campo url encontramos el cdigo JavaScript. De momento slo nos hace falta definir una sola funcin, la que debe estar asociada al evento de entrada. As pus, definimos una funcin con nombre nuevaPosicion y a la que por defecto el VRML le define dos parmetros: v que es el valor que llega al eventIn y t que es el instante de tiempo en el que se ha generado el evento. De esta forma, desde dentro de la funcin podemos acceder al valor del evento de entrada y lo podremos comparar en su coordenada X(1) con nuestro lmite de 5 unidades. Finalmente encontramos el ROUTE con el cual enlazamos el eventOut position_changed que tiene predefinido el ProximitySensor con el eventIn nuevaPosicion que hemos definido en nuestro node Script.

(1)

Al contrario de en VRML donde no se accede nunca a las componentes de los datos que pertenecen a tipos no escalares como SFVec3f, SFRotation, SFColor, SFVec2f y todos los MFs, cuando hemos de programar puede interesarnos acceder a estas componentes. En un caso como este, un valor de estos tipos se comporta como si fuera un array de JavaScript y por lo tanto se accede a las componentes indexando desde 0 (cero) hasta el nmero de componentes menos uno. Por ejemplo: a un field SFColor con nombre miColor, se le podran asignar los valores RGB (1, 0.5, 0.3) desde un Script indexando de la siguiente forma: miColor[0]=1; miColor[1]=0.5; miColor[2]=0.3;
Los eventOut

Los eventOut se definen en la primera parte del node Script de forma similar a los eventIn. Para poder generar el evento de salida a travs del eventOut que hemos definido, tan solo tenemos que asignarle un valor desde dentro de la funcin que ha de generar el evento. Ampliemos nuestro ejemplo anterior. Ahora queremos que suene una alarma cuando detectemos que el punto de vista ha sobrepasado el lmite de 5 unidades en el eje X. Los elementos necesarios son los siguientes: Ejemplo2: Definicin de unos eventos de salida para activar un sonido de alarma (aadimos al ejemplo anterior).
DEF SensorPuntoVista ProximitySensor { size 100 100 100 } DEF SiguePuntoVista Script {

eventIn SFVec3f nuevaPosicion eventOut SFTime activaAlarma eventOut SFTime apagaAlarma url "javascript: function nuevaPosicion (v,t) { if (v[0] > 5) activaAlarma = t; else apagaAlarma = t; } " } DEF ClipAlarma AudioClip { url "alarma.wav" startTime -1 loop TRUE } Sound { source USE ClipAlarma maxFront 200 maxBack 200 } ROUTE SensorPuntoVista.position_changed TO SiguePuntoVista.nuevaPosicion ROUTE SiguePuntoVista.activaAlarma TO ClipAlarma.startTime ROUTE SiguePuntoVista.apagaAlarma TO ClipAlarma.stopTime

Los elementos nuevos son los siguientes:

Hemos aadido dos eventOuts a nuestro Script: activaAlarma y apagaAlarma, de esta forma podremos activar y apagar el sonido de alarma segn la posicin del usuario. Estos eventos de salida son del tipo SFTime porque lo que deseamos es dar un tiempo de inicio y un tiempo de finalizacin del sonido. En el cdigo de JavaScript, hemos aadido una accin a realizar en el if y hemos aadido una opcin else. Lo que hacemos es aprovechar el hecho de que toda la funcin asociada a un eventIn tiene los dos parmetros por defecto: el valor del evento y el tiempo en que se ha generado. As pus, en t tenemos el instante de tiempo en que se ha generado el cambio de posicin del usuario y por lo tanto es el instante indicado para activar o apagar el sonido. Una vez el if ha discernido si el usuario ha traspasado el lmite, asignamos el tiempo al evento de salida correspondiente. Nota: Es importante entender que el evento de salida se genera por el solo hecho de asignar un valor al eventOut. El momento en el que se envan estos eventos de salida es cuando el VRML ha terminado de ejecutar todo el Script. A continuacin hemos aadido dos nodes para definir el sonido. No entraremos a explicarlo ya que se explican en el mdulo de sonido de este tutorial. Finalmente hemos aadido dos ROUTEs para encaminar los eventos de salida de nuestro Script hacia los eventos de entrada correspondientes de nuestro AudioClip.

Los fields

Los field tambin se definen en la primera parte del node Script de forma similar a los eventIn y a los eventOut. Los field sirven como variables globales para el Script y para guardar valores a lo largo de toda la ejecucin del entorno. Con esto podemos comparar valores de eventos nuevos con valores antiguos que hayamos guardado previamente en fields. De nuevo ampliemos nuestro ejemplo. Lo que haremos ahora es que suene la alarma solo la primer vez que el usuario pase el lmite. Si el usuario vuelve atrs y despus de nuevo sobrepasa el lmite, la alarma ya no deber sonar. Los elementos necesarios son los siguientes: Ejemplo3: Definicin de un field booleano para saber si el usuario ya haba traspasado el lmite prviamente.
DEF SensorPuntoVista ProximitySensor { size 100 100 100 } DEF SiguePuntoVista Script { eventIn SFVec3f nuevaPosicion field SFBool haEntrado FALSE eventOut SFTime activaAlarma eventOut SFTime apagaAlarma url "javascript: function nuevaPosicion (v,t) { if (v[0] > 5) if(!haEntrado){ activaAlarma = t; haEntrado = TRUE; } else apagaAlarma = t; } " } DEF ClipAlarma AudioClip { url "alarma.wav" startTime -1 loop TRUE } Sound { source USE ClipAlarma maxFront 200 maxBack 200 } ROUTE SensorPuntoVista.position_changed TO SiguePuntoVista.nuevaPosicion ROUTE SiguePuntoVista.activaAlarma TO ClipAlarma.startTime

ROUTE SiguePuntoVista.apagaAlarma TO ClipAlarma.stopTime

Solo hemos aadido los elementos siguientes:

Primero, hemos aadido un field de tipo SFBool con el nombre haEntrado. A este field le hemos dado un valor inicial de FALSE porque al inicio, el usuario an no ha sobrepasado la zona prohibida. Nota: todo field ha de tener un valor inicial independientemente de la utilizacin que se haga. En segundo lugar, hemos aadido un if dentro de la rama cierta del primero, poniendo la condicin de que per activar la alarma se debe cumplir que el usuario an nunca haya passado el lmite. Esto se consigue mirando si nuestro field haEntrado es falso o cierto. Finalmente, hemos aadido a la rama cierta del if, la accin de asignar el valor TRUE al field haEntrado para tener conocimiento de que el usuario ya ha traspasado una vez el lmite. No es necesario aadir nada ms porque cada vez que se llame el Script el field que hemos definido tendr el ltimo valor que le hayamos asignado.

El field mustEvaluate

Inicialmente hemos dicho que, excepto por el field url, el node Script no tena ningn otro campo predefinido. Esto lo hemos dicho para simplificar las explicaciones anteriores, pero no es exctamente cierto. De hecho el node Script dispone de dos campos predefinidos: mustEvaluate y directOutput. Durante la ejecucin de un entorno de VRML, el browser tiene la autorizacin (por especificacin) de gestionar los eventos en el momento que le sea ms idneo. Esto puede provocar que se acumulen una srie de eventos durante un lapso de tiempo, para despus ser evaluados todos de golpe (evidentemente en el orden en que se han generado). Esto significa que cuando programemos un Script para gestionar unos eventos, podra pasar que no se nos evale el Script cada vez que se genera el evento de entrada que necesitamos. En este caso pasara que al cabo de un rato se evaluara nuestro Script tantas veces como eventos de entrada se hayan acumulado. Para poder evitar o controlar esto, el node Script dispone del campo prodefinido field SFBool mustEvaluate. Por defecto, este campo tiene valor FALSE, cosa que significa que la evaluacin del Script puede ser postpuesta. Si queremos que nuestro Script se evale cada vez que se reciba un evento de entrada de los que gestionamos, entonces debemos poner el campo mustEvaluate TRUE. Nota: Es necesario tener en cuenta que poner mustEvaluate TRUE implica imponer un control ms exhaustivo al browser y por lo tanto se pierde eficiencia. Slo debe hacerse cuando sea estrctamente necesario.

El Mecanismo de Acceso a otros Nodes y el field directOutput

A veces es prctico poder acceder dirctamente a los exposedFields, eventOuts y eventIns de nodes externos al Script, sin tener que definir todo un conjunto de ROUTEs. Esto da ms control sobre el entorno ya que no se depende de la gestin de eventos que hace el browser. As pus, podramos tener definido un node de transformacin con un cubo como geometra, del cual queremos saber el valor del campo de traslacin desde dentro del Script sin necesidad de que se genere un evento. Entonces lo que haramos sera: Ejemplo4: Definimos un acceso directo a un node externo a un Script.
DEF TransfCubo Transform { translation 0 0 0 children [ Shape { geometry Box { size 1 1 1 } } DEF TS TouchSensor {} ] } DEF MiScript Script { eventIn SFTime click field SFNode TCubo USE TransfCubo url "javascript: function click(v,t) { if(TCubo.translation[0] > 5) ... } " } ROUTE TS.touchTime TO MiScript.click

Miremos paso a paso lo que se ha hecho en este ejemplo:

Definimos un node de trasformacin al cual ponemos un nombre TransfCubo para poder accederlo. Este node contiene un cubo como geometra, y un TouchSensor para que el cubo sea "clicable". A continuacin definimos un Script con los siguientes elementos: o Un eventIn SFTime click que nos captura los eventos de activacin del TouchSensor. o Definimos despus un field de tipo node (SFNode) para poder referenciar dirctamente el node de trasformacin externo. A este field le llamamos TCubo y para dejar claro que no es un node nuevo sino que en realidad estamos haciendo referencia al de la trasformacin, aadimos USE TransfCubo. Esto significa que est utilizando el node TransfCubo externo. o Entonces definimos la funcin asociada al eventIn click. En esta funcin empezamos mirando el valor de la componente X del campo de traslacin del

node de transformacin TransfCubo. Esto lo conseguimos a travs de la referencia que hemos definido en la primera parte del Script, es decir, a travs de TCubo.

Con este ejemplo vemos que podemos acceder a informacin de nodes externos sin tener que establecer ROUTEs que nos encaminen eventos. Pero tal y como est definido, slo podemos acceder a los exposedFields o a los eventOuts para leer su valor. Si quisiramos acceder a los exposedFields o a los eventIns para modificarlos, no podramos a menos que utilizramos el campo que subministra el VRML en los Scripts, que es el field SFBool directOutput. Este campo, por defecto tiene el valor FALSE. As, para poder tener acceso a los campos de nodes externos y poderlos modificar, debemos cambiarlo a TRUE. Veamoslo en el siguiente ejemplo: Ejemplo5: Definimos un acceso directo a un node externo a un Script con posibilidad de modificacin.
DEF TransfCubo Transform { translation 0 0 0 children [ Shape { geometry Box { size 1 1 1 } } DEF TS TouchSensor {} ] } DEF MiScript Script { directOutput TRUE eventIn SFTime click field SFNode TCubo USE TransfCubo url "javascript: function click(v,t) { if(TCubo.translation[0] > 5) TCubo.translation[0] = 0; else TCubo.translation[0] = TCubo.translation[0] + 1; } " } ROUTE TS.touchTime TO MiScript.click

Lo que hace el ejemplo es que cada vez que se entra al Script, se mueve el cubo una posicin en el eje de las X hasta llegar a 5, momento en el que se devuelve el cubo al origen.

Ejercicos propuestos: Disear un puente levadizo que suba y baje al apretar un botn que se encuentre en un panel. El puente debe realizar todo el recorrido de subida y de bajada sin que se pueda interrumpir a medio camino y sin que se le pueda pedir subir ciando ya est arriba ni bajar cuando est abajo. Comentarios

Utilizar tan solo primitivas para modelar los objetos. Utilitzar campos de Script de tipo SFBool (booleanos o lgicos) para saber el estado del puente en cada momento. Utilitzar OrientationInterpolators para animar el puente.

Solucin propuesta: pont.wrl.

Informacin de Navegacin y Fondos

Tutorial de VRML97
Este mdulo resulta un poco un cajn de sastre para terminar de ver las herramientas ms tiles del VRML97.
Informacin de Navegacin

La informacin de navegacin son aquellas caractersticas del browser que se pueden modificar desde el VRML97. por ejemplo, qu tipo de interfaz de navegacin se desea, si se quiere activar la luz de usuario (headlight), la velocidad de desplazamiento del punto de vista, etc. Esta herramienta es muy til para poder establecer ciertos parmetros del browser sin que lo tenga que hacer el usuario a travs del men. De esta forma podemos personalizar el entorno a nuestra aplicacin. La forma de definir estos parmetros, es mediante el node NavigationInfo. De todas formas, no todas las opciones de los mens del browser estn accessibles desde este nodo. Veamos las ms importantes:
La luz de usuario o headlight

Esta luz ya la hemos descrito en el mdulo sobre Iluminacin y vimos que es como si fuera una luz de casco de minero. Esta luz puede interferir en la iluminacin que deseamos dar a nuestro entorno y por eso es importante poder-lo apagar ya de entrada. La forma de hacerlo es:

Ejemplo1: Apagar luz de usuario o headlight.

NavigationInfo { headlight FALSE }

Aadiendo esta lnea a un entorno, nos aseguramos que controlamos la iluminacin.

Interfaz de Navegacin

Cuando se navega con un browser de VRML, se puede escoger entre tres modos que listamos a continuacin:
Modo examinar objetos o EXAMINE: con el cual, el efecto es como si el punto de vista se mantiene fijo y son los objetos los que se mueven respecto al punto de vista. Este modo es muy til, jstamente, para examinar objetos por todos sus costados. Modo de caminar o WALK: con el cual, es clramente el punto de vista el que se mueve, pero limita el movimiento de forma que se mantiene en un plano o bien siguiendo un "terreno". Este modo es til para emular el movimiento humano o de un vehculo terrestre. Modo de vuelo o FLY: con el cual el punto de vista se mueve en todas direcciones sin ninguna restriccin. Modo ningn interfaz o NONE: con el cual no aparece ningn tablero de controles de navegacin. Esto puede ser muy til si queremos nosotros proveer las herramientas de navegacin al usuario.

Todo lo que hay que hacer es escoger la palabra del navegador que queremos utilizar y escribir el siguiente comando: Ejemplo2: Escoger el tipo de interfcie de navegacin.
NavigationInfo { type "WALK" }

Velocidad de movimiento dentro del entorno

Tambin puede ser interesante controlar la velocidad con que se desplaza el punto de vista por el espacio en el entorno que hemos diseado. La velocidad por defecto es 1 y se puede controlar a travs de:

Ejemplo3: Establecer la velocidad de movimiento del punto de vista.

NavigationInfo { speed 1.0 }

Donde la cantidad especificada significa metros por segundo (recordad que las unidades en VRML son entendidas como metros).
Fondos

El control de un color de fondo puede ser muy til en el diseo de un entorno. En VRML97, no solo podemos controlar el color, sino que adems podemos definir degradados de "cielo", de "tierra", o bien poner imgenes como si fueran escenografas.
La Esfera del Cielo y la Tierra

Para definir un color slido o un degradado de fondo, VRML97 define el concepto de esfera (o semiesfera) de cielo (y tierra). El cielo es como si hubiera una esfera de radio infinito que engloba todo el mundo. La tierra es una semiesfera de radio infinito situada boca arriba, que engloba toda la mitad inferior del mundo. Todo esto se define a travs del node Background. En estas esfera y semiesfera, podemos definir un nico color, o bien podemos definir que un cierto color corresponde a un cierto ngulo de elevacin. Curiosamente, en la esfera del cielo, el ngulo se calcula a partir del punto superior (el "polonorte") que corresponde al ngulo 0 (cero grados) y se va incrementando hasta el punto inferior ("polo sur") al que corresponde el ngulo 180. En cambio, la semiesfera de la tierra funcieno al revs. La siguiente figura mustra una seccin vertical de la esfera del cielo (la externa) y la semiesfera de la tierra (interna).

No es obligatorio definir los dos fondos, la esfera del cielo y la semiesfera de la tierra, sino que se puede escoger definir una u otra, o las dos o ninguna. A continuacin veremos un ejemplo en que definimos un solo color de cielo. Ejemplo4: Definimos un fondo azul uniforme.
Background { skyColor [ 0.8 0.8 1 ] } Shape { # Objeto de referencia geometry Sphere { radius 2 } appearance Appearance { material Material { diffuseColor 1 0.8 0 } } }

En este caso estamos definiendo un solo color de cielo, que aunque no se especifica se asigna al ngulo 0 (cero grados) y el cual el VRML se encarga de distribuir a todo el fondo. El siguiente ejemplo define un degradado de azul obscuro a naranja como si fuese una puesta de sol. Ejemplo5: Definimos una "puesta de sol".
Background { # 0 22 45 60 75 85 90 skyAngle [ 0.384, 0.785, 1.047, 1.309, 1.484, 1.5708 ] skyColor [ 0 0 0.2, 0 0 1, 0 1 1, 0.75 0.75 1, 0.8 0.8 0, 0.8 0.6 0, 1 0.4 0 ] # azulobscuro azul cian azulclaro amarillo anaranjado rojizo } Shape { # Objeto de referencia geometry Sphere { radius 2 } appearance Appearance { material Material { diffuseColor 1 0.8 0 } } }

Cabe observar que el primer ngulo, el cero (0), no se incluye en la lista de ngulos. Ya se da por entendido que el primer valor de color corresponde al "polo norte" o ngulo cero. Como se puede observar, el ltimo color definido (el rojizo), se extiende hasta el polo sur. Esto es debido a que el VRML llena toda la esfera de color y por lo tanto deduce que queremos llenar la parte de la esfera que queda indefinida con el ltimo valor dado. Debido a estas dos razones, el primer ejemplo de color de fondo uniforme, tan solo define un solo color y ningn ngulo.

Par definir una tierra, se procede de forma anloga, pero en este caso, se empieza por el "polo sur" (que representa cero grados, 0). Aadamos pues un color de tierra verdoso uniforme a nuestro ejemplo de la puesta de sol: Ejemplo6: Definimos una "puesta de sol" con tierra verde.
Background { # 0 22 45 60 75 85 90 skyAngle [ 0.384, 0.785, 1.047, 1.309, 1.484, 1.5708 ] skyColor [ 0 0 0.2, 0 0 1, 0 1 1, 0.75 0.75 1, 0.8 0.8 0, 0.8 0.6 0, 1 0.4 0 ] # azulobscuro azul cian azulclaro amarillo anaranjado rojizo # 0 90 groundAngle [ 1.5708 ] groundColor [ 0.2 1 0.4, 0.2 1 0.4 ] } Shape { # Objeto de referencia geometry Sphere { radius 2 } appearance Appearance { material Material { diffuseColor 1 0.8 0 } } }

Observad que para la tierra, el funcionamiento es diferente que para el cielo. En este caso, el VRML97 deduce que debe poner el "color transparente" entre el ltimo ngulo definido y el "polo norte". por lo tanto, si solo definimos un color y ningn ngulo, no nos muestra nada, por qu entre el ltimo ngulo que hemos definido (el cero) y el "polo norte" l no pone nada. Por esta razn tenemos que repetir el color verde de la tierra, para la posicin cero y para la posicin 90.
Imgenes de Escenografa

Para definir un fondo, el VRML97 tambin permite definir unas imgenes que se mapean sobre las paredes internas de un cubo de tamao tericamente infinito que rodean todo el entorno: As pues, hemos de definir 6 imgenes para cubrir las paredes: frontal, posterior, derecha, izquierda, superior e inferior del cubo. A continuacin podemos ver un ejemplo donde las imgenes no forman un fondo uniforme, pero que permiten distinguir bien las seis superficies. Ejemplo7: Definimos un fondo con seis imgenes.
Background { frontUrl "fons1.gif" backUrl "fons2.gif" topUrl "fons3.gif"

bottomUrl "fons4.gif" rightUrl "fons5.gif" leftUrl "fons6.gif" } Shape { # Objeto de referencia geometry Sphere { radius 2 } appearance Appearance { material Material { diffuseColor 1 0.8 0 } } }

http://wwwdi.ujaen.es/~rsegura/igai/web3d/web3d/docs/cap16.html

16. Textura
Hasta ahora, para definir un objeto visible se ha utilizado el nodo Shape de la siguiente forma:

Shape { appearance Appearance { material ... } geometry ... }

en donde el nodo Appearance tiene un solo campo, material, con el que se definen el color y la transparencia, segn se ha visto en el captulo anterior. Pero en realidad puede tener tambin otros dos campos: texture y textureTransform, con los que se define la textura de los objetos:

Shape { appearance Appearance { material ... texture ... textureTransform ... } geometry ... } Vamos a centrarnos en el segundo campo exclusivamente (texture):

Shape { appearance Appearance { texture ... } geometry ... }

Qu es la textura?
La textura es la posibilidad que tenemos de envolver un objeto con: una imagen existente, usando el campo ImageTexture una pelcula, usando el campo MovieTexture una imagen creada por nosotros pixel a pixel, usando el campo PixelTexture

Se van a ver los dos primeros (ImageTexture y MovieTexture) en este captulo, y el tercero (PixelTexture) en el captulo siguiente.

Textura con ImageTexture

Tomemos como ejemplo la imagen de la derecha: monalisa.jpg Vamos a envolver con ella los objetos primitivos (caja, cono, cilindro y esfera). Para ello, se hace uso del nodo ImageTexture, como valor del campo texture, de la siguiente manera:

Shape { appearance Appearance { texture ImageTexture { url ["monalisa.jpg"] } } geometry ... } Como se puede ver, el nodo ImageTexture tiene el valor url ["monalisa.jpg"] (se supone que la imagen est en el mismo directorio que el documento VRML. Si no fuera as, se pondra entre comillas la ruta del fichero de imagen) Aplicando esto a una caja de dimensiones 1.5x2.2x0.5:

#VRML V2.0 utf8 # Ejemplo de caja con textura de una imagen Shape { appearance Appearance { texture ImageTexture { url ["monalisa.jpg"] } } geometry Box { size 1.5 2.2 0.5 } }

A la derecha se puede ver el resultado (pulsar para cargar el escenario). Como se puede observar, la imagen se ha reproducido en todas las caras. De manera similar, he aqu los resultados de aplicar esta imagen como textura de un cono, un cilindro y una esfera.

Imgenes distintas en un mismo objeto

Puede interesar que un objeto tenga imgenes diferentes en alguna o algunas de sus caras, como en el caso de la imagen de la derecha (pulsarla para cargar el escenario). Como se puede ver, este objeto, que representa una lata de bebida (que en realidad es un cilindro), tiene una imagen para su superficie lateral, y otra distinta para los fondos superior e inferior.

Si nos limitamos a ponerlo de esta manera:

Shape { appearance Appearance { texture ImageTexture { url ["etiqueta.jpg"] } } geometry ... } se reproducira la imagen de la etiqueta tambin en los fondos superior e inferior (como se ha podido comprobar en el caso del cilindro con la imagen monalisa.jpg) Nos interesa que en los fondos superior e inferior tenga la imagen de la derecha (fondo.jpg) La operacin se hace de la siguiente manera:

Se define el cilindro con la imagen etiqueta.jpg, pero se anulan las superficies superior e inferior:

Shape { appearance Appearance { texture ImageTexture { url ["etiqueta.jpg"] } } geometry Cylinder { height 2 radius 0.6 top FALSE bottom FALSE } } Lo que anula las superficies superior e inferior son los comandos top FALSE y bottom FALSE respectivamente. Se define otro cilindro idntico con la imagen fondo.jpg, pero se anula la superficie lateral.

Shape { appearance Appearance { texture ImageTexture { url ["fondo.jpg"] } } geometry Cylinder { height 2 radius 0.6 side FALSE } } En este caso, lo que anula la superficie lateral es el comando side FALSE Por medio del nodo Group (ver cap. 7) se agrupan ambos cilindros, con lo que el resultado es aparentemente un cilindro con imgenes distintas. Pulsando aqu se puede ver el texto final del documento VRML.

Formatos de las imgenes

Los formatos de imagen soportados para ser utilizados como texturas son: JPG ( JPEG) GIF PNG

Textura con MovieTexture

En lugar de usar imgenes estticas como textura de los objetos, se pueden utilizar videos (pelculas), en formato MPEG, haciendo uso del nodo MovieTexture, en vez de ImageTexture, de la siguiente manera:

Shape { appearance Appearance { texture MovieTexture { url "mivideo.mpg" speed 1 loop FALSE } } geometry ... } Con el comando speed se controla la velocidad (1, velocidad normal, 2 doble velocidad, etc.). Con valores negativos el video se ejecutara hacia atrs. Con el comando loop se controla si el video funciona ininterrumpidamente (TRUE) o una sola vez (FALSE).

Ejercicio prctico
Se propone como ejercicio prctico de este captulo poner textura a algunos de los objetos del ejercicio del captulo anterior (planetas13.wrl), de la siguiente manera: Planeta WebMaestro: Adjudicar a este objeto como textura la imagen de la derecha (wmtextura.gif). Para ello, es necesario capturar la imagen (pulsando con el botn derecho del ratn, y guardndola con su nombre junto con los dems ficheros de los ejemplos)

Planeta Web3D: Adjudicar a este objeto como textura la imagen de la derecha ( web3dtextura.gif). Tambin ser necesario capturar esta imagen y guardarla con su nombre junto con los dems

ficheros de los ejemplos.

Para ello, tal como se ha visto anteriormente, basta con sustituir, en el nodo Shape de ambos objetos el campo material:

material Material {} por el campo texture, de la siguiente manera:

texture ImageTexture { url "imagen.gif" } Una vez de hechos los cambios indicados, guardar el fichero como planetas16.wrl A la derecha puede verse el resultado (pulsar la imagen para cargar el escenario). Como todava no se ha definido el punto de vista inicial ms conveniente, puede ser que el visor se site inicialmente dentro de la esfera mayor, y no se vea nada. En este caso, es necesario retroceder lo que sea preciso. Pulsando aqu se puede ver el texto del ejercicio prctico planetas16.wrl

#VRML V2.0 utf8 #Ejercio prctico planetas16.wrl #Planeta WebMaestro Shape { appearance Appearance { texture ImageTexture { url ["wmtextura.gif"] } } geometry Sphere { radius 10 } } #Planeta WebStore Transform { translation 10 6 10 children [ Shape { appearance Appearance {

material Material { diffuseColor 1 0.5 1 transparency 0.5 } } geometry Sphere { radius 1 } } ] } #Planeta Chat de WMaestro Transform { translation 25 1 -7 children [ Shape { appearance Appearance { material Material { diffuseColor 1 0.3 0.3 transparency 0.6 } } geometry Sphere { radius 1 } } ] } #Planeta Web3D Transform { translation -8 8 27 children [ Shape { appearance Appearance { texture ImageTexture { url ["web3dtextura.gif"] } } geometry Box { size 1 1 1 } } ] } #Letrero de bienvenida Transform { translation -7 9 25 children [ Shape { appearance Appearance { material Material { diffuseColor 1 1 0 } }

geometry Text { string [ " Bienvenido", " a WMaestro!", "Aterriza en tu planeta preferido" ] } } ] }

13. Formas complejas. Elevaciones

En el captulo anterior se ha visto cmo crear un suelo plano para nuestro mundo, haciendo uso del nodo IndexedFaceSet. En este captulo se va a ver cmo crear suelos accidentados, con distintas elevaciones, muy apto para crear cordilleras, fondos marinos, superficies de planetas, etc.

Nodo ElevationGrid para crear suelos accidentados

El nodo ElevationGrid (en ingls: rejilla de elevaciones) determina una rejlla de puntos, es decir, una cuadrcula de puntos de separacin uniforme en el plano horizontal XZ, a los que se atribuyen distintas cotas de altura. Se generer una superficie irregular uniendo dichas cotas. Veamos su estructura general con un ejemplo:

ElevationGrid { xDimension 6 xSpacing 4 zDimension 3 zSpacing 8 height [ 0.25, 4, 7, 3, 1.5, 0.25, 1.5, 2.5, 1.5, 2.1, 1, 0, 0.3, 0.3, 0, -2.7, -1.5, -3.7 ] } Observamos los siguientes campos (puede tener otros ms, como veremos): xDimension es el nmero de puntos de la rejilla, en la direccin del eje X (en este caso, 6 puntos) xSpacing es la separacin de los puntos de la rejilla, en la direccin del eje X (en este caso, 4) zDimension es el nmero de puntos de la rejilla, en la direccin del eje Z (en este caso, 3 puntos)

zSpacing es la separacin de los puntos de la rejilla, en la direccin del eje Z (en este caso, 8) height es la altura de cada uno de los puntos de la rejilla. En este caso, la rejilla tiene 6x3=18 puntos, por lo tanto, hay que poner las 18 cotas de altura que correspondan a cada punto.

A continuacin, una representacin de la rejilla (en rojo), con sus 18 puntos (en azul) y las cotas de altura atribuidas a cada punto:

La rejilla debe comenzar siempre en el origen de coordenadas y crecer en el sentido positivo de los ejes X y Z. En el ejemplo se puede observar que habr un pico mximo de valor 7 en el centro de la hilera trasera, y una depresin mxima de -3.7 a la derecha de la hilera delantera.

Inclusin del nodo ElevationGrid en el nodo Shape

Como se ha dicho repetida veces, para que un nodo que define una forma (como es el caso del nodo ElevationGrid) sea visible, debe incluirse dentro del nodo Shape (ver cap. 5). La estructura general del nodo Shape es:

Shape { appearance ... geometry ... } El nodo ElevationGrid ser el valor del campo geometry, quedando por tanto as (de manera resumida):

Shape { appearance ... geometry ElevationGrid { ... } } Y desarrollando totalmente el ejemplo:

#VRML V2.0 utf8 #Ejemplo del nodo ElevationGrid, #con la apariencia por defecto Shape { appearance Appearance { material Material { } } geometry ElevationGrid { xDimension 6 xSpacing 4 zDimension 3 zSpacing 8 height [ 0.25, 4, 7, 3, 1.5, 0.25, 1.5, 2.5, 1.5, 2.1, 1, 0, 0.3, 0.3, 0, -2.7, -1.5, -3.7 ] } } Este es el resultado. Como el punto inicial (el origen de coordenadas) no es demasiado conveniente para visualizar la superficie generada, a la derecha se puede ver una imagen de este ejemplo en donde se ha modificado el punto de vista inicial a uno ms conveniente. Tambin se han aadido unos ejes coordenados. (Pulsar la imagen para cargar el escenario) Obsrvese que la superficie generada es slida y existe gravedad, por lo que si se camina por la supeficie se "escalar" por las elevaciones. Si se gira completamente el escenario, se puede comprobar tambin que la superficie slo es visible por su parte delantera.

Determinando una cara visible

Por defecto, la cara visible es la perpendicular a la parte positiva de los ejes coordenados. En el ejemplo anterior, la cara es perpendicular a la parte positiva del eje Z.

Pero puede haber ocasiones que nos interese que sea visible la otra cara. Para determinar una cosa o la otra, el nodo ElevationGrid puede tener el campo ccw (abreviatura de counterclockwise: contrario a la agujas del reloj). Hay dos posibilidades: ccw TRUE Es la opcin por defecto, por tanto no es obligatoria ponerlo. La cara visible es la perpendicular a la parte positiva de los ejes coordenados. ccw FALSE En este caso, la cara visible es la opuesta a la parte positiva de los ejes coordenados

Si en el ejemplo anterior se aade el campo ccw FALSE, se puede ver aqu el resultado. Para poder ver la superficie hay que girar 180 el escenario.

Determinando ambas caras visibles

Se puede hacer que ambas caras sean visibles simultneamente. Para ello el nodo ElevationGrid puede tener el campo solid, que tiene dos posibilidades: solid TRUE Es la opcin por defecto: slo una cara es visible (la determinada por el campo ccw), y por tanto no es obligatorio ponerlo. solid FALSE En este caso, ambas caras son visibles simultneamente.

Si al ejemplo anterior de la cara verde, se le aade el campo solid FALSE, se puede ver aqu el resultado. Girando el escenario, se ver que ambas caras son visibles.

Poniendo color a la superficie generada

En el ejemplo visto anteriormente se ha utilizado la apariencia por defecto, sin un color definido. Ms adelante (en el captulo 13), se ver cmo se define el color para toda una superficie, mediante la inclusin de determinados campos dentro del nodo Material. Esto es general para toda clase de objetos visibles. Pero en este caso concreto, hay una manera de determinar el color de partes determinadas de la superficie, como vamos a ver a continuacin. Para comprender este mtodo conviene observar de nuevo la representacin de la rejilla vista anteriormente. En este caso, la rejilla est formada por dos hileras de 5 cuadrculas, es decir, en total 10 cuadrculas. Se puede determinar el color de la superficie generada sobre cada cuadrcula. A continuacin est la representacin de la rejilla vista desde arriba. Adems, se ha escrito en cada cuadrcula el color que se desea para la parte de la superficie que le corresponda y un nmero (del 1 al 10), para sealar el orden de atribucin de colores. Se ha escogido el color blanco para las zonas ms altas, el rojo para las intermedias, el verde para las bajas y el azul para las ms bajas.

Hay que aadir dos campos al nodo ElevationGrid: color que contiene el nodo Color, que a su vez contiene el campo color, en donde se especifican los 10 colores atribuidos a cada cuadrcula. colorPerVertex que puede ser TRUE, para colores en gradiente (no se estudiar este caso). O puede ser FALSE, en cuyo caso los colores son continuos. Se aplicar esta posibilidad.

El ejemplo anterior quedar de esta manera:

#VRML V2.0 utf8 #Ejemplo del nodo ElevationGrid, #con colores en las caras Shape { appearance Appearance { material Material { } } geometry ElevationGrid { xDimension 6 xSpacing 4 zDimension 3 zSpacing 8 height [ 0.25, 4, 7, 3, 1.5, 0.25, 1.5, 2.5, 1.5, 2.1, 1, 0, 0.3, 0.3, 0, -2.7, -1.5, -3.7 ] color Color { color [ 1 0 0 #rojo para la cuadr. 1 1 1 1 #blanco para la cuadr. 2

1 1 0 0 0 0 0 0

1 0 1 1 1 1 1 0

1 0 0 0 0 0 0 1

#blanco para la cuadr. 3 #rojo para la cuadr. 4 #verde para la cuadr. 5 #verde para la cuadr. 6 #verde para la cuadr. 7 #verde para la cuadr. 8 #verde para la cuadr. 9 #azul para la cuadr. 10

] } colorPerVertex FALSE #colores continuos (no degradados) solid FALSE #ambas caras visibles } } A la derecha puede verse el resultado. Se han aadido unos ejes coordenados y modificado el punto de vista inicial. (Pulsar la imagen para cargar el escenario).

Ejercicio prctico
Como ejercicio prctico de este captulo se propone crear la superficie inversa a la del ejemplo prctico visto a lo largo del captulo, es decir, mantener la misma rejilla y la misma distribucin de colores, pero con las 18 cotas cambiadas de signo, que seran por lo tanto, las siguientes:

-0.25, -4, -7, -3, -1.5, -0.25, -1.5, -2.5, -1.5, -2.1, -1, 0, -0.3, -0.3, 0, 2.7, 1.5, 3.7 Guardar el fichero resultante con el nombre de superficie13.wrl Este es el resultado y este es el texto del fichero. #VRML V2.0 utf8 #Ejemplo prctico del captulo 13 #Superficie con colores en las caras Shape { appearance Appearance { material Material { } } geometry ElevationGrid { xDimension 6 xSpacing 4 zDimension 3 zSpacing 8 height [ -0.25, -4, -7, -3, -1.5, -0.25, -1.5, -2.5, -1.5, -2.1, -1, 0, -0.3, -0.3, 0, 2.7, 1.5, 3.7 ] color Color { color [ 1 0 0 #rojo para la cuadr. 1 1 1 1 #blanco para la cuadr. 2 1 1 1 #blanco para la cuadr. 3 1 0 0 #rojo para la cuadr. 4 0 1 0 #verde para la cuadr. 5 0 1 0 #verde para la cuadr. 6 0 1 0 #verde para la cuadr. 7 0 1 0 #verde para la cuadr. 8 0 1 0 #verde para la cuadr. 9 0 0 1 #azul para la cuadr. 10 ] } colorPerVertex FALSE #colores continuos (no degradados) solid FALSE #ambas caras visibles } }

12. Formas complejas. Caras

Nodo IndexedFaceSet para obtener caras
En los dos captulos ltimos se ha visto cmo obtener puntos aislados, o lneas uniendo una serie de puntos. En ste se ver cmo obtener caras (superficies planas) definidas por varios puntos.

La idea es unir una serie de puntos para que formen una polilnea cerrada, que es la que definir la cara. Su estructra resumida es:

IndexedFaceSet { coord Coordinate { point [ . . . } coordIndex [ . . .

] ]

Observamos dos campos (puede tener ms, como se ver): coord, cuyo valor es el nodo Coordinate, y que sirve para determinar las coordenadas de los puntos aislados que se van a unir entre s para formar las caras. Se defini en el captulo 10. coordIndex, con este campo se define el orden con el que se unen los puntos entre s para formar las distintas caras, como vamos a ver a continuacin.

Veamos primero un ejemplo sencillo: tres puntos que se unen ordenadamente entre s para formar una cara:

IndexedFaceSet { coord Coordinate point [ 5 5 0, # 15 9 0, # 20 18 0 # ] } coordIndex [ 0, 1, 2, -1 ] }

{ este es el punto 0 este es el punto 1 este es el punto 2

En el campo coord se establecen las coordenadas de los tres puntos. A cada coordenada se ha aadido una lnea de comentario para indicar cul es la numeracin que le corresponde al punto. Obsrvese que se comienza por 0 (y no por 1). En el campo coordIndex se establece el orden en el que se unen los tres puntos que van a formar la polilnea cerrada que va a formar la cara. Con el valor -1 se indica que ah acaba la cara.

Inclusin del nodo IndexedFaceSet en el nodo Shape

Como se vi en el cap. 10, para que un nodo pueda verse, debe estar incrustado en el nodo Shape. Por tanto, de manera resumida, la inclusin del nodo IndexedFaceSet en el nodo Shape se har de esta manera:

Shape { geometry IndexedFaceSet { ... } } No se ha especificado ningn campo para su apariencia ni color, lo que se ver ms adelante. Desarrollando el ejemplo, quedar de esta manera:

#VRML V2.0 utf8 #Ejemplo de cara uniendo tres puntos, sin definicion del color Shape { geometry IndexedFaceSet coord Coordinate { point [ 5 5 0, #este 15 9 0, #este 20 18 0 #este ] } coordIndex [ 0, 1, 2, -1 ] } } { es el punto 0 es el punto 1 es el punto 2

A la derecha puede verse el resultado (pulsarla para cargar el escenario). Se han aadido unos ejes coordenados y modificado el punto de vista inicial. Se puede observar que se ha creado una cara triangular, sin color ni apariencia definida. Si se manipula el escenario, se puede comprobar que la cara slo es visible por un lado.

Se pueden definir ms de una cara simultneamente, como veremos ms adelante.

El color en las caras

Para determinar el color de la cara hay que hacer uso de tres campos ms: color colorIndex colorPerVertex

Con el campo color se especifican cuntos y qu colores se van a usar (en el caso de que haya ms de una cara). Este campo se vi en el cap. 10. Con el campo colorIndex se atribuye a cada una de las caras existentes alguno de los colores expresados en el campo anterior. Con el campo colorPerVertex se especifica si los colores sern colores continuos, o un gradiente entre dos colores. Veamos una aplicacin en el ejemplo anterior: vamos a hacer que la cara tenga un color verde.

#VRML V2.0 utf8 #Ejemplo de cara, uniendo tres puntos, Shape { geometry IndexedFaceSet { coord Coordinate { point [ 5 5 0, #este es el punto 15 9 0, #este es el punto 20 18 0 #este es el punto ] } coordIndex [ 0, 1, 2, -1 ] color Color {

de color verde

0 1 2

color [ 0 1 0 ]

#este es el color 0 (verde), #el unico posible pues solo hay una cara

} colorIndex [ 0 #a la unica cara se le atribuye el unico color 0 ] colorPerVertex FALSE } } En el campo color se especifica el color (o los colores, si hay ms de una cara) En el campo colorIndex se atribuye el color a la la cara (o caras, si hay ms de una). En este ejemplo slo hay una cara con un nico color. En el ejercicio prctico se va ver un caso de tres caras de distinto color. Nota: Se omite la explicacin del caso colorPerVertex TRUE (para conseguir caras con colores en gradiente), por su complicacin y escasa utilidad, pero sobre todo porque provoca inestabilidad en los visores de VRML (por lo menos en el mo :-) A la derecha puede verse el resultado (pulsar para cargar el escenario). Se han aadido unos ejes coordenados y modificado el punto de vista inicial. Si se manipula el escenario, se puede observar que la cara verde es visible slo por un lado, el que est de frente.

Determinando una cara visible

Por defecto, la cara visible es la perpendicular a la parte positiva de los ejes coordenados. En el ejemplo anterior, la cara es perpendicular a la parte positiva del eje Z. Pero puede haber ocasiones que nos interese que sea visible la otra cara. Para determinar una cosa o la otra, el nodo IndexedFaceSet puede tener el campo ccw (abreviatura de counterclockwise: contrario a la agujas del reloj). Hay dos posibilidades: ccw TRUE Es la opcin por defecto, por tanto no es obligatoria ponerlo. La cara visible es la perpendicular a la parte positiva de los ejes coordenados. ccw FALSE En este caso, la cara visible es la opuesta a la parte positiva de los ejes coordenados

Si en el ejemplo anterior se aade el campo ccw FALSE, se puede ver aqu el resultado. Para poder ver la cara verde hay que girar 180 el escenario.

Determinando ambas caras visibles

Se puede hacer que ambas caras sean visibles simultneamente. Para ello el nodo IndexedFaceSet puede tener el campo solid, que tiene dos posibilidades: solid TRUE Es la opcin por defecto: slo una cara es visible (la determinada por el campo ccw), y por tanto no es obligatorio ponerlo. solid FALSE En este caso, ambas caras son visibles simultneamente.

Si al ejemplo anterior de la cara verde, se le aade el campo solid FALSE, se puede ver aqu el resultado. Girando el escenario, se ver que ambas caras son visibles.

Utilizacin de este nodo para crear un suelo

Un uso muy til del nodo IndexedFaceSet es el de crear un suelo para un escenario de realidad virtual. Supongamos que queremos crear un suelo de color azul para nuestro mundo, de dimensiones 100x100. Entonces, las coordenadas de las cuatro esquinas sern:

50,0,50 -50,0,50 -50,0,-50 50,0,-50 Vamos a aadir el campo solid FALSE, visto en el apartado anterior. Este es el resultado. Pero si se carga el escenario, en principio no se ver nada. Esto es debido a que el punto de vista por defecto est precisamente a nivel cero, es decir, en el mismo suelo. Slo se ver el suelo si se hace girar todo el escenario. Determinando un punto de vista inicial elevado sobre el suelo (se ver ms adelante cmo conseguirlo), y superponiendo unos ejes coordenados, obtenemos el resultado que se puede ver en la imagen de la derecha (pulsarla para cargar el escenario). Obsrvese que al cargar el escenario, se "aterriza" sobre el suelo, y que se puede desplazar por l, pero no se pueden efectuar movimientos de elevacin. Esto es debido, a que automticamente se determina que existe gravedad en el mundo. Para poder flotar, hay que pulsar el mando "Float", que inhabilita la gravedad. Con este mtodo obtenemos un suelo del color que queramos, pero se pueden obtener suelos que tengan una textura determinada (hierba, piedra, etc.), lo que se ver ms adelante.

Con el nodo IndexedFaceSet se crean suelos planos. En el siguiente captulo se ver cmo crear suelos accidentados (terrenos con ditintas elevaciones, colinas, etc.).

Ejercicio prctico
Partiendo de estos cuatro puntos, de coordenadas:

5 5 0, 15 9 0 20 18 0 20 0 15

# punto 0 # punto 1 # punto 2 # punto 3

Se propone crear tres caras contiguas, visibles por ambos lados y de distinto color, de la siguiente manera: Una cara verde, con los puntos 0-1-2 Una cara amarilla, con los puntos 1-2-3 Una cara azul, con los puntos 0-1-3

En el campo point se pondrn las coordenadas de los 4 puntos, que tienen una numeracin del 0 al 3. En el campo coordIndex se expresar que existen tres caras formadas por sus respectivos puntos. Por tanto quedar as:

coordIndex [ 0, 1, 2, -1, 1, 2, 3, -1, 0, 1, 3, -1 ]

# primera cara # segunda cara #tercera cara

Como hay tres colores, el campo color deber ser:

color [ 0 1 0, 1 1 0, 0 0 1 ]

# color 0 (verde) # color 1 (amarillo) # color 2 (azul)

En el campo colorIndex se expresar que el orden de los colores atribuidos es el 0 (verde) para la primera cara, el 1 (amarillo), para la segunda y 2 (azul), para la tercera

colorIndex [ 0, 1, 2 ]

Adems, se aadirn los campos colorPerVertex FALSE y solid FALSE (para que sean visibles por ambos lados). Guardar el fichero con el nombre de caras12.wrl. Este es el resultado y este es el texto. A la derecha puede verse este ejercicio prctico al que se ha modificado el punto de vista inicial y aadido unos ejes coordenados (pulsar la imagen para cargar el escenario).

#VRML V2.0 utf8 #Ejercico practico del capitulo 12: Tres caras de distinto color, visibles por ambos lados Shape { geometry IndexedFaceSet { coord Coordinate { point [ 5 5 0, #este es el punto 0 15 9 0, #este es el punto 1 20 18 0, #este es el punto 2 25 0 15 #este es el punto 3 ] } coordIndex [ 0, 1, 2, -1, #primera cara 1, 2, 3, -1, # segunda cara 0, 1, 3, -1 #tercera cara ] color Color { color [ 0 1 0, #color 0 verde 1 1 0, # color 1 (amarillo) 0 0 1 # color 2 (azul) ] } colorIndex [ 0, 1, 2 #orden de atribucion de los colores ] colorPerVertex FALSE solid FALSE } }

11. Formas complejas. Lneas

Nodo IndexedLineSet, para crear lneas
Con este nodo se crean lneas, uniendo una serie de puntos determinados. Su estructura resumida es la siguiente:

IndexedLineSet { coord Coordinate { point [ . . . } coordIndex [ . . . }

] ]

Como se puede ver, tiene dos campos: coord, cuyo valor es el nodo Coordinate, y que sirve para determinar las coordenadas de los puntos aislados que se van a unir entre s para formar las lneas. Se defini en el captulo anterior. coordIndex, con este campo se define el orden con el que se unen los puntos entre s, dnde empieza y acaba una lnea, etc., como vamos a ver a continuacin.

Veamos primero un ejemplo sencillo: tres puntos que se unen ordenadamente entre s, para formar una lnea:

IndexedLineSet { coord Coordinate point [ 5 5 0, # 15 9 0, # 20 18 0 # ] } coordIndex [ 0, 1, 2, -1 ] }

{ este es el punto 0 este es el punto 1 este es el punto 2

En el campo coord se establecen las coordenadas de los tres puntos (tal como se vi en el captulo anterior.) A cada coordenada se ha aadido una lnea de comentario para indicar cul es la numeracin que le corresponde al punto. Obsrvese que se comienza por 0 (y no por 1). En el campo coordIndex se establece el orden en el que se unen los tres puntos. En este caso la lnea empieza en el primero (el 0), sigue con el segundo (el 1) y acaba en el tercero (el 2). Con el valor -1 se indica que ah acaba la lnea.

Inclusin del nodo IndexedLineSet en el nodo Shape

Como se vi en el cap. anterior, para que un nodo pueda verse, debe estar incrustado en el nodo Shape. Por tanto, de manera resumida, la inclusin del nodo IndexedLineSet en el nodo Shape se har de esta manera:

Shape { geometry IndexedLineSet { ... } } No se ha especificado ningn campo para su apariencia ni color, lo que se ver ms adelante. Desarrollando el ejemplo, quedar de esta manera:

#VRML V2.0 utf8 #Ejemplo de linea uniendo tres puntos, sin definicion del color Shape { geometry IndexedLineSet coord Coordinate { point [ 5 5 0, #este 15 9 0, #este 20 18 0 #este ] } coordIndex [ 0, 1, 2, -1 ] } } { es el punto 0 es el punto 1 es el punto 2

Es te es el resultado (se han superpuesto unos ejes coordenados y modificado el punto de vista inicial). En el ejemplo, se han unido los puntos segn el orden en el que estn especificados en el campo point (0,1,2), pero se pueden unir en el orden que se desee, como por ejemplo (0,2,1), con lo que resultar una lnea distinta. Habra que modificar el campo coordIndex, que quedara de esta manera:

coordIndex [ 0, 2, 1, -1 ] Este es el resultado. Se pueden crear simultneamente diversas lneas. Supongamos que en el campo point se han especificado las coordenadas de 12 puntos (por tanto, del 0 al 11), y queremos crear dos lneas, la primera con los 6 primeros puntos y la segunda con los 6 ltimos. El campo coordIndex quedara de esta manera:

coordIndex [ 0, 1, 2, 3, 4, 5, -1, 6, 7, 8, 9, 10, 11, -1 ]

#esta es una lnea #esta es otra lnea

El color en las lneas

Para determinar el color de cada uno de los segmentos que compone la lnea, hay que hacer uso de tres campos ms: color colorIndex colorPerVertex

Con el campo color se especifican cuntos y qu colores se van a usar (en el caso de que haya ms de una lnea). Este campo se vi en el cap. anterior. Con el campo colorIndex se atribuye a cada una de las lneas existentes alguno de los colores expresados en el campo anterior. Con el campo colorPerVertex se especifica si los colores sern colores continuos, o un gradiente entre dos colores. Veamos una aplicacin en el ejemplo anterior: una nica lnea quebrada que une tres puntos, se va a hacer que sea toda ella de color verde.

#VRML V2.0 utf8 #Ejemplo de linea de color verde, uniendo tres puntos Shape { geometry IndexedLineSet { coord Coordinate { point [ 5 5 0, #este es el punto 0 15 9 0, #este es el punto 1 20 18 0 #este es el punto 2 ] } coordIndex [ 0, 1, 2, -1 ] color Color { color [ 0 1 0 #este es el color 0 (verde), ] #el unico posible pues solo hay una linea } colorIndex [ 0 #a la unica linea se le atribuye el unico color 0 ] colorPerVertex FALSE } }

En el campo color se especifica el color (o los colores, si hay ms de una lnea) En el campo colorIndex se atribuye el color a la la lnea (o lneas, si hay ms de una). Este campo hace una funcin anloga con los colores y las lneas a la del campo coordIndex con los puntos y las lneas. En este ejemplo slo hay una lnea con un nico color. En el ejercicio prctico se va ver un caso de dos lneas con dos colores. Este es el resultado del ejemplo (se han aadido unos ejes coordenados, y se ha modificado el punto de vista inicial). Nota: Se omite la explicacin del caso colorPerVertex TRUE (para conseguir lneas con colores en gradiente), por su complicacin y escasa utilidad, pero sobre todo porque provoca inestabilidad en los visores de VRML (por lo menos en el mo :-)

Ejercicio prctico
En el ejercicio prctico del captulo anterior se cre un grupo de 10 puntos verdes y otro de 10 puntos amarillos. Ahora se propone crear una lnea verde que una los diez primeros puntos, y otra lnea amarilla que una los 10 ltimos. En el campo point se pondrn las coordenadas de los 20 puntos, que tienen una numeracin del 0 al 19. En el campo coordIndex se expresa que existen dos lneas: la primera uniendo ordenadamente los puntos 0 al 9, y la segunda del 10 al 19. Por tanto quedar as:

coordIndex [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, # primera linea 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, -1 #segunda linea ] Como hay dos colores, el campo color deber ser:

color [ 0 1 0 1 1 0 ]

# color 0 (verde) # color 1 (amarillo)

En el campo colorIndex se expresar que el orden de los colores atribuidos es el 0 (verde) para la primera lnea y el 1 (amarillo), para la segunda:

colorIndex [ 0, 1

] Guardar el fichero con el nombre de lineas11.wrl Este es el escenario y ste es el texto de este fichero #VRML V2.0 utf8 #Ejercicio practico del capitulo 11 #Dos lineas de color, verde y amarilla, uniendo dos conjuntos de 10 puntos Shape { geometry IndexedLineSet { coord Coordinate { point [ # Coord. del primer grupo de 10 puntos 1 1 0, 2 4 0, 3 5 0, 4 4 0, 5 6 0, 6 7 0, 7 5 0, 8 6 0, 9 4 0, 10 3 0, # Coord. del segundo grupo de 10 puntos 1 3 0, 2 2 0, 3 2 0, 4 1 0, 5 2 0, 6 4 0, 7 3 0, 8 5 0, 9 5 0, 10 6 0 ] } coordIndex [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, # primera linea 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, -1 #segunda linea ] ] color Color { color [ 0 1 0 # color 0 (verde) 1 1 0 # color 1 (amarillo) ] } colorIndex [ 0, 1 ] colorPerVertex FALSE } }

10. Formas complejas. Puntos

Formas complejas
Hasta ahora, para crear los distintos objetos que forman un escenario de realidad virtual, se han utilizado exclusivamente las formas primitivas (caja, cono, cilindro y esfera), que se definieron en el captulo 4 (Nodos primitivos). Tal como se ha visto en los captulos anteriores, agrupando y modificando estas formas primitivas se pueden conseguir otras formas ms complejas. Pero esta tcnica tiene un lmite. Supongamos que se quiere representar un automvil, por ejemplo. Con la sola utilizacin de las formas primitivas sera demasiado complicado de crear, y se generaran ficheros VRML demasiado voluminosos. Hay un mtodo ms eficaz para construir las formas complejas, que consiste en definir una serie de puntos en el espacio y luego unirlos entre s para crear lneas o superficies.

Nodo Coordinate
Este nodo sirve simplemente para definir una serie de puntos en el espacio tridimensional. En s mismo no sirve para representarlos, sino que se utilizar dentro de otros nodos, como se va a ver a continuacin. La estructura de este nodo es la siguiente:

Coordinate { point [ 12 11 17.1, 20.5 13.8 5.3, 14 6.1 22.9 ] } Como se puede ver, tiene un campo point, cuyo valor son grupos de tres cifras, separadas por comas, englobadas entre corchetes [ y ]. Cada grupo de tres cifras representa un punto en el sistema de coordenas (segn se vi en el captulo 8). En el ejemplo estn definidos tres puntos, pero se pueden poner tantos como se quiera. Este nodo se utiliza dentro de otros nodos, para conseguir cosas distintas: PointSet - para crear puntos aislados IndexedLineSet - para crear lneas IndexedFaceSet - para crear caras (superficies)

Nodo PointSet, para crear puntos aislados

Su estructura es:

PointSet { coord Coordinate { point [ . . . } }

Como se puede ver, tiene un campo coord cuyo valor es el nodo Coordinate visto anteriormente. Aplicando al ejemplo del nodo Coordinate, quedara de esta manera:

PointSet { coord Coordinate { point [ 12 11 17.1, 20.5 13.8 5.3, 14 6.1 22.9 ] } } Si incluyramos este cdigo, tal como est, en un documento VRML, no podramos ver ninguno de los puntos todava. La razn es que, como se vi en el captulo 5, para crear un objeto visible se debe utilizar el nodo Shape.

Inclusin del nodo PointSet en el nodo Shape

Como se vi en el captulo 5, la estructura general del nodo Shape es:

Shape { appearance ... geometry ... } Con el campo appearance se define la apariencia del objeto (color, textura, etc.) y con el campo geometry su forma. Por tanto, es evidente que la inclusin del nodo PointSet deber hacerse en este ltimo campo, ya que la geometra de este objeto es la de un grupo de puntos. De manera resumida, quedar de esta manera:

Shape { appearance ... geometry PointSet { ... } }

Desarrollando totalmente el ejemplo:

#VRML V2.0 utf8 #Ejemplo de un grupo de tres puntos Shape { appearance Appearance { material Material { } } geometry PointSet { coord Coordinate { point [ 12 11 17.1, 20.5 13.8 5.3, 14 6.1 22.9 ] } } } Pulsando aqu se carga el escenario con los tres puntos, al que se le han aadido unos ejes coordenados. Se podr observar que se ven los puntos con la apariencia por defecto (es decir, sin color ni textura). Pero los puntos pueden tener color si se desea.

Color en los puntos

Hasta ahora hemos considerado que el nodo PointSet tena un solo campo (coord), que sirve para definir la posicin de los puntos. Pero puede tener tambin otro campo (color), que sirve para definir el color de cada uno de los puntos. Es decir, el nodo PointSet puede tener esta estructura (resumida):

PointSet { coord Coordinate { point [ . . . ] } color Color { color [ . . . ] } } Como se puede observar, el campo color tiene como valor el nodo Color, que a su vez tiene como valor el campo color de nuevo. Desarrollando totalmente el ejemplo:

#VRML V2.0 utf8 #Ejemplo de un grupo de tres puntos con colores Shape {

geometry PointSet { coord Coordinate { point [ 12 11 17.1, #1 punto 20.5 13.8 5.3, #2 punto 14 6.1 22.9 #3 punto ] } color Color { color [ 1 0 0, # 1 punto rojo 0 1 1, # 2 punto verde 1 1 0 # 3 punto amarillo ] } } } Obsrvese que se ha prescindido del campo appearance del nodo Shape, que haba en el ejemplo anterior, ya que no es necesario, pues los puntos no van a tener la apariencia por defecto, sino la que se determina en el campo color. En el campo color se puede observar que hay (entre corchetes) tres grupos de nmeros, separados por comas. Cada grupo de tres cifras representa un color, para cada punto expresado en el campo point, y correspondindose en el mismo orden. (Ver en el captulo 13 el cdigo de colores) Pulsando aqu se carga el escenario con los tres puntos con sus correspondientes colores. Se han aadido unos ejes coordenados, y se ha forzado el punto de vista inicial para poder obsevarlos mejor.

Ejercicio prctico
Como ejercicio prctico de este captulo se propone definir dos grupos de 10 puntos, el primero de ellos de color verde y el segundo de color amarillo. Las coordenadas de los 10 puntos verdes son las siguientes: 110 240 350 440 560 670 750 860 940 10 3 0 y las coordenadas de los 10 puntos amarillos son las siguientes:

130 220 320 410 520 640 730 850 950 10 6 0 Guardar el fichero del ejercicio con el nombre de puntos10.wrl Este es el escenario, y ste es el texto del ejercicio. En el ejercicio prctico del captulo siguiente, se van a unir entre s los puntos del primer grupo para formar una lnea verde, y los del segundo para formar otra lnea amarilla. #VRML V2.0 utf8 #Web3D. Manual de VRML - http://www.wmaestro.com/web3d #Ejercio prctico del captulo 10: 10 puntos verdes y 10 puntos amarillos Shape { geometry PointSet { coord Coordinate { point [ # Coord. del primer grupo de 10 puntos 1 1 0, 2 4 0, 3 5 0, 4 4 0, 5 6 0, 6 7 0, 7 5 0, 8 6 0, 9 4 0, 10 3 0, # Coord. del segundo grupo de 10 puntos 1 3 0, 2 2 0, 3 2 0, 4 1 0, 5 2 0, 6 4 0, 7 3 0, 8 5 0, 9 5 0, 10 6 0 ] } color Color { color [ # Definicion del color verde para los primeros 10 puntos: 0 1 1, 0 1 1, 0 1 1,

0 0 0 0 0 0 0 # ultimos puntos: 1 1 1 1 1 1 1 1 1 1 ] } } }

1 1, 1 1, 1 1, 1 1, 1 1, 1 1, 1 1, Definicion del color amarillo para los 10 1 1 1 1 1 1 1 1 1 1 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

9. Nodos Switch y Billboard

En este captulo se van a estudiar dos nodos que tambin sirven para agrupar otros nodos: el nodo Switch y el nodo Billboard.

Nodo Switch
Este nodo Switch (en ingls, bascular o conmutar) sirve para agrupar otros nodos, pero con una diferencia: slo ser utilizado uno de los hijos agrupados. Su estructura es la siguiente:

Switch { whichChoice choice choice choice }

0 [...] [...] [...]

Como se puede ver, este nodo tiene un campo whichChoice (en ingls, cul eleccin) cuyo valor es un nmero que indica cal hijo choice es el elegido (0, 1, 2, etc.). Si este valor es -1, entonces se indica que no est elegido ninguno. Qu utilidad tiene este nodo? Un posible uso de este nodo es el de tener preparadas diferentes versiones del nodo Shape (ver cap. 5), es decir, diferentes formas de un objeto. Bastar con variar el valor de whichCoice para pasar rpidamente de una forma a otra.

Esta variacin se har utilizando los eventos, que es algo que se ver ms adelante.

Nodo Billboard
Este nodo Billboard (en ingls, cartel) sirve para agrupar otros nodos hijos. Todos los nodos agrupados sern visibles (al contrario del anterior, en el que slo es visible uno de ellos). La particularidad de este nodo es que crea un sistema de coordenadas para los nodos agrupados que est siempre de cara al espectador. Su estructura es la siguiente:

Billboard { axisOfRotation 0 1 0 children [ . . . ] } Tiene un campo, axisOfRotation (eje de rotacin), cuyo valor es un grupo de tres cifras que indican cul es eje alrededor del cual se efecta automticamente el giro para permanecer siempre de cara. La convencin que se utiliza es la misma que la vista en el captulo anterior para la rotacin, excepto que en este caso no hace falta poner un cuarto valor para expresar el ngulo: Rotacin alrededor del eje X: 1 0 0 Rotacin alrededor del eje Y: 0 1 0 Rotacin alrededor del eje Z: 0 0 1

A la derecha se puede ver un ejemplo de utilizacin de este nodo (pulsar la imagen para cargar el escenario), creado por David R. Nadeau para el manual Introduction To VRML 2.0 En el centro hay una figura agrupada con el nodo Billboard, que est siempre de cara al usuario, girando alrededor de su eje vertical. A su alrededor hay cinco fichas de color azul que han sido creadas usando el nodo Transform, y que por tanto no tienen este comportamiento.

8. Nodo Transform
Como se ha mencionado en el captulo anterior, por defecto, todos los objetos son creados en el centro del escenario de realidad virtual. Ahora vamos a ver cmo posicionarlos en otros puntos. Pero para ello, es necesario antes comprender la nocin de los sistemas de coordenadas.

Un punto en el espacio est definido por su posicin con respecto al centro de coordenadas.En el lenguaje VRML se adopta la convencin de que sea X la distancia que ese punto est desplazado a la derecha o a la izquierda del centro, Y la distancia por encima o por debajo, y Z la distancia hacia delante o hacia atrs. Se puede ver en la imagen de la derecha una representacin tridimensional de los ejes de coordenadas. Pulsndola se carga el escenario. (Se ha confeccionado utilizando cilindros muy finos, convenientemente girados para representar los ejes) Un mundo virtual tiene su sistema de coordenadas situado en el centro. Con el nodo Group, visto en el captulo anterior, se consigue agrupar un conjunto de objetos, que son creados haciendo coincidir su centro con el centro del sistema de coordenadas, como se puede apreciar en la figura de la derecha. (Se ha superpuesto el conjunto de objetos a los ejes coordenados) Con el nodo Transform, que vamos a ver a continuacin, se determina un nuevo sistema de coordenadas para un grupo de objetos.

Este nuevo sistema de coordenadas sufre unas transformaciones: puede ser trasladado a un punto determinado, puede ser girado un determinado ngulo, y puede tener una escala (tamao relativo) distinta a la original. El grupo de objetos especificados en el nodo sufrirn las mismas transformaciones, es decir, sern trasladados, girados y variados de escala.

Estructura del nodo Transform

Su estructura general es la siguiente:

Transform { translation rotation scale children [ }

. . . .

. . . .

. . . . ]

Como se puede ver, tiene tres campos con los que se determina su posible traslado, rotacin o nueva escala, y un cuarto campo children, en donde se especifican cules son los objetos agrupados que sufrirn esas transformaciones. No tienen por qu estar los tres campos a la vez. Por tanto, para simplificar, vamos a ver cada uno de ellos por separado.

Traslacin
Poniendo slo el campo translation, queda el nodo Transform de esta manera:

Transform { translation 20 0 0 children [ . . . ] } Se ha puesto un valor al campo translation. El orden para el traslado de las coordenadas es X, Y, Z. Por tanto, en este caso, hay una traslacin de 20 unidades hacia la derecha (si hubiera sido hacia la izquierda se habra puesto -20.0) Por supuesto que se podran haber variado las tres coordenadas, no slo la X como en este caso.

Con respecto al campo children, se aplica lo dicho en el captulo anterior, para el nodo Group. Aplicando lo visto al ejemplo prctico del captulo anterior, en el que se utilizaba el nodo Group para un conjunto de seis objetos (este era su cdigo), ste sera el nuevo cdigo.

Rotacin
Poniendo ahora slo el campo rotation, queda el nodo Transform de esta manera:

Transform { rotation 1 0 0 1.57 children [ ... ] } Tal como se ha puesto el valor del campo rotation quiere decir lo siguiente: rotacin de 90 alrededor del eje X.

Explicacin: Las tres primeras cifras slo pueden tener el valor 0 1, y representan la rotacin alrededor de cada eje, en este orden: X, Y, Z. Es decir: Rotacin alrededor del eje X: 1 0 0 Rotacin alrededor del eje Y: 0 1 0 Rotacin alrededor del eje Z: 0 0 1

La cuarta cifra representa el ngulo girado, expresado en radianes. Para calcular la correspondencia entre grados y radianes, hay que tener en cuenta que 180 equivalen al nmero pi en radianes, es decir a 3.14 radianes. Por tanto, 90 sera la mitad de 3.14, es decir 1.57 radianes. El sentido del giro es el de un sacacorchos avanzando en la direccin positiva de los ejes. En la figura de la derecha se puede ver al grupo de objetos, trasladados 20 unidades hacia la derecha y girados 90 alrededor del eje X (pulsar la imagen para cargar el escenario), cuyo cdigo es:

Transform { translation 20 0 0 rotation 1 0 0 1.57 children [ ... ] }

Variacin de la escala
Poniendo ahora en el nodo Transform slo el campo scale, para variar la escala de los objetos, queda de la siguiente forma:

Transform { scale 0.5 2 0.5 children [ ... ] } Los valores del campo scale representan las variaciones de las dimensiones con respecto a los ejes X, Y , Z.

Por tanto, en el ejemplo que se ha puesto, se reducen las dimensiones en la direccin de las X a la mitad (0.5), se duplican en la direccin del eje Y (2), y se reducen a la mitad en la direccin del eje Z (0.5). Si se hubiera variado la misma cantidad en los tres valores (por ejemplo, 0.5) se habra mantenido las proporciones de la pieza. En la figura de la derecha se puede ver al grupo de objetos, trasladados 20 unidades hacia la derecha y variada su escala (pulsarla para cargar el escenario), de acuerdo con el siguiente cdigo:

Transform { translation 20 0 0 scale 0.5 2 0.5 children [ ... ] }

Combinando los tres campos simultneamente (traslacin, giro y cambio de escala), su cdigo sera:

Transform { translation 20 0 0 rotation 1 0 0 1.57 scale 0.5 2 0.5 children [ ... ] }

Se puede ver en la figura de la derecha la pieza despus de sufrir los tres cambios (pulsarla para cargar el escenario). En todos los ejemplos de este captulo se ha utilizado el mismo grupo de seis objetos definidos en el campo children. Pero dentro del campo children puede haber un nico objeto, no tienen por qu ser siempre varios objetos.

Ejercicio prctico
Ahora que sabemos cmo colocar los objetos en distintas posiciones, vamos a desarrollar el escenario de los planetas, que se comenz como ejercicio prctico del captulo 5. Partiendo del documento VRML planetas05.wrl, en el que se cre una esfera de radio 10, se va a crear un nuevo documento con el nombre de planetas08.wrl, en el que se van a crear los siguientes objetos: El planeta WebMaestro, que es la esfera de 10 de dimetro, situada en el centro, que ya estaba creada en el ejercicio planetas05.wrl El planeta WebStore, que es una esfera de radio 1, trasladada a las coordenadas 10.0 6.0 10.0 El planeta Chat de WMaestro, que es una esfera de radio 1, trasladada a las coordenadas 25.0 1.0 -7.0 El planeta Web3D que es un cubo de lado 1, que se cre en el ejercicio del captulo 5, cuborot05.wrl y que debe ser trasladado a las coordenadas -8.0 8.0 27.0 El letrero de bienvenida, que se cre en el ejercicio del captulo 6 con el nombre de texto06.wrl, y que debe ser trasladado a las coordenadas -7.0 9.0 25.0

Este es el texto del documento planetas08.wrl La imagen de la derecha es el escenario de planetas08.wrl (pulsar para cargarlo). Los cuerpos todava no tienen ninguna textura o color, y faltan las animaciones del cubo giratorio y de la luna alrededor del planeta WebMaestro. Adems el punto de vista inicial es el que hay por defecto. Por tanto, puede ocurrir que el visor se site inicialmente en un sitio inapropiado (como es el caso del Cosmo Player 2.0, que se sita dentro de la esfera mayor). En este caso, ser necesario alejarse, utilizando el mando Zoom. Ms adelante se ver cmo

forzar para que sea el que nos interese.

En la imagen de la derecha (pulsar para cargar el escenario), se puede ver el escenario del ejercicio prctico al que se le han superpuesto los ejes coordenados, para que se puedan apreciar mejor las posiciones relativas entre los distintos cuerpos. Adems, se ha forzado el punto de vista inicial, para que sea uno conveniente.

#VRML V2.0 utf8 #Ejercio prctico planetas08.wrl #Planeta WebMaestro Shape { appearance Appearance { material Material {} } geometry Sphere { radius 10 } } #Planeta WebStore Transform { translation 10 6 10 children [ Shape { appearance Appearance { material Material {} } geometry Sphere { radius 1 } } ] } #Planeta Chat de WMaestro Transform { translation 25 1 -7 children [ Shape { appearance Appearance { material Material {} } geometry Sphere { radius 1

} } ] } #Planeta Web3D Transform { translation -8 8 27 children [ Shape { appearance Appearance { material Material {} } geometry Box { size 1 1 1 } } ] } #Letrero de bienvenida Transform { translation -7 9 25 children [ Shape { appearance Appearance { material Material {} } geometry Text { string [ " Bienvenido", " a WMaestro!", "Aterriza en tu planeta preferido" ] } } ] }

7. Agrupacin de nodos. Nodo Group

Agrupacin de nodos
Hasta ahora hemos visto los objetos aisladamente. Veamos ahora cmo podemos agrupar un conjunto de ellos para conseguir formas ms complejas. En los prximos tres captulos se van a ver diferentes nodos que sirven para agrupar otros nodos: Nodo Group (cap. 7) Nodo Transform (cap. 8) Nodo Switch (cap. 8a) Nodo Billboard (cap. 8a)

Nodo Group
Existe el nodo Group que permite tratar a un conjunto de nodos como una entidad nica, pero sin efectuar ninguna transformacin en ellos. Su estructura general es la siguiente:

Group { children [ ... ] } Tiene un campo llamado children (en ingls, nios o hijos), cuyo valor (los puntos suspensivos) va entre corchetes [ y ], y que como veremos a continuacin, es la lista de los objetos que se quieren agrupar, representados por sus nodos Shape respectivos:

Group { children [ Shape { ... }, Shape { ... }, ... ] } Veamos un ejemplo: Vamos a agrupar los ejemplos de una caja y de un cono vistos en el captulo 5:

#VRML V2.0 utf8 #Ejemplo de agrupacin de una caja y un cono Group { children [ #Aqu empieza la caja: Shape { appearance Appearance material Material } geometry Box { size 2 0.5 3 } }, #Aqu empieza el cono: Shape { appearance Appearance material Material } geometry Cone { height 3 bottomRadius 0.75 } } ]

{ {

{ {

} Vase el resultado en la imagen de la derecha (pulsndola se carga el escenario). Se puede observar que la caja y el cono estn superpuestos. Esto es debido a que los objetos son creados todos en el mismo punto: en el centro del escenario de realidad virtual. Para colocar un objeto, o grupo de objetos, en otros puntos que no sean el centro, se deber utilizar otro tipo de nodo, como se ver ms adelante.

Consejos prcticos para escribir el cdigo

A lo largo de los captulos hemos ido viendo la sintaxis de cada nodo y la manera de cmo se incrustan unos nodos dentro de otros, etc., para poder confeccionar los correspondientes documentos VRML. Si observamos el ltimo ejemplo, parece como si el cdigo se complicara ms y ms (a pesar de tratarse de un ejemplo relativamente sencillo). No hay tal complicacin, pero s es muy importante seguir unas cuantas reglas prcticas, pues es absolutamente imprescindible que las cosas estn colocadas en el orden debido, y que no sobre ni falte ninguno de los smobolos de apertura y de cierre { y }, [ y ] Utilizar una lnea distinta para cada nodo, para cada campo y para cada valor de cada campo. No es que sea obligatorio, pues de hecho se podra escribir todo el cdigo en una sola lnea, aunque esto no sera muy prctico e inducira a cometer errores. Como comprobacin, vase aqu el cdigo del ejemplo anterior escrito en una sola lnea (se han omitido las lneas de comentarios, pues stas s que requieren forzosamente estar en una lnea aparte). Y vase aqu el escenario generado por ese cdigo. Se puede comprobar que es exactamente el mismo que el generado por el cdigo escrito en mltiples lneas. Indentar cada lnea, segn su jerarqua. (Para indentar, es muy til utilizar la tecla tabuladora, que desplaza el cursor un nmero fijo de espacios).

Veamos lo que se quiere decir, observando el ejemplo anterior. El nodo Group, que es el nodo raz, no est indentado. Este nodo tiene un slo campo (children), que se indenta una vez. Children tiene como valor dos nodos Shape, que se indentan dos veces (o sea que ambos estn al mismo nivel). Cada nodo Shape tiene a su vez dos campos (appearance y geometry), que se indentan tres veces. Estos ltimos tienen sus respectivos campos, que se indentan cuatro veces, etc. etc. Colocar cada smbolo de cierre en el nivel de indentacin que le corresponda. As vemos en el ejemplo que el smbolo de cierre } de Group no tiene ninguna indentacin (est situado al final del todo). El smbolo de cierre ] de children tiene una indentacin (como el campo children). Los de los nodos Shape, tienen dos indentaciones, etc. De esta manera, vemos que los smbolos de cierre estn situados exactamente debajo del comienzo de la lnea que le corresponde. De esta manera estn perfectamente identificados, y sirve como control para no olvidarse de ninguno de ellos. Poner las lneas de comentario necesarias al mismo nivel que lo que se comenta. As, en el ejemplo, el comentario "#Aqu empieza la caja:" se indenta dos veces, para que est situado en el mismo nivel que el nodo Shape, que es el objeto del comentario.

Poniendo nombres propios a los nodos

Podemos observar en el ejemplo que se ha repetido dos veces el nodo Appearance, para dotar de la misma apariencia por defecto a los dos objetos (la caja y el cilindro). No es tan grave en este caso, pero imaginemos que se quiere dotar de esa misma apariencia, por ejemplo a cinco objetos distintos (como va a ser el caso del ejemplo prctico de este captulo). Entonces, habra que repetir cinco veces todo el nodo Appearance en cada uno de los cinco objetos, lo cual sera bastante engorroso, adems de complicar innecesariamente el cdigo. Hay una solucin prevista para simplificar estas repeticiones, y es que se puede definir un nodo que se piensa repetir en el cdigo, ponindole un nombre arbitrario. Supongamos, por ejemplo, que se van a utilizar repetidamente en un escenario unos cilindros exactamente iguales (que podran ser las columnas de una casa), y que dichos cilindros tienen el siguiente cdigo:

Shape { appearance Appearance { material Material { } } geometry Cylinder { height 2 radius 0.5 } } (Este es el cdigo de un cilindro con la apariencia por defecto, de 2 unidades de alto y una base de radio 0.5)

Se puede definir, para el mbito de un documento VRML, que este tipo de cilindro tenga un nombre arbitrario, por ejemplo ColumnaRepetida (o como se quiera, con tal de que comience por mayscula), de la siguiente manera:

DEF ColumnaRepetida Shape { appearance Appearance { material Material { } } geometry Cylinder { height 2 radius 0.5 } } Entonces, cada vez que se quiera usar este nodo en otra parte del documento, basta con poner lo siguiente:

USE ColumnaRepetida En el ejemplo anterior de la caja y el cono, lo que est repetido es el nodo Appearance. Vamos a definirlo, en la primera ocasin que se utiliza con el nombre, por ejemplo, PorDefecto y en la segunda vez utilizar slo el comando USE (se omiten las lneas de comentarios):

#VRML V2.0 utf8 #Ejemplo de agrupacin de una caja y un cono, #haciendo uso de los comandos DEF y USE. Group { children [ Shape { appearance DEF PorDefecto Appearance { material Material { } } geometry Box { size 2 0.5 3 } }, Shape { appearance USE PorDefecto geometry Cone { height 3 bottomRadius 0.75 } } ] } En este caso concreto, la simplificacin no ha sido muy grande (slo un par de lneas menos de cdigo), pero ha servido para ilustrar el concepto.

Ejercicio prctico
Para practicar con los conceptos aprendidos en este captulo (nodo Group y comandos DEF y USE), se propone la realizacin de la pieza que se puede ver a la derecha (pulsndola se carga el escenario).

Nota:Al tratar de visualizar este ejemplo, puede ocurrir que inicialmente no se vea nada. La razn de esto es que algunos visualizadores (entre ellos el Cosmo Player 2.0) se sitan en el centro mismo del escenario. En ese caso, es necesario retroceder, utilizando el mando Zoom. Ms adelante se ver la manera de forzar al visualizador para que se site en el punto que ms nos convenga. Est compuesta por los siguientes objetos: Una caja de 10x10x10 (un cubo) Una esfera de radio 7 Un cilindro de altura 0.5 y radio de la base 12.5 Otro cilindro de altura 20 y radio de la base 4 Otro cilindro de altura 30 y radio de la base 3 Otro cilindro de altura 60 y radio de la base 1

Guardar el documento VRML con el nombre de pieza07.wrl Pulsando aqu se puede ver el texto del documentodocumento.

#VRML V2.0 utf8 #Ejercicio prctico pieza07.wrl Group { children [ Shape { appearance DEF PorDefecto Appearance { material Material { } } geometry Box { size 10 10 10 } }, Shape { appearance USE PorDefecto geometry Sphere { radius 7

} }, Shape { appearance USE PorDefecto geometry Cylinder { radius 12.5 height 0.5 } }, Shape { appearance USE PorDefecto geometry Cylinder { radius 4 height 20 } }, Shape { appearance USE PorDefecto geometry Cylinder { radius 3 height 30 } }, Shape { appearance USE PorDefecto geometry Cylinder { radius 1 height 60 } } ] }

6. Nodo Text
En los mundos virtuales ser a menudo necesario utilizar textos para guiar al visitante (en forma de carteles, comentarios, paneles de control, etc.) Para ello existe un nodo especfico, el nodo Text que, al igual que los nodos primitivos, ir incrustado en el nodo Shape, como se ver ms adelante. Los textos son siempre planos y no tienen espesor. Se puede determinar el tipo de fuente, su estilo y tamao, etc.

Estructura del nodo Text

Su estructura general es la siguiente:

Text { string ... fontStyle ...

} Tiene, por tanto, dos campos: string: (en ingls, fila). Su valor (los puntos suspensivos) es precisamente el texto que se quiere poner. fontStyle: su valor (los puntos suspensivos) es un sub-nodo llamado FontStyle (obsrvese una vez ms que el primero empieza por minscula, por ser un campo, mientras que el segundo lo hace por mayscula, por ser un nodo).

El campo fontStyle es opcional. Si se omite, el texto tendr el estilo de fuente por defecto. Veamos cada campo por separado:

Valor del campo string (el texto)

Se pone de esta manera:

string ["Esta es la primera fila de texto", "esta es la segunda fila", "etc."] Como se puede ver, cada fila de texto va entre comillas, con una coma al final de cada lnea, y todo ello englobado entre corchetes: [ y ]

Nodo FontStyle
Veamos su estructura con un ejemplo:

FontStyle { family "SERIF", style "BOLD", size 1 spacing 1 } En este ejemplo, el nodo FontStyle tiene los siguientes campos:

family: Determina la familia de fuente. Se puede escoger entre "SERIF", "SANS" o "TYPEWRITER" (en ingls, mquina de escribir). Obsrvese que los nombres estn en maysculas. style: Se puede escoger entre "BOLD" (negrita), "ITALIC" (cursiva), "BOTH" (ambas, es decir, negrita y cursiva), o "NONE" (ninguna, es decir, ni negrita ni cursiva). size: Determina el tamao de la fuente, pero en unidades VRML. Es decir, que si se adopta que la unidad equivale a un metro (escala aconsejada, pero no obligatoria), en el caso del ejemplo las letras se supone que tienen un metro de altura. spacing: Determina la separacin entre lneas, tambin en unidades VRML.

Existen ms campos que los que aparecen en este ejemplo, con los que se puede afinar an ms la disposicin del texto: justify: Determina la justificacin del texto. Puede ser "BEGIN" (al comienzo, es decir a la izquierda), "MIDDLE" (en el medio, es decir, centrado) o "END" (al final, es decir, a la derecha). otros: que se omiten aqu, pues estn pensados para idiomas exticos, como el chino (escritura en vertical), el rabe (escritura de derecha a izquierda), etc. Para la lista completa, se puede consultar la RFC 1766

Nodo Text completo

Poniendo ahora el nodo texto completo, con sus dos campos, queda de esta forma:

Text { string ["Esta es la primera fila de texto", "esta es la segunda fila", "etc."] fontStyle FontStyle { family "SERIF", style "BOLD", size 1 spacing 1 } }

Integrando el nodo Text en el nodo Shape

El nodo Text se incrusta en el nodo Shape, de la misma manera que se haca con los nodos primitivos. En el captulo anterior vimos que el nodo Shape tena esta estructura:

Shape { appearance ... geometry ... } Vimos que los nodos primitivos se ponan como valor del campo geometry. Es lo mismo que vamos a hacer ahora:

Shape { appearance ... geometry Text { ... } } Aqu est de una manera resumida. Para desarrollarlo completamente, hay que poner como campo de appearance la apariencia por defecto (ver cap. anterior), y lgicamente, el nodo Text completo.

Puedes ver: el documento VRML y el escenario de realidad virtual con este texto. Como se puede ver en la imagen, el texto se puede manipular como cualquier otro objeto (girndolo, etc.), ya que, en realidad, es un elemento plano de espesor cero. Las letras tienen el color por defecto, ya que se ha utilizado la apariencia por defecto. Pero se puede hacer que tengan el color que se desee, segn veremos ms adelante.

Ejercicio prctico
Como ejercicio prctico de este captulo, se a confeccionar el texto que aparece en primer trmino en el escenario planetas.wrl El nodo Text va a tener slo el campo string (no va a tener, por tanto el campo fontStyle). El valor del campo string van a ser las siguientes tres filas de texto: "Bienvenido" "a WMaestro!" "aterriza en tu planeta preferido" Para que queden las palabras centradas, se deben poner 14 espacios en blanco antes de la palabra Bienvenido, y 13 antes de la frase "a WMaestro!" El documento VRML se debe guardar con el nombre de texto06.wrl, junto con los otros ejercicios. Este es el documento y este el escenario. VRML V2.0 utf8 #Ejercicio prctico texto06.wrl Shape { appearance Appearance { material Material { }

geometry Text { string [" Bienvenido", " a WMaestro!", "Aterriza en tu planeta preferido"] } }

5. Nodo Shape
Como se indic en el captulo anterior, para crear un objeto visible se debe utilizar el nodo Shape. Este nodo tiene dos campos: appearance y geometry. Con el primero se controla la apariencia del objeto (color, textura, iluminacin, etc.) y con el segundo su geometra. Por tanto, la estructura general del nodo es:

Shape { appearance ... geometry ... } Los puntos suspensivos representan los valores de cada campo. El primer campo (appearance) es opcional, y se puede prescindir de l, lo que vamos a hacer de momento por motivo de sencillez en la explicacin. O sea, que el nodo quedara de esta manera:

Shape { geometry ... } Pero el valor del campo geometry (los puntos suspensivos) es precisamente uno de los cuatro nodos primitivos que hemos visto en el captulo anterior (Box, Cone, Cylinder y Sphere). Escojamos el primero de ellos (Box), del ejemplo del captulo anterior, y pongmoslo como valor del campo geometry:

Shape { geometry Box {size 2 0.5 3} } Con esto hemos definido un objeto visible (aunque todava sin ningn atributo de apariencia definido), que tiene la geometra de una caja de medidas 2x0.5x3 Hemos puesto el nodo Box en una sola lnea, pero conviene que lo pongamos desarrollado en varias lneas, para irnos acostumbrando, pues es muy importante que los smbolos { y } estn colocados en el orden que les corresponde, y no olvidarse de ninguno de ellos:

Shape { geometry Box { size 2 0.5 3 } }

Ahora ya estamos en condiciones de crear el primer documento VRML con el que se podr ver el objeto con el visualizador, aunque todava en unas condiciones bastante imperfectas, ya que todava no tiene definido ningn atributo de apariencia. Para crear el documento VRML slo falta ponerle la lnea de cabecera, y algn comentario si queremos:

#VRML V2.0 utf8 #Primer documento VRML #Caja sin apariencia definida Shape { geometry Box { size 2 0.5 3 } } Se guarda con el nombre que se quiera, con la extensin .wrl En este caso, va a ser cap05_caja.wrl Para verlo en el visualizador, basta con abrir este fichero en el navegador (con el men Archivo/Abrir). A la derecha se puede ver el resultado. Pulsando la imagen se carga el escenario de realidad virtual. Como se puede observar en la imagen, las caras del objeto son de color blanco y no se distinguen unas de otras, pudindose apreciar slamente el contorno del objeto. Ahora vamos a dar el siguiente paso: suministrar al objeto unas cualidades de apariencia (aunque de momento slo van a ser las que existen por defecto)

Poniendo la apariencia por defecto

Como se ha visto al comienzo del captulo, el nodo Shape tiene tambin el campo appearance, del que habamos prescindido de momento:

appearance ... Tenemos que poner un valor (los puntos suspensivos) al campo appearance. No va a ser un nmero (o un conjunto de nmeros), sino un nodo llamado Appearance. Obsrvese la A mayscula de Appearance, que indica que se trata de un nodo, mientras que en el caso de appearance la a minscula indica que es un campo (del nodo Shape). Veamos, primero por separado, la estructura de este nuevo nodo Appearance:

Appearance { material Material { }

Vemos que el nodo Appearance tiene, a su vez, un campo llamado material, cuyo valor es otro nodo, llamado Material, en el que se ha dejado en blanco su contenido (no hay nada entre los smbolos { y } del nodo Material), lo que hace que estn definidas las caractersticas por defecto de este nodo. En un captulo posterior aprenderemos a manipular el nodo Material, para definir sus caractersticas a nuestro gusto (color, luminosidad, transparencia, etc.)

Encajando todas las piezas

Todo lo anterior puede parecer a primera vista como algo muy complicado. Pero no lo es, si consideramos que, en realidad, los nodos son como mdulos de informacin que encajan unos en otros, formando una red (de ah su nombre). Es decir, algo que puede ser muy complejo, tal como un mundo virtual, est compuesto de pequeas y simples unidades de informacin (los nodos) que actan como las piezas de un mecano. Centrndonos en el caso concreto de la caja, vamos a ensamblar las distintas piezas. Primero, coloquemos el nodo Appearance como el valor del campo appearance:

appearance Appearance { material Material { }

Ahora ya podemos colocar este campo dentro del nodo Shape, en el documento VRML, con algunos comentarios que faciliten su comprensin:

#VRML V2.0 utf8 #Caja con la apariencia por defecto Shape { #Campo appearance: appearance Appearance { material Material { } #Campo geometry: geometry Box { size 2 0.5 3 } } Se guarda como cap05_caja1.wrl

A la derecha se puede ver el resultado. Pulsando la imagen se carga el escenario. Como se puede apreciar en la figura (y an ms manipulndola con el visualizador), la diferencia es notable. Ahora se distinguen perfectamente las caras de la caja, debido a que tienen una iluminacin y textura adecuadas. Siguiendo un proceso similar para el nodo primitivo Cone, visto en el captulo anterior, el documento VRML para visualizarlo (tambin con la apariencia por defecto), sera el siguiente:

#VRML V2.0 utf8 #Cono con la apariencia por defecto Shape { #Campo appearance: appearance Appearance { material Material { } #Campo geometry: geometry Cone { height 3 bottomRadius 0.75 } } Como se puede observar, el campo appearance es idntico al caso anterior, slo cambia el valor del campo geometry, que es el nodo Cone. A la derecha se puede ver el resultado. Pulsando la imagen se carga el escenario. Para completar los cuatro casos de geometra primitiva vistos en el captulo anterior, vamos a ver los ejemplos para el cilindro y para la esfera. Se van a omitir sus documentos VRML, por ser totalmente similares a los anteriores.

Pulsando cada imagen se carga el escenario:

Ejercicio prctico
A lo largo de los captulos se van a ir proponiendo ejercicios prcticos relacionados con el tema visto. Con los los distintos ejercicios se va ir creando progresivamente el siguiente escenario de realidad virtual (pulsar la imagen para cargar el escenario):

que consiste en unos planetas (unos estticos y otros en movimiento), y que al ser pulsados conducen a pginas Web determinadas. Como ejercicios prcticos del presente captulo, se deben crear los documentos VRML siguientes: Uno que contenga una esfera de radio 10, con la apariencia por defecto, que se debe guardar con el nombre de planetas05.wrl Otro, que contenga una caja, tambin con la apariencia por defecto, con las tres medidas (ancho, alto y fondo) iguales a la unidad (lo que har que sea un cubo), que se deber guardar como cuborot05.wrl

El primero va a ser el escenario general, y el segundo el cubo rotatorio, que se va a aadir dentro de l. Conviene crear una carpeta donde ir guardando los distintos ejercicios. Estos son los textos de los dos documentos VRML: planetas05.wrl

cuborot05.wrl

y estos son los escenarios creados con esos documentos: planetas05.wrl cuborot05.wrl

Nota:Si se trata de visualizar el primero de ellos, puede ocurrir que inicialmente no se vea la esfera. La razn de esto es que algunos visualizadores (entre ellos el Cosmo Player 2.0) se sitan dentro de la esfera, que es relativamente grande. En ese caso, es necesario retroceder, utilizando el mando Zoom. Ms adelante se ver la manera de forzar al visualizador para que se site en el punto que ms nos convenga.

4. Nodos primitivos
Los nodos son los bloques de informacin bsicos con los que se construye un mundo virtual. Vamos a ver la sintaxis de los nodos partiendo de los ms sencillos, los nodos de geometra primitiva, o nodos primitivos, que son: Box - caja Cone - cono Cylinder - cilindro Sphere - esfera

Con estas figuras geomtricas bsicas, agrupndolas y modificndolas convenientemente se pueden construir formas ms complicadas (lo que se va a ver en los tres captulos que forman la seccin Agrupacin de nodos). Para formas realmente complejas, hay otros procedimientos para crear objetos, partiendo de puntos, lneas o caras (se ver en la seccin Formas complejas).

Box
La estructura ms general de un nodo es:

Box { ... } Se escribe el nombre del nodo, en este caso Box, seguido del smbolo de apertura { A continuacin se escribe el campo, que es un atributo del nodo que podemos cambiar a voluntad, poniendo los valores que nos interesen. En este caso servir para establecer las dimensiones de la caja, como se ver a continuacin. A continuacin se escribe el smbolo de cierre }

Con respecto a los nombres, y en general cualquier otro comando usado en este lenguaje, se debe tener muy en cuenta que son sensibles a las maysculas y minsculas. Es decir, se debe escribir Box y no box, o fontStyle y no fontstyle, etc. Sustituyendo ahora los puntos suspensivos por el campo que define este nodo, que es size (tamao) con sus valores correspondientes (las dimensiones), queda el nodo completado de esta forma:

Box {size 2 0.5 3} Los nmeros representan respectivamente la anchura, la altura y el fondo. Son dimensiones abstractas, pero es conveniente, aunque no obligatorio, suponer que son metros. El nodo, por tanto, define un paralelepdo (una caja) de 2 m. de ancho, 0.5 m de alto y 3 m de fondo. Se ha escrito el nodo en una sla lnea, debido a su sencillez y a que slo tiene un campo, pero se podra haber escrito de esta otra forma:

Box { size 2 0.5 3 }

Cone
Veamos un ejemplo de este nodo, que define la geometra de un cono:

Cone { height 3 bottomRadius 0.75 } Como se puede observar, tiene dos campos: height (altura), al que se le ha puesto el valor de 3, y bottomRadius (radio de la base) el de 0.75. Con estos dos valores queda perfectamente definido el cono.

Cylinder
Ejemplo del nodo que define un cilindro:

Cylinder { height 2 radius 1.5 } Tiene dos campos: height (altura) y radius (radio)

Sphere
Ejemplo del nodo que define una esfera:

Sphere { radius 1 } Tiene un solo campo, radius (radio) pues es suficiente para definir con l una esfera.

Utilizacin de estos nodos

Estos cuatro nodos de geometra primitiva, que acabamos de ver, no se pueden utilizar directamente ellos solos, sino que son parte integrante de otro nodo ms general, el nodo Shape (forma), que veremos en el captulo siguiente. Es decir, si queremos crear el cono del ejemplo, sera incorrecto crear este documento VRML:

#VRML V2.0 utf8 #Este documento es incorrecto Cone { height 3 bottomRadius 0.75 } Suponiendo que lo guardramos con el nombre de cono.wrl, por ejemplo, y tratramos de ejecutarlo en un visualizador, nos dara error o no se vera nada. El motivo de esto es que estos nodos definen nicamente la geometra de estos cuerpos, pero no dan ninguna indicacin de cul deber ser su apariencia, es decir, su color, textura, iluminacin, etc. En cambio el nodo Shape se encarga de ambas cosas, ya que tiene dos campos: la apariencia y la geometra, en donde utiliza precisamente estos nodos que acabamos de ver. Es decir, estos nodos irn incrustados en el nodo Shape. Este es el tema del captulo siguiente, donde se comenzarn a crear los primero ejemplos de mundos virtuales.

Sintaxis de los nodos

Con los ejemplos anteriores podemos entender ms fcilmente el concepto y la sintaxis (reglas para la correcta escritura) de los nodos, desde un punto de vista general.

Nombre { campo1 x y z

campo2 x ... } El nodo es un bloque de informacin que tiene un Nombre (Box, Cone, etc.) Obsrvese que comienzan siempre por una letra mayscula. Englobados entre los smbolos { y } el nodo tiene uno o varios campos (size para el nodo Box, height y bottomRadius para el nodo Cylinder, etc.) Los campos son los atributos variables del nodo. Obsrvese que comienzan con una letra minscula. A continuacin est el valor que le asignamos a ese campo, que es un nmero (o conjunto de nmeros) Estos nmeros se escriben con punto flotante (es decir, con decimales). En ocasiones, en lugar de colocar como valor un nmero (o conjunto de nmeros) se coloca todo un nodo. Esta nocin, que puede parecer confusa de momento, se aclarar en el captulo siguiente, donde se ver con detalle el nodo Shape.

3. Documentos VRML
Para crear un mundo de realidad virtual se utiliza un fichero de texto, creado con un procesador cualquiera de textos que se debe guardar con la extensin .wrl Este fichero constituye un documento VRML, que ser ejecutado por el visualizador, de manera completamente anloga a los documentos HTML, que son ficheros de texto con la extensin .html y que son ejecutados por los navegadores para visualizar las pginas del Web. Tambin se pueden crear estos documentos utilizando ciertos progamas editores de VRML, que los generan automticamente, sin necesidad de saber programar en este lenguaje. Se hablar sobre estos programas ms adelante.

Estructura de los documentos VRML

En lneas generales, un documento VRML contiene los siguientes elementos: Lnea de cabecera Comentarios al cdigo Nodos

Lnea de cabecera
Todo documento VRML debe comenzar necesariamente con la siguiente lnea:

#VRML V2.0 utf8 Con esta lnea inicial se hace la declaracin de que el estndar empleado es el VRML 2.0. El identificativo utf8 sirve para permitir el uso de caracteres internacionales.

No se debe dejar ningn espacio en blanco antes del comienzo de la lnea (antes del smbolo #), pues en caso contrario el visualizador no la reconocera, y dara error al ejecutar el documento VRML.

Comentarios al cdigo
En todos los lenguajes se utilizan comentarios al cdigo, no visibles en la pantalla, que son muy tiles como recordatorio de lo que se ha hecho y que facilitan los cambios futuros. En este lenguaje los comentarios se escriben en una sola lnea que comienza con el smbolo #. Ejemplo:

# Este es un comentario al cdigo

Nodos
Los nodos son bloques de informacin que definen las caractersticas de un objeto concreto (su forma, su apariencia, etc.), o la relacin entre distintos objetos. Sirven tambin para crear sonidos, el panorama de fondo, enlaces a otros mundos o a pginas Web, etc. Es decir, son las unidades bsicas que forman el mundo virtual, y pueden ser afinadas hasta el detalle deseado. En el siguiente captulo se ver su sintaxis y algunos ejemplos.

2. Equipamiento necesario
Para poder apreciar el VRML es preciso disponer, adems de una conexin a Internet y de un navegador convencional del Web, de un visualizador de VRML. Si tienes una de las ltimas versiones completas de los navegadores del Web ms populares, el Netscape Navigator 4.0 o el Microsoft Internet Explorer 3.0 en adelante, probablemente tienes ya instalado, como un plug-in, un visualizador de VRML. Por otra parte, es preciso disponer de una buena conexin con Internet y de un ordenador relativamente potente y con suficiente memoria RAM.

Visualizadores de VRML
Los usuarios del Netscape Communicator 4.01 tendrn probablemente ya instalado como plugin de VRML el Cosmo Player de Silicon Graphics. Algunas versiones anteriores incluan en su lugar el Live3D, pero Netscape ha abandonado este programa. Quien lo tenga instalado

deber cambiarlo por el anterior (el Cosmo Player), pues el Live3D no funciona correctamente con el actual estndar VRML 2.0

Se puede averiguar cules plug-ins estn instalados en el Netscape, desplegando el men Help/About Plug-ins (Ayuda/Acerca de los plug-ins). La ltima versin del Cosmo Player es la 2.0 (para Win95/NT), y es con diferencia, el visualizador de VRML ms aconsejable. Se puede obtener en esta pgina de Cosmo Software Una vez obtenido el fichero, se debe ejecutar, y la instalacin dentro del Netscape o Explorer se har de forma automtica. Para moverse dentro del visualizador: bsicamente se consigue arrastrando el ratn sobre l (o utilizando las teclas con flecha). En su parte inferior existe una consola de mandos para cambiar la manera de actuar. A la derecha hay un botn para cargar una pgina de ayuda (Help) muy detallada (en ingls). Puedes encontrar, al final del ndice de este manual, en la seccin Ayuda visualizador un resumen de los mandos del Cosmo Player 2.0, y que por cargarse en el frame de la izquierda permanece siempre a la vista.

Conexin y equipo necesarios

Debes tener una conexin a Internet rpida, por lo menos de 28.800 bps. Si es ms lenta, tendrs que soportar largas esperas. Lgicamente, si es an ms rpida, todava mejor. Por ejemplo, los usuarios que dispongan de una conexin por medio RDSI (red digital de servicios integrados) apreciarn muchsimo ms la realidad virtual que los que lo intenten con una lenta conexin de 14.400 bps. Con respecto al ordenador, se debe disponer de por lo menos un microprocesador tipo Pentium corriendo a una velocidad de por lo menos 100 MHz. Menos que esto, simplemente no es lo suficentemente rpido como para poder apreciar la realidad virtual, pues de lo contrario se tendrn que soportar retrasos en la respuesta. Y con respecto a la memoria RAM, el ordenador debe tener un mnimo de 16 megas para una buena visualizacin, pero 32 megas o ms es muchsimo ms conveniente.

Prueba de VRML
Para comprobar si tienes instalado en tu navegador el correspondiente visualizador de VRML, as como para ver cul es el rendimiento de tu ordenador, puedes pulsar los siguientes enlaces, con los que se pueden cargar algunos ejemplos sencillos: Arcos Silla Lata Web3D A continuacin, un ejemplo de aplicacin del VRML para las pginas Web:

Pulsando esta imagen puedes cargar un mundo virtual que va a servir como entrada en tres dimensiones a WMaestro. Al pulsar algunos de los objetos (planetas), el usuario es transportado a la correspondiente pgina Web (WebMaestro, WebStore, etc.) En los ejercicios prcticos de los distintos captulos se explicar con detalle cmo crear este escenario de realidad virtual. En el ndice de este manual, puedes encontrar, en la seccin "Ayuda visualizadores", un resumen de los mandos de ambos visualizadores, el del Netscape y el del Explorer. Para salir del visualizador, debers pulsar el icono de retorno del navegador que te conducir de nuevo a esta pgina. Si la prueba ha sido satisfactoria, puedes visitar estos sitios de Internet, que son recopilaciones de distintos escenarios de VRML y que te permitirn juzgar sobre las posibilidades que ofrece esta tecnologa: VRML Gallery Proteinman's Top Ten VRML2.0 Worlds