Using one VB/IB per 256x256 is too big; that''s really inefficient (and Direct3D hardware doesn''t accelerate indices greater than 65535 at the most, anyway). Try using 32x32 patches, or 64x64.
If you want several levels of detail, then look into something known as "progressive meshes" or "VIPM" (which stands for "view independent progressive mesh").
However, you typically won''t need more than a few LOD buffers; if you use 64x64 patches and have 4 LODs, then the size of each LOD (assuming simple 4x reduction) is: 64x64, 32x32, 16x16, 8x8. What many terrain systems do is gang LODs together, so you always deal with, say, 32x32 buffers, but they cover different amounts of area. If you draw a regular 32x32 triangle field, then you only need to bake an IB once (you only need one IB per tile resolution in general). However, you need a number of IBs, of course.
There is also the issue of seaming up between different LODs; this can be done using dynamically generated VBs, by extending the existing VBs, or by creating separate IB/VB pairs.
In general, though, "switching VBs" is not as expensive these days as it was before. And if you use OpenGL, the moral equivalent (switching VBOs, or re-specifying VertexPointer()) is fairly cheap, because OpenGL runs almost entirely in user space. So I suggest getting used to using lots of buffers, and getting it to work right, rather than worrying about the VB cost.
Is there a way to use geomipmng without creating a vb and ib for each level?
you need exactly ONE vb for your terrain and for each level ONE vb per variant (cutout pieces for linkers to different lods). with 16x16 patches thats 1 ib for lowest lod, 15 for 2x2, 16 for 4x4, etc. resulting in (except 1x1 and 2x2) 16 ibs per level (+4 linkers per level that means 20ibs for every lod). the size of your terrain is changing nothing but the size of the single vb and if you start to use different ibs for different patches you should rethink your approach, because the only difference between patches is their offset into the vb.
also: texture coords per patch will always be the same, so store them once and not for every vertex. if you use vertex programs you could probably save a lot of memory by calculating x/z coords and texture coords on the fly.
also: texture coords per patch will always be the same, so store them once and not for every vertex. if you use vertex programs you could probably save a lot of memory by calculating x/z coords and texture coords on the fly.
I would recomend using 1 VB per patch of 17*17, then generate ur IBs on the fly and discard them each frame. Use triagnle fans to calculate ur IBs, and u can come up with something that is considerably fast. That in combination with good culling and visibility determination should be fast enough for pleasing resutls
In the terrain engine for Black and White 2 I first created just a ''global'' set of index buffers for each LOD and each patch having a vertex buffer. The vertex buffers are generated and cached and kicked out of memory after a while that this patch hasn''t been visible for a while. We also had a set of precalced stitched borders of the patches, to solve the LOD crack problem. Then we wanted to add support for arbitrary edge splits (to get nicer geometry output) as well as optimizations for each splat layer, to save fillrate, since we sometimes have up to 12 passes of the terrain. When you do this, you can no longer share the index buffers anymore between the patches, since it would have different edge splits. Besides this, the terrain is completely dynamic in both texturing and geometry. Changing geometry or texturing info changes the tesselation of the terrain. Having around 256 patches of 64x64 in one level, with up to say 8 layers, each having their own index buffers and each having 4 different detail levels, you end up with lots of megabytes of index buffer data. So I built a system that creates the buffers on the fly and cache them. We have lots of caches everywhere, without these things would really run bad 
I set a maximum cache size in terms of memory usage. With some clever tricks we noticed virtually no slowdowns as before when we had just global index buffers. Actually we got a bit of a speedup, thanks to the fillrate optimizations
We generate the VB''s at the highest LOD and just change the index data. The VB sizes are 64x64 (well, 65x65 actually) if I remember correctly. This was timed the fastest on current latest hardware.
I set a maximum cache size in terms of memory usage. With some clever tricks we noticed virtually no slowdowns as before when we had just global index buffers. Actually we got a bit of a speedup, thanks to the fillrate optimizations
We generate the VB''s at the highest LOD and just change the index data. The VB sizes are 64x64 (well, 65x65 actually) if I remember correctly. This was timed the fastest on current latest hardware.
quote:Original post by Anonymous Poster
In the terrain engine for Black and White 2 I first created just a ''global'' set of index buffers for each LOD and each patch having a vertex buffer....
Do you join patches at distance into bigger ones? Or you are not DIP limited?
And do you burn texture splatting into single texture per patch at distance as a LOD option?
quote:Original post by Zemedelecquote:Original post by Anonymous Poster
Do you join patches at distance into bigger ones? Or you are not DIP limited?
And do you burn texture splatting into single texture per patch at distance as a LOD option?
No, no joining. That would also make the buffers too big, and decrease speed. If we would have decreased VB''s too on LOD, this might have been good though.
Yes, texture splatting is burned into a single texture per patch in the distance. So is grass and some other geometry, depending on the LOD. When you get close up you also have normalmaps and highres splats. The lowend cards will probably go for completely pre-baking the splat layers.
quote:Original post by Anonymous Poster
No, no joining. That would also make the buffers too big, and decrease speed. If we would have decreased VB''s too on LOD, this might have been good though.
Yes, texture splatting is burned into a single texture per patch in the distance. So is grass and some other geometry, depending on the LOD. When you get close up you also have normalmaps and highres splats. The lowend cards will probably go for completely pre-baking the splat layers.
I see.
But if you do not join patches, how much of them gets visible at one time - I saw a great viewing distances at some of yours screenshots. Don''t you get DIP limited?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
