Allow For Holes In Terrain

Started by
8 comments, last by smasherprog 13 years, 3 months ago
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.

Does anyone have any ideas on a good way of going about this?
Advertisement

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.

Does anyone have any ideas on a good way of going about this?


Have the shader kill the pixels where the holes are supposed to be, except for the highest LOD?
http://www.gearboxsoftware.com/
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.
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.

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.
http://www.gearboxsoftware.com/
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?
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.
http://img440.images...gamedevsig.jpg/

I'm not the typical programmer.
I found a terrain render I wrote a few days ago.

So here is terrain, and respective height map used:

terrain:
screenshotwhole.png
Uploaded with ImageShack.us

height map:
landheightmapwhole.png
Uploaded with ImageShack.us

Now, by applying a black hole in height map, terrain has a negative growth at hole occurence:
terrain:
screenshothole.png
Uploaded with ImageShack.us

"Hole'd" heghtmap:
landheightmaphole.png
Uploaded with ImageShack.us

yh..
http://img440.images...gamedevsig.jpg/

I'm not the typical programmer.
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.
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.
Wisdom is knowing when to shut up, so try it.
--Game Development http://nolimitsdesigns.com: Reliable UDP library, Threading library, Math Library, UI Library. Take a look, its all free.

This topic is closed to new replies.

Advertisement