Procedural Terrain System, Temporary Home

$Revision: 2775 $

You do not need the PTS source code to use the system, unless you want to use the provided samples as templates or for study. Otherwise, just download the binary jar (link provided below) and code from the API spec (link provided below). UPDATE: Support for efficient and durable terrain-configuration persistence has been added, You can discuss the Procedural Terrain System or seek help at the User Code & Projects forum at jMonkeyEngine. PTS is redistributable according to the Apache 2.0 License. Table of Contents Resources Demos Features

The MiniMap below shows the instantaneous status of all local terrain blocks shaded = not instantiated; z = not attached; o = cullled; x = intersects frustum (not culled).

Resources

• Binary library jar file pts.jar.
• API Spec, includes refs to actual source code (drill down on the class name link toward the top of each class page).
• Source distribution zip file pts-src.zip

Demos

There are SimpleGame demonstrations of Procedural Terrain System. Each launcher either demonstrates a particular procedure (aka elevation-generation algorithm) or tests something currently being troubleshot.

Be aware that the System purposefully allows intermixing of all of these procedures. These demonstrations purposefully limit the number of procedures so the procedure being exhibited can easily be distinguished.

The normal 'q' and 'z' SimpleGame keys won't work for SimpleGame demos when surface-traversal mode is on. Use PGUP to allow the camera to escape the terrain surface (which is useful for viewing the terrain at a wider scale). If you want to change screen settings (for Simple*Game), use this button: Display Settings
Reset

The samples which implement multi-pass texturizing use a elevation-derived texture mapping with a geometrical exclusion zone (the dirt triangle before the starting camera location).

• Modeler: Multi-pass-Texturized 2 Simplex functions + a large Grayscale map SHIFT+F1 to load the terrain. SHIFT+F2 for World mini-map. Use LMB+RMB or normal keys to walk (add SHIFT to run). Use SHIFT+F10 to hyper-jump to anyplace on the world map (-5000 m to +5000 m in X and Z directions).
• SimpleGame: 2 Simplex functions + a large Grayscale map^*
• SimpleGame: Multi-pass-Texturized 2 Simplex functions + a large Grayscale map^* Same as previous, with real texture splatting.
• SimpleGame: Plateaus / flat areas^* This is suitable for paved/floored areas. For more natural areas, a noise function should be applied on top. This terrain has no edges.
• SimpleGame: Multi-pass-Texturized Plateaus / flat areas^* Same as previous, with real texture splatting.
The portal in this example now loads a new terrain from the Internet, replacing entire starting terrain map. Just step onto the dirt diamond to teleport.
• SimpleGame: Uses a jME FaultFractalHeightMap^* The same exact procedure class (JmeHeightMapProcedure) can be used in the same exact way for any jME AbsoluteHeightMap subclass.
• SimpleGame: Declaratively configured Terrain using a jME FaultFractalHeightMap^* Exactly the same as the previous item, but this terrain is configured at runtime by loading this text configuration file from the Internet and configuring the terrain accordingly.
• SimpleGame: Height procedure ranges limited by 2D indexed image^* Regions of height algorithms (which are purposefully trivial here) are limited according to this PNG file. Use the PGUP key and "q" to fly up to see that the green region in the PNG file gets raised, and the red region gets lowered to a channel.
• SimpleGame: Texture and Height procedure ranges are limited by 2D indexed image^* Same as previous example, except that both elevations and textures are mapped according to the same PNG file. This is just one combination, and not a particularly useful one, of area limiters.
• SimpleGame: Height procedure ranges limited by SVG image^* Regions of height algorithms (which are purposefully trivial here) are limited according to this SVG file. The ground is unrealistic and flat here, to make the area-limited regions obvious. That is the advantage of vector graphics. The game areas covered by these high-res borders are massive (as you will appreciate if you walk as suggested in the next sentence). Turn to the right and walk for a long while until you hit the raised area corresponding to the magenta curvey in the image. Then follow that to the right and you will eventually come to where it intersects with the lowered area corresponding to the red ribbon.
• SimpleGame: Multi-pass-Texturized Height procedure ranges limited by SVG image^{* **} Same as previous sample, except that both elevation and texture areas are limited by the same SVG image. In this case, there is no variation within the texture areas, so the texture bordering here is trivial and the same result can be achieved directly with a SVG Texture Procedure (as exemplified below). Until I/we improve SVG performance, as explained below, this sample takes nearly a minute to load.
• SimpleGame: Textures painted by indexed PNG image^* To eliminate a distraction, I have purposfully applied no elevation variation at all here. After appreciating the texture resolution at the surface, fly up with PGUP and "q" to see that the textures are applied according to this very low res (50x50) image. The ragged edges are due to the low image resolution. To show that you can ignore some colors, I have not mapped the bluish color in the image.
• SimpleGame: Textures painted by SVG image^{* **} The ground elevation is unrealistic and flat here, because our purpose is to demonstrate only texture splatting. The texture mappings are specified by this tiny SVG file. The game areas covered by these high-res borders are massive (as you will appreciate if you walk as suggested in the next sentence). Turn to the right and walk for a long while until you hit the snowy area corresponding to the magenta curvey in the image. Then follow that to the right and you will eventually come to where it intersects with the dir-textured are corresponding to the red ribbon.
Until I/we improve SVG performance, as explained below, this takes about a half minute to load.
• SimpleGame: Interactive HillHightMap with editable Elevations and Textures^* Keys to use are listed on the screen.
  • Numpad + - to elevate or excavate
  • Numpad * to texturize
  • _ to smooth/flatten
  • ,.[] keys to adjust editing parameters. The m value shown is magnitude). r is brush Radius. Set magnitude to 1 to completey flatten terrain. Set tex# to -1 to restore the default (dirt) terrain, 0 for grass, 1 for snow.
  Notice that the elevation-derived texturing is applied dynamically and automatically as you alter elevations, and that interactive edits override that texturing behavior, as it should. Automatically persists and loads changes to/from binary .ser file. To reset, delete the following file in your temp dir: TerrainRunner-<USERNAME>.ser. The saving is done very efficiently: We save only precisely what has been changed. Make changes and check the size of your .ser file.
• SimpleGame: Declaratively configured textured Terrain using 2 Simpex functions + GS map^* Exactly the same as the demo with the same features above, but this terrain is configured at runtime by loading this text configuration file from the Internet and configuring the terrain accordingly.

Please report any bugs at the jME User Code & Projects forum.

* SimpleGame demo details: The movement speed in all of these accurately models adult human jogging speed. To experience walking or running speed, change the movement speed variables as directed in the TerrainRunner.java code and recompile.

The SimpleGame which drives all of the SimpleGame examples is com.admc.sample.TerrainRunner, which you can find in the source distribution (see link above).

Features

• Proper hands-off library design.
• If you do need or want to recompile, the source code compiles very cleanly with strict warnings on.
• Unlimited mixing of procedures in the procedure chain.
• Extreme flexibility, by virtue of pluggable procedures and true OOD where each map, procedure, etc., has its own settings. Higher level structures such as elevationProcedureChains and world TerrainMaps are themselves instanced objects. Each procedure has reasonable defaults but allows for fine-grain control over scales, randomization, area-of-applicability, etc. The constructors and optional setters for customizing behavior are well documented in the API Spec.
• Supports edge-less (infinite) terrains, unless you specify only elevation procedures with edges (such as JmeHeightMapProcedures). Note that it is trivially easy to add a noise or flat procedure to a fixed procedure chain to make it unlimited.
• Each elevation procedure can target arbitrarily-specified areas of your game world.
• Interactive terrain editing (and persistence of changes) to both elevations and textures.
• Unlimited real texture-splatting support.
• Provided elevation procedures include a procedure to use jME Height Maps, and a sample for game-controller terrain excavation/modification.
• Provided texturizing procedures include a procedure that applies a texture based on the location's elevation.
• Gracefully supports hyper-jumping (moving the camera a huge distance in a single frame, as opposed to continuous movement).
• Graphical 2D painting of elevations, using 16 bit Grayscale files. PhotoShop is the only tool I'm aware of which supports doing this in an intuitive way (without tricks).
• Graphical 2D painting of arbitrary region/area boundaries, using standard indexed image files (I suggest indexed PNG). These can be used to set target areas for elevation procedures and/or texture procedures. The supplied procedures are not suitable for setting limits for huge, high-res borders, since that would require huge indexed image files to remain in RAM.
• Graphical 2D painting of arbitrary region/area boundaries, using standard SVG image files. These can be used to set target areas for elevation procedures and/or texture procedures. The great advantage here is that you can paint just like with indexed images (previous item), but the SVG file sizes are not proportional to the area covered. SVG files specifying numers complex regions in huge came worlds wil be very small. See ^** foot note below.
• Graphical 2D painting of textures, using standard SVG image files. This leverages the same benefits as listed for the previous item (and suffers from the temporary performance problem which is also listed there).
• The 2D painting features can be combined to paint regions and textures over top of a read-only height-map image layer in graphical editors like Gimp, Inkscape, and PhotoShop. Tip: You will usually want to work with a down-sampled copy of the 16 bit height-map for this. You must down-sample for Gimp and Netscape, which don't handle 16-bit grayscales.
• Declarative terrain configuration, via XML. See the following item.
• Durable persistence of terrain configurations. Here is an example of an elevation-only (no texturing) configuration. The TerraunRunner.java sample shows how to easily load this configuration file from the Internet, and you can run a launcher above to do it right now. There is also an example of a text configuration which much more complex elevation procedures and texturizing. The configurations are saved in XML format because this satisfies many more use cases and the performance impact of these tiny XML files is insignificant compared to terrain load time. If anybody justifies a need for binary serialization persistence (which is faster but less durable), that feature could be added in a straight-forward manner.
• Efficient transfer of terrain configurations. This is just a consequence of the previous item. Terrains can be passed among game components (peer-to-peer, client/server, etc.) very efficiently.

** As of the my first SVG support implementation, the original load time is very slow for large terrains as the SVG data is converted into cache blocks of much less efficient raster data. There at least two strategies to drastically improve performance by eliminating the raster level completely. One option is to make a custom SVG class to allow pixel values to be sampled directly from the vector data. Another option is to enhance the jME image combiner functions to support direct combining between raster and SVG images.