#### Archived

This topic is now archived and is closed to further replies.

# Geomipmapping: How to remove the gaps?

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

## Recommended Posts

I have a relatively simple heightmap at the moment, loaded from a raw file. I split it up in a quadtree and applied some geomipmapping in a bunch of vertex arrays. I''ve got my first geomipmapping going, but between the terrain patches the are gaps, because when the detail is lowered the vertices do not align properly anymore. How can I solve this? Should I lower the mipmapping steps (which is a multiplication of two at the moment) or are there other methods that solve this? Thank you!

##### Share on other sites

Hi,

I''m having that same problem at the moment, but what you really need to do (and what I''m going to do today) is keep track of pointers to the neighbouring quads.

This way you can see if a neighbour is already drawn, and, if so, in what resolution. If the lod of a neighbour is different from current quad, the you can stitch the quads together using the method described in the geomipmapping paper by Willem de Boer.

PS: I have a return question: how do you check if a sphere is entirely in the view frustum (not just part but the whole sphere).

Thanks

Edo

##### Share on other sites
quote:
Original post by edotorpedo

PS: I have a return question: how do you check if a sphere is entirely in the view frustum (not just part but the whole sphere).

Thanks

Edo

how do you check that a point is in a view frustrum?

I use 4 planes, on each side of the rendered scene, with normal vectors facing inwards. If a point is in a view frusrum

DotProduct( &point, &normal ) > DotProduct( &apointoftheplane, &normal )

if a sphere with radius R is entirely inside:
DotProduct( &spherecenter, &normal ) > ( DotProduct( &apointoftheplane, &normal ) + R )

##### Share on other sites
Thanks for the reference. I understand how I can pull this off now. Only thing that is still puzzling me is how the hell I can quickly figure out at which level a map is drawn map, since when I draw my quadtree I don''t know at what level the neighboring patch is drawn. Heh... I still have to figure out how I can find a neighboring patch.

I''m thinking.... perhaps I can set a level the one frame, and use it the next frame. No-one will notice that single frame that they are misaligned... no?

Anyway, to your frustum question. I found a good link on www.opengl.org you might be able to use:
http://www.markmorley.com/opengl/frustumculling.html

##### Share on other sites

You can keep track of the neighbouring patch when subdividing your quadtree, in about the same way used in the ROAM-algorithm (where you have 3 pointers to your neighbours in stead of 4). When rendering, you have pointers to your neighbours and they can tell you whether they already have been rendered (using a dirty-bit for example), and in which resolution.

The only problem I see is that you have to ''reset'' the dirty bit of all the leaves every frame, but with my 5-deep quadtree that shouldn''t take up to much time.

Edo

##### Share on other sites
Another option you could try would be to change your algorithm slightly. Instead of just calculating 1 LOD for each chunk, calculate 5 - one for each edge of the chunk, and one for the center.

Then, when you draw each chunk, you can use that information to match up the edges of adjacent chunks, without needing to store pointers to neighboring chunks or anything like that.

j

##### Share on other sites

I don''t get that... how can you know in which resolution a neighbouring chunk has been rendered, and in which LOD you need to render your edges (if you''re using a quadtree)? Could you explain a bit more?

Or are you suggesting that the edges always have the same LOD, and only the center lod changes? I already thougt of that option, but I rejected it because most of the time two neighbouring chunks have the same lod, and in that case quite a lot triangles are rendered unnecessary.

Laters,

Edo

##### Share on other sites
Edotorpedo:

Well, if you simply use your quadtree to cull chunks quickly, and all the actual geometry chunks are located at the bottom level of the quadtree and are uniform size, the 5 LOD thing works. If you have different geometry chunks at different levels in the quadtree, it won''t work at all.

quote:

I don''t get that... how can you know in which resolution a neighbouring chunk has been rendered, and in which LOD you need to render your edges (if you''re using a quadtree)? Could you explain a bit more?

If you have an LOD for each edge, you actually don''t need to know at what resolution a neighboring chunk was rendered. Because the neighboring chunk shares the same edge, the LOD that was calculated for it was identical along that edge, so when you render the current chunk taking into account the LOD of each of its edges, it will automatically line up with its neighboring chunks.

Hmmm...that sounded kind of confusing. The basic idea of what I''m trying to say is in this white paper here, on pages 10-12: http://developer.nvidia.com/docs/IO/1297/ATT/GDC01_evaluators.pdf

The advantage of this method is that chunks don''t need to know about their neighbors, so you don''t run into special cases at edges of maps, or if you are loading chunks procedurally and have a potentially infinite world.

The disadvantage would be that all 4 edges on a chunk could have different LODs, making it a bit tricky to match every edge up and still have fastand clean code.

j

##### Share on other sites
quote:
Original post by jdi
Another option you could try would be to change your algorithm slightly. Instead of just calculating 1 LOD for each chunk, calculate 5 - one for each edge of the chunk, and one for the center.

Then, when you draw each chunk, you can use that information to match up the edges of adjacent chunks, without needing to store pointers to neighboring chunks or anything like that.

j

That'd be quite a bad idea I think. It would increase your memory profile by a factor four. And what if there are two sides of that chunk that have a lower LOD. You only precompiled four chunks with one different edge.

[/edit]

I've rearranged my terrain class and I use a 2D array now that contains the leaves, this way I can refer to the neighbors, but I didn't get the algorithm to work yet.
Do you use an index array for drawing the terrain chunk? If so, what indices did you change? I keep getting triangular gaps.

[edited by - Structural on February 3, 2003 4:47:16 AM]

##### Share on other sites

Jdi: I get what you''re saying now... But I, as you said, only render the leaves of the quadtree, so I won''t be having any problems. I precompile the whole quadtree (using a roam-kind of split, keeping track of the neighbours), and I just draw the leaves. Pretty darn fast, even unoptimized.

Structural: if you''re rendering from left to right and from bottom to top, you only need to keep track of your left and bottom-neighbours. I used a 2D-array before, but it''s a lot more efficient (from a culling-point of view) to use a quadtree.

How can you keep getting gaps even if you know the LOD of your neighbours?

Edo

1. 1
Rutin
41
2. 2
3. 3
4. 4
5. 5

• 18
• 20
• 14
• 14
• 9
• ### Forum Statistics

• Total Topics
633368
• Total Posts
3011537
• ### Who's Online (See full list)

There are no registered users currently online

×