Terrain angle

I want to create an efficient way to get the terrain angle at different resolutions, and to store these values in a similar way as the heightmap values. I want to use this for A* pathfinding, and to determine a natural location for objects, i.e.: vegetation, water and buildings.

Does anyone have resources regarding this subject, or pointers on how this can be conveniently incorporated in jme?

Please, also let me know if someone is working on similar ideas, so I won’t try to duplicate any work or ideas.

Just so it’s clear, I have relatively to the core devs here, very little experience with both java and jme3, so I’m not suggestion collaborating on this with anyone as I will slow them down. In a best case I can produce a small amount of code that can possibly be incorporated by a core dev.

Hey makeshift,

So you want something like getAngle(x,z, lodLevel)?

That can be done real-time for quite cheap: similar to how getHeightmapHeight() works, we can drill down to the mesh and grab the normals from the normal buffer.

The lod level could average these angles, or just sample the angles at set distances (like how LOD works).

This could be quite useful, let me see in the next few days how easy/fast it will be to do. I think at the very least a getAngle(x,z) would be useful, then you can just grab the angles from the neighbour points and average them to fulfill your other requirements.

Hey! This was pretty much adressed to you, thanx for responding so quickly.

That’s exactly what I thought of, getNormal(x,z,lod) might be a better name though. Averaging normal values for lod sound like a great idea, and since normals are already computed it will be the fastest way afaik. For convenience it would be perfect if a method with LOD could be added.

My objective is storing all of the normals on updated cells in a terraingrid in a certain LOD as fast as possible, and then to traverse them.

Sploreg said:
....or just sample the angles at set distances (like how LOD works)...
Sound like this would add unnecessary computations, better to let the user decide what LOD's are needed.

I just committed Terrain.getNormal(x,z) to terrain and terrainQuad/patch. I haven’t updated terrainGrid to handle it yet, I will do that tomorrow.

It does not take into account LOD. That I think I need to leave up to specific user implementations since different LOD techniques can change what normal is returned.

For building your navmesh, you probably want a high-resolution normal map (one normal per point) since the navmesh will be pre-computed anyways, and terrain isn’t all that high-resolution. Also if you are sampling points on the terrain for it, you can just sample farther apart for lower resolution and use that.

1 Like

Thanx for your commit and advice.