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 [comentarios opcionales] 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 usuario

Archivo VRML VISUALIZADOR VRML PARSER prototipos

Constructor de nodos

ESCENA GRAFICA Jerarquización en transformaciones

Ruta gráfica Máquina de ejecución

* sensores * escript * 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 exposedFiel SFColor dato eventIn SFColor dato dato eventOut SFColor dato

field MFColor dato exposedFiel MFColor 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 exposedFiel SFFloat dato eventIn SFFloat dato eventOut SFFloat dato

field MFFloat dato exposedFiel MFFloat dato eventIn MFFloat 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 exposedFiel SFInt dato eventIn SFInt dato eventOut SFInt dato

field MFInt dato exposedFiel MFInt dato eventIn MFInt 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 exposedFiel SFRotation dato

field MFRotation dato exposedFiel MFRotation dato

eventIn SFRotation dato eventOut SFRotation dato

eventIn MFRotation dato eventOut MFRotation 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 exposedFiel SFString dato

field MFString dato exposedFiel MFString dato

eventIn SFString dato eventOut SFString dato

eventIn MFString 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 exposedFiel SFVect2f dato

field MFVect2f dato exposedFiel MFVect2f dato

eventIn SFVect2f dato eventOut SFVect2f dato

eventIn MFVect2f 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 exposedFiel SFVect3f dato

field MFVect3f dato exposedFiel MFVect3f dato

eventIn SFVect3f dato eventOut SFVect3f dato

eventIn MFVect3f dato eventOut MFVect3f dato

dato = 1.3 2

dato = 1 3.1, 2 5.3

Transform Transform { eventIn eventIn exposedField exposedField exposedField ∞,∞) exposedField exposedField ∞) exposedField field field ∞) or -1,-1,-1 }

MFNode addChildren MFNode removeChildren SFVec3f center 0 0 0 # (-∞,∞) MFNode children [] SFRotation rotation 0 0 1 0 # [-1,1],(SFVec3f scale 1 1 1 # (0, ∞) SFRotation scaleOrientation 0 0 1 0 # [-1,1],(- ∞, SFVec3f translation SFVec3f bboxCenter SFVec3f bboxSize

000 000

# (-∞,∞) # (-∞,∞) -1 -1 -1 # (0,

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 (rotation), y S (scale).

(scaleOrientation),

T

(translation),

R

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 field field field }

SFFloat SFFloat SFBool SFBool

bottomRadius 1 # (0, ∞) height 2 # (0, ∞) side TRUE 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 field field field field

SFBool SFFloat SFFloat SFBool SFBool

bottom TRUE height 2 # (0 ∞) radius 1 # (0, ∞) side TRUE 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 exposedField exposedField exposedField exposedField exposedField }

SFFloat ambientIntensity SFColor diffuseColor SFColor emissiveColor SFFloat shininess SFColor specularColor SFFloat transparency

0.2 # [0,1] 0.8 0.8 0.8 # [0,1] 000 # [0,1] 0.2 # [0,1] 000 # [0,1] 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 { appearance Appearance { 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 { appearance Appearance { material Material { ambientIntensity 0.7 diffuseColor 100 emissiveColor 100 shininess 0.7 specularColor 100 transparency 0.5

} texture ImageTexture { 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 # (-∞, ∞) exposedField MFString url [] field SFBool repeatS TRUE field SFBool repeatT TRUE 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 { appearance Appearance { texture MovieTexture{url "nombre.mpg"} } geometry Box{} } }

PixelTexture PixelTexture { exposedField SFImage image 000 field SFBool repeatS TRUE field SFBool repeatT TRUE } 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 { appearance Appearance { material Material{diffuseColor 1 0 0} texture PixelTexture{image 2 2 2 0xff0000} } geometry Box{} } }

TextureTransform TextureTransform { exposedField SFVec2f center exposedField SFFloat rotation exposedField SFVec2f scale

00 0 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 { appearance Appearance { 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 exposedField SFString fogType "LINEAR" exposedField SFFloat visibilityRange 0 eventIn SFBool set_bind eventOut SFBool isBound }

# [0,1] # [0,∞)

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

#

exposedField SFColor

color

#

[0,1] [0,1]

111

exposedField SFVec3f direction ∞,∞)

exposedField SFFloat

intensity

0 0 -1 # (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 { ambientIntensity 0.5 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 SFBool on TRUE 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]+ 2 attenuation[1]×r + attenuation[2]×r ,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 #experimentando con PointLight PointLight { ambientIntensity 0.5 attenuation 121 color 1 0.0 0.0 location 0 10 0 radius 50 } Transform { children Shape {geometry Box {}} } SpotLight SpotLight { exposedField SFFloat ambientIntensity exposedField SFVec3f attenuation exposedField SFFloat beamWidth /2] exposedField SFColor color exposedField SFFloat cutOffAngle /2] exposedField SFVec3f direction ∞) exposedField SFFloat intensity exposedField SFVec3f location ∞) exposedField SFBool on exposedField SFFloat radius ∞) }

0 # [0,1] 100 # [0,∞) 1.570796 # (0,π 111 # [0,1] 0.785398 # (0, π 0 0 -1 1 000 TRUE 100

# (- ∞, # [0,1] # (-∞,

# [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 { eventIn SFBool set_bind exposedField MFFloat groundAngle [] exposedfield MFColor groundColor [] exposedField MFString backUrl [] exposedField MFString bottomUrl [] exposedField MFString frontUrl [] exposedField MFString leftUrl [] exposedField MFString rightUrl [] exposedField MFString topUrl []

# [0, ∞/2] # [0,1]

exposedField MFFloat skyAngle [] # [0, ∞] exposedField MFColor skyColor [000] # [0,1] eventOut SFBool isBound } 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 color NULL exposedField SFNode normal NULL exposedField SFNode texCoord NULL field MFFloat height [] field SFBool ccw TRUE field SFBool colorPerVertex TRUE field SFFloat creaseAngle 0 field SFBool normalPerVertex TRUE field SFBool solid TRUE field SFInt32 xDimension 0 field SFFloat xSpacing 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 { exposedField SFNode color exposedField SFNode coord }

NULL NULL

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 texture ImageTexture {url "Texture/Fire_4.gif"} } geometry ElevationGrid

{ color NULL normal NULL texCoord NULL ccw TRUE colorPerVertex creaseAngle normalPerVertex solid xDimension 20 xSpacing 1 zDimension 10 zSpacing 2.1

FALSE 3.1416 TRUE FALSE

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 exposedField SFNode color NULL exposedField SFNode coord NULL field MFInt32 colorIndex [] ∞) field SFBool colorPerVertex TRUE field MFInt32 coordIndex [] ∞) }

# [-1, # [-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] colorPerVertex FALSE colorIndex [0,0,0,0] } } }

Sound { exposedField SFVec3f direction exposedField SFFloat intensity exposedField SFVec3f location exposedField SFFloat maxBack exposedField SFFloat maxFront exposedField SFFloat minBack exposedField SFFloat minFront exposedField SFFloat priority exposedField SFNode source field SFBool spatialize

001 1 # [0,1] 000 10 10 1 1 0 # [0,1] NULL 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-delobservador, 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 SFBool loop FALSE exposedField SFFloat pitch 1.0 exposedField SFTime startTime 0 exposedField SFTime stopTime 0 exposedField MFString url [] eventOut SFTime duration_changed eventOut SFBool isActive } 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 exposedField exposedField exposedField }

MFString string [] SFNode fontStyle NULL MFFloat length [] SFFloat maxExtent 0.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 field field field field field field field

MFString family SFBool horizontal MFString justify SFString language SFBool leftToRight SFFloat size SFFloat spacing SFString style

["SERIF"] TRUE "BEGIN" "" TRUE 1.0 # (0,∞) 1.0 # [0, ∞) "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 [] exposedField MFString url [] 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 keyValue [...] eventOut [S|M]F 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 { eventIn exposedField exposedField eventOut }

SFFloat set_fraction MFFloat key [] MFColor keyValue [] 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 { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFRotation keyValue [] eventOut SFRotation value_changed } el nodo OrientationInterpolator interpola valores de rotación sin que estos sean acumulativos. El campo key contiene las porcentajes de interpolación del campo 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. 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. PositionInterpolator { eventIn exposedField exposedField eventOut

SFFloat set_fraction MFFloat key [] MFVec3f keyValue [] SFVec3f value_changed

} el nodo PositionInterpolator interpola valores de traslación sin que estos sean acumulativos. El campo key contiene las porcentajes de interpolación del campo 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. 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. ScalarInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] exposedField MFFloat keyValue eventOut SFFloat value_changed }

[]

el nodo ScalarInterpolator interpola valores como radios, intensidad, brillo etc. sin que estos sean acumulativos. El campo key contiene las porcentajes de interpolación del campo keyValue que contiene las valores de interpolación. Hay que tener en cuenta que deben existir tantos porcentajes de interpolación como valores. 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. CoordinateInterpolator { eventIn SFFloat set_fraction exposedField MFFloat key [] 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 SFBool loop FALSE exposedField SFTime startTime 0 exposedField SFTime stopTime 0 eventOut SFTime cycleTime eventOut SFFloat fraction_changed eventOut SFBool isActive 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 { exposedField SFBool enabled TRUE eventOut SFVec3f hitNormal_changed eventOut SFVec3f hitPoint_changed eventOut SFVec2f hitTexCoord_changed eventOut SFBool isActive eventOut SFBool isOver eventOut SFTime touchTime } 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 {

exposedField MFString url [] 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 { eventIn SFBool exposedField SFFloat π)

set_bind 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 eventOut SFBool isBound }

# # (-

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 tan(FOVvertical/2)

pantalla

=

tan(FOVhorizontal/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 ROUTE Programa.nodo_cambiadoS TO SistemaCamaraLuna.removeChildren

ROUTE Programa.nodo_cambiadoS TO SistemaCamaraSol.addChildren ############### ROUTE TocarTierra.isActive TO Programa.cambiarTierra ROUTE Programa.nodo_cambiadoT TO SistemaCamaraSol.removeChildren ROUTE Programa.nodo_cambiadoT TO SistemaCamaraLuna.removeChildren ROUTE Programa.nodo_cambiadoT TO SistemaCamaraTierra.addChildren ############### ROUTE TocarLuna.isActive TO Programa.cambiarLuna ROUTE Programa.nodo_cambiadoL TO SistemaCamaraSol.removeChildren ROUTE Programa.nodo_cambiadoL TO SistemaCamaraTierra.removeChildren ROUTE Programa.nodo_cambiadoL TO 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 SFBool enabled exposedField SFVec2f maxPosition

TRUE -1 -1

# (-∞,

exposedField SFVec2f minPosition

00

# (-∞,

exposedField SFVec3f offset

0 0 0 # (-∞,

∞) ∞) ∞) eventOut eventOut eventOut }

SFBool isActive SFVec3f trackPoint_changed 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

DEF SistemaMundial Transform {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 DEF SistemaMundial Transform { 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 exposedField SFBool exposedField SFRotation eventOut SFBool eventOut SFRotation eventOut SFVec3f }

autoOffset TRUE enabled TRUE offset 0100 isActive rotation_changed 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 DEF SistemaMundial Transform { 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 DEF SistemaMundial Transform {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 field field field field field field field field field

SFNode SFNode SFNode SFNode SFNode SFNode SFFloat SFTime SFColor SFFloat

relojZN USE RelojZN relojZP USE RelojZP relojYN USE RelojYN relojYP USE RelojYP relojYNR USE RelojYNR relojYPR USE RelojYPR paso 1 velocidad 8 color 110 giro 0.5235987755983

eventOut SFTime eventOut SFVec3f

velocidad_cambiada 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 ROUTE miProg.traslacion_cambiada TO SCT.set_translation ################TRASLADARSE EN Z###################### ROUTE ToqueZN.isActive TO RelojZN.loop ROUTE RelojZN.fraction_changed TO miProg.TrasladarEnZN ROUTE miProg.traslacion_cambiada TO SCT.set_translation ROUTE ToqueZP.isActive TO RelojZP.loop ROUTE RelojZP.fraction_changed TO miProg.TrasladarEnZP ROUTE miProg.traslacion_cambiada TO SCT.set_translation ###################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.