Jump to content
  • Advertisement

Archived

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

Structural

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.

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

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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Thanks for the link,

Edo

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Ok, now to try and answer some of your questions.

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 this post


Link to post
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]
My bad... I understand what you're getting at now. Still would increase your profile though and your rendering overhead
[/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 this post


Link to post
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!