Suppose a group of children want to play with plastic airplanes. The first child pulls out a chemistry set, creates a few lumps of plastic, molds them into carefully shaped pieces, and assembles them into an airplane. She has total control over the size and shape of her resulting toy. The next child doesn't have the necessary chemistry skills, so he decides to build an airplane using a set of plastic construction blocks. While this is much faster, he loses some control over the final appearance; for example, the blocks make it impossible to have any rounded edges. The third child simply takes a set of blocks to her parents, along with a description of what she would like them to build for her. This last child has lost even more control over the final product, and yet she will end up with a perfectly good airplane.
The sudden appearance of children and airplanes in this article serves to illustrate a choice you must make when creating a graphical mathlet: how much of the low level computer code will you write? This is an important decision which can affect everything from your user interface to the types of graphics you can display. You must balance these considerations with other issues, such as your programming skill and the amount of time you can devote to your project. Roughly speaking, you have three options, similar to the children above.
At the bottom of the hierarchy, you might decide to write the entire mathlet from scratch. This gives you total control over all aspects of the mathlet; it also burdens you with total responsibility for implementing the user interface and graphics display engine. Needless to say, this option is not realistic unless you are an experienced computer programmer.
Next, you could decide to build your mathlet using a pre-existing library of components provided by packages like JavaView (Polthier et al.) or the Java 1.1 3D Renderer (Perlin). JavaView, for example, provides a large number of Java classes, ranging from configurable sliders to "displays" which let the user rotate three-dimensional objects with various settings for lighting, shading, and transparency. You are locked in to the stylistic choices the JavaView authors made when designing their components, but you can create much more elaborate user interfaces and pictures using JavaView than you could ever accomplish with LiveGraphics3D. Correspondingly, you will still spend significant time writing and compiling Java code in order to assemble the various components together.
The third option is to use a pre-existing applet such as LiveGraphics3D; you supply certain parameters to describe what you want on the screen, and the applet handles everything else. For example, consider this partial list of features implemented in LiveGraphics3D:
The downside to using LiveGraphics3D is that all aspects of the display and user interface are fixed; you cannot change, say, the method for zooming in and out. In many cases, the ability to create mathlets quickly without worrying about the underlying code far outweights the loss of freedom, but in the end this is a personal choice which depends on your needs and resources.