@jmaasing said:
I'll chime in with a +1 for ripping terrain and especially the noise stuff out of core (I agree with pspeed, even more things should be plugins).
I remember how many hours I wasted trying to understand the noise lib before giving up and just getting a Perlin implementation from the internet.
So I have my self to blame for those wasted evenings? No I donāt think so, including something in core signalled to me as a newbie that this is a special library that fit jME well for some reason and I should try hard to understand why that is. Turns out that wasnāt the case at all.
I know that feel. InfiniteTerrain isnāt usable at all. It gives NANs as a collision, support only 4 types of terrain, only diffuse, no lighting, and generation is just in crap state.
@normen said:
I don't think terrain should be taken out of core, the point of jme is that you get a toolkit to make games with. You can remove the terrain from your projects no problem but making it a completely separate plugin isn't a good idea imo. That said, I do think that the terrain implementation should be much more modular and reusable for other terrain purposes than the currently implemented one.
Actually there are two terrains.
One that is finite (probably can be made to infinite), stable, supported by ide, documented, supports lighting, shadows, up to 12 terrain types, normal maps, specular maps, glow maps, physics, vehicles. Main class for it is com.jme3.terrain.geomipmap.TerrainQuad.
There is also second. It only have infinite bounds but: is lacking documentation, is confusing, code have diferent meaning and calling convention, donāt work with anything like bullet or lighting. Itās quality is like junk. Main class of this system is com.jme3.terrain.geomipmap.TerrainGrid.
Currently i working on system that is infinite, is not intrusive, support up to 1024 of texture types (256x4 can be combined to have more diffuse, or to have difuse/specular/glow). It will work with ShaderNodes and as a non intrusive will not break any feature in core. 
In my opinion, TerrainGrid soon will be deprecated, not only because of quality of code, but also because there will be better alternative.
āEditā
GL requirements will be GL ES 2.0 + TEXTURE3D or GL1.5 + GLSL100. Current implementation uses TextureArray because Iām lazy.