TextureMappingApplet - Project Description
Overview
This applet incorporates an interesting blend of three different viewing systems: two different types of perspective transformations and a ray-tracer. By switching viewing systems at different points in the rendering process, the applet is able to exploit each system's advantages, while simultaneously avoiding many of their limitations. Because the applet allows users to choose any image they want to be texture-mapped, even more experimentation is made possible.

Areas of Interest
Any image can be used as the original image - See the AntiAliasingApplet description for more information.
Image download progress is monitored - See the AntiAliasingApplet description for more information.
Gradient-shaded background is "free" - Before drawing a new view, the applet erases the previous image by calling System.arrayCopy to clear the pixel array that generates the image. Therefore, the source array of pixels can contain a complicated background without incurring extra processing time because of it. In this case, the gradient fill is not particularly complex, but it illustrates design's potential.
Three viewing systems are used - The user specifies viewing parameters by setting the three parameters of the spherical coordinate system (two angles and a radius). These parameters are converted to the standard U, V, and N vectors. A standard viewing transform is used to determine bounding rectangles for each of the polygons in the environment (to speed the ray-tracing process). Once bounds have been determined, the applet ray-traces the image and displays the results. Ray-tracing was implemented for two reasons: I wanted some experience programming ray-tracing code, and Z-buffering is automatically carried out as part of the ray-tracing process. The integration of these three viewing systems seems to provide reasonably good performance, and was a good learning experience.
Images are double-buffered - Contrary to what would be expected, double-buffering is not done to speed the applet up or to generate more pleasing redraws. In fact, it results in much higher resource requirements for the applet and was not part of the original design. Instead, the applet double-buffers its images to avoid problems that cause the Java Virtual Machine to bomb. In Java 1.0, the recommended way of creating animations is to use a MemoryImageSource-based Image and call Image.flush each time the pixel data changes. Unfortunately, calling this method repeatedly with short intervals between successive calls locks the JVM on multiple platforms (Java 1.1 has implemented a better method for creating animated images - I have not yet tested it for this problem). To work around this limitation, I create two Images and alternate between them - so each image gets flushed half as often. This has corrected the problem for the machines on which I have seen and tested the applet. Hopefully the Java 1.1 implementation does not suffer from this problem.

Conclusion
I am pleased with the way this applet turned out. It demonstrates many texture-mapping concepts and behaviors while maintaining reasonable performance. Unfortunately, execution speed is a tad slow in spite of my efforts at optimizing the rendering process, but slowness is one of the negatives of ray-tracing and was not a surprise. Other than the speed issue, everything seems to have turned out nicely, and there is not much I wish I had done differently.


The applet is available.
The source code is available for educational purposes.