El Lenguaje VRML - 2

Metodologia del lenguaje VRML_2
Recopiladoby masrio valverde
ESPECIFICACIN DEL ESTNDAR VRML 2.0

1. 2. 3. 4. 5. 6. 7. Conceptos. 2 Tipos de datos. 7 Nodos. 13 Prototipos. 70 Rutas. 75 Gramtica. 76 Glosario.
Ref: http://www.jose-emilio.com/estudios/
Pgina 1 de 116
CONCEPTOS:
REALIDAD VIRTUAL:
La realidad virtual es un trmino asociado con sistemas computacionales que interactan con el usuario, permitindole algn grado de inmersin. Se puede lograr un grado de simulacin tal que el usuario puede ingresar a travs de mundos que aparentan ser reales. La inmersin dentro de este contexto se entiende como aquella situacin en la que un usuario se siente experimentando una realidad alterna desde adentro del sistema, el grado de inmersin logrado en VRML es aquel denominado parcial, la que se refiere a la observacin directa de una imagen 3D a travs de un computador. Un usuario navega cuando se desplaza el punto de vista de ste a travs del espacio tridimensional, logrando explorarlo e interactuar a travs de l aparentemente a voluntad; esta sensacin de movimiento crea la ilusin de un mundo virtual. Un Mundo Virtual se puede definir como un sistema de ambientes y objetos virtuales grficos y tridimensionales, de diversas jerarquas, relacionados entre s y operando en forma dinmica, interactiva y multisensorial con respecto a sus usuarios, apoyndose en el uso de uno o ms computadores para cumplir determinados propsitos. La creacin de un Mundo Virtual puede orientarse a diferentes usos desde el diseo de juegos, simulacin comercial de diseo, visita de cocinas con la participacin del usuario, visualizacin cientfica y participacin activa en proceso de ensamblaje de molculas.
VRML:
VRML (Virtual Reality Modeling Language) es un lenguaje para la descripcin de figuras tridimensionales y ambientes interactivos dentro del WWW (World Wide Web). Para escribir un archivo VRML se puede usar cualquier editor de texto, o bien alguna herramienta de desarrollo VRML que exista en el mercado. Para visualizar un archivo VRML se puede usar un visualizador VRML, o bien un browser HTML que lo soporte (Microsoft Internet Explorer 3.0, por ejemplo).
Pgina 2 de 116
CONSIDERACIONES ACERCA DE LA VERSIN UTILIZADA:
La versin de VRML que se documentar a continuacin es la VRML 2.0, llamada tambin Moving Worlds. Esta versin es el resultado de ms de 8 meses de trabajo por un grupo de ms de 100 personas. El resultado final de esto se conoci el 4 de agosto de 1996.
ESTRUCTURA DE UN ARCHIVO VRML:
Un archivo VRML contiene, bsicamente:

Un encabezado de archivo. Comentarios. Nodos (Nodes): Trozos de informacin escnica del mundo. Campos (Fields): Atributos de los nodos, que pueden ser cambiados. Valores (Values): Valores de atributo. Nombres particulares para nodos: Nombres para nodos reusables.
Todo esto en su conjunto permite definir un mundo tridimensional.

SINTAXIS DE ARCHIVO Y ESTRUCTURA:
SINTAXIS BSICA:
Para una fcil identificacin de un archivo VRML, todos los archivos VRML deben comenzar con la siguiente lnea:
#VRML V2.0 utf8
El identificador utf8 permite que caracteres internacionales sern mostrados en VRML usando la codificacin UTF-8 del estndar ISO 10646. Unicode es una alternativa de codificacin de ISO 10646. El carcter # inicia un comentario, todos los caracteres hasta la nueva lnea o retorno de carro son ignorados. Despus de este encabezado obligatorio, un archivo VRML puede contener lo siguiente:

Prototipos definidos usando PROTO o EXTERNPROTO. Nodos. Declaraciones de rutas (ROUTE).

Pgina 3 de 116
Las siguientes palabras reservadas no pueden ser usadas para los nodos: PROTO, EXTERNPROTO o nombres DEF.
SINTAXIS DE ARCHIVO V/S SINTAXIS DE INTERFACE PBLICA:
La sintaxis de la interface pblica es la especificacin definitiva para los campos, nombres, tipos y valores por defecto para un nodo dado. Notar que esta sintaxis no es la sintaxis del formato del archivo. Sin embargo las partes de la interface que son idnticas en la sintaxis del archivo estn en negrita. Por ejemplo la interface pblica para el nodo Collision es :
Collision { eventIn MFNode addChildren eventIn MFNode removeChildren exposedField MFNode children [] exposedField SFBool collide TRUE field SFVec3f bboxCenter 0 0 0 field SFVec3f bboxSize -1 -1 -1 field SFNode proxy NULL eventOut SFTime collideTime }
Notar que esta informacin es especificada de una forma distinta al usar la sintaxis de archivo. Las palabras reservadas "field" o "exposedField" y los tipos de los campos (como SFColor) no son especificadas cuando expresamos un nodo en el formato de archivo, desde este punto de vista esa informacin es transparente para el diseador de un mundo virtual. El nodo Collision en el formato de archivo queda entonces como:
Collision{ children [ ] collide TRUE bboxCenter 0 0 0 bboxSize -1 -1 -1 proxy NULL }
URLs:
Todos los campos URL son del tipo MFString. Los strings en estos campos indicarn mltiples direcciones hacia las cuales apuntar, en orden decreciente de preferencia. Si el browser no encuentra la primera direccin, entonces va a la siguiente y as sucesivamente.
Pgina 4 de 116
PROTOCOLO PARA LENGUAJES SCRIPT:
El campo url del nodo Script puede soportar un protocolo de varios tipos de lenguajes. Por ejemplo un URL prefijado con javascript puede contener un archivo fuente javascript, con caracteres de nueva lnea permitidos en el string. El siguiente ejemplo muestra algo de sto (el orden de precedencia determina prioridad):
#VRML V2.0 utf8 Script { url [ "javascript: ...", "http://bar.com/foo.js", "http://bar.com/foo.class" ] }
EXTENSIN DEL ARCHIVO Y MIMETYPE:
La extensin de un archivo VRML es .wrl. El MIME type para los archivos VRML es definido como:
model/vrml.
Por razones histricas (VRML 1.0) el siguiente MIME type tambin es soportado:
x-world/x-vrml.
Estos valores deben ser declarados tanto en el cliente (el el browser de la mquina en donde el usuario est viendo la aplicacin), como en el servidor (en donde el root o webmaster deber de especificar los valores en la mquina servidora).
Pgina 5 de 116
EJEMPLO DE UN ARCHIVO VRML:

#VRML V2.0 utf8 , Esto es el encabezado del archivo # Un cilindro; Esto es un comentario Shape { #Inicio de nodo Shape appearance Appearance { #Inicio de nodo Appearance material Material { } # Campo material y nodo Material } # Fin de nodo Appearance geometry Cylinder { # Inicio de nodo Cylinder height 2.0 #Campo heigh, que define la altura del cilindro radius 1.5 #Campo radius que define el radio del cilindro } #Fin de nodo Cylinder } #Fin de nodo Shape.
Pgina 6 de 116
TIPOS DE DATOS:
Un archivo VRML contendr nodos los cuales estn conformados por campos y eventos. Los tipos de datos que se definirn a continuacin son usados tanto por campos como por los eventos. Existen 2 clases de campos y eventos: los que contienen un valor simple (donde ste puede ser un nmero, un vector o una imagen), y los que contienen mltiples valores. Aquellos con valor simple tienen nombres que comienzan con las letras SF, mientras que los que tienen valores mltiples tienen nombres que empiezan con las letras MF. Los campos con mltiples valores son escritos como una serie de valores encerrados con parntesis cuadrados y separados por espacios en blanco (o comas). Si el campo o evento tiene valores cero, entonces slo se escriben los parntesis cuadrados. El ltimo valor puede opcionalmente ser seguido por un espacio en blanco (o coma). Si el campo tiene solamente un valor, los parntesis pueden ser omitidos y slo escribir el valor. Los tipos de datos que se ocupan en un archivo VRML son los siguientes: SFBool; SFColor y MF Color; SFFloat y MFFloat; SFImage; SFInt32 y MFInt32; SFNode y MFNode; SFRotation y SFRotation; SFString y MFString; SFTime; SFVec2f y MFVec2f; SFVec3f y MFVec3f.
SFBool:
Un campo o evento contiene un valor booleano simple. Los valores del campo entonces son TRUE (verdadero) o FALSE (falso). Por ejemplo:
fooBool FALSE
Es un campo SFBool, fooBool designa un valor falso. El valor inicial de un evento de salida (eventOut) SFBool es FALSE.
SFColor/MFColor:
SFColor especifica una tripleta de colores RGB (red-green-blue), y MFColor especifica cero o ms tripletas RGB. Cada color es escrito a un archivo como una
Pgina 7 de 116
tripleta de nmeros en punto flotante en el formato de punto flotante ANSI C, en el rango de 0.0 a 1.0. Por ejemplo:
fooColor [ 1.0 0. 0.0, 0 1 0, 0 0 1 ]
Es un campo MFColor, fooColor, contiene los tres colores primarios rojo, verde y azul. El valor inicial para un eventOut SFColor es (0 0 0). El valor inicial para un eventOut MFColor es [ ].
SFFloat/MFFloat:
SFFloat especifica un nmero simple con precisin de punto flotante, y MFFloat especifica cero o ms nmeros simples con precisin de punto flotante. SFFloat y MFFloat son escritos con el formato de punto flotante de los archivos ANSI C. Por ejemplo:
fooFloat [ 3.1415926, 12.5e-3, .0001 ].
Es un campo MFFloat, fooFloat, conteniendo tres valores de punto flotante. El valor inicial para un eventOut SFFloat es 0.0. El valor inicial de un eventOut MFFloat es [ ].
SFImage:
El campo o evento SFImage define una imagen pixelada bidimencional descomprimida. Los campos y eventos SFImage son escritos como tres enteros representando el ancho, la altura y el nmero de componentes en la imagen, seguidas por valores hexadecimales ancho*altura representando los pixeles en la imagen, separados por un espacio en blanco. fooImage <ancho> <altura> <num componentes> <valores de pixeles> Un primer componente de la imagen especifica un valor de un byte hexadecimal representando la intensidad de la imagen. Por ejemplo, 0xFF es intensidad plena, 0x00 es no intensivo. Un segundo componente de la imagen coloca la intensidad en el primer (alto) byte y el alpha (opaco) en el segundo (bajo) byte. Los pixeles en un tercer componente de la imagen tienen el componente rojo en el primer
Pgina 8 de 116
(alto) byte, seguidos por los componentes verdes y azules (0xFF0000 es rojo). El cuarto componente coloca el byte alpha despus de rojo/verde/amarillo (0x0000FF80 es azul semi-transparente). Un valor 0x00 es completamente transparente, 0xFF es completamente opaco. Cada pixel es leido como un simple nmero sin signo. Por ejemplo un tercer componente pixel con valores 0x0000FF puede tambin ser escrito como 0xFF o 255 (decimal). Los pixels son especificados de izquierda a derecha, abajo hacia arriba. El primer valor hexadecimal es el pixel menor de la izquierda y el ltimo valor es el pixel mayor a la derecha. Por ejemplo:
fooImage 1 2 1 0xFF 0x00
Es un pixel de ancho con 2 pixel de alto, un componente (por ejemplo una escala gris), con el pixel ms bajo blanco y el pixel ms alto negro. Otro ejemplo:
fooImage 2 4 3 0xFF0000 0xFF00 0 0 0 0 0xFFFFFF 0xFFFF00
Es 2 pixel de ancho con 4 pixel de alto, imagen RGB, con el pixel ms bajo de la izquierda rojo, el pixel ms bajo de la derecha verde, las dos hileras del medio de pixeles negros, el pixel ms alto a la izquierda blanco y el pixel ms alto a la derecha amarillo. El valor inicial de un eventOut SFImage es (0 0 0).
SFInt32/MFInt32:
El campo y evento SFInt32 especifican un entero de 32 bits, y el campo y evento MFInt32 especifican cero o ms enteros de 32 bits. Los campos y eventos SFInt32 y MFInt32 son escritos como un entero en los formatos decimal o hexadecimal (comenzando con "0x"). Por ejemplo:
fooInt32 [ 17, -0xE20, -518820 ]
Es un campo MFInt32 conteniendo tres valores.
Pgina 9 de 116
El valor inicial para un eventOut SFInt32 es 0. El valor inicial para un eventOut MFInt32 es [ ].
SFNode/MFNode:
El campo y evento SFNode especifican un nodo VRML, y el campo y evento MFNode especifica cero o ms nodos. El siguiente ejemplo ilustra la sintaxis vlida para un campo MFNode, fooNode, definiendo cuatro nodos.
fooNode [ Transform { translation 1 0 0 } DEF CUBE Box { } USE CUBE USE SOME_OTHER_NODE ]
Los campos y eventos SFNode y MFNode pueden contener la palabra reservada NULL para indicar que estn vacos. El valor inicial de un eventOut SFNode es NULL. El valor inicial de un eventOut MFNode es [ ].
SFRotation/MFRotation:
El campo y evento SFRotation especifica una rotacin arbitraria, y el campo y evento MFRotation especifica cero o ms rotaciones arbitrarias. Estos campos y/o eventos son escritos como cuatro valores de punto flotante separados por espacios en blanco. Los primeros tres valores especifican una rotacin normalizada en el eje acerca del cual la rotacin toma lugar. El cuarto valor especifica el grado de rotacin (regla de la mano derecha) en torno al eje, medido en radianes. Por ejemplo un SFRotation con un grado de rotacin de 180 grados sexagesimales, en torno al eje Y es :
fooRot 0.0 1.0 0.0 3.14159265
El valor inicial de un eventOut SFRotation es (0 0 1 0). El valor inicial de un eventOut MFRotation es [ ].

SFString/MFString:
Los campos y eventos SFString y MFString contienen strings formateados con el conjunto universal de caracteres UTF-8 (ISO/IEC 10646-1:1993,
Pgina 10 de 116
http://www.iso.ch/cate/d18741.html). SFString especifica un string simple y MFString especifica cero o ms strings. Los strings son escritos como una secuencia de UTF-8 octetos encerrados en dobles comillas (ej: "string"). Algunos caracteres (incluyendo retornos de carro y #) pueden aparecer sin las comillas. Para incluir dobles comillas en un string, ste debe ir precedido de un backslash. Para incluir un carcter backslash con el string se deben tipear 2 backslashes. Por ejemplo:
fooString [ "Un, Dos, Tres", "El dice, \"Maaambo!\"" ]
Es un campo MFString, fooString, con 2 strings vlidos. El valor inicial de un eventOut SFString es "". El valor inicial de un eventOut MFRotation es [ ].
SFTime/MFTime:
El campo y evento SFTime especifica un valor simple de tiempo, y el campo y evento MFTime especifican cero o ms valores de tiempo. Estos valores son escritos como un nmero en punto flotante de doble precisin en el formato de punto flotante ANSI C. Los valores de tiempo son especificados como el nmero de segundos desde un tiempo original especificado. Tpicamente los campos y eventos SFTime representan el nmero de segundos desde Jan 1, 1970, 00:00:00 GMT. El valor inicial de un eventOut SFTime es -1. El valor inicial de un eventOut MFTime es [ ].
SFVec2f/MFVec2f:
Un campo o evento SFVec2f especifica un vector bidimensional. Un campo o evento MFVec2f especifica cero o ms vectores bidimensionales. Los SFVec2fs y MFVec2fs son escritos como un par de valores en punto flotante separados por un espacio en blanco. Por ejemplo:
fooVec2f [ 42 666, 7, 94 ]
Es un campo MFVec2f, fooVec2f, con dos vectores vlidos.

Pgina 11 de 116
El valor inicial de un eventOut SFVec2f es (0 0). El valor inicial de un eventOut MFVec2f es [ ].

SFVec3f/MFVec3f:
Un campo o evento SFVec3f especifica un vector tridimensional. Un campo o evento MFVec3f especifica cero o ms vectores bidimensionales. Los SFVec3fs y MFVec3fs son escritos como tres valores en punto flotante separados por un espacio en blanco. Por ejemplo:
fooVec3f [ 1 42 666, 7, 94, 0 ]
Es un campo MFVec3f, fooVec3f, con dos vectores vlidos. El valor inicial de un eventOut SFVec3f es (0 0 0). El valor inicial de un eventOut MFVec3f es [ ].
Pgina 12 de 116
NODOS:
INTRODUCCIN A LOS NODOS:
En un alto nivel de abstraccin, VRML es un formato de archivo simple para la descripcin de objetos. Tericamente, los objetos pueden contener cualquier cosa (figuras geomtricas en 3 dimensiones, datos MIDI, imgenes JPEG, etc. VRML define un conjunto de objetos tiles para grficas 3d y la construccin de objetos y/o mundos interactivos. Estos objetos son llamados nodos, y contienen datos los cuales son guardados en campos.
CARACTERSTICAS GENERALES DE LOS NODOS:
Un nodo tiene las siguientes caractersticas:

Un nombre de tipo: este nombre puede ser como Box, Sphere, Sound, SpotLight, etc. Parmetros que distinguen a un nodo de otros del mismo tipo. Por ejemplo cada nodo Sphere, podr tener radios (valores de campo radius) diferentes. Estos parmetros son llamados campos. Un nodo puede tener 0 o ms campos . Cada especificacin de un nodo define el tipo, nombre y valores por defecto para cada uno de estos campos. El valor por defecto del campo es usado si un valor para ste no es especificado en el archivo VRML. El orden en que los campos de un nodo son ledos no es importante. Un conjunto de eventos asociados que los nodos reciben y envan. Los nodos pueden recibir un nmero de eventos de entrada set_events, denotados como eventIn, (tales como set_position, set_color y set_on), los cuales tpicamente cambian al nodo. Los nodos pueden tambin enviar un nmero de eventos _changed denotados como eventOut, los cuales indican que algunas cosas en el codo han sido cambiadas (por ejemplo position_changed, color_changed, on_changed). La palabra clave exposedField puede ser usada como un atajo para especificar que un campo dado que tiene un set_eventIn que es directamente encadenado a un valor de campo y a un _changed eventOut. Por ejemplo la declaracin:
Pgina 13 de 116
exposedField foo
es equivalente a la declaracin:
eventIn set_foo field foo eventOut foo_changed
La sintaxis para la representacin de este tipo de informacin es: Tipo de nodo {campos} Slo se requiere el tipo de nodo y los parntesis, los nodos pueden no tener especificados los valores de los campos. Cuando un valor de campo no es especificado se toman los valores por defecto.
NODOS DE GEOMETRA:
Box:
Box { field SFVec3f size 2 2 2 }
Este nodo dibuja una caja rectangular alineada con el eje coordenado. Por defecto esta caja est ubicada en el centro del eje coordenado (0,0,0), y con cada dimensin midiendo 2 unidades, desde -1 a +1.
CAMPO size:
field SFVec3f size 2 2 2.
Este campo especifica los valores del tamao de los lados del rectngulo en el orden (X,Y,Z). Y
Pgina 14 de 116
Ejemplo:
Box{ size 2.0 0.5 3.0 }
Cone:
Cone { field field field field }
SFFloat bottomRadius 1 SFFloat height 2 SFBool side TRUE SFBool bottom TRUE
Este nodo especifica un cono. Por defecto el cono se encontrar en el centro del eje tridimensional (0,0,0). y tendr un tamao que ir de -1 a +1 en las tres dimensiones del espacio.
CAMPO bottomRadius:
field SFFloat bottomRadius 1
Este campo especifica el valor del radio basal del cono.

CAMPO height:
field SFFloat height 2
Este campo especifica el valor de la altura del cono.

CAMPO side:
field SFBool side TRUE
Este campo especifica una parte del cono (el manto), si el valor es TRUE, entonces ser visible, si es FALSE, entonces no lo ser.
CAMPO botton:
field SFBool bottom TRUE
Pgina 15 de 116
Este campo especifica una parte del cono (la base), si el valor es TRUE, entonces ser visible, si es FALSE, entonces no lo ser. Ejemplo:
Cone{ heigh 3.0 bottonRadious 0.75 }
Cylinder:
Cylinder { field SFBool bottom TRUE field SFFloat height 2 field SFFloat radius 1 field SFBool side TRUE field SFBool top TRUE }
Este nodo especifica un cilindro alrededor del eje X. Por defecto el cilindro se encuentra en el centro del eje tridimensional, y un tamao que va desde -1 a +1. El cilindro tiene tres partes: manto, tope (Y=+1) y base (Y=-1).
CAMPO botton:
field SFBool bottom TRUE
Este campo especifica una parte del cilindro (la base), si el valor es TRUE, entonces ser visible, si es FALSE, entonces no lo ser.
CAMPO heigh:
field SFFloat height 2
Este campo especifica el valor de la altura del cilindro.

CAMPO radius:
field SFFloat radius 1
Este campo especifica el valor del radio del cono.

Pgina 16 de 116
CAMPO side:
field SFBool side TRUE
Este campo especifica una parte del cilindro (el manto), si el valor es TRUE, entonces ser visible, si es FALSE, entonces no lo ser.
CAMPO top:
field SFBool top TRUE
Este campo especifica una parte del cilindro (el tope), si el valor es TRUE, entonces ser visible, si es FALSE, entonces no lo ser. Ejemplo:
Cylinder{ height 2.0 radius 1.5 }
SPHERE:
Sphere { field SFFloat radius 1 }
Este nodo especifica una esfera. Por defecto la esfera es centrada en el origen, el valor del radio es 1.
CAMPO radius:
field SFFloat radius 1
Este campo especifica el valor del radio de la esfera. Ejemplo:

Sphere{ radius 1.0 }
Pgina 17 de 116
ElevationGrid:
ElevationGrid { eventIn MFFloat set_height exposedField SFNode color NULL exposedField SFNode normal NULL exposedField SFNode texCoord NULL field MFFloat height [] field SFBool ccw TRUE field SFBool colorPerVertex TRUE field SFFloat creaseAngle 0 field SFBool normalPerVertex TRUE field SFBool solid TRUE field SFInt32 xDimension 0 field SFFloat xSpacing 0.0 field SFInt32 zDimension 0 field SFFloat zSpacing 0.0 }
Este nodo crea una rejilla rectangular uniforme de altura variable en el plano XZ. La geometra es descrita por medio de un arreglo de valores de altura que especifican la altura de la superficie rectangular por encima de cada punto de la rejilla. Este nodo es ideal para crear efectos tales como cadenas montaosas, superficies marinas o superficies planetarias, por ejemplo.
Campos xDimension y zDimension:
field SFInt32 xDimension 0 field SFInt32 zDimension 0
Estos campos indican las dimensiones de la altura de la rejilla en las direcciones X y Z.

Campo height:
field MFFloat height []
Este campo es un arreglo de valores escalares X por Y, que representan la altura por encima de la rejilla para cada vrtice.
Campos xSpacing y zSpacing:
field SFFloat xSpacing 0.0 field SFFloat zSpacing 0.0
Pgina 18 de 116
Estos campos indican la distancia entre los vrtices en las direcciones X y Z respectivamente. De esta manera el vrtice correspondiente al punto P[i, j], en la grilla es puesto como:
P[i,j].x = xSpacing * i P[i,j].y = height[ i + j * zDimension] P[i,j].z = zSpacing * j
Donde 0<i<xDimencion y 0<j<zDimencion.

Campo colorPerVertex:
field SFBool colorPerVertex TRUE
Este campo determina si los colores (si estn especificados en el campo color) pueden ser aplicados a cada vrtice o a cada cuadriltero del ElevationGrid. Si colorPerVertex es FALSE y el campo color no es NULL, entonces el campo color debe contener un nodo Color conteniendo al menos (xDimension1)*(zDimension-1) colores. Si colorPerVertex es TRUE y el campo color no es NULL, entonces el campo color debe contener un nodo Color conteniendo al menos xDimension*zDimension colores.
Campo ccw:
field SFBool ccw TRUE
Este campo indica si los vrtices son ordenados en el sentido horario cuando la figura es vista desde el exterior (TRUE). Si el orden es antihorario o desconocido, el valor del campo es FALSE.
Campo solid:
field SFBool solid TRUE
Este campo indica si la figura circundada es un volumen (TRUE). Si el valor del campo es FALSE implica que la figura en relieve no puede ser presentada y que el polgono tiene dos lados.
Campo creaseAngle:
field SFFloat creaseAngle 0
Pgina 19 de 116
Este campo afecta como las normas por defecto son generadas. El creaseAngle es el ngulo entre las superficies normales en polgonos adyacentes.
Evento set_height:
eventIn MFFloat set_height
Este evento permite que el campo height pueda ser cambiado, permitiendo ElevationGrids animados. Ejemplo:
ElevationGrid { xDimension 3 xSpacing 1.0 zDimension 2 zSpacing 1.0 height [0.0, -0.5, 0.0, 0.2, 4.0, 0.0] }
Extrusion:
Extrusion { eventIn MFVec2f set_crossSection eventIn MFRotation set_orientation eventIn MFVec2f set_scale eventIn MFVec3f set_spine field SFBool beginCap TRUE field SFBool ccw TRUE field SFBool convex TRUE field SFFloat creaseAngle 0 field MFVec2f crossSection [ 1 1, 1 -1, -1 -1, -1 1, 1 1 ] field SFBool endCap TRUE field MFRotation orientation 0 0 1 0 field MFVec2f scale 1 1 field SFBool solid TRUE field MFVec3f spine [ 0 0 0, 0 1 0 ] }
Este nodo es usado para definir figuras basadas en un corte transversal en dos dimensiones estirado a lo largo de una columna tridimensional. El corte transversal puede ser escalado y rotado en cada uno de los puntos de la columna para producir una amplia variedad de figuras.
Pgina 20 de 116
Ejemplo:
Extrusion{ crossSection [1.0 0.0 ... ] spine [10.0 0.0 0.0 ... ]
IndexedFaceSet:
IndexedFaceSet { eventIn MFInt32 set_colorIndex eventIn MFInt32 set_coordIndex eventIn MFInt32 set_normalIndex eventIn MFInt32 set_texCoordIndex exposedField SFNode color NULL exposedField SFNode coord NULL exposedField SFNode normal NULL exposedField SFNode texCoord NULL field SFBool ccw TRUE field MFInt32 colorIndex [] field SFBool colorPerVertex TRUE field SFBool convex TRUE field MFInt32 coordIndex [] field SFFloat creaseAngle 0 field MFInt32 normalIndex [] field SFBool normalPerVertex TRUE field SFBool solid TRUE field MFInt32 texCoordIndex [] }
Este nodo dibuja una figura utilizando caras (polgonos) definidas por un conjunto de puntos.
Campo coord:
exposedField SFNode coord NULL
Este campo debe contener un nodo Coordinate.

Campo coordIndex:
field MFInt32 coordIndex []
Los ndices de este campo sirven para especificar las caras del polgono. Un ndice de -1 indica que la cara actual ha sido terminada y la prxima comienza. La ltima cara puede (pero no tiene que ser as) seguida por un -1. Si el nmero de ndices en el campo ccordIndex es N, entonces el nodo Coordinate debe contener N+1 coordenadas (indexadas como 0-N).
Pgina 21 de 116
Campo color:
exposedField SFNode color NULL
Si este campo no es NULL, entonces debe contener un nodo Color, cuyos colores son aplicados a los vrtices o caras de IndexedFaceSet como sigue:

Si colorPerVertex es FALSE, los colores son aplicados a cada cara como sigue: Si el campo colorIndex no est vaco entonces deben ser escogidos a usar un color por cada cara del IndexedFaceSet. Estos deben ser al menos tantos ndices en el campo colorIndex como caras son en el IndexedFaceSet.Si los ndices en el campo colorIndex son N, entonces deben haber N+1 colores en el nodo Color. El campo colorIndex no debe contener entradas negativas. Si el campo colorIndex es vaco, entonces los colores son aplicados a cada cara del IndexedFaceSet en orden. Estos deben ser al menos tantos colores en el nodo Color como caras existan. Si colorPerVertex es TRUE, los colores son aplicados a cada vrtice como sigue: Si el campo colorIndex no es vaco, entonces ste es usado para elegir colores para cada vrtice del IndexedFaceSet en exactamente la misma manera que el campo coordIndex es usado para elegir coordenadas para cada vrtice desde el nodo Coordinate. El campo colorIndex debe contener al menos tantos ndices como el campo coordIndex, y debe contener los fines de las caras marcados en exactamente los mismos lugares como los campos coorIndex. Si el ndice en el campo colorIndex es N, entonces deben haber N+1 colores en el nodo Color. Si el campo colorIndex es vaco entonces el campo coordIndex es usado para elegir colores desde el nodo Color. Si el ndice en el campo coordIndex es N, entonces deben haber N+1 colores en el nodo Color.
Campo normal:
exposedField SFNode normal NULL
Si este campo es NULL, entonces el browser puede automticamente generar nodos Normal, usando creaseAngle para determinar si y como sus vectores sern alisados a travs de los vrtices formados.
Pgina 22 de 116
Si este campo no es NULL, entonces debe contener un nodo Normal, cuyos vectores son aplicados a los vrtices o caras del IndexedFaceSet en una manera exactamente equivalente a como se describe abajo para la aplicacin de colores a vrtices/caras.
Campo texCoord:
exposedField SFNode texCoord NULL
Si el campo texCoord no es NULL, entonces debe contener un nodo TextureCoordinate, las coordenadas de textura en este nodo son aplicadas a los vrtices del IndexedFaceSet como sigue:
Si el campo texCoordIndex no es vaco, entonces ste es usado para elegir coordenadas de textura para cada vrtice del IndexedFaceSet en exactamente la misma forma que el campo coordIndex es usado para elegir coordenadas para cada vrtice desde el nodo Coordinate. El campo texCoordIndex debe contener al menos tantos ndices como el campo coordIndex, y debe contener los finales de cara marcados (-1) en exactamente la misma forma como el campo coordIndex. Si el ndice en el campo texCoordIndex es N, entonces deben haber N+1 coordenadas de textura en el nodo TextureCoordinate. Si el campo texCoordIndex es vaco, entonces el arreglo coordIndex es usado para elegir coordenadas de textura desde el nodo TextureCoordinate. Si el ndice en el campo coordIndex es N, entonces deben haber N+1 coordenadas de textura en el nodo TextureCoordinate.
Si el campo texCoord es NULL, un mapeamiento de una coordenada de textura es calculado usando una caja atada a la figura.
Campo convex:
field SFBool convex TRUE
Este campo indica si todas las caras en la figura son convexas (TRUE). Si nada se conoce acerca de las caras, este campo es FALSE. Ejemplo:
IndexedFaceSet{ coord Coordinate {...}
Pgina 23 de 116
coordIndex[...] color Color{ Color[1.0 0.0 0.0 ... ] } colorIndex [3,0,1,... ] colorPerVertex TRUE }
IndexedLineSet:
IndexedLineSet { eventIn MFInt32 set_colorIndex eventIn MFInt32 set_coordIndex exposedField SFNode color NULL exposedField SFNode coord NULL field MFInt32 colorIndex [] field SFBool colorPerVertex TRUE field MFInt32 coordIndex [] }
Este nodo dibuja una figura utilizando lneas definidas por un conjunto de puntos.
Campo Coord:
exposedField SFNode coord NULL
Este campo lista los vrtices para la construccin de lneas.

Campo coordIndex:
field MFInt32 coordIndex []
Pgina 24 de 116
Este campo posee ndices que especifican las lneas. Un ndice -1 indica que la lnea actual ha finalizado y comienza la siguiente. La ltima lnea puede (pero no tiene que ser as) ser seguida por un -1.
Campo color:
exposedField SFNode color NULL
Si este campo no es NULL, debe contener un nodo color, y los colores son aplicados a la lnea o lneas como sigue:

Si colorPerVertex es FALSE: Si el campo colorIndex no es vaco entonces un color es usado para cada lnea del IndexedLineSet. Estos deben ser al menos tantos ndices en el colorIndex como lneas en el IndexedLineSet. Si el ndice en el campo colorIndex es N, entonces deben haber N+1 colores en el nodo Color. El campo colorIndex no debe contener entradas negativas. Si el campo colorIndex es vaco, entonces los colores son aplicados a cada lnea del IndexedLineSet en orden. Debe haber al menos tantos colores en el nodo Color como lneas. Si colorPerVertex es TRUE: Si el campo colorIndex no es vaco entonces los colores son aplicados a cada vrtice del IndexedLineSet en exactamente la misma forma que el campo coordIndex es usado para proveer coordenadas para cada vrtice desde el nodo Coordinate. El campo colorIndex debe contener al menos tantos ndices como el campo coordIndex y debe contener un fin de lnea marcado (-1) en exactamente los mismos lugares como el campo coordIndex. Si el ndice en el campo colorIndex es N, entonces deben haber N+1 colores en el nodo Color.
Si el campo colorIndex es vaco, entonces el campo coordIndex es usado para elegir colores desde el nodo Color. Si el ndice en el campo coordIndex es N, entonces deben haber N+1 colores en el nodo Color. Ejemplo:
IndexedLineSet{ coord Coordinate{ point [...]
Pgina 25 de 116
} coordIndex [1,0,3,-1, ... ] }
PointSet:
PointSet { exposedField SFNode color NULL exposedField SFNode coord NULL }
Este nodo especifica una figura usando un conjunto de puntos. Estos puntos estn contenidos en el campo coord.
CAMPO coord:
Este campo debe ser un nodo Coordinate (o una instancia del nodo Coordinate).
CAMPO color:
Si este campo no es NULL, deber contener un nodo Color que contenga al menos el nmero de puntos contenido en el nodo coord. Estos campos (color) son siempre aplicados a cada punto en orden.
Text:
Text { exposedField MFString string [] exposedField SFNode fontStyle NULL exposedField MFFloat length [] exposedField SFFloat maxExtent 0.0 }
Este nodo representa una o ms cadenas de texto.
Pgina 26 de 116
CAMPO string:
Este campo contiene las cadenas de texto.

CAMPO fontStyle:
Este campo contiene un nodo FontStyle que especifica el tamao del tipo de letra, su familia y estilo, direccin de la cadena de texto y alguna especificacin de las tcnicas de renderizacin que deben ser usadas para el texto.
CAMPO length:
Este campo contiene un valor MFFloat que especifica el largo de cada cadena de texto en el espacio coordenado local. Si la cadena es demasiado corta, esta es estirada, si es demasiado larga es comprimida.
CAMPO maxExtent:
Este campo limita y escala la cadena de texto, si el largo natural de la cadena es larga, en comparacin a la extencin mxima. Si la cadena de texto es corta en comparacin a la extencin mxima, no es cambiada. La extensin mxima es medida horizontalmente para los textos horizontales (FontStyle: horizontal=TRUE) y verticalmente para los textos verticales (FontStyle: horizontal=FALSE). Ejemplo:
Text{ string ["HOY OFERTA", "LLEVE 2 y PAGUE 3"] }
NODOS DE AGRUPACIN:
Anchor:
Anchor { eventIn MFNode addChildren eventIn MFNode removeChildren exposedField MFNode children []
Pgina 27 de 116
exposedField SFString description "" exposedField MFString parameter [] exposedField MFString url [] field SFVec3f bboxCenter 0 0 0 field SFVec3f bboxSize -1 -1 -1 }
Este nodo crea un grupo de nodos hijos, los cuales son mostrados en su totalidad, seleccionando algn nodo hijo podemos saltar a un mundo VRML especificado por una determinada URL. En ese caso el mundo es cargado y mostrado en lugar de ste del cual el nodo Anchor es parte. La seleccin de los nodos hijos es hecha (con el browser VRML corriendo) haciendo click en uno de ellos y de esta manera el resultado ser una nueva escena que reemplazar a la anterior.
Campo description:
exposedField SFString description ""
Este campo permite escribir una descripcin acerca de la alternativa que se est eligiendo en ese momento al por ejemplo pulsar aquel nodo. Ejemplo:
Anchor {url "ejemplo.wrl" description "un ejemplo" children [...] }
Billboard:
Billboard { eventIn MFNode addChildren eventIn MFNode removeChildren exposedField SFVec3f axisOfRotation 0 1 0 exposedField MFNode children []
Pgina 28 de 116
field SFVec3f bboxCenter 0 0 0 field SFVec3f bboxSize -1 -1 -1 }
Este nodo crea un grupo con un sistema de coordenadas especiales. Aqu todos los nodos hijos son mostrados. El sistema de coordenadas es girado de tal forma que siempre las caras estn a la vista.
Campo axisOfRotation:
exposedField SFVec3f axisOfRotation 0 1 0
Este campo especifica cual eje va a ser usado para procesar la rotacin. Este eje es definido. Este eje es definido en las coordenadas locales del nodo billboard. El valor por defecto (0,1,0) es usado para objetos tales como arboles y postes, que estn posicionados sobre un plano recto. Pero si un objeto est orientado en torno a un ngulo, por ejemplo una montaa inclinada, entonces este eje puede tambin necesitar ser orientado en un ngulo similar. Un caso especial de esto es cuando tenemos que los objetos rotan y siempre estn alineados con la cmara (el observador) cuando sta se eleva, inclina o rota. Este caso especial se denota con el valor en el campo axisOfRotation (0,0,0). Ejemplo:
Group{ children[ Billboard{ axisOfRotation 0.0 1.0 0.0 children[...] } Transform {...} ] }
Collision:
Collision {
Pgina 29 de 116
eventIn MFNode addChildren eventIn MFNode removeChildren exposedField MFNode children [] exposedField SFBool collide TRUE field SFVec3f bboxCenter 0 0 0 field SFVec3f bboxSize -1 -1 -1 field SFNode proxy NULL eventOut SFTime collideTime }
Por defecto todos los objetos de una escena son colisionables, por lo tanto la deteccin de colisiones est siempre presente. El nodo Collision se comporta exactamente igual al nodo Group, con el agregado que permite especificar objetos alternativos a usar para la deteccin de colisiones. La colisin en este caso es entendida como aquel caso en que en una escena un objeto puede tapar a otro.
Campo collide:
exposedField SFBool collide TRUE
Este campo activa la deteccin de colisiones (prende y apaga). Si su valor es FALSE, entonces los hijos y sus descendientes no detectarn las colisiones, para que si sean detectadas el valor debe estar en TRUE.
Campo proxy:
field SFNode proxy NULL
Este campo define una colisin proxy, que es un grupo o un nodo hoja que es usado como un sustituto delos nodos hijos de la colisin durante la deteccin de stas. Proxy es usado slo para la deteccin de colisiones, si existen nodos que no son de geometra son ignorados.
Evento collideTime:
eventOut SFTime collideTime
Pgina 30 de 116
Genera un evento especificando el tiempo cuando el usuario intersecta los nodos colisionables o proxy del nodo Collision. Los browsers sern los encargados de definir que ocurre cuando el usuario navega en un objeto colisionable. Por ejemplo cuando el usuario est lo demasiado cerca de un objeto como para activar una colisin, el browser puede hacer que el usuario rebote, o se deslice a lo largo de la superficie.
Group:
Group { eventIn MFNode addChildren eventIn MFNode removeChildren exposedField MFNode children [] field SFVec3f bboxCenter 0 0 0 field SFVec3f bboxSize -1 -1 -1 }
Este nodo crea un grupo conformado por un nmero cualquiera de nodos hijos. Este nodo es equivalente al Transform, sin los campos de transformacin.
Transform:
Transform { eventIn MFNode addChildren eventIn MFNode removeChildren exposedField SFVec3f center 0 0 0 exposedField MFNode children [] exposedField SFRotation rotation 0 0 1 0 exposedField SFVec3f scale 1 1 1 exposedField SFRotation scaleOrientation 0 0 1 0 exposedField SFVec3f translation 0 0 0 field SFVec3f bboxCenter 0 0 0
Pgina 31 de 116
field SFVec3f bboxSize -1 -1 -1 }
Este nodo crea un grupo, como el nodo Group, pero adems define un sistema de coordenadas para los nodos hijos que es relativo al sistema de coordenadas de los padres.
Campo translation:
exposedField SFVec3f translation 0 0 0
Este campo permite una traslacin de una figura geomtrica tridimensional consistente de una escala no uniforme en torno a un punto arbitrario.
Campo rotation:
exposedField SFRotation rotation 0 0 1 0
Este campo especifica una rotacin del sistema de coordenadas, en torno a un punto y un eje.
Campo scale:
exposedField SFVec3f scale 1 1 1
Este campo especifica una escala no uniforme para el sistema coordenado.

Campo center:
exposedField SFVec3f center 0 0 0
Este campo especifica una traslacin desde el origen del sistema de coordenadas local (0,0,0).
Campo scaleOrientation:
exposedField SFRotation scaleOrientation 0 0 1 0
Este campo especifica una rotacin del sistema de coordenadas antes de escalarlo (al especificar escalas en orientaciones arbitrarias). Este campo se aplica slo en la operacin de especificar una escala. Ejemplo:
Transform{
Pgina 32 de 116
translation 4.0 0.0 0.0 rotation 0.0 1.0 0.0 0.785 scale 0.5 0.5 0.5 children [...] }
NODOS ESPECIALES DE AGRUPACIN:

Inline:
Inline { exposedField MFString url [] field SFVec3f bboxCenter 0 0 0 field SFVec3f bboxSize -1 -1 -1 }
Este nodo es similar a Group, pero crea un grupo especial. Los nodos hijos son ledos desde otro archivo VRML, seleccionado por medio de una URL. Todos los nodos hijo en el grupo son mostrados. Ejemplo:
Inline{ url "mesa.wrl" }
LOD:
LOD {
Pgina 33 de 116
exposedField MFNode level [] field SFVec3f center 0 0 0 field MFFloat range [] }
Este nodo es usado para permitir que los browsers puedan pasar entre varias representaciones de objetos automticamente. Con este nodo podemos por ejemplo reducir el tiempo de carga de un archivo, al cargar primero los modelos simples; y adems podemos mejorar la calidad de la estructura general del archivo, al usar modelos simples para objetos muy alejados.
Campo level:
exposedField MFNode level []
Este campo contiene nodos que representan el mismo objeto u objetos en varios niveles de detalle, desde el alto al bajo nivel de detalle.
Switch:
Switch { exposedField MFNode choice [] exposedField SFInt32 whichChoice -1 }
Este nodo define a un grupo de nodos y slo dibuja a un miembro de ese grupo, que ha sido previamente seleccionado.
Campo whichChoise:
exposedField SFInt32 whichChoice -1
Este campo especifica el ndice del nodo hijo a atravesar, donde el primer nodo hijo tiene ndice 0. Si este valor es menor que cero o mayor que el nmero de nodos en el campo choise, entonces ninguno es elegido. Ejemplo:
LOD{ range [...]
Pgina 34 de 116
center 0 0 0 level[...] }
NODOS DE LAZO (COMPLEMENTO):

Background:
Background { eventIn SFBool set_bind exposedField MFFloat groundAngle [] exposedfield MFColor groundColor [] exposedField MFString backUrl [] exposedField MFString bottomUrl [] exposedField MFString frontUrl [] exposedField MFString leftUrl [] exposedField MFString rightUrl [] exposedField MFString topUrl [] exposedField MFFloat skyAngle [] exposedField MFColor skyColor [ 0 0 0 ] eventOut SFBool isBound }
Este nodo es usado para especificar un color que simule cielo y tierra o un panorama que es empleado detrs de toda la geometra en la escena y en frente de el cielo y la tierra.
Campo skyColor:
exposedField MFColor skyColor [ 0 0 0 ]
Este campo especifica el color del cielo en los diversos ngulos de la esfera del crculo. El primer valor de este campo especifica el color del cielo en 0.0 grados sexagesimales (desde el punto de vista del observador).
Pgina 35 de 116
Campo skyAngle:
exposedField MFFloat skyAngle []
Este campo especifica los ngulos desde el polo norte, en los cuales crculos concntricos de color aparecen. El polo norte de la esfera es implcitamente definido en los 0.0 grados, el horizonte como pi/2 radianes y el polo sur como pi radianes. skyAngle va en el rango de 0.0 a pi radianes.
Campo groundColor:
exposedfield MFColor groundColor []
Este campo especifica el color del piso en los diversos ngulos de la esfera del piso. El primer valor de este campo especifica el color del piso en 0.0 grados sexagesimales, el polo sur.
Campo groundAngle:
exposedField MFFloat groundAngle []
Este campo especifica los ngulos del polo sur, donde los crculos concntricos de color aparecen. El polo sur de la esfera es implcitamente definido como 0.0 grados y con restriccin desde 0.0 a pi. El primer valor de color es para el polo sur, el cual no es especificado en el campo groundAngle. Si el ltimo valor de groundAngle es menor que pi , entonces la regin entre el ltimo groundAngle y el polo norte es invisible.
Campos backUrl, bottonUrl, frontUrl, leftUrl, rigthUrl, topUrl:
exposedField MFString backUrl [] exposedField MFString bottomUrl [] exposedField MFString frontUrl [] exposedField MFString leftUrl [] exposedField MFString rightUrl [] exposedField MFString topUrl []
Estos campos especifican un grupo de imgenes que definen un panorama de fondo, en el escenario creado. El panorama consiste de 6 imgenes.
Pgina 36 de 116
Frecuentemente las imgenes bottonUrl y topUrl no son especificadas, las cuales permiten definir un piso y un cielo a mostrar. Las otras cuatro nos pueden servir para especificar montaas u otros escenarios distantes. Por defecto no existen imgenes de panorama. Los Browsers requieren soportar los formatos de archivo JPEG, PNG y GIF, los cuales sern referenciados por url. El primer nodo Background encontrado durante la lectura del archivo wrl es usado como el fondo original cuando el archivo est cargado (evento set_bind TRUE). Ejemplo:
Background{ groundColor [0.14 0.28 0, 0.09 0.11 0] groundAngle[0.785] skyColor[0.02 0 0.26, 0.2 0 0.65] skyAngle[0.785] #Especificacin de un ambiente
Fog:
Fog { exposedField SFColor color 1 1 1 exposedField SFString fogType "LINEAR" exposedField SFFloat visibilityRange 1000 eventIn SFBool set_bind eventOut SFBool isBound }
Este nodo es un efecto especial que permite la simulacin de atmsferas con el color especificado por el campo color, este efecto (de un cierto desteido) ir dado por las distancias de los objetos, con respecto al observador.
Campo visibilityRange:
exposedField SFFloat visibilityRange 1000
Pgina 37 de 116
Este campo especifica la distancia (en el espacio coordenado del nodo Fog), en la cual los objetos son totalmente oscurecidos por la penumbra. Un valor de visibilityRange de 0.0 o menos desabilita el nodo Fog.
Campo fogType:
exposedField SFString fogType "LINEAR"
Este campo controla cuanto del color de la niebla es combinado con el objeto como una funcin de distancia. Si el valor es "LINEAR" (el valor por defecto), entonces la combinacin es una funcin lineal de la distancia, resultando un efecto de profundidad. Si el valor es "EXPONENTIAL", entonces se toma una funcin exponencial como incremento, resultando una apariencia de niebla ms natural. Para mejores resultados visuales, el nodo Background (el cual no es afectado por el nodo Fog), puede tener el mismo color del nodo Fog.
NavigationInfo:
NavigationInfo { eventIn SFBool set_bind exposedField MFFloat avatarSize [ 0.25, 1.6, 0.75 ] exposedField SFBool headlight TRUE exposedField SFFloat speed 1.0 exposedField MFString type "WALK" exposedField SFFloat visibilityLimit 0.0 eventOut SFBool isBound }
Este nodo da indicaciones al browser (sugerencias) VRML acerca del mejor camino para navegar en el mundo y el mejor tamao y velocidad para el observador. El tamao del observador es importante para la deteccin de colisiones.
campo Type:
exposedField MFString type "WALK"
Pgina 38 de 116
Este campo especifica el tipo de navegacin a usar en el mundo. Los tipos que todos los visualizadores VRML pueden soportar son: "WALK", "EXAMINE", "FLY", y "NONE". En WALK el explorador estar sintindose como que est caminando en el interior del mundo virtual. EXAMINE es usado generalmente para ver objetos individuales. FLY da la idea de estar volando en el interior del mundo virtual, no estn los pies en tierra.
Campo avatarSize:
exposedField MFFloat avatarSize [ 0.25, 1.6, 0.75 ]
Este campo especifica parmetros a usar para determinar las dimensiones del visualizador, con el propsito del manejo de deteccin de colisiones. El primer valor permite establecer la distancia permitida entre la posicin del usuario y alguna colisin geomtrica (especificada por colisin), antes de que la colisin sea detectada. El segundo valor establece la altura por encima del terreno, en que la cmara puede ser mantenida. El tercer valor establece la altura de objetos sobre los cuales la cmara puede pasar.
Campo visibilityLimit:
exposedField SFFloat visibilityLimit 0.0
Este campo setea la distancia ms lejana en la cual el visualizador puede ver. El valor 0.0 (el por defecto), indica un limite de visibilidad infinito.
Campo headlight:
exposedField SFBool headlight TRUE
Este campo especifica si un browser puede encender un headlight. Un headligth es una luz direccionada en la que siempre los puntos que caen en la direccin del usuario son vistos. El valor TRUE permite al browser tener un headligth, posiblemente usando su propia interface de control para encendido y apagado. El headligth puede tener intensidad 1, color 1 1 1, y direccin 0 0 -1. Ejemplo:
NavigationInfo{ avatarSize [0.25, 1.6, 0.75]
Pgina 39 de 116
headlight TRUE speed 1.0 type "WALK" }
Viewpoint:
Viewpoint { eventIn SFBool set_bind exposedField SFFloat fieldOfView 0.785398 exposedField SFBool jump TRUE exposedField SFRotation orientation 0 0 1 0 exposedField SFVec3f position 0 0 0 field SFString description "" eventOut SFTime bindTime_changed eventOut SFBool isBound }
Este nodo define una ubicacin especifica en un sistema de coordenadas local desde el cual el usuario puede ver la escena. Los browsers VRML pueden presentar una lista de Viewpoints, usando sus strings de descripcin.
Campos position y orientation:
exposedField SFVec3f position 0 0 0 exposedField SFRotation orientation 0 0 1 0
Estos campos especifican ubicaciones relativas en el sistema de coordenadas; position es relativa al origen del sistema de coordenadas (0,0,0), mientras que orientation especifica una orientacin relativa a la orientacin por defecto.
Campo jump:
exposedField SFBool jump TRUE
Pgina 40 de 116
Este campo especifica si el browser usa vistas "saltadas" (o animadas) en la posicin y orientacin del Viewpoint
Campo fieldOfView:
exposedField SFFloat fieldOfView 0.785398
Este campo especifica un campo preferido de vista desde el punto de vista en el que el nodo Viewpoint est actuando, este valor es dado en radianes. El rango de este valor es mayor que cero y menor que pi; el valor por defecto corresponde a 45 grados sexagesimales.
Campo description:
field SFString description ""
Este campo identifica Viewpoints que son recomendados para ser pblicamente accesables a travs de la interfaz de usuario del browser (ej. Viewpoints men). El string de este campo puede ser mostrado, si esta funcin es implementada. Esto es recomendado con el objeto que el browser se mueva hacia aquel Viewpoint, cuando la descripcin es seleccionada. El primer Viewpoint encontrado en el archivo es automticamente tomado (recibido un evento set_bind TRUE) y es usado como la posicin inicial del usuario cuando ha penetrado al mundo virtual. La expresin URL ".../scene.wrl#ViewpointName" especifica que el usuario inicialmente cuando entre a "scene.wrl", el primer Viewpoint que ver ser aquel definido como "DEF ViewpointName Viewpoint { ... }". Ejemplo:
Viewpoint{ position 0 0 10 orientation 0 0 10 description "Valores por defecto" }
Pgina 41 de 116
NODOS DE APARIENCIA:
Appearance:
Appearance { exposedField SFNode material NULL exposedField SFNode texture NULL exposedField SFNode textureTransform NULL }
Este nodo especifica las propiedades visibles de geometra por medio de la definicin de los nodos material y texture. El valor para algunos de los campos en estos nodos puede ser NULL. Sin embargo si el valor del campo no es NULL, ste debe contener un tipo especfico de nodo.
Campo material:
exposedField SFNode material NULL
Este campo si es especificado, debe contener un nodo Material. Si el campo es NULL o no especificado, la iluminacin se apaga. (todas las luces son ignoradas durante la renderizacin del objeto que referencia Appearance).
Campo texture:
exposedField SFNode texture NULL
Este campo, si es especificado, debe contener uno de los varios tipos de nodos de textura (ImageTexture, MovieTexture, PixelTexture). Si este nodo es NULL o no especificado, el objeto que referencia Appearance no es texturizado.
Campo textureTransform:
exposedField SFNode textureTransform NULL
Este campo si es especificado, debe contener un nodo TextureTransform. Si este campo es NULL o no especificado, o si el campo texture es NULL o no especificado, entonces textureTransform no tiene efecto Ejemplo:
Shape {appearance Appearance {
Pgina 42 de 116
material ... } geometry ... }
FontStyle:
FontStyle { field SFString family "SERIF" field SFBool horizontal TRUE field SFString justify "BEGIN" field SFString language "" field SFBool leftToRight TRUE field SFFloat size 1.0 field SFFloat spacing 1.0 field SFString style "" field SFBool topToBottom TRUE }
Este nodo define el tamao, tipo, familia y estilo de un tipo de texto, tambin la direccin de la cadena de texto, y algunas tcnicas de renderizacin que deben ser usadas para los textos que no estn escritos en ingls. Este nodo slo puede aparecer en el campo fontStyle de un nodo Text.
Campo size:
field SFFloat size 1.0
Este campo especifica el tamao de los caracteres.

Campo family:
field SFString family "SERIF"
Pgina 43 de 116
Este campo contiene las fuentes para las letras, as por ejemplo "SERIF" (el valor por defecto), es para las Times Roman; "SANS" es para las Helvtica; "TYPEWRITER" es para las Courier.
Campo style:
field SFString style ""
Este campo contiene los estilos que pueden ser: un string vaco (el valor por defecto); "BOLD" para negritas; "ITALIC" para tipo itlico; o "BOLD ITALIC" para tipo itlico y negrita.
Campos horizontal, leftToRight y topToBotton:
field SFBool horizontal TRUE field SFBool leftToRight TRUE field SFBool topToBottom TRUE
Estos campos indican la direccin del texto:

El campo horizontal indica si el texto es horizontal (TRUE, por defecto), o vertical (FALSE). El campo leftToRight indica si la direccin del texto es de izquierda a derecha (TRUE, por defecto) o de derecha a izquierda (FALSE). El campo topToBotton indica si la direccin del texto es de arriba hacia abajo (TRUE, por defecto) o de abajo hacia arriba (FALSE).
Campo justify:
field SFString justify "BEGIN"
Este campo determina el tipo de justificacin para el texto. Los valores pueden ser "BEGIN", "MIDDLE" Y "END". "BEGIN" es para la justificacin a la izquierda;"END" es para la justificacin a la derecha; "MIDLE" es para la justificacin centrada.
Campo spacing:
field SFFloat spacing 1.0
Este campo determina el espaciamiento entre las palabras.
Pgina 44 de 116
Ejemplo:
FontStyle{ family "SERIF" style "BOLD" size 1.0 spazing 1.0 }
ImageTexture:
ImageTexture { exposedField MFString url [] field SFBool repeatS TRUE field SFBool repeatT TRUE }
Este nodo define un mapeamiento de textura y parmetros para ste mapeamiento. La textura es leida desde una URL especificada por el campo url. Este nodo soporta los formatos GIF, JPEG y PNG.
Campo url:
exposedField MFString url []
Este campo especificar la textura a leer.

Campos repeatS y repeatT:
field SFBool repeatS TRUE field SFBool repeatT TRUE
Estos campos especifican como las texturas van a ser envueltas en las direcciones S (horizontal) y T (vertical). Si repeatS es TRUE (el defecto), el mapeamiento de
Pgina 45 de 116
la textura es repetido fuera del rango de stas (0 a 1) en la direccin S bajo la cual la figura va a ser rellenada. Si repeatS es FALSE, las coordenadas de textura son arrinconadas en la direccin S. El campo repeatT es anlogo. Ejemplo:
Appearance{ material Material{} texture ImageTexture{url "mimono.jpg"} }
Material:
Material { exposedField SFFloat ambientIntensity 0.2 exposedField SFColor diffuseColor 0.8 0.8 0.8 exposedField SFColor emissiveColor 0 0 0 exposedField SFFloat shininess 0.2 exposedField SFColor specularColor 0 0 0 exposedField SFFloat transparency 0 }
Este nodo define las propiedades del material para los nodos de geometra asociados. Los campos en el nodo material determinan el modo de reflejo de la luz lejos de un objeto causante de un color.
Campo diffuseColor:
exposedField SFColor diffuseColor 0.8 0.8 0.8
Este campo todas las fuentes de color VRML, dependiendo del ngulo de la superficie respecto a la fuente de luz. Mientras ms se acerquen las caras de la superficie, mayor difusin de luz se reflejar.
Pgina 46 de 116
Campo ambientIntensity:
exposedField SFFloat ambientIntensity 0.2
Este campo especifica cuanta luz del ambiente, desde las fuentes de luz de la superficie pueden ser reflejadas. La iluminacin del ambiente es omnidireccional y depende slo del nmero de fuentes de luz, no de sus posiciones respecto a la superficie. El color del ambiente es calculado como ambientIntensity*diffuseColor.
Campo specularColor y shininess:
exposedField SFFloat shininess 0.2 exposedField SFColor specularColor 0 0 0
Estos campos determinan la iluminacin especular. Bajos valores de shininess producen incandescencias suaves, mientras que valores medianos resultan en iluminaciones agudas.
campo emissiveColor:
exposedField SFColor emissiveColor 0 0 0
Este campo permite modelar objetos incandescentes.

Campo transparency:
exposedField SFFloat transparency 0
Este campo acta como borrando el objeto. Con el valor 1.0 el objeto es completamente transparente con 0.0 es completamente opaco.
MovieTexture:
MovieTexture { exposedField SFBool loop FALSE exposedField SFFloat speed 1 exposedField SFTime startTime 0 exposedField SFTime stopTime 0 exposedField MFString url []
Pgina 47 de 116
field SFBool repeatS TRUE field SFBool repeatT TRUE eventOut SFFloat duration_changed eventOut SFBool isActive }
Este nodo define un mapeamiento de textura animado (contenido en un archivo de animacin) y parmetros para el control de la animacin y el mapeamiento de la textura.
Campo url:
Este campo permite referenciar el archivo de animacin a usar, se pueden usar formatos de archivo MPEG1-Systems (audio y video) o MPEG1-Video (slo video).
Evento duration-Changed:
eventOut SFFloat duration_changed
Este evento indica la duracin del video en segundos. El valor de este evento puede ser leido (via un Script) para determinar la duracin de un video. Un valor -1 indica que el video no ha sido cargado, o que no est disponible por alguna razn.
Campo startTime:
exposedField SFTime startTime 0
Este campo indica el momento en el que los MovieTextures pueden partir. En ese tiempo el video es considerado como iniciado, el evento isActive es activado, y el frame muestra el video.
Campo stopTime:
exposedField SFTime stopTime 0
Este campo indica cuando el video se detendr, en ese momento el evento isActive FALSE es activado. stopTime es ignorado si loop es FALSE.
Pgina 48 de 116
Campo speed:
exposedField SFFloat speed 1
Este campo indica cuan rpido el video ser desplegado. Un valor de 2, indicar que el video est siendo desplegado el doble de su velocidad normal.
Campo loop:
exposedField SFBool loop FALSE
Este campo indica si el video ser o no repetido una vez que stopTime sea activado. Ejemplo:
Appearance{ texture MovieTexture{ url "mimono.jpg" speed 1 loop FALSE } }
PixelTexture:
PixelTexture { exposedField SFImage image 0 0 0 field SFBool repeatS TRUE field SFBool repeatT TRUE }
Este nodo define una imagen bidimensional, basados en una textura mapeada como un arreglo de valores de pixel y parmetros.
Campos repeatS y repeatT:
field SFBool repeatS TRUE
Pgina 49 de 116
field SFBool repeatT TRUE
Estos campos especifican como las texturas van a ser envueltas en las direcciones S y T. Si repeatS es TRUE (el defecto), el mapeamiento de la textura es repetido fuera del rango de stas (0 a 1) en la direccin S bajo la cual la figura va a ser rellenada. Si repeatS es FALSE, las coordenadas de textura son arrinconadas en la direccin S. El campo repeatT es anlogo. Ejemplo:
PixelTexture{ image 2 4 3 0xFF0000 0x000FF00 0 0 0 0xFFFFFF 0xFFFF00 }
TextureTransform:
TextureTransform { exposedField SFVec2f center 0 0 exposedField SFFloat rotation 0 exposedField SFVec2f scale 1 1 exposedField SFVec2f translation 0 0 }
Este nodo define una transformacin bidimensional que es aplicada a las coordenadas de la textura. Este nodo slo se aplica en el campo textureTransform del nodo Appearance y afecta al modo en que las texturas son aplicadas a las superficies del nodo Geometry asociado. La transformacin consiste de una escala no uniforme cerca de un punto central arbitrario, una rotacin cerca del mismo punto y una traslacin. Esto permite usar los cambios de tamao y posicin de las texturas en las figuras. Ejemplo:
TextureTransform{ rotation 0.39 #22 grados sexagesimales scale 1.0 1.4
Pgina 50 de 116
NODOS COMUNES:
AudioClip:
AudioClip { exposedField SFString description "" exposedField SFBool loop FALSE exposedField SFFloat pitch 1.0 exposedField SFTime startTime 0 exposedField SFTime stopTime 0 exposedField MFString url [] eventOut SFTime duration_changed eventOut SFBool isActive }
Este nodo representa un sonido que es cargado por el browser, puede empezar en cualquier momento y tiene una duracin conocida. Puede ser usado como la fuente de audio para algn nodo Sound (como pensar que es el tocacintas y el nodo Sound el parlante).
Campo url:
Este campo permite referenciar el archivo de audio a usar, se pueden usar formatos de archivo wav en el formato descomprimido PCM. Tambin se puede usar el formato MIDI.
Campo description:
exposedField SFString description ""
Este campo contiene una descripcin del sonido empleado, sta puede ser mostrada en el momento en que ste es activado.
Pgina 51 de 116
Campo loop:
exposedField SFBool loop FALSE
Este campo especifica si el sonido es constantemente repetido o no, por defecto su valor es FALSE, lo que indica que no es repetido (slo se toca una vez).
Campo startTime:
exposedField SFTime startTime 0
Este campo especifica el momento en el que el sonido comienza a ser emitido.

Campo stopTime:
exposedField SFTime stopTime 0
Este campo especifica el momento en que el sonido es apagado, luego de un cierto tiempo de estar encendido.
Campo pitch:
exposedField SFFloat pitch 1.0
Este campo especifica un mltiplo para la proporcin en la cual el sonido es emitido, va en el rango de 0 a ms infinito. El cambio de este campo afecta el tono del sonido. Si pitch toma el valor 2.0 el sonido puede sonar una octava ms alto que lo normal.
Evento isActive:
eventOut SFBool isActive
Este campo puede ser usado por otros nodos para determinar si el clip es actualmente ocupado por un nodo Sound. Ejemplo:
AudioClip{ url["the_wall.wav"] loop FALSE startTime 0
Pgina 52 de 116
DirectionalLight:
DirectionalLight { exposedField SFFloat ambientIntensity 0 exposedField SFColor color 1 1 1 exposedField SFVec3f direction 0 0 -1 exposedField SFFloat intensity 1 exposedField SFBool on TRUE }
Este nodo ilumina apuntando a una direccin especfica. Ejemplo:

DirectionalLight{ #luz estndar direction 1.0 0.0 0.0 }
PointLight:
PointLight { exposedField SFFloat ambientIntensity 0 exposedField SFVec3f attenuation 1 0 0 exposedField SFColor color 1 1 1 exposedField SFFloat intensity 1 exposedField SFVec3f location 0 0 0 exposedField SFBool on TRUE exposedField SFFloat radius 100 }
Pgina 53 de 116
Este nodo define un punto luminoso en una ubicacin tridimensional fija. Este punto ilumina igualmente en todas direcciones, por lo que se lo llama omnidireccional. Ejemplo:
PointLight{ #estndares location 0.0 0.0 0.0 radius 1.0 attenuation 1.0 0.0 0.0 }
Script:
Script { exposedField MFString url [] field SFBool directOutput FALSE field SFBool mustEvaluate FALSE # y algn nmero de: eventIn eventTypeName eventName field fieldTypeName fieldName initialValue eventOut eventTypeName eventName }
Este nodo es usado para programar el comportamiento en una escena. Estos nodos tpicamente reciben eventos que significan un cambio o acciones para el usuario, contienen un mdulo de programa que presenta algn algoritmo, y cambios de efecto, donde algunos de stos adems van enviando eventos de salida en la escena. Cada nodo Script tiene asociado un programa, referenciado por el campo url.
Pgina 54 de 116
Shape:
Shape { exposedField SFNode appearance NULL exposedField SFNode geometry NULL }
Este nodo construye una figura. Este nodo describe la geometra (forma o estructura) y la apariencia (color y textura).
Campo appearance:
exposedField SFNode appearance NULL
Este campo contiene un nodo Appearance el que tiene campos material, texture y textureTransforms.
Campo geometry:
exposedField SFNode geometry NULL
Este campo contiene un nodo de geometra.

Sound:
Sound { exposedField SFVec3f direction 0 0 1 exposedField SFFloat intensity 1 exposedField SFVec3f location 0 0 0 exposedField SFFloat maxBack 10 exposedField SFFloat maxFront 10 exposedField SFFloat minBack 1 exposedField SFFloat minFront 1 exposedField SFFloat priority 0 exposedField SFNode source NULL
Pgina 55 de 116
field SFBool spatialize TRUE }
Este nodo especifica un lugar en donde el sonido especificado en el nodo AudioClip sonar. Por lo tanto este nodo especifica ubicacin, direccin, regin de atenuacin, intensidad ("espacial" o no).
Campo source:
exposedField SFNode source NULL
Este campo especifica la fuente de sonido para el nodo Sound, si sta no es especificada el nodo no entregar audio. La fuente de sonido debe apuntar ya sea a un nodo AudioClip o a un MovieTexture. Algunas veces el nodo MovieTexture debe referenciar un formato de video que soporte sonido (Como MPEG1Systems).
Campo intensity:
exposedField SFFloat intensity 1
Este campo ajusta el volumen de cada fuente de sonido, en el rango de 0.0 a 1.0; 0.0 es silencio y 1.0 es volumen mximo.
Campo priority:
exposedField SFFloat intensity 1
Este campo da al autor algn control acerca de como los sonidos aparecern durante la ejecucin, sobre todo cuando existen diversos de stos al haber diversos canales disponibles. Las prioridades varan entre 0.0 y 1.0, con 1.0 la ms alta prioridad. Para algunas aplicaciones la prioridad 0.0 es usada como sonido normal y 1.0 como sonido para algn evento especial o sonidos que indican algo (usualmente de poca duracin), que el autor desea que sean as.
Campo location:
exposedField SFVec3f location 0 0 0
Este campo determina la ubicacin de la fuente de sonido

Campos minFront y minBack:
exposedField SFFloat minBack 1
Pgina 56 de 116
exposedField SFFloat minFront 1
Estos campos determinan el alcance de regiones de intensidad plena de sonido, tanto de frente como por detrs de ste.
Campos maxFront y maxBack:
exposedField SFFloat maxBack 10 exposedField SFFloat maxFront 10
Estos campos determinan los lmites de audibilidad en las regiones tanto de frente como por detrs del sonido. Si minFront es igual a minBack y maxFront es igual a maxBack, entonces el sonido es omni-direccional, el vector direccin es ignorado.
Campo spatialize:
field SFBool spatialize TRUE
Este campo setea el tipo de sonido conocido como "espacial". Ejemplo:

Sound{ source AudioClip {...} intensity 1 location 0 0 0 direction 0 0 1 spacialize TRUE }
Spotlight:
SpotLight { exposedField SFFloat ambientIntensity 0 exposedField SFVec3f attenuation 1 0 0 exposedField SFFloat beamWidth 1.570796
Pgina 57 de 116
exposedField SFColor color 1 1 1 exposedField SFFloat cutOffAngle 0.785398 exposedField SFVec3f direction 0 0 -1 exposedField SFFloat intensity 1 exposedField SFVec3f location 0 0 0 exposedField SFBool on TRUE exposedField SFFloat radius 100 }
Este nodo define una fuente de iluminacin que es puesta en una ubicacin fija en el espacio tridimensional en un cono a lo largo de una direccin particular. Ejemplo:
Spotlight{ location 0.0 0.0 0.0 direction 1.0 0.0 0.0 beamWidth 1.57 cutOfAngle 0.785 radius 1.0 attenuation 1.0 0.0 0.0 }
WorldInfo:
WorldInfo { field MFString info [] field SFString title "" }
Pgina 58 de 116
Este nodo contiene informacin acerca del mundo construido. Este nodo no presenta ningn efecto en la apariencia del mundo, slo es para propsitos de documentacin.
Campo title:
field SFString title ""
Este campo registra el nombre o ttulo del mundo, los browsers pueden presentar al usuario esta informacin como una instancia o a travs de una ventana.
Campo info:
field MFString info []
Este campo permite guardar informacin adicional acerca del mundo virtual hecho, como por ejemplo el autor, derechos de autor o informacin de dominio pblico. Ejemplo:
WorldInfo{ title "Este mundo loco" info["Un mundo hecho por Jos Muoz", "1996" ] }
NODOS SENSORES:
CylinderSensor:
CylinderSensor { exposedField SFFloat diskAngle 0.262 exposedField SFBool enabled TRUE exposedField SFFloat maxAngle -1 exposedField SFFloat minAngle 0 exposedField SFRotation offset 0 1 0 0 exposedField SFBool autoOffset TRUE
Pgina 59 de 116
eventOut SFBool isActive eventOut SFRotation rotation_changed eventOut SFVec3f trackPoint_changed }
Este nodo genera eventos que interpretan un click del usuario en un cilindro virtual.
Campo enabled:
exposedField SFBool enabled TRUE
Este campo habilita y desabilita el CylinderSensor. Si es TRUE el sensor reacciona frente a los eventos del usuario de una forma adecuada, por el contrario si es falso no lo hace.
PlaneSensor:
PlaneSensor { exposedField SFBool enabled TRUE exposedField SFVec2f maxPosition -1 -1 exposedField SFVec2f minPosition 0 0 exposedField SFVec3f offset 0 0 0 exposedField SFBool autoOffset TRUE eventOut SFBool isActive eventOut SFVec3f trackPoint_changed eventOut SFVec3f translation_changed }
Este nodo genera eventos cuando el usuario hace una traslacin por ejemplo con el mouse, en dos dimenciones.
ProximitySensor:
ProximitySensor {
Pgina 60 de 116
exposedField SFVec3f center 0 0 0 exposedField SFVec3f size 0 0 0 exposedField SFBool enabled TRUE eventOut SFBool isActive eventOut SFVec3f position_changed eventOut SFRotation orientation_changed eventOut SFTime enterTime eventOut SFTime exitTime }
Este nodo genera eventos cuando el usuario entra, sale y se mueve en una regin del espacio (definida por una caja).
SphereSensor:
SphereSensor { exposedField SFBool enabled TRUE exposedField SFRotation offset 0 1 0 0 exposedField SFBool autoOffset TRUE eventOut SFBool isActive eventOut SFRotation rotation_changed eventOut SFVec3f trackPoint_changed }
Este nodo mapea un movimiento de rotacin alrededor del centro de aquel espacio local.
TimeSensor:
TimeSensor { exposedField SFTime cycleInterval 1 exposedField SFBool enabled TRUE
Pgina 61 de 116
exposedField SFBool loop FALSE exposedField SFTime startTime 0 exposedField SFTime stopTime 0 eventOut SFTime cycleTime eventOut SFFloat fraction_changed eventOut SFBool isActive eventOut SFTime time }
Este nodo genera eventos que en un tiempo dado o en intervalos dados de tiempo. Este nodo es usado para conducir simulaciones contnuas y animaciones, o tambin actividades peridicas y/o eventos simples tales como la alarma de un reloj. Para esto TimeSensor controla el tiempo de inicio, final y el largo del ciclo; adems si este ciclo es peridico o no.
TouchSensor:
TouchSensor { exposedField SFBool enabled TRUE eventOut SFVec3f hitNormal_changed eventOut SFVec3f hitPoint_changed eventOut SFVec2f hitTexCoord_changed eventOut SFBool isActive eventOut SFBool isOver eventOut SFTime touchTime }
Este nodo rastrea la ubicacin y el estado de los puntos creados y detecta cuando el usuario apunta a una geometra contenida por el grupo padre del TouchSensor.
Pgina 62 de 116
Este sensor puede ser activado o desactivado enviando un evento de habilitacin con un valor TRUE o FALSE. Si el TouchSensor es desabilitado no rastrear las entradas del usuario o el envo de eventos de salida.
VisibilitySensor:
VisibilitySensor { exposedField SFVec3f center 0 0 0 exposedField SFBool enabled TRUE exposedField SFVec3f size 0 0 0 eventOut SFTime enterTime eventOut SFTime exitTime eventOut SFBool isActive }
Este nodo permite visualizar una regin. Es tpicamente usado para detectar cuando el usuario puede ver la especificacin de un objeto o regin en la escena y la activacin o desactivacin de algunas acciones o animaciones.
NODOS DE INTERPOLACIN:
ColorInterpolator:
ColorInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFColor keyValue [] eventOut SFColor value_changed }
Este nodo interpola entre medio de un conjunto de valores clave MFColor, producidos por un SFColor (RGB) en un evento value_changed. El nmero de colores en el campo keyValue debe ser igual al nmero de keyframes en el
Pgina 63 de 116
campo key. El campo keyValue y el valor del evento value_changed son definidos en el espacio de colores RGB.
CoordinateInterpolator:
CoordinateInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFVec3f keyValue [] eventOut MFVec3f value_changed }
Este nodo interpola posiciones entre medio de un conjunto de valores MFVec3f. Esto puede ser apropiado para interpolar posiciones de coordenadas para morfismos geomtricos. El nmero de coordenadas en el campo keyValue debe ser un mltiplo entero del nmero de keyframes en el campo key, estos mltiplos enteros definen cuantas coordenadas pueden ser contenidas en los eventos value_changed.
NormalInterpolator:
NormalInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFVec3f keyValue [] eventOut MFVec3f value_changed }
Este nodo interpola entre medio de un conjunto de valores Vec3f, convenientes para transformar vectores normales. Todos los vectores de salida pueden estar normalizados por el interpolador. El nmero de normales en el campo keyValue debe ser un mltiplo entero del nmero de keyframes en el campo key, estos mltiplos enteros definen cuantos normales pueden ser contenidas en los eventos value_changed.
Pgina 64 de 116
OrientationInterpolator:-OrientationInterpolator:-->
OrientationInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFRotation keyValue [] eventOut SFRotation value_changed }
Este nodo interpola entre medio de un conjunto de valores SFRotation. Las rotaciones son absolutas en el espacio del objeto y son en consecuencia no acumulativos. El campo keyValue debe contener exactamente tantas rotaciones como keyframes en el campo key, o sino se puede generar un error y los resultados ser indefinidos.
PositionInterpolator:
PositionInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFVec3f keyValue [] eventOut SFVec3f value_changed }
Este nodo interpola entre medio de un conjunto de valores SFVec3f. Esto es apropiado para interpolacin de traslaciones. Este nodo interpola entre medio de un grupo de valores SFVec3f. Los vectores son interpretados como posiciones absolutas en el espacio del objeto. El campo keyValue debe contener exactamente tantos valores como el campo field.
ScalarInterpolator:
ScalarInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key []
Pgina 65 de 116
exposedField MFFloat keyValue [] eventOut SFFloat value_changed }
Este nodo interpola entre medio de un conjunto de valores SFFloat. Este interpolador es apropiado para muchos parmetros definidos usando un valor simple de punto flotante, tales como width, radius, intensity, etc. El campo keyValue debe contener exactamente tantos nmeros como keyframes en el campo field.
NODOS DE PROPIEDADES GEOMTRICAS:
Color:
Color { exposedField MFColor color [] }
Este nodo es usado como el valor del campo color en los nodos IndexedFaseSet, IndexedLineSet, PointSet y ElevationGrid. Este nodo tendr una lista de valores RGB, que sern equivalentes a sus colores.
Coordinate:
Coordinate { exposedField MFVec3f point [] }
Este nodo define el grupo de coordenadas tridimensionales a usarse en los campos coord de los nodos de geometra (tales como IndexedFaceSet, IndexedLineSet y PointSet).
Normal:
Normal { exposedField MFVec3f vector [] }
Pgina 66 de 116
Este nodo define un conjunto de vectores normales a ser usados en el campo vector de algn nodo de geometra (por ejemplo: IndexedFaceSet, ElevationGrid). Este nodo contiene mltiples valores para el vector.
TextureCoordinate:
TextureCoordinate { exposedField MFVec2f point [] }
Este nodo define un conjunto de coordenadas bidimensionales a usar por los nodos de geometra (ej: IndexedFaceSet y ElevationGrid). El rango de las coordenadas de textura va de 0 a 1 a travs de la imagen texturizada. La coordenada horizontal S es especificada como la primera, seguida de la coordenada vertical T.
Pgina 67 de 116
PROTOTIPOS:
DEFINICIN DE PROTOTIPOS:
El prototipado es un mecanismo que permite la especificacin de nuevos tipos de nodos definidos por el usuario. Esto adems permite la encapsulacin y parametrizacin de figuras geomtricas, comportamientos o ambos. Una definicin de prototipos consiste de lo siguiente:

La palabra reservada PROTO. El nombre del nuevo tipo de nodo. Una lista de eventos que el nuevo tipo de nodo puede enviar y recibir. Una lista de campos que el nuevo tipo de nodo hace de acceso pblico, con valores por defecto. La definicin del nuevo tipo de nodo. Esta definicin es una o ms escenas grficas compuestas de nodos existentes (nodos ya incorporados
Pgina 68 de 116
o prototipos previamente definidos), y usa la palabra clave IS para sustituir los nuevos nombres de campos y eventos por los ya existentes. Entonces una definicin de prototipo sera:
PROTO nombre_del_prototipo[eventIn nombre_del_tipo_de_evento nombre eventOut nombre_del_tipo_de_evento nombre exposedField nombre_del_tipo_de_campo nombre default valor field nombre_del_tipo_de_campo nombre default valor ]{ cero o ms escenas grficas. (nodos, prototipos y rutas, conteniendo IS) }
Un prototipo no define un nodo dentro de una escena grfica, lo que hace es crear un nuevo tipo de nodo (nombrado por el nombre_del_prototipo) que puede ser creado posteriormente en el mismo archivo como si fuera un nodo ya incorporado. La primera escena grfica, (referenciada como la escena grfica primaria), encontrada en la definicin de prototipo, conteniendo la palabra IS es usada para representar al nodo. Las otras escenas grficas no son renderadas, pero pueden ser referenciadas via rutas o scripts y de ese modo no ser ignoradas. Tanto las declaraciones de PROTO como de EXTERNPROTO pueden aparecer en cualquier declaracin de ROUTE. Las declaraciones eventIn y eventOut exportan eventos desde la escena grfica primaria. Especificando cada tipo de evento tanto en la declaracin de prototipo como en la escena grfica primaria se pretende prevenir errores y tener consistencia con los prototipos externos. Los eventos generados y recibidos por los nodos en la implementacin de los prototipos son asociados con el prototipo usando la palabra reservada IS. Por ejemplo la siguiente declaracin pone un nodo Transform incorporado en un evento set_translation dndole a ste un nuevo nombre (set_position) en la interface del prototipo.
Pgina 69 de 116
PROTO FooTransform [eventIn SFVec3f set_position]{ Transform {set_translation IS set_position} }
Si permitimos a un prototipo que exporte campos, permitimos que el estado inicial de un objeto prototipado sea especificado cuando una instancia del objeto es creada. Los campos del prototipo son asociados con campos en la implementacin usando la palabra reservada IS. Por ejemplo:
PROTO BarTransform[exposedField SFVec3f position]{ Transform {translation IS position} }
La declaracin IS puede aparecer dentro de los nodos, donde sea que los campos puedan aparecer. Especificando una declaracin IS para un nodo en la escena grfica primaria, la cual no es parte de la implementacin de un prototipo, constituye un error. Un prototipo es instanciado como si fuera un nombre_de_tipo en un nodo incorporado. El nombre del prototipo debe ser nico dentro del alcance del archivo. Un nodo ya incorporado y un prototipo no pueden ser renombrados. Las instancias de los prototipos pueden ser nombradas usando DEF y pueden ser mltiplemente instanciadas usando USE como cualquier nodo incorporado. Una instancia de un prototipo puede ser usada en la escena grfica donde sea que el primer nodo de la escena primaria grfica pueda ser usada. Por ejemplo un prototipo definido como:
PROTO MyObject [...]{ Box{...} ROUTE ... Script{...} ... }
puede ser instanciado donde sea que Box pueda ser usado, puesto que el primer nodo de la escena del prototipo primario en la escena grfica es un nodo Box.
Pgina 70 de 116
Una escena grfica de un prototipo define unos DEF/USE separados del resto de la escena; nodos DEFinidos dentro de un prototipo no pueden ser USEados fuera del alcance del prototipo, y nodos DEFinidos fuera del alcance del prototipo no pueden ser USEados dentro del alcance del prototipo. Un prototipo puede ser instanciado en un archivo en cualquier lugar, despus de haber completado la definicin de ste. Un prototipo no puede ser instanciado dentro de su implementacin (los prototipos recursivos son ilegales). El siguiente ejemplo produce un error.
PROTO Foo[]{ Foo{} }
DEFINICIN DE PROTOTIPOS EN ARCHIVOS EXTERNOS:
La sintaxis para la definicin de prototipos en archivos externos es la siguiente:

EXTERNPROTO nombre_del_prototipo[eventIn nombre_del_tipo_de_evento nombre eventOut nombre_del_tipo_de_evento nombre field nombre_del_tipo_de_campo ...] "URL" o ["URL", "URL", ... ]
Se produce un error cuando las declaraciones de eventIn/eventOut en el EXTERNPROTO no son un subconjunto de las declaraciones eventIn/eventOut especificadas en la declaracin de PROTO referenciada por el URL. Si mltiples URLs o URNs son especificados, el browser busca en orden de preferencia. A diferencia de los prototipos, un prototipo externo no contiene una implementacin del tipo de nodo, en vez de eso la implementacin del prototipo es trada desde una URL o URN. La otra diferencia entre un prototipo y un prototipo externo es que estos ltimos no contienen valores por defecto para los campos. El prototipo externo referencia un archivo que contiene la implementacin del prototipo, y ese archivo contiene los valores por defecto de los campos. Se permite la creacin de bibliotecas, con definiciones de PROTO reusables, los browsers pueden reconocer URLs de EXTERNPROTO que finalicen con
Pgina 71 de 116
"#nombre#, con "nombre" indicando el nombre del prototipo en el archivo. Por ejemplo, una biblioteca de materiales estndar pueden ser guardados en un archivo llamado "materiales.wrl", como sigue:
#VRML V2.0 utf8 PROTO Gold [] {Material {...}} PROTO Silver [] {Material {...}} ... etc
Un Material desde esta biblioteca puede ser entonces referenciado y usado como sigue:
#VRML V2.0 utf8 EXTERNPROTO Gold [] "http://.../materiales.wrl#Gold" ... Shape{appearance Appearance{material Gold{}} geometry ...
} La ventaja de esto es que slo se necesita referenciar una URL para tener las diversas cosas a usar desde la biblioteca; la desventaja es que la biblioteca completa debe ser transmitida a travs de la red, siendo que es probable que slo usemos un prototipo en el archivo.
Pgina 72 de 116
RUTAS:
La coneccin entre un nodo generador de eventos y el nodo que los recibe se llama una ruta. Un nodo que produce eventos de un tipo dado puede ser ruteado a nodos que reciben eventos del mismo tipo usando la siguiente sintaxis:
ROUTE NodeName.eventOutName_changed TO NodeName.set_eventInName.
El prefijo set_ y el sufijo _changed son convenciones recomendadas, no reglas estrictas. As entonces cuando creamos prototipos o scripts, los nombres de los eventIns y los eventOuts pueden tener diversos nombres identificatorios legales. Debemos notar sin embargo, que los exposedField implcitamente definen set_xxx como un eventIn, xxx_changed como un eventOut, y xxx como un campo para un exposedField dado nombrado como xxx. A los diseadores se les recomienda fuertemente esto cuando crean nuevos tipos. Pero existen tres excepciones en la especificacin VRML a esta recomendacin: eventos Bool, eventos Time y eventos children. Todos los SF/MFBool eventIns y eventOuts son nombrados isFoo (ejemplo: isActive). Todos los SF/MFTime eventIns y
Pgina 73 de 116
eventOuts son nombrados fooTime (ejemplo: enterTime). Los eventIns en grupos para sumar y quitar hijos son nombrados: addChildren y removeChildren. Las rutas no son nodos; ROUTE es simplemente una construccin sintctica para el establecimiento de un camino para los eventos entre los nodos. Las declaraciones ROUTE pueden aparecer en cualquier lugar de un archivo .wrl o implementacin de prototipo, o tambin pueden aparecer dentro de un nodo en donde sea que los campos puedan aparecer. Los tipos de los eventIn y eventOut deben ser exactamente iguales, por ejemplo es ilegal una ruta desde un SFFloat a un SFInt32 o desde un SFFloat a un MFFloat. Las rutas deben ser establecidas solo desde eventOuts a eventIns.
GRAMTICA DE UN ARCHIVO VRML:

A continuacin entregaremos la sintaxis general tanto para un archivo VRML como para sus componentes principales (nodos y campos). Estas han sido tomadas exactamente igual del documento original en ingls con el objeto de evitar ambigedades. El caracter '#' (0x23) marca el inicio de una lnea de comentario la cual puede aparecer en cualquier punto de un archivo VRML fuera del alcance de los campos del tipo SFString o MFString. El caracter '#' y todos los otros caracteres hasta el retorno de carro o nueva lnea forman parte del comentario. Se puede usar un nmero de espacios en blanco y comentarios pueden ser usados para separar las entidades sintcticas de un archivo VRML.
Pgina 74 de 116
GRAMTICA GENERAL DE UN ARCHIVO VRML:
A continuacin se mostrar el esqueleto general en un archivo VRML:

vrmlScene: declarations declarations: declaration declaration declarations declaration: nodeDeclaration protoDeclaration routeDeclaration NULL nodeDeclaration: node DEF nodeNameId node USE nodeNameId protoDeclaration: proto externproto proto: PROTO nodeTypeId [ interface_declarations ] { vrmlScene } interfaceDeclarations: interfaceDeclaration interfaceDeclaration interfaceDeclarations restrictedInterfaceDeclaration:
Pgina 75 de 116
eventIn fieldType eventInId eventOut fieldType eventOutId field fieldType fieldId fieldValue interfaceDeclaration: restrictedInterfaceDeclaration exposedField fieldType fieldId fieldValue externproto: EXTERNPROTO nodeTypeId [ externInterfaceDeclarations ] mfstringValue externInterfaceDeclarations: externInterfaceDeclaration externInterfaceDeclaration externInterfaceDeclarations externInterfaceDeclaration: eventIn fieldType eventInId eventOut fieldType eventOutId field fieldType fieldId exposedField fieldType fieldId routeDeclaration: ROUTE nodeNameId . eventOutId TO nodeNameId . eventInId
GRAMATICA DE LOS NODOS:

node: nodeTypeId { nodeGuts } Script { scriptGuts } nodeGuts: nodeGut nodeGut nodeGuts
Pgina 76 de 116
scriptGuts: scriptGut scriptGut scriptGuts scriptGut: nodeGut restrictedInterfaceDeclaration eventIn fieldType eventInId IS eventInId eventOut fieldType eventOutId IS eventOutId field fieldType fieldId IS fieldId nodeGut: fieldId fieldValue fieldId IS fieldId eventInId IS eventInId eventOutId IS eventOutId routeDeclaration protoDeclaration nodeNameId: Id nodeTypeId: Id fieldId: Id eventInId: Id eventOutId: Id
Pgina 77 de 116
Id: IdFirstChar IdFirstChar IdRestChars IdFirstChar: Diversos ISO-10646 cdigos de caracteres usando UTF-8 excepto: 0x30-0x39, 0x0-0x20, 0x22, 0x23, 0x27, 0x2c, 0x2e, 0x5b, 0x5c, 0x5d, 0x7b, 0x7d. IdRestChars: Diversos numeros de ISO-10646 caracteres excepto: 0x0-0x20, 0x22, 0x23, 0x27, 0x2c, 0x2e, 0x5b, 0x5c, 0x5d, 0x7b, 0x7d.
GRAMATICA DE LOS CAMPOS:

fieldType: MFColor MFFloat MFInt32 MFNode MFRotation MFString MFVec2f MFVec3f SFBool SFColor SFFloat SFImage SFInt32 SFNode
Pgina 78 de 116
SFRotation SFString SFTime SFVec2f SFVec3f fieldValue: sfboolValue sfcolorValue sffloatValue sfimageValue sfint32Value sfnodeValue sfrotationValue sfstringValue sftimeValue sfvec2fValue sfvec3fValue mfcolorValue mffloatValue mfint32Value mfnodeValue mfrotationValue mfstringValue mfvec2fValue mfvec3fValue sfboolValue:
Pgina 79 de 116
TRUE FALSE sfcolorValue: float float float sffloatValue: ... nmeros en punto floatante ANSI Cformato punto flotante... sfimageValue: int32 int32 int32 int32s... sfint32Value: [0-9]+ 0x[0-9A-F]+ sfnodeValue: nodeDeclaration NULL sfrotationValue: float float float float sfstringValue: ".*" ... double-quotes must be \", backslashes must be \\... sftimeValue: ... double-precision number in ANSI C floating point format... sfvec2fValue: float float sfvec3fValue: float float float mfcolorValue: sfcolorValue
Pgina 80 de 116
[ ] [ sfcolorValues ] sfcolorValues: sfcolorValue sfcolorValue sfcolorValues mffloatValue: sffloatValue [ ] [ sffloatValues ] sffloatValues: sffloatValue sffloatValue sffloatValues mfint32Value: sfint32Value [ ] [ sfint32Values ] sfint32Values: sfint32Value sfint32Value sfint32Values mfnodeValue: nodeDeclaration [ ] [ nodeDeclarations ] nodeDeclarations: nodeDeclaration nodeDeclaration nodeDeclarations
Pgina 81 de 116
mfrotationValue: sfrotationValue [ ] [ sfrotationValues ] sfrotationValues: sfrotationValue sfrotationValue sfrotationValues mfstringValue: sfstringValue [ ] [ sfstringValues ] sfstringValues: sfstringValue sfstringValue sfstringValues mfvec2fValue: sfvec2fValue [ ] [ sfvec2fValues] sfvec2fValues: sfvec2fValue sfvec2fValue sfvec2fValues mfvec3fValue: sfvec3fValue [ ] [ sfvec3fValues ] sfvec3fValues:
Pgina 82 de 116
sfvec3fValue sfvec3fValue sfvec3fValues
METODOLOGA DE DESARROLLO VRML

INTRODUCCIN
El propsito es crear mundos virtuales, que puedan ser accesados a travs de Internet, para lograr sto se cuenta con VRML, que combina las tecnologas Realidad Virtual e Internet. VRML no es un lenguaje de programacin, es un lenguaje de especificacin de mundos virtuales. Esta tecnologa an es muy reciente como para contar con una filosofa de trabajo conocida y aceptada formalmente (como ocurre con la
Pgina 83 de 116
programacin convencional), sin embargo en la metodologa que se describir a continuacin se encontrarn fases anlogas a las encontradas en la Ingeniera de Software. Sin embargo conviene precisar que esta metodologa puede no estar exenta de errores u omisiones, y que dado el dinamismo existente en la comunidad VRML es muy probable que a la fecha de publicacin de este trabajo se encuentren metodologas ms completas o eficaces. La metodologa que se describir a continuacin es parte del proyecto final de carrera realizado por Diego lvarez, alumno de Licenciatura en Informtica de la Universidad Politcnica de Valencia, denominado "Realidad Virtual por Internet" el cual puede ser referenciado a travs de http://www.arrakis.es/~dalvarez/. Conviene aclarar que esa metodologa ha sido diseada para la especificacin 1.0 de VRML, por lo tanto deja afuera todas las posibles interacciones que puedan existir entre los objetos que pueblan el mundo VRML a construir, por otro lado se aprecia una fuerte tendencia hacia los proyectos arquitectnicos en la descripcin del mtodo, sin considerar que ese tipo de proyectos es slo un caso particular. Sin embargo ha sido la nica metodologa encontrada que se aparta del hecho de responder a una herramienta en particular, otros casos de metodologas encontradas eran slo una gua para el correcto desarrollo de las aplicaciones con una herramienta en particular. En virtud a que la metodologa de desarrollo encontrada slo responda a VRML 1.0, debi ser completada para abarcar los casos de dinamismo existente entre los objetos, adems se la provee de una notacin que permita un adecuado manejo de los conceptos VRML descritos en el captulo anterior. Cada una de las etapas fue revisada con el propsito de rescatarla tal cual, o agregar o quitar elementos de acuerdo al enfoque adoptado por este trabajo, vale decir tener una metodologa independiente de la herramienta que permita desarrollar proyectos VRML de acuerdo a su especificacin 2.0, y dejar abierto el camino a que pueda ser completada en caso que aparezcan nuevas especificaciones para VRML. Posteriormente a describir la metodologa ser usada en una aplicacin concreta.
GUA DE DESARROLLO
Un proyecto VRML, de cualquier envergadura, puede ser dividido en 7 etapas: 1. 2. 3. 4. 5. Especificacin Planificacin Muestreo Diseo Construccin
Pgina 84 de 116
6. Pruebas 7. Publicacin A continuacin se proceder a la descripcin de cada una de ellas:
ESPECIFICACIN
Aqu se decide qu es lo que se va a construir. Siempre en cualquier proyecto de SW es el usuario quien establece (o idealmente debera establecer) claramente los requisitos o funcionalidades especficas que desea para el SW que est solicitando. En un proyecto VRML se presentan algunas particularidades importantes frente a este respecto: En primer lugar hay un elemento artstico-tcnico muy importante a la hora de pensar en la satisfaccin plena ante el usuario. Se puede tener un proyecto VRML relacionado con el modelamiento de un monumento histrico, por ejemplo las ruinas de San Pedro de Atacama, pudo haberse hecho un trabajo muy completo relacionado con recopilacin adecuada de antecedentes, y estudio histrico, sin embargo es muy probable que nunca quede satisfecho plenamente quien encarga el proyecto (un arquelogo, o un profesor de historia), ya que a la hora de construir siempre habrn ciertos detalles precisos que puedan pasar por alto. En el caso de las ruinas puede ocurrir que una momia haya sido tratada con cierto tipo de tcnica de embalsamiento que hace que su color sea de cierta caracterstica, la cual no haya sido percibida adecuadamente por el modelador, o simplemente no lograda a travs de una combinacin RGB. Adems de lo anterior se debe tener en cuenta que los mundos VRML en resumen son realidad virtual, que puede ser accesada por Internet, vale decir, su caracterstica primordial es su divulgacin a travs de la red. Puede existir un proyecto relacionado por ejemplo con la confeccin de una super base militar estratgica, en donde es necesario tener todos los elementos ubicados en forma precisa. Est muy claro que aqu nadie del Estado Mayor querr que eso se vea por Internet, o que al menos se sepa que tiene esa caracterstica, ni aunque se les diga que se establecern todos los tipos de tcnicas criptogrficas o "restricciones al dominio". Una vez visto lo anterior se puede proceder a la especificacin del proyecto VRML, considerando dos tipos fundamentales de proyecto:
Pgina 85 de 116
Proyecto Profesional: Es el que consiste en el modelamiento de un sitio real, por lo tanto la imaginacin queda relegada y slo se recaban antecedentes objetivos acerca del "padre real", que dara origen a un "hijo virtual", por lo tanto es muy importante en este tipo de proyectos tener a mano a este "padre real" para que sirva de marco de referencia para establecer comparaciones. Proyecto Artstico: En este caso el modelamiento est basado en las ideas que surgen de la imaginacin del artista modelador, aqu el ideal esttico es lo ms importante, a diferencia del tipo de proyecto anterior en donde slo se "calca" lo que existe en la realidad objetiva. En el caso de estos mundos virtuales imaginarios es importante sealar que stos deben ser consistentes consigo mismos, es decir, se deben disear leyes que rijan el comportamiento del mundo a construir.
Una vez decidido qu es lo que se va a construir se debe establecer cual va a ser la finalidad de la construccin, en este sentido no es lo mismo construir un espacio que modele un edificio real con el propsito de ser visitado por personas en sillas de ruedas que quieran saber si ste es accesible en su totalidad o hacer un espacio dedicado al entretenimiento, donde el atractivo ser su principal fin. En el primer caso la fidelidad al modelo original debe ser la mxima a seguir, en el segundo caso se pueden permitir ciertas licencias constructivas. Las cuales por supuesto deben ser consistentes, por ejemplo se puede modelar un carrusel, pero no debera ocurrir que ste tuviera adems de movimiento de rotacin, uno de traslacin. Es importante por lo tanto decidir el nivel de detalle a alcanzar en el proyecto (ej. nmero de edificios y nivel de detalle de los mismos). Por ejemplo si se decide hacer slo la fachada de un edificio sin la posibilidad de acceder a su interior, o decidir que locaciones incluir y cuales no (ej. representar slo el primer piso y dentro de ste el hall, saln de actos y laboratorio). Como ya se ha dicho el elemento artstico dentro de un proyecto VRML, y de realidad virtual en general, es muy importante, por lo que el hecho de abarcar detalles que sean efectivamente relevantes a la hora del diseo y construccin del modelo es vital. Sin embargo, si este nivel de detalle es refinado a niveles muy rigurosos, se pueden abarcar aspectos que simplemente el usuario nunca va a considerar a la hora de explorar el mundo virtual, por lo que simplemente se habr perdido tiempo y recursos en su implementacin
Pgina 86 de 116
Dado el anlisis hecho en los puntos anteriores se tendr un documento de especificacin de proyecto VRML, el cual contendr los siguientes puntos: 1.- DESCRIPCIN: Se dice en qu consiste el proyecto (profesional o artstico) as como el nivel de detalle a alcanzar, locaciones a modelar y finalidad del proyecto. Cuando se habla de locaciones, significa cualquier tipo de escenario posible de modelar, por lo tanto puede ser una locacin tanto un escenario arquitectnico, como uno biolgico, qumico, imaginario, etc. 2.- USUARIOS Y CLIENTES: Se describe el perfil del usuario de sta aplicacin, as cmo quien encarga el proyecto. Ambas descripciones son importantes a la hora de establecer los requisitos de funcionalidad propios del proyecto. 3.- RECURSOS NECESARIOS: Se indican los recursos a ocupar en el desarrollo de la aplicacin (Software modelador, especificacin de VRML, editores, Software de aplicaciones grficas, elementos grficos, etc.). 4.- REQUERIMIENTOS FUNCIONALES: Aqu se establece el modo de interaccin con el usuario, que en estos casos est limitada a la interfaz del visualizador VRML que posea el usuario, en general es conveniente recomendar al usuario un visualizador especfico. Junto con esto se establece el siguiente tipo de restricciones:
Restricciones Estticas: Aqu se trata de conseguir que el resultado final sea identificable con lo que se est modelando. Esto implica revisar nuevamente la lista de objetos a modelar y ya sea confirmarla o corregirla considerando que se espera un resultado "identificable con", no necesariamente "igual a". Esto puede llevar a que la lista inicial sea recortada o por el contrario aumente.
Una vez decidido lo anterior debe verse cmo se dibuja, o sea, se usarn texturas para cubrir los objetos o no. Si los objetos son perfectamente identificables mediante colores RGB, el uso de texturas puede relegarse slo para entregar informacin adicional (un escudo, alguna superficie planetaria, etc.).
Restricciones Tcnicas: Un archivo VRML debe estar completamente cargado en memoria para que pueda ser visto, vale decir hay un tiempo entre la llegada del archivo por la red y su completo despliegue por pantalla. El uso de texturas permite otorgar una mayor cuota de realismo al mundo a modelar, sin embargo stas vienen definidas en archivos
Pgina 87 de 116
externos, por lo que deben recuperarse y leerse adicionalmente al archivo VRML en s. Si hablamos de un trfico muy atochado por la red, esto puede implicar un tiempo de carga completo de la escena grfica demasiado grande para un usuario que est visitando Internet, adems de los requerimientos mnimos de memoria y procesador que se requieren (32 Mb de RAM, Procesador Pentium de 120 MHz).
Restricciones de equipamiento computacional: Restricciones (HW/SW), para una correcta construccin, aqu lo mnimo, de acuerdo a la aplicacin realizada, es un PC con 16 Mb de RAM y procesador Pentium de 100MHz. Requerimientos ideales son PC con 32 Mb de RAM y procesador Pentium con 120 MHz.
Con todos estos antecedentes se tiene un dominio conocido en el cual se podr trabajar a travs de VRML.
PLANIFICACIN DEL PROYECTO
En esta etapa se decide cuando y cmo construir. El cuando depender del nmero de personas implicadas en el proyecto, as como de limitaciones impuestas por los receptores del proyecto (las que pueden ser plazos y/o de presupuesto), quienes sern los que fijen las condiciones temporales del proyecto. Es importante tener en cuenta lo siguiente: Lo ms relevante dentro del trabajo VRML es crear un modelo que deje plenamente satisfechos a sus usuarios en torno a lo que ellos esperan de su modelo (sobretodo si se habla de algn modelamiento que simule algn proceso ya sea biolgico, mecnico, de exploracin espacial, o simplemente una maqueta), por lo tanto sera conveniente que las faces de la planificacin aqu expuestas sean planteadas de acuerdo a ese planteamiento, vale decir, si se necesita que el comportamiento del objeto en torno a su interaccin con los dems sea correctamente modelado se deber de tener una etapa de diseo muy rigurosa, con el propsito de llegar a un nivel adecuado de comprensin en torno a ese asunto; por otro lado si se est frente a un proyecto en donde la apariencia final del objeto es muy importante deber de tenerse una fase de construccin lo suficientemente detallada que permita ese resultado. El cmo construir depender de la complejidad del proyecto
Pgina 88 de 116
Proyecto Simple: Por ejemplo un modelado de una ciudad en donde los edificios slo sean paralelgramos, aqu se pueden usar herramientas tales como Virtual Home Space Builder de Paragraph. Proyecto Complejo: Por ejemplo un modelado de un transbordador espacial, para que sea visitado por sus potenciales ocupantes; en este caso la planificacin requiere incluir la adquisicin y capacitacin en aplicaciones tales como: o Internet3D Space Builder o 3D-Studio o Autocad
La diferencia entre proyecto simple y complejo ir dada por el hecho del adecuado nivel de detalle precisado por los usuarios. Un proyecto simple sera entonces, para el caso de un edificio, hacer una caja; se transformara en complejo si adems de la caja se requiere que se note la diferencia entre los pisos, visita por dentro, funcionamiento del ascensor, etc. Una adecuada planificacin permitir tambin poder evaluar econmicamente el proyecto, desde el punto de vista de quien encarga el trabajo. En este sentido una evaluacin adecuada de este tipo de proyectos debe de considerar un seguimiento de los costos involucrados en cada fase del proyecto as como los plazos de entrega, en este sentido es importante definir la complejidad del proyecto, ya que en la medida que sta crece, su costo tambin aumenta. Un proyecto complejo exige SW de modelado 3D de alta calidad, junto a HW especialmente dedicado a la computacin grfica, desde este punto de vista los costos tanto en HW como en SW son mucho mayores que para el caso de un proyecto simple que pueda ser realizado en un PC sin necesidad de HW de aceleracin grfica. La complejidad del proyecto debe estar totalmente definida en la etapa de especificacin, ya que en este punto (planificacin), los recursos tanto HW/SW, as como de Recursos Humanos, deben estar plenamente establecidos para cada una de las etapas restantes del proyecto (muestreo, diseo, construccin, pruebas, publicacin). Por lo tanto los tems a considerar para la evaluacin de costos en un determinado proyecto VRML son:
HW: Elegir ya sea un PC con 32MB de RAM como mnimo en el caso de un proyecto simple una estacin de trabajo con alto poder grfico (se
Pgina 89 de 116
recomiendan las mquinas Silicon Graphics), para el caso de un proyecto complejo.
SW: En este caso si se habla de un proyecto simple habr SW que podr extraerse libremente desde la red, pero para casos de proyectos complejos existir SW ms especializado y por tanto con un costo involucrado. RRHH: En este caso se trata de determinar quienes estn involucrados en el proyecto (ingenieros, arquitectos, dibujantes, tcnicos) y su grado de participacin en cada una de las etapas del proyecto, aqu la medicin debe hacerse en personas-mes o personas-ao, empleando alguna tcnica de estimacin del esfuerzo. Dependiendo de la complejidad del proyecto, este tem puede ir variando, junto al tiempo involucrado en su desarrollo. Aqu tambin es importante considerar los costos en capacitacin para el personal en los que se pueda incurrir. Otros: Aqu se deben considerar los costos anexos en torno a fotocopias, fotos, u otros que puedan incidir en el costo total del proyecto.
Todos estos tems pueden ser resumidos en lo siguiente: CT = HW+SW+RRHH+CAP+OTR Donde CT representa los costos totales incurridos, HW representa el costo en HW, SW representa el costo en SW, RRHH representa el costo en recursos humanos y CAP el costo de capacitacin y OTR representa los otros tems a considerar. La estimacin de los ingresos que se puedan obtener, debido a la realizacin de aplicaciones de este tipo debe ir dada por el cubrimiento de los costos estipulados anteriormente as como por una estimacin acerca de lo que ganan quienes encargan el proyecto, vale decir si una empresa de turismo encarga modelar ciertas locaciones que sta incluye en alguno de sus planes debe de estimarse cuanto gana esta empresa por concepto de publicidad (y tambin prestigio) al tener este tipo de visita estipulada. Se sugiere el uso de Software de gestin de proyectos con el propsito de hacer un seguimiento preciso y continuo de las fases establecidas para la realizacin del proyecto as como un seguimiento de costos y plazos de entrega.
Pgina 90 de 116
De todo lo anterior se desprende que la complejidad de los proyectos VRML incide en forma directa en el costo involucrado para su desarrollo, esta relacin complejidad-costo podra ser establecida por medio de alguna relacin matemtica, sin embargo la poca experiencia en el mbito del desarrollo de aplicaciones VRML an no permite realizar esta relacin, por lo que cualquier medicin de este tipo slo podr ser realizada de acuerdo al criterio de los analistas durante la revisin de la especificacin, durante la etapa de planificacin. Del anlisis anterior se obtendr una pauta de trabajo, que puede ir dada por una carta Gantt, en donde se tendrn las etapas involucradas en el desarrollo de las aplicaciones VRML (Especificacin, muestreo, diseo, construccin, pruebas y publicacin), junto a su duracin (en semanas).
MUESTREO
Durante esta etapa se recaban todos los antecedentes acerca del objeto a modelar. Esta forma de recopilacin variar de acuerdo al objeto, si se trata de modelar un ente biolgico ( ej. el cuerpo humano) se tomaran fotografas de diversos ngulos o tambin podran hacerse tomas de video, las cuales posteriormente seran revisadas durante la etapa de construccin. Otra forma de muestreo es para el caso de modelar objetos geomtricos estticos (muebles, casas, una ciudad), en donde se puede pasar de un croquis simple (para el caso de un proyecto simple); a la recopilacin de planos (elevaciones, de planta, cortes), trabajos previos en Autocad, fotografas digitales, tomas de video (para el caso de un proyecto complejo). Finalmente se tiene el caso para los objetos dinmicos, vale decir aquellos que pueden ir cambiando en el tiempo, ya sea en respuesta a eventos internos (un objeto cuyo movimiento afecte a otro) o externos (un click). En este caso adems de los antecedentes ya nombrados se requiere tener un pleno conocimiento de los mecanismos que gobiernan el movimiento de cada uno de los componentes. Por ejemplo se puede estar frente al hecho de modelar un nuevo tipo de prtesis para un brazo humano, por lo que es necesario conocer todos aquellos principios que gobiernan el movimiento de la prtesis.
Pgina 91 de 116
Para el caso de un proyecto arquitectnico el uso de planos de las diversas construcciones y/o locaciones comprometidas es muy til por las siguientes razones:

Permite conocer las dimensiones de las construcciones a modelar Se pueden determinar fcilmente las distancias entre elementos tan importantes como por ejemplo puertas y ventanas. Se determina la ubicacin de los distintos elementos dentro de la escena (layout).
En resumen, en esta etapa se obtiene toda aquella informacin que sea necesaria para un adecuado modelamiento de los objetos que poblarn el mundo virtual a construir.
DISEO INTRODUCCIN
Una vez conseguidos todos los antecedentes acerca de las diversas locaciones a modelar, por medio del proceso de muestreo, se debe proceder al diseo del modelo virtual. Antes de iniciar cualquier proceso de diseo, conviene revisar la sintaxis y estructura bsica de un archivo VRML, la que se puede apreciar en el siguiente esquema:
Img 1_1
En un mundo VRML determinado se pueden apreciar componentes estticos y dinmicos. Los componentes estticos son todas aquellas figuras geomtricas que dan forma al objeto u objetos que se estn modelando. Los componentes dinmicos en cambio son todos aquellos eventos transmitidos entre los objetos
Pgina 92 de 116
que forman el mundo virtual, a travs de una ruta, que permiten a stos presentar interacciones traducidas en movimientos, sonidos, o algn otro fenmeno perceptible para el usuario. Estos eventos pueden ser tanto internos, como externos. Ahora es necesario comprender bien la estructura de un mundo VRML. Un mundo VRML est compuesto por una ms escenas grficas, cada una contenida en un archivo VRML. Las escenas grficas estn compuestas por un grupo de nodos, los cuales contienen campos y eventos. Los nodos representan el componente esencial en un archivo VRML, pueden ser de distinto tipo, nodos pueden agrupar otros nodos. Los eventos son mensajes enviados entre los nodos a travs de rutas, estos eventos permiten otorgar dinamismo a los componentes de un mundo VRML.
PASOS PRELIMINARES EN DEL DISEO
Los siguientes pasos son importantes a la hora de poder efectivamente lograr una emulacin adecuada del comportamiento modelado: 1. 2. 3. 4. Identificacin de objetos. Especificacin de atributos. Identificacin de eventos. Comunicacin entre objetos.
A continuacin se proceder a describir cada uno de estos pasos.

IDENTIFICACIN DE OBJETOS
La identificacin de objetos en el caso del modelamiento para VRML sigue un camino similar al anlisis orientado a objetos. En primer lugar los objetos sern identificados a partir del anlisis hecho a la especificacin del modelo, y de los antecedentes recogidos a partir del muestreo. De ambos pasos se aprecia que los objetos se pueden manifestar de las siguientes formas (dentro del marco VRML):
Lugares: Como ser una sala de clases, un parque, etc. Estos lugares establecen el contexto en el que se encuentra el modelo y por lo tanto permiten apreciar su comportamiento general. Por ejemplo si se trata de una sala de mquinas, quedar establecido que se est frente a objetos con una gran capacidad dinmica, por el contrario si es un saln de clases (obviando sus alumnos), estamos en presencia de un escenario esttico.
Pgina 93 de 116
Estructuras: Por ejemplo edificios, organismos vivos, mquinas. Se trata de definir en este punto aquellas figuras o formas que pueden formar parte de la Transformacin Jerrquica. Estas estructuras podrn ser descompuestas en otras ms pequeas, hasta llegar al nivel ms bajo. Una vez logrado sto se podr contar con clases de objetos que podrn ser instanciados en caso que sea necesario (DEF/USE). Ocurrencias o sucesos: Por ejemplo el fin de una serie de movimientos por parte de un robot. Estos sucesos deben estar claramente enmarcados dentro del contexto en el que se desarrolla el escenario a modelar. Seales: Elementos que indiquen o marquen el punto de partida de algn suceso.
Esta identificacin permite tener un punto de partida hacia el modelamiento definitivo. Extrapolando esto a VRML los objetos aqu identificados sern posteriormente modelados a partir del uso de nodos, de cualquiera de sus tipos dependiendo de la naturaleza del objeto.
ESPECIFICACIN DE ATRIBUTOS
Una vez identificados los objetos que van a poblar el escenario virtual, es hora de distinguir sus atributos, vale decir aquellos datos que le otorgan al objeto cualidades relevantes a ocupar para su modelamiento posterior. En este sentido los atributos son caractersticas fsicas propias del objeto a modelar, por ejemplo para el modelamiento de una radio-cassete sern alto, largo y ancho; color, volumen mximo y mnimo de sonido. Para encontrar una lista adecuada de atributos nuevamente se deben recabar los antecedentes recopilados tanto en la especificacin como en el muestreo, para que con los objetos ya identificados, hacer una lista de sus atributos ms relevantes para la finalidad del proyecto a realizar. Extrapolando esto a VRML los atributos aqu especificados pasarn a ocupar el lugar de los campos de los nodos, aunque esta equivalencia no debe ser considerada directa totalmente ya que en VRML, como ya se ha mencionado, est el concepto nodo padre, nodo hijo, donde los hijos estn agrupados bajo el campo children, por lo que son objetos al igual que el padre. La extrapolacin atributo-campo, slo es aplicable en los niveles ms bajos de descomposicin de la estructura jerrquica.
Pgina 94 de 116
IDENTIFICACIN DE EVENTOS
Un evento involucrar cambios en el objeto sobre el que se le aplica, ms bien se producen cambios en los valores de uno o ms de los atributos que estn contenidos en l. Estos cambios pueden ser de posicin, color, tamao, sonido, etc. Para lograr identificar los eventos, nuevamente se debe hacer un anlisis tanto de los datos entregados en la especificacin como en el muestreo, de manera de conseguir una clasificacin satisfactoria. Extrapolando esto a VRML, los eventos permiten el cambio de valores de los campos en los nodos. Estos eventos (que inducen operaciones) pueden ser internos como externos, ejemplo de un evento interno es la deteccin de colisiones, ejemplo de un evento externo es la activacin del sonido de una radio por medio del click con el mouse.
COMUNICACIN ENTRE OBJETOS
Los objetos se comunicarn por medio de mensajes, estos mensajes deben ir encaminados por una ruta. En VRML cambios en los nodos, producto de su interaccin, son posibles gracias al envo de mensajes por medio de eventos que son encaminados va una ruta (ROUTE). El anlisis de la especificacin y los datos recabados del muestreo, debern de indicar la existencia de estas interacciones, sobre todo en aquellos escenarios dinmicos en donde los objetos presenten variaciones en su movimiento y caractersticas fsicas.
NOTACION PROPUESTA
Ya se han visto los conceptos claves a tener en cuenta a la hora de hacer un diseo adecuado (Escena grfica, nodos, campos, eventos, rutas), es importante poder tener un tipo de notacin adecuada para seguir adelante en esta etapa. La notacin que se propone es la ocupada por la Silicon Graphics durante un seminario acerca de VRML realizado el 6 de agosto de 1996, en ella integran nodo, campo, evento como se ve en la figura siguiente:
Img 1_2
Pgina 95 de 116
Esta notacin permite el hecho de poder analizar ms grficamente la interaccin entre los diversos objetos. Supngase un escenario mediante el cual el usuario al acercarse a un objeto hasta llegar a la colisin, ocasiona que se produzca un ruido producto de esa colisin. Esto involucra un mensaje entre el objeto colisionado y la fuente de sonido, para que sta emita el correspondiente ruido. Hay un evento de salida por parte del nodo Collision, el cual ocasionar un accionar por parte del nodo AudioClip. La situacin grficamente sera la siguiente:
Img 1_3
Las flechas indican que se ha seguido una ruta, por lo tanto a la hora de codificar tentativamente debera de escribirse algo como:
ROUTE Nodo1.collideTime TO Nodo2.startTime
En un modelamiento real un escenario determinado puede tener cientos de objetos y una buena cantidad de estructuras, por lo que es necesario lograr una representacin concisa de estos conceptos. Para el propsito de abreviar un objeto se puede considerar representarlo con un rectngulo indicando su nombre en el interior, esta representacin es til sobre todo cuando se est definiendo la organizacin estructural de la escena grfica. Una vez vista esta notacin se pasar a estructurar los conceptos ya analizados.
ESTRUCTURA DE ENSAMBLAJE
Como ya se ha mencionado, dentro del diseo para VRML se puede apreciar que un objeto identificado en las etapas primarias del anlisis puede ser descompuesto en varias partes constitutivas, que pueden tambin ser definidas en s mismas como objetos. Estructuras de este tipo son denominadas estructuras de ensamblaje y se pueden definir con la siguiente notacin:
Img 1_4 Pgina 96 de 116
En donde el rectngulo significa un objeto y el tringulo implica la relacin de ensamblaje existente. La pregunta que surge a continuacin es qu ocurre con las instancias que se puedan presentar para un objeto o nodo determinado, vale decir, qu ocurre cuando frente a una determinada estructura se est claramente frente a una situacin que para VRML se debera tomar como DEF/USE?. En este caso debera de anotarse nuevamente la instancia con los respectivos valores de los campos modificados, lo ms usual es que se halla modificado la posicin, por lo que los valores en ese atributo deban ser especificados para la instancia, pudindose obviar el resto de los valores por ser iguales. Extrapolando a VRML, se tendra un nodo Transform, con valor especificado de campo translation y con campo children que tendra la referencia USE. Sin embargo la posicin de la instancia en el diagrama de ensamblaje puede ser manejado de tres diferentes formas, cada una de ellas tendr un significado distinto dentro del contexto VRML. Se analizarn estos casos tomando un caso sencillo en el cual se tiene un portal acompaado por dos columnas, una a cada lado de la puerta.
CASO 1
Colocar la instancia en el mismo nivel del objeto, esto implicara que la instancia estara supeditada solamente al movimiento que realizar el portal. Para sealar que Columna1 es instancia de Columna se unen por una lnea de flechas, con la flecha apuntando hacia el objeto que es instanciado.
Img 1_5
CASO 2
Colocar la instancia un nivel ms abajo que el objeto, esto implicara que la instancia est supeditada al movimiento del objeto, el cual a su vez est
Pgina 97 de 116
supeditado al movimiento del nodo padre. Esto significa que si Columna se mueve 2 unidades de desplazamiento, Columna1 tambin lo har. Columna puede desplazarse ya sea porque su propio atributo de posicin ha cambiado, o porque el atributo de desplazamiento de portal lo ha hecho, en ambos casos Columna1 se desplazar en la misma proporcin.
Img 1_6
CASO 3
En este caso la situacin se plantea de la siguiente forma: crear un objeto Columna el cual tenga a Columna1 como subobjeto y Columna2 como instancia de Columna1. De esta forma al desplazarse Columna, desplazar a ambas en la misma proporcin, y al desplazarse una de ellas, no afectar la posicin de la otra.
Img 1_7
En los tres casos descritos se ha obviado la informacin de atributos como una manera de abreviar la notacin y slo se ha anotado el nombre del nodo. Tambin puede ocurrir que se est frente a la posibilidad de mltiples instancias para un objeto determinado, se puede abreviar esta situacin, slo en el caso que se est en el mismo nivel de jerarqua, de la manera en la que se ve para el caso del Partenn griego:
Img 1_8
Pgina 98 de 116
En donde la lnea segmentada indica que se estn referenciando los objetos desde Columna1 a Columna100, vale decir que existen 100 columnas con los mismos atributos.
PROPIEDADES DINMICAS
Hasta el momento se ha considerado a los objetos en el mundo VRML como entes ensamblados y organizados jerrquicamente. Sin embargo tambin se puede enfrentar la posibilidad de dinamismo existente en estos objetos, vale decir, el hecho que stos pueden interactuar, por medio del envo de mensajes y tambin efectuar movimiento sin que medie alguna accin externa por parte del usuario. Estas acciones involucran un cambio en el estado de los objetos, por lo que cada objeto en el cual se pueda apreciar esta capacidad dinmica debe tener un diagrama de transicin de estados que refleje esta situacin. Los eventos originarn cambios en el estado de los objetos, por lo que es muy importante tenerlos bien identificados. Por otro lado, como se ha dicho, los objetos interactan entre ellos, por medio del envo de mensajes (o eventos) a travs de rutas, por lo que es importante, tambin, tener un diagrama de interacciones del mundo VRML, que permita modelar esto adecuadamente. Ambos tipos de diagrama son los que se proceder a analizar a continuacin, usando nuevamente, el ejemplo del objeto que emite un sonido al ser colisionado.
DIAGRAMA DE TRANSICIN DE ESTADOS
Por medio de este diagrama se puede ver el tipo de estados por el que puede pasar un objeto determinado, junto con los eventos que ocasionan la transicin de un estado a otro. De esta manera se puede capturar el comportamiento dinmico de los objetos del mundo VRML a modelar. En el caso del ejemplo del sonido activado por la colisin se tiene que los estados para Nodo2 (el que lleva a la activacin del sonido) son: Silencio y Sonido, el posible diagrama sera:
Img 1_9
Pgina 99 de 116
Las flechas indican una transicin de estado, en tanto sobre ellas se da un nombre simblico a los eventos involucrados.
DIAGRAMA DE INTERACCIONES
Un diagrama de interacciones permite realizar una traza de todos aquellos sucesos de carcter dinmico que se puedan presentar en un determinado escenario VRML. Para el ejemplo de la colisin detonadora de un sonido, el diagrama de interacciones sera el siguiente:
Im g 1_10
En donde los objetos van acompaados por una lnea de segmentos vertical y los eventos van acompaados por una flecha. Aqu simplemente se ejemplifica que Nodo1 (que es un nodo de tipo Collision) al detectar que se ha realizado una colisin enva un mensaje a Nodo2 (del tipo Sound), para que ste se active y de esta manera se emita un sonido. La posterior traduccin de sto a VRML (ROUTE), vendr dada en la etapa de construccin. Se debe tener presente los sinnimos que han sido usados en este captulo y que son absolutamente naturales: Nodo es sinnimo de objeto, atributo es sinnimo de campo, mensaje es sinnimo de evento. Tanto de la etapa de especificacin como de la de muestreo se ha obtenido un cmulo de informacin acerca del mundo virtual a construir, sin embargo mucha de esta informacin puede llegar a ser un estorbo a la hora de construir, puesto que se puede ocupar un buen porcentaje de tiempo en detalles sin importancia que el visitante de la aplicacin ni siquiera vaya a tomar en cuenta, por lo que es necesario siempre rescatar lo esencial y saber detectar lo superfluo, siempre lo que se busca en una representacin virtual de un elemento del mundo real es lograr una adecuada aproximacin que lo permita ser reconocible, no necesariamente sacar una fotocopia exacta. Por lo tanto en esta etapa es importante responder a preguntas tales como:
Pgina 100 de 116
Esto es arte? Es un espacio pblico? Debe ser funcional o slo sorprendente? Son datos abstractos que buscan una representacin concreta?
Junto con sto, al ya poseer todos los antecedentes recopilados en el muestreo, se puede decidir qu elementos incluir y cuales eliminar, por lo tanto otro set de preguntas sera:

Se deben incluir todos los elementos decorativos o slo los ms representativos? Deben aplicarse texturas para simular objetos, o deben construirse mediante polgonos? Ser necesario utilizar texturas o colores puros en los elementos representados?
Aqu es importante la capacitacin de los integrantes del equipo de desarrollo, con el fin de que las preguntas anteriores sean respondidas en forma satisfactoria. Por lo tanto es vital formar equipos con experiencia en los distintos campos necesarios:

Retoque fotogrfico Diseo tridimensional Redes de computadores Dibujo de ingeniera
Es importante tambin incluir distintas cmaras en los archivos VRML, de forma de guiar al usuario a puntos concretos dentro de la escena sin necesidad que l tenga que hacer desplazamientos. En resumen de la etapa de diseo se obtiene la organizacin jerrquica de los objetos a modelar, por medio de los diagramas de ensamblaje; mientras que todo lo relacionado con el aspecto dinmico e interaccin entre los objetos que pueblan el mundo y stos con el usuario, se obtiene mediante los diagramas de transicin de estados y de interacciones.
CONSTRUCCIN
En caso de haberse hecho con cuidado los pasos anteriores, sta fase se debe hacer con facilidad y sin ninguna dificultad imprevista.
Pgina 101 de 116
Se puede construir de cuatro maneras:

Digitando el cdigo completo Usar una herramienta de desarrollo Transformando un archivo de un formato adecuado a VRML en forma directa Combinar todas las anteriores
A continuacin se comentarn cada una de stas formas:

DIGITACIN DE CDIGO COMPLETO
El digitar el cdigo completo puede resultar una buena o mala idea dependiendo del tipo de objeto a modelar y de los requerimientos previamente establecidos: Si se trata de un proyecto en el que se busca ms que nada un nfasis pedaggico hacia VRML, sin importar lo que represente la aplicacin final, queda claro que aprender el cdigo es importante; si se trata de un proyecto profesional en el que los plazos de entrega son importantes y en donde hay formas muy complejas, que con la digitacin completa del cdigo pueden llegar a ser inmanejables, la idea anterior no es la mejor. En realidad un fin mucho ms til para un profesional de la informtica en el sentido de conocer la especificacin VRML es lograr que se pueda crear SW modelador de VRML en base a la especificacin entregada, y tambin el poder ser capaz de comprender y modelar los fenmenos de dependencia de movimientos y organizacin de componentes en forma jerrquica presentes en un desarrollo de proyectos de realidad virtual, ya sea usando VRML o no.
HERRAMIENTA DE DESARROLLO
Las herramientas de desarrollo VRML presentan una interfaz al usuario que no necesariamente est relacionada con los conceptos puros de VRML, por ejemplo se dice: "copiar un objeto", cuando en realidad lo que se est haciendo es nombrar un nodo, y posteriormente instanciarlo (DEF/USE). En este sentido las herramientas estn ms orientadas a personas dedicadas al diseo asistido por computador, ms que a un informtico. Pero la ayuda que entregan al permitir que formas complejas puedan ser llevadas a VRML con solo "arrastrar y soltar", las hacen completamente imprescindibles a la hora de construir un proyecto complejo. En caso de trabajar con herramientas de desarrollo es muy importante elaborar una correcta estrategia para elegir las mejores, ya que en este caso se puede presentar una clara falta de interoperatibilidad entre las distintas herramientas. Es
Pgina 102 de 116
imposible asegurar compatibilidad completa entre todas las herramientas, vale decir, lograr que la salida de una sea una entrada vlida para otra.
Im g 1_11
Para determinar las herramientas en la fase de construccin se puede tomar un modelo simple y aplicarle todas las herramientas a utilizar, y de esta manera advertir cualquier dificultad de conversin que surja en el proceso. El resultado ideal sera aquel en donde los objetos pasarn herramienta por herramienta sin ningn cambio perceptible. En este sentido existen ciertos detalles interesantes, por ejemplo para dibujar una caja roja con cdigo VRML bastara con digitar:
#VRML V2.0 utf8 Shape{ appearance Appearance{ material Material{diffuseColor 1.0 0.0 0.0} } geometry Box{ size 2.0 2.0 2.0 } }
Si es pasado por Internet3D Space Builder, el resultado sera:

#VRML V2.0 utf8 (Created By ISB 2.1) # This file was created with Internet3D Space Builder v2.1. # According to License Agreement, you may not remove or modify this notice. # Internet3D Space Builder (C) 1996, 1997 ParaGraph International, Inc. # http://www.paragraph.com # Last modification: [Thu Jul 17 23:26:55 1997]
Pgina 103 de 116
WorldInfo { info [ "LastSaveBy: Jose Emilio" ] } DirectionalLight { direction -0.2 -0.6 -0.8 } Group { # children: 2 children [ Shape { appearance Appearance { material Material { diffuseColor 1 0 0 } } geometry IndexedFaceSet { # faces: 6 convex FALSE colorPerVertex FALSE coord DEF Label_000 Coordinate { point [ -1 1 1, 1 1 1, 1 1 -1, -1 1 -1, -1 -1 -1,
Pgina 104 de 116
1 -1 -1, 1 -1 1, -1 -1 1 ] } coordIndex [ 0, 1, 2, 3, -1, 4, 5, 6, 7, -1, 7, 6, 1, 0, -1, 6, 5, 2, 1, -1, 5, 4, 3, 2, -1, 4, 7, 0, 3, -1 ] } } ] } # Faces total: 6 # Facesets total: 1
Lo nico que se hizo fue abrir el archivo original, guardarlo tal cual y cerrar el programa, sin embargo el cambio tanto en tamao, como en aplicacin de cdigo es radical. Mientras en el primer archivo se usa un nodo predeterminado por el estndar VRML para dibujar una caja (Box), el SW construye la caja a partir de caras (polgonos), definidas por un conjunto de puntos, adems de agregarle luz, la que incluso puede llegar a ser perjudicial, ms que beneficiosa, dependiendo del tipo de utilidad que se le quiera dar al modelo. Es importante sealar que no existe herramienta VRML "perfecta", cualquier proyecto VRML complejo que se precie requerir un adecuado ajuste "a mano",
Pgina 105 de 116
en los archivos VRML generados por stas. Por ejemplo en el caso anterior de la caja, si la luz molesta para contemplar el color rojo del cuadro, lo que hay que hacer es quitar las lneas de cdigo del nodo DirectionalLight y se podr ver normalmente.
TRANSFORMACIN DE ARCHIVOS
Hasta el momento se ha trabajado pensando que se debe de modelar todo, partiendo de cero. Sin embargo existe la posibilidad que ya exista un trabajo 3D acerca de lo que se desea modelar y que por lo tanto slo sea necesario hacer una adecuada transformacin de ese archivo a VRML. En este sentido existen herramientas (una de las cuales se detallar en el captulo siguiente), que permiten a partir de un formato estndar (ej. dxf, 3ds), transformar el archivo a VRML directamente, sin necesidad de ningn paso adicional. Con esto se permite un gran ahorro en tiempo ya que despus slo bastara refinar detalles.
INTEGRACIN DE ENFOQUES
La combinacin de los tres enfoques, o de dos cualesquiera de stos, resulta ser la mejor eleccin en caso de tratarse de un proyecto profesional, sto porque se usa todo el potencial de las herramientas, junto con arreglar "a mano" algunos detalles que la herramienta no haya dejado a nuestra plena satisfaccin. Por lo tanto depender de la habilidad del constructor el poder crear una correcta amalgama de stos enfoques y de esa manera optimizar los resultados. Por lo tanto de esta etapa se obtiene el modelo virtual descrito en la etapa de especificacin.
PRUEBAS
Como se ha dicho VRML no es un lenguaje de programacin, por lo tanto no se compila antes de lanzarlo. Por lo tanto cualquier deteccin de errores en la sintaxis de estos archivos se conocer recin cuando stos se estn cargando en memoria. En este sentido es importante que el browser a usar permita la deteccin de errores de sintaxis. Cosmoplayer de Silicon Graphics, es el browser que presenta mejor comportamiento en este sentido, ya que al detectar un error de sintaxis lo comunica en una ventana indicando el nmero de lnea.
Pgina 106 de 116
Tambin pueden haber problemas por nodos que no sean soportados por los browsers, por ejemplo Cosmoplayer an no detecta el nodo Text, por lo que cualquier mencin de ste en un archivo no es considerada. En cuanto al color es importante comprobar los colores tras aplicar las luces, pues los objetos reflejan la luz de manera distinta en funcin de las fuentes de luz que sobre ellos incidan. En resumen las pruebas permitirn apreciar si el resultado obtenido es el esperado o no y si efectivamente se ha logrado una representacin reconocible con el modelo original.
PUBLICACIN
Aqu simplemente se coloca el archivo VRML en un servidor web. Aqu se puede presentar una contradiccin en la que se tenga un mundo simple pero con un Mbyte de mapas de textura, lo que retarda enormemente la carga del archivo, estos aspectos deberan ya haberse tratado tanto en las etapas de especificacin como en la de diseo. Finalmente se debe tomar en cuenta que un mundo VRML debe estar completamente cargado en la memoria del computador para su adecuada visualizacin, por lo que el exceso en el tamao de un archivo VRML puede producir distintos resultados como el hecho que el browser no cargue el escenario virtual o que el computador se quede "pegado". Existen browsers que en este aspecto presentan la facilidad de poder cargar archivos VRML previamente comprimidos en formato gzip. En resumen se obtiene un sitio web que tiene una caracterstica muy particular, el hecho de ser realidad virtual la cual puede interactuar con el usuario en tiempo real. Desde el muestreo en adelante se puede considerar al proceso de desarrollo VRML como un ciclo iterativo.
Img 1_12
Aqu es importante destacar que la duracin de estas etapas es variable dependiendo del tipo de proyecto y los recursos que se dispongan. Por ejemplo si del muestreo se han obtenido trabajos previos de modelamiento 3D en Autocad
Pgina 107 de 116
para un proyecto arquitectnico la construccin se limitar a transformar estos archivos a VRML y acomodarlos adecuadamente, por lo tanto esa etapa sera relativamente breve. Por el contrario si no existiera nada previo, se necesita obligatoriamente modelar todo, y dependiendo del nivel de detalle exigido, la etapa de construccin sera la ms larga. Igualmente en el caso del diseo, si se est frente a un proyecto arquitectnico modelando una casa, el diseo se limitara solamente al diagrama de ensamblaje, ya que una casa es un elemento esttico; y al mismo tiempo las relaciones jerrquicas entre sus componentes son fciles de detectar. Sin embargo si correspondiera proceder a modelar el comportamiento de un volcn en erupcin, sera necesario adems del diagrama de ensamblaje, hacer un diagrama de interacciones que permita entender los eventos involucrados en el escurrimiento de lava volcnica y cmo sto afectara al entorno circundante. Por lo tanto aqu el estudio debe ser muchsimo ms detallado y por lo tanto se requerir ms tiempo.
CONSIDERACIONES ADICIONALES ESPACIO REALES
Es importante recalcar que al disear un mundo virtual se debe efectivamente cumplir con lo que se espera, o lo que es lo mismo, crear un espacio que se comporte como si fuera real, es importante no perder el sentido de la frase realidad virtual.
TECHOS Y PISOS
En la gran mayora de los mundos VRML que estn poblando la red se puede apreciar el entrar a un universo aparentemente ingrvido, en donde un mundo est flotando. Un piso, por muy humilde que sea, ayuda grandemente a lograr una referencia natural para una exploracin ms elegante del mundo virtual.
CMARAS
Como ya se ha sealado, es importante el uso de cmaras para guiar al usuario hacia los puntos de inters, o ayudarlo a encontrarse cuando se encuentre perdido.
HTML
Conviene tener una introduccin hacia los mundos virtuales mediante una pgina HTML que explique qu es lo que va a encontrar, con qu browser se consigue
Pgina 108 de 116
un mejor resultado para explorarlo, y en qu versin del VRML est hecho. Todo esto le permitir al usuario no cargar mundos que a la postre le resulten poco interesantes, o intentar cargar un mundo usando un browser incompatible con la versin para la cual ste ha sido modelado (ej. al intentar cargar un archivo VRML 2.0, con Live3D, el archivo bajar, pero no se apreciar nada, ya que ese browser ha sido creado para VRML 1.0).
COMPRESIN DE ARCHIVOS
Una ventaja clara de VRML es que son archivos escritos en formato de texto, por lo que al comprimirlos se pueden reducir hasta en un 80% del original, en general para archivos de ms de 50 Kbyte conviene realizar esta compresin la cual se realiza por medio del formato gzip, que es el que reconocen los browsers VRML.
PROPOSICION TEMA MEMORIA DE TITULO

Profesor Patrocinante: Yussef Farran. Comisin 1: Jorge Lpez. Comisin 2: Javier Vidal. Alumno: Jos Muoz. Titulo: Estudio y desarrollo de aplicaciones VRML. Descripcin: VRML es un estndar web que permite penetrar a travs de mundos virtuales en el ambiente de Internet, logrando de esta manera fusionar dos tecnologas aparentemente sin relacin alguna: Realidad virtual e Internet. Dentro de este contexto se han entregado dos especificaciones del estndar VRML: VRML 1.0, el cual bsicamente consista en entregar "pginas html tridimensionales", y VRML 2.0 o tambin denominado "Moving Worlds", el cual perfeccion a su predecesora en aspectos tales como la deteccin de colisiones (chocar con un objeto) y la creacin de ambientes
Pgina 109 de 116
interactivos. Especificaciones de VRML en sus dos versiones han sido profusamente divulgadas a travs de la web, junto con una gran cantidad de sitios VRML visitados cada da con mayor frecuencia, sin embargo an no se presentan con la misma claridad metodologas concretas de desarrollo de aplicaciones usando este estndar, que nos pudieran dar un punto de partida claro y objetivo para el inicio de un proyecto de realidad virtual con VRML, el cual nos permitira tenerlo a travs de Internet y de esta forma poder aprovechar todas las ventajas y potencialidades anexas (un arquitecto podra tener su proyecto modelado y recibir sugerencias y crticas de otros colegas, logrando un grupo de trabajo no limitado por la distancia fsica; o una gran corporacin podra divulgar, de una forma ms acorde a sus propios intereses, su infraestructura, junto con su propia organizacin, sin limitarse a descripciones escritas). El siguiente trabajo tiene como propsito estudiar las herramientas y tecnologas disponibles para el desarrollo de aplicaciones usando VRML, y usar stas en la construccin de un prototipo de visita virtual a la Universidad de Concepcin.
Objetivos:
1. Estudiar y ver las potencialidades y reas de aplicacin del software para desarrollo de aplicaciones VRML, el cual se encontrar disponible en el Laboratorio de Multimedios. 2. Bsqueda de metodologas de desarrollo para proyectos de realidad virtual, que involucren uso de VRML. 3. Construir un prototipo de visita virtual a la Universidad de Concepcin, usando VRML.
Pgina 110 de 116
PROPOSICION TEMA PROYECTO DE MENCIN

Profesor Gua: Christian Weldt. Alumno: Jos Muoz. Titulo: Estudio de la tecnologa VRML. Descripcin: El tema de la Realidad Virtual ha sido objeto de muchas discusiones, pero a la vez ha provocado una verdadera revolucin dentro de los cnones normales de diseo por computador. Tambin ha sido inspiracin de ms de alguna pelcula o novela en la cual el tema ha sido tocado desde una perspectiva ldica hasta una apocalptica. Sin embargo el verdadero sentido de lo que se debe considerar como las utilidades de esta tecnologa no han sido debidamente difundidos fuera de los ambientes estrictamente computacionales. Dentro de toda la vorgine de tendencias y tecnologas de la Realidad Virtual VRML aparece como una posibilidad de tener mundos virtuales a travs del Web de una forma relativamente accesible a aquellos usuarios y diseadores interesados
Pgina 111 de 116
en lograr una interaccin ms fluida, dinmica y "sensorial" a travs del Web. Basta solamente con imaginarse navegando a travs del Web sin tener que hacer clic en palabras subrayadas de un documento HTML, sino que abriendo puertas que pasan de una habitacin a otra dentro de un edificio virtual que representa el ciberespacio del Web, al hacer clic sobre otros objetos podemos ser transportados hacia otros sitios VRML.
Objetivos:
1. Especificar y documentar el estndar VRML. 2. Seleccionar e instalar una herramienta de desarrollo VRML. 3. Realizar una aplicacin demostrativa.
APLICACIN:
La aplicacin desarrollada se realiz con el modelador Internet3d Space Builder, el cual ha sido creado por ParaGraph International. Esta herramienta soporta el estndar 2.0 y es WYSIWYG. Al ser la aplicacin desarrollada en versin 2.0 se necesita un browser que permita soportar esto, por lo que se ha recurrido a CosmoPlayer desarrollado por Silicon Graphics, el cual tambin soporta los archivos de 1.0. Tanto visualizador como modelador son versiones beta que corren bajo Windows 95. La aplicacin en s consisti de un ambiente en el cual existe una oficina conformada por un escritorio, una silla, una lmpara sobre el escritorio y un estante para los libros. Todo aquello son objetos predefinidos por el modelador. En el escritorio al hacer clic sobre los cajones podemos tener acceso a otras pginas o a otros archivos VRML. Podemos navegar a travs de este ambiente, alejarnos, acercarnos, vistas frontales, por detrs; todo ello a partir de maniobras con el cursor.
Pgina 112 de 116
Las herramientas en s soportan muchas de las potencialidades de VRML, pero no son absolutamente perfectas (por ej. ISB no presenta una facilidad al usuario para la creacin de sus propios objetos as como de la capacidad "sensorial", entendindose sta como el uso de los nodos sensores). Esta aplicacin se puede referenciar a travs de: http://www.jose-emilio.com/estudios/oficina.wrl
PROTOTIPO VISITA VIRTUAL CAMPUS UDEC

El siguiente prototipo presenta una vista parcial del campus concepcion de la Universidad de Concepcin. Solo se han incluido algunas locaciones. Para navegar adecuadamente se debe tener al menos Netscape 3.0 o MS Internet Explorer 3.0 , junto a lo anterior se requiere tener el plugin Cosmoplayer (versin 2.0 Beta 1). Ademas se recomienda un PC con procesador Pentium de 120 Mhz y 32 Mb de RAM como mnimo (se recomiendan 64 Mb), o una estacin Silicon Graphics. Si ya se cumple con todos esos requisitos disfruten la experiencia, se recomienda seguir las cmaras sealizadas adecuadamente por Cosmoplayer y esperar a que el prototipo baje completamente antes de empezar la navegacin.
Pgina 113 de 116
Universidad de Concepcion (Campus Virtual)
BIBLIOGRAFA:
LIBROS:
Proyecto de Mencin "Desarrollo de Pre-Proyecto de Realidad Virtual"
Vernica Snchez, Profesor Gua: Csar Gonzlez.

REVISTAS:
PC Magazine.
Pgina 114 de 116
WORLD WIDE WEB:

http://vag.vrml.org/VRML2.0/DRAFT3/ http://vag.vrml.org/VRML2.0/FINAL/ http://vrml.sgi.com/cosmoplayer/ http://vrml.wired.com/vrml.tech/vrml10-3.html http://www.dnx.com/products/lr/index.html http://www.netscape.com/comprod/products/navigator/live3d/index.ht ml http://www.paragraph.com/ISB/INDEX.html http://www.sdsc.edu/siggraph96vrml http://www.sdsc.edu/vrml/ http://www.sics.se/dive/ http://www.webcom.com/~radiance/
CONCLUSIONES:
El lenguaje VRML aparece ante el usuario programador como un lenguaje orientado a objetos, fcil de entender, pero demasiado extenso. Las especificaciones del lenguaje han sido desarrolladas en base a discusiones de propuestas entregadas por los diseadores, las cuales con sto, ha permitido un gran dinamismo en el proceso de entrega de un estndar definitivo, sin embargo an no se ven las cosas en un nivel estable. Especialistas en el rea recomiendan que cuando ocurra esto se prueben los diversos browsers y plug-in con mundos hechos sin los nodos propietarios (vale decir aquellos definidos por prototipos),
Pgina 115 de 116
con el propsito de lograr una adecuada evaluacin de estas herramientas, as tambin como de los modeladores. Al buscar las herramientas para lograr el desarrollo de aplicaciones as como su visualizacin, hemos encontrado que la diversidad de estas exige un juicio objetivo, el cual es muy difcil de lograr dado el sesgo que entregan las propias especificaciones de las empresas desarrolladoras.
Pgina 116 de 116

El Lenguaje VRML - 2

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

El Lenguaje VRML - 2

Încărcat de

Drepturi de autor:

Formate disponibile

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

ESPECIFICACIN DEL ESTNDAR VRML 2.0

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

CONSIDERACIONES ACERCA DE LA VERSIN UTILIZADA:

Un archivo VRML contiene, bsicamente:

Todo esto en su conjunto permite definir un mundo tridimensional.

Prototipos definidos usando PROTO o EXTERNPROTO. Nodos. Declaraciones de rutas (ROUTE).

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

PROTOCOLO PARA LENGUAJES SCRIPT:

EXTENSIN DEL ARCHIVO Y MIMETYPE:

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

EJEMPLO DE UN ARCHIVO VRML:

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Es un campo MFInt32 conteniendo tres valores.

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

El valor inicial de un eventOut SFRotation es (0 0 1 0). El valor inicial de un eventOut MFRotation es [ ].

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Es un campo MFVec2f, fooVec2f, con dos vectores vlidos.

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

El valor inicial de un eventOut SFVec2f es (0 0). El valor inicial de un eventOut MFVec2f es [ ].

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Un nodo tiene las siguientes caractersticas:

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Este campo especifica el valor del radio basal del cono.

Este campo especifica el valor de la altura del cono.

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Este campo especifica el valor de la altura del cilindro.

Este campo especifica el valor del radio del cono.

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Este campo especifica el valor del radio de la esfera. Ejemplo:

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Estos campos indican las dimensiones de la altura de la rejilla en las direcciones X y Z.

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Donde 0<i<xDimencion y 0<j<zDimencion.

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Metodologia del lenguaje VRML_2

Recopiladoby masrio valverde

Este campo debe contener un nodo Coordinate.