Say I have 64 or 128 TerrainQuads tiled together in a scene, each with their own LOD control… Each of these TerrainQuads spawns its own thread (a single thread) to handle the updates on that TerrainQuad. Doing this on a large number of TerrainQuads will pretty easily bring any machine to its knees, so what is a good solution?
I started simple by just plugging in my own ExecutorService that would globally handle all TerrainQuad updates… It was definitely smoother than having a separate thread for each, but was clearly struggling to run smooth.
[java]
import com.jme3.terrain.geomipmap.TerrainQuad;
import java.util.concurrent.ExecutorService;
/**
Allows for an alternate {@link ExecutorService} to be plugged in on which to run
LOD updates.
@author Skye Book
*/
public class PluggableExecutorTerrainQuad extends TerrainQuad{
public PluggableExecutorTerrainQuad(String name, int patchSize, int totalSize, float[] heightMap, ExecutorService lodUpdateExecutor) {
super(name, patchSize, totalSize, heightMap);
// Set the executor
executor = lodUpdateExecutor;
}
}
[/java]
As of now, turning off LOD altogether is faster than running as-is or with the above adaptation to use a single thread pool. Does anyone have any ideas?
You should instead have only one TerrainQuad and stream in the underlying data. If you have 128 TerrainQuads on screen theres no way you see each point of each TerrainQuad. So if you have a 512x512 map and zoom out just take 1024x1024 points of your “real” map and condense them down, then the same TerrainQuad can display an area that is twice as large.
@normen said:You should instead have only one TerrainQuad and stream in the underlying data.
That would probably be a smart thing to do :) I've have to write something to combine all of the terrain textures together on the fly.. That shouldn't be too big of a deal.
That said, I very stupidly left the video recorder app state attached which was wreaking total havoc on performance.. Turned that off and it was smooth as silk (with both the original way of doing things and by using re-using thread pool).
My solution was to write a callable, that has an quadtree (of self-made terrain quads) as a parameter and camera location. This function’s responsibility was to check all the tree and split-combine quads if necessary. After the function is finished, the special flag is set tu true, meaning that we can call this function again in update loop. Using this method it was necessary to make a queue of quadtree nodes that needs to be splited or combined, and prepare them also in separate thread (preload textures, etc.), and in update loop write some weird function that deletes from rootNode all quads that are “old” and attach new ones from queue. After that empty the queue and call callable again.