13.3.4 Movimiento en Java 3D

Java 3D
Autores:
Carlos de Tapia Miguel del Corral
Aníbal Chehayeb Morán

Tabla de Contenidos
13.1 INTRODUCCIÓN ........................................................................................................5
13.1.1 ¿Qué es Java 3D? .............................................................................................5
13.1.2 Objetivos..............................................................................................................5
13.1.3 Cómo ver un objeto en 3D siguiendo un grafo .........................................6
13.1.4 Paradigma de programación..........................................................................7
13.1.4.1 Modelo de programación del grafo de escena .............................. 7
13.1.4.2 Aplicaciones y applets..................................................................... 7
13.1.5 Explicación de la estructura de trabajo.......................................................8
13.2 CONCEPTOS GENERALES..................................................................................10
13.2.1 Objetos del grafo de escena.........................................................................11
13.2.1.1 Objetos de la superestructura del grafo de escena .................... 12
13.2.1.2 Objetos de agrupación de nodos.................................................. 13
13.2.1.3 Objetos nodos hoja........................................................................ 14
13.2.2 Otros objetos implicados..............................................................................16
13.2.3 Construcción de un árbol .............................................................................17
13.2.3.1 Grafos de escena ilegales ............................................................. 18
13.2.4 Sistema de coordenadas...............................................................................19
13.2.4.1 Coordenadas de alta resolución................................................... 20
13.2.5 Modos de renderización ................................................................................21
13.2.6 Paquetes Java 3D............................................................................................23
13.3 MODELO DE CONTENIDOS .................................................................................24
13.3.1 Sistemas de coordenadas y paquete javax.vecmath ............................24
13.3.2 Formas geométricas.......................................................................................26
13.3.2.1 Formas geométricas predefinidas ................................................ 27
13.3.2.2 Construcción de elementos geométricos .................................... 28
13.3.2.3 Texto 2D y 3D.................................................................................. 33
13.3.2.4 Ayudas a la construcción de figuras geométricas...................... 34
13.3.2.5 Cargadores de escenas 3D ........................................................... 35
13.3.3 Modificación de la apariencia ......................................................................37
13.3.3.1 Concepto de límite ......................................................................... 37
13.3.3.2 Configuración del fondo................................................................ 38
13.3.3.3 Apariencia....................................................................................... 39
13.3.3.3.1 Atributos generales..........................................................................40
13.3.3.4 Luces............................................................................................... 42
13.3.3.4.1 Modelos implicados.........................................................................42
13.3.3.4.2 Fuentes de luz ...................................................................................45
13.3.3.4.3 Clase Material ....................................................................................46
13.3.3.4.4 Influencia de las fuentes de luz ....................................................47
13.3.3.5 Texturas .......................................................................................... 47
2

13.3.3.5.1 Clases esenciales de texturado....................................................49
13.3.4 Movimiento en Java 3D..................................................................................52
13.3.4.1 Conceptos básicos ........................................................................ 52
13.3.4.1.1 Traslaciones y rotaciones en Java 3D ........................................52
13.3.4.1.2 Concepto de capacidad ..................................................................53
13.3.4.1.3 Comportamientos .............................................................................53
13.3.4.2 Interacción con el usuario............................................................. 56
13.3.4.2.1 Interacción a través del teclado....................................................57
13.3.4.2.2 Gestión del ratón ..............................................................................58
13.3.4.2.3 Discriminación de objetos .............................................................58
13.3.4.3 Animación en Java 3D ................................................................... 60
13.4 MODELO DE VISUALIZACIÓN.............................................................................68
13.4.1 Justificación .....................................................................................................68
13.4.2 Influencia del entorno físico en la vista ....................................................69
13.4.2.1 Sistema montado en la cabeza ..................................................... 69
13.4.2.2 Sistema montado en una habitación ............................................ 70
13.4.3 Separación de físico y virtual.......................................................................70
13.4.3.1 El mundo virtual ............................................................................. 70
13.4.3.2 El mundo físico............................................................................... 71
13.4.4 Objetos que definen la vista.........................................................................71
13.4.5 ViewPlatform: Un lugar en el mundo virtual ............................................73
13.4.6 El sistema de coordenadas ..........................................................................74
13.4.6.1 Sistema de coordenadas “montados en habitación” ................. 74
13.4.6.1.1 Sistemas de coordenadas virtuales ............................................74
13.4.6.1.2 Sistemas de coordenadas físicos ................................................75
13.4.6.2 Sistemas de coordenadas “montados en cabeza” ..................... 75
13.5 RESUMEN .................................................................................................................76
13.6 CONCLUSIONES .....................................................................................................78
13.7 BILIOGRAFÍA Y RECURSOS................................................................................79
3

Índice de Tablas
TABLA 1 - ESCALA DE LAS COORDENADAS DE ALTA RESOLUCIÓN .................................................................... 20
TABLA 2 - REGLAS DE GENERACIÓN DE COLOR EN PRESENCIA DE UN OBJETO MATERIAL ................................. 47
TABLA 3 - REGLAS DE GENERACIÓN DE COLOR EN AUSENCIA DE UN OBJETO MATERIAL .................................. 47
TABLA 4 - TABLAS DE MOVIMIENTOS PREDEFINIDOS EN JAVA 3D .................................................................... 57
Índice de figuras
FIGURA 1 - IMAGEN 3D VISTA SIGUIENDO UNA ESTRUCTURA DE ÁRBOL ............................................................. 6
FIGURA 2 - NOTACIÓN EMPLEADA EN LOS GRAFOS DE ESCENA ......................................................................... 11
FIGURA 3 - ESTRUCTURA GENERAL DE UN GRAFO DE ESCENA........................................................................... 12
FIGURA 4 - GRAFO DE ESCENA ILEGAL .............................................................................................................. 18
FIGURA 5 - POSIBLE CORRECCIÓN DEL GRAFO DE ESCENA ILEGAL .................................................................... 19
FIGURA 6 - TIPOS DE SISTEMAS DE COORDENADAS............................................................................................ 19
FIGURA 7 - JERARQUÍA DE CLASES DEL PAQUETE JAVAX.VECMATH .................................................................. 25
FIGURA 8 - JERARQUÍA DE CLASES PARA LAS FIGURAS GEOMÉTRICAS PREDEFINIDAS ....................................... 27
FIGURA 9 - JERARQUÍA DE CLASES PARA LA CLASE GEOMETRY ........................................................................ 29
FIGURA 10 - EJEMPLO DE CREACIÓN DE UN CUBO EMPLEANDO CLASES INDEXADAS ......................................... 32
FIGURA 11 - JERARQUÍA DE CLASES DE DEFINICIÓN GEOMÉTRICA INDEXADAS ................................................. 33
FIGURA 12 - ORIENTACIÓN Y ALINEACIÓN DE UN TEXTO 3D............................................................................. 34
FIGURA 13 - LUZ (L), VECTOR NORMAL A LA SUPERFICIE (N) Y VECTOR DIRIGIDO AL OBSERVADOR (E) ......... 42
FIGURA 14 - ESFERA SOMBREADA..................................................................................................................... 43
FIGURA 15 - EL VECTOR DE LUZ PERMANECE CONSTANTE PARA UNA FUENTE DE TIPO DIRECTIONALLIGHT..... 43
FIGURA 16 - VARIACIÓN DEL VECTOR DIRIGIDO AL OBSERVADOR (E) ............................................................... 44
FIGURA 17 - MÉTODOS FLAT Y GOURAUD EMPLEADOS PARA SOMBREAR UNA ESFERA..................................... 45
FIGURA 18 - COMBINACIÓN DE TEXTURA Y COLOR ........................................................................................... 51
FIGURA 19 - GRAFO DE ESCENA QUE INCORPORA UN COMPORTAMIENTO.......................................................... 55
FIGURA 20 - CLASES DE COMPORTAMIENTO IMPLICADAS EN LA INTERACCIÓN CON EL USUARIO ...................... 56
FIGURA 21 - DISCRIMINACIÓN DE UN OBJETO VISUAL MEDIANTE EL MECANISMO PICK RAY .............................. 59
FIGURA 22 - JERARQUÍA DE CLASES BEHAVIOR INVOLUCRADAS EN LA ANIMACIÓN ......................................... 60
FIGURA 23 - PULSO DE TIEMPO GENERADO POR UN OBJETO ALPHA................................................................... 61
FIGURA 24 - FORMAS ALTERNATIVAS DE ONDA GENERADAS POR UN OBJETO ALPHA ....................................... 62
FIGURA 25 - SUAVIZADO DEL PULSO DE TIEMPO GENERADO POR UN OBJETO ALPHA ........................................ 62
FIGURA 26 - RESULTADOS DE SUAVIZAR UN PULSO DE TIEMPO DE UN OBJETO ALPHA...................................... 63
FIGURA 27 - JERARQUÍA DE CLASES DE LOS INTERPOLADORES.......................................................................... 63
FIGURA 28 - PARES KNOT/VALOR Y CRITERIO DE SELECCION DE UN KNOT ........................................................ 64
4

13.1 INTRODUCCIÓN
13.1.1 ¿Qué es Java 3D?
La API (Application Program Interface) Java 3D es una interfaz de programación de
aplicación utilizada para escribir aplicaciones y applets con gráficos en tres dimensiones.
Proporciona a los desarrolladores constructores de alto nivel para crear y manipular
geometrías 3D y para construir las estructuras utilizadas en el renderizado de dichas
geometrías. Se pueden describir grandes mundos virtuales utilizando estos constructores,
que proporcionan a Java 3D la suficiente información como para renderizar dichos mundos
de forma eficiente.
Java 3D proporciona a los desarrolladores de gráficos 3D la principal característica
de Java: “escribe una vez y ejecútalo donde sea”. Java 3D es parte del conjunto de APIs
JavaMedia, lo cual hace que esté disponible en un gran número de plataformas. También,
se integra correctamente con Internet ya que tanto los applets como las aplicaciones escritas
utilizando Java 3D tienen acceso al conjunto completo de clases de Java.
La API Java 3D parte de otras APIs gráficas existentes así como de las nuevas
tecnologías disponibles. Las construcciones gráficas de bajo nivel de Java 3D sintetizan las
mejores ideas encontradas en otras APIs de bajo nivel como Direct3D, OpenGL,
QuickDraw3D y XGL. Del mismo modo, sus construcciones de alto nivel integran las
mejores características proporcionadas por varios sistemas de escenas basados en grafos.
Además, Java 3D introduce algunos conceptos que no se consideran habitualmente como
parte de los entornos gráficos, como el sonido espacial 3D. Las posibilidades de sonido de
Java 3D permiten proporcionar una experiencia más realista al usuario.
13.1.2 Objetivos
Java 3D ha sido diseñado teniendo en cuenta diferentes objetivos; prestando especial
atención en el buen rendimiento. Se tomaron diferentes decisiones relativas al diseño de tal
forma que las implementaciones de Java 3D proporcionaran el mejor rendimiento posible a
las aplicaciones de usuario. En particular, cuando se realizan distribuciones, se elige la
alternativa que permite obtener mejores prestaciones en tiempo de ejecución.
Otros objetivos importantes de Java 3D son:
Proporcionar un amplio conjunto de utilidades que permitan crear mundos en 3D
interesantes. También se tuvo en cuenta no incluir características no esenciales u
oscuras. No se incluyeron características que podrían colocarse directamente sobre
Java 3D.
5

Proporcionar un paradigma de programación orientado a objetos de alto nivel para
permitir a los desarrolladores generar sofisticadas aplicaciones y applets de forma
rápida.
Proporcionar soporte a cargadores en tiempo de ejecución. Esto permite que Java
3D se adapte a un gran número de formatos de ficheros, como pueden ser formatos
específicos de distintos fabricantes de CAD, formatos de intercambio o VRML 1.0
(Virtual Reality Modelling Language) y VRML 2.0.
13.1.3 Cómo ver un objeto en 3D siguiendo un grafo
Java 3D distribuye la información necesaria para representar objetos y escenas en tres
dimensiones en una estructura de grafo. Siguiendo dicha estructura desde el nodo raíz hasta
los distintos nodos hoja, se van viendo las distintas operaciones que se realizan para crear la
escena final que se quiere conseguir. En dicho grafo se incluyen tanto los distintos
elementos que forman parte de la escena como las transformaciones que se les aplica. Del
mismo modo, se insertan en el mismo grafo (aunque en otra rama distinta) diferentes
elementos que tienen que ver con el punto de vista del usuario.
La Figura 13. 1 representa cómo se puede crear una imagen compleja mediante la
unión de diferentes elementos unidos por las correspondientes relaciones.
Figura 1 - Imagen 3D vista siguiendo una estructura de árbol
6

En esta figura puede apreciarse cómo, para componer la figura final (el circuito), es
necesario modelar previamente las distintas partes que la forman. Alguna de las partes
puede, a su vez, ser dividida en otras partes que también necesitan ser modeladas.
De esta forma, para llegar a obtener la imagen global, hay que recorrer las distintas ramas
generadas, desde las hojas hasta la raíz, formándose así los distintos elementos que
convergen en la creación del objeto final.
Al igual que en la figura, el árbol necesario para generar imágenes en Java 3D va formando
los distintos elementos de las mismas de manera progresiva, añadiendo en las diferentes
ramas del árbol las características propias de la imagen que se genera. Por otro lado, la
distribución de los elementos que forman la escena en una estructura jerárquica permite
aislar convenientemente unos aspectos de otros para poder trabajar con ellos de forma más
independiente.
13.1.4 Paradigma de programación
Java 3D es una API orientada a objetos. Las aplicaciones construyen los distintos elementos
gráficos como objetos separados y los conectan unos con otros mediante una estructura en
forma de árbol denominada grafo de escena. La aplicación manipula los diferentes objetos
utilizando los métodos de acceso, de modificación y de unión definidos en su interfaz.
13.1.4.1 Modelo de programación del grafo de escena
El modelo de programación basado en el grafo de escena de Java 3D proporciona un
mecanismo sencillo y flexible para representar y renderizar escenas. El grafo de escena
contiene una descripción completa de la escena o universo virtual. Esta descripción incluye
datos sobre la geometría, información de los distintos atributos, así como información de
visualización necesaria para renderizar la escena desde un punto de vista en particular.
La API Java 3D mejora algunas APIs previas eliminando algunas de las serias
dependencias impuestas por éstas. Java 3D permite al programador diseñar su escena en
base a objetos geométricos y no considerando triángulos. Le permite centrarse en la escena
y en su composición y no en cómo escribir el código para renderizar eficientemente la
escena en cuestión.
13.1.4.2 Aplicaciones y applets
Java 3D ni anticipa ni soporta directamente cualquier necesidad posible de 3D. En cambio,
proporciona la base necesaria para añadir nuevas funcionalidades utilizando código Java.
Objetos definidos utilizando un sistema de CAD o de animación se pueden incluir en una
aplicación basada en Java 3D. Algunos paquetes de modelados tienen distintos formatos
externos que son, en muchos casos, propietarios. Los diseñadores pueden exportar
geometrías a fichero utilizando modeladores externos. Java 3D puede utilizar toda esa
información geométrica, pero sólo si la aplicación proporciona un método para leer y
traducir la información del modelador en primitivas Java 3D.
7

De forma similar, cargadores VRML analizarán y traducirán ficheros VRML y
generarán los objetos Java 3D apropiados y el código Java necesario para poder utilizar el
contenido de los ficheros.
Navegadores. Los navegadores actuales pueden aceptar contenido 3D pasando
información a visores 3D (plugins) que la renderizan dentro de su propia ventana.
Con el tiempo, serán los propios navegadores los que se encarguen, directamente,
de la gestión de los elementos 3D.
Juegos. Los desarrolladores de software para juegos 3D siempre han intentado
aprovechar, en la medida de lo posible, hasta el límite las posibilidades del
hardware disponible. Históricamente han utilizado optimizaciones específicas del
hardware y, por su puesto, no portables. De esta forma trataban de lograr el mejor
rendimiento posible. Por esta razón, la programación típica de juegos se realizaba a
un nivel de abstracción menor que el sencillo nivel de Java 3D. Sin embargo, la
tendencia actual en la creación de juegos 3D es usar aceleradores hardware 3D de
propósito general y utilizar menos “trucos” para la renderización.
Así pues, aunque Java 3D no fue explícitamente diseñado para satisfacer las
expectativas de los desarrolladores de juegos, sus sofisticadas técnicas de implementación
proporcionan un rendimiento más que suficiente para realizar distintas aplicaciones para
juegos. Puede criticarse, de cualquier forma, que las aplicaciones escritas con una API
general, como puede ser Java 3D, pueden tener una ligera penalización en cuanto a
rendimiento en comparación con otras que utilicen técnicas no portables. Sin embargo,
otros factores como la propia portabilidad, el tiempo de desarrollo y el coste pueden
también tenerse en cuenta para contrarrestar ese pequeño déficit de rendimiento.
13.1.5 Explicación de la estructura de trabajo
En este documento se han tratado de explicar los conceptos básicos de Java 3D partiendo
de unos ciertos conocimientos previos (no demasiados) del mundo de la informática
gráfica. Se han abordado las distintas ideas centrales de Java 3D sin profundizar demasiado,
pero dando suficientes referencias a manuales y ejemplos como para permitir una
investigación posterior más exhaustiva.
El trabajo comienza con la explicación sencilla de los conceptos más generales para
profundizar posteriormente, primero en la parte relativa a la rama de contenido del grafo de
escena (los distintos elementos que se pueden utilizar para componer una escena) y,
posteriormente, en la rama de visualización (en la que se explican las distintas opciones de
visualización que proporciona Java 3D.
No se han añadido fragmentos de código ya que, aunque podrían resultar
aclaratorios, alargarían demasiado el presente documento (para compensar la ausencia de
8

código, se incluye una sección de recursos en la que se pueden encontrar tanto manuales y
documentación como variados ejemplos).
9

13.2 CONCEPTOS GENERALES
Un universo virtual de Java 3D se crea a partir de un grafo de escena.
Una definición habitual de grafo es una estructura de datos compuesta de nodos y
arcos. Un nodo es un elemento de datos y un arco es una relación ente elementos de datos.
Los nodos del grafo de escena se corresponden con instancias de clases Java 3D. Los arcos
representan dos tipos de relaciones entre las instancias de Java 3D. La relación más habitual
es la relación padre-hijo. Un nodo grupo puede tener varios hijos, pero sólo un padre. Un
nodo hoja puede tener un padre, pero no hijos. La otra relación es la referencia. Una
referencia asocia un objeto del tipo NodeComponent con un nodo del grafo de escena. Los
objetos NodeComponent definen tanto la geometría como los atributos de apariencia que se
utilizan para renderizar los objetos visuales. Los grafos de escena de Java 3D se construyen
utilizando objetos Node unidos por relaciones padre-hijo formando una estructura de árbol.
En una estructura de árbol, un nodo es la raíz. Se puede acceder al resto de los nodos del
árbol siguiendo los arcos que parten del nodo raíz. Los arcos de un árbol no forman ciclos.
Un grafo de escena está formado por árboles cuya raíz se sitúa en los objetos Locale. Los
NodeComponent y los arcos de referencia no forman parte, realmente, del árbol del grafo de
escena. Existe sólo un camino desde la raíz de un árbol hasta cada una de las hojas, de igual
forma, sólo hay un camino desde la raíz de un grafo de escena hasta cada uno de los nodos
hoja. El camino desde la raíz de un grafo de escena hasta un nodo hoja en particular se
llama el camino de escena de ese nodo hoja. Por lo tanto, teniendo en cuenta la propiedad
antes descrita, cada nodo hoja tiene sólo un camino de grafo de escena. Cada camino de
grafo de escena en Java 3D especifica completamente la información del estado de su hoja.
La información del estado incluye datos como la localización, orientación y tamaño de un
objeto visual. Por lo tanto, los atributos de cada objeto visual dependen directamente de su
camino de grafo de escena. El renderizador de Java 3D utiliza esta propiedad y renderiza
las hojas en el orden que él determina que es más eficiente. El programador de Java 3D no
tiene control sobre el orden en que se renderizan los distintos objetos.
Las representaciones gráficas de los grafos de escena sirven como herramienta de
desarrollo así como de documentación para los programas de Java 3D. Los grafos de escena
se crean utilizando la simbología mostrada en la Figura 13.2. Los programas de Java 3D
pueden tener muchos más objetos que los que se muestran en el grafo de escena. Para
diseñar un universo virtual de Java 3D se dibuja un grafo de escena utilizando el conjunto
habitual de símbolos. Una vez el programa se ha escrito, el grafo de escena creado es la
representación precisa del programa siempre y cuando se hayan seguido las
especificaciones indicadas por el mismo.
10

Figura 2 - Notación empleada en los grafos de escena
Los símbolos de la columna de la izquierda representan los distintos objetos que se
usan en el grafo de escena. Los dos primeros se corresponden con objetos de clases
específicas: VirtualUniverse y Locale. Los tres símbolos siguientes representan objetos de
las clases Group, Leaf y NodeCompoent. Estos tres símbolos suelen llevar anotaciones para
indicar la subclase a la que pertenece el objeto en cuestión. El último símbolo de la
izquierda se utiliza para representar cualquier otro tipo de objeto.
Por otro lado, los símbolos de la derecha representan los arcos que indican la
existencia de relaciones. La flecha convencional representa una relación padre-hijo entre
dos objetos. Y, la flecha sombreada, referencia otro objeto. Los objetos que son
referenciados se pueden compartir entre diferentes ramas del grafo de escena.
13.2.1 Objetos del grafo de escena
En la Figura 13.3, aparece el esqueleto general de un grafo de escena básico. En él aparecen
prácticamente todos los elementos que se utilizan para crear un grafo de escena. Dichos
elementos se enumeran a continuación y se explicarán con más detalle en los siguientes
apartados del trabajo.
11

Figura 3 - Estructura general de un grafo de escena
13.2.1.1 Objetos de la superestructura del grafo de escena
Java 3D define dos objetos de superestructura del grafo de escena, VirtualUniverse y
Locale, que se utilizan para contener los distintos subgrafos que forman el grafo de escena.
Objeto VirtualUniverse. Un objeto VirtualUniverse consiste en una lista de objetos
Locale que contienen una serie de nodos del grafo de escena que existen en el
universo. Normalmente, las aplicaciones sólo necesitan un universo virtual, incluso
las bases de datos virtuales muy grandes. Las operaciones sobre este objeto incluyen
la enumeración de los distintos objetos Locale que contiene.
Objeto Locale. El objeto Locale contiene un conjunto de subgrafos del grafo de
escena cuya raíz se corresponde con un nodo del tipo BranchGroup. Un objeto
Locale también define la localización del universo virtual utilizando coordenadas de
alta resolución (HiResCoord) para especificar la posición. El HiResCoord se utiliza
como el origen de todos los objetos del grafo de escena contenidos en el Locale. Un
objeto Locale no tiene padre en el grafo de escena, pero se une de forma implícita a
un universo virtual cuando se construye. Un objeto Locale puede referenciar un
número arbitrario de nodos BranchGroup, pero no tiene hijos explícitos. Las
coordenadas de todos los objetos del grafo de escena son relativas al HiResCoord
del Locale en el que se encuentran. Las operaciones del objeto Locale incluyen
establecer y obtener el HiResCoord y añadir y eliminar subgrafos.
12

13.2.1.2 Objetos de agrupación de nodos
Los nodos de agrupación son los elementos de unión que se utilizan para construir un grafo
de escena. Todos los nodos de agrupación pueden tener un número variable de nodos hijos
incluyendo otros nodos de agrupación y nodos hoja. Estos hijos tienen un índice asociado
que permite realizar operaciones sobre un hijo en particular. Sin embargo, salvo que se
utilice alguno de los nodos de agrupación ordenados especiales, el renderizador de Java 3D
puede renderizar los hijos de un nodo de agrupación en el orden que considere más
oportuno (incluso puede renderizar varios hijos en paralelo).
Nodos Group. Los objetos Group son nodos de agrupación de propósito general.
Tienen un solo padre y un número arbitrario de hijos. Entre las operaciones que
proporciona este objeto están las de añadir, eliminar y enumerar los hijos del grupo.
Las subclases de este objeto añaden semánticas adicionales.
Nodos BranchGroup. Un nodo BranchGroup es la raíz de un subgrafo de una
escena que puede compilarse como una unidad, unirse a un universo virtual o
incluirse como hijo de un nodo de agrupación en otro subgrafo.
Un subgrafo, cuya raíz sea un nodo de este tipo puede imaginarse como una unidad
de compilación a la que se le pueden realizar las siguientes acciones:
o Se puede compilar invocando a su método de compilación. Esta operación hará
que se compile el subgrafo completo así como cualquier otro nodo de tipo
BranchGroup contenido en dicho subgrafo (además de todos sus descendientes).
o Se puede insertar dentro de un universo virtual conectándolo con un objeto
Locale. Entonces se dice que el subgrafo completo está vivo.
o Se puede desconectar el BranchGroup del subgrafo al que está contenido en
tiempo de ejecución, siempre y cuando se den las condiciones necesarias para
poderlo hacer (las capacidades se analizan en el apartado Concepto de límite).
También se le puede cambiar de padre.
Si un BranchGroup se encuentra dentro de un subgrafo, como hijo de algún otro
nodo de agrupación, no se puede unir a un Locale.
Nodos TransformGroup. Los nodos TransformGroup especifican una
transformación espacial sencilla utilizando un objeto Transform3D que puede
colocar, orientar y escalar todos sus hijos. La transformación especificada tiene que
ser tal que se pueda realizar en los objetos en los que se va a aplicar. Si un nodo
TransformGroup se utiliza como antecesor de un nodo ViewPlatform en el grafo de
escena, entonces la transformación tiene que ser congruente, es decir, sólo se
pueden realizar rotaciones, traslaciones y escalados uniformes en un camino directo
desde un Locale hasta un nodo ViewPlatform. De todas formas, si se intenta realizar
13

una transformación no permitida, se generaría una excepción del tipo
BadTransformException.
Los efectos de las transformaciones en el grafo de escena son acumulativos. La
concatenación de las transformaciones de cada TransformGroup en un camino
directo desde el Locale hasta un nodo hoja define un modelo de transformación que
toma los puntos de las coordenadas locales del nodo hoja y los transforma en
coordenadas de mundo virtual. Este modelo de transformación se utiliza para
transformar puntos, normales y distancias en coordenadas de mundo virtual.
13.2.1.3 Objetos nodos hoja
Los nodos hoja (Leaf) forman una clase abstracta para todos los nodos del grafo de escena
que no tienen hijos. Proporcionan enlaces espaciales y capacidades de instanciación para
compartir grafos de escena. Proporcionan también una plataforma de visión para colocar y
orientar los objetos en un punto de vista dentro del mundo virtual.
Nodos Shape3D. La clase Shape3D da soporte a la creación de objetos geométricos.
Contiene dos componentes: una referencia a la forma geométrica y a su componente
de apariencia. El objeto de geometría define los datos geométricos de la forma,
mientras que el objeto de apariencia especifica los atributos de apariencia del objeto
como pueden ser color, material, textura, etc.
Nodos ViewPlatform. Los nodos ViewPlatform definen una plataforma de
visualización que se referencia mediante un objeto View. La posición, orientación y
escala de las transformaciones desde el grafo de escena hasta el nodo ViewPlatform
especifican la localización del punto de vista y hacia qué dirección está orientado.
Un observador puede deambular por una escena cambiando las transformaciones en
la jerarquía del grafo de escena por encima del ViewPlatform.
Nodos Behavior. Los nodos hoja Behavior permiten que una aplicación modifique
el grafo de escena en tiempo de ejecución. Behavior es una clase abstracta que
define propiedades comunes a todos los objetos de comportamiento de Java 3D.
Hay varios comportamientos predefinidos que son subclases de Behavior. Además,
el usuario puede redefinir estos objetos si lo considera preciso.
Nodo BoundingLeaf. Define una región limitada que puede ser referenciada por
otros nodos para definir una región de influencia (nodos Fog y Light), una región de
activación (nodos de Background, Clip y SoundScape) o una región de planificación
(nodos Sound y Behavior). La región limitada se define en el sistema de
coordenadas local del nodo BoundingLeaf. Se puede utilizar una referencia a este
nodo en lugar de a los límites de un objeto de alguno de los nodos antes
mencionados.
Este nodo permite a la aplicación especificar una región limitada en un sistema de
coordenadas diferente del sistema de coordenadas local del objeto que referencia los
14

límites. Es decir si, por ejemplo, en una habitación hay varias luces, los límites
aplicados a las distintas luces se corresponderán siempre con la habitación,
independientemente del movimiento de las propias luces. Así, utilizando un objeto
de este tipo, no es necesario aplicar coordenadas de límites distintas para cada
objeto de iluminación (ya que cada uno tendría su propio sistema de coordenadas),
sino que todos los límites se aplicarían en función del objeto BoundingLeaf.
Nodo Background. Este nodo define un fondo para la aplicación. Este fondo puede
ser, bien un color fijo o una imagen que se utiliza para rellenar la ventana utilizada.
También especifica a la aplicación la región en que el nodo Background está activo.
Un nodo de este tipo está activo cuando la región de la aplicación intersecta con el
volumen de activación del ViewPlatform. Si hay varios nodos Background activos,
se utiliza el que esté más cercano al ojo, y si no hay ninguno activo, el fondo de la
ventana se pinta de negro.
Nodo Fog. Se trata de una clase abstracta que define un conjunto de atributos
comunes que controlan la niebla de la escena. Entre dichos atributos se encuentran
el color de la niebla y un objeto de límites que especifica la región de la influencia
del nodo de niebla. Todos los objetos que intersectan con la región de influencia del
objeto de niebla modifican su color (para aplicarle la niebla) una vez aplicadas las
luces y texturas.
o Nodo ExponentialFog. Extiende el nodo Fog añadiéndole una densidad de
niebla que se usa como exponente de la ecuación de niebla. La densidad se
define en el sistema de coordenadas local del nodo, aunque la ecuación de
niebla se referirá a las coordenadas del ojo.
o Nodo LinearFog. Extiende el nodo Fog añadiendo un par de valores de
distancia en el eje z que indican el punto en que la niebla debe comenzar a
oscurecer la escena y en el que debe oscurecerla completamente.
Nodo Light. Es una clase abstracta que define las propiedades comunes a todos los
nodos de luz. Cada luz tiene asociado un color, un estado (encendida o apagada) y
un objeto de límites que especifica la región de influencia de la luz. El modelo de
iluminación de Java 3D se basa en un subconjunto del modelo de iluminación de
OpenGL. Sobre el tema de luces se vuelve en el apartado Luces.
Nodo Sound. Es también una clase abstracta que define las propiedades comunes de
todos los nodos de sonido. Un grafo de escena puede contener varios elementos de
sonido. Cada nodo de sonido contiene una referencia a los datos de sonido, un factor
de escala de amplitud, un flag que indica si el sonido asociado con el objeto debe
reproducirse hasta que se acaba o sólo hasta que se desactive el objeto, el número de
veces que debe repetirse, un estado (si está activado o no), una región de influencia,
una prioridad, etc. Siempre que el usuario se encuentre dentro de los límites de
influencia del sonido, este será potencialmente audible.
15

o Nodo BackgroundSound. Define una fuente de sonido sin atenuación que no
tiene ni posición ni dirección. Tiene los mismos atributos que el nodo Sound. Se
utilizan como sonidos de ambiente y puede haber varios activos a la vez.
o Nodo PointSound. Define un sonido cuyas ondas se emiten en todas las
direcciones desde su localización. Se añaden a los parámetros del nodo Sound,
la localización y el grado de atenuación con la distancia.
o Nodo ConeSound. Define un nodo PointSound cuyo sonido está dirigido a lo
largo de un vector en el espacio. El sonido se atenúa tanto a lo largo como en un
cierto ángulo también definido.
Nodo Morph. Este nodo permite que una aplicación realice morphings entre
diferentes matrices de geometría. Este nodo contiene un único nodo de apariencia y
una matriz de matrices de geometría, con un peso para cada una. El nodo Morph
combina todas estas matrices en una forma mezcla de todas en función del peso
asignado a cada una.
Nodo Link. Este nodo permite que la aplicación referencia un subgrupo compartido,
cuya raíz es un nodo SharedGroup, dentro de una rama del grafo de escena. Varios
nodos Link pueden referirse a un mismo nodo SharedGroup.
Las nieblas, el sonido y el morphing no son objeto de este trabajo, ya que se trata de
elementos que se pueden considerar avanzados dentro del mundo 3D. Para conocer más
sobre estos aspectos acudir a (Sun Microsystems, 1999).
13.2.2 Otros objetos implicados
Los objetos del grafo de escena analizados hasta ahora son los que realmente se consideran
parte de dicho grafo de escena. Pero, además de estos nodos, existen otros que permiten
incluir información adicional y esencial en dicha estructura de árbol.
El primer grupo de estos elementos son los que permiten configurar la rama de
visualización y que se unen al objeto ViewPlatform. Estos objetos son Canvas3D,
Screen3D, View, PhysicalBody y PhysicalEnvironment. De forma breve, ya que se
describirán con más detalle en el apartado 4, se comentan a continuación:
View. Este es el objeto principal de visualización ya que es el que determina toda la
información necesaria para generar la escena 3D. Contiene diferentes elementos del
estado de visualización.
Canvas3D. Es la versión 3D del objeto Canvas de AWT. Representa una ventana en
la que Java 3D dibujará las imágenes. Contiene una referencia a un objeto Screen3D
e información que describe el tamaño forma y localización dentro del objeto
Screen3D del objeto Canvas3D.
16

Screen3D. Es un objeto que contiene información relativa a las propiedades físicas
de la pantalla. Java 3D separa la información relativa a la pantalla en un objeto
independiente para evitar la duplicación de información sobre la pantalla, en caso de
que varios objetos Canvas3D compartan una sola pantalla.
PhysicalBody. Se trata de un objeto que contiene información de calibración relativa
al cuerpo físico del usuario.
PhysicalEnvironment. Este objeto contiene información de calibración del mundo
físico.
El segundo grupo de objetos adicionales son los objetos NodeComponent. Estos
objetos no formar parte de la estructura de árbol, pero son esenciales para generar
contenidos. De hecho, son los responsables, entre otras cosas, de que una figura tenga una
cierta geometría bajo una cierta apariencia (color, textura...) Los objetos NodeComponent
se asocian a través de relaciones de referencia con objetos Leaf para los cuales define la
apariencia y la geometría. Las características de estos nodos se analizan con más detalle en
los apartados Construcción de elementos geométricos y Modificación de apariencia.
13.2.3 Construcción de un árbol
Las subclases del objeto SceneGraph son los elementos que se unen para formar los grafos
de escena. El procedimiento básico para desarrollar un programa en Java 3D consiste en
siete pasos:
1. Crear un objeto Canvas3D.
2. Crear un objeto VirtualUniverse.
3. Crear un objeto Locale y unirlo al objeto VirtualUniverse.
4. Construir la rama de visualización del grafo.
a. Crear un objeto View.
b. Crear un objeto ViewPlatform.
c. Crear un objeto PhysicalBody.
d. Crear un objeto PhysicalEnvironment.
e. Unir los objetos ViewPlatform, PhysicalBody, PhysicalEnvironment y
Canvas3D al objeto View.
5. Construir la(s) rama(s) de contenido del grafo.
6. Compilar la(s) rama(s) del punto anterior.
7. Insertar los distintos subgrafos en el Locale.
Aunque no profundiza demasiado, esta receta sí refleja el concepto fundamental de
la programación en Java 3D: el grueso de la programación consiste en la creación de las
distintas ramas del grafo de escena.
17

13.2.3.1 Grafos de escena ilegales
Se pueden crear grafos de escena ilegales, un ejemplo de ello es la Figura 13.4. Dicho grafo
de escena es ilegal porque hay dos objetos TransformGroup que tienen un mismo objeto
hoja Shape3D como hijo. Un objeto hoja sólo puede tener un padre, sólo puede haber un
camino desde un objeto Locale hasta un objeto hoja.
Puede parecer que en la estructura de la figura se definen tres objetos del universo
virtual. Si consideramos que el objeto Shape3D se reutiliza, el grafo de escena puede
definir dos objetos visuales. Sin embargo, no es un árbol legal porque los arcos de relación
padre-hijo no forman un árbol.
Figura 4 - Grafo de escena ilegal
En la Figura 13. 5 se muestra una posible corrección a la estructura de árbol ilegal.
18

Figura 5 - Posible corrección del grafo de escena ilegal
Un programa en Java 3D que define un grafo de escena ilegal puede compilarse,
pero la imagen que define no puede generarse. Cuando se ejecuta un programa Java 3D que
contiene un grafo de escena ilegal, el sistema de Java 3D detecta el problema y, entonces,
genera una excepción. El programa se seguirá ejecutando, y será necesario detenerlo, pero
no se generará ninguna imagen.
13.2.4 Sistema de coordenadas
Los sistemas de coordenadas en Java 3D son, por defecto “diestros”, de tal forma que la
parte positiva del eje de ordenadas es el sentido ascendente de la gravedad, la parte positiva
del eje de abscisas es horizontal hacia la derecha y la parte positiva del eje z está dirigido
hacia el observador.
La unidad utilizada por defecto son los metros. En la siguiente figura, se puede ver
gráficamente esta distribución.
Figura 6 - Tipos de sistemas de coordenadas
19

13.2.4.1 Coordenadas de alta resolución
La representación de las coordenadas con valores en punto flotante de doble precisión, de
simple precisión o incluso valores de menor precisión es suficiente para representar y
mostrar escenas en tres dimensiones de gran calidad. Si nos alejamos doscientos kilómetros
desde el origen de coordenadas utilizando una precisión sencilla de punto flotante, los
puntos representables aparecen de alguna forma discretizados. Si lo que se pretende es
llegar a distancias muy pequeñas, muy cerca del origen, aparece el mismo problema.
Las coordenadas de alta resolución de Java 3D constan de 3 números de 256 bits de
punto fijo, uno para cada eje. El punto fijo se encuentra en el bit 128 y el valor 1.0 se
corresponde exactamente con un metro. Este sistema de coordenadas es suficiente para
describir un universo tan enorme como varios cientos de billones de años luz o como para
definir objetos tan pequeños como un protón.
En la Tabla 13.1 se representan cuántos bits son necesarios bien por encima o por
debajo del punto fijo para representar el rango que nos interese.
2 n Metros Unidades
87.29 Universo (20 billones de años luz)
69.68 Galaxia (100000 años luz)
53.07 Año Luz
43.43 Diámetros del Sistema Solar
23.60 Diámetro de la Tierra
10.65 Milla
9.97 Kilómetro
0.00 Metro
-19.93 Micra
-115.57 Longitud de Planck
Tabla 1 - Escala de las coordenadas de alta resolución
Los números de punto fijo de 256 bits proporcionan también la ventaja de ser
capaces de representar directamente, de forma exacta, cualquier valor de precisión sencilla
de punto flotante.
Las coordenadas de alta resolución de Java 3D se utilizan sólo para incluir los
sistemas de coordenadas tradicionales de punto flotante en un sistema de mucha mayor
resolución. De esta forma se pueden crear universos de cualquier tamaño imaginable sin
preocuparnos de la precisión.
Las coordenadas de alta resolución se representan como números de 256 bits con
signo en complemento a dos. Aunque Java 3D mantiene oculta la representación interna de
las coordenadas de alta resolución, el usuario debe especificar dichas coordenadas usando
matrices de enteros de 8 elementos. Java 3D trata el entero en la posición 0 como los bits
más significativos y el situado en la posición 7 como los menos significativos de la
20

coordenada de alta resolución. El punto binario se localiza en el bit 128 o entre los enteros
de las posiciones 3 y 4.
La forma en que los cargadores de ficheros manejan las coordenadas de alta
resolución depende de cada cargador en concreto, ya que Java 3D no define directamente
ninguna semántica de carga de ficheros. Sin embargo, hay ciertas consideraciones que
pueden indicarse.
Para universos pequeños (del orden de cientos de metros), un solo Locale con
coordenadas de alta resolución ubicado en la posición (0.0, 0.0, 0.0) como el nodo raíz es
suficiente. Un cargador puede construir automáticamente este nodo durante el proceso de
carga ya que las coordenadas de alta resolución no necesitan tener una representación
directa en el fichero externo. Universos virtuales de mayor tamaño se suelen construir
siguiendo la jerarquía habitual de directorios de cualquier disco duro, es decir, un universo
virtual raíz que contiene la mayoría de las referencias a ficheros externos que incluyen
universos virtuales. En este caso, el objeto que contiene la referencia al fichero define la
localización de los datos que se tienen que leer en el universo virtual en cuestión.
El contenido de los ficheros de datos debe enlazarse al nodo – fichero mientras se
leen, heredando así las coordenadas de alta resolución del objeto como el nuevo universo
virtual origen del grafo de escena embebido. Si ese mismo grafo de escena contiene a su
vez coordenadas de alta resolución, tendrán que ser trasladadas en la cantidad que indiquen
las coordenadas de alta resolución del objeto – fichero y entonces añadidas al universo
virtual mayor como nuevas coordenadas de alta resolución, con todo su contenido por
debajo de las mismas.
A la hora de tratar con objetos que se mueven con gran amplitud, hay que
considerar que tendrán que cambiar periódicamente su Locale padre de forma que se adapte
más adecuadamente a sus nuevas coordenadas. Si no existiera ningún Locale
suficientemente apropiado, la aplicación podría crear uno nuevo.
13.2.5 Modos de renderización
Java 3D proporciona tres modos diferentes de renderización: modo inmediato, modo
retenido y modo compilado-retenido. Cada modo proporciona, sucesivamente, mayor
libertad para optimizar la ejecución de la aplicación. Las características de la mayor parte
de las aplicaciones provocan que los dos últimos métodos sean los más utilizados.
Modo inmediato. El modo inmediato no permite mucha optimización en cuanto al
grafo de escena se refiere. En este modo, el nivel de abstracción de Java 3D es
bastante elevado y acelera el renderizado inmediato de los objetos. Una aplicación
debe proporcionar un método de dibujado con un conjunto completo de puntos,
líneas o triángulos que son posteriormente renderizados por el generador de
imágenes de alta velocidad de Java 3D. Por supuesto, la aplicación puede construir
estas listas de puntos, líneas o triángulos en cualquier forma que elija.
21

Este modo de renderización permite la mayor flexibilidad y libertad a costa de una
reducción en el rendimiento. Java 3D no dispone, en este modo, de información
acerca de los objetos gráficos de la composición. Debido a esa ausencia de
información, Java 3D apenas puede realizar optimizaciones en la aplicación del
programador.
El programador puede utilizar o no la estructura de grafo de escena heredada del
diseño de Java 3D; puede elegir entre dibujar la escena directamente o definir el
grafo de escena.
El modo inmediato puede utilizarse tanto de forma independiente como combinado
con los otros dos métodos existentes.
Modo retenido. El modo retenido requiere que la aplicación construya un grafo de
escena y que especifique qué elementos de dicho grafo de escena pueden cambiar
durante la renderización. El grafo de escena describe los objetos del universo
virtual, la distribución de dichos objetos y cómo la aplicación los anima.
Este modo proporciona gran parte de la flexibilidad del modo inmediato a la vez
que un incremento sustancial en la velocidad de renderización. Todos los objetos
definidos en el grafo de escena son accesibles y manipulables, como lo es el grafo
de escena en sí mismo.
El programador puede crear grafos de escena y añadir o eliminar nodos del mismo
rápidamente y ver inmediatamente los efectos de dichos cambios. Este modo
permite construir objetos, insertarlos en una base de datos, componer objetos y
añadir comportamientos a los objetos. Java 3D sabe que el programador ha definido
objetos, sabe cómo ha combinado dichos objetos para crear objetos compuestos o
grafos de escena y también conoce qué comportamientos o acciones se han añadido
a los objetos. Todo este conocimiento permite a Java 3D realizar diferentes
optimizaciones; puede construir estructuras de datos especiales que contengan la
geometría de los objetos de tal forma que se aumente la velocidad a la que puede
renderizarlo. Puede también compilar los comportamientos de los objetos para que
se ejecuten a una mayor velocidad cuando sean invocados.
Modo compilado-retenido. Este modo, al igual que el retenido, requiere que la
aplicación construya un grafo de escena y que especifique qué elementos pueden
cambiar durante la renderización. Además, la aplicación puede compilar parte o
todos los subgrafos que forman el grafo de escena completo. Java 3D compila estos
grafos en un formato interno. La representación compilada del grafo de escena
apenas se parece a la estructura de árbol original proporcionada por la aplicación,
sin embargo, es funcionalmente equivalente. Este modo es el que proporciona el
mejor rendimiento.
22

Este modo permite que la API de Java 3D realice una serie de complicadas
optimizaciones. Un programador puede solicitar que Java 3D compile un objeto o
un grafo de escena. Un objeto o un grafo de escena compilado consiste en
cualesquiera estructuras que Java 3D quiera crear para asegurar que los objetos o
grafos de escena se renderizan a la máxima velocidad posible. Como Java 3D sabe
que la mayor parte de los objetos o grafos de escena compilados no van a cambiar,
puede realizar múltiples optimizaciones como pueden ser la fusión de múltiples
objetos en un objeto conceptual, modificar un objeto para disponer de él en una
geometría comprimida o incluso romper un objeto en diferentes partes y
reensamblarlo en nuevos “objetos conceptuales”.
13.2.6 Paquetes Java 3D
Todos los programas de Java 3D se forman, al menos parcialmente, uniendo distintos
elementos de la jerarquía de clases de Java 3D. Esa gran colección de objetos describe un
universo virtual, que será el que posteriormente se renderizará. La API define más de cien
clases incluidas en el paquete javax.media.j3d. Estas clases son las normalmente
denominadas como clases núcleo de Java 3D. Hay cientos de campos y métodos en dichas
clases, sin embargo, un universo virtual sencillo que contenga algo de animación se puede
construir con sólo unas pocas de ellas.
Además del paquete núcleo, a la hora de desarrollar programas en Java 3D se utilizan otros
paquetes. Uno de ellos es el paquete normalmente conocido como de utilidad
(com.sunj3d.utils).
El paquete núcleo incluye sólo las clases de nivel más bajo necesarias para
programar en Java 3D. Las clases de utilidad son extensiones muy prácticas y potentes.
Como era de esperar, la utilización de clases de utilidad reduce significativamente el
número de líneas de código a la hora de programar.
Por último, también se utilizan clases del paquete java.awt y del paquete
javax.vecmath. Las clases AWT crean una ventana para mostrar la renderización. El
segundo paquete define clases matemáticas de vectores para puntos, vectores, matrices y
otros objetos matemáticos.
23

13.3 MODELO DE CONTENIDOS
Como ya se ha visto en los apartados anteriores, un programa en Java 3D presenta una
estructura de árbol con dos ramas bien diferenciadas. La primera de ellas es la rama de
contenidos, que establece qué se muestra al espectador y el aspecto de dichos objetos. La
otra rama es la de visualización 1 .
Esta última determina los parámetros de visualización tales como la localización de
la vista y la dirección. Para facilitar el abordar la parte de contenidos del árbol, se va a
abstraer la parte correspondiente a la rama de visualización.
En este apartado, se abordan los distintos mecanismos proporcionados por Java 3D
para la construcción de figuras geométricas, así como otros mecanismos interesantes como
los cargadores de escena. Por último, este apartado se centra en los aspectos de interacción
con el usuario y animación de escenas 3D. Esta sección se complementa con una serie de
ejemplos disponibles en el CD – ROM en el directorio ejemplos.
13.3.1 Sistemas de coordenadas y paquete javax.vecmath
Antes de empezar a describir cómo generar contenidos dentro de un universo virtual, es
necesario introducir al lector en un paquete de utilidad que permite gestionar la situación
física de los elementos dentro del universo (las coordenadas dentro del sistema cartesiano),
además de otros aspectos esenciales en un universo 3D (color, textura...). Este paquete se
denomina javax.vecmath.
Como ya se ha mencionado con anterioridad, una representación 3D no es más que
una secuencia de puntos dentro de un sistema de coordenadas cartesianas. Para facilitar la
forma de establecer la situación exacta de estos puntos se proporcionan las clases de este
paquete.
Los nombres de las clases de este paquete siguen la norma de indicar el número de
componentes que necesitan y el tipo de dichas componentes (b – byte, d – double, f – float).
1 Si el lector desea ir investigando los conceptos relativos a la rama de contenidos de forma
paulatina (para ellos se aconseja acudir a la bibliografía), podrá abstraerse de la rama de
visualización y centrarse en la rama de contenidos gracias a una clase de utilidad que
proporciona Java 3D. Esta clase es la que se denomina SimpleUniverse y se encuentra en el
paquete com.sun.j3d.utils.universe. Gracias a esta clase el usuario podrá crear universos
virtuales con una mínima configuración de la rama de visualización. Si lo prefiere, puede
empezar por el apartado 4 y centrarse en los detalles de la rama de visualización, aunque
esto no se aconseja.
24

En la figura adjunta puede verse la estructura jerárquica de clases que constituyen este
paquete.
Figura 7 - Jerarquía de clases del paquete javax.vecmath
Dentro de este paquete, las clases que realmente se utilizan para la situación de
elementos dentro del universo son las clases Point* 2 , Vector y Quat*. El resto de clases,
Color*, TextCoord* permite especificar aspectos como el color y la textura 3 .
2 El carácter “ *” sustituye a los dos últimos caracteres del nombre de cada clase.
3 Los aspectos de color y textura se analizan más adelante en este documento.
25

Las clases del grupo denominado Point* permiten establecer la posición de cada
uno de los vértices de un objeto. Además, también se utilizan para establecer puntos de luz,
la localización espacial de una fuente de sonido y la posición de otros tipos de elementos.
Estas clases, además, proporcionan métodos que permiten realizar operaciones habituales
dentro de un espacio en tres dimensiones, tales como cálculos de distancia euclídea,
distancia Manhattan... La unidad de medida es el metro.
Las clases Vector* se utilizan, normalmente, para determinar superficies, ya que
también se suelen utilizar para representar la dirección de una fuente de luz o una fuente de
sonido. Esta clase además, proporciona métodos que facilitan las operaciones con vectores,
tales como productos cruzados, normalización, cálculo del ángulo inscrito entre dos
vectores...
Las clases Quat* se utilizan para transformaciones de matrices avanzadas. Se ha
comentado que las clases Color* y TextCoord* permiten definir aspectos de un objeto no
relacionados con su posición física sino con su aspecto externo. Las clases Color* permiten
definir el color y la transparencia. Las clases Color3* permiten definir en color en formato
RGB. Las clases Color4* permiten, además, definir la transparencia que por defecto es
opaca. Las clases TextCoord* se centra en aspectos relativos a la textura de los objetos.
13.3.2 Formas geométricas
Una vez analizado uno de los mecanismos para definir puntos concretos en el
espacio 3D, superficies y otros elementos como el color y la textura, se va a abordar la
forma de crear objetos 3D.
La forma de crear objetos visuales es mediante la clase Shape3D. Esta clase, que
desciende de forma directa de la clase Leaf, puede aparecer únicamente como hoja dentro
de una de las ramas del grafo de contenidos. Esta clase no contiene ninguna información a
cerca de la forma o el color del objeto visual. Estos aspectos se definen a través de los
objetos NodeComponent. A través de este tipo de nodos, se va a poder definir la geometría
(clase Geometry y sus descendientes) y la apariencia (clase Appearance y sus
descendientes) del objeto visual.
Para definir un objeto 3D únicamente es necesario definir la geometría de dicho
objeto, ya que se define una apariencia de forma automática.
Una vez creado el objeto Shape3D y definidas sus características geométricas y de
apariencia, se añade a la rama de contenidos, con lo que ya puede ser visualizado.
En los siguientes apartados, se verá como utilizar los elementos geométricos predefinidos
en la distribución de Java 3D, así como los mecanismos para definir la geometría de objetos
3D creado por el programador.
26

13.3.2.1 Formas geométricas predefinidas
Dentro del paquete com.sun.j3d.utils.geometry se proporcionan una serie de elementos 3D
comunes en universos 3D, como son cajas (Box), conos (Cone), cilindros (Cylinder) y
esferas (Sphere).
Existe una quinta estructura geométrica, ColorCube, que muestra un cubo con cada
una de sus caras coloreadas y con efectos de luz ya establecidos. Esta clase está situada en
un punto diferente de la jerarquía de objetos, de hecho es un descendiente de la clase
Shape3D.
Estas figuras geométricas predefinidas no son más que objetos con un
NodeComponent asociado que define su geometría y que no se puede cambiar, aunque
algunos de sus parámetros se pueden configurar. Ninguna de estas estructuras, salvo
ColorCube, define ningún tipo de apariencia, y por lo tanto debe ser configurada por el
programador. En el caso del objeto ColorCube, tanto geometría como apariencia ya están
predefinidas y no pueden ser alteradas, salvo el tamaño del cubo.
Figura 8 - Jerarquía de clases para las figuras geométricas predefinidas
El objetivo de estos cinco tipos de objetos es proporcionar un mecanismo rápido
para crear contenidos en tres dimensiones con poco esfuerzo de programación. Así, son
muy utilizadas, sobre todo, a la hora de realizar prototipos 3D de forma rápida y simple.
La clase Box define un cubo 3D de dimensiones 2metros x 2metros x 2metros cuyos
vértices se localizan en (-1, -1, -1) y (1, 1, 1). Tanto las dimensiones como la situación de
27

los vértices es configurable en el momento de creación del cubo. Esta configurabilidad es
una tónica para todas las figuras predefinidas aquí comentadas.
La clase Cone define un cono centrado en el origen de coordenadas y alineado a lo
largo del eje de ordenadas. El radio por defecto es de un metro y la altura del cono es de
dos metros. Al igual que sucedía con la clase Box, tanto la altura como el radio son
configurables.
La clase Cylinder crea un cilindro con sus extremos cerrados y centrado en el origen
de coordenadas y con su eje central a lo largo del eje ordenadas. Las dimensiones por
defecto son de 1 metro para el radio y de 2 metros de altura.
La clase Sphere muestra una esfera centrada en el origen y de radio 1.
En la página de recursos pueden encontrarse ejemplo del uso de alguna de estas
primitivas. Así en el ejemplo HelloJava3D/HelloJava3Dc.java se construye y anima un
ColorCube. En el ejemplo Geometry/ConeYoyoApp.java se construye un yoyo con el uso
de dos objetos Cone. El resto de primitivas se utilizan de forma muy similar.
13.3.2.2 Construcción de elementos geométricos
La forma de generar contenido 3D hasta este momento se puede considerar simple pero
poco potente.
Para construir figuras más complejas es necesario establecer punto a punto todos los
vértices que lo forman y establecer, una a una, todas sus características. De hecho, la
construcción de figuras 3D complejas se basa en la construcción de triángulos, y en la
disposición conjunta de éstos (básicamente, los puntos del espacio se van a agrupar en
triángulos para formar volúmenes).
Tanto la especificación de la localización de un punto en el espacio, como la
definición de otras características (color, textura...), se realiza a través de lo que se
denomina notación basada en vértices, es decir todas las características se definen mediante
vectores de tres o cuatro componentes, como si de puntos del espacio se tratara.
Es en este punto, donde entra en escena la clase Geometry y todas sus subclases que
van a permitir este tipo de diseño, facilitando en gran medida este trabajo. El lector no debe
perder de vista que estas clases son del tipo NodeComponent y que no tienen ningún
sentido sino se asocian a un objeto Shape3D que es el que realmente establece el objeto
visual y es el que se incluye dentro de la rama del grafo de contenidos.
La jerarquía de clases, tal y como puede verse en la siguiente figura, es
considerable.
28

Figura 9 - Jerarquía de clases para la clase Geometry
A continuación, se analizarán cada una de las clases.
Clase GeometryArray
Las subclases de esta clase van a permitir definir un conjunto de puntos, así como la forma
en que esos puntos se conectan entre sí formando rectas y superficies. De esta manera, se va
definiendo la morfología de la figura 3D.
La clase GeometryArray es una clase abstracta, lo que significa que no puede ser
instanciada de forma directa, sino que debe instanciarse alguna de sus subclases.
Cuando se crea una instancia de una clase descendientes de GeometryArray, se
establece como únicos parámetros, el número de vértices que va a contener el objeto
GeometryArray, y la semántica de dichos puntos. Como se ha comentado en la introducción
de este apartado, todas las características de un objeto se especifican a través de lo que se
denomina formato de vértices (vertex format). Esto no es más que utilizar la misma
notación para configurar las diferentes características de un objeto 3D.
Así, existen los siguientes tipos semánticos para los vértices:
1. COORDINATES: especifica que los vértices contenidos en el vector indican
situación física.
2. NORMALS: especifica que los vértices van a representar una superficie (las
coordenadas definen el vector normal a dicha superficie).
3. COLOR_3 y COLOR_4: indican que los vértices identifican color sin indicar
transparencia e indicando transparencia, respectivamente.
4. TEXTURE_COORDINATE_2 y TEXTURE_COORDINATE_3: especifican
textura en dos dimensiones y tres dimensiones, respectivamente.
Sobre el color y la textura se volverá en los apartados de Luces y Texturas.
29

Creada la clase, es necesario completar la estructura recién creada con los valores en
formato de vértices adecuados. Para ello, la clase GeometryArray proporciona métodos
adecuados para incorporar dicho contenido dependiendo del sentido semántico que se ha
establecido. Un ejemplo de dichas funciones es setCoordinate(int index, Point*
coordinate) 4 que se utiliza habiendo, previamente, activado el bit COORDINATES.
Creado el contenido, se asocia con el objeto visual (Shape3D) a través de los
métodos que proporciona dicha clase.
La clase GeometryArray es una clase abstracta, por lo que es necesario utilizar
alguna de sus subclases. A continuación, se muestran dichas clases y su funcionamiento
básico.
Clases no indexadas
El primer grupo de subclases, denominadas no indexadas, se caracterizan por el
hecho de que cada vez que se dibuja una figura 3D las coordenadas son utilizadas una sola
vez. Cada una de las subclases se diferencia del resto en la forma en la que trata la conexión
de los puntos entre sí.
La primera de ellas es PointArray. Esta clase considera cada uno de los puntos de
forma independiente sin considerar ninguna conexión entre ellos.
La clase LineArray, por el contrario, sí considera conexión entre los puntos.
Considera parejas de puntos y los conecta. Cada punto únicamente puede estar conectado
con otro punto. Así, si se considera cada par de puntos conectados por una recta como un
conjunto, todos los conjuntos son disjuntos dos a dos. Si {v0,…, v5} son los puntos, las
rectas formadas son aquellas limitadas por los pares de puntos {v0, v1}, {v2, v3}, {v4, v5}.
Para ver como considera dichas parejas acuda a la Figura 13. 6. Se puede ver un ejemplo
del uso de esta clase en Geometry/AxisApp.java.
La clase TriangleArray considera grupos de tres puntos para construir triángulos. Al
igual que sucedía con la clase LineArray, cada punto puede únicamente pertenecer a un
triángulo. Si se considera el mismo conjunto de puntos que en el caso anterior los
triángulos que se forma son aquellos cuyos vértices son {v0, v1, v2}, {v3, v4, v5}. Su uso es
muy similar al de la clase LineArray.
La clase QuadArray considera grupos de cuatro puntos para construir cuadriláteros.
Como en los casos anteriores dichos cuadriláteros son disjuntos con respecto al resto.
Tanto los triángulos formados mediante la clase TriangleArray como los
cuadriláteros formados mediante el uso de la clase QuadArray están rellenos por defecto.
4 Acudir a (Sun Microsystems, 1999) para ver el resto de funciones.
30

La clase GeometryStripArray altera la forma de conexión de los puntos. Esta clase
es abstracta con lo que es necesario hacer uso de sus subclases LineStripArray,
TriangleStripArray y TriangleFanArray. El objetivo de estas clases es la construcción de
elementos donde la reutilización de puntos sea un aspecto crucial en su diseño. De esta
manera, van a permitir construir líneas y superficies compuestas.
Haciendo un paralelismo con las clases anteriores, la clase LineStripArray se puede
asemejar a la clase LineArray salvo por el hecho de que el extremo de la recta anterior sirve
de origen para la recta siguiente. Así, considerando el conjunto de seis puntos, las líneas
formadas por la clase LineStripArray son las siguientes {v0, v1}, {v1, v2}, {v2, v3}, {v3, v4},
{v4, v5}.
La clase TriangleStripArray forma triángulos con los puntos de forma que los dos
últimos vértices utilizados para formar el triángulo anterior son utilizados para construir el
siguiente triángulo.
La clase TriangleFanArray posee un comportamiento ligeramente diferente a
TriangleStripArray. Considera el primero de los puntos como el vértice superior de todos
los triángulos. El efecto final se asemeja a un “abanico” (fan), que puede observarse en la
Figura 13.11. Un ejemplo de su utilización se puede ver en el ejemplo
Geometry/YoyoLineApp.java donde se crea un yoyo con esta clase. Este ejemplo también
incluye aspectos relativos con la modificación de la apariencia por defecto. El tema de la
apariencia se aborda en el apartado Apariencia.
En la construcción de objetos de cualquiera de las clases derivadas de
GeometryStripArray, se aprecian diferencias con respecto a la forma de crear los objetos
GeometryArray básicos. En este caso, además de establecer el número de vértices y el
sentido semántico de dichos vértices, existe un tercer parámetro que establece el número de
grupos de conexión (strips) que pueden construirse.
Cada componente indica el número de vértices que van a formar parte de cada
grupo. Por supuesto, la suma de componentes de este vector debe ser igual al número de
vértices indicados en el primer parámetro. Este constructor se puede observar en el ejemplo
anteriormente indicado.
Clases indexadas
El primer grupo de clases se caracteriza por no reutilizar ninguno de sus vértices cada ver
que se redibuja la figura. Únicamente las clases derivadas de GeometryStripArray reutilizan
parcialmente los vértices que contienen. Por el contrario, las clases derivadas de
IndexedGeometryArray proporcionan un nivel más de indirección. Esto permite reutilizar
los vértices, de forma independiente a su situación física dentro del vector de puntos
proporcionado.
Para efectos de la comprensión de estas clases, se van a diferenciar los vectores de
puntos que utilizan en dos grupos: los vectores de datos y los vectores de índices. Los
primeros hacen referencia a los tipos que ya se han visto hasta ahora. Son los que contienen
31

los puntos que identifican coordenadas, color, textura... Los vectores de índices contienen
referencias a los vectores de datos.
Dentro de estos últimos, existen cuatro tipos: los índices de coordenadas, los de
color, superficie y de textura. Nótese que existen tantos tipos de índices como tipos de
vectores de datos. El número de vectores de índices coincide con el de vectores de datos y
el número de componentes dentro de cada vector de índices es, normalmente, mayor que el
número de componentes de los vectores de datos.
Un vector de índices podría tener, en un momento dado, múltiples referencias al
mismo vértice en los vectores de datos. Así, un vector de índices determina el orden de
procesamiento de los datos en los vectores de datos a la hora de mostrar la geometría de la
imagen 3D.
Para comprender cómo funciona, considérese el ejemplo de un cubo. En este caso
los vértices de dicha figura se pueden reutilizar a la hora de dibujar cada cara.
Figura 10 - Ejemplo de creación de un cubo empleando clases indexadas
El problema principal de utilización de este tipo de clases indexadas es el
rendimiento. Así, son muy útiles en entornos donde aspectos como la velocidad y la
memoria no son críticos.
La clase IndexedGeometryArray es una clase abstracta. A partir de ésta, surgen una
serie de subclases que sí pueden ser utilizadas. Estas clases son las que se muestran en la
figura adjunta.
32

Figura 11 - Jerarquía de clases de definición geométrica indexadas
Como puede observarse existe la clase indexada equivalente a la clase no indexada.
El funcionamiento de las clases indexadas, de cara al usuario, es el mismo que el de su
equivalente no indexada, pero la forma de trabajo interna es distinta.
Otras clases
Un tercer grupo de clase relacionadas con la generación de elementos geométrico es el
formado por las clases Raster, CompressedGeometry y Text3D. Esta última clase se analiza
en el apartado Texto 2D y 3D. Las otras dos clases se describen de forma breve a
continuación. Las otras dos clases quedan fuera del alcance de este documento. Para más
información acudir a (Sun Microsystems, 1999).
13.3.2.3 Texto 2D y 3D
Aunque el texto en sí no se puede considerar una forma geométrica, sí es una forma de
incorporar contenido a una escena 3D, y no sólo eso, sino que es un elemento habitual en
universos en tres dimensiones. En este apartado, se mostrará cómo incorporar texto en un
universo 3D y cómo configurar alguno de sus parámetros.
Java 3D considera el texto 2D y 3D de formas diferentes. Mientras el primero es un
objeto descendiente de Shape3D, y por lo tanto, directamente incorporable al grafo de
contenidos, el texto 3D es un NodeComponent y, como tal, necesita de la definición de un
objeto Shape3D para poder utilizarlo.
La clase que da soporte al texto 2D es la clase Text2D presente en el paquete
com.sun.j3d.utils.geometry. Esta clase permite definir no sólo el texto que se desea que
aparezca, sino otros aspectos como color, tipo de fuente, tamaño de la fuente y formato de
dicha fuente. Creado el texto 2D, únicamente queda añadirlo al grafo de escena. Un
ejemplo de uso de texto en dos dimensiones se puede encontrar en
easyContent/Text2Dapp.java 5 .
5 Este ejemplo incluye elementos de animación. La animación se trata en el apartado Movimiento en Java 3D.
33

En cuanto al texto 3D, éste presenta ciertas características adicionales respecto al
texto 2D que requieren más atención. En primer lugar, el texto 3D está pensado como un
NodeComponent y como tal se debe incorporar a un objeto Shape3D. Para incorporar texto
en tres dimensiones son necesarias dos clases adicionales: la clase Font3D y la clase
Text3D. La clase Font3D permite crear una instancia de una fuentes estándar en una fuente
en tres dimensiones. A la fuente planta se le añade una extrusión, es decir profundidad a
través del objeto FontExtrusion.
Una vez creada la fuente 3D, se crea la instancia de la clase Text3D. En el momento
de creación de esta instancia se establece el objeto Font3D anteriormente creado, así como
el texto que se desea mostrar. Además, a través de la clase Text3D se pueden especificar
otros aspectos del texto 3D que se desea mostrar. Estas características son la posición y el
punto de referencia. La posición se refiere al punto concreto dentro del espacio donde se
sitúa el punto de referencia. El punto de referencia establece el punto de origen del objeto.
La orientación y la alineación definen el punto de referencia. En la siguiente figura se
observa el efecto de cada uno de los parámetros.
Figura 12 - Orientación y alineación de un texto 3D
El uso de texto 3D se puede ver en la aplicación easyContent/Text3Dapp.java.
13.3.2.4 Ayudas a la construcción de figuras geométricas
Para crear una figura geométrica es necesario establecer cada uno de los puntos que va a
ocupar en el espacio, y luego generar superficies utilizando dichos puntos (las superficies
son normalmente triángulos). Se ha visto como este trabajo se realiza de forma sencilla a
través de las clases descendientes de GeometryArray. Aún así, la creación de una figura
puede llegar a ser una labor ardua y muy compleja. Para facilitar un poco el trabajo, el API
de Java 3D proporciona un conjunto de clases de utilidad que, a partir del contorno de la
34

figura a construir, realizan los cálculos necesarios para, por ejemplo, generar los triángulos
necesarios para formar el resto de la figura.
Estas clases se encuentran en el paquete com.sun.j3d.utils.geometry.
La clase GeometryInfo funciona como un contenedor de puntos con una
determinada connotación semántica. Cuando se define un objeto de este tipo, se establece la
naturaleza de las superficies a construir con dichos puntos. Así, a través de una serie de
flags, se define si se construirán polígonos (POLYGON_ARRAY), si se construirán
cuadriláteros (QUAD_ARRAY) o triángulos (TRIANGLE_ARRAY,
TRIANGLE_STRIP_ARRAY, TRIANGLE_FAN_ARRAY). A través de los métodos
adecuados se introducen, en la instancia de GeometryInfo las coordenadas de los puntos.
Una vez creada una instancia de la clase GeometryInfo el uso de otras clases van a
permitir realizar nuevas transformaciones sobre los puntos especificados en la primera.
Estas clases son la clase Triangulator, NormalGenerator y Stripifier. Todas ellas van a
tomar como referencia una instancia de la clase GeometryInfo para realizar nuevas
operaciones sobre la matriz de puntos.
La clase Triangulator permite convertir cualquier tipo de polígonos en triángulos
que Java 3D puede procesar. Esta clase trabaja sólo en aquellas circunstancias en las que la
clase GeometryInfo se define utilizando el flag POLYGON_ARRAY.
La clase NormalGenerator se encarga de calcular y rellenar superficies normales a
partir de los puntos del objeto GeometryInfo. Esta transformación se basa en el uso de datos
indexados. En el caso de que los puntos proporcionados por GeometryInfo no presenten
esta estructura, se genera el índice adecuado. Al contrario que la clase Triangulator, la
clase NormalGenerator puede utilizarse de forma independiente del flag elegido.
La clase Stripifier analiza los triángulos contenidos en el vector de datos de
GeometryInfo y los convierte en una estructura de triángulos similar a la obtenida con la
clase TriangleStripArray. Como consecuencia, se obtiene una estructura de triángulos más
optimizada que con la clase Triangulator. Normalmente, para mejorar el funcionamiento de
la clase Stripifier, esta transformación se combina con la clase NormalGenerator.
Los pasos descritos en este apartado así como el uso de las distintas clases se puede
ver en la aplicación easyContent/GeometryInfoApp.java.
13.3.2.5 Cargadores de escenas 3D
Existe una gran variedad de programas que permiten generar contenidos en tres
dimensiones y almacenar dicho contenido en un fichero para su posterior utilización.
Programas de este estilo son 3D-Studio, Autocad...
Java 3D proporciona como parte de su API un conjunto de utilidades (loaders) que
van a permitir incluir el contenido de los ficheros generados por otras aplicaciones en
35

universos virtuales. Este conjunto de utilidades se encuentra en el paquete
com.sun.j3d.loaders.
Como ya habrá intuido el lector esto abre las puertas a una forma de generar
contenido 3D mucho más potente y más sencilla. La dificultad de generar figuras en 3D
está en distribuir, de forma correcta, los puntos en el espacio. En el caso de aplicaciones
simples, este problema no es un gran inconveniente, pero a medida que las escenas se
complican, la tarea de situar cada punto puede llegar a ser una tarea tediosa, e incluso
intratable. Por lo tanto, si se pudiera disponer de herramientas de diseño 3D avanzado para
construir las figuras 3D y luego importar dichas figuras, las escenas que se podrían
conseguir sólo estarían limitadas por la imaginación del programador.
En realidad, estos cargadores de escenas no forman parte del API de Java 3D, sino
que, simplemente, Java 3D proporciona los mecanismos para su construcción. Es decir,
sólo especifican la interfaz de dichos cargadores, sin establecer cómo deben implementarse.
El número de cargadores disponibles es bastante considerable, y mucho de ellos de
libre distribución. Java 3D proporciona un ejemplo de cargador ya implementado para el
formato “.obj”. Este cargador está disponible a través de la clase ObjectFile en el paquete
com.sun.j3d.loaders.objectfile.
Además Java 3D va a permitir no sólo cargar una escena completa de un fichero
externo, sino partes de dicha escena, se puede especificar que únicamente se carguen
ciertos efectos de luz, nieblas... o incluso combinar varios ficheros externos para formar
una misma escena. La potencia que se puede conseguir sólo depende de la implementación
del cargador que se esté utilizando y de la propia especificación del fichero que se está
procesando 6 .
Las clases e interfaces que dan soporte a esta tecnología son los siguientes:
Loader. Esta interfaz define una serie de métodos que permiten determinar la
localización del fichero desde el cual cargar la escena, así como un conjunto de
flags que determina que elementos del fichero se desean cargar. Algunos de estos
flags son: LOAD_ALL que permite cargar todo el fichero;
LOAD_BACKGROUND_NODES que permite cargar únicamente los elementos
que configuran el fondo; LOAD_LIGTH_NODES que determina que sólo se
cargarán los elementos de luz, etc.
Scene. Esta interfaz define un conjunto de métodos que serán los encargados de
extraer las características de la escena cargada desde el fichero.
LoaderBase. Esta clase implementa la interfaz Loader. Los autores de cargadores
extienden esta clase como paso previo a la construcción de sus propiso cargadores.
6
Si el fichero externo no especifica contenido sobre luces, sonido..., este tipo de contenidos
no se podrá cargar.
36

SceneBase. Esta clase implementa la interfaz Scene. Esta clase implementa un
conjunto de métodos que permiten recuperar cada uno de los nodos que forman la
escena cargada desde el fichero. Así, por ejemplo, cuenta con métodos como
getBackgroundNodes() que permite recuperar un vector con todos los nodos que
forman el fondo de la escena.
13.3.3 Modificación de la apariencia
En el apartado anterior, se ha analizado diferentes formas de construcción de figuras
geométricas. Dejando a un lado las figuras geométricas preestablecidas, se ha visto como el
mecanismo de trabajo es crea un objeto del tipo NodeComponent que contenga la
información geométrica para dibujar la figura en tres dimensiones. Esta forma de trabajo se
continúa para establecer efectos de apariencia en las figuras, es decir, se crea un objeto de
la clase anterior que contendrá la información necesaria para configurar la apariencia de las
figuras.
En este apartado, se analiza como realizar dichas operaciones de cambio de
apariencia, tanto a nivel de una figura concreta, como a nivel de toda una escena.
13.3.3.1 Concepto de límite
En muchos aspectos dentro de Java 3D (luces, comportamiento, configuración del fondo...)
se utilizan límites o rangos. Los límites (bounds) van a permitir al programador flexibilizar
acciones, apariencia..., limitando las regiones de influencia de determinados elementos. Un
límite permite definir un área en la cual un determinado elemento tiene influencia.
En implementación, existe una clase general denominada Bounds que permite
incluir dentro de un grafo de escena el concepto de límite. Una instancia de esta clase se
enlaza con un objeto del grafo de escena. Así, cada vez que el objeto del grafo de escena se
desplace, el objeto Bounds irá con él. En otros casos, los objetos Bounds tendrán autonomía
de movimiento 7 . La forma más común de determinar los límites de influencia de un
determinado elemento es mediante la definición de una esfera de cierto tamaño. Esta forma
de trabajo es lógica ya que la esfera es la figura geométrica más adecuada para establecer
una región dentro de un mundo en tres dimensiones. La forma de definir dicha esfera es a
través de la clase BoundingSphere. Aunque, no es la única manera. Existen clases que
permiten definir los límites en base a figuras que no son una esfera, como son BoundingBox
y BoundingPolytope.
Como ejemplo ilustrativo del concepto de límite, considérese una escena en la que
existe una serie de elementos en movimiento y un punto de luz fijo que ilumina todos los
7 Que el objeto Bound tenga libertad de movimiento o dependa de un objeto del grafo de
escena, dependerá del propósito a conseguir.
37

objetos. Para que la luz afecte a todos los objetos en movimiento, el alcance de dicha luz
debería ser lo suficientemente grande para que todos los objetos estuvieran dentro de sus
límites. El tamaño de la zona de influencia se puede definir a través de los métodos
proporcionados por la clase Bounds y sus descendientes.
Además de la clase Bounds, existe una clase adicional que permite el control de
límites. Esta clase es la clase BoundingLeaf. Esta clase extiende la clase Leaf. La diferencia
con respecto a la clase Bounds, es que la clase BoundingLeaf se puede incorporar como un
nodo hoja al grafo de escena funcionando de forma independiente. El objeto (u objetos)
sobre el que se vaya a definir una región de influencia podrá hacer referencia a dicho
BoundingLeaf.
Se volverá sobre el concepto de límite en el apartado Luces. Si se desea saber más
sobre dicho conceptos y su uso, se recomienda acudir al capítulo 6 de (J. Bouvier, 1999).
13.3.3.2 Configuración del fondo
Aunque el formato del fondo no es un elemento que afecte a una figura en especial, es un
elemento que permite alterar el aspecto de toda la escena, por lo que se ha optado por
discutirlo en este punto. Por defecto, el color de fondo predeterminado por defecto para este
objeto es negro. Java 3D proporciona los mecanismos necesarios para cambiar el color de
fondo, o si el usuario lo prefiere, añadir imágenes como fondo e incluso formas geométricas
o una combinación de los elementos anteriores. Incluso es posible definir diferentes fondos
para diferentes secciones dentro de un mismo universo virtual.
La clase que se encarga de gestionar el fondo es la clase Background. Esta clase
hereda de forma directa de la clase Leaf. Como consecuencia, las instancias de la clase
Background podrán añadirse directamente como terminación de una rama del grafo de
escena, como si de una figura 3D habitual se tratara.
Para crear un nuevo fondo, se deben seguir los siguientes pasos generales:
1. Se crea el objeto Background y se define el color de fondo o la imagen que va a
constituirse como fondo.
2. Se añade un elemento geométrico si se desea que una figura geométrica forme parte
del fondo. Este punto es opcional en el proceso de construcción de un fondo.
3. Se proporcionan los límites del fondo.
4. Se añade como hoja al grafo de escena.
Para cambiar el color de fondo o incluir una imagen, la clase Background
proporciona las funciones necesarias para tal cometido. Dichas clases toman como
parámetro el color (en formato RGB) o un objeto que encapsula la imagen
(ImageComponent2D) y actualizan el fondo.
En cambio, para el segundo punto, la cosa se complica, no por la forma de incluirlo
en el fondo, ya que existe la correspondiente función para ello, sino por la construcción en
38

sí de la figura geométrica. En el ejemplo easyContent/BackgroundApp.java se puede
observar la inclusión de figuras geométricas como fondo de la escena. Se han utilizado
objetos PointArray para simular estrellas y una clase LineArray para simular una
constelación. Además, este ejemplo es un buen punto de referencia para conocer más a
fondo el uso de las clases BoundingSphere y k, esta última aplicada a aspectos de
interacción con el usuario 8 .
13.3.3.3 Apariencia
Analizada la forma de alterar el fondo de una escena 3D, queda profundizar en cómo
cambiar la apariencia de cada uno del resto de los elementos que forman el universo virtual.
Como ya se ha podido observar, la apariencia no es un elemento que condicione la
creación de universos virtuales, y de hecho, se presenta como algo adicional. Todas las
formas 3D tienen definida por defecto una apariencia.
Por otro lado, se ha visto como, sin necesidad de definir un nodo Appearance
explícito, se pueden definir efectos de color y textura a través de las clases específicas para
definir geometría 9 . Sin embargo, para otros muchos casos es necesario un objeto explícito
que realice el trabajo.
La clase Appearance es descendiente de NodeComponent y por lo tanto deberá estar
relacionada con un objeto Shape3D ya que, de forma directa, no se puede incluir en el grafo
de escena.
Un objeto del tipo Appearance no contiene ningún tipo de información acerca de
cómo se debe mostrar una figura, pero si conoce dónde buscar dicha información. Mantiene
un conjunto de referencias a otras instancias de clases descendientes de la clase
NodeComponent, las cuales sí tiene la información necesaria.
Este último conjunto de clases se conoce como atributos de apariencia e incluyen
las siguientes clases:
PointAttributes. Atributos relativos a cómo se mostrarán los puntos.
LineAttributes. Establece las características de visualización de una recta.
PolygonAttributes. Define las características para los polígonos.
8 La interacción con el usuario se aborda en el apartado Movimiento en Java 3D.
9 Las clases descendientes de la clase Geometry permitían definir un conjunto de puntos así
como su significado semántico. Dentro del rango de significados semánticos soportados
estaban los siguientes: COLOR_3, COLOR_4, TEXTURE_COORDINATE_2 y
TEXTURE_COORDINATE_3.
39

ColoringAttributes. Establece detalles relativos al color.
TransparencyAttributes. Atributos relativos a efectos de transparencia.
RenderingAtributes. Permite controlar dos aspectos relacionados en el proceso de
visualización de un píxel: la gestión del buffer de dibujo y la función alfa. Por esta
razón, permite definir aspectos de visualización aplicables a todos los tipos de
primitivas.
Material. Esta clase de atributos está relacionada con los efectos de luz que se
describen más adelante en este documento.
TextureAttributes, Texture y TexCoordGeneration. Las tres clases están
relacionadas con la gestión de texturas. Estas clases se analizan más adelante en el
documento (apartado de texturas).
La clase Appearance proporciona los métodos necesarios para incluir las referencias
a cada una de las instancias de las clases vistas.
A continuación se describen cada una de las clases con más detalle. Para su
explicación se agrupan en tres secciones. La primera agrupa las clases relativas a atributos
de apariencia generales, y las siguientes abordan el tema de las luces y las texturas.
13.3.3.3.1 Atributos generales
PointAttributes
Esta clase define los atributos que establecen cómo se mostrarán cada uno de los puntos
que formar la figura. Por defecto, cada punto se corresponde directamente con un píxel.
Aumentar el tamaño del punto supone aumentar el número de píxeles asociados a dicho
punto. Este aumento de tamaño, a través de métodos proporcionados por la propia clase,
supone acentuar la forma cuadrada que presenta el punto. Para suavizar esta forma, la clase
PointAttribute proporciona un método, setPointAntialiasingEnabled(), que permite cambiar
el color de los píxeles de los extremos que forman el punto, dando sensación de redondez.
LineAttributes
Esta clase define las características de visualización que presentarán las rectas.
Concretamente, afecta a la forma en la que se mostrarán las rectas en tres sentidos:
Permite definir el cuerpo de la línea, estableciendo si es sólido, intermitente, a
puntos o mixto. En una palabra, define como cada uno de los píxeles que forman la
recta se deben dibujar. Este aspecto de una recta se denomina patrón de la recta.
Otra característica que define es el ancho de la línea, es decir el ancho de cada píxel
que forma la recta.
40

El tercer aspecto que permite definir es el conocido como antiálias (antialiasing),
permitiendo mostrar un aspecto más suave en el dibujo de la recta.
PolygonAttributes
En cuanto a la visualización de polígonos se pueden parametrizar los siguientes aspectos:
Se puede definir la forma en la que se mostrará el polígono: relleno, sin relleno
mostrando su superficie mediante líneas que se cortan (a modo de entramado) o
mostrando únicamente su perfil. Si se muestra siguiendo los dos últimos formatos
especificados, los atributos del polígono también se ven afectados por las clases
PointAttributes y LineAttributes. El aspecto del polígono se denomina el modo del
polígono.
Otro aspecto que permite configurar es si el polígono se muestra completo o no
(culled). Se puede definir que caras del polígono se van a mostrar, si sólo las de la
parte frontal o las de la parte posterior. Esto permite aumentar el rendimiento al
mostrarse únicamente la mitad de las caras que forman un polígono.
Un ejemplo de la utilización de esta clase para alterar la apariencia de un objeto se
puede ver en los ejemplos geometry/YoyoLineApp.java y geometry/YoyoPointApp.java.
ColoringAttributes
Permiten determinar y controlar cómo se colorea la figura correspondiente. El color como
en otras ocasiones se define siguiendo la notación RGB o mediante la clase Color3f.
También, permite definir como se extenderá el color definido al resto de la figura por
ejemplo si se trata de un polígono o una recta.
Como se vio en el apartado Construcción de elementos geométricos los colores
también se pueden definir por cada vértice en las clases derivadas de Geometry sin más que
definir que el vector de puntos especificado identifica color. En el caso que se haya
especificado color, tanto a través de la clase Geometry como a través de los atributos de
color, la definición realizada sobre aquella prevalece sobre la segunda forma de definir el
color. Se volverá sobre el tema del color en el apartado Luces.
TransparencyAttributes
Permite controlar la opacidad de una figura. Define si una figura tiene cierta transparencia
así como el método elegido para generar dicho efecto de transparencia. Esta propiedad
varía en una escala numérica desde 0.0, que indica que es un cuerpo opaco, y 1.0, que
indica que el objeto es totalmente transparente
RenderingAttributes
Esta clase define un conjunto de flags que permiten configurar las características relativas
al tamaño del buffer de dibujo y a la función alfa entre otros aspectos. Acudir a (Sun
41

Microsystems, 1999) para una mayor descripción de cada uno de los flags y de los
diferentes métodos que permiten utilizar dichos flags.
13.3.3.4 Luces
La mayor parte del modelo de luces y sombras de Java 3D está basado en OpenGL, por lo
que se puede consultar más información en los temas 7 y 8 de esta asignatura.
13.3.3.4.1 Modelos implicados
Para incluir efectos de luz dentro de un universo virtual, Java 3D trabaja con tres modelos
específicos: modelo de luz (Lighting Model), modelo de color (Color Model) y modelo de
sombreado (Shade Model). A continuación se describen de forma breve.
Lighting Model
Java 3D utiliza este modelo para mostrar los objetos con una mayor realidad, ya que el
color de los objetos se percibe como una combinación de las propiedades físicas del objeto,
de las características de las fuentes emisoras de luz, de la posición respecto a ellas y del
ángulo desde el que se observa el objeto.
La ecuación con la que se trabaja en este modelo se basa en tres vectores: vector
normal a la superficie del vértice (N), vector dirigido a la fuente de luz (L) y el vector
dirigido al observador (E). En la figura inferior se muestra como cada vértice de la esfera
potencialmente se puede representar con una sombra diferente.
Figura 13 - Luz (L), vector normal a la superficie (N) y vector dirigido al observador (E)
Este modelo permite representar en un universo virtual tres tipos de reflexiones de
luz presentes en el mundo real. La reflexión ambiental que mantiene un bajo nivel de luz, la
difusión que es la reflexión natural de la luz sobre un objeto y la reflexión especular que
creo zonas con una mayor iluminación del objeto. En la figura que tenemos a continuación,
se muestra lo expuesto anteriormente, de manera que la parte más oscura de la esfera
exhibe sólo la reflexión ambiente, el centro está iluminado por la luz difusa y ambiente y la
parte más brillante de la esfera es el resultado de la reflexión especular con reflexiones
ambiente y difusa.
42

Figura 14 - Esfera sombreada
Como se ha visto el tratamiento de la luz por parte de Java 3D es bastante complejo
y si cada punto del objeto contiene un nivel de luz distinto una porción significativa del
cálculo de representación se utiliza para estos vértices sombreados. Esto se puede evitar si
el vector L o el vector E son constantes.
Para conseguir que el vector L sea constante se debe usar una fuente
DirectionalLight que proporciona una sola dirección al brillo de la luz. Esta clase
proporciona tres constructores en los que se puede especificar el color, la dirección y el
estado. Tal y omo se observa en la figura, al ser todos los vectores de luz de una fuente
DirectionalLight paralelos la luz no se atenúa, es decir, la intensidad de la fuente no varía
con la distancia al objeto.
Figura 15 - El vector de luz permanece constante para una fuente de tipo DirectionalLight
El vector E, también conocido como vector de ojo infinito, es constante por defecto,
aunque podemos especificar un vector variable del ojo usando un método del objeto View.
Si nos fijamos en la figura siguiente se ve como en la ventana de la izquierda que tiene un
vector E constante hace que las reflexiones especulares están básicamente en la misma
posición para cada esfera al contrario que en la ventana de la derecha. El objeto View
contiene todos los parámetros necesarios para renderizar una escena tridimensional desde
un punto de vista.
43

Figura 16 - variación del vector dirigido al observador (E)
El tiempo real para renderizar además de variar con los vectores L y E varía con el
sistema utilizado. La diferencia es más pronunciada en los sistemas que renderizan por
software.
Para concluir este apartado hay que decir que en este modelo los fenómenos físicos
complejos no se modelan, ya que en la figura anterior vemos como falta la sombra de la
esfera, la luz de la esfera sobre el plano… porque para reducir la complejidad del cálculo, el
modelo de iluminación considera solamente un objeto visual al mismo tiempo.
Color Model
En la realidad el color es una combinación de muchas longitudes de onda de la luz pero en
el mundo virtual de Java 3D un solo color de luz queda especificado por una combinación
de rojo, verde y azul. Es el conocido modelo de color RGB que representa muchos colores,
pero no todos. El modelo de iluminación es un modelo físico, mientras que el modelo de
color es una adaptación.
Shade Model
Es el encargado de dar sombra y color a todos los vértices que se encuentran bajo un punto
de luz. Existen varios métodos para sombrear una figura, por un lado el sombreado
Gouraud en el que cada píxel se sombrea con un valor derivado de la interpolación trilinear
del valor de la sombra en cada vértice del polígono que lo encierra y por otro, el sombreado
plano en el que a todos los píxeles de un polígono se les asigna el valor de la sobra a partir
de un vértice del polígono. El primero tiene como ventaja la apariencia visual y el segundo
la velocidad en la representación del software.
44

Figura 17 - Métodos Flat y Gouraud empleados para sombrear una esfera
Tanto este modelo como el modelo de luz están basados en OpenGL 10 .
13.3.3.4.2 Fuentes de luz
El primer elemento indispensable para incluir luz en una escena es una fuente luminosa.
Para ello, Java 3D proporciona toda una estructura de clases encargadas de tal cometido.
Las clases definidas como elementos luminosos son descendientes de la clase Leaf y por lo
tanto se pueden incluir de forma directa en el grafo de escena. Estas clases son las que se
definen a continuación de forma breve.
La clase principal es la clase Light. Es una clase abstracta que define los parámetros
principales de la luz como son el estado (encendido o apagado), el color y los límites de
influencia. Heredando de esta clase se encuentran clases más específicas que permiten
incluir ciertos tipos de luz concretos:
AmbientLight. Los objetos de luz ambiente proporcionan luz de la misma
intensidad en todas las direcciones y modelan la luz reflejada desde otros objetos
visuales. Mientras que podría ser natural pensar que una fuente de luz ambiente se
puede aplicar globalmente, esto no es necesariamente cierto en un programa Java
3D. La influencia de la fuente AmbientLight está controlada por sus límites igual
que otras fuentes de luz Java 3D. Se pueden utilizar varios objetos fuente
AmbientLight en un programa de Java 3D. No hay límite en el número de los
objetos fuentes AmbientLight que se pueden utilizar.
DirectionalLight. Al contrario que las anteriores estas fuentes proporcionan una
sola dirección al brillo de luz. Para los objetos iluminados con esta fuente el vector
de luz es constante. Estas fuentes solo participan en las porciones difusas y specular
de la reflexión del modelo de iluminación.
PointLight. Es lo contrario de una fuente DirectionalLight. Define una fuente de luz
colocada en algún punto del espacio y que emite luz en todas direcciones. La
intensidad se atenúa con la distancia.
10 Dado que se apoya sobre OpenGL se aconseja acudir a bibliografía sobre esta librería
gráfica para ampliar conceptos sobre los distintos modelos implicados (Wright et al., 1997).
45

SpotLight. Es una subclase de PointLight que agrega dirección y concentración a
los parámetros de posición y atenuación. La intensidad de la luz producida por una
fuente de este tipo produce la luz dentro de un ángulo especificado desde la
dirección de la luz. El ángulo de extensión de un objeto SpotLight podría hacer que
la luz iluminara parte de un objeto visual, por lo que esta es la única luz capaz de
iluminar solamente una parte de un objeto.
El número de luces y los atributos de éstas es más bien una consideración artística
que científica, pero a continuación se van a dar unas pautas generales. A menudo es
suficiente tener solo dos luces para una escena dada, una que proporcione la iluminación
principal y la otra se utiliza para completar la cara más oscura de los objetos. La luz
principal normalmente se coloca a la derecha del espectador mientras que el relleno a la
izquierda. Normalmente se prefiere incluir fuentes de luz direccionales para la mayoría de
las aplicaciones puesto que el cálculo requerido en la representación es perceptiblemente
menor que para los puntos de luz. Las fuentes de puntos de luz se usan muy raramente
debido a la alta complejidad de cálculo.
La influencia de una luz va a determinar que objetos se ven afectados por dicha luz
y cuales no. Existen dos formas de realizarlo. La primera es mediante objetos Bound
(BoundingSphere, BoundingBox...) o BoundingLeaf. La segunda forma es mediante el
alcance de la fuente de luz. Este segundo mecanismo simplifica bastante el tema de control
de influencia de un emisor de luz. El alcance se define a través de un nodo Group que
establece la lista de objetos que están bajo la influencia de la luz. Para ampliar más se
aconseja acudir al capítulo 6 de (J. Bouvier, 1999).
13.3.3.4.3 Clase Material
La inclusión de una fuente de luz no significa que los objetos vayan a presentar una
apariencia modificada por dicha fuente de luz. Para que esto suceda es necesario definir un
objeto Material y enlazarlo con el objeto Appearance del elemento 3D. El objeto Material
es del tipo NodeComponent.
Este objeto va a permitir definir el color ambiente, el color de difusión, el color
especular, así como el color de emisión y el brillo. Los tres primeros colores son los
utilizados por el modelo de luz (Lighting Model) para generar los efectos de reflexión
anteriormente citados.
Cuando para un objeto se define un atributo del tipo Material, este objeto se ve
influenciado por la luz (o luces), siempre y cuando entre dentro de los límites de influencia
de la fuente luminosa.
El lector habrá comprobado que con el objeto Material ya existen tres formas de
definir color para un objeto (las otras dos son mediante el objeto Geometry definiendo
coordenadas de color o mediante el objeto ColoringAttributes). Quien finalmente defina el
color depende de un conjunto de reglas de generación de color preestablecidas. Las
siguiente tablas muestran el resultado de dichas reglas.
46

Geometry ColoringAttributes Resultado
NO NO Material
SI NO Geometry
NO SI Material
SI SI Geometry
Tabla 2 - Reglas de generación de color en presencia de un objeto Material
La Tabla 13. 2 muestra desde donde se tomará el color cuando un objeto de tipo Material se
incluya dentro del objeto Appearance del elemento visual (es decir cuando esté influido por
la luz). Se puede comprobar como prevalece el color definido por el objeto Geometry, y en
su ausencia el color definir por el objeto Material.
En ausencia de un objeto Material (el objeto no se verá afectado por la luz) el color se toma
siguiendo las siguientes reglas:
Geometry ColoringAttributes Resultado
NO NO En blanco
SI NO Geometry
NO SI Coloring Attributes
SI SI Geometry
Tabla 3 - Reglas de generación de color en ausencia de un objeto Material
13.3.3.4.4 Influencia de las fuentes de luz
Un aspecto comentado hasta ahora es el término de límites de influencia. Este concepto ya
se introdujo al principio de este apartado.
La influencia de una luz va a determinar que objetos se ven afectados por dicha luz y cuales
no. Existen dos formas de realizarlo. La primera es mediante objetos Bound o
BoundingLeaf. La segunda forma es mediante el alcance o scope de la fuente de luz. Este
segundo mecanismo simplifica bastante el tema de control de influencia de un emisor de
luz. El alcance se define a través de un nodo Group que establece la lista de objetos que
están bajo la influencia de la luz. Para ampliar más se aconseja acudir al capítulo 6 de (J.
Bouvier, 1999). En el ejemplo light/LightScopeApp.java se implementa el concepto de
alcance de una fuente de luz.
13.3.3.5 Texturas
La utilización de texturas es uno de los mecanismos más importantes que permiten dar
realismo a una escena 3D. En mucho casos, es la única forma de que un objeto 3D muestre
un aspecto real. Algunos objetos que no se representan bien con polígonos planos no
texturados son la madera, los ladrillos, el cemento, una alfombra…
Por lo tanto se necesita una técnica como el texturado, también llamado mapeo de
textura, que añada riqueza visual a una superficie sin la adición de detalles geométricos
47

finos. La riqueza visual la proporciona una imagen, también llamada textura, que da el
aspecto del detalle superficial para el objeto visual. La imagen se mapeada dentro de la
geometría del objeto visual en el momento de la renderización. De ahí el término mapeo de
textura.
Al igual que sucedía con las luces la inclusión de texturas es un proceso que
requiere el uso de un gran número de clases, de las cuales más adelante se explicarán las
más importantes.
Pasos a seguir para proporcionar texturado a nuestro objeto:
Preparar las imágenes de texturas: este paso se realiza externamente a los
programas de Java 3D y lo que se pretende conseguir es que la imagen que dará la
textura a nuestro objeto tenga unas dimensiones aceptables y que el formato del
fichero que la almacena pueda ser leído por Java 3D.
Una restricción que impone Java 3D es que las imágenes tienen que tener un tamaño
potencia matemática de dos en todas las dimensiones porque sino dará una
excepción en tiempo de ejecución.
Los formatos estándares que carga son JPEG y GIF, aunque la clase TextureLoader
también carga otras texturas.
Cargar la textura: consiste en conseguir la imagen preparada en un objeto imagen.
Se puede hacer a través de un fichero o de una URL usando un mismo proceso que
puede implicar un gran número de líneas de código o por el contrario unas pocas si
se usa el objeto TexturaLoader. Si nos fijamos en el siguiente código podemos ver
como se usa el objeto TextureLoader para cargar el fichero imagen.gif.
TextureLoader loader = new TextureLoader("imagen.gif", this);
ImageComponent2D image = loader.getImage();
Las imágenes se cargan de forma asíncrona lo que es muy útil cuando la carga se
realiza a través de una URL. Para facilitar el manejo de cargas asíncronas de
imágenes, los componentes de AWT están capacitados para ser observadores de
imagen, que es observar el proceso de la carga de la imagen. A un observador de
imagen se le puede preguntar por los detalles de la carga de la imagen.
Con el fin escribir programas Java 3D todo lo que necesitamos saber es que
cualquier componente del AWT puede servir como un observador de imagen.
Puesto que applet es una extensión del componente Panel del AWT, el objeto applet
de un programa de Java 3D puede ser el observador de imagen para el objeto
TextureLoader.
Crear el manojo de Appearance: una vez que se tiene cargada la imagen parar
poderla utilizar como una textura en un objeto visual se debe asignar como la
48

textura de un objeto Texture. Las siguientes líneas de código se situarán a
inmediatamente después que las del paso anterior:
Texture2D texture = new Texture2D();
texture.setImage(0, image);
Appearance appear = new Appearance();
appear.setTexture(texture);
La imagen entonces se asigna al objeto Texture2D y luego el objeto Texture2D se
agrega al objeto Appearance. En este ejemplo no se ha utilizado pero llegados a este
punto se suele hacer uso del objeto TextureAttributes que por su gran importancia se
explicará más adelante.
Especificar las coordenadas: para finalizar hace falta la colocación de la textura en
la geometría a través de la especificación de las coordenadas de textura. Las
especificaciones se hacen por cada vértice de geometría. Cada píxel de una textura
se llama un texel. Con la especificación de algunos puntos de la imagen que se
aplicarán a los vértices de la geometría, la imagen será rotada, estirada, aplastada,
y/o duplicada para hacer que quepa en la especificación. Para esto se hace uno del
objeto GeometryArray.
Una vez completados estos sencillos pasos ya se puede añadir el objeto a un
escenario gráfico.
13.3.3.5.1 Clases esenciales de texturado
En primer lugar, están los cargadores de texturas. Las clases TextureLoader y
NewTextureLoader permiten cargar, a partir de un fichero gráfico externo, una textura para
utilizarla dentro de una escena. Ambas clases proporcionan un objeto ImageComponent2D
que funciona como un contenedor de la imagen. Esta imagen aún no puede ser utilizada tal
y como vimos en el apartado anterior.
Una segunda clase que interviene en este proceso es la clase GeometryArray que
podía especificar que las coordenadas se referían a aspectos relativos a la textura que se iba
a aplicar al objeto visual (mediante los métodos adecuados de la clase GeometryArray o a
través de los flags TEXTURE_COORDINATE_2 y TEXTURE_COORDINATE_3).
Otro grupo de clases son las derivadas de la clase NodeComponent. Entre estas
clases están:
La clase Texture y sus derivadas Texture2D y Texture3D. Estas clases van a
permitir tanto importar la imagen del componente ImageComponent2D como
configurar ciertos aspectos de cómo se aplicará la textura. Un objeto del tipo
Texture se incorpora a la escena enlazándolo con el objeto Appearance relacionado
con el objeto Shape3D al que se desea aplicar la textura.
49

La clase TextureAttributes, que permite configurar ciertos aspectos que condicionan
la forma en la cual se aplicará la textura. Junto con la clase Texture permite
configurar las características más importantes.
La clase TextCoordGeneration que proporciona al programador una forma más
sencilla de generar las coordenadas de la textura, que de otra forma se debería
incluir “a mano” a través del objeto GeometryArray.
Existen más clases que ayudan a la gestión de texturas pero no son objeto de
explicación en este documento. A continuación, se describirán con un poco más de detalle
las clases Texture y TextureAttributes. Para completar estas clases y para saber más sobre el
resto de clases acudir a (J. Bouvier, 1999) y (Sun Microsystems, 1999).
Clase Texture
Sobre esta clase destacar, principalmente, el hecho de que es la que permite incluir la
textura en sí.
La clase Texture2D permite incluir texturas en dos dimensiones y la clase
Texture3D, como su propio nombre indica, texturas en tres dimensiones.
Un aspecto que permite definir la clase Texture es el conocido como Boundary
Mode. Es decir, la forma en la cual la textura se aplicará sobre la superficie en caso de que
el tamaño de dicha textura no cubra toda la superficie. Para realizar este proceso, existen
dos opciones. La primera es la conocida como distribución en mosaico o wrap que se basa
en utilizar la textura varias veces para cubrir toda la superficie. La segunda utiliza un color,
que también se puede definir, para rellenar los huecos. Si este no se especifica se utiliza el
color del límite de la textura para rellenar el espacio. Esta técnica recibe el nombre de
clamp.
Clase TextureAttributes
Esta clase deriva de la clase NodeComponent y sirve de medio para definir características
de cómo se aplicará la textura. Puede convivir con el objeto Texture dentro del mismo
objeto Appearance.
Entre los aspectos que permite definir dicha clase están:
El modelo en el que la textura influirá en el aspecto final del píxel. Como ya se ha
visto en el apartado de luces, el aspecto externo de un píxel depende de los
atributos de color de distintos objeto y de la influencia de las luces. Este color es el
que primero se calcula y luego se completa con el definido por la textura. Existen
cuatro formas de definir cómo se combinan textura y color:
o BLEND: el color de la textura se mezcla con el color del material
arbitrariamente con un color de mezcla. La transparencia que resulta es la
combinación de la transparencia de la textura y del material.
50

o DECAL: el color de la textura se aplica como etiqueta encima del color de la
no-textura. La transparencia de la textura determina la cantidad de color material
a utilizar. La transparencia del píxel se deja sin cambios. Esto es totalmente
igual que aplicar una etiqueta a un objeto del mundo real.
o MODULATE: el color de la textura se combina con el color de la no-textura. La
transparencia que resulta es la combinación de la transparencia de la textura y
del material. Puesto que el color que resulta depende de la no-textura y de los
colores de la textura, este modo es útil en la aplicación de la misma textura a
una gran variedad de objetos visuales sin hacer que todos parezcan iguales. Este
modo se utiliza a menudo en escenas de iluminación.
o REPLACE: la textura proporciona el color y la transparencia para el píxel, no
haciendo caso del resto de los colores excepto del color specular (si se permite
la iluminación). Éste es el modo de textura por defecto incluso cuando no hay
componente TextureAttributes en el manojo de apariencia.
Figura 18 - Combinación de textura y color
Java 3D por defecto siempre realizar una corrección de la textura en función del
punto de vista desde el que se observe el objeto. De esta forma se asegura que la textura
siempre se muestre de forma correcta. A través de la clase TextureAttributes se puede
definir el grado de corrección que se pretende conseguir mediante dos valores: FASTEST y
NICEST, que obviamente premian la velocidad y la calidad de la corrección,
respectivamente.
51

13.3.4 Movimiento en Java 3D
En el apartado Formas geométricas se ha centrado la atención en la creación de contenidos
dejando a un lado aspectos de transformación de la escena como rotaciones, translaciones...
Este tipo de aspectos se abordan en esta sección.
En primer lugar, se describen ciertos conceptos esenciales para la comprensión de la
forma en la que Java 3D aborda el tema del movimiento dentro de un universo virtual. A
continuación, se introducen los mecanismos más avanzados presentes en el API para
realizar animaciones así como para controlar la interacción con el usuario.
13.3.4.1 Conceptos básicos
En este punto, se describen los fundamentos básicos que proporciona el API de Java 3D
para transformar la situación inicial de las figuras en una escena.
13.3.4.1.1 Traslaciones y rotaciones en Java 3D
Con anterioridad se introdujeron las clases TransformGroup y Transform3D. Estas dos
clases son el germen para realizar modificaciones sobre la posición y orientación por
defecto de una figura 3D.
La clase Transform3D proporciona métodos que permiten realizar translaciones de
una figura desde un punto del espacio a otro, rotaciones respecto a un eje determinado y
con un ángulo dado... En una palabra, va a encapsular toda la lógica de procesamiento de
matrices implicada en el proceso de transformación gráfica. Un objeto Transform3D realiza
una sola operación de transformación básica. Como consecuencia de esa transformación, la
figura afectada dentro del grafo de escena mostrará una nueva posición o una nueva
orientación o ambas cosas. Si se desea aplicar nuevas transformaciones a partir de dicha
situación, no es necesario más que crear otro objeto del tipo Transform3D, determinar la
transformación a realizar y combinar las dos instancias de los objetos Transform3D. Como
consecuencia de esta combinación, las matrices de transformación que encapsulan las
instancias de los objetos Transform3D implicados se multiplican dando como resultado la
transformación final.
Una vez creada la transformación, ésta se incluye en el grafo de escena añadiendo la
instancia de la clase Transform3D que contiene el resultado de la multiplicación de todas
las matrices a una instancia de la clase TransformGroup.
Para que la transformación tenga efecto, la figura 3D objeto de la transformación se
debe añadir como hija de la instancia de la clase TransformGroup para la que se ha definido
la transformación.
52

13.3.4.1.2 Concepto de capacidad
El proceso descrito en el punto anterior, se realiza de forma previa a la compilación 11 de la
rama generada y la visualización de la escena. Es decir, se hace en tiempo de diseño del
universo. Sin embargo, una vez creada la escena, ésta es totalmente estática.
Para evitar que tras la compilación de una rama, los valores definidos para cada
figura queden inmutables, se define el concepto de bit de capacidad (capability bit). A
través de estos bits no sólo se puede establecer que una figura pueda ser objeto de
transformaciones una vez incluida en el grafo de escena, sino que además decidir que sólo
sea susceptible de ciertos tipos de transformaciones. Además, al definirse el concepto de
capacidad a nivel de la clase SceneGraphObject, cada elemento 3D tendrá sus propias
capacidades.
Por supuesto, la activación de los bits de capacidad de un elemento del grafo de
escena, se debe realizar de forma previa a la compilación y ejecución de la rama del árbol
implicada. La clase SceneGraphObject proporciona métodos adecuados que permiten
activar y desactivar estos bits.
Las diferentes clases que componen Java 3D se caracterizan por un conjunto de bits
de capacidad diferentes. Para conocer dichos flags acudir a (Sun Microsystems,1999).
13.3.4.1.3 Comportamientos
El comportamiento se articula en torno a una clase denominada Behavior. Esta clase se
encarga de modificar los objetos de la escena 3D ante distintos estímulos, y en particular
estímulos procedentes de la interacción del usuario. Las modificaciones que se pueden
realizar a través de la clase Behavior y sus descendientes está únicamente limitada por las
capacidades de cada uno de los objetos del grafo de escena.
El objetivo final de una instancia de la clase Behavior es la modificación de un
determinado objeto. Este objeto se conoce como objeto de cambio. Por supuesto, la
instancia encargada de la gestión del comportamiento debe tener una referencia al objeto
susceptible de ser cambiado. Esta referencia se debe incluir en el momento de construcción
del grafo de escena. De hecho, es uno de los parámetros del constructor.
Funcionamiento
El comportamiento posee un método específico que lo inicializa: initialization(). Este
método es responsable de cargar el disparador (trigger) encargado de responder al evento y
11 El concepto de compilación se introdujo en el apartado Modos de renderización
53

la condición para que dicho evento se dispare 12 . El disparador es un objeto de la clase
WakeupCondition o una combinación de objetos de dicha clase.
Una vez que el comportamiento está activado y dispuesto para recibir eventos,
dicho comportamiento será capaz de capturar el evento producido mediante el método
processStimulus().
Este método es el lugar apropiado para incluir aquellas acciones a ejecutar cuando
se recibe el evento. Otra tarea que debe realizar este método es la reactivación del evento.
Es decir, debe volver a habilitar el disparador cuando se haya terminado de procesar el
evento, para así poder recibir nuevos eventos. Si esto no se realiza, el comportamiento sólo
respondería al evento que se quiere controlar una sola vez.
Uso de comportamientos
Conocido el funcionamiento de un elemento de comportamiento, el siguiente paso es
analizar cómo se utiliza.
El primer paso es configurar de forma adecuada el elemento (o elementos) que va a
ser objeto de modificación por parte del comportamiento. Además de la creación de este
elemento, será necesario establecer las capacidades adecuadas que permitan actuar sobre él
una vez que el grafo de escena esté construido.
El siguiente paso es crear una instancia del comportamiento que se desea exhibir
prestando atención en el hecho de que el comportamiento debe tener la referencia al objeto
que desea modificar.
El tercer paso es determinar el alcance de acción del comportamiento. Se utilizará
un objeto BoundingSphere, BoundingBox o BoundingPolytope para determinar dichos
límites. Para Java 3D, un comportamiento sólo está activo si sus límites intersecan con el
volumen de activación determinado para el objeto ViewPlatform 13 , y sólo sí el
comportamiento está activo puede recibir eventos. Por lo tanto, hay que prestar atención a
la hora de determinar los límites de un comportamiento para asegurar que reciba los
eventos cuando se desea.
El último paso, sería añadir el objeto que controla el comportamiento a la rama del
grafo. En la siguiente figura se puede ver el resultado final de las conexiones entre los
distintos elementos comentados de dos formas diferentes.
12 Es común que se desea controlar sólo el evento de clic del ratón ignorando el evento de movimiento del
ratón. Sin embargo, ambos son eventos de ratón. La condición del evento permite la diferenciación de eventos
relacionados semánticamente.
13 Esta clase se describe en la sección ViewPlatform: Un lugar en el mundo virtual.
54

Figura 19 - Grafo de escena que incorpora un comportamiento
En estos grafos, el elemento B (Behavior) es el comportamiento y el elemento TG
(TransformGroup) es el objeto susceptible de ser transformado. Si la transformación fuese
realizar una rotación, el resultado sería que toda la rama por debajo de TG se vería rotada,
en este caso el cubo de color.
La diferencia entre las dos formas de conexión está en que, en el primer caso, el
objeto que se rota se desplaza pero el comportamiento no se desplaza con él. En el segundo
caso, como el comportamiento depende del objeto transformado, también se verá afectado
por la rotación y se desplazará con el objeto.
A primera vista, los dos enfoques son idénticos, pero no es así. Antes se ha
comentado que, para que un objeto comportamiento esté activo es necesario que sus límites
intersecten con el volumen de la vista (objeto ViewPlatform). Imagínese que el objeto
ViewPlatform se cambia, de tal forma que el comportamiento no interseca con el volumen
de la vista, pero el cubo sigue visible. El comportamiento no está activo y el usuario que sí
puede ver el cubo no puede interactuar con él. En el segundo caso, esto nunca sucedería, ya
que mientras la figura esté visible, el comportamiento estará activo. Sin embargo, bajo el
enfoque de la derecha, el cubo nunca podrá abandonar la vista en su proceso de rotación,
mientras que con el enfoque de la derecha la figura seguiría siendo rotada aunque estuviera
fuera de la vista del usuario ya que el comportamiento sí estaría dentro del volumen de la
vista.
Condiciones de inicio
Como ya se ha comentado antes, es necesario configurar un comportamiento para que
responda a un determinado evento. Para ello se utilizan las condiciones de inicio
implementadas a través de la clase WakeupCondition y derivadas. Se pueden establecer dos
grupos. El primero lo forman la clase WakeupCriterion y sus derivadas. El segundo, el
resto de clases derivadas de WakeupCondition.
55

Esta distinción se realiza porque el primer grupo sirve como mecanismo para agrupar
condiciones de arranque del segundo grupo. Las verdaderas condiciones de inicio son las
del segundo grupo.
No se va a entrar a detallar cada uno de los criterios de inicio existentes. Para conocer
detalles sobre ellos acudir a (J. Bouvier, 1999) y a (Sun Microsystems, 1999).
13.3.4.2 Interacción con el usuario
Una vez conocidos los primeros pasos para incorporar transformaciones en una escena 3D,
se va a analizar cómo realizar dichas transformaciones ante eventos generados por la
interacción del usuario con el universo creado.
De todas las clases que descienden de la clase Behavior, las implicadas en la
interacción con el usuario son las que se muestran a continuación.
Figura 20 - Clases de comportamiento implicadas en la interacción con el usuario
56

13.3.4.2.1 Interacción a través del teclado
El primer elemento disponible para que el usuario interaccione con un programa es el
teclado. Mediante el control de teclas, el usuario va a poder modificar la escena.
En este capítulo, se muestra como se puede utilizar los comportamientos vistos con
anterioridad para gestionar este tipo de interacción con el usuario.
El control del teclado en Java 3D se realiza a través de las clases
KeyNavigatorBehavior y KeyNavigator. La primera clase es la que realmente utiliza el
programador para controlar la pulsación de teclas. La segunda clase queda oculta al
programado y no es necesario que éste sepa de su existencia para poder manejar el teclado.
Esta última clase es la que se encarga de la lógica de la función processStimulus().
La respuesta de esta función a los eventos del teclado está predefinida para ciertas teclas
que son comúnmente utilizadas. En la siguiente tabla se muestran los comportamientos por
defecto.
Tabla 4 - Tablas de movimientos predefinidos en Java 3D
La clase que se debe instanciar para controlar los eventos del teclado es la clase
KeyNavigatorBehavior, que como tal comportamiento deberá incorporar una referencia al
objeto que se desea transformar.
Si se desea, el usuario puede crear su propia clase comportamiento que controle el
teclado y así controlar la pulsación de teclas que se consideren oportunas.
Un ejemplo de uso de las teclas de navegación del teclado se puede ver en
interaction/KeyNavigatorApp.java.
57

13.3.4.2.2 Gestión del ratón
Otro dispositivo utilizado por el usuario para interaccionar con un programa es el ratón.
Java 3D proporciona los comportamientos necesarios para controlar los distintos eventos
que puede generar el ratón. Entre estos eventos está la pulsación de cada uno de los
botones. El evento no se dispara por el hecho de pulsar un botón sino por pulsar y desplazar
el ratón sin soltar el botón pulsado.
Por defecto, cada uno de los botones del ratón tiene un efecto preestablecido que es
controlador por una clase diferente en cada caso:
La pulsación del botón izquierdo acompañada de movimiento provoca que el objeto
visual rote. Este evento lo controla la clase comportamiento MouseRotate.
El desplazamiento del ratón manteniendo pulsado el botón derecho provoca que la
figura se desplace siguiendo una trayectoria paralela al plano de imagen. Este evento lo
controla la clase MouseTranslate, que por supuesto es otro comportamiento.
Por último, la pulsación del tercer botón del ratón con desplazamiento de este
provoca una alteración del zoom de la imagen, o lo que es lo mismo, desplaza la imagen en
un plano ortogonal al plano de imagen. Este evento lo controla la clase MouseZoom.
Los tres comportamientos se pueden incorporar de forma simultánea a un programa
y para controlar el mismo objeto visual, como no podría ser de otra forma. Estas tres clases
descienden en la jerarquía de la clase abstracta MouseBehavior que implementa la interfaz
MouseCallback.
La clase abstracta es el punto de partida idóneo para crear, por parte del
programador, un comportamiento que maneje el ratón. De hecho, la mayor parte de
métodos de esta clase se deben sobrescribir. Por otro lado, la interfaz proporciona un
método, transformChanged() que es invocado cada vez que el objeto susceptible del campo
es transformado.
En el apartado de recursos pueden consultarse varios ejemplos sobre interacción con
el ratón. Entre ellos se recomienda interaction/MouseBehaviorApp.java.
13.3.4.2.3 Discriminación de objetos
Mientras no se especifique lo contrario, las interacciones a través del teclado o del ratón
afectan a todo el universo, desplazando toda la escena. Para determinar un objeto concreto
como el objetivo del evento se debe utilizar los que se denomina picking.
Como parece lógico, este mecanismo se implementa como un comportamiento que
responde ante eventos de ratón (¿cómo si no se va a acceder a un elemento concreto dentro
de una escena 3D?).
58

El funcionamiento es el siguiente:
En primer lugar se determina el objeto visual que se desea manipular, con el ratón.
En el momento que se pulse un botón del ratón sobre dicho objeto y se desplace el ratón se
dispara el evento.
Para determinar que objeto hay que manipular, el sistema genera un rayo
denominado pick ray que se proyecta dentro del universo virtual. Este rayo interfecta con el
objeto más cercano al usuario. Este objeto será el que se vea afectado por la interacción. Es
posible que la proyección del rayo interseque con más de un objeto, en este caso existen
métodos para ir seleccionando cada uno de dichos objetos (objeto PickObject).
Figura 21 - Discriminación de un objeto visual mediante el mecanismo pick ray
Un buen ejemplo de discriminación de un objeto dentro de una escena se puede
observar en interaction/MousePickApp.java.
La interacción con una figura concreta es una operación muy costosa en tiempos de
computación.
El primer lugar, ciertos tipos de interacciones (rotaciones, translaciones...) no
afectan al objeto visual en sí sino a alguno de los nodos TransformGroup por encima en el
grafo de escena. Por otro lado, si el objeto está formado por numerosos elementos
geométricos (por ejemplo un cubo que este formado por cuatro caras individuales), cada
uno de estos objetos deber ser objeto de la interacción.
No es objeto de este documento entrar en cómo optimizar el coste de este tipo de
interacciones. Para conocer más acudir a (J. Bouvier, 1999).
Siguiendo la tónica de trabajo de Java 3D se proporcionan clases que permiten
manejar la interacción sobre un objeto concreto y se proporcionan un conjunto de clases
útiles para crear nuevos comportamientos por parte del programador. Todas ellas se
encuentran en el paquete com.sun.j3d.utils.behavior.picking.
59

Las clases predefinidas en el API son PickRotateBehavior, PickTranslateBehavior y
PickZoomBehavior. Para crear una instancia de cualquiera de estas tres clases es necesario
establecer tres parámetros:
1. El primero es el nodo dentro del grafo de escena por debajo del cual se va a
controlar los eventos.
2. El segundo parámetro es el marco en el cual se mueve el ratón, es decir el objeto
Canvas3D creado para mostrar la escena.
3. El último parámetro indica los límites de acción del comportamiento.
Cada clase anterior controla los eventos del ratón correspondientes a pulsar el botón
izquierdo, derecho y central, respectivamente (junto con el desplazamiento de este
dispositivo).
La construcción de comportamientos propios para controlar este tipo de eventos no
es objeto de este documento. Para saber más sobre las clases proporcionadas por Java 3D
que permiten crear comportamientos propios para el control de este tipo de interacciones,
acudir a (J. Bouvier, 1999).
13.3.4.3 Animación en Java 3D
En el apartado anterior se ha introducido la forma de incluir movimiento en una escena 3D
mediante el control de la interacción del usuario. En este apartado, se analiza cómo incluir
animaciones. Esto supone movimiento sin ningún tipo de interacción por parte del
espectador.
De la jerarquía de la clase Behavior, las clases involucradas en la generación de
animaciones son las que se muestran en la siguiente figura.
Figura 22 - Jerarquía de clases Behavior involucradas en la animación
Además de estas clases, existen otras clases adicionales que contribuyen de alguna
forma a la generación de escenas animadas.
La forma más natural de crear una animación es realizando transformaciones sobre
la escena de forma continua en el tiempo. Para ello, además de los comportamientos vistos
60

hasta ahora, que permiten incluir modificaciones, es necesaria una fuente de reloj que vaya
marcando el tiempo. Java 3D proporciona los dos elementos. Los comportamientos
implicados se conocen como interpoladores (Interpolator) y el reloj lo implementa la clase
Alpha. La característica principal de los objetos Interpolator es que son capaces de actual
en función de un objeto Alpha. Aunque los interpoladores no son la única forma de crear
animación basada en el tiempo, sí es la forma más rápida y sencilla.
Alpha
A continuación, se analizan cada uno de los elementos implicados.
Este objeto genera valores entre 0.0 y 1.0 que varían con el tiempo como muestra la
siguiente figura.
Figura 23 - Pulso de tiempo generado por un objeto Alpha
Como se puede ver, el pulso generado por el objeto Alpha tiene cuatro fases: fase de
crecimiento, fase alta, fase de decrecimiento y fase nula. Cada una de estas fases
corresponde con un valor entero que se puede configurar en la creación del objeto.
El número de pulsos que genera el objeto Alpha es otro de los parámetros que se
pueden configurar. Puede variar entre un determinado tiempo máximo e infinito. Este
tiempo no aparece en la figura anterior y se conoce como timeCount.
El tiempo inicial de un objeto Alpha se obtiene del tiempo de inicio de la aplicación,
con lo que todos están sincronizados aunque se hayan creado en diferentes momentos.
61

La Figura 13.23 muestra la forma habitual de los pulsos generados por el objeto
Alpha, pero no son las únicas formas posibles. En la siguiente figura se pueden observar
otras formas de onda que se pueden utilizar.
Figura 24 - Formas alternativas de onda generadas por un objeto Alpha
La forma del pulso condiciona los instantes en los que se dispara el evento y por lo
tanto, el momento en el cual el comportamiento entra en juego.
Otras características importantes que se pueden configurar en un objeto Alpha son el
parámetro increasingAlphaDuration y el parámetro increasingAlphaRampDuration. En la
siguiente figura se puede observar cómo afecta cada uno al pulso.
Figura 25 - Suavizado del pulso de tiempo generado por un objeto Alpha
Los efectos que se consiguen al suavizar la curva son relativos a la aceleración con
la cual se dispara el comportamiento que modifica el objeto. En la siguiente figura, se
muestra este efecto en el movimiento de tres coches.
62

Interpoladores
Figura 26 - Resultados de suavizar un pulso de tiempo de un objeto Alpha
Una vez analizada la clase que permite generar eventos de tiempo, el siguiente paso es
centrarse en los interpoladores.
En la siguiente figura, se muestra la jerarquía de clases para los interpoladores.
Figura 27 - Jerarquía de clases de los interpoladores
A continuación, se van a describir, de forma breve, cada uno de los interpoladores
de la figura. En el ejemplo animation/InterpolatorApp.java se hace uso de alguno de los
interpoladores que se van a describir a continuación.
ColorInterpolator
Este interpolador altera el color de una determinada figura. Para ello, esta clase mantiene
una referencia a atributo de la figura visual que define el color (Material). Puesto que este
tipo de nodos (en general los nodos del tipo NodeComponent) se pueden compartir entre
figuras, el interpolador podría alterar el color de un conjunto de objetos visuales de forma
sencilla y rápida.
63

El valor generado por el objeto Alpha se interpola entre dos vectores que definen un
rango de color, para generar el color resultado.
PathInterpolator
Tanto la clase ColorInterpolator como los siguientes interpoladores que se van a explicar a
continuación, utilizan el mecanismo de interpolación entre dos valores como mecanismo de
trabajo.
En cambio, las clases derivadas de la clase PathInterpolator pueden almacenar más
de dos valores para realizar la interpolación. Estas clases mantienen una referencia a un
objeto TransformGroup sobre el cual van a realizar cambios de posición, orientación y
escala (y por lo tanto sobre sus descendientes).
El conjunto de puntos que almacena esta clase se conocen como knots. Cada vez se
utilizan dos de estos puntos para realizar la interpolación. Cuáles se elijan depende del
valor del objeto Alpha.
El valor de estos knots varía entre 0.0 y 1.0, que corresponde con los valores entre
los que varía el valor generado por el objeto Alpha. Además, el primer punto del conjunto
de knots debe tener el valor 0.0 y el último el valor 1.0. El resto se definen en orden
creciente. Cada knot tiene asociado un valor que permite determinar cuál se activa
dependiendo del valor del objeto Alpha. En la siguiente figura se puede observar esta
correspondencia y cómo se selecciona un knot para un valor determinado del objeto Alpha.
Figura 28 - Pares knot/valor y criterio de seleccion de un knot
Por otro lado, se puede ver cómo cada knot tiene además un valor asociado que
representa la información válida para realizar la animación. En el caso de la figura anterior,
esta información es un vector de puntos.
La clase PathInterpolator es la superclase de un conjunto de clases, cada una de las
cuales encargada de un comportamiento diferente. Además, existen una serie de clases de
utilidad relacionadas con estos interpoladores.
64

Entre las clases derivadas está la clase PositionInterpolator que define pares
knot/posición para alterar la posición; la clase RotationInterpolator que actúa sobre la
orientación; la clase RotPosPathInterpolator que permite variar la posición y la orientación
y, por último, la clase RotPosScalePathInterpolator que permite variar tanto posición como
orientación como escala.
En el paquete de utilidad está la clase TCBPathSplineInterpolator (con una clase
derivada) que funciona de forma similar a la clase PathInterpolator pero utiliza
interpolación por esplines con lo cual permite obtener animaciones más suaves.
PositionInterpolator
Este interpolador permite variar la posición de un objeto visual a lo largo de un
determinado eje de coordenadas.
Mantiene una referencia a un objeto TransformGroup que va a desplazar entre una
posición inicial y otra posición final (ambas especificadas mediante número reales). El
objeto Alpha genera un valor que se interpola dentro del rango establecido siguiendo una
interpolación lineal. El valor interpolado se utiliza para generar una translación sobre el
objeto TransformGroup (la translación se realiza mediante un objeto Transform3D).
RotationInterpolator
Permite variar la orientación de un objeto visual sobre un eje.
Al igual que en el caso anterior, mantiene una referencia a un objeto
TransformGroup. En este caso, el valor generado por el objeto Alpha se interpola entre dos
valores de ángulos (siguiendo una interpolación lineal). De nuevo, para realizar la
transformación se utiliza un objeto Transform3D que establece, además, sobre que eje
realizar el giro.
ScaleInterpolator
Este interpolador va a permitir modificar la posición de un objeto visual, acercándolo o
alejándolo del espectador. En este caso, se interpola entre dos valores que establecen un
rango de escala para el objeto TransformGroup objetivo de la transformación. La forma de
aplicar la transformación es como en los casos anteriores.
SwitchValueInterpolator
Este interpolador no interpola entre un par de valores como en los casos anteriores, sino
entre un conjunto de elementos denominados Switch.
La clase Switch, básicamente, actúa como un contenedor de elementos (de hecho
deriva de la clase Group). El valor generado por el objeto Alpha se interpola entre el valor 0
y el número total de elementos contenidos en el objeto Switch. Esto permite elegir uno de
65

los hijos, que será el que se muestre en la escena. A modo de ejemplo, mediante el uso de
ese interpolador se puede mostrar una secuencia de imágenes cualesquiera.
La potencia de la clase Switch está en que permite definir en cada momento qué
objetos, de entre los que mantiene, se van a visualizar (todos, sólo los que cumplan un
patrón o ninguno).
TransparencyInterpolator
Este interpolador mantiene una referencia a un objeto del tipo TransparencyAttribute, por
lo cual podrá cambiar la transparencia asignada al objeto visual, y si el nodo
TransparencyAttribute es compartido por más de un objeto visual, podrá cambiar la
transparencia de todos ellos.
En este caso, el valor del objeto Alpha se interpola entre dos valores de
transparencia.
Billboard
Este concepto se utiliza en el mundo del diseño 3D para identificar la técnica que consiste
en rotar, de forma automática, elementos en un plano de tal forma que siempre se muestran
de frente al usuario. El objetivo original de esta técnica es la utilización de una estructura
plana para simular una estructura tridimensional más compleja, con mucho menos coste de
procesamiento.
El API de Java 3D proporciona la clase Billboard que hereda de forma directa de la
clase Behavior. La forma de usar esta clase es similar al uso de los interpoladores con la
salvedad de que no existe relación con un objeto Alpha. En este caso, la animación se basa
en la posición relativa del objeto Billboard dentro del mundo virtual. Cualquier alteración
del punto de vista de la escena provoca que se desencadene la acción de este tipo de
comportamiento de forma que el objeto controlado siempre se muestra de frente al usuario.
Un ejemplo sobre este tipo de comportamiento se puede ver en
animation/BillboardApp.java.
LOD
Las siglas LOD (Level Of Detail) identifican la técnica que consiste en variar la cantidad de
detalle con el cual se dibuja un determinado objeto visual dependiendo de su posición en el
universo virtual, concretamente atendiendo a la distancia respecto al espectador. Así, a
medida que un objeto se aleja, el nivel de detalle con el que es necesario representarlo es
menor con lo que se reduce el esfuerzo de visualización del objeto. La clase DistanceLOD
implementa esta funcionalidad.
Otro parámetro que posibilita alterar el nivel de detalle con el que se muestra una
figura es la velocidad de visualización.
66

La forma de trabajo consiste en utilizar un objeto Switch (ya se vio este objeto en el
apartado SwitchValueInterpolator) con el conjunto de objetos que se mostrarán
dependiendo de la distancia al espectador. El primer elemento visual especificado es el de
mayor nivel de detalle. El último, el de meno nivel de detalle. El objeto LOD puede trabajar
con varios objetos Switch de forma paralela, con lo que podrá controlar la visualización de
distintos objetos.
67

13.4 MODELO DE VISUALIZACIÓN
Java 3D introduce un nuevo modelo de vista que toma el espíritu típico de Java de “escribe
una vez y ejecútalo en cualquier lugar” y que lo generaliza para incluir dispositivos de
imagen y periféricos de entrada con seis grados de libertad como los head trackers. Este
espíritu del nuevo modelo implica que una aplicación o un applet escrito utilizando el
modelo de vista de Java 3D puede generar imágenes en un amplio abanico de dispositivos,
que van desde las pantallas de los ordenadores convencionales hasta dispositivos
“montados en la cabeza” (como por ejemplo gafas de realidad virtual). Todo ello sin tener
que modificar el grafo de escena. Este nuevo modelo también logra que la misma
aplicación, y una vez más sin realizar ninguna modificación, puede generar vistas
estereoscópicas y puede aprovecharse de un head tracker para controlar la vista generada.
Para obtener esta gran versatilidad, Java 3D realiza una clara separación entre el
mundo virtual y el físico. Este modelo distingue entre cómo una aplicación coloca, orienta
y escala un objeto ViewPlatform (un punto de vista) dentro del mundo virtual y cómo el
generador de Java 3D construye la vista final desde la orientación y posición de ese mismo
punto de vista. La aplicación controla la posición y orientación del ViewPlatform; el
generador obtiene qué vista debe generar utilizando dicha posición y orientación, una
descripción del entorno físico del usuario y la posición y orientación del propio usuario
dentro de dicho entorno físico.
Tanto los modelos basados en cámara, como los basados en Java 3D permiten a los
programadores especificar la forma del fustrum de la vista y, bajo el control del programa,
colocarlo, moverlo, orientarlo..., dentro del entorno virtual. Sin embargo, lo que varía entre
unos modelos y otros es cómo lo hacen. Los modelos basados en Java 3D permiten
configurar el fustrum de acuerdo con 6 grados de libertad (que se corresponden con los
dispositivos de reastreo o tracking), de tal forma que puede modificar dicho fustrum para
generar imágenes adaptadas al punto de vista concreto del usuario final.
13.4.1 Justificación
Los modelos de vista basados en cámara propios de APIs de bajo nivel, proporcionan a los
programadores el control de todos los parámetros de la generación de imágenes. Esto
resulta muy apropiado cuando se están desarrollando aplicaciones personalizadas, pero
resulta menos adecuado cuando se trata de sistemas que intentan disponer de una mayor
aplicabilidad, sistemas como visores o navegadores que cargan y muestran mundos enteros
como un solo elemento o sistemas donde el usuario final observa, navega e incluso
interactúa con el mundo virtual generado.
Los modelos de vista basados en cámara emulan una cámara en el mundo virtual, no
a una persona en dicho mundo. Los desarrolladores deben cambiar la posición de la cámara
continuamente para emular a un humano en el mundo virtual. El modelo de vista de Java
3D incorpora el head tracker directamente, en caso de que exista, sin ningún tipo de
68

esfuerzo adicional por parte del desarrollador y proporcionando a los usuarios la sensación
de encontrarse dentro del mundo virtual.
Cuando el modelo de vista de Java 3D opera en un entorno sin head tracker y
cuando genera las imágenes en una sola pantalla, actúa de forma muy similar a los
tradicionales modelos de vista basados en cámara, pero con la funcionalidad añadida de ser
capaz de generar, de forma transparente, vistas estéreo.
13.4.2 Influencia del entorno físico en la vista
No se resulta muy adecuado dejar que la aplicación controle todos los parámetros de
visualización si el entorno físico determina parte de dichos parámetros. Por ejemplo, en
caso de disponer de un dispositivo de salida “montado en la cabeza” (algo como un casco o
unas gafas multimedia), es dicho dispositivo el que determina el punto de vista que debe
usar la aplicación. Además, diferentes dispositivos tienen diferentes puntos de vista, con lo
cual, sería inútil dejar prefijados ciertos parámetros de antemano.
Los parámetros de visualización pueden variar mucho dependiendo de los detalles
físicos del entorno del usuario. Factores que influyen mucho en dichos parámetros son el
tamaño del dispositivo físico, dónde se encuentra situado (en una mesa o en la cabeza del
usuario), si el ordenador conoce la posición de la cabeza del usuario en el espacio, la
resolución del dispositivo, etc.
Para explicar todo esto con mayor claridad vamos a ver un pequeño ejemplo.
Supongamos que el usuario se sienta en una alfombra mágica y que la aplicación que esta
utilizando hace volar al usuario por el entorno virtual controlando la posición y orientación
de la alfombra dentro del mundo virtual. Parece, a primera vista, que la aplicación también
tiene que controlar lo que el usuario ve, y lo hace, pero sólo superficialmente. Ahora
podremos ver cómo el entorno del usuario final puede afectar de forma significativa cómo
una aplicación debe construir las transformaciones de visualización.
13.4.2.1 Sistema montado en la cabeza
Supongamos que el usuario ve la alfombra mágica y el mundo virtual a través de un
dispositivo montado en su cabeza y que dispone de un head tracker. A medida que la
aplicación hace volar la alfombra por el mundo virtual, el usuario puede girarse para mirar
a la izquierda o a la derecha o hacia la parte trasera de su alfombra.
Debido a la utilización del head tracker, el generador de imágenes dispone de la
información suficiente para saber hacia dónde mira el usuario y no necesita dibujar la
escena en frente de la alfombra mágica. La vista que el generador de imágenes dibuja en el
dispositivo montado en la cabeza del usuario debe adaptarse a lo que el usuario vería si la
experiencia ocurriera en el mundo real.
69

13.4.2.2 Sistema montado en una habitación
Supongamos ahora un entorno ligeramente diferente. El usuario se sienta en una habitación
oscura delante de una gran pantalla de proyección. La aplicación todavía controla el vuelo
de la alfombra, sin embargo, la posición y orientación de la cabeza del usuario apenas
influye en la imagen dibujada en la pantalla. Si el usuario mira a izquierda o a derecha, sólo
ve la habitación oscura. La pantalla no se mueve y, como la pantalla representa, de alguna
forma, la ventana frontal de la alfombra, la habitación representa el interior oscuro de la
misma. Si se añadieran pantallas a la izquierda y a la derecha, se le proporcionaría al
conductor de la alfombra una visión más completa del mundo virtual que rodea a la
alfombra. En ese caso, el usuario podría ver la vista a la derecha o la izquierda de la
alfombra simplemente girando su cabeza.
En el ejemplo usando un dispositivo “montado en la cabeza” , la posición y
orientación de la cabeza del usuario afectan significativamente la posición y orientación de
la cámara del modelo, pero apenas influye en la matriz de proyección. En el ejemplo con un
sistema “montado en la habitación” , la posición y orientación de la cabeza del usuario no
influye apenas en la posición y orientación de la cámara, pero sí influye en la matriz de
proyección.
Desde una perspectiva basada en una cámara, el desarrollador de la aplicación debe
construir la posición y orientación de la cámara combinando el componente relativo al
mundo virtual (la posición y orientación de la alfombra) y el componente del mundo físico
(la posición y orientación de la cabeza del usuario).
El modelo de vista de Java 3D incorpora las abstracciones apropiadas para
compensar toda esta posible variabilidad de los entornos de usuario.
13.4.3 Separación de físico y virtual
El modelo de visualización de Java 3D separa el entorno virtual, donde el programador ha
colocado los distintos objetos unos en relación con los otros, del entorno físico, donde el
usuario sí existe, ve los dispositivos de salida del ordenador y manipula los de entrada.
Java 3D define también una correspondencia fundamental entre el mundo físico del
usuario y el mundo virtual de la aplicación gráfica. Esta correspondencia define un espacio
común donde una acción llevada a cabo por el usuario afecta a los objetos en el mundo
virtual y donde cualquier actividad de los objetos en el mundo virtual afecta la vista del
usuario.
13.4.3.1 El mundo virtual
El mundo virtual es un espacio común en el que existen los objetos virtuales. El sistema de
coordenadas del mundo virtual existe de forma relativa a un Locale de alta resolución (cada
objeto Locale define el origen de unas coordenadas del mundo virtual para todos los objetos
70

unidos a dicho Locale). El objeto Locale que contiene al objeto ViewPlatform activo define
las coordenadas del mundo virtual utilizadas para generar las imágenes. Java 3D
transformará, eventualmente, todas las coordenadas asociadas con los elementos del grafo
de escena para incluirlos en el espacio común del mundo virtual.
13.4.3.2 El mundo físico
El mundo físico es, simplemente, el mundo real. Es el espacio en el que existe el usuario en
el que mueve su cuerpo, su cabeza, sus manos... Es el espacio en el que cualquier rastreador
físico define sus coordenadas locales y en el que se describen varios sistemas de
coordenadas de calibración.
El mundo físico es un espacio, no un sistema de coordenadas común entre diferentes
instancias de ejecución de Java 3D. Así, si dos ordenadores diferentes, en dos posiciones
físicas distintas en el mundo están ejecutando una aplicación a la vez, Java 3D no dispone
ningún mecanismo directo para relacionar los sistemas de coordenadas del mundo físico de
cada uno de ellos. Son las características propias de cada entorno las que definen el sistema
de coordenadas local de cada mundo físico.
13.4.4 Objetos que definen la vista
Java 3D distribuye los parámetros del modelo de visualización en distintos objetos: el
objeto View y los objetos componentes asociados con él, el objeto PhysicalBody, el objeto
PhysicalEnvironment, el objeto Canvas3D y el objeto Screen3D.
A continuación se describe brevemente el papel de cada uno de estos objetos en el
sistema:
ViewPlatform. Es un nodo hoja que ubica una vista dentro de un grafo de escena.
Sus padres especifican su posición, orientación y escala en el mundo virtual.
Canvas3D. El objeto Canvas3D encapsula todos los parámetros relativos a la
ventana en la que se está renderizando. Cuando se une un objeto Canvas3D a un
objeto View, Java 3D renderiza la vista especificada en la pantalla. Varios objetos
Canvas3D pueden referirse al mismo objeto View. Canvas3D extiende el objeto
java.awt.Canvas para incluir información relativa a los objetos 3D como pueden ser
el tamaño en píxeles del lienzo, la localización del mismo también en píxeles dentro
de un objeto Screen3D y si el lienzo tiene activada o no la opción de estéreo. Como
todos los objetos Canvas3D contienen una referencia a un objeto Screen3D, y
debido a que los objetos Screen3D definen el tamaño de un píxel en unidades física,
Java 3D puede convertir un tamaño en píxeles en un tamaño del mundo real en
metros. También puede determinar la posición y orientación del Canvas3D en el
mundo real.
71

Screen3D. El objeto Screen3D encapsula todos los parámetros asociados con la
pantalla física que contiene el lienzo. Estos parámetros pueden ser la anchura y
altura de la pantalla en píxeles, las dimensiones físicas de la pantalla y varios
valores de calibración física. Este objeto proporciona la versión 3D del objeto
Screen de AWT. Java 3D permite tener activos varios objetos Screen3D de forma
simultánea. Por supuesto sólo se pueden utilizar varias pantallas si la configuración
de la máquina que se utiliza dispone de varias pantallas de salida. Un objeto
Screen3D representa un dispositivo independiente. La configuración más
convencional para Java 3D es un ordenador de sobremesa con una sola pantalla.
Sin embargo, Java 3D puede aprovechar entornos en los que se necesitan tres o más
pantallas. Estos entornos requieren un mayor cuidado en la inicialización y en la
calibración.
Java 3D debe conocer las posiciones relativas de los objetos Screen3D (de cada uno
respecto del resto).
View. El objeto View especifica la información necesaria para renderizar el grafo de
escena. El objeto View es el objeto central de Java 3D para coordinar todos los
aspectos de visualización. Todos los parámetros de visualización de Java 3D o bien
están contenidos directamente dentro del objeto View o bien lo están en objetos
accesibles desde un objeto View.
Java 3D permite el uso simultáneo de varios objetos View activos, cada uno de los
cuales puede renderizar uno o más lienzos.
Este objeto coordina todos los aspectos del proceso de renderización. Contiene los
parámetros o referencias a los objetos que contienen los parámetros que determinan
cómo renderizar las imágenes en las ventanas representadas por sus
correspondientes objetos Canvas3D. También contiene el conjunto de lienzos que
representan varias ventanas en una misma vista.
PhysicalBody. El objeto PhysicalBody encapsula todos los parámetros asociados
con el cuerpo físico como pueden ser la posición de la cabeza, del ojo derecho e
izquierdo, los oídos, izquierdo y derecho e incluso la distancia entre ambas pupilas.
El objeto PhysicalBody contiene información relativa a las características físicas
del cuerpo del usuario. Los parámetros relativos a la cabeza permiten a dichos
usuarios especificar las características de su propia cabeza para adaptar las
aplicaciones de Java 3D de tal forma que se adapten a su propia geometría. El
objeto PhysicalBody define un sistema de coordenadas relativo a la cabeza del
espectador, que sirve de punto de referencia para definir los parámetros de su
cabeza.
Dicho sistema de coordenadas tiene su origen en el plano bilateral de simetría de la
cabeza, aproximadamente a mitad de camino entre el ojo izquierdo y el derecho. El
origen del sistema de coordenadas de la cabeza se denomina ojo central. La parte
positiva del eje de abscisas se extiende a la derecha y el eje de ordenadas, hacia
72

arriba. El eje positivo de la componente z se introduce en la cabeza. Los valores se
dan en metros.
PhysicalEnvironment. El objeto PhysicalEnvironment encapsula toda la
información relativa al entorno físico como pueden ser parámetros de calibración de
los distintos tipos de rastreo.
Estos objetos describen, conjuntamente, la geometría de visualización. El generador
de imágenes de Java 3D utiliza esta información para construir las matrices de
visualización y de proyección apropiados. El hecho de que estén creados desde un
punto de vista geométrico proporciona a estos objetos una gran flexibilidad para
generar vistas, lo cual les permite cambiar fácilmente de configuración.
13.4.5 ViewPlatform: Un lugar en el mundo virtual
Un nodo hoja ViewPlatform define un sistema de coordenadas y, por lo tanto, un punto de
referencia relativo a su origen asociado en el mundo virtual. Este objeto sirve como punto
de unión para los objetos de visualización y como base para determinar el punto de vista de
la renderización.
Los nodos que se sitúan por encima del ViewPlatform en el grafo de escena
determinan la posición de dicho ViewPlatform así cómo está orientado dentro del mundo
virtual. Si se modifica el objeto Transform3D asociado con un nodo TransformGroup en
cualquier lugar por encima de un ViewPlatform, se puede permitir que una aplicación o
comportamiento pueda mover dicho ViewPlatform de cualquier forma dentro del mundo
virtual.
Un VirtualUniverse puede tener varios ViewPlatform, pero un objeto View sólo
puede unirse a un único ViewPlatform. Así pues, cada generación de imágenes en un
Canvas3D se realiza desde el punto de vista de un único ViewPlatform.
Una aplicación puede navegar por el mundo virtual modificando el padre de un
objeto ViewPlatform, el objeto TransformGroup. Aplicaciones que pueden modificar la
ubicación y orientación de un ViewPlatform son los navegadores, visualizadores de objetos
incluso juegos de búsqueda. El control del objeto ViewPlatform puede producir resultados
muy útiles e interesantes.
Un grafo de escena puede contener varios objetos ViewPlatform. Si un usuario
separa un objeto View de un objeto ViewPlatform y, posteriormente, une ese mismo objeto
View a otro ViewPlatform diferente, la imagen que se muestre se generará desde el punto de
vista del nuevo objeto ViewPlatform.
73

13.4.6 El sistema de coordenadas
El modelo básico de visualización consta de ocho o nueve sistemas de coordenadas,
dependiendo de si el sistema del usuario es montado “en cabeza” o “en habitación”.
13.4.6.1 Sistema de coordenadas “montados en habitación”
El sistema de coordenadas montado en habitación se divide en sistema de coordenadas
virtual y sistema de coordenadas físico.
Los sistemas de coordenadas situados dentro de la zona gris existen en el mundo
virtual y los situados fuera de dicha zona existen en el mundo físico. El sistema de
coordenadas de coexistencia existe en ambos mundos.
13.4.6.1.1 Sistemas de coordenadas virtuales
Sistema de coordenadas del mundo virtual
El sistema de coordenadas del mundo virtual encapsula el sistema de coordenadas unificado
para todos los objetos del grafo de escena localizados en el entorno virtual. Para un objeto
View dado, el sistema de coordenadas del mundo virtual lo define el objeto Locale que
contiene el objeto ViewPlatform unido al objeto View. Como ya se ha comentado, se trata
de un sistema de coordenadas diestro.
Sistema de coordenadas de ViewPlatform
El sistema de coordenadas del objeto ViewPlatform es el sistema de coordenadas local.
Sistema de coordenadas de coexistencia
Un objetivo fundamental, e implícito, de cualquier modelo de visualización es poder
mapear una porción específica del mundo físico en una zona específica del mundo virtual.
Una vez establecida esta relación, se puede preguntar dónde está la cabeza o la mano del
usuario dentro del mundo virtual o dónde se encuentra un objeto virtual en el mundo físico.
De esta forma el usuario físico puede interactuar con objetos propios del mundo virtual y
viceversa. Para establecer este mapeado Java 3D define un sistema de coordenadas especial
llamado de coexistencia y que se define de tal forma que existe en ambos mundos, el virtual
y el físico.
El sistema de coordenadas de coexistencia existe en ambos mundos. Las dos
transformaciones que pasan del sistema de coordenadas de coexistencia al sistema de
coordenadas del mundo virtual y al contrario, disponen de la información necesaria para
expandir o contraer el mundo virtual relativo al mundo físico, así como de toda la
información necesaria para colocar y orientar el mundo virtual relativamente al mundo
físico. Si estas transformaciones se cambian, se modifica también lo que puede ver el
74

usuario. Para mover al usuario a través del mundo virtual se modifican dichas
transformaciones.
13.4.6.1.2 Sistemas de coordenadas físicos
Sistema de coordenadas de cabeza
Este sistema de coordenadas permite que una aplicación disponga de la información
relativa a la geometría de la cabeza del usuario. Proporciona información suficiente como
para determinar la posición de los ojos y de los oídos.
Sistema de coordenadas de pantalla
Este sistema de coordenadas se corresponde con el sistema de coordenadas físico del
generador de imágenes. Se define de tal forma que su origen se encuentra en la esquina
inferior izquierda del área de visualización. Este sistema de coordenadas es diferente tanto
del que correspondería a una pantalla a la izquierda como a una pantalla a la derecha. Estos
otros sistemas de coordenadas se definen exclusivamente para sistemas montados ‘en
cabeza’.
Sistema de coordenadas del head tracker
Este sistema de coordenadas se corresponde con el sensor de seis grados de libertad unido a
la cabeza del usuario. Describe la posición de la cabeza del usuario en cada momento.
Sistema de coordenadas de la base del tracker
Se corresponde con el emisor asociado con los rastreadores de posición y orientación
absolutas. Este sistema de coordenadas suele estar fuertemente unido al mundo físico.
13.4.6.2 Sistemas de coordenadas “montados en cabeza”
Estos sistemas de coordenadas también se dividen en físicos y virtuales. En la siguiente
figura se muestran todos ellos. Como ocurría con los sistemas de coordenadas “montados
en habitación” los localizados en el área gris corresponden al mundo virtual y los que se
encuentran fuera de dicha zona corresponden al mundo real. El sistema de coexistencia
existe, también aquí, en ambos mundos. Además de dichos sistemas de coordenadas, Java
3D añade dos nuevos sistemas de coordenadas de pantalla, uno para cada ojo del usuario.
Sistema de coordenadas de pantalla izquierda y derecha
Estos dos sistemas de coordenadas se corresponden con el sistema de coordenadas físico
asociado con cada uno de los ojos. Su origen se encuentra en la esquina inferior izquierda
de la zona de pantalla. Ambos planos (los de los dos ojos) no tienen por qué estar en
paralelo.
75

13.5 RESUMEN
En este capítulo, se han analizado de forma general los mecanismos que proporciona el API
de Java 3D para la construcción de escenas en tres dimensiones. Aunque se trata de una
descripción a grandes rasgos, es suficiente para descubrir toda la potencia que puede
obtenerse con esta API.
Analizada la entidad de Java 3D y los objetivos que se persiguen con su diseño, el
documento se centra en el análisis de los conceptos elementales y la estructura básica en la
que se basa esta API, el grafo de escena.
A continuación, se describe cómo se estructura el sistema de coordenadas utilizado
en la representación de elementos 3D centrándose en la descripción de las coordenadas de
alta resolución que permiten ajustar las necesidades de precisión para describir cualquier
elemento a modelar (desde una galaxia a un átomo).
El grafo de escena proporciona una descomposición del universo virtual en dos
grupos principales: la rama de contenidos y la rama de visualización. Basándose en esta
separación, el trabajo se divide, de forma lógica, en dos grandes grupos describiendo cada
una de dichas ramas. Dentro de la rama de contenidos, se han descrito los mecanismos
principales que proporciona Java 3D para la generación de figuras geométricas. En primer
lugar, se comentan las clases involucradas en la generación de figuras primitivas (conos,
cilindros, esferas...) para luego centrarse en mecanismo más potentes que permiten generar
elementos más complejos. En este punto, se ha analizado como Java 3D realiza el
tratamiento de puntos para generar elementos de volumen. Para ello, se introduce la clase
GeometryArray y sus derivadas describiendo los principios de funcionamiento de dichas
clases. Dentro de la generación de contenidos se analiza la utilización de texto 2D y 3D.
Además, esta API proporciona mecanismos adicionales de ayuda para la generación de
universos virtuales: cargadores de escenas y clases especializadas de tratamiento de puntos
(GeometryInfo, NormalGenerator...).
Una vez tratados los mecanismos para crear objetos dentro de una escena, se pasa a
describir cómo alterar y configurar la apariencia de cada uno de los objetos. El primer
elemento sobre el que se trabaja es el fondo de la propia escena, para, a continuación,
centrarse en la descripción de los mecanismos para modelar la apariencia del resto de
elementos. En este punto se aborda, de forma general, el tema de la gestión de luces y de
texturas.
Como punto final de la descripción de la rama de contenidos, se introducen los
mecanismos para interactuar con el usuario así como para crear movimiento y animación en
Java 3D. En este punto, y en primer lugar, se describen ciertos conceptos esenciales que
dan soporte tanto a la gestión de la interacción con el usuario como a la generación de
animaciones. Entre estos aspectos generales destacar, el concepto de capacidad que define
qué características de un objeto podrán modificarse en tiempo de ejecución y cuales no, así
como el concepto de comportamiento.
76

Respecto a la interacción con el usuario, se aborda cómo gestionar los dispositivos
básicos de interacción (ratón y teclado) y los comportamientos destinados a ello
(KeyNavigatorBehavior, MouseBehavior...), aunque Java 3D no está limitado a estos
dispositivos.
En cuanto al tema de las animaciones, se aborda, principalmente, el tema de los
interpoladores y las animaciones basadas en el tiempo, dejando entrever otros aspectos
como el morphing.
Tras el análisis de la generación de contenido, el siguiente paso es la descripción de
todo lo relacionado con la forma en la cual el sistema visualiza dicho contenido. Para ello,
se abordan los conceptos principales en los que se basa la rama de visualización que es la
que posee todos los parámetros para configurar la forma en la que se mostrarán los objetos.
En este apartado, se introducen ciertos conceptos de interés que caracterizan a Java 3D
como es el hecho de superar el concepto de cámara como forma tradicional de visualizar un
entorno 3D incorporando aspectos más avanzados como son los head trackers que permiten
considerar al usuario como parte de la escena 3D controlando en todo momento su
posición, y tomando decisiones en base a dicha posición. Se analizar cómo se combina
mundo físico y mundo virtual en Java 3D y como a través de un amplio número de sistemas
de coordenadas, esta API puede llegar a corresponder de forma precisa ambos mundos.
77

13.6 CONCLUSIONES
A lo largo de este trabajo se ha podido comprobar, de forma general, la potencia de Java 3D
como entorno para la generación de escenas en tres dimensiones.
La verdad es que se podía haber profundizado mucho más en todo lo referente a
métodos y clases, pero no se ha considerado oportuno ya que dicho nivel de detalle queda
fuera de las pretensiones de este trabajo. Por el contrario, se ha tratado de dar una visión
amplia de los diferentes conceptos y elementos involucrados en la generación de entornos
en tres dimensiones utilizando Java 3D.
La versión de Java 3D que se ha analizado en este documento es la que se ejecuta
sobre sistemas gráficos basados en OpenGL con lo cual, aunque existen diferencias
inherentes en la filosofía utilizada por ambas APIs, hay elementos (como por ejemplo el
modelo de iluminación) que son prácticamente equivalentes.
Una diferencia importante entre Java 3D y OpenGL es el modo de realizar tanto las
modificaciones como la configuración de la escena. Mientras que en OpenGL las
operaciones se hacen en cualquier orden y con actualizar la escena, todo queda en su sitio,
en Java 3D es necesario seguir un orden tanto en la creación de escenas como en su
modificación. Esto es debido a que Java 3D utiliza una estructura jerarquizada (un grafo de
escena) para representar los distintos elementos. El uso del grafo de escena permite una
representación gráfica de la escena previa a su generación por parte del sistema. Además, la
estructura del grafo de escena hace posible aislar distintos componentes del mismo, trabajar
con zonas del gráfico de forma aislada, incluso compilar partes del grafo de forma aislada
y, posteriormente, unirlas al grafo de escena en su lugar correspondiente.
Por otro lado, Java 3D es un sistema muy orientado a la compatibilidad con otros
entornos (es capaz de cargar escenas generadas en diferentes tipos de sistemas) así como a
la versatilidad con multitud de dispositivos (su estructura de visualización permite adaptar
un mismo grafo de escena a variadas configuraciones físicas realizando las mínimas
modificaciones).
78

13.7 BILIOGRAFÍA Y RECURSOS
Documentación:
- Pratdepadua J. J. “Programación en 3D con Java 3D”. Editorial Ra-Ma. 2003.
- Sun Microsystems. Java 3D 1.3 API Documentation (documentation does not
include documentation for utilities).
Disponible en http://java.sun.com/products/javamedia/3D/forDevelopers/J3D_1_3_API/j3dapi/index.html
- Sun Microsystems. Java 3D 1.3 API Specification Guide.
Disponible en http://java.sun.com/products/javamedia/3D/forDevelopers/J3D_1_3_API/j3dguide/index.html
June 2002.
- Sun Microsystems. Java 3D API Tutorial.
Disponible en http://java.sun.com/developer/onlineTraining/java3d/index.html
September 2000.
- Java 3D 1.3.2 API Documentation (include information for utilities).
Disponible en http://download.java.net/media/java3d/javadoc/1.3.2/index.html
- Java 3D FAQ.
Disponible en http://wiki.java.net/bin/view/Javadesktop/Java3DFAQ
Ejemplos de código fuente
- Java 3D examples.
http://www.java2s.com/Code/Java/3D/Catalog3D.htm
Foros de debate
- Sun Developer Network. Multimedia and Imaging APIs - Java 3D.
http://forum.java.sun.com/forum.jspa?forumID=21
- java.net Forums. Java Desktop Technologies. Java 3D.
http://forums.java.net/jive/forum.jspa?forumID=70
79

Otros sitios de interés
- The Java 3D Home Page
http://java.sun.com/products/java-media/3D/
- The Java 3D Graphics Community
http://www.j3d.org/
- The j3d.org Code Repository
http://code.j3d.org/
- Java 3D VRML 97 Loader
https://j3d-vrml97.dev.java.net/
- Project Looking Glass - A Comprehensive Overview of the Technology
Disponible en https://lg3d-core.dev.java.net/files/documents/1834/30923/LG3D-
Overview.pdf
Rev. 0.2 March 14, 2006.
- Getting Started with the Project Looking Glass Developer’s Release
https://lg3d.dev.java.net/lg3d-getting-started.html
- Project Looking Glass Developer’s Guide
https://lg3d.dev.java.net/lg3d-developers-guide.html
- Project Looking Glass Demo Applications
https://lg3d-demo-apps.dev.java.net/
- Project Looking Glass Application Tutorial 1 - An introduction to the lg3d
framework
https://lg3d.dev.java.net/tutorial/tutorial1.html
- Project Looking Glass Application Tutorial 2 – Simple manipulations and user
interactions
https://lg3d.dev.java.net/tutorial/tutorial2.html
- Project Looking Glass Application Tutorial 3 – Complex manipulations and user
interaction
https://lg3d.dev.java.net/tutorial/tutorial3.html
- java.net Forums – Project Looking Glass 3D
http://forums.java.net/jive/forum.jspa?forumID=80
80