VRML

VRML
CONCEPTO
El VRML (virtual reality modeling lenguage ) es un formato de
archivo que describe objetos interactivos 3D dentro de una escena
especifica. Como tal podemos decir además que es un lenguaje no
de programación sino un lenguaje de modelamiento de escenas
tridimensionales interactivas. El VRML permite implementar
escenas estáticas o dinámicas en 3D con posibilidad de
encadenamiento de texto, sonido imágenes y vídeo. Dentro de la
arquitectura del VRML aparece un concepto interesante como lo es
el concepto de visualizador el cual como su nombre lo indica
permite presentar la escena VRML. Un visualizador básicamente es
un programa de computador que se encarga de interpretar el
código VRML y ejecutarlo en la plataforma en la que se encuentra,
permitiendo al usuario interactuar con la escena definida. Esta
forma de ejecución de un archivo VRML es ventajosa considerando
las implicaciones que tiene cargar por la red un archivo ejecutable
contar un archivo de solo texto como lo son los archivos VRML. Todo
el trabajo se deja entonces la visualizador.
ORGANISMOS CONSTITUYENTES
Los entes que colaboraron en la estandarización del worlwide fueron
la ISO (organización internacional de estandarización), la IEC
(comisión internacional electrónica), la JTC (comité técnico de
trabajo) y el consorcio VRML.
OBJETIVOS
• El VRML esta diseñado para ser utilizado sobre Internet, Intranets
o como clientes locales.
• Los formatos VRML están diseñados para integrar gráficos
tridimensionales y multimedia.
• El VRML está pensado para diversidad de aplicaciones en áreas
como ingeniería, simulación, entretenimiento, educación etc.
CARACTERISTICAS DEL VRML

EL VRML fue concebido bajo las siguientes características de
diseño:
• originalidad: los programas VRML son creados, editados y
mantenidos de manera muy sencilla mediante la manipulación
directa de los formatos fuente. presentando además la
posibilidad de importación de objeto s 3D de otros formatos
industriales.
• integrabilidad: los programas VRML permiten usar diferentes
objetos 3D formando escenas compuestas lo que a su vez
permite la reusabilidad de ambientes.
• extensibilidad: los programas VRML ofrecen la posibilidad de
adicionar nuevos elementos aun no explícitos en VRML.
• implementabilidad: los programas VRML son fácilmente
implementados bajo un amplio rango de sistemas.
• rendimiento: los elementos VRML son diseñados para brindar
optimo rendimiento bajo una amplia variedad de plataformas.
• escalabilidad: Los elementos VRML son diseñados para brindar
flexibilidad en las composiciones futuras.
• Potencial multi-usuario: facilita la implementación de ambientes
multiusuario.
• Ortogonalidad: Los elementos de VRML son independientes uno
de otro y cualquier dependencia es estructurada y bien definida.
• estructuración: Los elementos VRML tiene bien definido sus
interfaces por cuanto el uso de múltiples elementos no tiene
efectos impredecible.
ALCANCES Y LIMITACIONES
Una escena VRML es una integración básica de gráficos 3D y
multimedia los objetos integrados en una escena pueden ser
modificados en momento de ejecución a través de diferentes
mecanismos. VRML compone, encapsula y da extensibilidad a una
escena.
VRML no define dispositivos físicos u otros conceptos afines como
resolución de pantalla o dispositivos de entrada, VRML interpreta un
amplio rango de posibilidades sin particularizar sobre el uso de
ciertos elementos por ejemplo VRML no asume la existencia de
mouse en 2D.
ARCHIVOS VRML.
un archivo VRML puede contener:
a. Una escena compuesta de objetos
b. un conjunto de posibilidades multimedia
c. encadenamiento a otros archivos y aplicaciones.
d. mecanismos de modificación del comportamiento de los objetos.
DEFINICIONES:
nodo: componente esencial de una escena en VRML. Un nodo es
una abstracción de conceptos y objetos reales. Esta compuesto por
campos y eventos que determinan las características y
comportamiento del nodo.
nodos de agrupación: son nodos cuya tarea primordial es agrupar
otros nodos, con el fin primordial de establecer un comportamiento
particular sobre ellos.
campo: es una propiedad, característica, atributo o estado del nodo.

Un campo puede ser de diferentes clases de datos y existe un
número fijo campos para cada dato.
nombre del campo: identificador propio de cada campo dentro de
un nodo.
campos expuestos: son campos que pueden recibir eventos de
entrada para cambiar sus valores y generar eventos de salida
cuando sus valores cambian.
evento: es un mensaje enviado de un nodo a otro, lo cual estimula

el cambio de los campos de un nodo determinado. Un evento tiene
que ver con el tiempo del mensaje y el valor de un campo.
eventos en cascada: secuencia de eventos inicializados por un
script o sensor y propagados de un nodo a otro a lo largo de un
ruta.
evento de entrada: receptor lógico atado a un nodo el cual recibe el
evento.
evento de salida: emisor lógico atado a un nodo desde el cual se
envía el evento.
activación: es la generación de un evento isActive por parte de la
interacción del usuario, paso del tiempo, u otros eventos.
avatar: representación del usuario en el mundo VRML. Utilizada
para calcular aspectos tan importantes como la colisión.
marcación: es una línea recta pasada en una dirección determinada
en tal forma que ella es una guía para los sensores en la escena y
conforma a la mayor proximidad generar eventos.
nodos atados: son nodos que pueden tener varias instancias en una
escena pero solo una de ellas esta activa.
Modelos de color: VRML utiliza el modelo de color RGB con el cual
define los colores y el modelo de color HSV con el cual realiza
interpolación de colores.
Escogencia: eliminación de objeto o partes de objetos que en la
escena no se verán.
sensores ambientales: son dispositivos que generan eventos que
con miras a modificar ele estado de una escena. dependiendo de la
ubicación del observador o determinados objeto en el ambiente
VRML.
HSV: valor de saturación hue.
hiperencadenamiento: referencia a un URL (Uniform Resource
Locator) a través de un nodo de un nodo de encadenamiento.
in-lining: es el mecanismo por el cual un archivo VRML es incluido
jerarquicamente en otro
instancia: es una referencia de un nodo definido
nodos de interpolación: son los nodos sobre los cuales se puede
implementar interpolaciónes lineales.
ciclo: secuencia de eventos.
message: cadena enviada entre nodos en la ocurrencia de un
evento.
puntero: es una localización y dirección en el mundo virtual definido
por el dispositivo apuntador que el usuario generalmente utiliza o
para interactuar con la escena VRML
prototipo: definición de un nuevo tipo de nodo en función de nodos
ya definidos
interface publica: definición formal de un nodo.
rgb: es el modelo de color usado en VRML para la especificación del
color en su combinación de rojo verde y azul.
ruta: conexión entre un nodo que genera un evento y un nodo que
recibe un evento.
tiempo: es la medida del tiempo empezando desde 00:00:00
febrero de 1970.
timestamp : parte del mensaje que describe el tiempo de ocurrencia
del evento.
observador: una localización, dirección y ángulo de vcisió en un
mundo virtual limitada por la parte de la escena presentada por el
visualizador.
documento del servidor VRML: es un computador que se encarga de
transmitir archivos VRML y el soporte de los archivos.
Archivo VRML: es un archivo con un stream de datos o stream de
caracteres UTF-8 que contiene la información codificada de acuerda
a las normas ISO/IEC 14772.
ambientes VRML: es la colección de uno o mas archivos VRML que
describen escenas 3D interpretadas por el visualizador quien se
encarga de desplegarlas
objeto: son los nodos sobre los cuales están definido una serie de
procedimientos y características propias del VRML.
ESTRUCTURA DE UN ARCHIVO VRML
Un archivo VRML esta compuesto de los siguiente elementos: el
encabezamiento, la escena gráfica, los prototipos y el enrutamiento
de eventos. Cada uno de estos elementos son procesados por el
visualizador en el cual se carga el archivo VRML una vez
procesados los elementos que componen el archivo vrml es
presentado.
Encabezamiento: el encabezamiento de un archivo VRML
sintácticamente se escribe como:
#VRML V2.0 <tipo de codificación> [comentarios opcionales]
<línea de terminación>
El encabezamiento es una línea codificada en formato UTF-8 (8-bit
UCS Transformation Format) es decir en formato de transformación
8 bits UCS (Universal multiple-octet coded Character Set) que a su
vez es el conjunto de caracteres codificados universal múltiple
octeto.
la información del encabezamiento #VRML, V2.0, tipo de
codificación y comentario opcional deben ir separadas por un
espacio. El tipo de codificación se debe especificar sintácticamente
como utf8 definido en la norma ISO 10646-1 indicando el formato
internacional que se va a seguir o cualquier otro valor definido en la
norma ISO/IEC 14772. Cualquier carácter después del tipo de
codificación es ignorado por el visualizador por cuando se puede
asumir como comentario. La línea de encabezamiento finaliza con
un carácter alimentación de línea 0x0A o el carácter enter 0x0D.
#VRML V2.0 utf8 esto es el encabezamiento.
escena gráfica: la escena gráfica esta compuesta por nodos los
cuales describen objetos y sus propiedades. La escena gráfica esta
jerárquicamente constituida como una agrupación geométrica
provisionando así una representación audiovisual coherente y
manejable en cuanto a los mecanismos de generación de eventos
se refiere.
prototipos: El manejo de los prototipos permiten extender el
concepto de objeto que se manejan en VRML. los prototipos pueden
ser definidos interna o externamente al archivo VRML. los prototipos
pueden ser definidos en términos de otros nodos VRML o pueden
ser definidos usando mecanismos de extensión proporcionados por
el visualizador en el que se este presentando la escena. Una del as
características mas interesantes de los prototipos es que son
independientes del visualizador que se utilice por el formato
estándar que se maneja en los archivos VRML.
Enrutamiento de eventos: Algunos nodos VRML generar eventos en
respuesta a cambios en el ambiente o interacciones del usuario. los
eventos se constituyen en elemento clave para generar la
interacción con una escena VRML a través del cambio de los
estados de los nodos
que repercutirán en la dinámica de la escena. El VRML proporciona
los nodos script que dan gran flexibilidad al manejo de eventos
pues ellos permiten declara eventos tanto de entrada como de
salida y manejar internamente como procesos lo que esta pasando
en la escena con los eventos de entrada y comunicar una respuesta
al medio con los eventos de salida. Los script tiene la gran
propiedad también de adicionar o eliminar rutas dinámicamente y
en consecuencia modificar radicalmente la topología del
enrutamiento de eventos.
Un modelo de eventos ideal, procesa todos los eventos
instantáneamente en el orden que son generados. El Timestmp es
el tiempo en el que el evento es lanzado a un nodo lo cual tiene
dos propósitos. En primer lugar suministrar un mecanismo
cronológico lo que puede ser usado para efectos de sincronismo y
en segundo lugar suministra un mecanismo de enlace con miras a
suministra ronden entre tiempos y eventos.
PRESENTACIÓN E INTERACIÓN DE UNA ESCENA VRML
La interpretación, ejecución y representación de un archivo VRML
será expresada bajo un mecanismo conocido como visualizador
quien se encarga de desplegar las formas y sonidos en la escena
gráfica y suministrar soporte a los formas de interacción del usuario
con el ambiente VRML. Esta representación gráfica es conocida
como mundo virtual el cual es navegado por un humano o entidad
mecánica conocida como usuario. La escena desplegada se
presentará de acuerdo a la ubicación y dirección del observador
humano o mecánico. El visualizador puede suministrar paradigmas
de navegación como la traslación(walking), el vuelo (flyign) que
habilita al usuario a mover el observador a través del mundo
virtual. Dado que el visualizador soporta los mecanismo de
interacción del usuario con el mundo virtual otra posibilidad
importante de interacción del ambiente virtual lo constituyen los
sensores nodos pensados especialmente para la manipulación de la
escena ya sea desde el mismo ambiente o como usuario. La
representación visual de objetos geométricos en ambientes VRML
permite dar a los objetos modelos conceptuales como el de
iluminación y propiedades de apariencia que configuran no solo una
escena 3D sino que le imprimen características coherentes muy
cercanas a la realidad.
Componentes de un visualizador: un visualizador es descrito como
una aplicación que permite no solo la presentación de una escena
3D sino que también permite la interacción con la misma. un
visualizador tiene tres componentes esenciales: el parser, la
escena gráfica y al presentación audiovisual. El componente Parser
lee el archivo VRML y crea la escena gráfica. La escena gráfica es
una composición jerárquica de nodos y conexión entre los mismos,
se encarga de manejar los eventos y cambios que se presenten en
la escena producto de los enrutamientos que tengan esos eventos y
que modifique las propiedades de los nodos en escena. el
componente de presentación audiovisual renderea los objetos 3D y
maneja del sonido realimentando la escena con las posibles
modificaciones que se presenten.
entradas
Archivo VRML
usuario
VISUALIZADOR VRML
PARSER
prototipos Constructor
de nodos
ESCENA GRAFICA
Jerarquización en
transformaciones Ruta gráfica
Máquina * sensores
de * escript
ejecución * interpolaciones
PRESENTACION AUDIO/VISUAL
DATOS QUE SE PUEDEN DEFINIR EN VRML

USUARIO
SFBool
SFBool es una campo o un evento que contiene un valor booleano.
Los SFBools pueden tener un valor falso (FALSE) o verdadero
(TRUE).
Ejemplo:
field SFBool dato
exposedFiel SFBool dato
eventIn SFBool dato
eventOut SFBool dato
dato=TRUE
dato=FALSE
SFColor / MFColor
SFColor especifica una tripleta de color RGB. MFColor cero o más
tripletas de color RGB. Cada color en VRML se escribe como una
tripleta RGB en donde la combinación de rojo, verde y azul son
números en punto flotante expresados en el formato ISOC. en
donde cada número esta en un rango de 0.0 y 1.0.
field SFColor dato field MFColor dato

exposedFiel SFColor dato exposedFiel MFColor
eventIn SFColor dato dato
eventOut SFColor dato eventIn MFColor dato
eventOut MFColor dato
dato = 1 0 0
dato = 1 0 0, 0 1 1, 0.1
0.5 1
SFFloat / MFFloat
SFFloat especifica un número en punto flotante. MFFloat especifica
cero o más números en punto flotante. Tanto SFFloat y MFFloat son
escritos en el formato de punto flotante ISO C.
field SFFloat dato field MFFloat dato

exposedFiel SFFloat dato exposedFiel MFFloat dato
eventIn SFFloat dato eventIn MFFloat dato
eventOut SFFloat dato eventOut MFFloat dato
dato = 1.5666 dato = 1.23 1.34 2.34
SFInt32 / MFInt32
SFInt32 especifica un entero de 32 bits, MFInt especifica cero o
más enteros de 32 bits. Lo datos entero se escriben en VRML como
decinales o hexadecimales.
field SFInt dato field MFInt dato
exposedFiel SFInt dato exposedFiel MFInt dato
eventIn SFInt dato eventIn MFInt dato
eventOut SFInt dato eventOut MFInt dato
dato = 15 dato = -5 4 0x6
SFRotation / MFRotation
SFRotation especifica una determinada rotación. MFRotation
especifica cero o más rotaciones. Una SFRotation se escribe en los
archivos VRML con cuatro valores flotantes del formato ISO C y
además separados por un espacio. Los tres primeros Valores
especifican un eje de rotación normalizado vector alrededor del cual
se efectúa la rotación. El cuarto valor especifica la rotación que se
debe realizar y esta expresada en radianes. MFRotation especifica
cero o más rotaciones.
field SFRotation dato field MFRotation dato

exposedFiel SFRotation exposedFiel MFRotation
dato dato
eventIn SFRotation dato eventIn MFRotation dato
eventOut SFRotation eventOut MFRotation
dato dato
dato = 1 0 0 3.14 dato = 0 1 1, 0 1 1, 0 1

1
SFString / MFString
SFString y MFString contienen cadenas formateadas con la norma
UTF-8, SFString especifica una cadena de caracteres mientras
MFSTRing especifica cero o más cadenas de caracteres. Cualquier
carácter puede aparecer dentro de las comillas incluso las comillas
mismas para lo cual se debe anteponer un backslash para que no
sean reconocidas como el carácter que esta encerrando la cadena
de caracteres.
field SFString dato field MFString dato

exposedFiel SFString exposedFiel MFString
dato dato
eventIn SFString dato eventIn MFString dato
eventOut SFString dato eventOut MFString dato
dato = “VRMLÓ dato = “VRMLÓ,
“\“VRML\ÓÓ
SFTime
SFTime especifica un valor de tiempo. El timepo en VRML es escrito
con numeros en punto flotante de doble precision en el formato de
ls ISO C. Los valores de tiempo son especificados como el número
de segundos desde enero 1 de 1970, 00:00:00
field SFTime dato

exposedFiel SFTime dato
eventIn SFTime dato
eventOut SFTime dato
dato = 0
SFVec2f / MFVec2f
SFVect2f espefica un vector en dos dimensiones. MFVect2F
especifica cero o más vectores en dos dimensiones. tanto SFVect2f
como MFVect2f son vectores escritos en VRML como valores en
punto flotante según el formato ISO C. separdos poe espacios en
blanco.
field SFVect2f dato field MFVect2f dato

exposedFiel SFVect2f exposedFiel MFVect2f
dato dato
eventIn SFVect2f dato eventIn MFVect2f dato
eventOut SFVect2f dato eventOut MFVect2f dato
dato = 1.3 2 dato = 1 3.1, 2 5.3
SFVec3f / MFVec3f
SFVec3f especifica un vector en tres dimensiones. MFVec3f
especifica cero o más vectores en tres dimensiones. SFVec3f y
MFVec3f se escriben en un archivo VRML como valores en punto
flotante del formato ISO C. separados con espacios:
field SFVect3f dato field MFVect3f dato
exposedFiel SFVect3f exposedFiel MFVect3f
dato dato
eventIn SFVect3f dato eventIn MFVect3f dato
eventOut SFVect3f dato eventOut MFVect3f dato
dato = 1.3 2 dato = 1 3.1, 2 5.3
Transform
Transform {
eventIn MFNode addChildren
eventIn MFNode removeChildren
exposedField SFVec3f center 0 0 0 # (-∞,∞)
exposedField MFNode children []
exposedField SFRotation rotation 0 0 1 0 # [-1,1],(-
∞,∞)
exposedField SFVec3f scale 1 1 1 # (0, ∞)
exposedField SFRotation scaleOrientation 0 0 1 0 # [-1,1],(- ∞,
∞)
exposedField SFVec3f translation 000 # (-∞,∞)
field SFVec3f bboxCenter 000 # (-∞,∞)
field SFVec3f bboxSize -1 -1 -1 # (0,
∞) or -1,-1,-1
}
El nodo Transorm es un nodo de agrupación que define un sistema

de coordenadas para sus nodos hijos.
Los eventos de entrada addChildren y removeChildfre especifican la
posibilidad sobre un nodo Transforn agregar y quitar nodos que se
encuentren en el children del nodo Trasnform.
Los campos bboxCenter y bboxSize especifican un cubo que

encierra los hijos del nodo Transform. Estos dos campos son usados
para efectos de optimización. Los valores por defecto le especifican
al browser que el calcule los valores que empleara.
Los campos traslation, rotation, scale, scaleOrientation y center
definen las transformaciones geométricas así:
• una posible escala no uniforme sobre un punto arbitrario.
• Una rotación sobre un punto arbitrario y eje.
• Una traslación.
El campo center especifica un offset de traslación del origen del

sistema coordenado local.
El campo rotación especifica una rotación del sistema coordenado.
El campo scale especifica la aplicación de una escala sobre el
sistema coordenado. Estos campos escala deben ser mayores de
0.0.
El campo scaleOrientation especifica una rotación del sistema
coordenado antes de la escala.
El campo traslation especifica una traslación del sistema
coordenado.
Dado un punto P, este es transformado a P’ así:
P' = T × C × R × SR × S × -SR × -C × P
Donde: C (center), SR (scaleOrientation), T (translation), R

(rotation), y S (scale).
Shape
Shape {
exposedField SFNode appearance NULL
exposedField SFNode geometry NULL
}
El nodo Shape tiene dos campos el campo appearance y el campo
geometry los cuales son usados para usar objetos rendereados en
el mundo.
El campo appearance contiene nodo Appearance que especifica los
atributos visuales “material y texturaÓ que serán aplicados a la
geometría.
El campo gemetry contiene un nodo geometría la cual es
rendereada con la apariencia.
Si la geometría es null no se pinta nada.
Geometrias
Sphere
Sphere {
field SFFloat radius 1 # (0,∞)
}
El nodo esfera especifica una esfera centrada en (0,0,0) en sistema
coordenado local. El campo radius especifica el radio de la esfera
que debe ser >0.0
Box
Box {
field SFVec3f size 2 2 2 # (0, ∞)
}
el nodo Box especifica un cubo paralepipedo rectangular centrado
en (0,0,0) en sistema coordenado local alineado con los ejes. Por
defecto al medida del cubo es de 2 unidades en x,y,z tomados en
cada eje desde –1 hasta 1.
Cone
Cone {
field SFFloat bottomRadius 1 # (0, ∞)
field SFFloat height 2 # (0, ∞)
field SFBool side TRUE
field SFBool bottom TRUE
}
el nodo Cane especifica un cono centrado en sistema coordenado

local cuyo eje central se alinea al eje y.
El campo bottonRadius especifca el radio de la base del cono. El
campo height especifica la altura del cono desde el centro de la
base hasta el ápice. Por defecto el cono es de radio 1.0 unidades y
altura 2.0 unidades. con ápice en y/2 y base en –y/2.
El campo side especifica si los lados son o no creados. El campo
bottom especifica si la base del cono es dibujada o no.
Cylinder
Cylinder {
field SFBool bottom TRUE
field SFFloat height 2 # (0 ∞)
field SFFloat radius 1 # (0, ∞)
field SFBool side TRUE
field SFBool top TRUE
}
El nodo Cylinder especifica un cilindro centrado en (0,0,0) en

sistema coordenado local y con el eje central orientado en el eje y.
El campo radius especifica el radio del cilindro. El campo heigth
especifica la altura del cilindro a lo largo del eje y.
Los campos top, side y bottom especifican si se dibujan o no la tapa
superior los lados o la base respectivamente
Programa:
#VRML V2.0 utf8
Transform {
children [
Shape {
geometry Box {size 1 1 1}
}
]
}
Appearance
Appearance {
exposedField SFNode material NULL
exposedField SFNode texture NULL
exposedField SFNode textureTransform NULL
}
El nodo Appearance especifica las propiedades visuales de las

geotermias, por definición el material y textura del nodo. Los
valores para cada campo puede ser NULL de lo contrario debe
contener un nodo del tipo de propiedad.
El campo material si es especificado debe contener un nodo
Material. Si el campo material es NULL o no especificado, la
iluminación estará apagada. “todas las luces son ignoradas durante
la renderizacion de los objetos que referencian esta aparienciaÓ. Y
el color de iniluminacion del objeto es (1, 1 ,1).
El campo texture si es especificado puede contener cualquiera de

los nodos de textura ImageTexture, MovieTexture o PixelTexture. Si
el nodo texture es NULL o el campo textura no es especificado, el
objeto que referencia esta Appearance no es texturado.
El campo textureTransform, si es especificado contendrá un nodo

TextureTransform. Si el campo texture es NULL o no es especificado,
o si el textureTransform es NULL o no es especificado, el campo
texutreTransform no será afectado.
Material
Material {
exposedField SFFloat ambientIntensity 0.2 # [0,1]
exposedField SFColor diffuseColor 0.8 0.8 0.8 # [0,1]
exposedField SFColor emissiveColor 000 # [0,1]
exposedField SFFloat shininess 0.2 # [0,1]
exposedField SFColor specularColor 000 # [0,1]
exposedField SFFloat transparency 0 # [0,1]
}
El nodo Material especifica las propiedades del material de las

superficies para el nodo especificado en la geometría y es usado
por las ecuaciones de iluminación durante la renderizacion. Todos
los campos dentro del nodo material están en un rango de 0.0 a 1.0
El campo ambientIntensity especifica cuantas luces ambiente de

fuentes de luz esta superficie reflejara. La luz ambiente es
omnidireccional y depende únicamente del numero de fuentes de
luz no su posición con respecto a la superficie. El color ambientes es
calculado como:
ambinetIntensity x diffuseColor
El campo diffuseColor refleja todas las fuentes de luz VRML

dependiendo del ángulo de la superficie con respecto a la fuente de
luz. La luz mas directa sobre una superficie reflejara mas
iluminación diffuseColor.
El campo emissiveColor modela el relucimiento de un objeto. Este

puede ser usado para desplegar un modelo pre-iluminacion “donde
la energia de la luz de la escena es computado explícitamenteÓ o
por despliegue científico de datos.
Los campos specularColor y shininess determinan la iluminación

especular. Cuando el ángulo de iluminación de la superficie es
cerrado al ángulo de la superficie del observador . El specularColor
es adicionado a los cálculos de color de difusión y ambiente.
El campo transparency especifica como un objeto se vuelve

traslucido siendo 1.0 un objeto completamente invisible y 0.0 u
objeto completamente sólido.
ImageTexture
ImageTexture {
exposedField MFString url []
field SFBool repeatS TRUE
field SFBool repeatT TRUE
}
El nodo ImageTecture define un mapa de textura por especificación

de un archivo de imagen y un parámetro general para el mapeo de
geometrías. Los mapeos de textura son definidos en sistema
coordenado bidimensional (s,t) en los rangos [0.0,1.0] en ambas
direcciones. El lado inferior de la imagen corresponde al eje S del
mapa de textura, y el lado izquierdo corresponde al eje T del mapa
de textura. La parte inferior izquierda corresponde a s=0, t=0 y la
parte superior derecha corresponde a s=1, t=1.
La texura es leída del campo url especificado. Cuando el campo url
no contiene un valor es deshabilitado. Los browser soportan los
siguientes formatos:
JPEG: "JPEG File Interchange Format," JFIF, Version 1.02, 1992.
PNG: “Portable Network GraphicsÓ Specification Version 1.0, W3C
Recommendation, 1 October 1996.
CGM: ÓComputer graphics MetafileÓ for the storage and transfer of
picture description information.
GIF: "Graphics Interchange Format" - A standard defining a
mechanism for the storage and transmission of raster-based
graphics information, Version 89a, CompuServe.
Los campos repeatS y repeatT especifican como es el cubrimiento

de la textura en las direcciones S y T. Si repatS es TRUE “por
defectoÓ el mapeo de la textura es repetido hacia afuera de 0.0 a
1.0 en dirección del eje S. Si es falso las coordenadas de textura
son sujetas a atarse al eje S dentro del rango [0.0 1.0]. De la
misma forma que se comporta el campos repeaS lo hace el campo
repatT.
#VRML V2.0 utf8

#programa de experimentación con Material
Transform
{
children Shape
{
appearance Appearance
{
material Material
{
ambientIntensity 0.6
diffuseColor 0.5 0 1
emissiveColor 0.5 0 1
shininess 0.5
specularColor 0.5 0 1
transparency 0.1
}
}
geometry Sphere {radius 2.0}
}
}
#VRML V2.0 utf8

#programa de experimentacion con ImageTexture
Transform
{
children Shape
{
{
texture ImageTexture
{
url "Texture\Fire_4.gif"
repeatS FALSE
repeatT FALSE
}
}
geometry Box {size 1 1 1}
}
}
#VRML V2.0 utf8
#programa de experimentacion con Matarial y ImageTexture
Transform
{
children Shape
{
{
material Material
{
diffuseColor 100
emissiveColor 100
shininess 0.7
specularColor 100
transparency 0.5
}
{ url "Texture\Stucko_2.jpg"}
}
geometry Cone { }
}
}
MovieTexture
MovieTexture {
exposedField SFBool loop FALSE
exposedField SFFloat speed 1.0 # (-∞,
∞)
exposedField SFTime startTime 0 # (-∞,
∞)
exposedField SFTime stopTime 0 # (-∞,
∞)
eventOut SFTime duration_changed
eventOut SFBool isActive
}
El nodo MovieTexture define un mapa de textura “que contiene un
archivo de una películaÓ y los parámetros del control de la película
y el mapeo de textura. Un nodo MovieTexture puede ser usado
también como una fuente de datos de sonido por un nodo Sound.
En este caso especial el nodo MovieTexture no es usado para
rendereo.
Los mapas de textura son definidos en sistema coordenado 2D (s,t)

dentro de los rangos 0.0 y 1.0 en ambas direcciones. El lado de
abajo corresponde al eje s del mapa de textura y el lado izquierdo
de la imagen corresponde al eje t. El pixel inferior izquierdo de la
imagen corresponde a s=0.0,t=0.0 y el pixel superior derecho de la
imagen corresponde a s=1.0 t=1.0.
El campo url en el que se define la película soporta sistemas de
formato de película MPEG1 “audio y videoÓ o MPEG1 “únicamente
videoÓ.
Tan pronto la película es cargada, un evento de salida

durtino_changed es enviado. Este indica la duración de la película
en segundos. Este evento de salida puede ser leído por ejemplo pos
un nodo Script. Que determina la duración de la película. Un valor
de –1 implica que la película aun no ha sido cargada o el valor es
inutilizado por alguna razón.
Los campos expuestos loop, startTime y stopTime sirven para

determinar cuando el nodo se vuelve activo o inactivo cuando el
campo loop es verdadero se ejecuta un ciclo o un numero infinito de
ciclos hasta que su valor de verdad no sea cambiado. Los campos
starTime y stopTime sirven para indicar el inicio y final de la
activación de la película. El evento de salida isActive es genrado en
el momento en el que se activa la película enviando un valor
verdadero cuando se desactiva en isActive se envía un valor falso.
El campo expuesto speed cuan rápido al película es desplegada.

Una velocidad de 2 indica que la película se correrá dos veces mas
rápido de los normal. El campo duration_changed no es afectado
por el campo speed. Los eventos set_speed son ignorados cuando la
película esta corriendo. Una velocidad negativa implica que la
película se rodara hacia atrás.
Si un nodo MovieTexture esta inactivo cuando la película es primero
cargada, el frame cero de la textura de la película es desplegado si
la velocidad de la película no es negativa o el ultimo frame de la
textura de la película se muestra si la velocidad es negativa. Un
nodo MovieTexture desplegara el frame cero si la velocidad es cero.
Para valores positivos de velocidad, un nodo activo MovieTexture
despliega el frame dentro de un tiempo de película t así:
t = (now - startTime) modulo (duration/speed)

si la velocidad es negativa, el nodo MovieTexture despliega el
tiempo de frame de la película como:
t = duration - ((now - startTime) modulo ABS(duration/speed))
Cuando un nodo MovieTexture se vuelve inactivo, el frame

correspondinte al tiempo en el cual MovieTexture se volvió inactivo
quedara como textura.
#VRML V2.0 utf8
#experimentando con MovieTexture
Transform
{
children Shape
{
{
texture MovieTexture{url "nombre.mpg"}
}
geometry Box{}
}
}
PixelTexture
PixelTexture {
exposedField SFImage image 000
}
El nodo PixelTexture define un mapa de textura bidimensional como

un arreglo explícito de valores de pixeles y parámetros controlando
la repetición de la textura sobre la geometría.
Los mapas de textura son definidos en sistema coordenado 2D (s,t)
en los rangos de 0.0 y 1.0 en ambas direcciones. El lado de abajo de
la imagen del pixel corresponde al eje S del mapa de textura y el
lado izquierdo de la imagen del pixel corresponde al eje T del mapa
de textura. El pixel izquierdo inferior de la imagen de pixeles
corresponde a s=0.0, t=0.0 y el pixel derecho superior de la imagen
corresponde de a s=1.0, t=1.0.
Los campos repeatS y repeatT especifican como es el cubrimiento

de la textura en las direcciones de S y de T. Si repeatS es verdadero
“por defectoÓ. El mapa de textura es repetido hacia afuera de 0.0 a
1.0 en la direccion del eje s. De la misma forma para t.
#VRML V2.0 utf8

#experimentando con PixelTexture
Transform
{
children Shape
{
{
material Material{diffuseColor 1 0 0}
texture PixelTexture{image 2 2 2 0xff0000}
}
geometry Box{}
}
}
TextureTransform
TextureTransform {
exposedField SFVec2f center 00 # (-∞,∞)
exposedField SFFloat rotation 0 # (-∞,∞)
exposedField SFVec2f scale 11 # (-∞,∞)
exposedField SFVec2f translation 0 0 # (-∞,∞)
}
El nodo TextureTransform define una transformación bidimensional

que es aplicada a las coordenadas de textura. Este nodo afecta la
forma en que las coordenadas de textura son aplicadas a las
superficies de las geometrías así:
a. una traslacion
b. una rotacion alrededor del punto central
c. una escala no uniforme alrededor del punto central.
Estos parámetros soportan cambios de tamaño, orientación y

posición de texturas en las formas. Note que estas operaciones
aparecen revertidas cuando vemos la superficie de la geometría.
Por ejemplo un valor de escala de (2,2) escalara las coordenadas de
textura y tendrá la red afectada en un factor de 2. Una traslación de
(0.5, 0, 0) traslada las coordenadas de textura +0.5 unidades a lo
largo del eje s y afecta la red en una traslación de –0.5 a lo largo del
eje s sobre las superficies de la geometría. Una rotación de π/2 de
las coordenadas de textura da un resultado de -π/2 rotación de la
textura de la geometría.
El campo center especifica un offset de traslación en espacio de
coordenadas de textura alrededor de la cual la rotación y campos
escala son aplicados. El campos scale especifica el factor de escala
en S y T de las coordenadas de textura alrededor del punto central.
El campo rotation especifica una rotación en radianes de las
coordenadas de textura alrededor del punto central después de
haberse aplicada la escala. Una rotación positiva asegura que se
rotara en sentido contrario a las manecillas del reloj alrededor del
punto central. El campo translation especifica una traslación de las
coordenadas de textura
La matriz trasnformacion ser: Tc' = -C × S × R × C × T × Tc

Con Tc coordenadas de textura, C centro, T traslación, R rotación , S
escala
#VRML V2.0 utf8
#experimentando con TextureTransform
Transform
{
children Shape
{
{
texture ImageTexture {url "Texture/Fire_4.gif"}
textureTransform TextureTransform
{
center 0 0
scale 2 3
translation 1 0
rotation 1.5
}
}
geometry Box{}
}
}
Fog
Fog {
exposedField SFColor color 111 # [0,1]
exposedField SFString fogType "LINEAR"
exposedField SFFloat visibilityRange 0 # [0,∞)
eventIn SFBool set_bind
eventOut SFBool isBound
}
El nodo Fog provee la forma de simular efectos atmosféricos por la

mezcla de los objetos con el color especifico del campo color
tomándose el concepto además de la distancia que tienen los
objetos al observador. Las distancias son calculadas en coordenadas
espaciales del nodo Fog. El rango de visibilidad “visibilityRangeÓ
especifica la distancia “en sistema coordenado local Ó al cual los
objetos son totalmente oscurecidos por la niebla “fogÓ. Los objetos
localizados en el rango de visibilidad o mas del observador son
dibujados con una constante de color. Los objetos muy cercanos al
observador son mezclados muy poco con el color de niebla.
Un rango de visibilidad de 0.0 desabilita el nodo Fog el rango de

visibilidad son afectados por las transformaciones de escala de los
nodos raíz del nodo Fog. El rango de visibilidad debe estar en una
rango de [0,∞].
Puesto que los nodos Fog son nodos atables “bindables nodesÓ.
Existe una pila de nodos, en la cual el tope será el actualmente
activo. Para colocar un nodo Fog en el tope de la pila se necesita
enviar un valor verdadero al evento de entrdad set_bind. Una ves
activado el nodo Fog es atado al visualizador del browser. Un valor
FALSE enviado al evento de entrada set_bind saca el nodo de la pila
y lo desata del observador del browser.
Comportamiento del Stack Para nodos atables
Los nodos atables tienen cada uno su propia pila con a la cual se
modela el comportamiento de estos nodos en una escena, este
comportamiento se maneja a través de los eventos del entrad
set_bind y el evento de salida isBound. El evento de entrada
set_bind es usado para mover un nodo dado del tope o hacia el tope
de la pila. Un valor TRUE enviado a set_bind mueve el nodo al tope
de la pila, un valor FALSE enviado a set_bind remueve el nodo del
tope de la pila. El evento de salida isBoud es generado cuando el
nodo es movido del tope, cuando el nodo es movido hacia el tope o
cuando el nodo se mete debajo del tope de la pila. Es decir un
evento isBound es enviado cuando un dado se convierte o deja de
ser nodo activo. El nodo en el tope del stack es usado por el
browser para definir la escena. Si la pila esta vacía porque no se
han definido nodos o por que ha sido vaciada se presenta la escena
con los valores por defecto que se tengan.
Para atar nodos se tienen las siguientes reglas:
• durante la lectura el primer nodo atable es colocado en el topo
de la pila
• cuando un nodo recibe TRUE en set_bind, puede suceder:
- que el nodo no este en el tope del stack lo cual hace que sea
es movido al tope. Enviando un evento de salida isBoud de
TRUE. El nodo que se encontraba en el tope envía por su
parte un evento de salida isBoud FALSE.
- Que el nodo este en el tope de la pila situación en la cual los
eventos no tiene efecto.
• cuando un nodo recibe FALSE en set_bind el nodo es removido
del stack
- si estaba en el tope del stack envia un evnto isBound FALSE el
siguiente nodo en el stack se atara y este enviara isbound TRUE.
• cuando un nodo recibe FALSE en set_bind y este nodo no se
encuentra en pila los eventos son ignorados
• cuando un nodo reemplaza otro en el tope de la pila se envía
simultáneamente isBound TRUE y FALSE para los nodos de forma
respectiva.
• Si un ndo es borradoi se comporta como si recibiera un set_bind
FALSE.
El campo fogType controla la manera en la que el color es mezclado

con los objetos en función de la distancia. Si el tipo de neblina
“fogTypeÓ es lineal la cantidad mezclada es una función lineal de la
distancia. Si el tipo de neblina es EXPONENCIAL la cantidad
mezclada se incrementa en forma exponencial dando un mejor
apariencia al modelo.
#VRML V2.0 utf8
#experimentando con fog
Fog{
color 1 0 0
visibilityRange 1
}
Transform
{
children Shape{geometry Box{}}
}
DirectionalLight
DirectionalLight {
exposedField SFFloat ambientIntensity 0 #
[0,1]
exposedField SFColor color 111 #
[0,1]
exposedField SFVec3f direction 0 0 -1 # (-
∞,∞)
exposedField SFFloat intensity 1 #
[0,1]
exposedField SFBool on TRUE
}
El nodo DirectionalLight define una funet de luz direccional que

ilumina a lo largo de rayos paralelos de un vector 3D.
El campo intesity especifica el resplandor derl aemision directa de

la luz, El campo ambientIntensity especifica la intensidad de
emision de la luz ambiente, el campo color especifica las
propiedades de color espectral como una tripleta rgb de las
emisiones de luz directa y ambiental.
El campo direction especifica el vector direccion de emision de luz

de la funte luminosa. En sistema coordenado local. La luz es emitida
a lo largo de rayos paralelos aobre una distancia infinita. Una funete
de luz direccional ilumina unicamente los objetos encerrados en su
grupo. La luz puede iluminar todo dentro del sistema coordenado
local. Incluyendo los nodo descendientes. Las transformaciones
acumulados afectan la luz.
Los nodo DirectionalLight no se atenuan con la distancia
#VRML V2.0 utf8

#experimentacion con DirectionalLight
DirectionalLight
{
intensity 0.8
color 100
direction 0 0 -1
on TRUE
}
Transform
{
children Shape
{
geometry Box {}
}
}
PointLight
PointLight {
exposedField SFFloat ambientIntensity 0 # [0,1]
exposedField SFVec3f attenuation 1 0 0 # [0,∞)
exposedField SFColor color 1 1 1 # [0,1]
exposedField SFFloat intensity 1 # [0,1]
exposedField SFVec3f location 0 0 0 # (-∞,∞)
exposedField SFFloat radius 100 # [0, ∞)
}
El nodo PointLight una fuente de luz puntual con una ubicación en
sistema coordenado local. Un fuente puntual emite luz
uniformemente en todas direcciones es decir es omnidireccional.
Una fuente puntual es afectada por las transformaciones ancestro.
El campo intesity especifica el resplandor de la emisión directa de la

luz, El campo ambientIntensity especifica la intensidad de emisión
de la luz ambiente, el campo color especifica las propiedades de
color espectral como una tripleta rgb de las emisiones de luz directa
y ambiental.
Un nodo PointLight ilumina las geometrías dentro del radio de su

localización. Tanto radius como location son afectado por las
transformaciones ancestro. La escala afecta el radio y las
transformaciones la localización. El radio lógicamente debe ser
mayor de 0.0
La atenuación se expresa como: 1/max(attenuation[0]+

attenuation[1]×r + attenuation[2]×r ,1)
2
donde r es la distancia de la fuente luminosa a la superficie de

iluminación, es importante notar que por defecto no hay atenuación
pues se escoge como valor máximo a uno, por ejemplo si el vector
attenuation es 1 2 3 y r=1 la ecuación de atenuación será:
factor de atenuación = /max(1+ 2×1 + 3×12,1)=1/6.
#VRML V2.0 utf8
#experimentando con PointLight
PointLight
{
attenuation 121
color 1 0.0 0.0
location 0 10 0
radius 50
}
Transform { children Shape {geometry Box {}} }
SpotLight
SpotLight {
exposedField SFFloat ambientIntensity 0 # [0,1]
exposedField SFVec3f attenuation 100 # [0,∞)
exposedField SFFloat beamWidth 1.570796 # (0,π
/2]
exposedField SFColor color 111 # [0,1]
exposedField SFFloat cutOffAngle 0.785398 # (0, π
/2]
exposedField SFVec3f direction 0 0 -1 # (- ∞,
∞)
exposedField SFVec3f location 000 # (-∞,
∞)
exposedField SFFloat radius 100 # [0,
∞)
}
El nodo SpotLight define una furnte de luz que emite luz de un

punto especifico de luz a lo largo de la direccion de un vector
especifico y restringido dentro de un angulo soilido. SpotLight
puede iluminar nodos geometria que respondan a funets luminosaa
e intersecten el angulo solido definido por el SpotLight. El nodo
SpotLoight se especifca en coordenadas locales es afectado por las
transformaciones ancestro.
El campo intesity especifica el resplandor de la emisión directa de la
luz, El campo ambientIntensity especifica la intensidad de emisión
de la luz ambiente, el campo color especifica las propiedades de
color espectral como una tripleta rgb de las emisiones de luz directa
y ambiental.
El campo location especifica un offset traslacion del punto central

de la funte de luz desde el origen dl sistema coordenado local de la
luz. Este punto es el apice de un angulo solido que ata la emision de
la luz de l afuente luminosa dada. El campo radius especifica la
extension radila del angulo solido, y la maxima distancia de
localizacion que puede ser iluminada por la funte. La fuente de lus
no emite luz fuera de este radio. Tanto radius como location son
afectado por las transformaciones ancestro. La escala afecta el
radio y las transformaciones la localización. El radio lógicamente
debe ser mayor de 0.0
El campo direction especifica el vector direciion del eje central de la

luz definido en sistema coordenado local. El campo on especifica si
la funete emitye o no luz. Es decir si es TRUE o FALSE
respectivamente.
El campo cutOffAngle especifica el limite exterior del angulo solido.

La funete de luz no emite luz en el exteriro del angulo solido. El
campo beamWidth especifica un angulo solido interiro dentro del
cual la luz emitida es uniforme e intensidad maxima. Si el campo
beamWidth es mas grande que cutOffAngle, se igualan ambos
deben ser mayores de 0.0.
La atenuación dentro del nodo SpotLight como:
1/max(attenuation[0]+ attenuation[1]×r + attenuation[2]×r2,1)
donde r es la distancia de la fuente luminosa a la superficie de
iluminación, es importante notar que por defecto no hay atenuación
pues se escoge como valor máximo a uno, por ejemplo si el vector
attenuation es 1 2 3 y r=1 la ecuación de atenuación será:
factor de atenuación = /max(1+ 2×1 + 3×12,1)=1/6.
#VRML V2.0 utf8
#experimentado con SpotLight
SpotLight
{
ambientIntensity 1
attenuation 1 2 3
beamWidth 1.5
color 100
cutOffAngle 0.7
direction 0 0 -1
location 0 0 10
}
Transform
{
children Shape{geometry Box{}}
}
Ecuación de Iluminación en VRML
Una implementación ideal en VRML evaluará la siguiente ecuación

de iluminación para cada punto de una superficie iluminada. La
intensidades RGB para cada punto en una geometría Irgb esta dada
por:
Irgb=IFrgb×(1- f0)+f0×[OErgb+SUM(oni×attenuationi×spoti×ILrgb×(ambienti +
difussei + especulari))]
donde:
IFrgb = color de Fog actualmente atado.
f0 = fog interpolado.
LINEAR ⇒ f0 = (fogVisibility-dV) / fogVisibility para dV
< fogVisibility
LINEAR ⇒ f0 = 0 para dV
≥ fogVisibility
EXPONENTIAL ⇒ f0 = exp(-dV / (fogVisibility- dV ) ) para dV
< fogVisibility
EXPONENTIAL ⇒ f0 = 0 para dV ≥
fogVisibility
NO Fog ⇒ f0 = 1
Con: dV = distancia del punto de la geometría a la posición
del observador, en sistema
coordenado del nodo Fog actual.
fogVisibility= visibilityRange.
OErgb = color de emisión del material “emissiveColorÓ.
oni = 1 (TRUE), si la fuente de luz esta activa.

0 (FALSE) si la fuente de luz no esta activa o si la geometría
esta fuera del radio para
PointLight, SpotLight o fuera de los nodos de agrupación
para DirectionalLight.
attenuationi = 1/max(c1 + c2×dL + c3×dL² , 1 )

con:
c1,c2 ,c3 coeficientes de atenuación de la luz i.
dL = distancia de la luz al punto de la geometria, en
sietma coordenado de la luz
spoti= factor spotlight.

lighti is PointLight o DirectionalLight1 ⇒ spoti = 1
spotAngle >= spotCO ⇒ spoti = 0
spotAngle <= spotBW ⇒ spoti =1
spotBW < spotAngle < spot CO ⇒ spoti =
(spotAngle - spotCO ) / (spotBW-spotCO)
con:
spotAngle = acos( -L · spotDiri)
spotDiri =directccion normalizada SpotLight i
spot BW = SpotLight i beamWidth
spot CO = SpotLight i cutOffAngle
ILrgb = color de la luz i.
ambientei = Iia × ODrgb × Oa

con:
Iia = intensidad ambiente para la luz i.
ODrgb = color de difusión del nodo material, nodo
color y/o nodo textura.
Oa = intensidad ambiente del material.
difusióni = Ii× ODrgb × ( N · L )

con:
Ii = intensidad de la luz i.
ODrgb = color de difusión del nodo material, nodo
color y/o nodo textura.
N = vector normal mormalizado de la geometría.
L = (Point/SpotLight) vector normalizado de un
punto de la geometria a la
posicion de la fuente de luz i
L = (DirectionalLight) –direccion de la funete de luz
i
especulari = Ii× OSrgb × ( N · ((L + V) / |L + V|))shininess×128

con:
Ii = intensidad de la luz i.
OSrgb = color especular para el material.
N = vector normal mormalizado de la geometría.
L = (Point/SpotLight) vector normalizado de un
punto de la geometria a la
posicion de la fuente de luz i
L = (DirectionalLight) –direccion de la funete de luz
i
V = vector normalizado de la geometría a la
posición del observador.
shininess= brillo del material.
SUM = suma de todas las fuentes luz i.
Background {
exposedField MFFloat groundAngle [] # [0, ∞/2]
exposedfield MFColor groundColor [] # [0,1]
exposedField MFString backUrl []
exposedField MFString bottomUrl []
exposedField MFString frontUrl []
exposedField MFString leftUrl []
exposedField MFString rightUrl []
exposedField MFString topUrl []
exposedField MFFloat skyAngle [] # [0, ∞]
exposedField MFColor skyColor [000] # [0,1]
}
El nodo Background es usado para especificar un color backdrop
que simule tierra y cielo, tan satisfactorio como una textura del
fondo, o panorama, que se pone detrás de todas las geometrías en
la escena en frente del la tierra y el cielo. Los nodos Background se
especifican en el sistema coordenado local y son afectados por la
rotación acumulada de sus antepasados.los nodos Background son
nodos del atados." existe un stack de Background, en el cual el tope
será el nodo activo. Para mover un nodo Background al tope se
envía un valor TRUE al evento de entrada set_bin.Un valor de FALSE
enviado a set_bind remueve el backgraund del tope de la pila.El
backdrop es conceptually una esfera parcial (la tierra) encerrada
dentro de de una esfera completa (el cielo) en el sistema
coordenado local con el observador en el centro de las esferas.
Ambas esferas tienen radios infinitos (un epsilon aparte) y cada una
es pintada con círculos concentricos de colores interpolados,
perpendicular al eje Y local de la esfera. El nodo Background esta
sujeto a las rotaciones acumuladas de su antepasadas
transformaciones. El escalamineto y traslación son ignorados. La
esfera del cielo siempre esta un poco más alejada del obsrvador
que la esfera de la tierra causando que la tierra aparesca en frente
del cielo en casos donde se solapan.
El campo skyColor especifica el color del cielo a varios angulos

sobre la esfera del cielo. El primer valor del campo skyColor
especifica el color del cielo a 0.0 radianes representando el cenit
(hacia arriba del observador). El campo del skyAngle especifica los
ángulos del cenit en el cual los círculos concentricos de color
aparecen. El cenit de la esfera es implicitamente definió para ser
0.0 radianes, el horizonte natural es una π/ 2 radianes, y el nadir
(hacia abajo del observador) está a Imagen radians. el skyAngle
esta restringido a valores no decrecientes en el rango (0.0, π). debe
haber un valor más de skyColor que de skyAngle. El primer valor
del color es el color del cenit, que no se especifica en el campo del
skyAngle. Si el último skyAngle es menor que pi, entonces el color
ata entre el último skyAngle y el nadir es sujetado al último
skyColor. El color del cielo es linealmente interpolado entre el valor
especificado del skyColor.
El campo groundColor especifica el color de la tierra en los
diferentes ángulos del hemisferio de la tierra. El primer valor del
campo groundColor especifica el color de la tierra a 0.0 radianes
representa el nadir ([i.e]., hacia abajo del usuario). El campo
groundAngle especifica los ángulos del nadir que los círculos del
concentricos de color presentan. El nadir de la esfera es
implicitamente definido a 0.0 radianses. El groundAngle esta
restringido a valores no decrecioentes en el rango [0.0,π/2]. debe
haber un valor de groundColor que de valores groundAngle. El
primer valor del color es para el nadir que no se especifica en el
campo groundAngle. Si el último groundAngle es menos que π/2
(usual), la región entre el último groundAngle y el ecuador es
invisible. El color de la tierra es linealmente interpolado entre los
valores especificados del groundColor.
Los campos backUrl, bottomUrl, frontUrl, leftUrl, rightUrl, y topUrl

especifican un juego de imagenes que definen un panorama de
background entre la tierra/cielo backdrop y la geometría de la
escena. El panorama consta de seis imagenes, cada una de las
cuales es mapeada en una cara de un cubo infinitamente grande
contunido dentro de las esferas del backdrop y centreda en el
sistema coordenado local. las imagenes son aplicadas
individualmente a cada cara del cubo . En las caras frental,
posterior, derecho, e izquierdas del cubo, cuando la vista del origen
parece abajo del eje negativo Z con el eje Y con vista hacia arriba,
se traza cada imagen hacia la cara correspondiente con la misma
orientación como si se desplegara la imagen normalmente en 2D
(backUrl cara posterior, frontUrl cara frontal, leftUrl cara izquierda, y
rightUrl cara derecha). En el tope de la cara del cubo, cuando la
vista del origen parece a lo largo del eje +Y con el eje + Z como
dirección de la vista hacia arriba, el topUrl es mapeado en la cara
con la misma orientación como si normalmente se desplegara la
imagen en 2D. En el cara botton del cubo, cuando la vista del origen
es a lo largo del eje negativo Y con el eje negativo Z como la vista
en dirección arriba, se traza la imagen del bottomUrl sobre la cara
con la misma orientación como si normalmente se desplegra la
imagen en 2D.
A menudo, las imagenes bottomUrl y topUrl, no serán especificadas

permitiendo que cielo y tierra sean mostrados. Las otras cuatro
imagenes pdrín representar un cerco de montañas u otros paisajes
distantes. los Browsers pueden soportar formatos JPEG, PNG y
CGM. Tmabien se pueden soportar formatos GIF recomendado para
transparencias.
las imagenes del panorama pueden ser componentes en escala de

grices, dos componente (escala de grices plus alfa), tres
componente (full RGB ), o cuatro-componente (full RGB colores plus
alfa).los colores de la tierra, colores del cielo , e imagenes
panorámicas no se trasladan con respecto al abservador, aunque si
rotan. Esto es, el observador no puede salir del Background, pero
puede volver examinar todo lados del panorama cubico, y puede
ver los anillos concentricos de la tierra y cielo si visibles). El
background no es afectado por el nodo Fog. Por eso, si un nodo del
Fondo es activo mientras un nodo Fog esta activo, entonces se
desplegará el nodo Background sin envolverse en efectos de Fog. El
primer nodoBackground hallado durante lectura del mundo se ata
automáticamente (recibe en set_bind el valor TURE y se usa como
el fondo inicial cuando se carga el mundo.
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 [] # [-1, ∞)
field SFBool colorPerVertex TRUE
field SFBool convex TRUE
field MFInt32 coordIndex [] # [-1, ∞)
field SFFloat creaseAngle 0 # [0, ∞)
field MFInt32 normalIndex [] # [-1, ∞)
field SFBool normalPerVertex TRUE
field SFBool solid TRUE
field MFInt32 texCoordIndex [] # [-1, ∞)
}
El nodo IndexedFaceSet representa un objeto 3D formado por
construicción de caras (poligonos) de vertices listados en el campo
del coord (coordenadas). El campo coord contiene un nodo
Coordinate que define los vertices 3D referenciados del por el
campo coordIndex. IndexedFaceSet usa los indices en su campo
coordIndex para especificar las poligononos de las caras por
indexación de las coordenadas en el nodo Cordinate. Un índice de "-
1" indica que la cara presente ha acabado y la próxima empieza. La
última cara puede estar o no seguida de un índice "-1". Si el índice
más grande en el campo [coordIndex es N, el nodo Coordinate
contendrá N+1 coordenadas (índixado como 0 a N). Cada cara del
IndexedFaceSet tendrá:
a. al menos tres vertices no-coincidentes.
b. vertices que definan un poligono plano.
c. vertices que define poligono que no se intersecta asi mismo.
de otra manera los resultados son indefinidos. El nodo
IndexedFaceSet es especificado en sistema coordenado local y es
afectado por las transformaciones ancestro.
El campo normal contiene un nodo Normal
Normal { exposedField MFVec3f vector [] # (-∞,∞)}
El campo color contiene un no Color
Color { exposedField MFColor color [] # [0,1]}
El campo coord contiene un nodo Coordiante
Coordinate { exposedField MFVec3f point [] # (-∞,∞)}
El nodo texCoord contiene un nodo TextureCoordinate
TextureCoordinate { exposedField MFVec2f point [] # (-∞,∞)}
Las descripciones de los nodos coord, normal, texCoord estan

dados en los nodos Coordinate, Normal, y TextureCoordinate
respectivamente.
Si el campo del color es no NULL, debe contener un nodo del Color

cuyos colores son aplicados a los vértices o caras del
IndexedFaceSet como siguen:
d. si el colorPerVertex es FALSE, los coloresson aplicados a cada
cara, como sigue:
1. si el campo colorIndex no esta vacío, entonces un color es usado
por cara del IndexedFaceSet. Debe haber por lo menos tantos
indices en el campo colorIndex como caras en el IndexedFaceSet.
Si el índice más grande en el campo colorIndex es N, entonces
debe haber N+1 colores en el nodo del Color. El campo
colorIndex no debe contener ningunas entradas negativas.
2. si el campo colorIndex esta vacío, entonces los colores en el
nodo Color son aplicados a cada cara del IndexedFaceSet en
orden. Debe haber por lo menos tantos colores en el nodo del
Color como hay caras.
e. Si colorPerVertex es TRUE, los colores son aplicados a cada
vértice, como sigue:
1. Si el campo colorIndex no esta vacío, los colores son aplicados a
cada vértice del IndexedFaceSet en exactamente la misma
manera que se usa el campo coordIndex para escoger las
coordenadas por cada vértice del nodo Coordinate. El campo
colorIndex debe contener por lo menos tantos indices como el
campo coordIndex, y debe contener marcadores de fin-de-cara
(-1) en exactamente los mismos lugares como el campo
coordIndex. Si el índice más gran en el campo colorIndex es N,
entonces debe haber N+1 colores en el nodo Color.
2. Si el campo del colorIndex esta vacío, entonces se usa
coordIndex para escoger los colores del Color. Si el índice más
grande en el campo coordIndex es N, entonces debe haber N+1
colores en el nodo Color.
si el campo color es NULL, la geometria debe ser rendereada
usando Material y la textura definida en elnodo Appearance.
Si el campo normal no es NULL, debe contener un nodo Normal
cuyas normales son aplicadas a los vertices o caras de
IndexedFaceSet en una manera precisamente equivalente a la
descrita pora los colores a vertices/caras (donde la normalPerVertex
corresponde a colorPerVertex y normalIndex corresponde a
colorIndex). Si el campo del normal es NULL, el browser generará
automáticamente normales, usa creaseAngle para determinar si y
cómo normales son genradas por vertices.
coordenadas de la textura en ese nodo a los vertices de
IndexedFaceSet como sigue:
f. Si el campo texCoordIndex no esta vacío, entonces es usado
para escoger las coordenadas por cada vértice IndexedFaceSet
en exactamente la misma manera que se usa el campo
coordIndex para escoger las coordenadas por cada vértice del
nodo Coordinate. El campo texCoordIndex debe contener por lo
menos tanto indices como el campo coordIndex, y debe contener
marcadores del fin-de-cara (-1) en exactamente los mismos
lugares como el campo coordIndex. Si el índice más gran en el
campo texCoordIndex es N, entonces debe haber N+1
coordenadas de la textura en el nodo TextureCoordinate.
g. Si el campo texCoordIndex esta vacío, entonces el arreglo de
coordenadas es usado para escoger el orden de coordenadas de
la textura del nodo TextureCoordinate. Si el índice más gran en
el campo coordIndex es N, entonces debe haber N+1
coordenadas de la textura en el nodo TextureCoordinate.
Si el campo texCoord es NULL, un mapeo de las coordenadas de
textura es calculado usando el sitema coordenado local limitando
la caja de la forma. La dimensión más larga de la caja define las
coordenadas S, y el próximo más largo define las coordenadas T. Si
dos o todo las tres dimensiones de la caja son iguales, se romperán
los vínculos para escoger la dimensión X, Y, o Z en ese orden de
preferencia. El valor de la coordenada S tiene rango de 0 a 1, del
fin del limite de la caja al otro. La coordenada T tiene cierto alcance
entre 0 y la proporción de la segunda más gran dimensión dela
limite de la caja a la más grande dimensión.
El campo ccw define el orden de las coordenadas para los vértices

de la geometría con respecto al usuario dado o vectores noramles
generados automáticamente usados en los modelos de ecuación
para las luces. Si ccw es verdadero las normales deberán asignar la
regla de la mano derecha, la orientación de cada normal con
respecto a los vértices (tomados en orden) serán tales que los
vértices serán orientados en sentido contrario de las manecillas del
reloj cuando los vértices son vistos en dirección opuesta a las
normales. Si ccw es FALSE, las normales deberán ser orientadas en
dirección opuesta. Si las normales no son generadas pero son
reemplazadas por el nodo Normal , la orientación de las normales
no confrontan el contenido del campo ccw. los resultados son
indefinidos.
El campo solid determina si uno o ambos lados de cada polígono

deben ser desplegados.
Si el campo solid es FALSE cada polígono deberá ser visible respecto
a la dirección de visualización. Si el campo solid es TRUE, la
visibilidad de cada polígono deberá ser determinada así:
V = posición del observador en el sistema coordenado
local de la geometría
N = vector normal de la geometría del polígono.
P = un punto sobre le plano definido por los vértices
del polígono.
si:
(V·N) - (N·P) > 0 el polígono será visible
(V·N) - (N·P) ≤ 0 el polígono será invisible
El campo creaseAngle, afecta el generamiento de las normales. Si el

ángulo entre las normales de una geometría de dos superficies
adyacentes es menor que el ángulo de crecimiento, las normales
deberán ser calculadas para que las superficies sean sombreadas
por los lados. de otra forma las normales deben ser calculadas para
que la discontinuidad en la luz sobre los lados sea producida. Por
ejemplo un ángulo de crecimiento de 0.5 radianes significa que los
lados adyacentes a las superficies poligonales serán sombreados si
las normales de la geometría de las dos superficies forman un
ángulo menor de 0.5 radianes. de otra manera las superficies
aparecerán facetadas. el ángulo de crecimiento debe ser mayor o
igual a 0.0 radianes.
Por defecto los cuadriláteros son definidos en sentido contrario a las
manecillas del reloj. Por lo tanto la componente Y de la normal es
positiva. Dando al campo cww el valor FALSE la dirección de las
normales es invertido. El anverso de una superficie es escogido
cuando el campo solid es TRUE. El campo convex especifica si los
poligonos en la forma son convexos (TRUE). Un poligono es convexo
si es plano es decir no se intersecta asi mismo y todo los angulos
interiores a sus vertices son menoers de 180 grados.
#VRML V2.0 utf8

#experimentando con indexedFaceSet
DEF miColor Color {color [1 0 0,0 1 1,1 0 0,0 0 1]}
DEF miCoord Coordinate {point [-1 1 0,-1 -1 0,1 -1 0, 1 1 0 ]}
DEF miNormal Normal {vector [1 0 0]}
DEF miTextura TextureCoordinate {point [1 2]}
Transform
{
translation 0 0 0
rotation 0 0 1 0
scale 111
center 000
children Shape
{
appearance NULL
geometry IndexedFaceSet
{
color USE miColor
coord USE miCoord
normal USE miNormal
texCoord USE miTextura
ccw TRUE
colorPerVertex FALSE
convex TRUE
normalPerVertex TRUE
creaseAngle 0
solid FALSE
coordIndex [ 0, 1, 2, 3, -1 ]
colorIndex 2
}
}
}
#VRML V2.0 utf8

Background
{
groundAngle [ 0.9, 1.5, 1.57 ]
groundColor [0.789406 0.8 0.127632,
0.82 0.725712 0.0802584,
0.82 0.722015 0.0200536,
0.67 0.63537 0.048045 ]
skyAngle [ 0.1, 1.2, 1.57 ]
skyColor [ 0.146735 0.784408 0.8,
0.156392 0.7 0.672704,
0.222549 0.390234 0.7,
0.0513393 0.540593 0.69]
}
Transform
{
children Shape {geometry Sphere {}}
}
ElevationGrid {
eventIn MFFloat set_height
exposedField SFNode normal NULL
exposedField SFNode texCoord NULL
field MFFloat height []
field SFBool ccw TRUE
field SFFloat creaseAngle 0
field SFBool normalPerVertex TRUE
field SFBool solid TRUE
field SFInt32 xDimension 0
field SFFloat xSpacing 1.0
field SFInt32 zDimension 0
field SFFloat zSpacing 1.0
}
El nodo ElevationGrid es una grilla rectangular a la cual se le puede

configurar la altura sobre el plano Y=0 en sistema coordenado
local. Esta geometría se describe a través de un arreglo escalar de
alturas que especifican las alturas de las superficies sobre cada
punto de la grilla.
Los campos xDimension y zDimension indican el numero de

divisiones de la grilla. La localización de los vértices para los
rectángulos son definidos por el campo height y los campos
xSpacing y zSpacing:
• el campo height es un arreglo de valores escalares xDimension
por zDimension representado la altura sobre las grillas para cada
vértice.
• los campos xSpacing y zSpacing indican la distancia entre los
vértices en las direcciones X y Z respectivamente y deben ser
mayores de cero.
De esta manera los vértices correspondientes a un arreglo P[i,j]
sobre la grilla son colocados como:
P[i,j].x = xSpacing × i
P[i,j].y = height[ i + j × xDimension]
P[i,j].z = zSpacing × j
con:
0 ≤ i < xDimension y 0 ≤ j < zDimension
y P[0,0] es height[0] unidades por encima o debajo del
sistema coordenado local.
El evento de entrada set_height asigna la altura al campo height

para que la altura sea cambiada soportando de esta manera la
animación para el nodo ElevationGrid.
El campo color especifica los colores por vértice o por cuadrilátero

para el nodo ElevationGrid dependiendo de los valores de
colorPerVertex. Si el campo color es NULL, El nodo ElevationGrid es
rendereado con los atributos del nodo Shape que contenga el nodo
ElevationGrid.
El campo colorPerVertex determina si los colores especificados en el

campo color son aplicados a cada vértice o cada cuadrilátero del
nodo ElevationGrid. Si el campo colorPerVertex es falso y el campo
color no es NULL, el campo color debe especificar un nodo color que
contenga por lo menos los colores (xDimension-1)×(zDimension-1),
uno para cada cuadrilátero ordenados asi:
QuadColor[i,j] = Color[ i + j ×
(xDimension-1)]
con:
0 ≤ i < xDimension-1 y 0 ≤ j <
zDimension-1,
y QuadColor[i,j] es el color para el
cuarilatero definido por:
height[i+j×xDimension]
height[(i+1)+j×xDimension]
height[(i+1)+(j+1)×xDimension]
height[i+(j+1)×xDimension]
si colorPerVertex es verdadero y el campo de color no es NULL, el
campo color debe especificar un nodo color conteniendo por lo
menos los colores xDimension × zDimension colores, uno para cada
vértice, ordenados así:
VertexColor[i,j] = Color[ i + j ×
xDimension]
con:
0 <= i < xDimension and 0 <= j <
zDimension
y VertexColor[i,j] es el color por
vétice definido por
height[i+j×xDimension]
El campo normal especifica las normales por vértice o por

cuadrilátero para el nodo ElevationGrid. Si el campo normal es
NULL, el browser debe generar automáticamente normales, usando
el campo creaseAngle para determinar si y como las normales son
hechas en la superficie.
El campo normalPerVertex determina si las normales son aplicadas

a cada vértice o a cada cuadrilátero del nodo ElevationGrid
dependiendo de los valores de normalPerVertex. Si la
normalPerVertex es FALSE y el nodo normal no es NULL, el campo
normal deberá especificar un nodo normal contenido por lo menos
las normales (xDimension-1)×(zDimension-1),
ordenadas así:
QuadNormal[i,j] = Normal[ i + j × (xDimension-1)]
con:
0 ≤ i < xDimension-1 and 0 ≤ j < zDimension-1,
y QuadNormal[i,j] es la normal para el cuadrilátero
definido
por: height[i+j×xDimension],
height[(i+1)+j×xDimension],
height[(i+1)+(j+1)×xDimension] y
height[i+(j+1)×xDimension]
Si la normalPerVertex es TRUE y el campo normal no es NULL, el
campo normal debe especificar un nodo normal que conteniendo
por lo menos las normales xDimension × zDimension normals, una
para cada vértice, ordenadas así:
VertexNormal[i,j] = Normal[ i + j ×
xDimension]
con:
0 ≤i < xDimension and 0 ≤ j <
zDimension,
y VertexNormal[i,j], es la normal por
vertece definido
por height[i+j×xDimension]
El campo texCoord especifica las coordenadas de textura por

vértice para el nodo ElvationGrid. Si texCoord es NULL, las
coordenadas de textura por defecto son aplicadas a la geometría. El
rango de coordenadas por defecto para la textura es (0,0) para el
primer vértice y (1,1) para el último vértice. La coordenada S de
textura es alineada con el eje X positivo. y la coordenada de
textura T con el eje Z positivo. Si texCoord no es NULL, Esta debe
especificar un nodo TextureCoordinate conteniedo por lo menos la
coordenada de textura (xDimension)×(zDimension), una para cada
vértice, ordenadas así:
VertexTexCoord[i,j] = TextureCoordinate[ i
+ j × xDimension]
con 0 ≤ i < xDimension and 0 ≤ j <
zDimension,
y VertexTexCoord[i,j] es la coordenada de
textura por vértice
definida por height[i+j×xDimension]
El campo ccw define el orden de las coordenadas para los vértices

de la geometría con respecto al usuario dado o vectores noramles
generados automáticamente usados en los modelos de ecuación
para las luces. Si ccw es verdadero las normales deberán asignar la
regla de la mano derecha, la orientación de cada normal con
respecto a los vértices (tomados en orden) serán tales que los
vértices serán orientados en sentido contrario de las manecillas del
reloj cuando los vértices son vistos en dirección opuesta a las
normales. Si ccw es FALSE, las normales deberán ser orientadas en
dirección opuesta. Si las normales no son generadas pero son
reemplazadas por el nodo Normal , la orientación de las normales
no confrontan el contenido del campo ccw. los resultados son
indefinidos.
El campo solid determina si uno o ambos lados de cada polígono

deben ser desplegados.
Si el campo solid es FALSE cada polígono deberá ser visible respecto
a la dirección de visualización. Si el campo solid es TRUE, la
visibilidad de cada polígono deberá ser determinada así:
V = posición del observador en el sistema coordenado
local de la geometría
N = vector normal de la geometría del polígono.
P = un punto sobre le plano definido por los vértices
del polígono.
si:
(V·N) - (N·P) > 0 el polígono será visible
(V·N) - (N·P) ≤ 0 el polígono será invisible
El campo creaseAngle, afecta el generamiento de las normales. Si el

ángulo entre las normales de una geometría de dos superficies
adyacentes es menor que el ángulo de crecimiento, las normales
deberán ser calculadas para que las superficies sean sombreadas
por los lados. de otra forma las normales deben ser calculadas para
que la discontinuidad en la luz sobre los lados sea producida. Por
ejemplo un ángulo de crecimiento de 0.5 radianes significa que los
lados adyacentes a las superficies poligonales serán sombreados si
las normales de la geometría de las dos superficies forman un
ángulo menor de 0.5 radianes. de otra manera las superficies
aparecerán facetadas. el ángulo de crecimiento debe ser mayor o
igual a 0.0 radianes.
Por defecto los cuadriláteros son definidos en sentido contrario a las

manecillas del reloj. Por lo tanto la componente Y de la normal es
positiva. Dando al campo cww el valor FALSE la dirección de las
normales es invertido. El anverso de una superficie es escogido
cuando el campo solid es TRUE.
PointSet {
}
El nodo PointSet especifica un conjunto de puntos 3D, en sistema
local de coordenadas con colores asociados a cada punto. el campo
coord especifica que puede contener un nodo Coordinate o una
instancia de un nodo Cordinate. El campo color especifica que
puede contener un nodo Color.
#VRML V2.0 utf8

#Programa de manejo de ElevatinGrid
#definiciones
DEF colores Color { color [1 1 1, 1 1 1, 1 1 1]}

DEF coordenadas Coordinate {point[-3 2.0 3,1.5 2.1 3,3 4.5 3]}
Transform
{
translation 5 10 0
children [Shape { appearance
Appearance {texture ImageTexture
{url "Texture/Fire_4.gif"} }
geometry Sphere{}
}
Shape { appearance NULL
geometry PointSet {
color USE colores
coord USE coordenadas
}
}
]#fin del children
}#fin de la transform
Transform
{
children [
Shape {
appearance
Appearance {
material NULL
{url "Texture/Fire_4.gif"}
}
geometry ElevationGrid
{
color NULL
normal NULL
texCoord NULL
ccw TRUE
creaseAngle 3.1416
normalPerVertex TRUE
solid FALSE
xDimension 20
xSpacing 1
zDimension 10
zSpacing 2.1
height
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0.574138, 1.15642, 0, 0, 0, 0, 0,
0, 0, 0, 1.24391, 1.22496, 1.34675,
0, 0.750605, 0, 0, 0, 0, 0.77818,
0.882007, 0.511196, 1.17336, 1.51892,
0.682372, 0, 0, 0, 0, 0, 3.02813,
2.04578, 1.70073, 0.900392, 0, 0, 0,
0, 0, 0.935582, 2.29136, 1.80391,
1.94608, 0.80072, 1.82315, 0, 0, 0, 0,
1.0034, 1.94628, 1.77, 1.98183,1.47482,
0, 0, 0, 0, 0, 1.48495, 0.754169, 2.0891,
2.53922, 1.56558, 1.30134, 0, 0, 0, 0, 0,
0, 0.689713, 0, 0.987446, 0.696322, 0, 0,
0, 0.750605, 0, 2.30714, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0
]
}#fin height
}#fin Shape
]#fin de children
}#fin Transform
IndexedLineSet
IndexedLineSet {
eventIn MFInt32 set_colorIndex
eventIn MFInt32 set_coordIndex
field MFInt32 colorIndex [] # [-1,
∞)
field MFInt32 coordIndex [] # [-1,
∞)
}
El nodo IndexedLineSet representa una geometría 3D formada por

polilineas de vértices 3D especificados en el campo coord.
IndexedLineSet usa los índices de su campo coordIndex para
especificar las polilineas para conectar los vértices del campo
coord. Un índice de “-1Ó indica que la polilinea actual a finalizado y
la siguiente empieza. La ultima polilinea puede o no terminar con
“-1Ó. IndexedLineSet es especificada en sistema coordenado local y
es afectada por las transformaciones ancestro
El campo coord especifica los vértices 3D del conjunto de líneas y

contiene un nodo Coordinate. Las líneas no son iluminadas, no son
texturadas y no participan en la detección de colisión. El ancho de
las líneas es dependiente de la implementacion y cada segmento de
línea es sólido.
a. Si el color por vertice “colorPerVertexÓ es “FALSEÓ:
• si el campo colorIndex no esta vacío, entonces un color es usado
para cada polilinea del IndexedLineSet. Deben haber por lo
menos tantos índices en el campo colorIndex como hay
polilineas en el IndexedLineSet. Si el índice mas grande en el
campo colorIndex es N. Enotnces deben haber N+1 colores en
el nodo Color. El campo coloIndex no puede contener entradas
negativas.
• Si el campo colorIndex esta vacío, entonces los colores del nodo
Color son aplicados a cada polilinea del IndexedLineSet en
orden. Deben haber por lo menos tantos colores en el nodo Color
como hay polilineas.
b. Si colorPerVertex es TRUE
• si el campo colorIndex no esta vacío, entonces los colores son
aplicados a cada vértice del IndexedLineSet en exactamente la
misma forma que el campo coordIndex es usado para suplir las
coordenadas para cada vértice del nodo Coordinate. El campo
colorIndex debe contener por lo menos tantos índices en el
campo coordindex con la separación de –1 en los mismos lugares
del campo coordIndex. Si el índice mas grande en el campo
colorIndex es N entonces debe haber N+1 color en el nodo Color.
• Si el campo colorIndex esta vacío, entonces el campo coordIndex
es usado para escoger colores del nodo Color. Si el índice mas
grande en el campo coordIndex es N. Deben haber N+1 colores
en el nodo Color.
Si el campo color es NULL y hay un Material definido para

Appearance este afectara elIndexedLineSet, el emissiveColor del
Material será usado para dibujar las líneas
#VRML V2.0 utf8

#experimentando con IndexedLineSet
DEF miColor Color {color [1 1 0]}

DEF miCoordenada Coordinate{point [1 1 0,-1 1 0,-1 -1 0,1 -1 0]}
Transform
{
translation 0 0 0
rotation 0 0 1 0
scale 111
center 000
children Shape
{appearance Appearance {material Material {}}
geometry IndexedLineSet
{
color USE miColor
coord USE miCoordenada
coordIndex [0,1,-1,1,2,-1,2,3,-1,3,0]
colorIndex [0,0,0,0]
}
}
}
Sound {
exposedField SFVec3f direction 001
exposedField SFVec3f location 000
exposedField SFFloat maxBack 10
exposedField SFFloat maxFront 10
exposedField SFFloat minBack 1
exposedField SFFloat minFront 1
exposedField SFFloat priority 0 # [0,1]
exposedField SFNode source NULL
field SFBool spatialize TRUE
}
El nodo Sound especifica la presentación espacial de un sonido en

una escena VRML . El sonido es localizado en un punto en el
sistema coordenado local y emite el sonido en un modelo elíptico
(definido por dos elipsoides). Los elipsoides se orientan en una
dirección especificada por el campo de dirección. La forma de los
elipsoides puede ser modifica para proveer más o menos enfoque
direccional de la localización del sonido.
El campo source especifica la fuente del sonido. Si el campo source

no se especifica el nodo Sound no emitirá sonido. El campo source
puede especificar un nodo AudioClip o un nodo MovieTexture. Si un
nodo MovieTexture es especificado como la fuente del sonido, el
MovieTexture debe referirse a un formato movie que soporte sonido
([e.g]., MPEG1-Systems, ve 2.[ MPEG]).
El campo intensity ajusta los (decibelios) del sonido emitido por el

nodo Sound (nota: éste es diferente de la definición tradicional de
intensidad con respecto al sonido). El campo intensity tiene un
valor en un rango de 0.0 a 1.0 y especifica un factor el cual debe
ser usado para escalar los datos de las muestras normalizadas de la
fuente de sonido durante el (playback). Un nodo Sound con una
intensidad de 1.0 podrá emitir audio a su máximo potencia
(atenuación anterior), y un nodo Sound con una intensidad de 0.0
no emitirá audio. Entre estos valores la potencia debe aumentar
linealmente con un cambio de -20 dB aprovechando una intensidad
de 0.0 a un cambio de 0 dB en una intensidad de 1.0.
El campo priority da una señal para que al browser escoja que

sonidos tocar cuando hay mas nodos de sonido activos que pueden
ser tocados al tiempo limitando los recursos del sistema. El rango
de 0.0 a 1.0, con 1.0 empieza la más alta prioridad y 0.0 la más
baja prioridad .
El campo location determina la localización del emisor de sonido en

el sistema coordenado local. Una salida del nodo Sound es audible
sólo si es parte de la escena. los nodos Sound que son
desciendientes de LOD, Switch, o cualquiera nodo de agrupación o
prototipo desactiven el sonido de sus nodos hijos no serán
audibles que se intercepten. Si un nodo Sound es desactivado por
un nodo Switch o LOD, y más tarde de nuevo llega a ser parte de la
intersección, el sonido deberá reanudarse como si hubiera estado
sonando constantemente.
El nodo Sound tiene un elipsoide interno que define un volumen de
espacio en el cual el máximo nivel de sonido es audible. Dentro de
este elipsoide los datos de la muestra normalizados son escalados
por el campo intensity y no hay ninguna atenuación. Si la elipsoide
interna es definida por extensión del vector de dirección por la
localidad. Los campos minBack y minFront especifican distancias
atrás y delante de la localización a lo largo del vector de dirección
respectivamente. El elipsoide interno tiene uno de sus focos en la
localización (el foco del segundo es implícito) e intercepta el vector
de la dirección en minBack y minFront.
El nodo Sound tiene un elipsoide exterior que define un volumen de

espacio ese limita la capacidad audible del sonido. El sonido no
puede ser oído fuera de este elipsoide. El elipsoide es definido por
la extensión del vector dirección a través de la localización. Los
campos maxBack y maxFront especifican distancias atrás y delante
de la localidad a lo largo del vector de la dirección respectivamente.
El elipsoide exterior tiene uno de su focos en la localización (el
enfoque del segundo es implícito) e intercepta el vector de la
dirección a maxBack y maxFront.
los campos minFront, maxFront, minBack, y maxBack son definidos

coordenadas locales, y deben ser >= 0.0. El campo de minBack
debe ser <= maxBack, y minFront debes ser <= maxFront. Se
especifican los parámetros del elipsoide en el sistema de la
coordenada local pero la geometría de la elipsoides se afecta por
transformaciones anteriores .
Entre los dos elipsoides habrá una atenuación lineal en potencia, de

0 [dB] en el elipsoide mínimo a -20 [dB] en el elipsoide del máximo:
attenuation = -20 × (d' / d")
donde d' es la distancia a lo largo del vector de localización-del-
observador, medida de la transformada mínimo del límite del
elipsoide al observador, y d" es la distancia a lo largo del vector de
localización-del-observador de la transformada mínima del límite
del elipsoide a la transformada máxima del límite del elipsoide.
El campo spatialize especifica si el sonido se percibe como una

dirección relativa al observador. Si el campo spatialize es TRUE y el
observador es localizado entre el elipsoide transformado interno y
externo, la dirección del observador y la localización relativa del
nodo Sound deberá ser tomados en cuenta durante el playback. Si
el campo spatialize es FALSO, entonces se ignoran los efectos de
dirección, pero las dimensiones del elipsoide e intensidad todavía
afectarár la potencia del sonido. Si la fuente del es multi-canal
([e.g]., estero), entonces la fuente debe retener sus canales
separados durante el playback.
AudioClip {
exposedField SFString description ""
exposedField SFFloat pitch 1.0
exposedField SFTime startTime 0
exposedField SFTime stopTime 0
eventOut SFTime duration_changed
}
Un nodo AudioClip especifica los datos de audio que pueden ser
referenciados por otros nodos que requieren una fuente de audio. El
campo description especifica una descripción textual de la fuente
del audio. No se requiere visualizador para desplegar el campo
description pero puede escoger hacerlo en adición a tocar el sonido.
El campo url especifica el URL (localizador de recursos) desde el
cual el sonido es cargado. los Browsers deben soportar por lo
menos el formato del wavefile en estructura estructura PCM, se
recomienda que los browsers también soporten archivos de tipo
MIDI. Los resultados no son definidos cuando el URL referenciado
tiene tipos de datos no soportados.
Los campos expuestos loop, startTime, y stopTime definne si el

sonido se repite, el tiempo de inicio y el tiempo de pare del sonido.
El "cycle" de un AudioClip es la longitud de tiempo en segundos por
un toque del audio en el pitch especifico.
El campo pitch(diapason) especifica un multiplicador para la tasa a
la cual un sonido muestreado es tocado. Sólo valores positivos son
permitidos por el pitch. Un valor de ceros o menos producirán
resultados indefinidos. Cambiar el campo pitch afectara ambos el
pitch y la velocidad del playback de un sonido. Si el evento
set_pitch para activar un AudioClip es ignorado y el evento de salida
pitch_changed no es generado. Si el pitch se fija a 2.0, el sonido
deberá ser tocado sobre una octava más alto de lo normal y tocado
dos veces más rápido. Para un sonido muestreado el campo fitch
altera la tasa de muestreo en la cual el sonido es tocado. La
implementación propia de control de pitch para MIDI es para
multiplicar el tiempo del playback por el valor del pitch y ajusta la
rudimentaria melodía MIDI.
Un evento duration_changed es enviado cuando quiera que hay un

valor nuevo para la duración "normal" del clip. Típicamente, esto
sólo ocurrirá cuando el url actual en usa cambie y los datos de
sonido han sido cargados, indicando que el clip esta tocando una
fuente diferente de sonido. La duración es la longitud de tiempo en
segundos por un ciclo del audio para un pitch puesto a 1.0.
Cambiando el campo pitch no activará un evento duration_changed.
Una valor de duración de "-1" implica que los datos de sonido no se
han cargado todavía o el valor no esta disponible por alguna razón.
El evento de salida isActive puede ser usado por otros nodos para
determinar si el clip esta actualmente activo. Si un AudioClip es
activo, este deberá tocar el sonido correspondiente al tiempo del
sonido.
t = (now - startTime) modulo (duration / pitch)
#VRML V2.0 utf8
#Programa para el monejo del sonido
#definiciones
DEF miSonido AudioClip

{ description "Programa de Sonido"
loop TRUE
pitch 4
startTime 0
stopTime 0
url "sonidos\explos.wav"
}
Transform
{
children [
Shape {geometry Sphere {radius 0.5}}
Sound {
direction 0 0 1
intensity 1
location 0 0 0
maxBack 10
maxFront 20
minBack 1
minFront 10
priority 1
source USE miSonido
spatialize TRUE
}
]
}
Text
Text {
exposedField MFString string []
exposedField SFNode fontStyle NULL
exposedField MFFloat length [] # [0,∞)
exposedField SFFloat maxExtent 0.0 # [0, ∞)
}
El nodo Text es un objeto string texto plano posicionado en el plano

Z=0 sobre el sistema coordenado local basad en los valores
definidos en el campo fontStyle. El nodo Text puede contener
múltiples strings de texto especificados en formato UFT-8. Los
strings de texto son almacenados en el orden en el cual los
caracteres modo texto van a ser reproducidos como defina los
parámetros en el nodo FontStyle.
Los strings de texto están contenidos en el campo string. El campo

fontStyle contiene un nodo FontStyle que especifica el tamaño de la
fuente la familia y estilo, la dirección del string de texto y cualquier
técnica de renderizacion de lenguaje especifico debe ser usada para
el texto.
El campo maxExtent limita y comprende todos los string del texto si

la longitud del string máximo es mas larga que la máxima extensión
medida en sistema coordenado local. Si el string del texto con la
maxima longitud es mas corta que maxExtent, entonces no hay
compresión. La máxima extensión es medida horizontalmente para
texto horizontal (FontStyle node: horizontal=TRUE) y verticalmente
para texto vertical (FontStyle node: horizontal=FALSE). El campo
maxExtent debe ser mayor de 0.0
El campo lenght contiene un valor MFFloat que especifica la

longitud de cada string de texto en el sistema coordenado local. Si
el string es demasiado corto. Este es estirado “por escalamiento del
texto o por adición de espacios entre los caracteresÓ. Si el string es
demasiado largo. Este es comprimido “por escalamiento del texto o
por substracción de espacio entre los caracteresÓ. Si un valor de
longitud hace falata “por ejemplo. Si hay cuatro strings pero
únicamente tres valores de longitudÓ. Los valores faltantes son
considerados a cero. El campo longitud debe ser mayor de 0.0.
Especificar un valor de 0 para ambos campos tanto length como

maxExtent indica que los string pueden ser de cualquier longitud.
FontStyle
FontStyle {
field MFString family ["SERIF"]
field SFBool horizontal TRUE
field MFString justify "BEGIN"
field SFString language ""
field SFBool leftToRight TRUE
field SFFloat size 1.0 # (0,∞)
field SFFloat spacing 1.0 # [0, ∞)
field SFString style "PLAIN"
field SFBool topToBottom TRUE
}
El nodo FontStyle define el tamaño, familia y estilo usado por el

nodo Text, como también la dirección de los strings del texto y las
técnicas de renderizacion especificas del lenguaje que pueden ser
usadas para texto no Ingles. El campo size especifica la altura
nominal, en sistema coordenado local del nodo Text. Los valores del
campo size deben ser mayores de 0.0.
El campo spacing determina el espacio de línea entre líneas

adyacentes de texto. La distancia entre la líneas base de cada línea
de texto es (spacing × size) en la dirección apropiada (dependiendo
de otros campos descritos abajo). Los valores del campo spacing
deber ser mayores o iguales 0.0.
Lo atributos de la fuente son definidos con los campos family y

style. Ewl browser mapeara los atributos especificados de la fuente
para una fuente disponible apropiada con se describe abajo.
El campo family contiene un case-sensitivo con valor MFString que

especifica una secuencia de familias de fuentes nombradas en
orden preferencial. Todos los browser deben soportar por lo menos
fuentes “SERIFÓ para funets serif tales como la Times Roman;
“SANSÓ para fuentes sans-serif tales como la Helvetica. Y
“TYPEWRITERÓ para fuentes fixed-pitch. Tales como la courier. Un
valor de family vacio es idéntico a [“SERIFÓ].
El campo style especifica un valor case-sensitivo SFString que

puede ser “PLAINÓ (por defecto) para el tipo plano de defecto;
“BOLDÓ para el tipo boldface. “ITALICÓ para el tipo itálico; o
“BOLDITALICÓ para el tipo bold e itálico. Un valor para style vacío es
equivalente a “PLAINÓ.
Dirección y justificación
Los campos horizontal, leftToRight y topBottom indican La dirección

del texto. El campo horizontal indica si el texto avanza
horizontalmente en su mayor dirección “horizontal=TRUEÓ o
vertical en su mayor dirección “horizontal=FALSEÓ. Los campos
leftToRight y topToBottom indican la dirección de avance del texto
en el mayo (caracteres dentro un string simple) y menor (strings
sucesivos) eje del arreglo. Que campo es usado para la dirección
mayor y cual es usado para la dirección menor es determinado por
el campo horizontal.
Para texto horizontal (horizontal=TRUE), los caracteres de cada

línea del texto avanzan en la dirección X positiva si leftToRight es
TRUE o en la dirección negativa de
X si leftToRight es FALSE. Los caracteres van avanzando de acuerdo
a su ancho de avance natural. Cada línea de caracteres avanza en
la dirección Y negativa si topToBottom es TRUE o en la dirección Y
positiva si topToBottom es FALSE. Las líneas van avanzando de
acuerdo a la cantidad sizex spacing.
Para texto vertical (horizontal =FALSE), los caracteres de cada línea

de texto avanzan en la dirección Y negativa si el topToBottom es
TRUE o en la dirección positiva Y si topToBottom es FALSE. Los
caracteres van avanzando de acuerdo a su alto de avance natural.
Cada línea de caracteres avanza en la dirección X positiva si
leftToRight es TRUE o en la dirección negativa de X si leftToRight es
FALSE . Las líneas van avanzando en la cantidad size x spacing.
El campo justify determina el alineamiento por encima del arreglo

relativo al orinen del sistema coordenado de objeto. El campo justify
es un MFString que puede contener dos valores. El primer valor
especifica el alineamiento a lo largo del eje mayor y el segundo
valor especifica el alineamiento a lo largo del eje menor. Como
determina el campo horizontal. Un valor para el campo justify de “Ó
es equivalente al valor por defecto. Si el segundo string,
alineamiento menor no es especificado el valor por defecto del
menor alineamiento es “FIRSTÓ . Los valores [“BEGINÓ y
“BEGINÓÓRIRSTÓ] SON EQUIVALENTES.
El mayor alineamiento es a lo largo del eje X cuando el campo

horizontal es TRUE y a lo largo del eje Y cuando horizontal es FALSE.
El menor alineamiento a lo largo del eje Y cuando horizontal es
TRUE y a lo largo del eje X cuando la horizontal es FALSE. Los
posibles valores para el campo justify son “ FIRSTÓ, “BEGINÓ,
“MIDDLEÓ y “ENDÓ. Para el mayor alineamiento, cada línea del
texto es posicionada individualmente de acuerdo al mayor
alineamiento enumerado. Para el menor alineamiento, el bloque del
texto representa todas las líneas juntas son puestas de acuerdo a la
menor enumeración de alineamiento.
El campo lenguaje especifica el contexto del lenguaje para el string

del texto. El campo language es necesario para proveer un
apropiado atributo del lenguaje del string del texto. Entre algunos
lenguaje podemos mencionar ‘zh =Chinese’, ‘jp=Japanese’,
‘sc=Swedish’. Si lenguaje esta vacío se ata el que se este usando.
#VRML V2.0 utf8

#experimentado con Text y FontStyle
Transform
{
children Shape
{geometry Text
{string "HOLA MUNDO"
fontStyle FontStyle
{
family "SANS"
horizontal FALSE
justify "END"
leftToRight TRUE
style "PLAIN"
topToBottom TRUE
}
maxExtent 1
}
}
}
Anchor
Anchor {
eventIn MFNode addChildren
eventIn MFNode removeChildren
exposedField MFNode children []
exposedField SFString description ""
exposedField MFString parameter []
field SFVec3f bboxCenter 0 0 0
field SFVec3f bboxSize -1 -1 -1
}
El nodo de agrupación del Anchor recupera el contenido de un URL

cuando el usuario activa (por ejemplo, pulsa el botón) de alguna
geometría contenida dentro del campo children del nodo Anchor. Si
el URL apunta a un archivo VRML válido, ese mundo reemplaza el
mundo del cual el nodo Anchor es una parte (excepto cuando el
campo de parámetros, descrito abajo, altera este comportamiento).
Si no se recuperan datos VRML, el browser determinará cómo
manejar esos datos; típicamente, serán pasados a un apropiado
browser non-VRML.
Exactamente cómo un usuario activa geometría contenida por el

nodo Anchor depende del dispositivo apuntador y es determinado
por el browser VRML.
El campo descripción del nodo Anchor sirve para especificar una

descripción textual que sirva
al usuario par ver los detalles necesarios sobre el archivo VRML.
El campo expuesto parameter puede ser usado para brindar

información que pueda ser interpretada por el browser VRML y
HTML. Cada string puede contener la pareja “palabra clave=valorÓ
por ejemplo algunos browser asigna la especificación “targetÓ para
efectuar encadenamientos etc.
Anchor {
parameter [ "target=name_of_frame" ]
...
}
Un nodo Anchor puede ser usado par atar un nodo Viewpoint

especificando el nombre al final de campo url con la sintaxis
#AlgunNombreDeCamara
Anchor {
url "http://.../AlgunaEscena.wrl#AlgunNombreDeCamara"
children Shape { geometry Box {} }
}
cuando se cargue la escena AlgunaEscena.wrl se ata la cámara

“ViewpoitÓ AlgunNombreDeCAmara justo cuando se active la
geometría. si el nombre de la cámara no se encuentra se cargará
por defecto la del browser.
Si en el campo url solo se especifica el nombre de la cámara esta se
cargar si existe en el ambiente actual dan set_bind un valor de
TRUE.
por ejemplo:
Anchor {
url "#Doorway"
children Shape { geometry Sphere {} }
}
Los campos bboxCenter y bboxSize especifican una caja en la cual

se encierra el alcance del
del nodo Anchor ello para efectos de optimización del browser.
#VRML V2.0 utf8

#experimentando con Anchor
Anchor
{ children Shape {geometry Box {}}
bboxCenter 1 0 0
bboxSize 111
description "ESTE ES MI ANCHOR"
parameter ""
url "texto.WRL"
}
Interpoladores
Los nodos interpoladores están diseñados para animaciones

lineales. Un nodo interpolador define una función lineal f(t), en el
intervalo (-∞,+∞). La función lineal es definida por n valores de t.
Llamados claves, sobre los correspondientes n valores de f(t),
llamados keyValue. Las claves serán monotonicas no decrecientes y
no son restringidas a cualquier intervalo. Los resultados son
indefinidos si las claves no son monotonica o no decrecientes.
Un nodo interpolador evalúa f(t) dando cualquier valor de t (vía el

evento de entrada set_fraction) como sigue:
De las n claves k0,k1,k2,...,kn-1 partiendo el dominio (-∞,+∞)
dentro de los n+1 subintervalos (-∞,k0) , [k0,k1),[k1,k2),...,[kn-1,+
∞)
tambien de los n valores v0,v1,v2,...,vn-1 estos serán los valores
de una función desconocida, F(t) a los valores de clave asociados.
Esto es vj=F(kj). La función f(t) será definida como
f(t) = v0, si t < k0,

= vn-1, si t > kn-1,
= vi, si t = ki para cualquier valor de i, donde -1 < i < n,
= linterp(t, vj, vj+1), si kj < t < kj+1
Donde interp(t,x,y) es una interpolación lineal y -1 < j < n-1.
El tercer valor condicional de f(t) asigna la definición de múltiples

valores para una clave simple (limites de ambos la izquierda y la
derecha en una discontinuidad en f(t)). El primer valor especificado
es usado como el limite de f(t) de izquierda. El ultimo valor
especificado es usado como el limite de f(t) de derecha. Los valores
de f(t) en una múltiple clave definida es indeterminado. Pero debe
ser uno de los valores limite asociados.
Los nodo iterpoladores manejados por VRML son:

•ColorInterpolator
•CoordinateInterpolator
•NormalInterpolator
•OrientationInterpolator
•PositionInterpolator
•ScalarInterpolator
Todos los nodo interpoladores tiene una semántica común así:
eventIn SFFloat set_fraction

exposedField MFFloat key [...]
exposedField MF<type> keyValue [...]
eventOut [S|M]F<type> value_changed
El tipo “typeÓ del campo keyValue es dependiente del tipo de

interpolador por ejemplo para
ColorInterpolator el campo keyValue es de tipo MFColor.
El evento de entrada set_fraction recibe un SFFloat y causa la

función interpolador a evaluar, resultando el evento de salida
value_changed como el mismo timestamp del evento set_fraction
ColorInterpolator {
exposedField MFFloat key []
exposedField MFColor keyValue []
eventOut SFColor value_changed
}
El campo key contiene las porcentajes de interpolación del campo

keyValue que contiene los colores de interpolación hay que tener en
cuenta que deben existir tantos porcentajes de interpolación como
colores.
El evento de entrada set_fraction recibe un evento que indica el
comienzo de la interpolación
el evento de salida value_changed genera los valores de
interpolación.
OrientationInterpolator {
exposedField MFRotation keyValue []
eventOut SFRotation value_changed
}
el nodo OrientationInterpolator interpola valores de rotación sin que

estos sean acumulativos.
keyValue que contiene los ángulos de rotación de interpolación.
Hay que tener en cuenta que deben existir tantos porcentajes de
interpolación como ángulos de rotación.
interpolación.
PositionInterpolator {
exposedField MFVec3f keyValue []
eventOut SFVec3f value_changed
}
el nodo PositionInterpolator interpola valores de traslación sin que
estos sean acumulativos.
keyValue que contiene las posiciones de interpolación. Hay que
tener en cuenta que deben existir tantos porcentajes de
interpolación como posiciones de traslación.
interpolación.
ScalarInterpolator {
exposedField MFFloat keyValue []
eventOut SFFloat value_changed
}
el nodo ScalarInterpolator interpola valores como radios, intensidad,

brillo etc. sin que estos sean acumulativos.
keyValue que contiene las valores de interpolación. Hay que tener
en cuenta que deben existir tantos porcentajes de interpolación
como valores.
interpolación.
CoordinateInterpolator {
exposedField MFVec3f keyValue []
eventOut MFVec3f value_changed
}
Este nodo linealmente interpola entre un conjunto de valores

MFVecef. El numero de coordenadas en el campo keyValue debe ser
un múltiplo entero del número de keyframes en el campo key. Este
múltiplo entero como las coordenadas serán contenidas en el
evento de salida value_changed.
TimeSensor {
exposedField SFTime cycleInterval 1
exposedField SFBool enabled TRUE
exposedField SFTime startTime 0
exposedField SFTime stopTime 0
eventOut SFTime cycleTime
eventOut SFFloat fraction_changed
eventOut SFTime time
}
El nodo TimeSensor genera eventos en pasos de tiempo. El nodo

TimeSensor puede ser usado para:
a. Manejo de simulación continua y animación.
b. control de actividades periódicas.
c. iniciación de ocurrencias de eventos.
El evento de salida isActive manda un valor verdadero cuando el

TimeSensor empieza a correr y falso cuando para de correr. El
evento de salida cycleTime envía un evento de salida al startTeime
al empiezo de cada ciclo. El evento de salida fraction_changed
envía la fracción actual en el ciclo actual
El campo enable habilita o desabilita el TimeSensor. El campo loop

activa una secuencia en el nodo TimeSensor, el campo starTime da
el tiempo de inicio de un ciclo y el campo stopTime da el tiempo de
finalización de un ciclo. el campo cycleInterval da al ciclo la
duración que tenga este en segundos.
#VRML V2.0 utf8
#programa para el amnejo de una interpolación de rotacion
DEF SistemaMundial Transform

{
rotation 0 0 1 0.575959
children DEF SistemaTerrestre Transform
{
children
[
Shape
{
appearance
Appearance {texture ImageTexture{url
"Texture/Sky_2.gif"}}
geometry Sphere { }
}
DEF RelojTierra TimeSensor
{
cycleInterval 8
loop TRUE
}
DEF GiroTierra OrientationInterpolator
{
key [0,0.33,0.66,1]
keyValue [0 0 1 0,0 1 0 2.1,0 1 0 4.2,0 0 1 0]
}
DEF SistemaLunar Transform
{
translation 5 0 0
children[
Shape {
appearance
Appearance {texture ImageTexture{url
"Texture/Marble3.jpg"}}
geometry Sphere {radius 0.3}
}
DEF RelojLuna TimeSensor
{
cycleInterval 8
loop TRUE
}
DEF GiroLuna OrientationInterpolator

{
key [0,0.33,0.66,1]
keyValue [0 0 1 0,0 1 0 2.1,0 1 0 4.2,0 0 1 0]
}
]
ROUTE RelojLuna.fraction_changed TO GiroLuna.set_fraction

ROUTE GiroLuna.value_changed TO SistemaLunar.rotation
}
]
ROUTE RelojTierra.fraction_changed TO GiroTierra.set_fraction
ROUTE GiroTierra.value_changed TO SistemaTerrestre.rotation
}
}
TouchSensor {
eventOut SFVec3f hitNormal_changed
eventOut SFVec3f hitPoint_changed
eventOut SFVec2f hitTexCoord_changed
eventOut SFBool isOver
eventOut SFTime touchTime
}
Un nodo TouchSensor rastrea la localización y estado del dispositivo

puntero y detecta cuando el usuario apunta a geometría contenida
por un grupo padre del nodo TouchSensor. Un nodo TouchSensor se
puede habilitar o desabilitar por el envía de un evento con un valor
de TRUE o FALSE. Si el nodo TouchSensor es desactivado, no rastrea
las entradas del usuario o eventos enviados.
El TouchSensor genera eventos cuando el dispositivo puntero
apunta hacia cualquier nodos de geometría que son descendientes
del grupo padre del TouchSensor.
El evento de salida isOver refleja el estado del dispositivo puntero

con respecto a si apunta hacia la geometría del nodo TouchSensor o
no. Cuando el dispositivo puntero cambia el estado de una posición
tal que no corta cualquier geometría del nodo TouchSensor a una
en la que corta la geometría, se genera el evento TRUE isOver.
Cuando el dispositivo apuntador se mueve de una posición tal que
la marcación corta la geometría para uno en el que no intercepta
más alla la geometría, o algunos otra geometría obstruye la
geometría del nodo TourachSensor, se genera el evento FALSE para
isOver. Se generan sólo estos eventos cuando el dispositivo
apuntador ha movido y cambiado su estado over. No se generan
eventos si la geometría así mismo se esta animando y moviendo
debajo del dispositivo puntero.
Como el usuario mueve la marcación encima de la geometría del
nodo TouchSensor, el punto de intersección entre la marcación y a
geometría es determinado. Cada movimiento del dispositivo
apuntador, mientras isOver es TRUE, genera hitPoint_changed,
hitNormal_changed y eventos hitTexCoord_changed. los eventos
hitPoint_changed contiene los puntos 3D en la superficie de la
geometría subyacente, dados en el sistema de la coordenada del
nodo TouchSensor. Los eventos hitNormal_changed contienen el
vector del normal de la superficie en el hitPoint. Los eventos
hitTexCoord_changed contienen las coordenadas de textura de esa
superficie en el hitPoint.
Si isOver es TRUE, el usuario puede activar el dispositivo apuntador

para causar al nodo TouchSensor la generación del evento isActive
(por ejemplo preisonando el botón primario del mouse). Cuando el
nodo TouchSensor genera un evento isActive TRUE, este graba
todos los siguientes eventos de movimiento del dispositivo puntero
hasta que este sea liberado y genere un evento isActive FALSE
(otros sensores dispositivos apuntadores no generaran eventos
durante este tiempo). El movimiento de un dispositivo apuntado
cuyo isActive sea TRUE es llamado “dragÓ. Si un dispositivo 2D esta
en uso, Los eventos isActive reflejan el estado del boton primario
asociado con el dispositivo (isActive esTRUE cuando el botón
primario esta presionado y falso cuando esta suelto). Si un
dispositivo 3D esta en uso , los eventos isActive típicamente
reflejarán si el dispositivo apuntador esta con (o en contacto con)
una geometría del nodo.
El evento de salida touchTime es generado cuando toda las tres

siguientes condiciones son verdaderas:
a. El dispositivo apuntador estuvo apuntando hacia la geometría
cuando ella fue inicialmente activada (isActive esTRUE).
b. El dispositivo puntero esta corrientemente apuntando hacia la
geometría (isOver es TRUE).
c. El dispositivo apuntador esta desactivado (el evento isActive
FALSE también es generado.
Script
Script {
field SFBool directOutput FALSE
field SFBool mustEvaluate FALSE
# And any number of:
eventIn eventType eventName
field fieldType fieldName initialValue
eventOut eventType eventName
}
El nodo Script es usado para programar el comportamiento de una

escena. Un nodo Scirpt sirve para:
a.efectuar un cambio o ver una accion del usuario

b.recibir eventos de otros nodos
c.contener modulos de programas que ejecuten un copmuto
d.efectuar cambiso en la escena por el envio de eventos.
eventIn type name. Es un evento de entrada de cualqueir tipo

estandar de VRML declarado por el usuario.
eventOut type name. Es un evento de salida de cualquier tipo
estandar de VRML declardo por el usuario.
En el nodo Script no son permitidos los exposedField.
El campo mustEvaluate evalua para un determinado browser el

envio de eventos de entrada si es FALSE el browser puede retardar
el envio de eventos de entrada al script hasta que sus salidas sean
necesitadas por el browser. Si el campo mustEvaluate es TRUE el
browser debera enviar los eventos de entrada al script tan pronto
como sea posible a menos que otra de las salidas sea necesaria.
El campo directOutput sirve para establecer las condicones de envia

de eventos cuando este campo es TRUE el script puede enviar
eventos directamente a cualquier nodo al cual el tiene acceso y
puede dianmicamente establecer rutas. Si el campo directOutput es
FALSE el script puede afectar unicamente el resto de la escena via
los eventos de salida.
Un script esta abilitado para comunicarse directamente con el

browser VRML para obtener informacion tal como el tiempo actual
y el actual mundo URL. Este es definido estrictamente por el API
para el especifico lenguaje script que esta siendo usado.
#VRML V2.0 utf8
#Programa para el manejo de script
DEF SistemaMundial Transform {
children [
DEF CuboIzquierdo Transform
{
translation -5 0 0
children [
Shape {
appearance
Appearance {material Material {diffuseColor 1 0 0}
}
geometry Box {}
}
DEF Esfera Shape { geometry Sphere{radius 1.3} }
]
}
DEF CuboDerecho Transform
{
translation 500
children [
Shape {
appearance
Appearance {material Material {diffuseColor 0 0
1}}
geometry Box {}
}
]
}
DEF Boton Transform
{
translation 0 -5 0
children [
Shape {
appearance
Appearance {material Material {diffuseColor 0 1
0} }
geometry Box {}
}
DEF Tocar TouchSensor {}
DEF Programa Script {
url "vrmlscript:
function cambiar(valor)
{
if(vf){nodo_cambiado1 =
nodo;vf=FALSE;}
else {nodo_cambiado2 =
nodo;vf=TRUE ;}
}"
directOutput FALSE
mustEvaluate FALSE
eventIn SFTime cambiar
eventOut MFNode nodo_cambiado1
eventOut MFNode nodo_cambiado2
field MFNode nodo USE Esfera
field SFBool vf TRUE
}
]
ROUTE Tocar.touchTime TO Programa.cambiar
ROUTE Programa.nodo_cambiado1 TO
CuboIzquierdo.removeChildren
ROUTE Programa.nodo_cambiado1 TO CuboDerecho.addChildren
ROUTE Tocar.touchTime TO Programa.cambiar

ROUTE Programa.nodo_cambiado2 TO
CuboDerecho.removeChildren
ROUTE Programa.nodo_cambiado2 TO CuboIzquierdo.addChildren
}
]
}
Viewpoint
Viewpoint {
exposedField SFFloat fieldOfView 0.785398 # (0,
π)
exposedField SFBool jump TRUE
exposedField SFRotation orientation 0010 #
[-1,1],(- ∞,∞)
exposedField SFVec3f position 0 0 10 # (-
∞,∞)
field SFString description ""
eventOut SFTime bindTime
}
El nodo Viewpoint se define en sistema local de coordenadas, el

nodo Viewpoint se define en un stack es decir que pueden existir
varias cámaras pero solo una estará activa según este o no en el
tope. Todos los cambios efectuados al sistema coordenado local
afectaran igualmente la cámara. Cuando una cámara es movida del
tope de la pila envía un evento isBound FALSE y es colocado en el
fondo de la pila. Con una animación utilizando cámaras se pueden
obtener efectos interesantes a través de la captura de diferentes
escenas.
El evento de salida bindTime envía el tiempo en el cual el nodo
Viewpoint es atada o desatado
así:
a. durante el cargado.
b. cuando al nodo Viewpoint es enviado un evento set_bind.
c. cuando el browser ata el nodo Viewpoint a través de su interfaz
de usuario.
Los campos position y orientation del nodo Viewpoint especifican la
localización y rotación relativa en sistema coordenado local. El
campo jump especifica si la vista de usuario salta a la posición y
orientación del nodo Viewpoint atado o permanece incambiable. El
manejo de este campo es importante por cuanto activar una
cámara o no puede traer implicaciones cuando de colisiones se
trata esto es activar una cámara en un espacio que no es permitido.
El Campo fieldOfView especifica un mínimo ángulo de visión del

observador expresado en radianes. Un ángulo reducido corresponde
a un lente reducido y un ángulo grande corresponde a un lente
ancho. El ángulo de visión debe ser más grande de cero y menor
que la figura. el valor del campo de visión representa el mínimo
ángulo de visón en cualquier dirección perpendicular a los ejes. Un
browser con una proyección rectangular debe tener la siguiente
relación:
ancho pantalla/ alto pantalla = tan(FOVhorizontal/2) /
tan(FOVvertical/2)
El campo descripción se puede utilizar para efectuar la descripción

textual del nodo Viewpoint. Este puede ser usado por los browser
para especificar la interfaz de usuario. Si este campo se deja vacío
se deja la posibilidad de utilizar la cámara del visualizador.
#VRML V2.0 utf8
#programa de manejo de camaras
DEF SistemaMundial Transform {

children
[
DEF SistemaSol Transform
{
children [ Shape {
appearance
Appearance {texture DEF Fire
ImageTexture {url "Texture/Fire_4.gif"}
}
geometry DEF Sol Sphere {radius 2}
}
DEF SistemaCamaraSol Transform
{
translation -1 2.1 0
rotation 0 -1 0 1.5708
children DEF Camara Viewpoint
{
jump TRUE
orientation 0 0 -1 0
position 0 0 0
description ""
}
}
DEF TocarSol TouchSensor {}
DEF RelojSol TimeSensor {
cycleInterval 4
loop TRUE
}
DEF RotacionSol OrientationInterpolator
{
key [ 0, 0.5, 1 ]
keyValue [ 0 1 0 0,0 1 0 3.1416,0 1 0 6.2832 ]
}
]#fin del children del SistemaSol
ROUTE RelojSol.fraction_changed TO RotacionSol.set_fraction
ROUTE RotacionSol.value_changed TO SistemaSol.rotation
}#fin de la transformacion del SistemaSol
DEF SistemaBase Transform

{
children [
DEF SistemaTierra Transform
{
translation 12 0 0
children [ Shape {
appearance
Appearance {texture ImageTexture {url
"Texture/Sky_2.gif"}}
geometry DEF Tierra Sphere {}
}
DEF SistemaCamaraTierra Transform
{
translation 1 1.1 0
rotation 0 1 0 1.5708
children NULL
}
DEF TocarTierra TouchSensor {}
DEF RelojTierra TimeSensor
{
cycleInterval 4
loop TRUE
}
DEF RotacionTierra OrientationInterpolator
{
key [ 0, 0.5, 1 ]
keyValue [ 0 1 0 0,0 1 0 3.1416,0 1 0 6.2832 ]
}
DEF SistemaLuna Transform
{
translation 200
children [ Shape {
appearance
Appearance {texture
ImageTexture {url
"Texture/Marble3.jpg"}
}
geometry DEF Luna Sphere {radius
0.4}
}
DEF SistemaCamaraLuna Transform

{
translation 1 1.1 0
rotation 0 1 0 1.5708
children NULL
}
DEF TocarLuna TouchSensor {}
DEF RelojLuna TimeSensor
{
cycleInterval 2
loop TRUE
}
DEF RotacionLuna
OrientationInterpolator
{
key [0,0.5,1]
keyValue [0 1 0 0,0 1 0 3.1416,0 1 0
6.2832 ]
}
]#fin children SistemaLuna
ROUTE RelojLuna.fraction_changed TO
RotacionLuna.set_fraction
ROUTE RotacionLuna.value_changed TO
SistemaLuna.rotation
}#fin del SistemaLuna
]#fin del children SistemaTierra
ROUTE RelojTierra.fraction_changed TO
RotacionTierra.set_fraction
ROUTE RotacionTierra.value_changed TO
SistemaTierra.rotation
}#fin de la transformación del SistemaTierra
DEF RelojBase TimeSensor
{
cycleInterval 25
loop TRUE
}
DEF RotacionBase OrientationInterpolator
{
key [ 0, 0.5, 1 ]
keyValue [ 0 0 1 0,0 1 0 3.1416,0 1 0 6.2832 ]
}
]#fin del children SistemaBase
ROUTE RelojBase.fraction_changed TO RotacionBase.set_fraction
ROUTE RotacionBase.value_changed TO SistemaBase.rotation
}#fin de la transformacion del sistemaBase
DEF Programa Script {

url "vrmlscript:
function cambiarSol(valor){nodo_cambiadoS=nodo;}
function cambiarTierra(valor){nodo_cambiadoT=nodo;}
function cambiarLuna(valor){nodo_cambiadoL=nodo;}
"
directOutput FALSE
mustEvaluate FALSE
eventIn SFBool cambiarSol
eventIn SFBool cambiarTierra
eventIn SFBool cambiarLuna
field MFNode nodo USE Camara
eventOut MFNode nodo_cambiadoS
eventOut MFNode nodo_cambiadoT
eventOut MFNode nodo_cambiadoL
}
]#fin del chlidren del SistemaMundial
#####
ROUTE TocarSol.isActive TO Programa.cambiarSol
ROUTE Programa.nodo_cambiadoS TO
SistemaCamaraTierra.removeChildren
SistemaCamaraLuna.removeChildren
SistemaCamaraSol.addChildren
###############
ROUTE TocarTierra.isActive TO Programa.cambiarTierra
ROUTE Programa.nodo_cambiadoT TO
SistemaCamaraSol.removeChildren
SistemaCamaraLuna.removeChildren
SistemaCamaraTierra.addChildren
###############
ROUTE TocarLuna.isActive TO Programa.cambiarLuna
ROUTE Programa.nodo_cambiadoL TO
SistemaCamaraSol.removeChildren
SistemaCamaraTierra.removeChildren
SistemaCamaraLuna.addChildren
#####
}#fin de la transformacion del SistemaMundial
Prototipos
El comando PROTO define un nuevo tipo de nodo en términos de

los nodos ya definidos. El nombre del tipo de nodo debe ser único
en cada archivo VRML. La interfaz de un prototipo es definida a
través de uno o mas field, eventIn y eventOut. En la declaración se
debe incluir para los eventIn y eventOut su nombre y tipo, para los
field es necesario incluir además del nombre y tipo un valor por
defecto. También se pueden declarar exposedField los cuales
resultan convenientes para definir al mismo tiempo un eventIn, un
filed y un eventOut es decir si definimos un exposedFiled llamado
miCampoExpuesto es equivalente a declarar un field llamado
miCampoExpuesto, un eventIn llamado set_miCampoExpuesto, y un
eventOut llamado miCampoExpuesto_changed.
Un prototipo se instancia con la sintaxis estándar de los nodos, cada
instancia del prototipo es una copia completa del prototipo. Nodos
definidos dentro de un prototipo pueden tener sus campos y
eventos asociados a los campos y eventos de la interfaz del
prototipo esto a través del comando IS dentro del cuerpo del nodo.
#VRML V2.0 utf8

PROTO miEscalar
[field SFVec3f escalaInicial 1 1 1 field SFVec3f escalaFinal 2 2 2
field MFNode miChildren [] ]
{
DEF SC Transform {children IS miChildren}
DEF Reloj TimeSensor { cycleInterval 8 loop TRUE }
DEF Interp PositionInterpolator { key [0 1] keyValue [1 1 1, 2 2
2] }
DEF miProg Script
{
url "javascript:
function Cambiar()
{ if(vf) {escalamiento = new
MFVec3f(escalaInicial,escalaFinal);vf=FALSE;}
else {escalamiento = new
MFVec3f(escalaFinal,escalaInicial);vf=TRUE; } } "
eventIn SFTime Cambiar
field SFBool vf FALSE
field SFVec3f escalaInicial IS escalaInicial
field SFVec3f escalaFinal IS escalaFinal
eventOut MFVec3f escalamiento
}
ROUTE Reloj.cycleTime TO miProg.Cambiar
ROUTE miProg.escalamiento TO Interp.set_keyValue
ROUTE Reloj.fraction_changed TO Interp.set_fraction
ROUTE Interp.value_changed TO SC.scale
}
Transform
{children miEscalar{ miChildren Shape {geometry Box{}}}}
PlaneSensor {
exposedField SFBool autoOffset TRUE
exposedField SFVec2f maxPosition -1 -1 # (-∞,
∞)
exposedField SFVec2f minPosition 00 # (-∞,
∞)
exposedField SFVec3f offset 0 0 0 # (-∞,
∞)
eventOut SFVec3f trackPoint_changed
eventOut SFVec3f translation_changed
}
El nodo PlaneSensor traza el movimiento del puntero de dispositivo

dentro de una traslación en dos dimensiones en plano paralelo al
plano Z=0 del sistema coordenado local. El nodo PlaneSensor usa la
geometría descendiente de su nodo padre para determinar si ella es
responsable de la generación de eventos.
El campo expuesto enabled habilita o deshabilita el PlaneSensor. Si

enabled está TRUE, el sensor reacciona apropiadamente a los
eventos del usuario. Si enabled es FALSE, el sensor no rastrea la
entrada del usuario o envía eventos. Si enabled recibe un evento
FALSE y isActive es TRUE, el sensor vuelve a deshabilitado o
desactivado , y envía un evento isActive FALSE. Si enabled recibe un
evento TRUE, se habilita el sensor y queda listo para la activación
del usuario. El nodo PlaneSensor genera eventos cuando el puntero
de dispositivo es activado mientras que el puntero este indicando
cualquier nodos de geometría descendiente del grupo padre del
sensor.
En la activación del puntero de dispositivo (botón del ratón

presionado) mientras indica la geometría del sensor, se envía el
evento TRUE isActive. El puntero de movimiento es trazado dentro
de l a traslación relativa en un plano paralelo al plano local del
sensor Z r= 0 y coincidente con el punto inicial de intersección. Por
cada movimiento subsecuente del marcador, un evento
translation_changed es dado tal que corresponde a la suma de la
traslación relativa del punto de intersección original de la nueva
marcación en el plano más el valor de desplazamiento. El signo de
la traslación es definida por el plano Z=0 del sistema coordenado
del sensor. los eventos trackPoint_changed reflejan el posición de
arrastre sujetada en la superficie de este plano. Cuando el puntero
de dispositivo es desactivado y el autoOffset es TRUE, el offset es
dado en el último valor de translation_changed y se genera el
evento offset_changed.
Cuando el sensor genera un evento isActive TRUE, ello graba todo

los eventos de movimiento poeteriores del puntero de dispositivo
hasta que es desactivado y genera un evento isActive FALSE. Otro
sensores punteros de dispositivo no pueden generar eventos
durante este tiempo. El movimiento de puntero de dispositivo
mientras isActive es TRUE se referido como un "drag". Si un
puntero de dispositivo 2D está en uso, los eventos isActive
típicamente reflejan el estado del botón primario asociado con el
dispositivo ( isActive es TRUE cuando el botón primario esta
presionado, y es FALSE cuando es soltado). Si un puntero de
dispositivo (wand) está en uso, los eventos isActive típicamente
reflejan si el puntero es dentro o en contacto con la geometría del
sensor.
minPosition y maxPosition pueden ser fijadas para sujetar eventos

translation_changed en un rango de valores como medida del
origen del plano Z= 0. Si la componente X o Y de minPosition es
más grande que el componente correspondiente de maxPosition, no
se sujetan eventos translation_changed en esa dimensión. Si el
componente X o Y de minPosition es igual al componente
correspondiente de maxPosition, el componente es restringido al
valor dado. Esta técnica provee una manera de implementar una
línea sensor que traza movimiento de arastre de una traslación en
una dimensión.
Mientras el puntero de dispositivo es activado y movido, los eventos

trackPoint_changed y translation_changed son enviados. Los
eventos trackPoint_changed representan el punto de intersección
sujetadas sobre la superficie del plano local Z=0. Si el puntero de
dispositivo esta fuera del plano Z= 0 mientras esta activado ([e.g].,
por encima de la línea horizontal), los browsers pueden interpretar
esto en una variedad de formas. Cada movimiento del puntero de
dispositivo, mientras isActive es TRUE, genera eventos
trackPoint_changed y translation_changed.
#VRML V2.0 utf8

#experimentando con PlaneSensor
{children DEF SistemaCubo Transform
{children [
Shape {appearance
Appearance {material Material {diffuseColor
1 0 0} }
geometry Box {}
}
DEF Plano PlaneSensor {
autoOffset TRUE #pruebe FALSE
maxPosition 5 5
minPosition -5 -5
offset 0 0 0
}
]
ROUTE Plano.translation_changed TO
SistemaCubo.translation
}
}
#VRML V2.0 utf8
#experimentando con isActive de PlaneSensor

{
children DEF SistemaCubo Transform
{
children [
Shape {appearance
Appearance{material Material{diffuseColor 1 0
0}}
geometry Box{}
}
DEF Plano PlaneSensor {}
DEF Reloj TimeSensor { cycleInterval 2 }
DEF RotacionCubo OrientationInterpolator
{ key [ 0, 1 ]
keyValue [ 0 0 1 0,0 1 0 3.1416 ]
}
]
ROUTE Plano.isActive TO Reloj.loop
ROUTE Reloj.fraction_changed TO RotacionCubo.set_fraction
ROUTE RotacionCubo.value_changed TO
SistemaMundial.rotation
}
}
SphereSensor
SphereSensor {
exposedField SFBool autoOffset TRUE
exposedField SFRotation offset 0100
eventOut SFRotation rotation_changed
eventOut SFVec3f trackPoint_changed
}
El nodo SphereSensor traza el movimiento del puntero dispositivo

dentro de una rotación esférica alrededor del sistema coordenado
local. El nodo SphereSensor usa la geometría descendente de su
nodo padre si es responsable de generar eventos.
El campo expuesto enabled habilita y deshabilita el nodo

SphereSensor. Si enabled es TRUE, el sensor reacciona
apropiadamente a los eventos del usuario. Si enabled es FALSE, el
sensor no rastrea las entradas del usuario o envía eventos. Si
enabled recibe un evento FALSE y isActive es TRUE, el sensor se
convierte deshabilitado y desactivado y saca un evento isActive
FALSE. Si enabled recibe un evento TRUE se habilita el sensor y esta
listo para la activación del usuario.
El nodo SphereSensor genera eventos cuando el puntero de
dispositivo es activado mientras el puntero esta indicando
cualquier nodos geometría descendente del grupo padre del sensor.
En la activación del puntero dispositivo ( botón del mouse

presionado) encima de la geometría del sensor, se envía el evento
isActive TRUE. El vector definido por el punto inicial de intersección
en el la geometría de SphereSensor y el origen local determina la
radio de la esfera que se usa para trazar el movimiento
subsecuente del puntero dispositivo mientras arrastra. La esfera
virtual definida por este radio y el origen local en el tiempo de
activación se usa para interpretar el movimiento subsecuente del
puntero dispositivo y no se afecta por cualquier cambio en el
sistema coordenada del sensor mientras el sensor esta activo. Por
cada posición de marcación, se envía un evento rotation_changed
que corresponde a la suma de la rotación relativa del punto de
intersección original más el valor offset. El eventos
trackPoint_changed refleja el posición de arrastre tomada en la
superficie de esta esfera. Cuando el puntero de dispositivo es
desactivado y autoOffset es TRUE, el offset es dado al último valor
de rotation_changed y se genera un evento offset_changed.
Cuando el sensor genera un evento isActive TRUE, el graba todos

los eventos de movimiento posteriores del puntero de dispositivo
hasta que es liberado y genera un evento isActive FALSE (otro
punteros de dispositivo no generan eventos durante este tiempo).
El movimiento del dispositivo puntero mientras isActive es TRUE es
denominado un "drag." Si un puntero de dispositivo 2D está en uso,
los eventos isActive reflejarán típicamente el estado del botón
primario asociado con el dispositivo (isActive es VERDADERO
cuando el botón primario es presionado y FALSE cuando es
liberado). Si un puntero de dispositivo 3D (wand) está en uso, los
eventos isActive reflejarán típicamente si el puntero estro dentro(o
en contacto con) la geometría de la sensor.
Mientras el puntero de dispositivo esta activado los eventos
trackPoint_changed y rotation_changed son enviados. Los eventos
trackPoint_changed representan el punto intersección de sujeción
en la superficie de la esfera invisible. Cada movimiento del puntero
dispositivo mientras isActive es TRUE genera eventos
trackPoint_changed y rotation_changed.
#VRML V2.0 utf8

#experimentando con SphereSensor
{
children DEF SistemaCubo Transform
{children [ Shape {appearance
Appearance {material Material {diffuseColor 1
0 0}}
geometry Box {}
}
DEF Esfera SphereSensor {}
DEF Reloj TimeSensor {cycleInterval 2}
DEF RotationCubo OrientationInterpolator
{
key [ 0, 1 ]
keyValue [ 0 0 1 0,0 1 0 3.1416 ]
}
]#fin del children de sistema del cubo
ROUTE Esfera.isActive TO Reloj.loop
ROUTE Reloj.fraction_changed TO RotationCubo.set_fraction
ROUTE RotationCubo.value_changed TO
SistemaCubo.rotation
}#fin del sistema del cubo
}#fin del sistema mundial
#VRML V2.0 utf8

#experimentando con autOffset de SphereSensor
{children DEF SistemaCubo Transform
{children [
Shape {appearance
Appearance {material Material {diffuseColor
1 0 0}}
geometry Box {}
}
DEF Esfera SphereSensor
{
autoOffset TRUE #pruebe con FALSE
offset 0010
}
]
ROUTE Esfera.rotation_changed TO SistemaCubo.rotation
}
}
#VRML V2.0 utf8
DEF SCM Transform

{
children
[
######################UBICACION DE LA
ESCENA#########################
DEF SCE Transform{
#aqui se colo caria toa la escena
}
################UBICAION DEL
OBSERVADOR################################
DEF SCT Transform {
children DEF SCR Transform
{
children [
Transform {
rotation 1 0 0 -1.570796326795
children
Shape{appearance
Appearance {material
Material{diffuseColor 1 1 0}}
geometry Cone{}
}
}
Transform {
translation 0 -1.5 0
children
Shape{appearance
Appearance {material
Material{diffuseColor 1 0 0}}
geometry Sphere{radius 1.2}
}
}
]
}
}
#########################################
##############################
]
}
DEF SCControles Transform
{
translation 0 -3 0
children
[
DEF SCControlVel Transform
{
translation 0 -5 0
children [
Shape {geometry Sphere{radius 0.5}}
DEF ToqueV TouchSensor{}
]
}
DEF SCControlYNR Transform
{
translation 3 -5 0
children [
Shape {geometry Box{size 1.5 0.5 1}}
DEF ToqueYNR TouchSensor{}
DEF RelojYNR TimeSensor{cycleInterval 4}
]
}
DEF SCControlYPR Transform
{
translation -3 -5 0
children [
Shape {geometry Box{size 1.5 0.5 1}}
DEF ToqueYPR TouchSensor{}
DEF RelojYPR TimeSensor{cycleInterval 4}
]
}
DEF SCControlZN Transform

{
translation 1 -5 0
children [
Shape {geometry Box{size 0.5 1 1}}
DEF ToqueZN TouchSensor{}
DEF RelojZN TimeSensor{cycleInterval 4}
]
}
DEF SCControlZP Transform
{
translation -1 -5 0
children [
Shape {geometry Box{size 0.5 1 1}}
DEF ToqueZP TouchSensor{}
DEF RelojZP TimeSensor{cycleInterval 4}
]
}
DEF SCControlYN Transform

{
translation 0 -7 0
children [
Shape {geometry Box{size 1 1 1}}
DEF ToqueYN TouchSensor{}
DEF RelojYN TimeSensor{cycleInterval 4}
]
}
DEF SCControlYP Transform
{
translation 0 -3 0
children [
Shape {geometry Box{size 1 1 1}}
DEF ToqueYP TouchSensor{}
DEF RelojYP TimeSensor{cycleInterval 4}
]
}
]
}
DEF miProg Script
{
url "javascript:
function CambiarVelocidad()
{velocidad=velocidad-2;
if(velocidad==0)velocidad=8;velocidad_cambiada=velocidad;}
function TrasladarEnYN(tiempo)
{traslacion_cambiada[1]=traslacion_cambiada[1]-
paso*tiempo/relojYN.cycleInterval;}
function TrasladarEnYP(tiempo)
{traslacion_cambiada[1]=traslacion_cambiada[1]+paso*tiempo/
relojYP.cycleInterval;}
function TrasladarEnZN(tiempo)
{traslacion_cambiada[2]=traslacion_cambiada[2]-
paso*tiempo/relojZN.cycleInterval;}
function TrasladarEnZP(tiempo)
{traslacion_cambiada[2]=traslacion_cambiada[2]+paso*tiempo/
relojZP.cycleInterval;}
function RotarEnYN(tiempo)
{rotacion_cambiada[0]=0;rotacion_cambiada[1]=1;rotacion_cam
biada[2]=0;
rotacion_cambiada[3]=rotacion_cambiada[3]-
giro*tiempo/relojYNR.cycleInterval;}
function RotarEnYP(tiempo)
{rotacion_cambiada[0]=0;rotacion_cambiada[1]=1;rotacion_cam
biada[2]=0;
rotacion_cambiada[3]=rotacion_cambiada[3]+giro*tiempo/relojY
PR.cycleInterval;}
"
eventIn SFTime CambiarVelocidad
eventIn SFFloat TrasladarEnYN
eventIn SFFloat TrasladarEnYP
eventIn SFFloat TrasladarEnZN
eventIn SFFloat TrasladarEnZP
eventIn SFFloat RotarEnYN
eventIn SFFloat RotarEnYP
field SFNode relojZN USE RelojZN

field SFNode relojZP USE RelojZP
field SFNode relojYN USE RelojYN
field SFNode relojYP USE RelojYP
field SFNode relojYNR USE RelojYNR
field SFNode relojYPR USE RelojYPR
field SFFloat paso 1
field SFTime velocidad 8
field SFColor color 110
field SFFloat giro 0.5235987755983
eventOut SFTime velocidad_cambiada

eventOut SFVec3f traslacion_cambiada
eventOut SFRotation rotacion_cambiada
}
#############CONFIGURAR
VELOCIDAD#####################
ROUTE ToqueV.touchTime TO miProg.CambiarVelocidad
ROUTE miProg.velocidad_cambiada TO RelojYN.cycleInterval
ROUTE miProg.velocidad_cambiada TO RelojYP.cycleInterval
ROUTE miProg.velocidad_cambiada TO RelojZN.cycleInterval
ROUTE miProg.velocidad_cambiada TO RelojZP.cycleInterval
################TRASLADARSE EN
Y######################
ROUTE ToqueYN.isActive TO RelojYN.loop
ROUTE RelojYN.fraction_changed TO miProg.TrasladarEnYN
ROUTE miProg.traslacion_cambiada TO SCT.set_translation
ROUTE ToqueYP.isActive TO RelojYP.loop

ROUTE RelojYP.fraction_changed TO miProg.TrasladarEnYP
################TRASLADARSE EN
Z######################
ROUTE ToqueZN.isActive TO RelojZN.loop
ROUTE RelojZN.fraction_changed TO miProg.TrasladarEnZN
ROUTE ToqueZP.isActive TO RelojZP.loop

ROUTE RelojZP.fraction_changed TO miProg.TrasladarEnZP
###################ROTACION EN
X######################
ROUTE ToqueYNR.isActive TO RelojYNR.loop
ROUTE RelojYNR.fraction_changed TO miProg.RotarEnYN
ROUTE miProg.rotacion_cambiada TO SCR.set_rotation
ROUTE ToqueYPR.isActive TO RelojYPR.loop

ROUTE RelojYPR.fraction_changed TO miProg.RotarEnYP
ROUTE miProg.rotacion_cambiada TO SCR.set_rotation
En el anterior programa se especifica un diseño de como s poderia

ser los controles para un observador. Es preciso tener en ceunta
que existe un proble el cual radica en que el observador nose puede
mover libremente mas que en z y y, la idea es que se implemente el
obervador moviendose en el plano zx libremete manejando
adecuadamente los giros la altura es controlada con el eje y.

VRML

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

VRML

Caricato da

Copyright:

Formati disponibili

VRML

CARACTERISTICAS DEL VRML

campo: es una propiedad, característica, atributo o estado del nodo.

evento: es un mensaje enviado de un nodo a otro, lo cual estimula

DATOS QUE SE PUEDEN DEFINIR EN VRML

field SFColor dato field MFColor dato

field SFFloat dato field MFFloat dato

dato = 1.5666 dato = 1.23 1.34 2.34

dato = 15 dato = -5 4 0x6

field SFRotation dato field MFRotation dato

dato = 1 0 0 3.14 dato = 0 1 1, 0 1 1, 0 1

field SFString dato field MFString dato

field SFTime dato

field SFVect2f dato field MFVect2f dato

dato = 1.3 2 dato = 1 3.1, 2 5.3

dato = 1.3 2 dato = 1 3.1, 2 5.3

El nodo Transorm es un nodo de agrupación que define un sistema

Los campos bboxCenter y bboxSize especifican un cubo que

El campo center especifica un offset de traslación del origen del

Dado un punto P, este es transformado a P’ así:

Donde: C (center), SR (scaleOrientation), T (translation), R

el nodo Cane especifica un cono centrado en sistema coordenado

El nodo Cylinder especifica un cilindro centrado en (0,0,0) en

#VRML V2.0 utf8

El nodo Appearance especifica las propiedades visuales de las

El campo texture si es especificado puede contener cualquiera de

El campo textureTransform, si es especificado contendrá un nodo

El nodo Material especifica las propiedades del material de las

El campo ambientIntensity especifica cuantas luces ambiente de

El campo diffuseColor refleja todas las fuentes de luz VRML

El campo emissiveColor modela el relucimiento de un objeto. Este

Los campos specularColor y shininess determinan la iluminación

El campo transparency especifica como un objeto se vuelve

El nodo ImageTecture define un mapa de textura por especificación

Los campos repeatS y repeatT especifican como es el cubrimiento

#VRML V2.0 utf8

#VRML V2.0 utf8

Los mapas de textura son definidos en sistema coordenado 2D (s,t)

Tan pronto la película es cargada, un evento de salida

Los campos expuestos loop, startTime y stopTime sirven para

El campo expuesto speed cuan rápido al película es desplegada.

t = (now - startTime) modulo (duration/speed)

Cuando un nodo MovieTexture se vuelve inactivo, el frame

El nodo PixelTexture define un mapa de textura bidimensional como

Los campos repeatS y repeatT especifican como es el cubrimiento

#VRML V2.0 utf8

El nodo TextureTransform define una transformación bidimensional

Estos parámetros soportan cambios de tamaño, orientación y

La matriz trasnformacion ser: Tc' = -C × S × R × C × T × Tc

El nodo Fog provee la forma de simular efectos atmosféricos por la

Un rango de visibilidad de 0.0 desabilita el nodo Fog el rango de

Comportamiento del Stack Para nodos atables

El campo fogType controla la manera en la que el color es mezclado

El nodo DirectionalLight define una funet de luz direccional que

El campo intesity especifica el resplandor derl aemision directa de

El campo direction especifica el vector direccion de emision de luz

Los nodo DirectionalLight no se atenuan con la distancia

#VRML V2.0 utf8

El campo intesity especifica el resplandor de la emisión directa de la

Un nodo PointLight ilumina las geometrías dentro del radio de su

La atenuación se expresa como: 1/max(attenuation[0]+

donde r es la distancia de la fuente luminosa a la superficie de

El nodo SpotLight define una furnte de luz que emite luz de un

El campo location especifica un offset traslacion del punto central