Java Programing

March 30, 2007

The JavaMet example, included with this book, uses

Filed under: Java 3D Programming — webmaster @ 2:06 am

for 3D CAD visualization input is largely mouse or tablet driven and motion is usually confined to a small number of objects and is not continuous. Lower rates of five or more FPS may be acceptable. For interactive 3D games a frame rate is required that allows users to suspend belief and accept that they are moving within the scene. Lower frame rates provide a choppier motion and quickly destroy the impression of smooth movement, 20 or more FPS is typically required. 7.2.1 Rendering quality Rendering quality depends on such factors as geometry description, low-level graphics language, rendering hardware, and display hardware. Typically the only factor under the developer s direct control is geometry description. The following will influence the visual appearance of rendered geometry: Complexity of model description. Such complexity is usually defined in terms of the number of vertices or surfaces. Application of different lighting and shading models. Lighting and shading models can be used to influence perceived surface characteristics, such as smoothness of the model (Gauraud shading), or to add specular highlights to the model (Phong shading), Complexity of texture images applied to the model. High-resolution texture images are less likely to suffer from becoming pixelated when magnified. Java 3D rendering settings. Java 3D and the lower-level graphics language compromise internally between speed and accuracy of rendering. There are settings to tell Java 3D to err on the side of speed or accuracy for everything from perspective calculation through to lighting and fog calculations. Rendering quality is a difficult balancing act, and a compromise must typically be struck between the complexity of model description plus texture images on the one hand and rendering time on the other. It may be necessary to dynamically change the model description based on the distance of the object from the viewer using a level of detail approach. Unfortunately, not all software and hardware renderers are created equal, and noticeable differences will be perceived between DirectX and OpenGL rendering as well as between different makes (and versions) of 3D accelerator cards and drivers. To compound matters, certain makes of 3D cards will incorrectly render certain configurations of geometric primitives. The only advice that can be given is to ensure applications are tested on as wide a variety of hardware and software platforms as possible. 7.2.2 Load time Load time is not typically of paramount importance, but loading large complex geometric models and texture images can become very time consuming, particularly if the models are loaded across the Internet. Like other objectives, load-time objectives should be set and adhered to throughout the development phase. Before your application s data can be loaded, the JVM must be loaded from disk and started. The time taken to load the JVM is heavily dependent upon available physical memory, and it can take minutes to load the JVM on machines with less than 64 MB. You must seriously consider using delayed loading techniques for application data to ensure that the user is not left waiting for several minutes for your application to complete startup. 7.2.3 Memory footprint The total memory footprint (all allocated memory) of a Java 3D application is unfortunately quite large. Most of the memory allocated will probably be used by the JVM and the Java 3D subsystem. If models and textures are very large, however, they can come to play a significant part in determining runtime memory 105

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Java Web Hosting services

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Sorry, the comment form is closed at this time.

Powered by Java Web Hosting