Jump to content
  • Advertisement
Sign in to follow this  
jamesss

Rendering Geomipmaps .

This topic is 4101 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

ok i have understood the theory behind the geomipmaps ...i began to coding last day and loop through all patches along the terrain sides=Allocated patches,Setted and Updated lods distance based from Camera Pos to the patch center.now the time for more advanced part..rendering patches...check around all patches neighbours for crack prevention...ok thats ok....main parts finished time for rendering..i will use triangle strips not Triangle fans..now what is the best and Fast way of creating vertex-index buffers for patches? i am thinking a static vertexbuffer for all patches then dynamic index buffer for each lod ....can you show me the fast way and some source code Using Directx 9 & C++ thanks for any reply.

Share this post


Link to post
Share on other sites
Advertisement
To be honest, you'd be better with an indexed triangle list, since it'll be far easier, and possibly more efficient (Cards these days are particularly optimised for dealing with indexed triangle lists).
I'd use a dynamic VB and a dynamic IB. If you have a static IB, it'll have to be huge.

The main thing to remember is that you want to use as few DrawIndexedPrimitive() calls as possible, certainly not rendering each patch and skirt seperately if you can help it.

Share this post


Link to post
Share on other sites
Steve is correct on the indexed triangle lists - there are a few arguments for triangle strips these days, but it's marginal at best. Lists are easier to manage than strips which is great - best of both worlds [grin]

Although that all goes to pot if you don't optimize for vertex-fetch and/or post-transform cache coherance. Both of which D3DX can do for you, but it's not really a run-time optimization.

I would suggest you give some serious thought to temporal factors with terrain LOD. I found this to be the second biggest win after heirarchical culling - yes, more so than LOD [oh]

Consider that your terrain is largely (or totally) static and that the camera moves very slowly (relative to the terrain) in most situations.

On a frame-to-frame basis the PVS and LOD won't really change much, this gives rise to two temporal optimizations:

1. Perform quick delta updates
2. Perform updates at a different timing granularity

The former can be difficult to implement but is probably the more elegant solution. The latter is trivial to implement and can work wonders with a bounded buffer and multi-threaded architecture (which we should all be doing these days [wink])...

With reference to my previous project, Greg Snook's "interlocking terrain tiles" (or similar) paper in GPG2 (iirc) was the best one I ever played with. I'm a little out of date, but one thing that was very neat about it was that it allowed for static LOD index buffers provided you didn't mind a bit of combinatorial explosion. You got the benefits of LOD with minimal CPU usage and no resource modification [cool]

hth
Jack

Share this post


Link to post
Share on other sites
Here's how I do it:

- using indexed triangle lists in clockwise order
- one VertexBuffer for the entire terrain
- one 16bit IndexBuffer for each terrain patch, but only for the highest lod (16bit will allow a patch size up to 129x129)

In the world's Update call I check which LODs changed during the last frame and repair cracks by locking the IB, degenerating triangles from the higher lod patches by offsetting some indices, and unlocking the IB again.
Since I only do this when it differs from the last frame performance is very well.

I managed to run six 1025x1025 simple singletextured terrains at the same time with about 20fps on a GF6800gt. Using just one 1025x1025 terrain is about 500fps.

Using frustum culling I typically end up with about 20-60 DIP calls with offsets to the large vertex buffer (depending on the patch size and view point)

regards

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!