More on Terrain Generation


Finding the Surface Height

KeyBehavior interacts with HeightFinder by calling requestMoveHeight( ), which stores a (x, y, z) coordinate in the global theMove Vector3d object:

     // globals     private Vector3d theMove;  // current move request from KeyBehavior     private boolean calcRequested;     synchronized public void requestMoveHeight(Vector3d mv)     { theMove.set(mv.x, mv.y, mv.z);               // will overwrite any pending request in theMove       calcRequested = true;     }

The (x, z) values in theMove are used for the picking calculation. The calcRequested Boolean signals a pending request.

If the user presses the move keys rapidly, KeyBehavior will call requestMoveHeight( ) frequently, causing theMove to be updated frequently. When HeightFinder processes the next request, it will find only the most recent one in theMove, saving itself unnecessary work. This illustrates the decoupling of key processing from height calculation, so the users can move as fast (or as slow) as they like.

requestMoveHeight( ) returns immediately; KeyBehavior doesn't wait for an answer, or it might be waiting for one or two seconds. Instead, KeyBehavior uses the current y-height for its move. HeightFinder's run( ) method constantly loops, reads the current move request from theMove( ), and then calls getLandHeight( ). At the end of getLandHeight( ), the new height is passed back to KeyBehavior:

     public void run( )     { Vector3d vec;       while(true) {         if (calcRequested) {           vec = getMove( );      // get the requested move           getLandHeight(vec.x, vec.z);   // pick with it         }         else {   // no pending request           try {             Thread.sleep(200);    // sleep a little           }           catch(InterruptedException e) {}         }       }     }

The data in theMove is obtained via getMove( ):

     synchronized private Vector3d getMove( )     { calcRequested = false;       return new Vector3d(theMove.x, theMove.y, theMove.z);     }

The method is synchronized as is requestMoveHeight( ) since the methods access and change theMove( ) and calcRequested( ), and I want to impose mutual exclusion on those operations.

Picking in HeightFinder

getLandHeight( ) in HeightFinder implements picking on the landscape and uses the same code as getLandHeight( ) in the Landscape class in FractalLand3D. Placing the code in the HeightFinder class is a matter of taste: all the height calculations should be located in a single object.

The HeightFinder constructor is passed a reference to the Landscape object so terrain-related data and methods can be accessed:

     // globals     private Landscape land;     private KeyBehavior keyBeh;     private PickTool picker;     private double scaleLen;     public HeightFinder(Landscape ld, KeyBehavior kb)     {       land = ld;       keyBeh = kb;       picker = new PickTool(land.getLandBG( ));   //only check landscape       picker.setMode(PickTool.GEOMETRY_INTERSECT_INFO);       scaleLen = land.getScaleLen( );  // scale factor for terrain       theMove = new Vector3d( );       calcRequested = false;     }

The PickTool object, picker, is configured to examine only landBG. However, 3D models and ground cover are attached to this node, so they should be made unpickable; I'm only interested in obtaining floor coordinates at pick time.

One feature of getLandHeight( ) is the pick ray is specified in world coordinates even though the PickTool is attached to landBG (which uses landscape coordinates):

     // global     private final static Vector3d DOWN_VEC = new Vector3d(0.0,-1.0,0.0);     private void getLandHeight(double x, double z)     {       // high up in world coords; shoot a ray downwards       Point3d pickStart = new Point3d(x, 2000, z);       picker.setShapeRay(pickStart, DOWN_VEC);       PickResult picked = picker.pickClosest( );       if (picked != null) {   // pick sometimes misses at edge/corner         if (picked.numIntersections( ) != 0) { //sometimes no intersects           PickIntersection pi = picked.getIntersection(0);           Point3d nextPt;           try {   // handles 'Interp point outside quad' error             nextPt = pi.getPointCoordinates( );           }           catch (Exception e) {             System.out.println(e);             return;   // don't talk to KeyBehavior as no height found           }           double nextYHeight = nextPt.z * scaleLen;                                // z-axis land --> y-axis world           keyBeh.adjustHeight(nextYHeight);  //tell KeyBehavior height         }       }     }  // end of getLandHeight( )

The intersection point is obtained in local (i.e., terrain) coordinates by calling PickIntersection.getPointCoordinates( ), which returns the point in world coordinates.

KeyBehavior utilizes world coordinates, so the height value (nextPt.z) must be converted, but this can be done inexpensively by scaling the point directly to give nextYHeight. This value is passed to KeyBehavior by calling adjustHeight( ). The world coordinates are needed since KeyBehavior uses the terrain's height to adjust the user's position in the scene.



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