# Allow For Holes In Terrain

This topic is 2894 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm trying to come up with a good method for rendering pretty large terrains and I think that chunked LOD seems like the way to go. (If I understand correctly, that's where you have quadtree of terrain LODs, right?). The only thing I can't figure out is how to allow for holes in the terrain - places where triangles aren't drawn to allow for buildings that extend underground. If I simply use a different IBO for each terrain chunk/LOD, then this is easy (I can just skip indices). However, since I need to stitch the terrain squares together, I would need a total of 9 IBOs per terrain chunk, which doesn't sound so nice. Without holes, I could just reuse the 9 IBOs and total they wouldn't even take up 1MB. The only solution I can think of is to dynamically generate IBOs for terrain squares, but using a fixed set of 9 seems a lot nicer so I'd prefer to try to think of an alternative solution before trying that.

##### Share on other sites

I'm trying to come up with a good method for rendering pretty large terrains and I think that chunked LOD seems like the way to go. (If I understand correctly, that's where you have quadtree of terrain LODs, right?). The only thing I can't figure out is how to allow for holes in the terrain - places where triangles aren't drawn to allow for buildings that extend underground. If I simply use a different IBO for each terrain chunk/LOD, then this is easy (I can just skip indices). However, since I need to stitch the terrain squares together, I would need a total of 9 IBOs per terrain chunk, which doesn't sound so nice. Without holes, I could just reuse the 9 IBOs and total they wouldn't even take up 1MB. The only solution I can think of is to dynamically generate IBOs for terrain squares, but using a fixed set of 9 seems a lot nicer so I'd prefer to try to think of an alternative solution before trying that.

Have the shader kill the pixels where the holes are supposed to be, except for the highest LOD?

##### Share on other sites
I was thinking about that, but that seems like it could potentially have bad performance penalties. I've heard that discard() or equivalent functions in the pixel shader disables early z reject, and since terrain takes up a significant portion of the screen, it seems like that would be pretty bad.

##### Share on other sites
You'd only have to use clip/discard on the chunks that actually have holes in them... Depending on the scene, this may only be a few chunks.... or it may be all of them...

Early-Z changes from one GPU to the next... but a common implementation is a 2-update system (trivial-accept and trivial-reject) part of it is updated by the rasterization stage, and part by the ROP (pixel output) stage. When alpha-test (discard) is enabled, the rasterization part of the update process has to be killed, increasing subsequent false-negatives.

##### Share on other sites

I was thinking about that, but that seems like it could potentially have bad performance penalties. I've heard that discard() or equivalent functions in the pixel shader disables early z reject, and since terrain takes up a significant portion of the screen, it seems like that would be pretty bad.

Well the highest LOD by definition should be in your face and consuming most of the fillrate, I would imagine the penalty for having a clip on the distant copy of the terrain could be written off as the cost of doing business and worried about less.

##### Share on other sites
Hmm, alright, I will go ahead and give discard a try (and only use the shader containing discard on high LOD terrain with holes), since I guess I can't know the performance until I benchmark. If anyone does happen to have alternative ideas though I'd still be interested in hearing them.

EDIT: I do have a question regarding alpha testing/discard() though. If I use discard, does it generally only affect the performance of the batch that uses it or will all batches drawn after also be affected?

##### Share on other sites
Maybe this suggestion is inept and lacking in logical endowment. Well it all depends. If you were using height maps to create your terrains, then a simple thing such as 'deletion' of non-needed terrain bits could be done;
but it would require your terrain reader to be alpha-compatible, that is be able to detect transparency.

This is just an idea that `materialized in this response. Perhaps, since height map terrains' varying heights ( whether flat or non-flat ) are based on intensity of differentiations in height map color data, then probably, in the same way you edit height maps to create heights based on intensity, holes may be created where no intensity exists. That is place an area of transparency.

I'm a beginner, so I don't know if this is a valid idea.

##### Share on other sites
I found a terrain render I wrote a few days ago.

So here is terrain, and respective height map used:

terrain:

height map:

Now, by applying a black hole in height map, terrain has a negative growth at hole occurence:
terrain:

"Hole'd" heghtmap:

yh..

##### Share on other sites
Thanks for the suggestion, but I think we're actually talking about different things. What I mean is what you see in this image. This is to allow for buildings to extend under the terrain, like this tunnel.

##### Share on other sites
discard would be your best bet. If you have separate index buffers for each chunk then you cannot instance your draw calls any more. So, the cost is probably the same, but discard is a much easier solution than different index buffers.

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633702
• Total Posts
3013450
×