Ok some of you are going to think I'm crazy on this one and some of you might consider me a genius.
If any of you have done raycasting you know that it is extremely fast when you split the rays into their component parts and then move through the map based on tangents one component at a time.
The inherent problem with terrains is this: too many polies and while this can be solved using quadtrees and other algos I am going to present another possible solution.
My idea is as follows. Create and or pre-compute a large terrain from a heightmap. Sectorize the map by assigning numbers to represent the sectors. Store each mesh in an array that represents each sector. For instance, sector 1 would represent ID3DXMesh MapMeshes[1] and so on.
Create a small tile map much like wolfenstein or the old 2D tile maps. Then to draw the scene, simply raycast through the map based on tangents. When you hit a number, render that mesh to the screen if its visible - this can be tested quite easily using a z buffer. So let's say each mesh was 16x16 cells. You could represent a very large terrain with a minimal 2D map. The x,y and z positions of the meshes are easy to compute. Simply compute each mesh in local space - that is everything is centered around 0,0,0. Then translate the matrix by x*rayworldx,y*rayworldy,z*rayworldz. This would put the mesh in place where it needs to be. Of course more calculation would be needed to compensate for cell size but you get the idea. So in a sense we are still raycasting, but we are rendering meshes that represent the entire mesh.
This technique would save on the number of actual primitives being drawn at one time because each mesh would have a set number of primitives. As well, you could render this extremely fast because only the 'sections' that lie within your view will be rendered. These sections are computed by the ray caster. If you render this front to back and store the tops of each column -that is the screen.y component of each vertex then this would be a fast render. If the y component of the vertex being rendered is above and beyond (on z) the y component of the one previously rendered there - draw it, else skip it. The z buffer is handled by D3D but the trick would be up to you - think about it. You won't see any terrain vertexes that are not higher on the screen than the highest vertex for that column of pixels. This presents more problems because not all vertexes will lie on columns - it would be possible that two vertexes would be connected and thus you would have to find the point at which that line intersects the desired column, but it could be done.
With this method I think it would be possible to render extremely large distances with little trouble and the framerate would be very good.
So what do you guys think?
Originally Posted by Silvercord
