Sign in to follow this  

Vertex and Index generetion for Terrains (GeoMipMapping)

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everybody, right now I have terrain sample running where I copied much code from the Riemer's tutorials (link). I added some features like culling (quadtree) and a proper skybox to it. While the results are pretty nice the code doesn't work very well with large heightmaps due to a missing LOD system. Now I'd like to create my own terrain renderer using GeoMipMapping. I read the original Geomipmapping article by de Boer, but I have some questions: - when I create a heightmap of size 257x257 and patch sizes e.g. 17x17 - how does that fit? 257 / 17 is not an even number, so there would be some vertices at the edges of the map that would not fit entirely into a single patch - in which order should I read in my vertices? Right now I do something like this:
for(int x=0; x < PATCH_SIZE; x++)
   for(int z=0; z < PATCH_SIZE; z++)
      vertices.Add(new Vector3(x, height[x,z], z));

where vertices is a vector I just append for each vertex. This way the vertices will be added column-wise from the heightmap to the vector. Is this okay? - what's the best order to create the indices for a given vector of vertices? Could you give me the beginning of a sample index buffer or a sketch how to create the indices? I made some sketches and tried to put this into code, but the results displayed were wrong. Thanks so far for your help regards

Share this post


Link to post
Share on other sites
Quote:
- when I create a heightmap of size 257x257 and patch sizes e.g. 17x17 - how does that fit? 257 / 17 is not an even number, so there would be some vertices at the edges of the map that would not fit entirely into a single patch
Patches share edges. Think of each patch as 16 quads wide, not 17 vertices wide. The terrain is then 256 polygons wide, and you get an even division of 16 patches to a side. Oh, and 17 square is a really small patch size. I'd suggest starting at 65 square, and make 17 square the minimum size for each patch.
Quote:
This way the vertices will be added column-wise from the heightmap to the vector. Is this okay?
It doesn't matter. Just be aware that there are consistency issues that will appear, and you'll need to make sure the order is the same every time.
Quote:
- what's the best order to create the indices for a given vector of vertices?
The best way? The best way is a triangle list or strip (doesn't matter) with crack patching and cache priming in strips to achieve optimal post-VS cache hit rate. That's complicated though, so you may as well start off with a regular old list or strip.
Quote:
Could you give me the beginning of a sample index buffer or a sketch how to create the indices? I made some sketches and tried to put this into code, but the results displayed were wrong.
I suggest you figure this one out on your own. A list is going to be easier to build than strips.

Share this post


Link to post
Share on other sites
Okay thanks, I have made a small progress so far, here it is:



I read in a 257x257 and defined the patch size to be 17x17 (33x33 and 65x65 also work fine).
This way I get 256 (64, 16) patches. The triangle list is created in clockwise direction so they can get culled counterclockwise.

One problem that I have is: how can I connect these patches? One solution would be to read in the vertices at the edges twice, but I'd like to solve it via the index buffer.
In the index loop however I can't just increase the counter by one, because the vertices for the adjacent patch are stored at a different position in the vertex buffer, since they get created recursively.
Right now I'm only using one large VB and IB and in the draw call I just set the VB and IB offset for the particular patch using DrawIndexedPrimitives().

What's the best technique here?

Maybe creating a temoprary table with the VB offsets of each patch, so I can easily get the right and bottom patch for a patch that is not at the edge of the terrain?

Share this post


Link to post
Share on other sites
Thanks. I'm doing good progress so far.
I have a geomipmapped terrain running at 1025x1025 with ~300 to 900fps at 800x600 (depends on the culling).
I'm also using shared edges and 16 bit indices which seems to work fine so far.
I yet have to remove the cracks, but that shouldn't be too hard to implement I guess.

As you seem to be the most competent person regarding geomipmaps here (I read the other threads about your implementation), I still have a few questions:

- How many triangles per frame are okay? Right now I'm at ~15k (tau=8) and up to 55k for tau=3. Also, I'm seeing pretty large popups using tau=5, in the original paper de Boer even used tau=8, what are your experiences?

- do you limit the maximum LoD difference between two adjacent patches to be 1? I guess that the most elegant solution to remove cracks

- (not gmm related): what scale would be okay if players should be able to run around the world? A 1025x1025 map should be about 2-4 kilometers wide.

regards

[Edited by - FoxHunter2 on August 18, 2007 6:41:48 AM]

Share this post


Link to post
Share on other sites
Promit posted some details about the calculations 3 years ago in this thread. They are basically just an implementation of the formulas de Boer mentions in his original papers.

Aside from the error calculations I'm using my very own implementation of the terrain, quadtree etc.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this