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));
Vertex and Index generetion for Terrains (GeoMipMapping)
Author
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:
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
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 patchPatches 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.
Author
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?
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?
I just repeat the edge vertices. You can patch it up with 32 bit indices, but it's not worth doing.
Author
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]
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]
Would you mind sharing how you are calculating which LOD level to use seeing as how you mentioned what value for tau you're using?
Author
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.
Aside from the error calculations I'm using my very own implementation of the terrain, quadtree etc.
Author
Promit, would you might answering the last three questions? I'm finished with my terrain so far and I'm happy with the results :-)
thanks
thanks
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
