Geoclipmapping paper

Hi Ivo. It's been a while since I read the paper by Hoppe but I remember Nick Brettell had a more detailed paper where he talks about the implementation. Maybe this can help? http://www.cosc.canterbury.ac.nz/research/reports/HonsReps/2005/hons_0502.pdf

Nicolai

as a relatd question, doesds anyon understand how collision works with this kind of terrain? I have implemented a somewhat similar terrain system using vertex textures and so forth, but it seems not possible to do accurate collision, particulary where normals are concerned.

Quote:

Original post by ndhb Hi Ivo. It's been a while since I read the paper by Hoppe but I remember Nick Brettell had a more detailed paper where he talks about the implementation. Maybe this can help? http://www.cosc.canterbury.ac.nz/research/reports/HonsReps/2005/hons_0502.pdf Nicolai de Haan Brøgger

Thank you for your answer but I already know that paper. In fact quoting Nick's paper "A clipmap Ci of level i has twice the width and twice the height of the clipmap Ci−1, but the same number of vertices." he states exactly that each clipmap has the same number of vertices in each level.

Even on the original clipmap paper (Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids) we can see the same on figure 3 and 4, the finer level is slightly offset to the right, which means that I has a even number of vertices

Hi,

With grids 2^k-1, you can't center them on their finer level. Each grid is always shifted 2.0f on left/right and top/bottom (4 cases). That's why you can see those L-Shapes in the screens.





PS : Each level as the same number of vertices, you can use the same vertex buffer for each level.

Quote:

Original post by filousnt Hi, With grids 2^k-1, you can't center them on their finer level. Each grid is always shifted 2.0f on left/right and top/bottom (4 cases). That's why you can see those L-Shapes in the screens. PS : Each level as the same number of vertices, you can use the same vertex buffer for each level.

Tnks a lot for your answer, now i understand :-). I've noticed also that with close observation of figure 2-4 it's possible to reach that conclusion.

PS: I've tried to bump your rating but it says that i can only rate one user at a time.

I dont understand how is accuracy presevered in geoclipmapping.

What if distant terrain is very rough and spiky? Then the triangles in the outtermost ring in the geoclipmap, though small in screen space but HUGE in world space, would poorly approximate the actual rough terrain.

I don't suppose the height of distance vertices in the outtermost ring is the average of its neighbor height.

Thanks

it doesnt - the outer level of a geometry clipmap would use, say, every 16th vertex of the heightmap, so it is very possible that the peaks of mountains, for example, would be lost until you got closer.

There's one other thing that i do not understand. I have read the two papers, Geometry Clipmaps - Terrain Rendering Using Nested Regular Grids and Terrain Rendering Using GPU-Based Geometry Clipmaps and the first one divides each clipmap in 4 blocks (Figure 3). But in the second paper (Figure 2-5) they divide the terrain in a lot of blocks for the same purpose. What’s the reason for this?

Tnks in advance.

Quote:

Original post by Ivo Leitao There's one other thing that i do not understand. I have read the two papers, Geometry Clipmaps - Terrain Rendering Using Nested Regular Grids and Terrain Rendering Using GPU-Based Geometry Clipmaps and the first one divides each clipmap in 4 blocks (Figure 3). But in the second paper (Figure 2-5) they divide the terrain in a lot of blocks for the same purpose. What’s the reason for this? Tnks in advance.

If you reread section 2.3.2 of the GPU implementation paper it explains the reasoning pretty well. It significantly reduces the memory cost. You only need a few static vertex and index buffers for the various pieces, and they are usable for each level. This is what gives the GPU implementation its constant vertex and index buffer costs mentioned in Table 2-1. And since they are static buffers, they are much faster than dynamic buffers.

Quote:

Original post by Kalidor Quote: Original post by Ivo Leitao There's one other thing that i do not understand. I have read the two papers, Geometry Clipmaps - Terrain Rendering Using Nested Regular Grids and Terrain Rendering Using GPU-Based Geometry Clipmaps and the first one divides each clipmap in 4 blocks (Figure 3). But in the second paper (Figure 2-5) they divide the terrain in a lot of blocks for the same purpose. What’s the reason for this? Tnks in advance. If you reread section 2.3.2 of the GPU implementation paper it explains the reasoning pretty well. It significantly reduces the memory cost. You only need a few static vertex and index buffers for the various pieces, and they are usable for each level. This is what gives the GPU implementation its constant vertex and index buffer costs mentioned in Table 2-1. And since they are static buffers, they are much faster than dynamic buffers.

Ha ok now I see it (sorry I’ve missed that detail). So if my objective was to implement the first version of the algorithm the approach described in the GPU paper could be used to divide the blocks right? I'm not completely sure if that brings any advantage or if it makes sense. More specifically I’m thinking in the approach that i have seen in Greg Snook Real Time Terrain Engines in C++ Book. In that book he uses 2 vertex streams one for heights and the other for the vertexes...
Sorry if that doesn’t make a sense in this context but it's just a thought that popped in my mind suddenly ;-)

Tnks for your answer

[Edited by - Ivo Leitao on January 17, 2007 12:57:46 PM]

Quote:

Original post by Ivo Leitao Ha ok now I see it (sorry I’ve missed that detail). So if my objective was to implement the first version of the algorithm the approach described in the GPU paper could be used to divide the blocks right? I'm not completely sure if that brings any advantage or if it makes sense. More specifically I’m thinking in the approach that Greg Snook used in the Real Time Terrain Engines in C++ Book. In that book he uses 2 streams one for heights and the other for the vertexes... Sorry if that doesn’t make a sense in this context but it's just a thought that popped in my mind suddenly ;-) Tnks for your answer

Don't worry about it, we're here to help. [smile]

It's been a while since I've really dug deep into clipmaps (and I still haven't gotten around to implementing either version) but using everything else from the original implementation I suppose it would be possible to split the levels up using that approach, it would largely defeat the purpose however. Since the vertex buffers would need to be updated with the height information, they would need to be unique and they wouldn't be usable in more than one level. It would also be much more than the 4 buffers (and draw calls) per level in the original version, so it will be much less efficient.

I'm not familiar with that book, but if you can get the height information from a different vertex stream (similar to using a vertex texture) in the vertex shader than I think splitting the levels up like that would be beneficial. I imagine this is similar to using render-to-vertex-buffer instead of vertex textures for the GPU clipmap implementation on a card that doesn't support vertex textures.

I haven't given it much thought but it should also be possible to split the levels up differently from how it's done in the GPU clipmap paper. Using the example from Figure 2-5, I can see it being split into 4 rectangular buffers and the interior trim (getting rid of the fix-up). Or perhaps 4 rectangular buffers with 2 of them being slightly "fatter" to get rid of the interior trim as well, although in this case there will need to be two sets of such buffers and each adjacent level will need to use the other set. Again, I haven't given it much thought, and they've probably tested several ways of splitting the levels and decided on the way presented in the paper based on that. Just something to keep in mind.

Ring split also enable view frustum culling.

Quote:

Original post by filousnt Ring split also enable view frustum culling.

That's right, the smaller blocks in the GPU partitioning scheme allows "tighter" frustum culling than partitioning in larger blocks (such as the partitioning used in the original paper's implementation). This may have been another reason why they chose that scheme over the original.

Quote:

Original post by Kalidor Quote: Original post by Ivo Leitao Ha ok now I see it (sorry I’ve missed that detail). So if my objective was to implement the first version of the algorithm the approach described in the GPU paper could be used to divide the blocks right? I'm not completely sure if that brings any advantage or if it makes sense. More specifically I’m thinking in the approach that Greg Snook used in the Real Time Terrain Engines in C++ Book. In that book he uses 2 streams one for heights and the other for the vertexes... Sorry if that doesn’t make a sense in this context but it's just a thought that popped in my mind suddenly ;-) Tnks for your answer Don't worry about it, we're here to help. [smile] It's been a while since I've really dug deep into clipmaps (and I still haven't gotten around to implementing either version) but using everything else from the original implementation I suppose it would be possible to split the levels up using that approach, it would largely defeat the purpose however. Since the vertex buffers would need to be updated with the height information, they would need to be unique and they wouldn't be usable in more than one level. It would also be much more than the 4 buffers (and draw calls) per level in the original version, so it will be much less efficient. I'm not familiar with that book, but if you can get the height information from a different vertex stream (similar to using a vertex texture) in the vertex shader than I think splitting the levels up like that would be beneficial. I imagine this is similar to using render-to-vertex-buffer instead of vertex textures for the GPU clipmap implementation on a card that doesn't support vertex textures. I haven't given it much thought but it should also be possible to split the levels up differently from how it's done in the GPU clipmap paper. Using the example from Figure 2-5, I can see it being split into 4 rectangular buffers and the interior trim (getting rid of the fix-up). Or perhaps 4 rectangular buffers with 2 of them being slightly "fatter" to get rid of the interior trim as well, although in this case there will need to be two sets of such buffers and each adjacent level will need to use the other set. Again, I haven't given it much thought, and they've probably tested several ways of splitting the levels and decided on the way presented in the paper based on that. Just something to keep in mind.

Ok tnks a lot for all the input in this thread. Now it's time to start coding ;-)