java.sun.com/j2se/1.4/demos/jcanyon -> java.sun.com/j2se/1.4/demos/jcanyon/
Reference > 16 Code Samples and Apps > 17 Join a Sun Developer Network Community 18 Profile and Registration | 19 Why Register? JCanyon: GRAND CANYON FOR JAVA As seen at 21 JavaOne 2001 JCanyon screenshot Kenneth Russell, Sun Microsystems, Inc. Contents * i. Quick Start with Java Web Start * 1. Direct Buffers * 2. JCanyon Overview + 26 Use of New File I/O + 27 Rendering Loop * 3. Flight Dynamics * 4. Frequently Asked Questions * 5. Source Code * 6. Acknowledgments * 7. Feedback * 8. References * 9. Trademarks i. Quick Start with Java Web Start System requirements: * 330 MB of free disk space * 192 MB or more RAM * 39 OpenGL(R) (is pre-installed on Windows(R) PCs and many GNU/Linux distributions) System recommendations: * 3D accelerator card with hardware texture mapping (has been tested extensively with 40 NVIDIA(R) GeForce(R) family of products) The launch links below require 41 Java Web Start. Beta will provide substantial performance improvements for this and other NIO-intensive applications. The links below are designed to work on the following operating systems: * Solaris/SPARC with 43 OpenGL for Solaris/SPARC * Solaris/x86 with 44 Mesa * GNU/Linux on x86 (Mesa is usually pre-installed; It is recommended that you change your display settings to 640x480 before launching the demo to simulate full-screen mode; OpenGL on Windows. The first time the program is launched, a 20 MB jar file will be downloaded and decompressed onto your local disk into a directory you choose. The complete source code for jcanyon is 49 available below. JNI calls 1. Java platform were the 51 JNI Get<PrimitiveType>ArrayElements and GetPrimitiveArrayCritical entry points. The implementation of Get<PrimitiveType>ArrayElements either incurs a memory allocation and data copy, which is expensive, or requires pinning support in the garbage collector, which is difficult or impossible depending on the garbage collection algorithm used by the Java virtual machine implementation (JVM). GetPrimitiveArrayCritical is fast but has severe limitations on how it can be used which make it unacceptable for many kinds of applications. JSR-000051). They are applicable to more domains than just I/O; I/O, 2D, 3D, database access, and inter-language interoperability can potentially benefit from direct buffers. The Java 53 HotSpot Client and Server VMs have been optimized to generate very efficient code for buffer operations. JCanyon is intended solely as a technology demonstration. APIs. The entire application, including the physically-accurate flight model and rendering loop, is written in the Java programming language. No native code aside from the OpenGL binding is required or used. The simulator runs at real-time rates using the Java HotSpot Client VM on a single-CPU 750 MHz Pentium III PC with an 58 NVIDIA GeForce or GeForce 2 graphics card. The rest of this paper is organized as follows. Section 3 provides details on the multiresolution algorithm and the flight dynamics. Section 4 contains answers to frequently asked questions. Section 5 provides links to the complete source code of the jcanyon demonstration. Section 6 contains acknowledgments, 64 Section 7 the alias for feedback, and 65 Section 8 references for further reading. OpenGL. Use of New File I/O The data set which jcanyon renders is comprised of roughly 100 MB (uncompressed) of elevation data, which provides the shape of the canyon and mountains, and 200 MB of satellite imagery, which provides the surface color. The data is too large to fit in RAM on most machines; Memory-mapped file I/O is used to transfer both the elevation and image data into the application. The elevation data is currently always mapped in at the highest resolution and is decimated at run time. The image data is downsampled into pyramids ahead of time and only the data of the needed resolution is mapped into memory at any given time. Imagery is fetched from the disk in a background thread and is scanned by that thread to ensure the data is in the disk cache before it becomes accessible to the main thread; Rendering Loop The inner rendering loop strides through the geometric data for a portion of the data set and assembles 3D points, as well as references to the 2D imagery in the form of texture coordinates, into a large buffer containing single-precision floating-point values. This buffer is then transferred to the graphics card for rendering. In order for OpenGL to render the buffer, it requires a persistent pointer to the buffer's starting address. There are two versions of the inner rendering loop; OpenGL, and the other uses a standard Java programming language float . Because of the semantics of the OpenGL APIs, the only correct method of sending data down to the card from a Java programming language float is to either use Get<PrimitiveType>ArrayElements (which requires a memory allocation and data copy on any JVM which does not support pinning) or to use GetPrimitiveArrayCritical and copy the data manually; Such a data copy can easily be the bottleneck in an application. This demonstration was originally intended to use the NVIDIA 67 GL_NV_vertex_array_range (VAR) extension to OpenGL for high-throughput rendering of the terrain mesh. However, after implementing the terrain engine as well as supporting code to allow the use of the VAR extension, it was discovered that enabling VAR caused a slowdown when the polygon count went up; In the meantime, VAR can be enabled by passing in the -nv command line option to DBFlyer when running on a GeForce-based card with the latest Detonator drivers. Multiresolution Algorithm The terrain renderer uses a variant of the algorithm described in 68 LKR96 . The data set is subdivided into roughly 200 tiles and measures 13 by 15 tiles. Each tile contains both elevation and image data. At the highest resolution, each tile measures 513x513 elevation samples and 512x512 image samples. Tiles are downsampled into pyramids by recursively dropping every other sample. Image pyramids for texture mapping are created off-line. The geometric data is decimated at run time by iterating through the highest-resolution data with an appropriate stride. Maximum deltas as described in 69 LKR96 are computed off-line for each level of the elevation data pyramid. These deltas are defined as the maximum world-coordinate error incurred in the vertical direction by rendering a given tile at the next-lower resolution. The level-of-detail (LOD) selection algorithm is somewhat dependent on the deltas being monotonically increasing, so a quadratic curve is fitted to these deltas and they are subsequently resampled. However, this technique is not currently guaranteed to produce monotonically increasing deltas and, in fact, several tiles in the database produce deltas which are not increasing. The resulting visible effects have not yet been characterized. During rendering of each frame, the position of the camera is compared to the centroid of each visible tile. The maximum screen-space error is computed and compared against the precomputed maximum deltas; Thus, LOD selection is performed for each tile every frame and each tile's LOD is independent. The two primary contributions of jcanyon's rendering algorithm are its texture selection technique and a method for eliminating cracks in the surface called filleting. Texture selection It was observed that using the same algorithm for texture LOD as is used for geometry LOD caused unacceptable visual artifacts, as too-coarse textures were frequently selected. Synthetic "deltas" for the textures were created and the texture LOD selection decoupled from the geometry, but tuning of the texture deltas did not yield acceptable results; LOD algorithm to incorrectly shift to too-coarse LODs for tiles directly underneath the camera. Instead, a new algorithm was devised for selection of texture LODs. This algorithm is an approximation to screen-space error for images, and takes into account that the visible area of the texture decreases first as the tile moves further away from the camera, and second as the angle between the normal vector of the tile and the forward vector of the camera approaches 90 deg...
|
http://csua.com/feed/