Quote:Fog ?

I can't help much with most of your questions. For fog, however, if it's acceptable for the scene, you may want to use it.

You can do some quick culling of objects or terrain, avoiding drawing anything beyond "fogEnd" (whatever parameter you use to specify that).

In addition, with a little fog in the distance, you can "cover up" some low LOD terrain, if you decide to go that way.

Quote:Original post by Zaph-0
after much sweat and tears I finally got a completely unoptimized version of my clipmap terrain engine running. It is based on hoppe's clipmaps although I did some improvements/changes, especially with the texturing, splatting and multisampling.

Congrats [smile] I never made it as far as to actually implement it, so this is all from my limited understanding of the technique.

Quote:
-frustum culling
Is there a good way to do this ? I have no idea how to i.e. match a box against the frustum to see if it is visible...

IIRC, the improved GPU clipmap approach is to just render the entire terrain in one batch. If you're CPU bound, you probably shouldn't worry about frustum culling (at least not yet) and just set the GPU to work. This approach looks like a good AABB/Frustum, but Googling AABB frustum turns up a few more hits that may be useful.

Quote:
-vertex block optimization
I am using only single triangle lists and I think I can greatly reduce the number of vertice transformation if I change it to indexed strip lists. But I heard the gfx card buffers vertices anyway and my info is outdated too, so is this still advisable ?

Over here you can find some more information about vertex buffering/caching. That deals with indexed lists vs non-indexed strips though, so I'm not sure where multiple indexed strips would fit in. Intuitively I'd prefer a single list over multiple strips, since it would be more straightforward and uses only one draw call.

Quote:
-Render optimizing
I am currently occasionally doing a little work in the background with "StretchRect". Is this a big performance hit and should I use the renderpipeline for that as well (although I am certain "StretchRect" is HW-accelerated too).

It depends on what you're using it for. StretchRect is commonly used to read back data from a render target, which can make for a big performance hit. Essentially it stalls the pipeline, since everything has to be rendered before it can be read back, forcing the CPU and GPU to sync up. If you're using it on surfaces other than render targets, I wouldn't worry about it too much.

Got this wrong, see ET3D's reply below.

Quote:
-Distance
What should I put in the distance of the terrain ? Fog ? Or would it be better to just go all the way out with a really low LoD ?

I'd draw it as far out as useful and definitely use fog. In addition to masking the terrain cutoff, fog also goes a long way in faking aerial perspective, which will add a lot to the look of your scene. Make sure to use the same fog distances on the your objects too, otherwise it can look quite weird.

Quote:
-Skybox
I am currently not using a skybox, but is this still usable technology ? My days of directx programming are many years in the past and I think some things should have improved there. What is state of the art ? Maybe a sphere instead to make it smoother ?

I think skyboxes are still commonly used, probably because they work well as cubemaps for reflection in the bargain. For my simple projects I just used a 'skydome' though, which can be a bit easier to set up. Another (more complex & power hungry) approach which seems to be getting more and more popular is to do actual athmospheric scattering and also do clouds in realtime.

Quote:
-FPS
I am having a rather smaller terrain (1k x 1k) with a moderate level- and vertex-count at 800x800 while nothing else is going on with about 1700fps (8800gts,6ghz athlon xp). What should I aim for with the optimizations in place ?

That's very hard to say. I'd determine which level and vertex count works for your specific game/application and stick with that. 1700 fps sounds like a *very* good start, so just see how things work out when you start adding more and more elements. If the performance should ever drop below an acceptable level, you could always reduce the level and/or vertex count.

Hope this helps :)


[Edited by - remigius on July 17, 2008 8:27:15 AM]

Quote:Original post by remigius

Quote:
-vertex block optimization
I am using only single triangle lists and I think I can greatly reduce the number of vertice transformation if I change it to indexed strip lists. But I heard the gfx card buffers vertices anyway and my info is outdated too, so is this still advisable ?

Over here you can find some more information about vertex buffering/caching. That deals with indexed lists vs non-indexed strips though, so I'm not sure where multiple indexed strips would fit in. Intuitively I'd prefer a single list over multiple strips, since it would be more straightforward and uses only one draw call.

Don't use triangle strips, stick with indexed lists - they're just better. simple.

Shameless plug: An Example of Optimal Terrain Rendering (part two). I wrote up in my journal about utilizing the pre- and post-transform vertex caches using indexed lists and the results speak for themselves really - around 37 million triangles per second on an old GeForce 6800. I don't know how that compares to yours (crude multiples of your numbes would give 3.4 billion triangles per second, but I'm sceptical of that [lol])

Quote:Original post by remigius

Quote:
-Skybox
I am currently not using a skybox, but is this still usable technology ? My days of directx programming are many years in the past and I think some things should have improved there. What is state of the art ? Maybe a sphere instead to make it smoother ?

I think skyboxes are still commonly used, probably because they work well as cubemaps for reflection in the bargain. For my simple projects I just used a 'skydome' though, which can be a bit easier to set up. Another (more complex & power hungry) approach which seems to be getting more and more popular is to do actual athmospheric scattering and also do clouds in realtime.

I'd vote for atmospheric scattering as well.

I also saw a usage of SH/PRT for terrain that was jaw dropping when combined with day/night cycles for terrain. I was never a fan of SH/PRT due to its restrictions on static geometry, but for terrain thats not a problem unless you want deformations.

Quote:Original post by remigius

Quote:
-FPS
I am having a rather smaller terrain (1k x 1k) with a moderate level- and vertex-count at 800x800 while nothing else is going on with about 1700fps (8800gts,6ghz athlon xp). What should I aim for with the optimizations in place ?

That's very hard to say. I'd determine which level and vertex count works for your specific game/application and stick with that. 1700 fps sounds like a *very* good start, so just see how things work out when you start adding more and more elements. If the performance should ever drop below an acceptable level, you could always reduce the level and/or vertex count.

I'd hazard to say that your current performance metric is largely useless unfortunately. Frame rate is non-linear and over 1000fps starts to really degrade the quality of information.

Start measuring frame-time and then overload your system. Try and get it down to under a 100fps and then fire it through NVPerfHUD to try and analyse where your true bottlenecks are.


Oh, and my final recommendation - if you haven't already read Ysaneya's journal, do so now. An evening (or ten) reading through the archives of his planetary and terrain engines will be time well spent. There's some truly inspiring and clever tricks in there. I could only hope of being able to create something so impressive [grin]


hth
Jack

Quote:Original post by remigius

Quote:Original post by Zaph-0
-Render optimizing
I am currently occasionally doing a little work in the background with "StretchRect". Is this a big performance hit and should I use the renderpipeline for that as well (although I am certain "StretchRect" is HW-accelerated too).

It depends on what you're using it for. StretchRect is commonly used to read back data from a render target, which can make for a big performance hit. Essentially it stalls the pipeline, since everything has to be rendered before it can be read back, forcing the CPU and GPU to sync up. If you're using it on surfaces other than render targets, I wouldn't worry about it too much.

StretchRect by itself can't be used to copy from the GPU to the CPU (source and dest must be in the default pool -- see the docs) and therefore shouldn't cause a CPU to GPU sync.

Theoretically StretchRect should be able to work faster than rendering (since it bypasses the pipeline), but I don't know how it's slotted into the command stream, so it's possible that it's slower. I'd suggest testing the options.

Quote:Original post by ET3D
StretchRect by itself can't be used to copy from the GPU to the CPU (source and dest must be in the default pool -- see the docs) and therefore shouldn't cause a CPU to GPU sync.

Theoretically StretchRect should be able to work faster than rendering (since it bypasses the pipeline), but I don't know how it's slotted into the command stream, so it's possible that it's slower. I'd suggest testing the options.

Sorry, my bad. I was so into Tom's FAQ about CPU/GPU syncing I mis-extrapolated [smile]