Asuntos Técnicos

OK. Vamos a empezar a entrar ahora en el interior del VRML. Hemos cubierto hasta ahora los elementos escenciales, y continuaremos. Ahora, necesitamos empezar a ponernos serios sobre todo esto. Este capítulo va a entrar en detalles de tipos de campos y eventos que un nodo puede tener, y explica sobre el Prototyping (uso de protos o prototipos) que es útil para reusar el código. También cubriremos los "routes" que son la base para toda animación en VRML. Realmente no vamos a aplicar este material hasta después, pero es útil comenzar a conocerlo.

Fields & Types

Entonces vale. Como probablemente sabrás ya de los tutoriales anteriores, los archivos VRML consisten en grupos de nodos. Estos nodos también pueden contener otros nodos, y también puede contener campos. Cada campo tiene un tipo que gobierna qué datos puede contener, y cuántos de él. Hay varios tipos diferentes en VRML que se describen debajo. Será mejor que te acostumbres a éstos, porque voy a usarlos para describir los nodos de ahora en adelante.

SFBool
Este es un valor booleano simple que puede tomar el valor "TRUE" o "FALSE".
SFColor & MFColor
Este campo contiene un color simple conformado por tres números de punto flotante entre 0 y 1 que corresponden a los valores rojos, verdes y azules de ese color, por ejemplo 0 1 0 es verde. MFColor es un campo que contiene colores múltiples, por ejemplo [0 1 0, 1 0 0, 0 0 1].
SFFloat & MFFloat
SFFloat es un valor simple de punto flotante, por ejemplo 7.5. MFFloat son varios valores de punto flotante, por ejemplo [1.0, 3.4, 76.54].
SFImage
SFImage es una imagen bidimensional, ya sea en color o gris. Consiste de: Los pixeles se especifican de izquierda a derecha y de abajo hacia arriba.
SFInt32 & MFInt32
Uno solo o una lista de números enteros de 32 bits. Éstos pueden estar en formato decimal o hexadecimal. Los números en hexadecimal comienzan con el 0x, por ejemplo el 0xFF es 255 en decimal.
SFNode & MFNode
SFNode es un solo nodo, y MFNode es una lista de nodos. Nota que los campos children en muchos nodos es del tipo MFNode.
SFRotation & MFRotation
Estos campos especifican una rotación sobre un eje. Esto es realizado por cuatro números del punto flotante. Los primeros tres especifican las coordenadas X Y Z para el vector correspondiente al eje sobre el cual rotar, y el cuarto es el número (ángulo) en radiánes para rotar. Para más explicación ir a la sección de rotación del capítulo 1.3. SFRotation es un solo set de valores, MFRotation es una lista.
SFString & MFString
Este tipo contiene una lista de caracteres en el set de caracteres utf-8. ASCII es un subconjunto de utf-8, de modo que  no necesitas preocuparte sobre carácteres diferentes o algo así. Un string (SFString) se especifica como "Hola", entre comillas. Una lista (MFString) se parecería a: ["Hola", "Mundo"].
SFTime & MFTime
Uno solo o una lista de valores de tiempo. Estos se especifican como números de punto flotante que representan el número de segundos transcurridos desde que pasó la medianoche del 1 de enero1970. Esto tendrá más sentido cuando  cubramos los eventos.
SFVec2f & MFVec2f
Uno solo o una lista de vectores 2D. Un vector 2D es un par de números de punto flotante.
SFVec3f & MFVec3f
Uno solo o una lista de vectores 3D. Un vector 3D es un triple de números de punto flotante.

Ahora que conoces todos los tipos de valores que acepta campo y cómo especificarlos, podemos seguir avanzando para cubrir los eventos. Estamos ahora en la fase donde necesitas algún tipo de referencia de nodos detallada. Tengo idea de hacer uno, pero no en este momento. Si usas Windows, consigue soporte del VRML Helpfile del Dr. Clue. Si no, puedes usar las especificaciones de VRML. Los dos se encuentran en la sección de Vinculos. También, verifica el VRML Repository para información.

Events

Mu bien, eventos. Así como los campos, la mayoría de los nodos contienen eventos. Hay dos tipos de eventos, eventIn y eventOut. Los eventOuts son eventos emergentes (salientes) que generan información como el cambiar un valor o el tiempo de un clic del ratón. Los eventIns son eventos entrantes que aceptan información de fuera del nodo y hacen algo con él. Cada evento tiene un tipo de dato asociado a él, tal como fue descrito anteriormente.

Algunos nodos tienen campos que son exposed (expuestos). Esto significa que el nodo tiene dos eventos definidos para ese campo, set_nombredecampo y nombredecampo_changed. Éstos son un eventIn y eventOut para el campo que puede usarse para cambiar su valor y notificar al mundo externo cuando ha cambiado. Si tu usas set_nombredecampo para cambiar el valor del campo del evento, el nodo generará un nombredecampo_changed. Para una facilidad de uso, el set_ y _changed de los eventos puede omitirse, y el navegador trabajará con el evento que está usándose. Si un campo no es expuesto, no puede intercambiar eventos, y el valor en el archivo sera el usado en todo momento. Para ver qué campos son los expuestos en cada nodo, ayudate con una guía de referencia de uno de los lugares en la pagina de los vinculos , o echa una mirada a la referencia de nodos en el apendice de este tutorial.

Routes

Para hacer cosas útiles con los eventos, nosotros necesitamos unirlos de algún modo. Esta unión es conocida como ROUTE. Por ejemplo, para dirigir un touchTime eventOut a un startTime eventIn (por ejemplo para reproducir un sonido con un clic del ratón), nosotros dirigiríamos el evento como sigue: 

ROUTE SENSOR.touchTime TO SOUND.startTime

Route

Así que éste trozo de código dirigirá el evento del touchTime de un TouchSensor (que cubriremos luego) a un evento  startTime en un nodo de sonido (que también cubriremos luego). Por consiguiente, cuando el TouchSensor es pulsado con el raton, el sonido se activará. Necesitas usar DEF para cada nodo que precises dirigir hacia o desde, para que tengan nombres individuales. De esta manera el TouchSensor y el nodo del sonido se deberían definir con un nombre. 

DEF SENSOR TouchSensor {
}


DEF SOUND Sound {
}

Excepto por el hecho de que deberían contener campos, obviamente. Si tienes varios objetos con el mismo nombre (usando el USE), y ruteas hacia o desde ellos, todos los objetos seran afectados. Si quieres solo afectar a uno, le das un único nombre o usas un PROTO, como explico debajo.

PROTO

Solo una cosa más para cubrir, y ése es el prototyping. Realmente no se relaciona con los eventos y rutas, pero ahora que he cubierto los campos, es más fácil de explicar.

Prototyping (empleo de prototipos) es una manera de reusar tu codigo. Si deseas un número de objetos del mismo tipo exacto,  puedes usar DEF y USE. ¿Que pasa, sin embargo, si quieres varios objetos que son muy similares, pero con pequeñas diferencias, por ejemplo alturas diferentes? En ese caso, puedes usar PROTO. Para definir un prototipo, defines tu objeto, y defines campos y eventos para él. Aquí va un ejemplo de un PROTO para una caja con color variable. 

PROTO VBox [
   field SFColor boxColour 1 0 0
]
{
   Shape {
      appearance Appearance {
         material Material {
            diffuseColor IS boxColour
         }
      }
      geometry Box {
      }
   }
}

El campo entre corchetes al comienzo de la declaración es la interface para el objeto, y los números son los valores predefinidos por el campo. Cuando el VBox se declara, el valor asignado al campo del boxColour se pone en el campo diffuseColor del nodo Material. Por consiguiente, para declarar un VBox rojo y un VBox verde, podemos usar el nuevo nodo de VBox en cualquier parte donde tengamos previamente definido un nodo Shape como VBox. 

VBox { }


VBox {
   boxColour 0 1 0
}

El primer uso define un VBox rojo predefinido, el segundo da uno verde. Tu puedes definir eventIns, eventOuts y exposedFields para los prototipos de la misma manera, usando IS para trazar el campo del  PROTO  que desees cambiar al implementarlo en el mundo. Un campo PROTO tiene que ser trazado con el mismo tipo que field/event ( no puedes trazar un eventIn a un eventOut), y también tienen que ser datos del mismo tipo (no puedes rutear un SFTime a un SFFloat). La única excepción a esto es que puedes trazar un campo normal en la definición de PROTO a un exposedField en la implementación, como un campo normal , un subconjunto de un exposedField. Así, trazandolos juntos los dos no se producen estragos. De todos modos, no lo puedes hacer de otra manera...

EXTERNPROTO

Si quieres definir PROTOs en alguna otra parte que no sea tu archivo principal, puedes usar EXTERNPROTO. Este dice al navegador que la mayor parte de la definición del objeto se encuentra en otro archivo. En tu archivo prinicpal, incluye la definición del EXTERNPROTO, y tienes el PROTO completo en otro archivo. La sintaxis de EXTERNPROTO se muestra debajo: 

EXTERNPROTO VBox [
   field SFColor boxColour
]
"proto.wrl"

El archivo, "proto.wrl" en este caso, debe contener la cabecera VRML y las definiciones del prototipo, nada más. Si tienes más de un PROTO en el archivo, debe ras declarar cual estas usando, como esto: 

"proto.wrl#VBox"

Piensa que no necesitas incluir los valores predefinidos en la definición de EXTERNPROTO, sólo los tipos del campo. En lugar de un solo archivo, si quieres incluir mutiples opciones para la carga del archivo, puedes ponerlos entre corchetes: 

EXTERNPROTO VBox [
   field SFColor boxColour
]
[
   "proto.wrl"
   "http://www.mydomain.com/protos/proto.wrl"
]

Terminus

Puedes echar una mirada ahora al mundo si quieres. Yo he reemplazado las cuatro definiciones del cono con un PROTO, para que todos luzcan iguales, Esto hace al archivo más eficaz y ligeramente más pequeño.
Tutorial Mundo 1.7 + el código.

Eso es todo entonces. Usaremos todo este material de aquí en adelante, mezclándolo con animación, scripting y cosas por el estilo. Antes de eso, en los próximos dos capítulos yo voy a cubrir iluminación, cámaras, sonido, y otros efectos elegantes para hacer tus mundos más realistas y útiles.