[Heh, this turned out longer than I expected when I started writing...] Curtis L. Olson wrote: > I would recommend doing a net search for CLOD (continuous level of > detail) and ROAM (I forget what that stands for.) There are a lot of > spiffy demos out there. However, there are some non-trivial issues in > taking a chunk of demo code and making it work for the entire world.
Amen, brother. :) I got as far as making a whole-world ROAMish* tesselator work. It works on mipmap-style tiles, with many "generations". The largest generation was 1024m per sample with my test data, down to 8m for the smallest. Tiles would be paged in and out based on screen-space priority with a threaded loader. This part worked really well, actually. * For the LOD geeks: Split only, with a modified screen error metric and square/diamond-based (instead of per-triangle) error terms. The spherical world geometry is handled via a trapezoidal deformation of the square grids and a distance-dependent "push-down" of elevation data, with an internal transition to a separate data set near the poles. But the texturing is a huge mess. The first problem is that you want to generate your textures automatically out of "archetypes" to avoid having to store the whole world at 1m per pixel. I was using a terrain type gridding, with 1 terrain type for each 256mx256m area. But of course you don't just draw them next to each other, because that's ugly. So I came up with a set of noise-based blending textures (four of them, which sum to an alpha of 1.0) that smoothly (but not too smoothly) blend the type textures into each other. This was working pretty well, too. I have some samples that saved somewhere; I'll try to dig them up and post them. Then the problem was getting S3TC working to acheive a useful level of coverage. As I mentioned before, this just didn't work well at all on current ATI drivers. I was looking either at writing my own S3TC compressor (about which there are confusing patent issues, sigh) or settling for a rather poor level of on-screen texture detail. And the final problem was the mapping of generational terrain textures to the geometry polygons. Remember that the terrain geometry is paged in according to screen-space error (so that distant mountains might get loaded before nearby plains). But the terrain textures don't care about vertical error -- they want a plain, "flat" generation structure. Handling the mapping between these two spaces, and keeping it consistent as geometry tiles came in and out and terrain textures were generated and deallocated turned into a huge bookeeping mess. Add that to the fact that due to the compression issue it wasn't going to look very good anyway, and I just gave up. If I was going to revisit the project, I think a better idea would be to reduce the required number of textures by compositing the terrain types and noise modulators right on the polygons as they are drawn. That's an 8x (!) multitexture algorithm (i.e. at least two passes on current hardware), but that should be doable. It is, however, and even greater bookeeping nightmare. It also needs to be pointed out that this kind of mechanism has no built-in support for "custom" terrain geometry features like roads or airports (this wasn't a problem for the game I had in mind, but it's kind of a showstopper for FlightGear). Those would require lots more work. :) Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
