Java 3D

Este m�dulo presenta las t�cnicas para proporcionar detalles de los objetos visuales a trav�s de sombras y texturas. Esta p�gina explica el modelo de iluminaci�n y c�mo utilizar luces en Java 3D para conseguir sombras.

Java 3D sombrea los objetos visuales bas�ndose en la combinaci�n de sus caracter�sticas materiales y en las luces del universo virtual. El sombreado resulta de aplicar un modelo de iluminaci�n a un objeto visual en presencia de fuentes de luz. La siguiente secci�n da una descripci�n del modelo de iluminaci�n usado en el renderizador de Java 3D y c�mo la luz interact�a con las caracter�sticas materiales para proporcionar sombreado. Cada una de las siguientes secciones explica las caracter�sticas relevantes del API Java 3D para el modelo de iluminaci�n.

�Sombreado en Java 3D

Sombrear objetos visuales en Java 3D depende de muchos factores. Esta secci�n proporciona una descripci�n abreviada del modelo de iluminaci�n de Java 3D, del modelo de color, y del modelo de sombreado. La especificaci�n del API Java 3D presenta una informaci�n m�s detallada sobre el modelo de iluminaci�n de Java 3D. Como la mayor parte de la iluminaci�n de Java 3D y del modelo de sombreado se basa en OpenGL, se puede encontrar m�s informaci�n en p�ginas sobre OpenGL.

Modelo de Iluminaci�n

En el mundo real, los colores que percibimos son una combinaci�n de las caracter�sticas f�sicas del objeto, de las caracter�sticas de las fuentes de luz, de las posiciones relativas de los objetos a las fuentes de luz, y del �ngulo desde el cual se ve el objeto. Java 3D utiliza un modelo de iluminaci�n para aproximar la f�sica del mundo real. El resto de esta secci�n explica el modelo de iluminaci�n de Java 3D en t�rminos generales. La secci�n E.2 de la especificaci�n del API Java 3D presenta las ecuaciones matem�ticas para el modelo de iluminaci�n Java 3D.

La ecuaci�n del modelo de iluminaci�n depende de tres vectores: la superficie normal (n), la direcci�n de la luz (l), y la direcci�n al ojo del espectador (e) adem�s de las caracter�sticas materiales del objeto y de las caracter�sticas de la luz. La Figura 6-1 muestra los tres vectores para dos v�rtices de una superficie esf�rica. Los vectores para cada v�rtice pueden tener distintas direcciones dependiendo de espec�ficidades de la escena. Cuando los vectores de la luz y del ojo var�an, se c�lculan en tiempo de ejecuci�n. Por lo tanto, cada v�rtice de la esfera potencialmente se renderiza como una sombra diferente.

El modelo de iluminaci�n incorpora tres tipos de reflexiones de luz del mundo real: ambiente, difuso, y especular. La reflexi�n ambiente resulta de la luz ambiente, luz constante de bajo nivel, en una escena. La reflexi�n difusa es la reflexi�n normal de una fuente de luz desde un objeto visual. Las reflexiones especulares son las reflexiones sobreiluminadas de una fuente de luz sobre un objeto, que ocurren en ciertas situaciones.

La Figura 6-2 muestra una esfera y un plano renderizados por Java 3D. Los tres tipos de reflexi�n se pueden ver en la esfera de la Figura 6-2. La parte m�s oscura de la esfera exhibe s�lo la reflexi�n ambiente. El centro de la esfera est� iluminado por la luz difusa y ambiente. Con una esfera azul y una luz blanca, la reflexi�n difusa es azul. La parte m�s brillante de la esfera es el resultado de la reflexi�n especular con reflexiones ambiente y difusa.

Ojo Local contra Vectores de Ojos Infinitos

Si cada v�rtice de cada objeto visual en una escena requiere un vector de luz, un vector del ojo, y el c�lculo de la sombra, una porci�n significativa del c�lculo de representaci�n se utiliza en los v�rtices sombreados. La cantidad de c�lculo puede reducirse si el vector de luz, o el vector del ojo, o ambos vectores son constantes. El vector de luz es constante cuando usa una luz direccional.. El vector del ojo es constante por defecto, aunque podemos especificar un vector variable del ojo usando un m�todo del objeto View.

Efectos inter-objetos no Considerados

Mientras que el modelo de iluminaci�n se basa en la f�sica, los fen�menos f�sicos complejos no se modelan. Obviamente, la sombra echada por la esfera sobre el plano no est� en la Figura 6-2. No tan obvio, tambi�n falta la luz reflejada de la esfera sobre el plano. Tambi�n falta la luz reflejada desde el plano sobre la esfera que de nuevo se refleja en el plano... etc�tera.

A menudo es dif�cil comprender la complejidad del c�lculo de la acci�n de la luz. Consideremos la dificultad de calcular c�mo cada gota del agua se comporta en una ducha. Las gotas vienen de la cabeza de la ducha en distintas direcciones. Cuando encuentran un objeto, la colisi�n que resulta produce muchas gotas m�s peque�as que viajan en distintas direcciones. El proceso se repite muchas veces antes de que el agua se vaya por el desague. La complejidad de interacciones de la luz con los objetos visuales es muy semejante. Algunas de las diferencias entre los comportamientos del agua y la luz son que la luz no tiene ninguna adherencia (luz no se pega a los objetos visuales) y el efecto de la gravedad es insignificante para la luz.

Para reducir la complejidad del c�lculo, el modelo de iluminaci�n considera solamente un objeto visual al mismo tiempo. Consecuentemente, las sombras y las reflexiones inter-objetos no son renderizadas por el modelo de iluminaci�n. Estos dos efectos requieren la consideraci�n de todos los objetos junto con sus posiciones relativas en el momento de la representaci�n. Se necesita considerablemente m�s c�lculo para renderizar una sola escena con efectos inter-objetos. Java 3D, y el resto de los sistemas gr�ficos en tiempo real, no hacen caso de efectos inter-objetos en la representaci�n. Algunos de los efectos ignorados del mundo real se pueden agregar a las escenas cuando sea necesario.

Modelo de Color

El modelo del color no est� basado en la f�sica. Java 3D modela el color de las luces y los materiales como una combinaci�n de rojo, verde, y azul. El color blanco, como el color de la luz o del material, es la combinaci�n de los tres componentes con la intensidad m�xima. Cada luz produce un solo color de luz especificado por un tuple RGB. El modelo de iluminaci�n se aplica a cada uno de los componentes del color RGB. Por ejemplo, una bola roja en presencia de una luz azul no ser� visible puesto que la luz azul no se refleja desde un objeto rojo. En realidad, el color es una combinaci�n de muchas longitudes de onda de la luz, no solo tres. El modelo de color RGB representa muchos colores, pero no todos.

Influencia de las Luces

En Java 3D, la porci�n de una escena donde los objetos visuales son iluminados por una fuente de luz determinada se llama la regi�n de influencia de ese objeto de luz. La regi�n de influencia m�s simple para una fuente de luz usa un objeto Bounds y el m�todo setInfluencingBounds() de Light. Cuando un objeto fuente de luz con l�mites de influencia intersecciona con los l�mites de un objeto visual, se utiliza la luz para sombrear todo el objeto. Los l�mites de influencian de una luz determinan qu� objetos iluminar, no qu� porciones de objetos se iluminan.

Modelo de Sombreado

El modelo de iluminaci�n sombrea todos los v�rtice de un objeto visual por cada luz de influencia. La sombra de un v�rtice es la suma de las sombras proporcionadas por cada fuente de luz para la v�rtice. El resto de un objeto visual se sombrea bas�ndose en la sombra de los v�rtices. El modelo de sombra de un objeto visual, especificado como atributo Appearance NodeComponent, determina c�mo se hace el sombreado para el resto del objeto visual.

El ColoringAttributes NodeComponent especifica el modelo de sombra para los objetos visuales donde el modelo de sombra se especifica como uno de SHADE_GOURAUD, SHADE_FLAT, FASTEST, NICEST. Debemos tener cuidado ya que el color de un objeto ColoringAttributes nunca se utiliza en el sombreado.

En el sombrado Gouraud, cada pixel se sombrea con un valor derivado de la interpolaci�n trilinear del valor de la sombra de cada v�rtice del pol�gono que lo encierra. En el sombreado plano, todos los pixeles de un pol�gono se asignan el valor de la sombra a partir de un v�rtice del pol�gono. La Figura 6-3 muestra una esfera sombreada plana y una esfera sombrada Gouraud. La ventaja del sombreado plano es la velocidad en la representaci�n del software. El sombreado de Gouraud tiene la ventaja de la apariencia visual.

Un �ltimo punto antes de ir a un ejemplo; los objetos fuentes de luz no son objetos visuales. Incluso si una fuente de luz se situa dentro de la vista, no ser� renderizada.

�Receta para Iluminar Objetos Visuales

Se necesita una serie de pasos para permitir la iluminaci�n de los objetos visuales en el universo virtual. Adem�s de crear y de personalizar objetos para requisitos particulares de luz, cada objeto de luz debe ser agregado al escenario gr�fico y haber especificado un objeto Bound. Cada objeto visual que se va a sombrear debe tener superficies normales y caracter�sticas de material. Abajo podemos ver la receta con los pasos necesarios:

1. Especificaci�n de la fuente de Luz
   1. seleccionar los l�mites
   2. a�adirla al escenario gr�fico
2. Objeto Visual
   1. superficies
   2. propiedades de material

Si falta algunos de estos elementos no se podr� usar la iluminaci�n. La presencia del objeto Material en un manojo Appearance de un objeto visual permite el modelo de iluminaci�n para ese objeto. Sin el objeto Material el objeto visual ser� coloreado, pero no sombreado por el ColoringAttribute o los colores de v�rtice del objeto Geometry. Si ni uno ni otro est�n presentes, el objeto ser� blanco s�lido. La Figura 6-5 muestra la excepci�n lanzada cuando un objeto visual tiene un objeto Material pero no tiene superficies normales.

javax.media.j3D.IllegalRenderingStateException: Cannot do lighting without
specifying normals in geometry object

Los errores con fuentes de luz pueden no ser f�ciles de encontrar. No hay ning�n aviso de que dejamos sin luz un escenario gr�fico. Ni hay ninguna alerta por no fijar los l�mites de influencia de una fuente de luz. En cualquiera de estos casos, el objeto de luz no tendr� ninguna influencia sobre los objetos visuales en el escenario gr�fico. Un objeto visual especificado correctamente para sombreado (es decir, uno con un objeto Material) en un escenario gr�fico vivo pero fuera de los l�mites de influencia de todos los objetos fuente de luz se renderizar� a negro.

Es posible especificar correctamente una escena en la cual un objeto visual con las caracter�sticas materiales influenciadas por un objeto de luz y que se renderice a negro. La orientaci�n relativa de la luz, el objeto visual, y la direcci�n de la visi�n entran en juego en el renderizado.

�Ejemplos de Luces Sencillas

Seg�n lo mencionado arriba, crear renderizados con sombras implica la especificaci�n apropiada de la fuente de luz y de los objetos visuales. Hasta el momento, ni la clase Light ni los objetos Material se han discutido en detalle. Sin embargo, aprovech�ndo los valores por defecto del API y sus caracter�sticas, podemos proceder a iluminar mundos virtuales. Los primitivos geom�tricos generan superficies normales cuando se solicitan. Los valores por defecto del objeto Material especifican un objeto visual razonable. Los valores por defecto de los constructores de la fuente de luz especifican fuentes de luz utilizables.

Usando la clase SimpleUniverse con los dos m�todos del Fragmento de c�digo 6-1 se produce un universo virtual que incluye una sola esfera con las caracter�sticas materiales con sus valores por defecto iluminada por un solo objeto fuente de luz AmbientLight. El primer m�todo del fragmento del c�digo ensambla un objeto Material con un objeto Apeareance para la esfera. El segundo m�todo crea un objeto BranchGroup para servir como la ra�z de la rama de contenido gr�fico, despu�s agrega los objetos Sphere y AmbientLight al escenario gr�fico. El objeto Material en el manojo del aspecto se agrega al objeto Sphere en la construcci�n de la esfera (l�neas 12 y 13). Un valor por defecto BoundingSphere proporciona la regi�n de influencia para el objeto AmbientLight (l�neas 15 a 17). El diagrama del escenario gr�fico de este mundo virtual aparece en La Figura 6-6.

1.     Appearance createAppearance() {
2.     Appearance appear = new Appearance();
3.     Material material = new Material();
4.     appear.setMaterial(material);
5.
6.     return appear;
7.     }
8.
9.     BranchGroup createScene (){
10.   BranchGroup scene = new BranchGroup();
11.
12.   scene.addChild(new Sphere(0.5f, Sphere.GENERATE_NORMALS,
13.   createAppearance()));
14.
15.   AmbientLight lightA = new AmbientLight();
16.   lightA.setInfluencingBounds(new BoundingSphere());
17.   scene.addChild(lightA);
18.
19.   return scene;
20.   }

Las l�neas 4 y 5 del Fragmento de c�digo 6-1 podr�an ser reemplazadas por la siguiente l�nea que crea y usa un objeto Material an�nimo.

Appear.setMaterial(new Material());

Los objetos Material son completamente personalizables con los par�metros de su constructor, simplificando el uso de objetos Material an�nimos. Por el contrario, crear un objeto Light an�nimo hace mucho m�s d�ficil la adicci�n de l�mites de influencia. Debemos tener en cuenta que el nombramiento del objeto Material puede hacer el objeto sea m�s f�cil de compartir entre varios manojos del aspecto, dando como resultado un funcionamiento mejor.

El SimpleUniverse proporciona los objetos VirtualUniverse y Locale junto con el la rama de vista gr�fica para el diagrama de escenario gr�fico mostrado en la Figura 6-6. Sin una transformaci�n, el objeto Sphere y el objeto BoundingSphere estar�n centrados en el origen, y se interseccionar�n. El objeto Sphere se sombrea por la fuente AmbientLight. La Figura 6-7 muestra la imagen que resulta con un fondo blanco. La especificaci�n del fondo no se muestra en el c�digo.

La esfera de la Figura 6-7 es de color gris uniforme, que es el valor por defecto de la propiedad ambiente del material.

La Figura 6-7 muestra que las escenas iluminadas unicamente con luz ambiente son opacas. Como la iluminaci�n ambiente es uniforme, produce la sombra uniforme. La luz ambiente est� pensada para llenar de luz una escena donde otras fuentes no iluminan. La adici�n de una fuente DirectionalLight har� esta escena m�s interesante.

Insertando el Fragmento de c�digo 6-2 en el Fragmento de c�digo 6-1 se a�ade un DirectionalLight a la rama de contenido gr�fico de la escena. Una vez m�s los valores por defecto se utilizan para la fuente de luz, y se utiliza un BoundingSphere por defecto para la regi�n de influencia. La Figura 6-8 muestra el diagrama del escenario gr�fico que resulta sin los objetos proporcionados por el SimpleUniverse.

1.     DirectionalLight lightD1 = new DirectionalLight();
2.     lightD1.setInfluencingBounds(new BoundingSphere());
3.     // customize DirectionalLight object
4.     scene.addChild(lightD1);

La Figura 6-9 muestra la imagen producida por la combinaci�n de los dos fragmentos del c�digo. La influencia del objeto AmbientLight apenas se puede ver con la fuente DirectionalLight. Obviamente, es necesaria la personalizaci�n de los requisitos particulares de los objetos de luz y/o las caracter�sticas materiales del objeto visual para crear escenas interesantes.

�D�nde A�adir un Objeto Light en un Escenario Gr�fico

La influencia de un objeto de luz en el mundo no est� afectada por la posici�n del objeto de luz en el escenario gr�fico; sin embargo, el objeto bounds referenciado por la luz si lo est�. El objeto bounds est� sujeto a las coordenadas locales del escenario gr�fico donde se inserta el objeto de luz. Consideremos la Figura 6-10 como ejemplo. El mismo objeto BoundingSphere referenciado por dos fuentes de luz proporciona dos regiones de influencia distintas debidas la traslaci�n proporcionada por el objeto TransformGroup. El origen del sistema de coordenadas local del escenario gr�fico debajo del TransformGroup est� 2 metros por debajo del origen del mundo (Locale) y la otra regi�n de la esfera de influencia.

Si dependen o no, los objetos de la fuente de luz del escenario gr�fico en la Figura 6-10 influencian el sombreado (luz) del objeto visual iluminado si los l�mites del objeto visual interseccionan con la regi�n de influencia de los objetos de luz. Especificar la regi�n de influencia de una luz como un s�lo bounds podr�a no funcionar para todas las aplicaciones.

�Clase Light

El API Java 3D proporciona cuatro clases para luces. Todas se derivan de la clase Light. La Figura 6-11 muestra la jerarqu�a de clases de Java 3D relacionada con las luces. Light, una clase abstracta, proporciona los m�todos y las constantes de capacidades asociadas para manipular el estado, color, y los l�mites de un objeto Light. El estado de la luz es un boleano que activa y desactiva la luz.

El siguiente bloque de referencia lista los m�todos y las constantes de la clase Light. Debemos recordar que los l�mites seleccionados con setInfluencingBounds() activan una luz cuando el objeto bounds referenciado intersecciona con la vista.

void setColor(Color3f color)

void setEnable(boolean state)

void setInfluencingBounds(Bounds bounds)

ALLOW_INFLUENCING_BOUNDS_READ | WRITE
ALLOW_STATE_READ | WRITE
ALLOW_COLOR_READ | WRITE.

�Luz Ambiente

Los objetos de luz ambiente proporcionan luz de la misma intensidad en todas las localizaciones y en todas las direcciones. Los objetos de luz ambiente modelan la luz reflejada desde otros objetos visuales. Si miramos la superficie inferior de nuestro escritorio, veremos la parte inferior del escritorio aunque ninguna fuente de luz est� dando directamente en esa superficie (a menos que tengamos una l�mpara bajo el escritorio). La luz que brillaba hacia arriba en el fondo del escritorio se reflej� en el suelo y en otros objetos. En ambientes naturales con muchos objetos, la luz se refleja desde muchos objetos para proporcionar la luz ambiente. La clase AmbientLight de Java 3D simula este efecto.

El siguiente bloque de referencia enumera los constructores de la clase AmbientLight. La clase abstracta Light proporciona los m�todos y las capacidades para esta clase (enumerada en el bloque de referencia anterior).

AmbientLight()

AmbientLight(Color3f color)

AmbientLight(boolean lightOn, Color3f color)

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 objeto 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.

Seg�n lo mencionado en secciones anteriores, la sombra de un v�rtice es el resultado de las fuentes de luz, de las caracter�sticas materiales del objeto visual, y de su geometr�a relativa (distancia y orientaci�n). Para las reflexiones ambiente, la geometr�a no es un factor. La propiedad ambiente del material s�lo se utiliza para calcular la reflexi�n ambiente. El modelo de iluminaci�n calcula la reflexi�n ambiente de la luz como el producto la intensidad del AmbientLight y la propiedad ambiente del material del objeto visual.

�Luz Direccional

Una fuente DirectionalLight aproxima fuentes de luz muy distantes tales como el sol. Al contratrio que las fuentes AmbientLight, las fuentes DirectionalLight proporcionan una sola direcci�n al brillo de luz. Para los objetos iluminados con una fuente DirectionalLight, el vector de luz es constante.

La Figura 6-12 muestra dos v�rtices de la misma esfera que est�n siendo iluminados por una fuente DirectionalLight. El vector de luz es igual para estos dos y para todos los v�rtices. Compara La Figura 6-12 con la Figura 6-1 para ver la diferencia. Puesto que todos los vectores de luz de una fuente DirectionalLight son paralelos, la luz no se aten�a. En otras palabras, la intensidad de una fuente DirectionalLight no var�a con la distancia al objeto visual y la fuente DirectionalLight.

Los siguientes bloques de referencia listan los constructores y los m�todos de DirectionalLight, respectivamente.

DirectionalLight()

DirectionalLight(Color3f color, Vector3f direction)

DirectionalLight(boolean lightOn, Color3f color, Vector3f direction)

void setDirection(Vector3f direction)

void setDirection(float x, float y, float z)

ALLOW_DIRECTION_READ | WRITE

Los DirectionalLights s�lo participan en las porciones difusas y specular de la reflexi�n del modelo de la iluminaci�n. Para las reflexiones difusas y specular, la geometr�a es un factor (al contrario que las reflexiones ambiente). Variar la direcci�n de la fuente de luz cambiar� el sombreado de los objetos visuales. Solo las caracter�sticas materiales difusas y specular se utilizan para calcular las reflexiones difusas y specular.

�Punto de Luz

Un PointLight es el contrario de un DirectionalLight. Es una fuente de luz omnidireccional cuya intensidad se aten�a con la distancia y tiene una localizaci�n. (un DirectionalLight no tiene ninguna localizaci�n, solo una direcci�n). Los objetos PointLight se aproximan a bombillas, velas, u otras fuentes de luz sin reflectores o lentes.

Un modelo de ecuaci�n cuadr�tica modela la atenuaci�n de las fuentes PointLight. La ecuaci�n se encuentra en la secci�n E.2 de la especificaci�n del API Java 3D. La Figura 6-13 ilustra la relaci�n de un objeto PointLight con una esfera. Observa que los vectores de luz no son paralelos.

Los siguientes bloques de referencia listan los constructores y los m�tosos de PointLight, respectivamente.

PointLight()

PointLight(Color3f color, Point3f position, Point3f attenuation)

PointLight(boolean lightOn, Color3f color, Point3f position, Point3f
attenuation)

void setAttenuation(Point3f attenuation)

				      1
	atenuaci�n = --------------------------------------------------------------------
			constate+linear+cuadr�tico*distancia2

void setAttenuation(float constant, float linear, float quadratic)

void setPosition(Point3f position)

void setPosition(float x, float y, float z)

ALLOW_POSITION_READ | WRITE
ALLOW_ATTENUATION_READ | WRITE

Como DirectionalLight, PointLight participa solamente en las porciones difusa y de reflexi�n especular del modelo de iluminaci�n. Para las reflexiones difusas y especular, la geometr�a es un factor. Variando la localizaci�n de un objeto PointLight se cambiar� el sombreado de los objetos visuales en una escena.

�SpotLight

SpotLight es una subclase de PointLight. La clase SpotLight agrega direcci�n y concentraci�n a los par�metros de posici�n y de atenuaci�n de PointLight. Los objetos SpotLight crean manualmente modelos de fuentes de luz artificiales como flashes , l�mparas, y otras fuentes con reflectores y/o lentes.

La intensidad de la luz producida por una fuente SpotLight produce la luz dentro de un �ngulo especificado desde la direcci�n de la luz. Si el v�rtice exterior se sale del �ngulo de la extensi�n de la luz, entonces no se produce ninguna luz. Por dentro del �ngulo de extensi�n, la intensidad var�a mediante el �ngulo y la distancia al v�rtice. Una vez m�s una ecuaci�n cuadr�tica modela la atenuaci�n debido a la distancia. El par�metro concentraci�n y una ecuaci�n diferente gobiernan la variaci�n de la intensidad debido al �ngulo. Las ecuaciones que gobiernan estos lazos se encuentran en la secci�n E.2 de la especificaci�n del API Java 3D. La Figura 6-14 ilustra en 2D c�mo la intensidad de luz var�a desde una fuente PointLight en 3D.

El �ngulo de extensi�n de un objeto SpotLight podr�a hacer que la luz iluminara parte de un objeto visual. Esta es la �nica luz capaz de iluminar s�lo una parte de un objeto visual.

Los siguientes bloques de referencia listan los constructores y m�todos de PointLight, respectivamente.

SpotLight()

SpotLight(Color3f color, Point3f position, Point3f attenuation, Vector3f
direction, float spreadAngle, float concentration)

SpotLight(boolean lightOn, Color3f color, Point3f position, Point3f
attenuation, Vector3f direction, float spreadAngle, float concentration)

void setConcentration(float concentration)

void setDirection(float x, float y, float z)

void setDirection(Vector3f direction)

void setSpreadAngle(float spreadAngle)

ALLOW_SPREAD_ANGLE_READ | WRITE
ALLOW_CONCENTRATION_READ | WRITE
ALLOW_DIRECTION_READ | WRITE

Como los objetos DirectionalLight y PointLight, los SpotLights participan solamente en las porciones difusas y reflexi�n specular del modelo de iluminaci�n. Para las reflexiones difusas y specular, la geometr�a es un factor. Cambiar la localizaci�n o la orientaci�n de una fuente de SpotLight cambiar� el sombreado de los v�rtices dentro de la regi�n de influencia de la luz.

�Aplicaciones de Fuentes de Luz

Con todos los tipos de fuentes de luz, y la variedad de maneras de utilizarlas, veremos una peque�a gu�a de su uso t�pico en esta secci�n. En general, desearemos utilizar tan pocas fuentes de luz como se pueda para una aplicaci�n dada. Cu�ntas son suficientes depender� del efecto de iluminaci�n deseado para la aplicaci�n. El n�mero de luces y la configuraci�n de atributos es m�s una consideraci�n art�stica que cient�fica.

Desde un punto de vista art�stico, a menudo es suficiente tener solo dos luces para una escena dada. Una luz proporciona la iluminaci�n principal, 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, el relleno a la izquierda del espectador. Una vez m�s �stas son pautas generales para lo que pueda ser un dise�o art�stico complejo.

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.

Es normal incluir una sola fuente de luz ambiente con una gran regi�n de influencia. Esto iluminar� las partes posteriores de los objetos (como la "cara oscura de la luna"). El valor por defecto del color funcionar� razonablemente bien. El tiempo requerido para incluir la luz ambiente es peque�o comparado con otras fuentes de luz. Dejar fuera una luz ambiente puede ser muy sensible en algunas escenas, y no ser notado en absoluto en otras.

�Ejemplos de Iluminaci�n

La interacci�n de la luz con los objetos es muy compleja en la naturaleza. Incluso en el mundo virtual donde es menos complejo el modelo de la iluminaci�n, las fuentes de luz son simplistas, y las superficies son menos detalladas, el efecto de una fuente de luz en un objeto visual es algo complejo. Esta secci�n presenta algunos ejemplos de la iluminaci�n para ayudar a clarificar las caracter�sticas, capacidades, y las limitaciones del modelo de iluminaci�n en Java 3D.

Dos Luces Coloreadas

La Figura 6-15 muestra una sola esfera blanca iluminada por dos fuentes de luz direccionales, una roja y una azul. Aunque puede sorprendernos, la sombra que resulta es magenta. Mezclar rojo y azul da lugar a la p�rpura, que es el resultado en el sistema de color sustractivo. Mezclar luces rojas y azules resulta en magenta, los resultados de un sistema de color aditivo.

En ausencia de luz, la esfera es negra. Si la �nica fuente de luz es roja, entonces la esfera aparecer� roja, o algo sombreada en rojo. Con la adicci�n de una fuente de luz azul, s�lo son posibles el rojo, el azul y las mezclas de estos dos.

Diferentes Patrones de Iluminaci�n

La siguiente aplicaci�n ilustra las diferencia entre las fuentes de luz. En LightsNPlanesApp.java se iluminan tres planos con una fuente de luz distinta. De izquierda a derecha, los objetos DirectionalLight, PointLight, y SpotLight iluminan los planos. La Figura 6-16 muestra la imagen renderizada por la aplicaci�n.

El DirectionalLight ilumina el plano uniformemente. El PointLight, situado directamente sobre el borde superior del plano del centro, ilumina el plano de forma irregular debido a la direcci�n variable de la luz con respecto a las superficies, y, en un grado inferior, a la atenuaci�n de la luz. El SpotLight, tambi�n situado directamente sobre el centro de su plano, ilumina solamente una parte peque�a del tercer plano.

La Figura 6-17 ilustra la geometr�a implicada en la iluminaci�n de los primeros dos planos. En la ilustraci�n izquierda, los vectores de luz constantes de la fuente DirectionalLight en conjunci�n con los vectores normales constantes de un plano dan lugar a vectores constantes de la reflexi�n, e incluso de la iluminaci�n del plano. En la ilustraci�n derecha los vectores de luz variables de la fuente PointLight se combinan con los vectores normales constantes del plano dando por resultado las distintas direcciones para los vectores de reflexi�n, y una iluminaci�n desigual del plano. El SpotLight es un caso especial de la fuente PointLight donde la influencia de la fuente de luz est� limitada por el �ngulo de la extensi�n.

Concentraci�n y �ngulo de Extensi�n de SpotLights

La Figura 6-18 muestra las im�genes renderizadas a partir de versiones distintas del programa ConcentrationApp.java. Un plano es iluminado por nueve puntos de luz. Los valores del �ngulo y de la concentraci�n de la extensi�n para las luces de los puntos var�an con la posici�n. El �ngulo de la extensi�n var�a por cada fila con valores de .1, .3 y .5 (radianes) desde la fila superior a la inferior, respectivamente. La concentraci�n var�a por cada columna con valores de 1,0, 50,0, y 100,0 desde la columna de la izquierda a la de la derecha, respectivamente.

Los valores de concentraci�n no tienen ning�n efecto para la fila superior, el �ngulo de la extensi�n es el �nico factor. En la fila inferior, la concentraci�n tiene un efecto para cada uno de los �ngulos de la extensi�n. El azul en las im�genes es el color difuso del material.

ConcentrationApp.java demuestra dos limitaciones del modelo de iluminaci�n. La primera es el renderizado de los artefactos representados en la Figura 6-18. Artefactos similares son visibles en la Figura 6-16. Los modelos desiguales de iluminaci�n para los planos verdes y rojos son debidos al peque�o n�mero de v�rtices usados para representar los planos. Recordamos que el modelo de iluminaci�n se aplica solamente en los v�rtices. Cuantos m�s v�rtices, mayor es el efecto de sombreado y m�s tardar� en renderizarse.

La diferencia entre las im�genes izquierda y derecha de la Figura 6-18 es debido a la diferencia en el n�mero de las v�rtices usados para representar el plano. La versi�n del programa que gener� la imagen izquierda utiliz� 16 veces m�s v�rtices que la que est� a la derecha (2.500 v�rtices contra 40.000). Los artefactos de la imagen derecha son un resultado de la reducci�n de la densidad de v�rtices en la superficie y la triangulaci�n impuesta por el sistema de renderizado de Java 3D.

Limitar el N�mero de Luces

La segunda limitaci�n demostrada en ConcentrationApp no se ve en la representaci�n. El plano de ConcentrationApp son realmente cuatro objetos planos uno al lado de otro. Esto se hizo para superar una potencial limitaci�n del sistema de representaci�n subyacente. La especificaci�n de OpenGL requiere soporte para ocho fuentes de luz simult�neas. Si el plano de ConcentrationApp fuera un objeto visual, entonces OpenGL limitar�a el n�mero de luces a ocho en algunas m�quinas.

Usando los l�mites de influencia para seleccionar solamente las fuentes de luz relevantes para un objeto visual, Java 3D crea din�micamente las especificaciones de iluminaci�n para las luces mientras que se renderizan los objetos visuales. Mientras que ning�n objeto sea iluminado por m�s de ocho luces, los programas de Java 3D no est�n limitados en el n�mero de luces en un mundo virtual.

Por eso proporcionar al cuadro planos m�s peque�os y los l�mites apropiados para asegurarse de que ning�n plano se ve influenciado por m�s de ocho luces, en el ejemplo parece que hay nueve luces (realmente diez, con la luz ambiente) iluminando un plano. Necesita un poco m�s programaci�n, pero el programa que resulta es m�s portable. Mientras que muchas implementaciones de OpenGL utilizan m�s de ocho luces simult�neas, si estamos planeando distribuir nuestros programas, debemos tener en cuante esta limitaci�n potencial.

En esta secci�n, algunos ejemplos muestran alguna de las caracter�sticas y las limitaciones de la iluminaci�n Java 3D. La intenci�n de esta secci�n es dar a los lectores algunos ejemplos de programas b�sicos y algunas figuras de ejemplo para comparar con sus propios programas. No es posible proporcionar ejemplos de cada posible situaci�n de iluminaci�n, pues los factores en la representaci�n son demasiado diferentes.

Una �ltima cosa, PointLight y SpotLight utilizan la especificaci�n de atenuaci�n. La atenuaci�n se especifica por los t�rminos constantes en la ecuaci�n cuadr�tica inversa basada en la distancia entre la luz y el v�rtice (v�ase el bloque de la referencia anterior). Encontrar la atenuaci�n apropiada para una aplicaci�n espec�fica es un problema art�stico. No se incluye ningun programa de ejemplo de atenuaci�n en este tutorial.

�Objetos Material

Las caracter�sticas materiales de un objeto visual se especifican en el objeto Material de un manojo de aspecto. Material es una subclase de NodeComponent. La Figura 6-19 muestra la jerarqu�a de clases del API Java 3D para Material.

El objeto Material especifica colores ambiente, difusos, especular, y emisivo y un valor de brillantez. Cada uno de los tres primeros colores se utiliza en el modelo de iluminaci�n para calcular la reflexi�n correspondiente. El color emisivo permite que los objetos visuales "brillen intensamente en la oscuridad". El valor de brillantez se utiliza solamente para calcular reflexiones especulares.

Los siguientes bloques de referencia enumeran los constructores y los m�todos de la clase Material.

Material()

Material(Color3f ambientColor, Color3f emissiveColor, Color3f diffuseColor,
Color3f specularColor, float shininess)

void setAmbientColor(Color3f color)

void setAmbientColor(float r, float g, float b)

void setDiffuseColor(Color3f color)

void setDiffuseColor(float r, float g, float b)

void setDiffuseColor(float r, float g, float b, float a)

void setEmissiveColor(Color3f color)

void setEmissiveColor(float r, float g, float b)

void setLightingEnable(boolean state)

void setShininess(float shininess)

void setSpecularColor(Color3f color)

void setSpecularColor(float r, float g, float b)

java.lang.String toString()

ALLOW_COMPONENT_READ | WRITE

�Ejemplos sencillos de Material

Las reflexiones especulares ocurren naturalmente en los objetos lisos. En general, cuanto m�s lisa sea una superficie, m�s definida e intensa es la reflexi�n especular. Cuando una superficie es suficientemente lisa, act�a como un espejo que refleja la luz sin cambiar el color de la luz. Por lo tanto, el color especular de un objeto normalmente es blanco. Cambiamos el color specular de un Material para alterar la intensidad de una reflexi�n specular (por ejemplo, Color3f(0.8f, 0.8f, 0.8f)).

El valor de brillantez controla el rango de la extensi�n del �ngulo de la visi�n para el cual se puede ver una reflexi�n especular. Una brillantez m�s alta resulta en reflexiones especulares m�s peque�as. La Figura 6-20 muestra nueve esferas distintas iluminadas por una fuente de luz. Cada esfera tiene un valor de brillantez distinto.

Un objeto Material se asocia a un objeto visual a trav�s de un objeto Apearance de la misma manera que lo hacen los atributos del aspecto. El m�todo SetMaterial() de la clase Appearance referencia un objeto Material para ese objeto Appearance.

�Propiedades Geometry color, ColoringAttributes, y Material

Hay tres maneras de especificar el color para un objeto visual: color por-v�rtice especificado en la geometr�a con los m�todos getColor(), ColoringAttributes de un nodo Appearance, y el objeto Material. Java 3D permite que creemos objetos visuales sin usar ninguna, alguna, o las tres formas de especificar color.

Cuando se ha hecho m�s de una especificaci�n del color, dos sencillas reglas determinan qu� especificaci�n del color toma la precedencia.

• Color Material se utiliza solamente cuando la representaci�n ilumina objetos y color de ColoringAttributes s�lo se utiliza cuando se renderizan objetos no iluminados.
• Geometr�a por-v�rtice siempre tiene precedencia sobre ColoringAttributes o Material.

Las reglas pueden ser m�s claras cuando el problema se divide en objetos iluminados o apagados. La iluminaci�n est� activa para un objeto cuando se referencia un objeto Material. Inversamente, cuando no se asocia ning�n objeto Material al objeto visual, la iluminaci�n est� desactivada para ese objeto. Observa que una escena puede tener tanto objetos iluminados como apagados.

Cuando la iluminaci�n est� activa para un objeto (es decir, se referencia un objeto Material), se utilizan el color material o el color de la geometr�a por-v�rtice para sombrear. Si esta presente, el color por-v�rtice reemplaza los colores de Material difusos y ambiente. Observa que el color de ColoringAttributes nunca se utiliza para la iluminaci�n de objetos. La siguiente Tabla resume las relaciones:

Cuando la iluminaci�n est� desactivada para un objeto (es decir, no se referencia un objeto Material), se usan el color de ColoringAttributes o el color de por-v�rtice para colorear. Si est� presente, el color de la geometr�a por-v�rtice reemplaza el color de ColoringAttributes. La siguiente Tabla resume las relaciones.

�Superficies Normales

Seg�n lo mencionado en secciones anteriores, las superficies normales son necesarias para sombrear los objetos visuales. Al crear objetos visuales usando clases Geometry, utilizamos uno de los m�todos setNormal() para especificar los vectores de los v�rtices.

El NormalGenerator incluido con los utilidades de Java 3D genera superficies normales al especificar los objetos visuales que usan objetos GeometryInfo. Para generar superficies normales, ponemos nuestro objeto visual Geometry y llamamos a NormalGenerator.generateNormals().

Los primitivos geom�tricos generan sus propias superficies normalea cuando son especificados.

No importa c�mo se especifican (o se generan) las superficies normales, s�lo se especifica una superficie normal por v�rtice. Esto conduce a algunos problemas interesantes. Por ejemplo, cuando las dos superficies normales de pol�gonos son visibles, la normal es solamente correcta para una de las superficies normales. El resultado es que las caras posteriores sean renderizadas (si se renderizan) solamente con las caracter�sticas materiales de ambiente. Las reflexiones difusa y especular requieren la especificaci�n normal apropiada.

Este problema com�n se soluciona especificando caras normales detr�s al contrario que las superficies normales delanteras. Utilizamos el m�todo setBackFaceNormalFlip() de un objeto PolygonAttributes para este prop�sito.

La Figura 6-21 muestra dos im�genes sombreadas de una tira doblada. La imagen de la izquierda fue renderizada desde la superficie frontal, y la derecha muestra las superficies normales traseras.

Cuando un v�rtice es compartido por las superficies normales o varian las orientaciones, tener solamente una superficie normal por v�rtice puede dar lugar a problemas. Consideremos los ejemplos ilustrados en la Figura 6-22. La geometr�a ilustrada en la cara del lado izquierdo de la Figura 6-22 muestra la secci�n transversal de una superficie donde cada pol�gono se orienta a un �ngulo de 90� de sus vecinos. Si se selecciona la superficie normal como el normal actual para una superficie, es muy incorrecto para su vecino. Si las superficies normales se especifican seg�n lo mostrado, entonces la superficie estar� sombreada constantemente entre los v�rtices con superficies paralelas. Un problema similar ocurre con la geometr�a del cubo mostrada en la cara derecha en la Figura 6-22. La soluci�n a ambos problemas es aumentar el n�mero de v�rtices para aumentar el n�mero de superficies normales. Esto, por supuesto, aumenta el uso de la memoria y el tiempo de la renderizaci�n.

�Especificar la Influencia de las Luces

En ejemplos anteriores, la especificaci�n de los l�mites que influencian un objeto de luz se consigue al referirse a un objeto Bounds. Esto conecta la localizaci�n de los l�mites que influencian a la localizaci�n de la luz. (En secciones anteriores se explic� c�mo las transformaciones en el escenario gr�fico afectan a los vol�menes de limites usados para especificar los l�mites de influencia de las luces.) Mientras que esto se hace trivial para mover luces junto con los objetos visuales que se iluminan, otras aplicaciones necesitan una especificaci�n m�s flexible de la influencia de luces. Afortunadamente, el API Java 3D proporciona un m�todo alternativo para especificar los l�mites de influencia y una manera de limitar el �mbito en adici�n de los l�mites.

�Alternativa a los L�mites de Influencia: BoundingLeaf

Un objeto BoundingLeaf es un alternativa a un objeto Bounds de influencia. Un objeto BoundingLeaf es referido por otros nodos de la hoja para definir una regi�n de influencia. Como descendiente de SceneGraphObject, los ejemplares de BoundingLeaf se agregan al escenario gr�fico. El objeto BoundingLeaf est� sujeto al sistema de coordenadas local de su posici�n en el escenario gr�fico, que podr�a ser independiente del sistema de coordenadas del objeto de luz. Es decir, usar un BoundingLeaf permite a una luz y a sus l�mites de influencia moverse independientemente.

Una llamada a setInfluencingBoundingLeaf() para un objeto de luz especifica el argumento BoundingLeaf como los l�mites de influencia de la luz. Esta especificaci�n reemplaza cualquier especificaci�n regional de los l�mites de influencia. Un objeto BoundingLeaf puede ser compartido por varios objetos de luz.

La Figura 6-23 muestra el diagrama del escenario gr�fico para una aplicaci�n de ejemplo de un objeto BoundingLeaf con objetos de luz. En esta escena, se mueven dos luces junto con un objeto TransformGroup (a la derecha). Estas luces pod�an ser ejemplares de PointLight o de SpotLight. Sin embargo, la influencia de estas luces no cambia cuando las luces se mueven. La influencia de las luces se mueve cuando el TransformGroup izquierdo cambia la localizaci�n del objeto BoundingLeaf. Podemos comparar este diagrama del escenario gr�fico con el que est� en la Figura 6-10.

En la Figura 6-10, si se mueve la luz, su regi�n de influencia tambi�n se mueve. Tambi�n, seg�n lo demostrado en la Figura 6-10, la regi�n de influencia de dos luces que comparten el mismo objeto Bounds pueden o no pueden tener la misma regi�n de influencia. Cuando dos o m�s luces comparten el mismo objeto BoundingLeaf, tienen siempre la misma regi�n de la influencia.

��mbito de L�mites de Influencia de las Luces

Una regi�n de limites, con un objeto Bounds o un objeto BoundingLeaf, especifica la regi�n de influencia de un objeto de luz. Un �mbito especificado puede adem�s limitar la influencia de una luz a una porci�n del escenario gr�fico. Como valor por defecto, todas las luces tienen el alcance del mundo virtual en el cual reside. La adici�n de una especificaci�n del alcance reduce adem�s la influencia de una luz a los objetos visuales en el escenario gr�fico debajo del group(s) especificado. Por ejemplo, consideremos la aplicaci�n siguiente.

Ejemplo de �mbito de Iluminaci�n

La escena consiste en una l�mpara y algunos objetos visuales en una mesa. La l�mpara tiene una sombra, por eso no todos los objetos, ni toda la mesa, debe ser iluminada por la l�mpara. El interior (pero no el exterior) de la l�mpara tambi�n se debe iluminar (en este ejemplo, la sombra de la l�mpara es completamente opaca). Sabemos que Java 3D no proporcionar� la obstrucci�n por nosotros. Usando s�lo un volumen de limitaci�n, la influencia de la luz puede ser controlada, pero podr�a ser muy dif�cil, especialmente si se iluminan y apagan objetos que est�n uno cerca del otro, o se mueven.

Especificar un �mbito de limitaciones para la luz nos permite controlar limitaciones complejas de la influencia m�s f�cilmente. La �nica consideraci�n es mantener los objetos iluminados y apagados en partes separadas del escenario gr�fico. Nuestro pensamiento inicial pudo ser comenzar a construir el escenario gr�fico BranchGroups para los objetos iluminados y apagados, pero �so no es a menudo necesario ni recomendado para la mayor�a de las aplicaciones.

El diagrama del escenario gr�fico de la izquierda de la Figura 6-24 muestra un acercamiento nativo a la construcci�n del escenario gr�fico. La organizaci�n no es natural y ser� dif�cil de manipular en una aplicaci�n animada. Por ejemplo, si la mesa se mueve, la l�mpara y otros objetos deben moverse con ella. En el escenario gr�fico de la izquierda, mover la mesa (mediante la manipulaci�n de TransformGroup) no mover� la l�mpara o el rect�ngulo ilumiando; solamente el rect�ngulo apagado se mover� con la mesa.

El diagrama del escenario gr�fico de la derecha representa una organizaci�n m�s natural para la escena. Los objetos en la mesa son hijos del TransformGroup que coloca la mesa. Si la mesa se mueve (mediante la manipulaci�n de TransformGroup) los objetos de la mesa se moveran con ella.

La escena de ejemplo se crea en LightScopeApp.java. La Figura 6-25 muestra dos im�genes renderizadas del programa de ejemplo. La imagen izquierda utiliza �mbito de luz para limitar la influencia de la luz de la l�mpara a la l�mpara y el rect�ngulo iluminado. La imagen derecha no utiliza scoping; por lo tanto, la luz de la l�mpara ilumina el ' rect�ngulo no iluminado'.

El �rea brillante debajo de la l�mpara (no representada en ning�n diagrama del escenario gr�fico) es un pol�gono situado justo sobre la tapa de la mesa. Este pol�gono brillante representa la parte de la mesa que es iluminada por la l�mpara. El �rea brillante aparece m�s ligera que el resto de la mesa (incluso en la imagen derecha de la Figura 6-9) porque sus superficies se alinean m�s cercanas al punto de luz de la l�mpara.

La sombra no aparece iluminada en ninguna imagen de la Figura 6-25 porque su caracter�stica Material difusa es negra. La sombra puede crearser con el uso del scoping solamente si un nodo adicional del grupo que se utiliza en el escenario gr�fico.

La sombra en esta escena fue creada a mano. Las t�cnicas para crear sombras autom�ticamente (incluso din�micamente) se discuten en la siguiente secci�n.

Tampoco se representan en ning�n diagrama del escenario gr�fico las tres fuentes de luz adicionales: dos fuentes de luz direccionales y una fuente de luz ambiente. �stas son necesarias para simular la luz de una escena natural.

El siguiente bloque de referencia muestra los m�todos de la clase Light usados para especificar limitaciones del scoping y el uso de los objetos BoundingLeaf para especificar los l�mites de influencia.

void addScope(Group scope)

java.util.Enumeration getAllScopes()

void insertScope(Group scope, int index)

int numScopes()

void removeScope(int index)

void setInfluencingBoundingLeaf(BoundingLeaf region)

void setScope(Group scope, int index)

Otra ventaja de usar alcances para limitar la influencia de una luz: puede reducir el tiempo de renderizado. Calcular la intersecci�n de los l�mites para un objeto visual con los l�mites que influencian de una luz es m�s complejo que determinar el alcance de una luz. Debemos tener cuidado con que ni el uso de los l�mites de influencia ni los alcances limitar� la influencia de una luz a una parte de un objeto visual.

�Crear Objetos Brillantes-en-la-Oscuridad, Sombras y Otros Problemas de Iluminaci�n

Las secciones anteriores cubren las aplicaciones t�picas de iluminaci�n en Java 3D. Esta secci�n cubre algunas de las caracter�sticas y t�cnicas menos utilizadas.

�Objetos Brillantes-en-la-Oscuridad

El objeto Material permite la especificaci�n de un color emisivo. Esto se puede utilizar para crear el efecto de un objeto brillante en la oscuridad. Tener un color emisivo no hace del objeto visual una fuente de luz; no iluminar� otros objetos visuales. El Material Emisivo es tambi�n �til en aplicaciones especiales, tales como indicar un objeto especial o un objeto que se ha escogido.

La Figura 6-26 muestra la escena del programa del �mbito de luz donde se le ha dado color emisivo al rect�ngulo no iluminado. Comparemos esta imagen con la imagen izquierda de la Figura 6-25. Como podemos ver, el uso del color emisivo s�lo modifica al objeto visual que lo tiene. Este ejemplo tambi�n demuestra que el uso eficaz del color emisivo, como con la mayor�a de los par�metros de la iluminaci�n, es m�s un problema art�stico que de programaci�n.

�Calcular Sombras

La complejidad de calcular sombras es tan grande que no forma parte de ning�n sistema de gr�ficos en tiempo real. La complejidad viene de c�lcular si la fuente de luz alcanza o no un v�rtice. Todo pol�gono de otro objeto visual debe ser considerado al calcular la respuesta.

El sombreado es mucho m�s complejo en realidad. Las fuentes de luz no son fuentes puramente direccionales ni perfectas. Por lo tanto, las sombras no tienen bordes sostenidos. Ignorando la realidad, como hacemos a menudo en gr�ficos, echemos una ojeada a las formas de simular sombras.

�Crear Sombras

Hay dos partes b�sicas al simular (o al falsificar) sombras: calcular donde est�n las sombras, y crear geometr�as (o texturas) para servir como sombras. Hay varias maneras de calcular la localizaci�n de la sombra, pero los detalles de las distintas t�cnicas de sombreado est�n m�s all� del alcance de esta gu�a. Las dos secciones siguientes cubren dos t�cnicas generales para crear el contenido de la sombra.

Sombrear Pol�gonos

Un pol�gono especificado sin propiedades Material se puede utilizar como pol�gono de sombra, llamado un pol�gono sombra coloreado. El color del pol�gono sombra, especificado por geometr�a o con un objeto ColoringAttributes, se elige para aparecer como el objeto en sombra. Los pol�gonos sombra especificados de esta manera pueden parecer falsos en escenas complejas.

Los pol�gonos sombra especificados con las caracter�sticas Material pero fuera de la influencia de uno o m�s objetos de luz se llaman pol�gonos sombra sombreados. Los pol�gonos sombra son sombreados por los objetos de luz que los influencian tal que parecen m�s realistas. Obviamente, especificar un pol�gono sombra sombreado es m�s complejo que especificar un pol�gono sombra coloreado.

No importa c�mo se especifique un pol�gono sombra, la posici�n del pol�gono sombra es justo arriba, o en frente de, el pol�gono al que da sombra. Mientras que la adici�n de pol�gonos sombra no da lugar normalmente a m�s pol�gonos para renderizar (debido a la obstrucci�n de otros pol�gonos) crea m�s objetos en el universo virtual lo que puede degradar el funcionamiento de la renderizaci�n.

En vez de crear los pol�gonos sombra, las sombras pueden crearse cambiando la influencia de luces para excluir pol�gonos 'en la sombra'. El �mbito de luces es �til para este prop�sito. Sin embargo, puesto que la influencia se determina en base al objeto, puede ser complejo calcular c�mo subdividir los objetos visuales que se sombrean parcialmente.

Sombrear Texturas

Como las sombras anteriores, las sombras naturales son complejas. Una sombra natural raramente tiene un borde recto y una sombra constante. Se puede usar el texturado para hacer sombras m�s realistas. Hay dos maneras b�sicas de usar texturado para crear sombras: aplicando textura a los pol�gonos sombra, o la aplicaci�n de texturas a los objetos visuales.

Como el texturado no se ha cubierto todav�a (Cap�tulo 7), y el c�lculo de las texturas de la sombra (incluso off-line) es dif�cil (y va m�s all� del alcance de esta gu�a) este es un tema pendiente para otro libro.

Mover Objetos, Mover Sombras

Debemos tener presente que la adici�n de sombras a una aplicaci�n hace la aplicaci�n mucho m�s compleja. Por ejemplo, cuando un cubo con una sombra gira, la sombra gira y se deforma. Para esa materia, las luces m�viles hacen que las sombras se muevan tambi�n. En cualquier caso, el movimiento agrega otro nivel de complejidad a la programaci�n de sombras.

�Programa de Ejemplo de Sombras

El programa ShadowApp.java da un ejemplo de c�mo se pueden crear pol�gonos sombra sencillos. El programa define una clase para crear los pol�gonos sombra. La clase sombra crea un pol�gono sombra para cada geometr�a dada como entrada de informaci�n. El Fragmento de C�digo 6-3 muestra la clase SimpleShadow usada para crear pol�gonos sombra en ShadowApp.java. La Figura 6-28 muestra la escena renderizada con una sombra.

1.     public class SimpleShadow extends Shape3D {
2.     SimpleShadow(GeometryArray geom, Vector3f direction,
3.     Color3f col, float height) {
4.
5.     int vCount = geom.getVertexCount();
6.     QuadArray poly = new QuadArray(vCount, GeometryArray.COORDINATES
7.     | GeometryArray.COLOR_3
8.     );
9. 
10.   int v;
11.   Point3f vertex = new Point3f();
12.   Point3f shadow = new Point3f();
13.   for (v = 0; v < vCount; v++) {
14.   geom.getCoordinate(v, vertex);
15.   shadow.set( vertex.x + (vertex.y-height) * direction.x,
16.   height + 0.0001f,
17.   vertex.z + (vertex.y-height) * direction.y);
18.   poly.setCoordinate(v, shadow);
19.   poly.setColor(v, col);
20.   }
21.
22.   this.setGeometry(poly);
23. }

Varias asunciones hechas en la clase SimpleShadow (para hacerlo f�cil) limitan las aplicaciones de esta clase. SimpleShadow est� limitada en que: proyecta solamente a los planos, s�lo considera una luz, s�lo hace algunas orientaciones, no considera las dimensiones del plano sobre el que se est� proyectando. Escribir una clase de fines generales para el c�lculo de la sombra es una empresa importante.

�T�pico Avanzado: El Papel del Objeto View en el Sombreado

La vista (o las vistas) asociadas a un escenario gr�fico juegan una gran variedad de papeles en c�mo se renderiza una escena. Esta secci�n no explica todos los papeles del objeto View. La especificaci�n del API Java 3D proporciona una referencia completa a la clase View. Esta secci�n menciona solamente dos m�todos de la clase View �tiles para entender el sombreado de objetos visuales.

Seg�n lo mencionado en la secci�n "Vectores de ojo local contra ojos infinito", el vector del ojo es constante como valor por defecto. Esto se conoce como un vector de ojo infinito. Es decir, la escena se renderiza como si fuera vista desde el infinito. Tener un ojo infinito reduce perceptiblemente el c�lculo de renderizaci�n.

Sin embargo, la imagen que resulta puede parecer incorrecta. La Figura 6-29 muestra las im�genes renderizadas a partir de una escena usando un ojo infinito y un ojo local usando diversas fuentes de luz.

Para apreciar completamente las im�genes de la Figura 6-29 necesitamos conocer la geometr�a de la escena. La escena son nueve esferas en una organizaci�n planar. Cada una de las im�genes se ve con el mismo campo visual desde la misma posici�n. Las �nicas variables son si la luz es un DirectionalLight o un PointLight, y si el ojo es infinito o local. El DirectionalLight tiene direcci�n (0, 0, -1), el PointLight se coloca en (0, 0, 1).

Las im�genes (a) y (c) de la Figura 6-29 se renderizan con un ojo infinito. En estas im�genes, los vectores del ojo son constantes, as� que las reflexiones especulares est�n b�sicamente en la misma posici�n para cada esfera. Las im�genes (b) y (d) de la Figura 6-29 se renderizan con un ojo local. Los vectores del ojo var�an en estas im�genes, as� que las reflexiones especulares est�n en distinta posici�n para cada esfera. Observemos tambi�n que la reflexi�n difusa (azul) en las esferas var�a s�lo con la fuente de luz. El vector del ojo s�lo desempe�a un papel en el c�lculo de la reflexi�n especular.

Una vez m�s la caracter�stica de la visi�n del ojo infinito se utiliza para reducir el c�lculo, y por lo tanto el tiempo de la renderizaci�n. La imagen (a) de la Figura 6-29 tarda un menor tiempo para renderizarse y la imagen (d) tarda el mayor tiempo. Las im�genes (b) y (c) tardan una cantidad casi igual de tiempo, que es menor que el tiempo de la imagen (d), pero mayor que el de la imagen (a). El tiempo real para renderizar var�a con el sistema utilizado. La diferencia es m�s pronunciada en los sistemas que renderizan por software.

void setLocalEyeLightingEnable(boolean flag)

void setWindowEyepointPolicy(int policy)

El objeto View se puede conseguir desde un SimpleUniverse usando los m�todos apropiados. Entonces el objeto View se puede manipular como en el siguiente ejemplo:

SimpleUniverse su = new SimpleUniverse(canvas);
su.getViewer().getView().setLocalEyeLightingEnable(true);