Yes, they get removed because they are no longer part of the view distance. That’s essentially what the view distance is there for. If we allow tiles to stay in the scene, we alter the graphical capability of the game. Your PC may be able to handle 5 tiles in each direction, by my poor laptop may not. If your game decides that a tile should stay in the scene for some reason or another, you increase the average triangle count significantly as a result, and it becomes unplayable in the situations that you deem appropriate to keep that tile in the scene. Just be aware of that whilst reading below.
The tiles extend TerrainQuad, and so inherit all of the cool stuff they can do.
The TileListener#TileLoaded and TileListener#TileUnloaded events are called directly before they are added or removed from the scene. You can return false to these events to cancel them if you wish, so as you stated, you didnt want to unload a tile - you would cancel the TileUnloaded event by returning false.
Tiles are distinguised by their position, and you can work out if something is in a tile like so:
[java]
// just some data to use as an example
Vector3f enemyPositoin = new Vector3f(199, 20, 2332);
int tileX = (int)enemyPosition.getX() >> bitshift;
int tileZ = (int)enemyPosition.getZ() >> bitshift;
// this is the tile location the enemy is in.
TerrainLocation enemyChunk = new TerrainLocation(tileX, tileZ);
[/java]
Now we know this, we can do the same in the TileUnloaded event.
[java]
public boolean TileUnloaded(TerrainChunk terrainChunk)
{
int tileX = (int)terrainChunk.getLocalTranslation().getX() >> bitshift;
int tileZ = (int)terrainChunk.getLocalTranslation().getZ() >> bitshift;
// this is the tile location of the tile that will unload.
TerrainLocation tLoc = new TerrainLocation(tileX, tileZ);
if (enemyChunk.equals(tLoc)
{
// the enemy is in this chunk, and it wants to unload,
// so cancel the tile unload event.
return false;
}
return true;
}
[/java]
The tile will attempt to remove again when you move out of the chunk you are in, so you dont necesarrily need to clean up after yourself when you cancel it.
In addition, its also worth mentioning that there is also a TileListener#tileLoadedThreaded method, that allows you to load models, do some math, modify the tile as you please, add to it, whatever - in the thread that loads the tiles, rather than in the GL thread - which may cause a noticable delay in your game.
The threadpool in the World.java class determines how many threads to use. This threadpool is used to load tiles as well as determine the LOD of each loaded tile, so theoretically (depending on whether there are any threads available) each tile is loaded in a seperate thread - so although doing very intensive tasks wont delay the loading of other tiles (which is the ideal situation), it will delay the loading of that tile specifically.