These demos show several extremely different types of procedures that Procedural Terrain System supports. It does not show the power of combining these methods together… I only have so much time to write demos. Not only can you make a chain of any number of procedures, where each procedure is an instance with its own settings (and reasonable defaults), but each such procedure can target arbitrary areas of the map. On a single world map, I can have a stadium area with flat ground, a plateau area with 3 Simplex Noise functions over the flat plateau, a valley with FaultFractalHeightMap + some erosion, and a mountain+hill area made from a painted grayscale image + noise or with jME’s HillHeightMap. Then the game itself, a database, or interactive editing can modify it further. Nearly all of these are shown in the examples individually, but I have only combined 1, 2, or 3 procedures in each of the demos, so use your imagination.
If any procedure in your procedure chain has no edges (such as noise functions, Flat functions, etc.), then your final terrain will have no edges.
As mentioned previously, the Procedural Terrain System is a proper library. All of these examples were made by using the core classes, not by changing any library code.
Notice that the JmeHeightMapProcedure class demonstrated by the fractal example more than satisfies Momoko_Fan’s request:
Quote:
This library would be a lot more useful if it loaded pre-generated terrain, rather than creating it's own.
The raised plateau has a flat (constant) procedure which only effects the specified area of the map. The terrain would look more realistic if some noise were added, but I wanted to clearly show the plateau surfaces.
I just now completed the texturing system design in my brain. There will be texProcedureChains paralleling the elevationProcedureChains. Whereas (elevation) Procedures are for generating elevations from game world (x,z) coords, TexProcedures are for generating a reference/index of one of the tiled textures (like moss, dirt, water, etc.) from game world (x,z) coords.
I hope to have one TexProcedure working by Monday.
Now understanding how trivial texturing (such as the existing samples need), I've greatly shortened the sample classes.
In the source distro, see, for example, the classes com/admc/sample/TerrainRunner.java + com/admc/sample/FaultTerrainSample.java for how easy it is to use use PTS with a previously saved jME HeightMap or one generated at startup. (Or see the *Sample.java classes corresponding to the other demos listed on the app home page).
It would be great if somebody could make their own SimpleGame or StandardGame following the examples, to flush out any usability problems. Until I get the texturing system in place, you can attach any one tile-able TextureState to the ProceduralTerrain Node (including the provided sample dirt TextureState, as shown in TerrainRunner.java), in normal jME fashion.
Minor typo in MathUtil at one of the imports "java.math.MathContext;;" Extra ";"
Compiles fine after this is fixed.
It compiles that way without warning with default Sun 1.6 javac settings (and even with lint on), but I like my stuff to compile with strict checks. As soon as I get texturing done I'll turn up lots of compilation validations and clean up.
As you can see in the code, that has nothing to do with terrain, but I should make it easy for people to recompile the samples. I'll replace the PsychedlicSphere with the 3 lines needed to generate one from a jME Sphere.
I also notice that the couple of classes not in the terrain package itself did not make it into the API spec (I open-sourced these from my commercial code base). I'll fix the JavaDocs.
I'd like to add a slick build system (Ivy would be appropriate here), Eclipse configs, etc., but don't want to waste time on that until I know where the permanent home for this project will be.
UPDATE: Distributions updated with the reported items fixed.
UPDATE: I just now pushed the first public release. I want to write some TextureProcedures to allow for painting of textures, but all core systems are implemented, and anybody can write their own TextureProcedure implementations to satsify the interface. I'll take a screen shot and post an announcement Topic now...
Yes. To keep the applet small as possible (or to minimize runtime network bandwidth if it's a networked game with network-streamed map), generate your maps at runtime, instead of loading them from data. New area-limiters and procedures that I'll be working on later today and tomorrow will be applicable to this use case too.
