Nice to know. No missing pixels?

no problem.

but then again, the way i'm doing things, i don't think there could be.

for daytime scenes, i:
1. clear the screen to sky color (for the moment).
2. clear the zbuffer.
3. set lights based on time of day.
4. set camera
6. beginscene
7. draw sun: ztest off. zwrite off. lighting off. alphablend on. one drawprimitive call, one static quad mesh (2 tris), one static texture. then turn lighting, zwrite,and ztest back on, and alphablend off again.
8. draw clouds: set material based on time of day. set clip planes to 400 and 2000. recalc frustum clipping planes. add 1000 clouds to the "drawlist" - a list of textures in the scene, and the meshes that use them. draw the meshes in the drawlist: for each texture, set texture. for each mesh that uses that texture, set world transform. set mesh, material, cull, alphatest, and clamp on the fly as needed using a state manager. then call drawprimitive. reset clip planes to 0.1 and 1000. recalc frustum culling planes.
9. clear zbuf.
10. draw everything else
11. present

so i clear the screen and the zbuffer, then alpha blend in the sun with zbuffer test and write turned off. then i turn on the zbuffer again and draw the clouds with the distant clip planes. then i clear the zbuffer and draw everything else with the closer clip planes.

i may not need to clear the zbuffer between drawing clouds and everything else. the near plane for clouds is 400. visual range (for non LOD background stuff) is only 300. so i never really draw anything much past 300. and when i do clear it, the zbuffer just has ~500 clouds starting at range 400, which won't change anything if i then draw a bunch of stuff at 300 or closer.

By the way how many times can you do this trick? I mean, does it work for really large distances or do you eventually lose all precision for very high near and far values (say you were rendering very distant objects). Or do you use a different method for this?

Zset_clip_planes() calls directx's set projection matrix routine. so that's the overhead hit you take every time you change the clip planes.

i've been playing with very large clip planes in my airship flight sim. visual range there for the largest object (a size XL zep) is almost 200 miles. so its sort of like doing a space flight sim, a few of which i've done in my day. in the airship flight sim, the scale is 1 d3d unit = 1 foot. the clip planes are set to 10 and 1000000 (1 million). the "world map" is 9030 miles across (from the Ural Mountains in Russia to about Chicago in the United States). needless to say, d3d's coordinate system can't handle that size of a world at that scale. so the world is divided up into 10000x10000 sectors, each with its own local d3d coordinate system.

i see no reason why the far clip plane can't be set out to the limits of the d3d coordinate system's ability to draw things. and the call to set projection matrix is the only cost. so the thing to do would be draw the scene in sections from most distant to closest. for each section, you'd set the planes to just enclose that section. this would give you maximum zbuf accuracy for the upcoming drawcall, to avoid zfighting. then you set the planes to just enclose the next section closer, and draw that. then you set the planes for up close and draw the rest. then you might want to set them very close to draw some high rez mesh up close, such as a weapon in hand.

sections might be split into sky (background) stuff, distant lod (3d skybox) stuff, normal visual range stuff, and closeup stuff. perhaps even 2 distant lod or normal range sections, depending on the total visual range and scene complexity. by using this "divide and conquer" strategy combined with good old painter's algo of farthest to nearest, one should be able to render scenes of arbitrary visual range with no zfighting.

actually, set projection matrix is not the only cost. you have to clear the zbuffer for each section draw, for max zbuffer accuracy. but you may have sufficent zbuffer accuracy to span 2 or more adjacent sections between zbuffer clears.

come to think of it, you'd have to clear the zbuf every time you reset planes, as the zbuf values are a function of the clip planes since its non-linear. at least i suspect so.

so zbuf data would only be valid for a given set of clip planes. you could for example draw some stuff, then turn off zbuf , change clip planes, draw more stuff, then change back to the old clip planes, and turn zbuf back on, and your zbuf data would still be valid for further drawing. but zbuf use with different clip planes would require a zbuf clear, i'm pretty sure. can anyone out there confirm this?