geomipmaps

My goodness Steg, I think you''re making this harder than it is. First off, do you have a quadtree? If not, then you had better get one, cause that''s the first step in geomipmapped LOD. A quadtree will make this whole ordeal much easier. If you''ve got a quadtree already, all you do is calculate different LODs for leaf of the quadtree (patch). This can be done by using different index buffers or by different index and vertex buffers. The former takes up less memory, but the latter (I''ve found (I use OGL)) can be faster. So anyway, when it comes time to render, you check you quadtree through your frustum culler, then render each leaf thats in the frustum. When you go to render each leaf, you find the distance between the camera and the center of each node visible, and based on that distance, you select a LOD. Hope that helps.

Thanks GreatOne (like the name ;-) )

But I don''t have a quad tree yet, Not doing any occlussion culling at the moment. I''ve got Trents book and am starting from how he works through the book, thus, brute force then geomipmaps and then later quad trees.

I''m thinking to render a patch of say LOD0 which is 16x16 quads I would need something like :

int offset = 0;
for(int i=0; i<16;i++) {
SetIndices(LOD0);
DrawIndexedPrimitive(D3DPT_TRIANGLELIST,0,0,2,offset*6,16*2);
offset+=MapWidth;
}

This would draw a patch with highest detail of size 16x16, does this make sense ?

Thanks,
Steve

I suppose that makes sense, but as I said, I'm an OGL guy, I've never really used DirectX. Also, the code snippet you posted will render a row of triangles, then stop, then move up and back, and render another row, the similiar sort of motion a type writer does when it finished typing a line and moves up. To be more efficient, and to cut down on the number of API calls, you should render the patch all at once with just one call to DrawIndexedPrimitive.

Instead of rendering from left to right, move up a row, left to right, move up a row, etc, you should render left to right, move a up a row, right to left, move up a row, left to right, etc. This way, you can render the whole patch with one call, understand? If you post the code that you use to generate indices, I can help you change it so that rendering the whole patch in one call is possible.

However, you really need a quadtree to get the most out of really any terrain LOD scheme involving patches. Quadtrees are incredibly easy to code (even without tutorials), if you just think about it for a bit. I hope some of that makes sense.

[edited by - GreatOne on May 24, 2003 3:26:47 PM]

Thanks GreatOne,

I thought it would be best to render a patch in one DrawIndexedPrimitive call, but like I said earlier, doing it in one call I wouldn't know how to 'position' patches next to each other ?

Here is my code for producing the indices :




Where LOD is the level of detail, i.e.1,2,4,8 ....
This generates indices for the whole terrain as one big patch.
My tri's are set out like the following :

0 1 2
|\|\|
3 4 5
|\|\|
6 7 8

thus indices :
0,4,3,1,4,0,1,5,4,2,5,1
3,7,6,4,7,3,4,8,7,5,8,4


Any help is much appreciated.

Kind regards,
Steve


[edited by - steg on May 25, 2003 5:11:22 AM]

quote:

---

Original post by steg
doing it in one call I wouldn''t know how to ''position'' patches next to each other ?

---

your patches consist of vertices, your vertices have a position and the position of vertices in patches that are next to each other already are next to each other, so you shouldnt have to do anything but drawing them.

if your general problem is that you dont want a call for each patch, then first: dont think about it, at least not yet.
second: if you feel that patches of 8x8 result in ridiculously few triangles per call (128 max) then maybe you should get used to the idea that 16x16 or 32x32 are better sizes ,-)

third: if you really want to go so far, then you would have to copy all indices from the patches you want to draw to a bigger array and draw that. or have a look at the multi-draw-arrays extension.

I want to be able to render a patch with one DrawIndexedPrimitive call, thus rendering more than one row of strips with one call ?

Kind regards,
Steve

then either use multi draw whatever extension, connect all strips to one or just forget strips as the obviously cause more work than its worth. use a simple triangle list, sort them in a cache friendly order and the result is as fast or faster (and definitely faster than multiple calls to draw)

Thanks Trienco,

Ihave got it working now using Tri-lists with one index buffer and one vertex buffer.