El API Java 3D

El API Java 3D

Todo programa Java 3D está, al menos, parcialmente ensamblado por objetos del árbol de clases Java 3D. Esta colección de objetos describe un universo virtual, que va a ser renderizado. El API define unas 100 clases presentadas en el paquete javax.media.j3d

Hay cientos de campos y métodos en las clases del API Java 3D. Sin embargo, un sencillo universo virtual que incluya animación puede construirse con unas pocas clases. Este capítulo describe un conjunto mínimo de objetos y sus interacciones para renderizar un universo virtual.

Esta página incluye el desarrollo de un sencillo pero completo programa Java 3D, llamado HelloJava3Dd.java, que muestra un cubo giratorio. El programa de ejemplo se desarrolla de forma incremental, y se presenta en varias versiones, para demostrar cada parte del proceso de programación Java 3D.

Además del paquete corazón de Java 3D, se usan otros paquetes para escribir programas Java 3D. Uno de estos paques es com.sun.j3d.utils el que normalmente se referiere como clases de utilidades de Java 3D. El paquete de las clases corazón incluye sólo las clases de menor nivel necesarias en la programación Java 3D.

Las clases de utilidades son adiciones convenientes y poderosas al corazón. Estas clases se dividen en cuatro categorías: cargadores de contenidos, ayudas a la construcción del escenario gráfico, clases de geometría y utilidades de conveniencia.

Al utilizar las clases de utilidades se reduce significativamente el número de líneas de código en un programa Java 3D. Además de las clases de los paquetes corazón y de utilidades de Java 3D, todo programa 3D usa clases de los paquetes java.awt y javax.vecmath. El paquete java.awt define el "Abstract Windowing Toolkit" (AWT). Las clases AWT crean una ventana para mostrar el renderizado. El paquete javax.vecmath define clases de vectores matemáticos para puntos, vectores, matrices y otros objetos matemáticos.

En el resto del texto, el término objeto visual se utilizará para referirnos a un "objeto del escenario gráfico" (por ejemplo, un cubo o una esfera). El término objeto sólo se usará para referirse a un ejemplar de una clase. El término contenido se usará para referirnos a objetos visuales en un escenario gráfico como un todo.

Construir un Escenario Gráfico

Un universo virtual Java 3D se crea desde un escenario gráfico. Un escenario gráfico se crea usando ejemplares de clases Java 3D. El escenario gráfico está ensamblado desde objetos que definen la geometría, los sonidos, las luces, la localización, la orientación y la apariencia de los objetos visuales y sonoros.

Una definición común de un escenario gráfico es una estructura de datos compuesta de nodos y arcos. Un nodo es un elemento dato y un arco es una relación entre elementos datos. Los nodos en un escenario gráfico son los ejemplares de las clases Java 3D. Los arcos representan dos tipos de relaciones entre ejemplares Java 3D.

La relación más común es padre-hijo. Un nodo Group puede tener cualquier número de hijos, pero sólo un padre. Un nodo hoja sólo puede tener un padre y no puede tener hijos. La otra relación es una referencia. Una referencia asocia un objeto NodeComponent con un nodo del escenario gráfico. Los objetos NodeComponent definen la geometría y los atributos de apariencia usados para renderizar los objetos visuales.

Un escenario gráfico Java 3D está construido de objetos nodos con relaciones padre-hijo formando una estructura de árbol. En una estructura de árbol, un nodo es el raíz. Se peude acceder a otros nodos siguiendo los arcos desde el raíz. Los nodos de un árbol no forman bucles. Un escenario gráfico está formado desde los árboles con raíces en los objetos Locale. Los NodeComponents y las referencias a arcos no forman parte del escenario gráfico.

Sólo existe un camino desde la raíz de un árbol a cada una de las hojas; por lo tanto, sólo hay un camino desde la raíz hasta el escenario gráfico de cada nodo hoja. El camino desde la raíz de un escenario gráfico hasta una hoja especificada es el camino al escenario gráfico del nodo hoja. Como un camino de un escenario gráfico trata exactamente con un sola hoja, hay un camino de escenario gráfico para cada hoja en el escenario.

Todo camino de escenario gráfico en un escenario gráfico Java 3D especifica completamente la información de estado de su hoja. Esta información incluye, la localización, la orientación y el tamaño del objeto visual. Consecuentemente, los atributos visuales de cada objeto visual dependen sólo de su camino de escenario gráfico. El renderizador Java 3D se aprovecha de este echo y renderiza las hojas en el orden que él determina más eficiente. El programador Java 3D normalmente no tiene control sobre el orden de renderizado de los objetos.

Las representaciones gráficas de un escenario gráfico pueden servir como herramienta de diseño y/o documentación para los programas Java 3D. Los escenarios gráficos se dibujan usando símbolos gráficos estándards como se ve en la Figura 1-1. Los programas Java 3D podrían tener más objetos que los que hay en su escenerio gráfico.

Para diseñar un universo virtual Java 3D se dibuja un escenario gráfico usando un conjunto de símbolos estándard. Después de completar el diseño, este escenerio gráfico es la especificación para el programa. Después de completar el programa, el mismo escenario gráfico es una representación concisa del programa (asumiendo que se siguió la especificación).

Cada uno de los símbolos mostrados al lado izquierdo de la Figura 1.1 representa un sólo objeto cuando se usa en un escenario gráfico. Los dos primeros símbolos representan objetos de clases específicas: VirtualUniverse y Locale. Lo siguientes tres símbolos de la izquierda representan objetos de las clases Group, Leaf, y NodeComponent. Estos tres símbolos normalmente tienen anotaciones para indicar la subclase del objeto específico. El último símbolo se usa para representar otras clases de objetos.

El símbolo de la flecha sólida representa una relación padre-hijo entre dos objetos. La flecha punteada es una referencia a otro objeto. Los objetos referenciados pueden ser compartidos entre diferentes ramas de una escenario gráfico. En la Figura 1-2, podemos ver un sencillo escenario gráfico:

Es posible crear un escenario gráfico ilegal. Podemos ver uno en la Figura 1-3. Este escenario es ilegal porque viola las propiedades de un DAG. El problema son los dos objetos TransformGroup que tienen al mismo objeto Shape3D como hijo. Recuerda que una hoja sólo puede tener un padre. En otras palabras, sólo puede haber un camino desde el objeto Locale hasta la hoja (o un camino desde la hoja hasta el objeto Loale).

Podríamos

...