Terrain Begun

im gonna sue dell, im sure they changed the chip to somethin like 800Mhz, and put the identifier on it as 2.6Ghz. GRRR. Il go buy some more ram!

Takes about a minute to init on my 1.8Ghz under w2k.

It’s very cool :slight_smile:


Would it be possible to avoid this start-up time (in a more complete game) by saving a serialized version of the terrain after the CLOD records are already established? (Actually, I think it would be nice if scene graphs were serializable generally, although annotating the tree with renderer-specific render states makes that slightly more complicated.)

We are considering that exact thing, regarding Clod records. No time estimate though.

We’ve also discussed ways of saving/loading a scenegraph, but as a more readable format (XML) that way, you could possibly create an entire scene without touching a line of Java. Also no time estimate.

Not to pour salt in the wound, :slight_smile: but the latest TestTerrrainPage with textures took just under 3 minutes on my 400Mhz Celeron :slight_smile:


:’(, a 400Mhz machine beats my machine?! and its a celeron too! :’(

Edit: retested my results, and it took 14 secs!. Yay! :smiley:

While I’m sure that some of this is due to my Radeon 7200 graphics card, even my celeron is able to move around the TestTerrainPage at about 30 frames per second at 1280x1024 16-bit color.

That bodes extremely well!


I’m playing around with TerrainPage.

One thing I noticed is that MidPointHeightMap sizes must be a power of 2, but TerrainPage requires a HeightMap size that’s a (power of 2) + 1.


Yep, MidPointHeightmaps can’t be used with pages, just blocks. FaultFractal and ParticleDeposition are 2^N + 1. Later, I might allow the MidPoint to generate an extra row and column to bring it up to the correct size.

"mojomonk" wrote:
We've also discussed ways of saving/loading a scenegraph, but as a more readable format (XML) that way, you could possibly create an entire scene without touching a line of Java.
Though exporting to an XML document is nice, performance is going to be horrendous. It should also be possible to serialize it to a binary format, since it would be a lot faster to import. In short, do both :)

Isn’t the proposed LWJGL model format based on XML?

Ok, Terrain is done for this release. There are future enhancements/improvements to be made later on, but this will be the initial cut.

One thing I want to mention, if you are using TerrainPage.

Speed results depend on a combination of things.

The three main factors are blockSize compared to size, using clod, and stepScale.

  1. blockSize defines how large the quadtree’s leaf will be. Depending on if you are using Clod sometimes a slightly larger block size is preferrable (more vertices to collapse). For instance, we found that using 257 sized terrain with a block size of 65 resulted in better speeds than 33. However, if you are not using clod, smaller is usually better, as more can be culled.

  2. Using clod does not always benefit in faster speeds, especially if the terrain is small. For example, for sizes 127 Clod resulted in speed decrease, while 257 and above resulted in increase.

  3. stepScale spreads out the terrain. This allows Clod to work even more efficiently for good sized terrain.

    Basically, playing around for your particular setting is the way to go.

Also, I should mention that it is a known issue that you can sometimes see seams between blocks. It will be addressed "sometime in the future" so no need to post your screen shots. :slight_smile:

For those of us who don’t see/know the obvious, disabling clod on my application changed the load time from 40 seconds to 1 second.

If nothing else, it’s useful to turn this clod off for intial testing.