Querying atlas terrain info?

#1 Anyone? Ben? Bueller?

#2 A) No.
b) There is no blocksize.
c) No.
d) You don't.

Atlas is a whole new paradigm. It can support any sort of geometry, so getting height isn't really meaningful anymore. You're working in poly soup now. :)

What are you trying to do? Maybe there's a better way to do it now.

#3 Hi Ben: basically what we were doing before was retrieving the TerrainBlock, retrieving the height at each vertex and using those heights to calculate the slopes of the terrain triangles. We stored those slope values in a map that we could use later on with our pathfinding engine to determine which areas of the map were too steeply sloped to allow RTSUnit movement.

We were using a standard(?) 2048m x 2048m terrain created from a 256x256 image with a squaresize of 8. So we would do something like:

for(int i = 0; i < 256; i++)
{
     for(int j = 0; j < 256; j++)
     {
          a = terrainBlock->getHeight(j, i+1);
          b = terrainBlock->getHeight(j+1, i);
          c = terrainBlock->getHeight(j, i);
          d = terrainBlock->getHeight(j+1, i+1);

          storeSlopeFromTriangle(i, j, a, b, c);
          storeSlopeFromTriangle(i, j, a, b, d);
     }
}

That was extremely over-simplified of course, but it's basically the process we used. Since the heightmap vertices were 8 meters apart, that was really the best resolution we could get. I'm hoping we can get much more detailed terrain from Atlas.

I don't quite understand though: since Atlas is currently only supporting heightmap-based geometry, why isn't the heightmap exposed so it can be queried like the old terrain could? Should I be using AtlasInstance::castray to get the heights now? And maybe "blocksize" isn't the right term to use anymore, but the heightmap still has a "resolution" which determines the distance between vertices so shouldn't there be some way to query it?

Thanks!

#4 Hey Justin,

The geometry is not stored as a grid, even on the lowest detail levels. It could potentially be anything - up to, including, and beyond, an entire eight story building, if you wanted. There are no constraints on vertex spacing, although the current generator implementation has a grid spacing based on the parameters you pass it.

Atlas supports ANY geometry. It's just the generation tools that only support heightfields. The heightfield isn't exposed because at runtime it's not loaded - just geometry.

I suggest using castRay if you want to sample heights, or doing an exact solution based on the mesh. You could easily add a bitvector to the format to store a per-polygon flag indicating whether a given face is traversable or not. Or you could get more creative than that.

#5 Ok, thanks Ben. I didn't realize the heightfield stuff was for generating the terrain file *only*. I figured it was loaded in at runtime as well. That makes more sense now. I'll probably just use castRay for now since I think that will require the least painful changes to the code. :-)

I wonder though how many people coming from TGE will want to convert to Atlas for performance reasons but still be able to keep the heightmap quering capabilities they had with the legacy terrain. But maybe not that many people ever use that part of the API.

Anyway, thanks for the info!

#6 Justin,

I find it ironic that, after literally years of asking for support for things like overhangs, once a technology is delivered that'll do it, one of the first things people ask for is... support for the same paradigm that locked them out of overhangs or more complex shapes to begin with.

castRay is a fine solution if you're not going to have any overhangs or anything.

Precalculating based on the mesh topology would probably be better in the long run. :)

But, whatever gets your game going - that's the best choice.

#7 We then if atlas is a more robust terrain perhaps there should be a more robust way to query terrain geometry. A new Paradigm if you will(I really hate this word).

What I thinking about is a class like AtlasSurfaceQuery that allow a script to run various query's and enumuate over the results. For example there could be a RayQuery function that casts a ray and allows the script to enumerate over all triangles that interesect (which is better than the cast ray function since that returns only the first surface it hits).

Another example is a NormalRangeQuery that returns all surfaces that have normals within a certain range. Or you can query by hieght range or slope.

An idea. Maybe i will look into it.

#8 There's actually couple of classes in the existing collision library that do things like that. :)

But I agree, some robust querying interfaces would be pretty handy.

#9 This has me begging the question: Can you alter the terrain in game while it's running? I.E dig a tunnel or something? a moat?

#10 It's not impossible.