i'd say documentify, cleanify and optimify llama's code. if i remember correctly, it even allows implementing different LOD techniques.
i think the one llama implemented is quite similar to the one ogre uses. except llama's code uses dynamic loading/unloading of terrain patches and uses by default a higher LOD level (but i have to admit i drew this conclusion only by running the ogre terrain demo, so it isn't really objective).
nothing against your implementation todi, but as far as i remember it had no LOD.
oh my... i just love terrain LOD algorithms... XD
As i already said over a year ago (gush how time flies by): we don't want to compete. ( I just say that in case my english sounds different :D)
Basically there is one main difference between Iliamas aproach and ours.
Iliama (as i understand it) undertook the task to implement seemless terrain without anything else.
So he rewrote terrainblock, added some terainmanager and lod.
We had a more abstract problem. We were in need of a "framework" that could load and parse a world description and then takes care of everything including seemless terrain,
So we started out with the goal to have some "TerrainManagment" that takes care not only of endless terrain but also of placement of static objects in that world terrain, as well as static sounds skybox etc. in short a kind of dynamic world loader. We also started implementing a terraincreator that would create seamless terrain by adapting each "block" to the adjacent ones.
Since neither of us is a 3D guru we relied on jme standard features like the old terrainblock. When it came to lod and texture splatting however our knowledge came to a first limit. And since then we didn't have much time until a short while ago.
Now I think his implementation of terrain is more feature rich and better than ours. Naturally because we didn't implement one at all.
I think that our apporach to the more abstract problem (world loading with static objects, sounds, skysetting etc.) is better than his because (as i see it) it was not in his scope.
I think it would be beneficial if we could "define" the scope of a potential change in terrainhandling in jme.
We(our team) needs texturesplatting, dynamic loading of terrain AND objects and sounds in that terrain, simulation of daylight and change of skyboxes.
But the basic question for us all here is: What is needed or wanted for jme and what for developers using jme ?
If there is a need for a more general "world definition" framework like ours, then we might simply throw in our (in case of pure 3D rather abstract ;) ) knowledge and file format definitions and perhaps iliama assists with a new and adapted version of his code. I would be willing to spend time on this.
If there is a need for a terrain managment system then i agree that iliamas solution alone is perhaps sufficient for most people.
Comments ? Suggestions ?