I’m investigating JME against Xith3D and noticed that terrain engine performance are not up to par (sadly).
I’ve recreated a JME demo like the Xith3D demo, with flat vertex shading, no textures and the same heightmap (loaded via an external grayscale image).
The differences were noticeable, the lowest FPS I get on Xith is around 30 FPS, while JME has 8-10 frames as maximum, unless all the terrain patch is outside the screen, where i get outstanding top FPS (around 200) while Xith sits around a top of 60.
The strange thing is that JME is superior in any other test, is just the terrain that has slow performance, it is a known shortcoming that can be bettered (even by some volonteer like me, not necessarily by the staff) or is a limit of the architecture?
I made JME using the TerrainPage with CLOD enabled (even if disable there’s not much difference, just a couple of fps).
The hardware is a P3 800 with 384 MB of RAM. The video Card is a GeForce 2 MX (32MB).
I made the measurement at the work PC, at home I have a Athtlon XP 2.4+, 1 GB Ram, Ati 8500 256MB and performances are better (min 40 FPS) but the gap between Xith and JME on terrain rendering remain consistant (in any other aspect JME seems to fare well).
One thing I noticed is that CLOD for terrain use the same technique for meshes (only visual inspection). This make the terrain remain more highpoly than the Xith counterpart that scales the LOD more efficiently. This speculation can be true?
Does the jME terrain have more triangles? I wonder if we can put that into VBO?
I think that’s a major problem, using flat shading you can see lots of triangles even when the terrain is lodded. I guess some performance hits can be overcomed using an ad-hoc system to reduce the visible vertexes-triangles in a frame, but it seems to me that the surfaces of my heightmaps are at least interpolated to have an accurate (but slow) land profile.
I also saw that Xith reduces details far earlier than JME in terrain rendering, maybe there’s a way to use a different lod manager for terrain nodes (this may be a nice solution, after all). This may be useful even to reduce the load for highly crowded scenes, where the default lodding seems to be not enough.
Using a too much high scale stretches the terrain and you’ll lose the land features.
I don’t think that game-wise using less polys will be more bad in term of overall quality, anyway this evening I’ll try to investigate the matter in more detail.
There’s a nice Terminal Velocity clone incoming if all goes well 
Just get me in the right direction and I’ll try to get something out.
I haven’t been all that pleased with the terrain performance either, especially in memory.
The Clod algorithm reduces the triangle count but keeps the shape (i.e. zero popping), but does end up leaving more triangles on screen.
The current implementation is pretty much for newer hardware, as it is pretty much straight Quadtree. Geomipmapping or something would be needed to get a high speed terrain up and running on lower-mid range hardware.
Is there any plans on improving the terrain system? I had the same problem and it is keeping me from using terrain in a game.
I’m sure it will be improved… That said, I use Terrain in Dirt and it still runs at a respectable rate… And I use models, basic ai, lensflares, a special third person camera, sounds, skybox, and so forth at the same time.
Sorry for the lack of feedback but my box died friday morning and the new one has huge issues handling high AGP bus traffic (so almost no 3D usage), thanks VIA and their crappy post XP SP2 drivers…
BTW, before I died made some tests with the terrain and just using a more aggressive CLOD is improving performance considerably (at least for my needs). The aim is to have a not so vertex-dense terrain system with reasonable LODding.
As soon I will have my PC at full shape I’ll report back, for now no OpenGL dev at home (and at work I must work, sadly).