Embed Size (px)
Citation preview
Capítulo 5
La escena 3D
5.1. Aspectos generales
5.1.1. Virtual Reality Toolbox
Virtual Reality Toolbox es un paquete de herramientas de MATLAB que permite visualizar
simulaciones de sistemas dinámicos en una escena 3D de realidad virtual creada en el lenguaje
estándar VRML971. Mediante una sencilla interfaz de funciones orientadas a objetos y bloques,
este toolbox enlaza, respectivamente, MATLAB y Simulink con las grá�cas de realidad virtual.
Utilizando señales de Simulink es posible controlar parámetros como la posición, orientación y
dimensión de los objetos de�nidos en el entorno 3D, generando así una animación de la simulación.
El toolbox incluye:
Orbisnap, una herramienta de visualización de escenas VRML. En la instalación de VRT se
instala automáticamente y se usa por defecto.
Blaxxun Contact, un plug-in opcional para Internet Explorer que permite visualizar escenas
VRML como una página web. En la instalación de VRT se copia el instalador a la carpeta
de archivos de MATLAB pero no se instala.
V-Realm Builder, una herramienta de edición VRML que proporciona una interfaz grá�ca
de usuario sencilla e intuitiva para crear y editar la escena 3D. En la instalación de VRT se
copia el instalador a la carpeta de archivos de MATLAB pero no se instala.
5.1.1.1. Instalación de V-Realm Builder
Para poder usar el editor hay que hacer lo siguiente:
1. Iniciar MATLAB
1VRML = Virtual Reality Modeling Language.
68
5.1. Aspectos generales 69
Figura 5.1: Librería Simulink de Virtual Reality Toolbox
2. En la ventana de comandos escribir: vrinstall -install editor y pulsar intro.
Aparece el mensaje:
Starting editor installation...
Done.
3. Para comprobar la instalación escribir: vrinstall -check y pulsar intro.
Si la instalación es correcta debe aparecer el mensaje:
VRML viewer: installed2 ó unsupported (Unknown)
VRML editor: installed
5.1.1.2. Interfaz de VRT para Simulink
El comando vrlib desde la ventana de comandos de MATLAB abre la librería Simulink de VRT
que se observa en la Figura 5.1
Bloque VR Sink Este es el bloque que sirve como interfaz entre las señales de un modelo y
la escena virtual. Al pulsar dos veces con el ratón sobre este bloque incluido en un modelo de
Simulink se abre la ventana de con�guración que se muestra en la Figura 5.2
Los parámetros más importantes son:
Botón Browse: sirve para buscar y seleccionar un archivo .wrl que contenga la escena 3D.
2si está instalado Blaxxun Contact.
5.1. Aspectos generales 70
Figura 5.2: Con�guración VR Sink
Botón View : abre una ventana del visor con la escena seleccionada.
Botón New / Edit : abre el editor VRML para crear una escena 3D nueva o editar la escena
seleccionada (requiere que V-Real Builder esté instalado. Ver 5.1.1.1).
Botón Reload : sirve para recargar la escena seleccionada en caso de haberla editado.
Casilla Open VRML Viewer automatically : cuando está seleccionada, se abre la ventana del
visor automáticamente cuando se abre el modelo.
Sample time: el tiempo de muestreo. Es el intervalo de tiempo entre cada actualización de valo-
res.
VRML Tree: en este cuadro aparece un árbol con todos los nodos de la escena 3D seleccionada.
Según el tiempo de muestreo, el bloque escribe valores de Simulink en los campos de los
nodos de la escena virtual que estén marcados según las casillas que aparecen en esta vista
de árbol. Cada campo que se marque corresponde a un puerto de entrada del bloque.
Una vez seleccionada una escena 3D, al pulsar OK, el bloque añadirá un puerto de entrada por cada
casilla que se haya marcado en la vista de árbol de la ventana de con�guración. Si se vuelve a pulsar
dos veces sobre el bloque se abrirá una ventana del visor en vez de la ventana de con�guración.
Para volver a acceder a la ventana de con�guración hay que entrar en el menú Simulation de la
ventana del visor y pulsar sobre Block Parameters.
Bloque Joystick Input Este bloque proporciona una interfaz entre Simulink y cualquier joystick
reconocido por Windows, de forma que se puede usar los valores que proporcionan los ejes y botones
como señales de entrada a un modelo.
5.1. Aspectos generales 71
Bloque VR Placeholder Este bloque genera una señal del tamaño especi�cado en el parámetro
Output width cuyos elementos son mantenedores del valor actual del campo al cual se conecte.
Bloque VR Signal Expander Este bloque recibe como entrada una señal y genera como salida
otra de tamaño igual o mayor, especi�cado en el parámetro Output width. El parámetro Output
signal indices es un vector del tamaño de la señal de entrada, cuyos componentes indican la posición
en la señal de salida de cada elemento de entrada. Si la señal de salida es mayor que la de entrada,
las posiciones restantes se rellenan con mantenedores. Por ejemplo, si Output width es 3 y Output
signal indices es [3 1], la señal de entrada tiene dos componentes, el primer elemento de entrada
pasará a ser el tercero de salida, el segundo elemento de entrada pasará a ser el primero de salida
y el segundo de salida será un mantenedor.
5.1.2. Introducción a VRML
5.1.2.1. Formato de archivos
En VRML97 las escenas que se construyen se conocen comúnmente como worlds (mundos) y
por esta razón tienen la extensión .wrl
Todos los archivos de VRML97 son archivos de texto (ASCII) y por lo tanto pueden ser editados
con cualquier editor de textos. Sin embargo, existen editores, como V-Realm Builder, que inter-
pretan el código, permitiendo ver la escena al tiempo que se añaden objetos nuevos y se modi�can
los existentes. Para una identi�cación sencilla de los archivos de VRML97, todos deben incluir la
cabecera siguiente: #VRML V2.0 utf8
La primera parte (#VRML V2.0 ) denota el tipo y la versión. La segunda (utf8 ) permite
utilizar la codi�cación UTF-8 para trabajar con todos los caracteres especiales (acentos, caracteres
japoneses, cirílico, etc.) según el estándar ISO 10646. Para poner un comentario en un archivo
VRML97, se debe anteponer el carácter #. Este carácter se puede situar en cualquier sitio del
código y provoca que el resto de la línea sea ignorado.
Todas las especi�caciones de VRML97 se encuentran de�nidas en el estándar ISO/IEC 14772-
1:1997 e ISO/IEC 14772-2:2004. Ver [10]
5.1.2.2. Nodos y Campos
En un mundo de VRML97 lo que se de�ne es simplemente un grupo de objetos3. Estos objetos
pueden contener geometría 3D, imágenes, colores, etc. y en VRML97 reciben el nombre de nodes
(nodos).
Estos nodos tienen algunas características variables que se pueden de�nir en cada caso mediante
�elds (campos), los cuales funcionan a modo de parámetros. Por ejemplo, el nodo:
3en el sentido de orientación a objeto.
5.1. Aspectos generales 72
Figura 5.3: Ejes en VRML
Box {
size 1 1 1}
de�ne un cubo genérico de lado 1 mediante el campo size.
Los campos son univaluados cuando sólo se necesita un valor o bien multivaluados cuando se
requiere una lista de valores.
Los campos tienen un tipo de datos asociado, es decir, cada campo sólo puede tener datos de
un cierto tipo concreto de datos. Por ejemplo, el campo size es de tipo vector 3D en coma �otante
y por tanto se dice que es de tipo SFVec3f (Single-valued Field Vector 3D �oating point)4. Se
puede ver la lista completa de todos los tipos de datos en el capítulo 5 de [10].
Existen nodos especiales que pueden agrupar a otros nodos si estos últimos se de�nen en su
campo children. Un nodo agrupador sirve para que varios objetos tengan las mismas propiedades
como transformaciones geométricas, comportamiento, etc.
El lenguaje VRML97 es sensible al cambio de mayúsculas a minúsculas y por eso se debe ir con
cuidado al escribir el código y al de�nir los nombres de los objetos y campos.
5.1.2.3. Ejes y unidades
En VRML97 el eje X positivo apunta a la derecha, el eje Y positivo apunta hacia arriba y el
eje Z positivo apunta hacia fuera de la pantalla, tal y como muestra la Figura 5.3.
El sistema de ejes en VRML97 funciona mediante un sistema "local� para cada objeto que
se de�ne, y un sistema "global" para poner en correspondencia a todos los objetos de un mismo
entorno. Por lo tanto, si se de�ne un objeto y no se le aplican transformaciones, su sistema de ejes
"local" coincidirá con el sistema de ejes de mundo.
Por convenio, las distancias lineales están en metros, los ángulos en radianes, el tiempo en
segundos y los colores en RGB.
4Es importante no caer en el error de pensar que es un campo multivaluado, ya que no es una lista de tres valoresen coma �otante, si no que es un sólo vector de tres dimensiones.
5.1. Aspectos generales 73
5.1.2.4. Primitivas y materiales
En VRML97 existe una serie de objetos prede�nidos que forman el conjunto de primitivas de
geometría. Estas primitivas son:
Box (paralelepípedos genéricos: cubos, cajas)
Sphere (esfera)
Cone (cono)
Cylinder (cilindro)
Para poder visualizar estas primitivas, es necesario utilizar el nodo Shape. Este nodo tiene dos
campos: geometry y appearance.
El campo geometry es donde se especi�ca la geometría de algún objeto 3D. El campo appearance
es donde se de�ne el color o la textura del objeto. A continuación se muestra como de�nir cada
una de las primitivas existentes:
Box:
Shape {
appearance Appearance {
material Material {
diffuseColor 1 0 0}
}
geometry Box {
size 4 3 5
}}
Aquí se de�ne una caja de cuatro metros de ancho, tres metros de alto y cinco metros de fondo. El
objeto queda de�nido de forma que su centro coincide con el origen de coordenadas locales, y que
en este caso, como no se aplican transformaciones, coincide también con el origen de coordenadas
globales. Se observa que el campo appearance se de�ne con otro nodo llamado Appearance que
contiene un campo llamado material. Este campo, a su vez, se de�ne con otro nodo llamado
Material que contiene los campos donde se de�nen los colores del objeto. El campo di�useColor
corresponde al color que re�eja el objeto y en este caso es rojo, según la de�nición de RGB.
Sphere:
Shape {
geometry Sphere {
radius 5
}}
5.1. Aspectos generales 74
Aquí se de�ne una esfera de cinco metros de radio. También queda centrada en el origen de
coordenadas.
Cone:
Shape {
geometry Cone {
bottomRadius 3
height 2
}}
Aquí se de�ne un cono con una base de tres metros de radio y dos metros de altura . También
queda centrado en el origen de coordenadas.
Cylinder:
Shape {
geometry Cylinder {
height 5
radius 4
}}
Aquí se de�ne un cilindro con una base de cuatro metros de radio y cinco metros de altura. También
queda centrado en el origen de coordenadas.
5.1.2.5. Objetos y Líneas
VRML97 cuenta con estructuras para dibujar geometrías arbitrarias. Estas estructuras per-
miten de�nir la geometría de un objeto 3D a partir de sus vértices y caras. Se usa el nodo Indexed-
FaceSet de�nido en el campo geometry de un nodo Shape.
Por ejemplo, un cubo unitario se puede de�nir a partir de ocho vértices y seis caras de la
siguiente forma:
Shape {
geometry IndexedFaceSet {
coord Coordinate {
point [0.5 0.5 0.5,
0.5 0.5 -0.5,
-0.5 0.5 -0.5,
-0.5 0.5 0.5,
0.5 -0.5 0.5,
0.5 -0.5 -0.5,
-0.5 -0.5 -0.5,
-0.5 -0.5 0.5 ]
}
coordIndex [0, 1, 2, 3, -1,
0, 4, 5, 1, -1,
5.1. Aspectos generales 75
1, 5, 6, 2, -1,
2, 6, 7, 3, -1,
3, 7, 4, 0, -1,
4, 7, 6, 5, -1 ]
}}
Se observa que en primer lugar se de�nen los vértices en el campo coord, usando el campo point de
un nodo Coordinate para listar los puntos 3D que forman los vértices del objeto. Una vez listados
los vértices, ya sólo queda de�nir los polígonos que forman las caras. Esto se hace mediante el
campo coordIndex, donde se listan las caras como una sucesión de índices correspondientes a los
elementos del campo point. Para identi�car cada una de las caras, la lista de vértices de una cara
se separa de la siguiente mediante un −15.
El orden en que se dan los vértices de una cara es muy importante ya que si no se respetan unas
ciertas normas, los polígonos de las caras no se dibujan correctamente. Las normas para listar los
vértices de cada cara son:
Los vértices deben ser consecutivos siguiendo el perímetro de la cara.
Los vértices deben listarse en orden antihorario mirando la cara desde el exterior del objeto.
Se da por entendido que el último vértice de cada cara enlaza con el primero de forma que
se obtenga un circuito cerrado.
Evidentemente, no tiene mucho sentido de�nir un cubo cuando ya se dispone de una primitiva que
lo hace directamente, pero con este sistema se puede modelar cualquier objeto formado por caras
planas.
El color también se puede dar al objeto polígono a polígono mediante los campos color y
colorPerVertex. A continuación se muestra un ejemplo:
Shape {
geometry IndexedFaceSet {
coord Coordinate {
point [0.5 0.5 0.5,
0.5 0.5 -0.5,
-0.5 0.5 -0.5,
-0.5 0.5 0.5,
0.5 -0.5 0.5,
0.5 -0.5 -0.5,
-0.5 -0.5 -0.5,
-0.5 -0.5 0.5 ]
}
coordIndex [0, 1, 2, 3, -1,
0, 4, 5, 1, -1,
1, 5, 6, 2, -1,
2, 6, 7, 3, -1,
5El número mínimo de vértices por cara es lógicamente tres.
5.1. Aspectos generales 76
3, 7, 4, 0, -1,
4, 7, 6, 5, -1 ]
colorPerVertex FALSE
color Color {
color [1 0 0,
0 1 0,
0 0 1,
1 0 1,
1 1 0,
0 1 1 ]
}
}}
El campo colorPerVertex dice si los colores se asignan a los vértices o a las caras del objeto. El
valor FALSE signi�ca que la asignación se realiza por caras.
A continuación el campo color contiene la lista de colores RGB que se asignan a las caras a
través del nodo Color y su campo color. Se deben listar los colores en el orden correspondiente en
que están listadas las caras en coordIndex. Sin embargo, si se quiere, por ejemplo, que la mitad de
las caras sean de un color y la otra mitad de otro, no es necesario repetir el color para cada cara.
Se puede utilizar el campo colorIndex de la siguiente manera:
Shape {
geometry IndexedFaceSet {
coord Coordinate {
point [0.5 0.5 0.5,
0.5 0.5 -0.5,
-0.5 0.5 -0.5,
-0.5 0.5 0.5,
0.5 -0.5 0.5,
0.5 -0.5 -0.5,
-0.5 -0.5 -0.5,
-0.5 -0.5 0.5 ]
}
coordIndex [0, 1, 2, 3, -1,
0, 4, 5, 1, -1,
1, 5, 6, 2, -1,
2, 6, 7, 3, -1,
3, 7, 4, 0, -1,
4, 7, 6, 5, -1 ]
colorPerVertex FALSE
color Color {
color [0 0 1,
1 1 0 ]
}
colorIndex [0, 0, 0, 1, 1, 1]
}}
Este código especi�ca qué color le corresponde a cada cara a partir del índice correspondiente a
los elementos de la lista de colores.
Cuando el valor de colorPerVertex es TRUE, la asignación de colores se realiza por vértice y
no por cara.
5.1. Aspectos generales 77
Shape {
geometry IndexedFaceSet {
coord Coordinate {
point [0.5 0.5 0.5,
0.5 0.5 -0.5,
-0.5 0.5 -0.5,
-0.5 0.5 0.5,
0.5 -0.5 0.5,
0.5 -0.5 -0.5,
-0.5 -0.5 -0.5,
-0.5 -0.5 0.5 ]
}
coordIndex [0, 1, 2, 3, -1,
0, 4, 5, 1, -1,
1, 5, 6, 2, -1,
2, 6, 7, 3, -1,
3, 7, 4, 0, -1,
4, 7, 6, 5, -1 ]
colorPerVertex TRUE
color Color {
color [1 0 0,
0 1 0,
0 0 1,
1 0 1,
1 1 0,
0 1 1,
1 0.5 0,
0 1 0.5 ]
}
colorIndex [0, 1, 2, 3, -1,
0, 4, 5, 1, -1,
1, 5, 6, 2, -1,
2, 6, 7, 3, -1,
3, 7, 4, 0, -1,
4, 7, 6, 5, -1 ]
}}
En este caso el campo colorIndex funciona de forma diferente. La lista que contiene es la lista de
índices de colores para cada vértice de cada cara. Es decir, cada grupo de índices acabado en −1
forma el conjunto de colores que se le asignan a los vértices de cada cara. El color �nal de la cara
es el resultado de la interpolación entre los colores de sus vértices.
De forma similar a como se de�nen objetos sólidos, también se puede de�nir objetos llamados
de "alambre", es decir, objetos formados simplemente por aristas sin caras planas. Para esto se usa
el nodo IndexedLineSet de forma completamente análoga.
5.1.2.6. Materiales
Como se menciona en 5.1.2.4, el color básico de los objetos se de�ne en el campo di�useColor
del nodo Material. Además de esta, se pueden de�nir otras propiedades de color y de textura en
VRML97.
5.1. Aspectos generales 78
El nodo Material tiene dos campos que permiten controlar las características de brillo de un
material. Estos campos son specularColor y shininess. El primero de�ne el color en formato RGB
que presenta un objeto al re�ejar especularmente la luz. El segundo determina cómo de de�nido o
borroso es el re�ejo especular. El valor de este último campo debe estar dentro del rango [0, 1].
Cuando se desea de�nir un material que emita por sí mismo luz, se puede utilizar el campo
emissiveColor. Con este campo se de�ne el color que emite el material sin necesidad de que haya
una fuente de luz que le ilumine.
La transparencia de un objeto es otra propiedad que se puede controlar mediante el campo
transparency. El valor de este campo debe estar dentro del rango [0, 1].
Otra posibilidad es aplicar texturas a los objetos. El texturizado de objetos se hace mediante
el nodo ImageTexture de�nido en el campo texture del nodo Appearance.
En este nodo se de�ne la dirección de la imagen que ha de servir como textura en el campo url.
Las imágenes deben estar en formato JPEG, PNG o GIF.
Para variar el tamaño y colocación de la textura sobre el objeto, se usa el campo textureTrans-
form del nodo Appearance. En este campo, se debe utilizar el nodo TextureTransform que permite
escalar, rotar y trasladar la textura.
Para conocer todos los detalles de cómo aplicar texturas a los objetos consultar [11].
5.1.2.7. Agrupamiento y Transformaciones
Nodo Transform Para situar, orientar y escalar los objetos dentro del entorno que se esté
construyendo, se aplican las transformaciones geométricas básicas de traslación, rotación y escalado.
Para aplicar transformaciones en VRML97 se utiliza el nodo Transform. Se trata de un nodo
agrupador que puede realizar cualquiera de las tres operaciones o las tres a la vez.
Par aplicar una traslación se utiliza el campo translation donde se de�ne el desplazamiento en
cada eje que sufrirá el objeto que se desea trasladar.
Para aplicar una rotación se utiliza el campo rotation. Las rotaciones en VRML97 se representan
mediante el formato vector-ángulo. Los tres primeros valores de este campo determinan un vector
en el espacio que corresponde al eje de rotación de la transformación. El cuarto valor corresponde al
ángulo de rotación que se quiere aplicar, expresado en radianes, respecto al eje de�nido. Los ángulos
positivos resultan en rotaciones en sentido antihorario y los ángulos negativos, en rotaciones en
sentido horario.
Para aplicar un escalado se utiliza el campo scale donde se de�ne la escala que se aplica a cada
dimensión del objeto. El escalado puede ser no uniforme si los valores son diferentes para cada eje.
El campo children es donde se de�ne el conjunto de objetos que serán afectados de la misma
forma por la trasformación especi�cada.
Cuando se desea aplicar más de una transformación a un objeto, no es necesario de�nir un nodo
Transform para cada una, sino que se puede de�nir las tres bajo un mismo nodo. Por de�nición,
5.1. Aspectos generales 79
VRML97 de�ne un orden de preferencia de operaciones de transformación que es el siguiente: en
primer lugar se aplica el escalado, en segundo lugar la rotación y en tercer lugar la traslación.
También es posible encadenar transformaciones simples sin más que de�nir un nodo Transform
en el campo children de otro nodo Transform. Las trasformaciones de�nidas de esta manera son
relativas al sistema de referencia local del nodo anterior. Cuando se utiliza esta propiedad hay que
tener en cuenta que el código se lee de dentro hacia fuera, es decir, primero se genera el objeto y
luego se van aplicando las operaciones desde el nodo interior al nodo exterior.
Nodo Anchor Así como en HTML se pueden de�nir enlaces a otros documentos, en VRML97
también se puede hacer. Esto se consigue mediante el nodo Anchor. Este nodo agrupador permite
englobar a un objeto o conjunto de objetos sobre un mismo enlace, de forma que cuando el usuario
señale uno de los objetos con el cursor y pulse el botón del ratón, se genera el enlace y se abre el
documento asociado, sea HTML, VRML o cualquier otra posibilidad.
Cada programa de visualización tiene su forma para indicar que un objeto es activo como
enlace, pero en general se acostumbra a cambiar la forma del cursor.
Para usar esta propiedad basta con incluir los objetos que se quiere que sean enlaces en el
campo children.
La opción más común es utilizar puntos de vista como enlaces añadiendo el nombre del punto
de vista escrito en su campo description, en el campo url del nodo Anchor poniendo un símbolo
# delante. De esta forma, al pulsar sobre un objeto se cambiará el punto de vista al indicado en
el enlace, permitiendo de esta manera enfocar objetos.
Nodo Billboard El nodo Billboard se utiliza para agrupar y mantener orientados el conjunto
de objetos de�nido en el campo children según la posición del observador. Es especialmente útil en
escenas en las que interesa que el observador vea sólo una cara de un objeto mientras se produce
un desplazamiento bien del observador, bien del objeto en cuestión. Para conseguir este efecto
hay que especi�car el vector [0, 0, 0] en el campo axisofRotation. De esta forma el eje Y local del
nodo Billboard se mantiene alineado con el eje Y local del punto de vista. Cuando el vector tiene
otro valor, entonces se pivota el eje Z local del nodo Billboard alrededor del vector de�nido en
axisofRotation hasta ponerlo sobre el plano de�nido por el vector que une el nodo con el punto de
vista y el vector axisofRotation.
5.1.2.8. Entorno
Iluminación Existen tres tipos de iluminación en VRML97: luz direccional (nodo Directional-
Light), luz puntual (nodo PointLight) y foco de luz (nodo SpotLight). Cada uno de los tres tipos
de luz corresponde a uno de los tres modelos clásicos de luz en grá�cos por ordenador.
El tratamiento de la luz ambiental es diferente en VRML97 respecto a otros sistemas grá�cos.
Aquella parte de la luz que ilumina los objetos de forma indirecta, por rebotes de luz provenientes
5.1. Aspectos generales 80
de las múltiples re�exiones y radiaciones sobre otros objetos adyacentes, es modelada mediante
un único concepto llamado luz ambiental o luz ambiente. Esta luz ambiente se modela mediante
un valor único que representa un incremento de intensidad que se aplica al color de los objetos,
de forma uniforme. Esto es una simpli�cación de lo que, de otra forma, resultaría muy costoso en
tiempo de cálculo.
En VRML97 no se dispone de un control único para simular la iluminación ambiente, sino que
se dispone de un control de emisión de luz ambiente por cada tipo de luz y un control de re�exión
de luz ambiente por cada material. Es decir, cada tipo de luz de�ne su incremento de intensidad
que en caso de haber múltiples luces de�nidas, se van acumulando sus iluminaciones ambiente
sobre la intensidad de cada objeto, y por otra parte, cada material de�ne en qué proporción se
verá afectado por esa iluminación ambiente de cada luz.
En el nodoMaterial se encuentra el campo ambientIntesity el cual determina en qué proporción
el material re�eja la intensidad ambiente de las luces de�nidas en el entorno. El valor de este campo
debe estar dentro del rango [0, 1] y su valor por defecto es 0,2.
Nodo DirectionalLight Con este tipo de luz se pueden iluminar los objetos con rayos pa-
ralelos entre sí, como si fueran los rayos del sol al llegar a la tierra. En otras palabras, no se tiene
un punto de luz del que salgan radialmente los rayos, sino que todos los rayos son paralelos entre
sí y por tanto inciden con el mismo ángulo sobre una super�cie. El siguiente ejemplo de�ne una
iluminación paralela que proviene de arriba a la derecha en dirección hacia abajo a la izquierda.
DirectionalLight {
ambientIntensity 0.5
color 1 1 1
intensity 1
direction -0.5 -0.5 0}
El campo ambientIntensity tiene un valor intermedio. Si se pone un valor bajo, las sombras se
intensi�can resultando más duras o contrastadas. En cambio, si se pone un valor elevado, las
sombras quedan poco notorias y en consecuencia suaves.
El campo color de�ne el color que tiene la luz. Cabe resaltar que no es la intensidad, sino sólo
el color. El color de�nido es totalmente blanco, como la luz del sol al mediodía.
El campo intensity de�ne la potencia con que la luz ilumina. El valor de este campo también
debe estar dentro del rango [0, 1].
Finalmente, el campo direction es el que determina la dirección de los rayos de luz. Lo que se
debe de�nir es un vector director.
Nodo PointLight Las luces puntuales tienen la propiedad de irradiar rayos de luz en todas
direcciones a partir de un punto dado en el campo location. Por esta razón no de�nen una dirección
de iluminación. Lo que si de�nen es lo que se conoce como atenuación. Esto quiere decir que la
5.1. Aspectos generales 81
potencia de la luz va menguando conforme aumenta la distancia a la fuente luminosa según el
factor 1/max(attenuation[0] + attenuation[1]× r + attenuation[2]× r2, 1), siendo r la distancia.
Otra propiedad de estas luces es el radio de acción de�nido en el campo radius. Se trata de la
distancia a partir de la cual, independientemente de la atenuación, la luz ya no actúa. Esto sirve
para hacer más e�ciente el renderizado de la escena.
PointLight {
location 8 -3 -10
radius 15
ambientIntensity 0.5
color 0 0 1 #Luz de color azul
intensity 1
attenuation 1 0 0 # Esta combinación no presenta atenuación}
Nodo SpotLight Este tipo de luz es el más complejo. Se basa en rayos de luz que salen desde
un punto determinado y en una dirección determinada. Es como una luz de teatro en la cual se
de�ne la dirección en que ilumina y el ángulo de apertura del haz de luz.
SpotLight {
location 0 0 -10
radius 3
ambientIntensity 0.5
color 1 0 0 #Luz de color rojo
intensity 1
attenuation 1 0 0
direction 0 -1 0
cutOffAngle 1.0472 # 60 grados en radianes
beamWidth 0.785398 # 45 grados en radianes}
En el ejemplo, todo es análogo al nodo PointLight. Lo que varía son los campos direction, cutO�-
Angle y beamWidth. El campo direction permite dar el vector director del haz de luz, es decir, la
dirección en la que se dirige la luz.
El campo cutO�Angle determina el ángulo de apertura del haz de luz, mientras que el campo
beamWidth de�ne un ángulo interno al campo cutO�Angle donde la intensidad del haz de luz es
máxima y uniforme. Entre el ángulo especi�cado por beamWidth y el especi�cado por cutO�Angle
la intensidad del haz de luz va menguando de dentro a fuera creando una zona difuminada. Estos
conceptos se muestran en la Figura 5.4.
Puntos de vista Aunque los programas de visualización permiten navegar libremente en un
mundo virtual, en VRML97 existe la posibilidad de de�nir diversos puntos de vista que actúan
como cámaras prede�nidas.
La forma de de�nir estos puntos de vista, es mediante el nodo Viewpoint.
Viewpoint {
5.1. Aspectos generales 82
Figura 5.4: De�nición de SpotLight
position 0 0 10
orientation 0 0 1 0
description "PVpor_Defecto"
}
Viewpoint {
position 10 0 10
orientation 0 1 0 0.7854 # 45 grados en radianes
description "PV_ejemplo"}
El primer nodo Viewpoint del ejemplo de�ne un punto de vista idéntico al que ya se establece por
defecto en cualquier programa de visualización de VRML97. Por lo tanto, los valores por defecto
son situar el observador sobre el eje Z positivo a diez metros del origen y mirando en dirección del
eje Z negativo.
La forma en que funciona el campo orientation es análoga a la rotación de una transformación,
utiliza un vector como eje y un ángulo de rotación para desviar el vector director por defecto de
la cámara, es decir, el vector [0, 0,−1]. En el caso del punto de vista por defecto, el eje de rotación
de�nido es el eje Z, pero esto en realidad es indiferente ya que el ángulo de rotación es cero grados.
Por lo tanto, no existe desviación.
En el segundo punto de vista se de�ne la posición del observador a diez metros en el eje X y diez
metros en el eje Z. Lo que se pretende conseguir es mirar en dirección al origen de coordenadas.
Para hacer esto, se debe desviar el vector director por defecto de la cámara hacia el origen rotando
45 grados respecto al eje Y local del punto de vista, tal y como muestra la Figura 5.5.
Así como en una cámara se puede cambiar la lente para tener un ángulo de visión más o menos
amplio, el modelo de punto de vista de VRML97 permite variar este ángulo de visión mediante el
campo �eldOfView. El ángulo que se varía es el horizontal y el vertical se adapta automáticamente
según las proporciones de la ventana del programa de visualización. El valor de este campo debe
estar dentro del rango [0, pi] y su valor por defecto es 0,785398. El siguiente ejemplo de�ne tres
puntos de vista simulando tres tipos de lentes:
Viewpoint {
5.1. Aspectos generales 83
Figura 5.5: Posición y orientación del punto de vista
fieldOfView 2.618
description "Gran_Angular"
}
Viewpoint {
fieldOfView 1.3962667
description "80mm"
}
Viewpoint {
fieldOfView 0.31416
description "Telefoto"}
Hace falta tener claro que al cambiar de punto de vista en el ejemplo anterior, la posición del
observador no se modi�ca, es decir, el observador no se mueve ni hacia delante ni atrás, es como
si tuviese un zoom el cual utiliza para ampliar o reducir lo que aparece en su rango de visión.
Es importante darle un nombre a los puntos de vista mediante el campo description, ya que el
valor de este campo es el que utilizan los programas de visualización para hacer la lista de puntos
de vista disponibles.
Panorama En muchas ocasiones es necesario complementar la representación gra�ca de los ob-
jetos de interés con un entorno para añadir realismo a la escena. Es por esto que se dispone del
nodo Background cuyo objetivo es generar un fondo que envuelve a la escena.
Se trata de una esfera de radio in�nito que engloba todo el mundo, que representa el cielo, y
una semiesfera boca arriba también de radio in�nito, que representa la tierra.
En estas esfera y semiesfera, se puede de�nir un único color, o bien se puede de�nir que un
cierto color corresponde a un cierto ángulo de elevación. En la esfera del cielo, el ángulo se calcula
a partir del punto superior o polo norte, que corresponde al ángulo 0º y se va incrementando hasta
el punto inferior o polo sur, al que corresponde el ángulo 180. En la semiesfera de la tierra funciona
al revés. Lo anterior se ilustra en la Figura 5.6.
No es obligatorio de�nir los dos fondos, la esfera del cielo y la semiesfera de la tierra, sino que
se puede escoger de�nir una u otra, las dos o ninguna. El siguiente ejemplo de�ne un cielo de color
azul uniforme.
Background {
5.1. Aspectos generales 84
Figura 5.6: de�nición de Background
skyColor [0.8 0.8 1]}
El siguiente ejemplo de�ne un degradado de azul oscuro a naranja como si fuese una puesta de sol.
Background { #0º 22º 45º 60º 75º 85º 90º
skyAngle [ 0.384, 0.785, 1.047, 1.309, 1.484, 1.5708]
skyColor [0 0 0.2, 0 0 1, 0 1 1, 0.75 0.75 1,
0.8 0.8 0, 0.8 0.6 0, 1 0.4 0 ]}
Se observa que el primer ángulo, el cero, no se incluye en la lista de ángulos. Ya se da por entendido
que el primer valor de color corresponde al polo norte. Así mismo, el último color de�nido se
extiende hasta el polo sur ya que se rellena la parte de la esfera que queda inde�nida con el último
valor dado.
Debido a estas dos razones, el primer ejemplo de color de fondo uniforme, sólo de�ne un color
y ningún ángulo.
Para de�nir una tierra, se procede de forma análoga, pero en este caso, se empieza por el polo
sur. El siguiente ejemplo añade una tierra verde.
Background { #0º 22º 45º 60º 75º 85º 90º
skyAngle [ 0.384, 0.785, 1.047, 1.309, 1.484, 1.5708]
skyColor [0 0 0.2, 0 0 1, 0 1 1, 0.75 0.75 1,
0.8 0.8 0, 0.8 0.6 0, 1 0.4 0 ]
#0º 90º
groundAngle [ 1.5708]
groundColor [0.2 1 0.4, 0.2 1 0.4]}
Se comprueba que para la tierra, el funcionamiento es diferente que para el cielo. En este caso, no
se dibuja ningún color entre el último ángulo de�nido y el polo norte. Si sólo se de�ne un color y
ningún ángulo, no se muestra nada. Por esta razón se tiene que repetir el color verde de la tierra,
para la posición 0 y para la posición 90.
5.1. Aspectos generales 85
Para de�nir un fondo, VRML97 también permite usar imágenes que se mapean sobre las paredes
internas de un cubo de tamaño in�nito que rodean todo el entorno. Así pues, se de�nen seis imágenes
para cubrir las paredes frontal, posterior, derecha, izquierda, superior e inferior del cubo en sus
respectivos campos. El siguiente ejemplo ilustra esta idea.
Background {
frontUrl "imagen1.gif"
backUrl "imagen2.gif"
topUrl "imagen3.gif"
bottomUrl "imagen4.gif"
rightUrl "imagen5.gif"
leftUrl "imagen6.gif"}
5.1.2.9. DEF y USE
Cuando queremos de�nir un nodo que se repite en muchos sitios se utiliza DEF y USE.
DEF MiColor Appearance {
material Material {
diffuseColor 0.8 0.2 0.4
}}
Transform {
translation -2 0 0
children Shape {
geometry Box {
size 3 3 3
}
appearance USE MiColor
}
}
Transform {
translation 2 0 0
children Shape {
geometry Sphere {
radius 2
}
appearance USE MiColor
}}
Aquí se observa como se de�ne una apariencia que después se usa en dos objetos diferentes. Lo se
hace en realidad es sencillamente darle el nombre MiColor a un nodo para después no tener que
escribirlo varias veces. Aún más importante que el ahorro en escritura, es la gran ayuda que supone
cuando se varía la de�nición, ya que automáticamente se modi�ca en todos los lugares donde se
use.
5.1.2.10. Nodo Switch
Este nodo tiene como misión poder elegir el nodo a presentar entre todos los nodos de�nidos
en su campo choice. El valor del campo whichChoice determina cuál elegir, siendo cero el primer
5.2. Escena para la aplicación 86
Figura 5.7: Ventana de V-Realm Builder
nodo. Si el valor de whichChoice es menor de cero, no se representa ninguno de los nodos.
5.2. Escena para la aplicación
El archivo que contiene la escena se llama Scene.wrl. Se pretende conseguir una escenario que
cuente con un helicóptero y un barco, cuyos movimientos vienen controlados por un modelo de
Simulink mediante VRT.
5.2.1. Entorno
La Figura 5.7 muestra la ventana de V-Realm Builder. En la parte izquierda de la pantalla
se puede ver un árbol donde se muestran todos los nodos de la escena, mientras que en la parte
derecha de la pantalla se ve la interpretación del código, tal y como se ve en un programa de
visualización como Orbisnap. Mediante el árbol se puede acceder a cualquier campo de los nodos
de�nidos y modi�car sus valores.
5.2.1.1. Iluminación
La iluminación de la escena está compuesta por dos nodos DirectionalLight llamados Sun1 y
Sun2 como se aprecia en la Figura 5.8.
DEF Sun1 DirectionalLight {
color 1 1 1
direction -0.707107 -0.707107 -2.38419e-007
intensity 0.6
}
DEF Sun2 DirectionalLight {
color 1 1 1
direction 0.707107 -0.707107 -2.38419e-007
intensity 0.6}
5.2. Escena para la aplicación 87
Figura 5.8: Iluminación
Figura 5.9: Fondo
5.2.1.2. Fondo
El fondo está de�nido mediante el nodo Background, como se muestra en la Figura 5.9.
Background {
groundAngle 1.571
groundColor [ 0 0.2 1, 0 0.2 1 ]
skyAngle [ 1.309, 1.571 ]skyColor [ 0 0.2 0.7, 0 0.5 1, 1 1 1 ]
}
La Figura 5.10 muestra el per�l de la esfera con los colores de�nidos en el código.
5.2.1.3. Objetos
El escenario está de�nido por los siguientes objetos:
Nodo Water Este es un nodo de tipo Transform que puede verse en la Figura 5.11, de�nido
por el siguiente código:
DEF Water Transform {
children Shape {
appearance Appearance {
material Material {
ambientIntensity 0
5.2. Escena para la aplicación 88
Figura 5.10: Colores de la esfera de fondo
Figura 5.11: Nodo Water
5.2. Escena para la aplicación 89
Figura 5.12: Nodo Land
diffuseColor 0 0 0
emissiveColor 0 0.2 1
shininess 0
}
}
geometry IndexedFaceSet {
coord Coordinate {
point [-200 0.1 -200,
200 0.1 -200,
200 0.1 200,
-200 0.1 200 ]
}
coordIndex [ 3, 2, 1, 0, -1 ]
}
}}
Se trata simplemente de un plano paralelo al plano XZ que representa la super�cie del agua. Emite
luz de color igual al color del fondo, de forma que su apariencia no se ve afectada por la iluminación
de la escena.
Nodo Land Este es un nodo de tipo Transform que puede verse en la Figura 5.12, de�nido por
el siguiente código:
DEF Land Transform {
children Shape {
appearance Appearance {
material Material {
diffuseColor 0.6 0.9 0.25
shininess 0
}
}
geometry ElevationGrid {
creaseAngle 3.14
5.2. Escena para la aplicación 90
Figura 5.13: Nodo ElevationGrid
Figura 5.14: Terreno generado
xDimension 32
xSpacing 3
zDimension 28
zSpacing 3
height [...]
}}
El nodo ElevationGrid es un tipo especial parecido a IndexedFaceSet. De�ne una rejilla de puntos en
el plano XZ de dimensión xDimension por zDimension equiespaciados por las cantidades xSpacing
y zSpacing respectivamente. Cada punto tiene una elevación en la dirección Y de�nida mediante
la lista de valores del campo height. Todos los puntos se unen mediante planos y las aristas se
redondean teniendo en cuenta el ángulo de�nido en el campo creaseAngle. De esta forma se pueden
representar terrenos, tal como se aprecia en la Figura 5.13.
El terreno generado puede verse en la Figura 5.14.
Como el plano que representa la super�cie del agua esta de�nido a una altura de 0,1, el fondo
del terreno6 se oculta y las montañas sobresalen, creando la apariencia de un conjunto de islas en
medio del mar. Este escenario está basado en el escenario del ejemplo vrlights de VRT, con algunas
6que tiene altura 0.
5.2. Escena para la aplicación 91
Figura 5.15: Nodos Runway y Deck
Figura 5.16: Pista y muelle
modi�caciones.
Nodos Runway y Deck Estos dos nodos de tipo Transform que pueden verse en la Figura 5.15,
representan una pista de aterrizaje y un muelle respectivamente utilizando planos con texturas, tal
como se aprecia en la Figura 5.16.
DEF Runway Transform {
translation 63 0 57
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 1 1 1
shininess 0}
textureTransform TextureTransform {
5.2. Escena para la aplicación 92
scale 5 1
}
texture ImageTexture {
url "texture/runway.jpg"
repeatS TRUE
repeatT TRUE
}
}
geometry IndexedFaceSet {
coord Coordinate {
point [ -1.5 1.01 -7.5,
-1.5 1.01 7.5,
1.5 1.01 7.5,
1.5 1.01 -7.5 ]
}
texCoord TextureCoordinate {
point [ 0 0,
1 0,
1 1,
0 1 ]
}
coordIndex [ 0, 1, 2, 3, -1 ]
texCoordIndex [ ]}
}
Shape {
appearance Appearance {
material Material {
diffuseColor 1 1 1
shininess 0
}
textureTransform TextureTransform {
scale 1 1
}
texture ImageTexture {
url "texture/landpad.jpg"
repeatS TRUE
repeatT TRUE
}
}
geometry IndexedFaceSet {
coord Coordinate {
point [ 3 1.01 5.5,
3 1.01 7.5,
5 1.01 7.5,
5 1.01 5.5 ]
}
texCoord TextureCoordinate {
point [ 0 0,
1 0,
1 1,
0 1 ]
}
coordIndex [ 0, 1, 2, 3, -1 ]
texCoordIndex [ 1, 2, 3, 0, -1 ]
}
}
5.2. Escena para la aplicación 93
]}
DEF Deck Transform {
translation 70.5 0 54
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 1 1 1
shininess 0
}
textureTransform TextureTransform {
scale 1 10
}
texture ImageTexture {
url "texture/madera.jpg"
repeatS TRUE
repeatT TRUE
}
}
geometry IndexedFaceSet {
coord Coordinate {
point [ -5 0.35 1.5,
5 0.35 1.5,
5 0.35 -1.5,
-5 0.35 -1.5 ]
}
texCoord TextureCoordinate {
point [ 0 0,
1 0,
1 1,
0 1 ]
}
coordIndex [ 0, 1, 2, 3, -1 ]
texCoordIndex [ 1, 2, 3, 0, -1 ]
}}
Transform {
translation 4.8 0.174 1.3
children DEF pilar Shape {
appearance Appearance {
material Material {
diffuseColor 0 0 0
emissiveColor 0.6 0.3 0
shininess 0
}
}
geometry Cylinder {
height 0.35
radius 0.1
}
}
}
Transform {
translation 4.8 0.174 -1.3
children USE pilar
}
5.2. Escena para la aplicación 94
Figura 5.17: Nodo OXYZ_VRML
Figura 5.18: Origen de coordenadas global
Transform {
translation 1 0.174 -1.3
children USE pilar
}
Transform {
translation 1 0.174 1.3
children USE pilar
}
]}
5.2.2. Origen de coordenadas global
Este nodo representa el origen de coordenadas global de VRML que puede verse en la Figura
5.17, mediante tres cilindros de colores7 agrupados en el nodo Group llamado Gejes . Las letras
que marcan los ejes están hechas mediante planos indexados usando un nodo Billboard para que se
lean siempre independientemente de la posición de la cámara. Todo esto se engloba bajo un nodo
Switch que permite activar o desactivar su visualización. En la Figura 5.18 se muestra el objeto.
De aquí en adelante se omite el código dada la extensión del mismo. Consultar el archivo Scene.wrl
5.2.3. Origen de coordenadas local
El nodo tipo Transform llamado OXYZ_Comun que puede verse en la Figura 5.19, engloba a
su vez dos nodos llamados OXYZ_Heli y OXYZ_Boat.
7azul para el eje X, verde para el eje Y y rojo para el eje Z.
5.2. Escena para la aplicación 95
Figura 5.19: Origen de coordenadas para los objetos móviles
Este origen de coordenadas local está situado sobre la plataforma de aterrizaje del helicóptero
de�nida en el nodo Runway mediante la traslación X = 67 , Y = 1,215 , Z = 63,5. La rotación
[−0,577683 0,577683 0,576684 2,0944] hace el cambio de coordenadas:XL = −ZG , YL = XG , ZL =
YG, donde el subíndice G signi�ca las coordenadas globales de VRML y el subíndice L signi�ca
las coordenadas locales bajo el nodo OXYZ_Comun. Por otra parte, el nodo OXYZ_Heli no tiene
traslación ni rotación, por lo que este nuevo origen, que tiene por objetivo englobar el helicóptero,
coincide con el origen común. Así mismo, el nodo OXYZ_Boat tiene una traslación X = 12,5 , Y =
−13 , Z = −0,4150 y una rotación [0,707107 − 0,707107 0 3,14159]8, lo que sitúa este nuevo ori-
gen en el agua cerca del muelle con el cambio de coordenadas XL = XG , YL = ZG , ZL = −YG,
con objeto de englobar el barco. Estos dos orígenes de coordenadas se toman en adelante como el
origen de coordenadas global de Simulink para el helicóptero y el barco respectivamente. La Figura
5.20 ilustra todo lo anterior. El sistema de referencia local del helicóptero que usa el modelo es el
siguiente: eje X apunta hacia adelante, eje Y apunta hacia la izquierda y eje Z apunta hacia arriba.
Para el barco el sistema de referencia local es: eje X apunta hacia proa, eje Y apunta hacia estribor
y eje Z apunta hacia abajo.
8ambas respecto al origen común.
5.2. Escena para la aplicación 96
Figura 5.20: Diferentes orígenes de coordenadas (OXYZ_VRML, OXYZ_Comun = OXYZ_Heliy OXYZ_Boat)
5.2.4. Estructura de nodos para el movimiento
El siguiente esquema ilustra la organización de nodos para el movimiento de los objetos con-
trolado por Simulink teniendo en cuenta lo anterior.
5.2. Escena para la aplicación 97
Origen de VRML (Scene.wlr )
OXYZ_Comun (Transform )
OXYZ_Heli (Transform )
Ejes (nodo Switch para visualizar los ejes definidos por Gejes )...
Obs_Heli (Viewpoint estático cerca de la pista)
HelicopterN (Switch para mostrar u ocultar el objeto)
HelicopterN (Anchor para cambiar la cámara a vista
de piloto si se selecciona el objeto)
OrigenN (Transform )
TrasN (Transform para aplicar la traslación)
RotN (Transform para aplicar la rotación)
PartsN (Transform para agrupar las partes
que conforman el objeto)
Raptor60N (Transform para agrupar el
modelo del helicóptero)...
Tail_rotN (Transform para aplicar la rotación
a las palas del rotor de cola)...
POS_fijaN y PilotoN (varios ViewPoint que definen
diferentes cámaras)
ColIndN (Transform que define un indicador para
detección de colisiones)...
ReglaN (Switch para mostrar u ocultar unos ejes
locales del helicóptero)...
FuerzaN (Switch para mostrar u ocultar indicadores
de fuerzas y momentos del helicóptero)...
POS_segNrot (varios Transform para aplicar rotaciones
parciales y definir diferentes cámaras)
OXYZ_Boat (Transform )
Ejes (nodo Switch para visualizar los ejes definidos por Gejes )...
BoatN (Switch para mostrar u ocultar el objeto)
BoatN (Anchor para cambiar la cámara a vista de piloto si se
selecciona el objeto)
OrigenNb (Transform )
TrasNb (Transform para aplicar la traslación)
RotNb (Transform para aplicar la rotación)
PartsNb (Transform para agrupar las partes que
conforman el objeto)
Navy_EscortN (Transform para agrupar el modelo del barco)...
POS_fijaNb, POS_fija_popaNb y PilotoNb
(varios ViewPoint que definen diferentes cámaras)
POS_segNbrot y POS_seg_popaNbrot
(varios Transform para aplicar rotaciones
parciales y definir diferentes cámaras)
5.2. Escena para la aplicación 98
En el esquema anterior, la letra N toma los valores 1, 2 o 3 ya que se encuentran de�nidos
tres helicópteros y tres barcos. El número uno toma el color azul y sirve para representar el
movimiento de referencia. El número dos toma el color verde y representa el movimiento de la
simulación. Finalmente, el número tres toma el color rojo y representa el movimiento según datos
experimentales.
Respecto a los diferentes puntos de vista de�nidos, la palabra POS pude tomar los valores izq,
der, delante, atras y arriba. De esta forma se indica la posición de la cámara respecto al objeto.
Es decir, la cámara izq mira el objeto desde el lado izquierdo, der desde el lado derecho, etc. Las
vistas marcadas como �ja se encuentran bajo la acción de la rotación y la traslación9, por lo que
se mueven solidarias al objeto. En cambio, las marcadas como seg se encuentran afectadas por la
traslación y por alguna rotación parcial aplicada al nodo POS_segNrot. Por ejemplo, suponiendo
que se aplique una rotación al helicóptero N, ésta viene de�nida por los ángulos de Euler cuyos
valores son r, p e y10 y se aplica al nodo RotN de forma adecuada11. La cámara atras_segN mira el
helicóptero N desde atrás. Como el eje de la cámara se corresponde con el eje X del helicóptero, la
rotación parcial consiste en aplicar al nodo POS_segNrot los valores p e y del helicóptero, dejando
r = 0. De esta forma se consigue que la cámara siga al helicóptero al igual que la cámara �ja, pero
permitiendo ver la rotación del objeto que ocurre alrededor de su eje.
La cámara PilotoN es una cámara �ja que va situada en la posición de un piloto real.
Todo lo anterior es completamente análogo para el caso del barco. Para distinguir los nodos
unos de otros, se añade la letra b al �nal en los nodos del barco.
Además de las vistas de�nidas para el helicóptero, el barco cuenta con algunas vistas auxiliares
en la sección de popa para poder observar los casos en que el helicóptero aterrice sobre esta.
5.2.5. Modelo 3D del helicóptero
Un modelo bastante utilizado en experimentación con UAVs es el Raptor 60 de la empresa
Thunder Tiger como el que se muestra en la Figura 5.21. Ver [13].
El simulador de vuelo Clear View, del cual se dispone de una versión de evaluación descar-
gable a través de Internet (ver [14]) incorpora entre sus modelos a escala uno del Raptor 60.
Este simulador utiliza el formato abierto de modelado 3D del programa AC3D, del cual tam-
bién se dispone de una versión de evaluación descargable a través de Internet (ver [15]). Dicho
modelo se encuentra en el archivo body.ac en la carpeta �C:\Archivos de Programa/SVK Sys-
tems/ClearView/models/raptor60/�. El programa AC3D tiene la posibilidad de exportar archivos
a otros formatos de modelado 3D, entre ellos VRML97. Basta con abrir el archivo y seleccionar en
el menú File la opción Export y luego pulsar sobre VRML 2.
9son children del nodo RotN que a su vez es children del nodo TrasN.10r = roll (rotación alrededor del eje X), p = pitch (rotación alrededor del eje Y) , y = yaw (rotación alrededor
del eje Z).11pasando de rpy a la forma vector/ángulo.
5.2. Escena para la aplicación 99
Figura 5.21: Thunder Tiger Raptor 60
Una vez exportado el archivo ya se tiene el modelo del Raptor 60 en el formato adecuado.
El archivo que se genera está en formato .wrl y consta de un grupo con varios nodos Shape que
representan las piezas del helicóptero mediante objetos de tipo IndexedFaceSet e IndexedLineSet. La
mayor parte de estas piezas tiene una textura de�nida por imágenes que se encuentran en la misma
carpeta del modelo. Puesto que se pretende que el helicóptero se mueva mediante transformaciones
que son controladas con señales de Simulink, el hecho de que el objeto tenga texturas afecta
negativamente al rendimiento, ya que el renderizado que se realiza en cada actualización de valores
se ralentiza considerablemente por la presencia de estas.
Para solventar este problema, se eliminan todas las texturas del modelo cambiando la apariencia
de las piezas por colores planos12. Para eliminar dichas texturas hay que borrar los siguientes
elementos del código del modelo:
Dentro del nodo Appearance de todos los nodos Shape, los campos:
textureTransform TextureTransform { }texture ImageTexture { }
Dentro del campo geometry de todos los nodos Shape, los campos:
texCoord TextureCoordinate { point [ ] }texCoordIndex [ ]
Todos los nodos IndexedLineSet
Por razones desconocidas en el proceso de exportar el archivo se introducen ciertos fallos en el
código que hacen que algunas partes del modelo no se dibujen correctamente en V-Realm Builder
12azul, verde o rojo para las piezas principales como el fuselaje y gris para el resto de piezas.
5.2. Escena para la aplicación 100
Figura 5.22: Modelo 3D del helicóptero
y causen un error en Orbisnap impidiendo su visualización. Para corregir este otro problema,
hay que revisar cuidadosamente dentro del campo geometry de todos los nodos Shape, el campo
coordIndex y eliminar los trozos de la lista en donde haya menos de tres valores antes de una marca
−1.
Una vez aislado el modelo, se introducen en la escena tres copias con sus respectivos colores
sin más que copiar el código en el campo children del nodo Raptor60N mencionado en 5.2.4.
Todas las piezas son renombradas convenientemente teniendo en cuenta la parte del helicóptero
que representan. Las palas del rotor de cola, nombradas como bladesN, se apartan de este grupo y
se sitúan bajo el nodo Tail_RotN
DEF Tail_Rot1 Transform {
translation 0.9213 0.028 -0.0574
children DEF blades1 Transform {
translation -0.9213 -0.028 0.0574children [...]
Como se puede ver, el nodo bladesN tiene una traslación para situar la pieza en el origen de
coordenadas y el nodo Tail_RotN tiene una traslación de signo contrario para volver a situar la
pieza en la cola. Con esto se consigue que al aplicar la rotación adecuada en el nodo Tail_RotN
las palas giren sobre si mismas y no alrededor del centro del helicóptero.
La Figura 5.22 muestra el resultado �nal.
5.2.6. Modelo 3D del barco
El modelo del barco elegido es el Navy_Escort de la librería de objetos de V-Realm Builder.
Al igual que el helicóptero, se introducen tres copias con sus respectivos colores y con una escala
del 5,6 % en todos los ejes, como se aprecia en la Figura 5.23.
5.2. Escena para la aplicación 101
Figura 5.23: Modelo 3D del barco
5.2.7. Otros objetos
5.2.7.1. Reglas
El nodo ReglaN de tipo Switch, contiene unos ejes locales del helicóptero hasta una longitud de
cuatro metros, con marcas principales en cada metro y marcas secundarias cada diez centímetros.
En la Figura 5.24 se puede ver este objeto.
5.2.7.2. Indicadores de fuerza y momentos
El nodo FuerzaN de tipo Switch, contiene unos indicadores de fuerzas y momentos basados en
los indicadores de fuerzas y el volante del ejemplo vr_octavia de VRT. En la Figura 5.25 se pueden
ver estos indicadores.
5.2.7.3. Indicadores para la detección de colisiones
Con el objetivo de implementar un detector de colisiones entre el helicóptero y la plataforma
de popa del barco se añade este objeto que consiste en tres esferas de colores que deben aparecer13
cuando se detecte la colisión bajo el siguiente criterio:
Colisión entre helicóptero de simulación y barco de simulación ->esferas amarilla y verde
sobre helicóptero verde
Colisión entre helicóptero de simulación y barco experimental ->esferas amarilla y roja sobre
helicóptero verde
13haciendo uso de nodos Switch.
5.2. Escena para la aplicación 102
Figura 5.24: Ejes locales del helicóptero
Figura 5.25: Indicadores de fuerzas (líneas) y momentos (volantes)
5.2. Escena para la aplicación 103
Figura 5.26: Indicador de colisiones
Colisión entre helicóptero experimental y barco de simulación ->esferas amarilla y verde
sobre helicóptero rojo
Colisión entre helicóptero experimental y barco experimental ->esferas amarilla y roja sobre
helicóptero rojo
Mediante un nodo Billboard se consigue que las esferas siempre estén alineadas independientemente
de la posición de la cámara. La Figura 5.26 muestra un ejemplo del objeto completo.
