Nice one Llama, just delving into the code - the loading of a heightmap is threaded.
Ill make a similar implementation whereby a task is also created when the data is available, then expand this for textures and sceneobjects
Well yes, that's the point of it… everything is already asynchronous (loading, creating geometry etc). It used the jME Task Framework I created for this project, which enables you to have special tasks that can be paused during rendering, excecute in the OpenGL thread, etc.
If you want Object loading, just create a new pass OR hook it in the file loader, and fire new tasks to load the objects (with caching I presume), place them on the terrain, etc.
What I'll be doing for the next release is making sure everything SimpleTerraView itself does is also run in a task, so that it doesn't delay the rendering…
I added
try {
Thread.sleep(7000);
} catch(Exception ec) {
}
in the loadMap of jmexMapStore, only one task is created at a time and it waits on one map retreived. Wonder if there is any benefit in creating a task to tell the
DistanceLoadingPass when the data is ready. that way it can continue to request many maps
Anyone any objections to using java 1.5 code for Future and Callable
Edit the above - the thread sleep test is not comparable , the loading is single thread, but the task queuing isnt.
Forgive moi,
I don't mind using 1.5 code (jME is 1.5 after all) but let's not mix Future and Callable with the other task system being used. The framework I wrote is better suited anyway, Sun's stuff doesn't really fit a high performance OpenGL application, since it doesn't let you control when NOT to execute any tasks, or in which thread it should be done.
Agree that the threading should remain as is for now - will get fer too complex to mix jobs in hand with touching that too. Also it works fine as it is.
The advantage of the new threading stuff is that you can do away with all the synchronized calls ( isThereALock, getTheLock, doTheLock, didYouGetThelock etc ).
The idea is that the main thread doing the rendering also has a BlockingQueue from which it can obtain tasks. It can then choose to run these tasks in the jme update method.
Yes, unfortunatly there's no method that I know of for pausing those task after a certain time using the 1.5 stuff.
Lllama, with respect to TerraData. It has a single textureBuffer.
The question is - is this adequate for all needs, or should we look at an opaque textureBuffer and an alphaBuffer.
Another puzzle in my head is that if a smaller texture is repeated accross many parts of the terrain - say the dirt.png and then various textures are placed on top, what would be the optimal way to do this. should this be abstract so that the user can plug in their own implementation..
have started a task implementation - but will go into more detail on that later
TerraData is just a placeholder. Ideally there should be plugin system so users can create their own TerraData/TerraMesh implementation, so they can add textures, shaders, etc.
In that case - any objection to abstracting out TerraData and TerraMesh. The current example implementation becomes SimpleTerraSata and SimpleTerraMesh.
Also - to keep TerraView intact as is, TerraData will need to create a TerraMesh instantiation, thereby keeping TerraView in tact as is. It is TerraData that will know the Type of TerraMesh, making TerraData in essence a factory.
reference is a snippet from TerraView
public void update() {
synchronized (terraNodes) {
if (!terraNodes.isEmpty()) {
TerraData tdata = (TerraData) terraNodes.iterator().next();
while (terraNodes.remove(tdata));
if (tdata.getTerraMesh() == null) {
TerraMesh tmesh = new TerraMesh(tdata);
tdata.deleted = true;
tdata.setTerraMesh(tmesh);
would become
TerraMesh tmesh = tdata.createTerraMesh();
Not at all, that's been on my TODO for ages 
I'd keep SimpleTerraData/Mesh indeed very simple, and put most of the stuff they do in a TerraUtil class or something like it.
the abstraction is done per above. only reservation is that the passes DistanceGeomPass and LODPass relied on the implementation of TerraData. These have been renamed Simple* . However, once a satisfactory factory for the TerraData is known by the passes and a new method is added onto terradata then perhaps they can get changed back.
the archive can be downloaded from www.forthestars.com/jme/terra.rar
The tests still work…
Have added sparce documenting. really need to start writing a tutorial also.
Started to create a LoadTextureTask - rough outline as follows but still in design stage
SimpleTerraView should have a
TaskRunner runnerMapTextureLoader = new ContThreadTaskRunner(1)
Abstract class TerraMapTextureDecoratorPass extends TerraViewPass
This will know what Textures it needs for the map, will create as many TerraLoadTextureTasks as it needs. This decorator will need to be notified when the data has been converted from each TerraJMETextureTask directly from the TaskObject.
It is up to the implementation of TerraMapTextureDecoratorPass to decide when it is ready to decorate the terrain. it may wish to do it in one pass of the update method, or many passes until it has completed. Therefore it needs a method boolean decorateMap in which it decorates the map and returns a boolean if it needs to decorate on a further update pass. If it returns true, the task is set to
The first task TerraLoadTextureTask, and would obtain the texture data required for one map ( abstract - so from a file, url or not at all if it is a Savable Texture ) .
Once the data has been obtained, a second task being TerraJMETextureTask will convert the data obtained from the TerraLoadTextureTask to jme format ( a Texture )
I can start work again on wednesday. In the meantime and if you agree please release this version
okay okay - wednesday has been and gone - more delays …
Hopefully be able to get going again early tommorrow.
Ill look to get a basic texture example on the terrain which will serve for anyone wanting to try out splatting or shaders.
Excuse my ignorance, but I have tryed to place a TerrainView with the following instructions:
tv.setLocalTranslation(1f, 1f, 1f);
tv.updateGeometricState(0.0f, false);
just at the end of the simpleInitGame() method, after I created the TerrainView and everything seems to work well.
Now, what about the "add a TerraView anywhere" problem? I passed up any mentions in this thread about a fix, or the TerrainView should be placed in scene through some other method?
well try some bigger values I guess, 1f is just one square. Plus it should work with scaling, and probably the whole thing should work at different angles too.
Maybe I did fix the distance thing though… :-o it should be simple of course
I was trying to reproduce that error, because I was planning to fix it (and also scaling bug). But if you plan to it by yourself, I think you will probably get a better (and faster) result. 
Anyway I tryed also a bigger value (0f, -10f, 0f), and things still worked well. Now, I guess that the value should be bigger… something about 100?
I guess I already fixed it. It's in the SimpleTerraView update method I think. Don't it takes into account the "heigth" though. Also. try a different scale though, and then move into a certain direction… you'll see you'll go faster or slower than the terrain updates.
Have recently been porting from swing to fenggui - about 120 screens so far.
Will get the basic render done when i get a chance - probably in a week or so …
In the mean time - if you are happy with the abstraction, can you update the src so that other people can grab it in the off chance that they wanna try rendering too ??
I need some help debugging threading issues when using jme terra. Sometimes, during loading of new blocks, the main thread locks up (profiler reports main() thread to stay in monitor state forever). Does this indicate a deadlock? I assumed it did, and in order to find the exact place where it occured, sprayed debugging printlns all over the DistancePasses' add() and remove() methods… which, naturally, slowed the system down enough to not hang up any more.
I hear that there are amazing new ways of finding deadlocks builtin to java 6, but I can't seem to be able to use them - does anybody have any clues for me?