Many of you who have been here for some time know I've been working on a quad-tree terrain renderer. My early version had serious problems with the quad-tree frustum culling code.
Well I've been doing research on procedural texture generation and other types of texturing and came across an article on gamedev that explains my earlier problem.
I was not 'looking' for the solution but rather looking for a way to generate textures inside of my pixel shaders and then output them to the screen. What this means, I think, is no more SetTexture() calls. Rather I 'tell' the video card what should be there. I'm still not exactly sure how it works or if you have to start out with a blank texture and then pass that into the shader? I just don't know, but I'll figure it out.
Anyways this quote:
Was the exact issue I was having. And the thread earlier about the Z buffer issue with very close Z near's is the EXACT solution I needed. It seems that when the z buffer near plane is too close, the precision in a float falters as you move off into the distance. Well if you understand 3D, you realize that most of what is culled is on the edges of the screen. The bottom edge is going to be the most precise while on the ground which is why it worked. The left and right edges will lose precision as you move up the screen and eventually it will be so far off that areas will 'fail' the bbox test when they should pass it.I'm progressing well on the terrain integration. I have fixed a problem in the frustum culling code, which caused some planets to disapear when they were close to the edge of the screen. This actually wasn't a bug, but a restriction that i was unaware of, to the standard frustum culling algorithm ( the bbox vs 6 planes one ) regarding on how close the znear plane can be, which i fixed by adjusting the distance to the znear plane.
The two screens above are again at sunset ( or close to ), to "hide" the lack of detail texture on the terrain ( yeah i'm cheating ). The terrain is still very simple, until i add all the details and noise back.
If you also recall from my earlier posts when you viewed the terrain from above looking down, all edges failed. This now makes sense. This was due to the fact that all the culling was happening in the distance since I was above the terrain looking down. So the precision really caused a lot of problems.
I'm going to re-code the entire quad-tree culling algo with my new Z distances, ambient/diffuse/specular/bump mapping shaders combined with a sky-scattering article I found on ATI's website from some time ago. The math is a bit heavy but I'll figure it out.
Also I found an easy way to do sphere texturing for planets. Instead of doing spherical mapping which distorts no matter what, I'll environment map the sphere using a distorted cube map. Then when I texture it I'll use a environment map shader that pulls from a cube map. It should work correctly w/o the distortion issues.
Here are some pictures of the problem I was having with my first version of the terrain system.
The first image clearly shows the problems.
The second image does not show the issue b/c it was taken when the camera was not moving. It was only occuring when the camera was moving or rotating. The second image also shows the power of the quad-tree. This is a 2048x2048 height map on a GeForce 3 card with 64MB RAM and NO shaders. My current system now runs at 350+ FPS with a brute-force 256x256 grid. I can't wait to see what the quad-tree does to it.