A warning about transparency

1, 0, 1, 1, 0, 1, 0, 0 };

//define the normal vector for the new left face

Vector3f normalVector = new Vector3f(−1.0f, 0.0f, 0.0f);

//assign the colors to the QuadArray geometry.setColors( 0, colors, 0, 4 );

//assign the normal vector for each vertex in the QuadArray for( int n = 0; n <4; n++ )

geometry.setNormal( n, normalVector );

//assign the texture coordinates for each vertex in the QuadArray geometry.setTextureCoordinates( 0, tcoords, 0, 4 );

//finally, assign the vertices themselves into the QuadArray geometry.setCoordinates( 0, verts );

NOTE All rendering was performed with PolygonAttributes.CULL_NONE; so all the faces of the Box were rendered.

9.12.1 A warning about transparency

Consider carefully what you are trying to achieve if you choose to use transparency as an Appearance attribute in your scene. It is very difficult to know exactly what will be rendered by Java 3D in either NICEST or SCREEN_DOOR mode, and without some form of application−specific sorting algorithm, which must be carried out potentially on every frame, problems will probably occur.

The issues with transparency really do not reside at the Java3D level, but Java 3D has not done a good job of insulating the Java 3D developer from the underlying issues in the OpenGL/DirectX implementation. I am hopeful that Sun can address many of these issues in Java 3D 1.3.

Figure 9.19 Coloring = null, Material = null, Transparency = null

Figure 9.20 Coloring = green, Material = null, Transparency = null. Note that the QuadArray with per−vertex colors is unaffected

Figure 9.21 Coloring = null, Ambient: white Diffuse: white Emissive: blue, Transparency = null. Lighting is now active and affects the QuadArray with per−vertex colors

Figure 9.22 Coloring = null, Material = null. Transparency = 0—NICEST. Here we have set up transparency for both the Box (100% opaque) and the QuadArray (per−vertex transparency). Even though the QuadArray should be visible at the front of the Box, it is being rendered behind the Box. This would be a case that could be solved using a simple sorting algorithm because the centroid of the Box is behind the centroid of the QuadArray and hence it should be rendered before the QuadArray

Figure 9.23 Coloring = null, Material = null. Transparency = 0—SCREEN_DOOR. Here, when we switch to SCREEN_DOOR transparency, the rendering order problem disappears

Figure 9.24 Coloring = null, Material = null. Transparency = 0.5—NICEST. When the Box is semitransparent, the problem with rendering order is not apparent because you can see the QuadArray through the Box

Figure 9.25 Coloring = null, Material = null. Transparency = 0.5—SCREEN_DOOR. Using stippling to simulate transparency is not as realistic as using true color blending

Figure 9.26 Coloring = null, Material = null. Transparency = 0.8—NICEST. We have increased the transparency of the Box and rotated it so that the QuadArray is now at the rear of the Box. No problems apparent here

Figure 9.27 Coloring = null, Material = null. Transparency = 0.8—SCREEN_DOOR. We have increased the

transparency of the Box and rotated it so that the QuadArray is now at the rear of the Box. Using SCREEN_DOOR transparency, the QuadArray has now disappeared

Figure 9.28 Coloring = null, Ambient: white, Diffuse: white, Emissive: blue, Transparency = 0.5—NICEST. The scene renders correctly—but continuously renders, cycling over the back faces and then redrawing the front faces

Figure 9.29 Coloring = null, Ambient: white, Diffuse: white, Emissive: blue, Transparency = 0.5—SCREEN_DOOR. No problems apparent here

9.13 Summary

Java 3D provides you with a rich set of capabilities for controlling the appearance of your geometry. By combining aspects of the Appearance class, such as materials, transparency, textures, or rendering attributes, you can achieve visually effective scenes with very little programming.

The high−level object−oriented API allows you to easily navigate through the dozens of appearance capabilities and is a real productivity improvement over a lower−level API such as OpenGL. In some areas (for example, transparency), however, it can be important to understand what is going on under the covers, as Java 3D does a poor job at insulating you from the peculiarities of the underlying implementation or providing adequate documentation. If you require additional information I strongly recommend a good 3D graphics text as well as an OpenGL/DirectX reference.

CHAPTER 10

Lights

10.1 Lights 10.2 Light node 10.3 AmbientLight 10.4 DirectionalLight 10.5 PointLight 10.6 SpotLight

10.7 Lighting, material attributes, and per−vertex colors 10.8 Summary

Lighting is an important topic in 3D graphics. The lights that you choose for your scene can have a profound impact, making it appear, for examples, highly atmospheric or almost photographically realistic or flat and artificial. There are two basic problems with setting up lighting for your scene. The first is to understand how lighting is calculated, as well as understanding the mechanics of setting up lighting parameters and doing the necessary programming. The second problem is aesthetic and involves making artistic decisions regarding how you want your scene to appear. Because lights can also be computationally expensive, you need to use them carefully and ensure you are striking the right balance between frame rate and responsiveness on the one hand and a richly shaded scene on the other.

Figures 10.2 through 10.15 show a scene viewed under different lighting conditions. The illustrations give an indication of the lighting effects that are possible using Java 3D and provide a starting point for designing your own scene lighting. You’ll want to run the example application to see the color illustrations for the full effect. You can also refer to the ebook edition of this book, available from the publisher’s web site at http://www.manning.com/selman, which contains color illustrations.

The LightTest example application allows you to interactively modify lighting parameters and view the results.

10.1 Lights

Careful use of lights can make the difference between a flat, unconvincing 3D scene and an atmospheric, immersive virtual reality. The shading that results from applying lighting to a 3D scene provides many of the important visual cues that convey the depth information for the scene.

There are four basic types of light defined in Java 3D and most 3D rendering APIs:

Ambient lights—Applied to the whole scene.

•

Directional lights—Positioned at infinity and shine in a given direction.

•

Point lights—Radiating outward from a given point in 3D space within the scene.

•

Spotlights—Radiating outward from a given point and with a given spread angle, to allow the width of the light’s beam to be specified.

•

Lights positioned within the scene influence the colors that are applied to surfaces. Lights are not visible entities in themselves, but they affect the colors of the surfaces of objects within the scene. For example, there is no built−in support for displaying shafts of light that illuminate fog or dust before falling onto the surfaces of objects in the scene. Other lighting side effects, like lens−flare, are also not supported. Such visual effects, now commonly seen is 3D games such as Quake, are not implemented in either OpenGL or DirectX and hence not supported in Java 3D.

Once the lights are positioned within the scene, complex lighting equations govern the resulting color and shading of a surface. The result, a rendered shaded surface, relies on many factors, such as:

Surface Properties

•

angle of surface relative to light sources

material properties: ambient, diffuse, emissive and specular colors, shininess (or gloss) surface simulation: e.g., bumpy or wrinkled

vertex colors transparency

applied texture image

shading model (Lambert, Gouraud, Phong) Light Properties

•

position color direction

attenuation: how the intensity of the light decreases with distance concentration

spread angle extent (Bounds)