Chapter 28. Trees That Grow


Accelerating Terrain Following

The code for terrain following sacrifices accuracy for speed, meaning that users can move quickly over the terrain with the disadvantage that they move straight into the side of a mountain or float off the edge of a cliff. Their vertical position will be corrected, but a temporary position disparity is disconcerting. What can be done? A number of tricks can be utilized without making any fundamental changes to the application.

The step distance used in KeyBehavior is 0.2 world units, which is 26 terrain units (0.2/0.0078125). As a rough comparison, each mesh coordinate is 30 units apart. If the step distance was reduced, the user would move over the terrain more slowly, and height changes would occur more gradually. This would help the picking code keep up with the height adjustments.

It's possible to increase the user's height, which is 0.5 world unit in KeyBehavior or is 64 terrain units. If the eyeline is higher off the floor, then a larger height change will be required before the users notice that they've sunk beneath the surface.

Two other solutions are to create landscapes with gentler slopes and make it impossible for users to move into rough terrain by imposing restrictions on KeyBehavior. This latter kind of behavior is typical of racing games, where a vehicle can only move a short distance off the racing track.

The terrain and scenery (the 3D and 2D ground cover) are different. Even when the terrain is flat, the problem of walking through castle walls and trees remains. The general approach I've used in previous examples (e.g., the maze walls in Chapter 25) is to store information about the obstacles' location and prevent the user from walking into them.

More Threads?

Since HeightFinder is a thread, why not throw more threads at the task? The single HeightFinder tHRead takes a couple of seconds to finish a calculation before it can start the next one, which adds a considerable delay to the processing time for the next request. By having several threads, the turnaround time would be reduced since the wait time would be less.

I tried this and discovered that picking on a geometry cannot be threaded. Multiple threads can initiate picking at roughly the same time, but each operation is sequentialized, and extra time is added in the process. Threads may be more successful if the picking is carried out on different GeometryArrays, but I haven't tried it.

Mesh Decomposition

The real problem is the mesh is too large for efficient picking. It should be divided into pieces, perhaps based on the terrain's latitude and longitude. Then, as a user moves over the terrain, the relevant terrain piece can be selected easily and picking would be faster due to the smaller size of the piece.

Multiple pieces lend themselves to the support of multiple levels of detail and dynamic loading. Several of the approaches described in the next section use these ideas.



Killer Game Programming in Java
Killer Game Programming in Java
ISBN: 0596007302
EAN: 2147483647
Year: 2006
Pages: 340

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net