What are the obligations of TerrainGridTileLoader?

I have a nice procedurally generated terrain (quad). To generate it I use a class I wrote that generates a heightmap (as a float[]) and an alpha map Texture for the splat maps.

So I create my TerrainQuad something like this:


hMapGenerator = createHeightmap(assetManager, terrainSize);

terrain = new TerrainQuad(“my terrain”, patchSize, terrainSize, hMapGenerator.getHeightMap());

Texture alphaTexture = hMapGenerator.getAlphaTexture()

mat_terrain.setTexture(“AlphaMap”, alphaTexture);


The rest is pretty standard stuff of adding textures for the DiffuseMaps (I’m using TerrainLighting), adding a TerrainLodControl, setting up physics and that. It all works great.

So I’m thinking that I’d like to use TerrainGrid. As a test I created my own TerrainGridTileLoader and since it has the method:

[java]public TerrainQuad getTerrainQuadAt(Vector3f location);[/java]

I’d thought I’d just use the same code I already have to create a terrain quad and return that. But that doesn’t work, I get no terrain showing at all, no errors in the logs either.

So my question is if the TerrainGridTileLoader really can return a TerrainQuad with all bells and whistles (physics, materials, scaling and so on) or if it would make sense to change this interface to actually return the heightmap?

It can, check out the j3o streaming. We plan to add editing of such grids to the SDK so you can add models and batch them and/or add AssetLinkNodes even on single tiles, which will then be saved just like other j3os, streaming/linking/caching the data using the AssetManager.

Oh, that’s cool :slight_smile: