David Megginson writes: > Continuous LOD is probably a non-starter for us -- at least, the > implementations I've read about assume a regular elevation grid with a > simple texture mapped on top, and that doesn't describe the way we > model scenery. If someone wants to try that, you'll probably want to > write it from scratch and then we can try plumbing it into > FlightGear.
There are many issues with making CLOD work. Many/most of them are solvable with a lot of effort. > For static LOD, we could create multiple versions of each tile at > different resolutions for different distances. In that case, as Curt > has pointed out, the challenge is edge meshing. Let's say that we > have four LOD versions for each tile, and that we have an algorithm > that guarantees no more than a single-step resolution jump between > tiles. Any given edge will still have to be able to mesh up with > another tile of the same resolution, one higher, or one lower, so > we'll have, probably, over a hundred versions of each tile. It would be interesting to abstract out the scenery rendering/management system so that we could drop in additional schemes (maybe similar to the FDM's). There are a zillion different schemes to handle terrain LOD, most of which have been tried at one point or another, all of which have significant short comings, but many of which have significant strengths as well. In the end (for me) it came down to picking the approach that seemed to have the fewest short comings and then making it work as best as we can. No, we can't push out the visibility to obscene values, but consider that a reasonable visibility is 10 miles which we handle quite easily on average hardware. Sure there are places in the world where the visibility is much higher, and as you gain alitude visibility increases. But ... in my mind, if that's the only issue, I'm not too upset. I do like the idea of abstracting out the scenery subsystem. This would allow someone else to gain a better understanding of the complexities of building a terrain renderer that works in a flight sim. You'll need to consider things like: - continuous world wide coverage - disk space usage - data availability - edge matching if you use a tiling scheme - ability to query for a terrain elevation at an arbitrary point - ability to insert airports into the larger scheme (and do all the appropriate edge matching) - roads, rivers? - random ground cover objects? The CLOD techniques are really slick, and I've seen some cool demos. However, I personally so far (and maybe something exists, I dunno) have not seen anyone pull all the pieces of this together and handle all the issues/needs required by a flight sim. That doesn't mean there couldn't be something out there I'm not aware of (likely there is) but I haven't seen it. Oh, I almost forgot, you also have to consider what you are going to do about creating the necessary tools to generate the earth in the appropriate format required by your scheme. This is no small task. There's a good chance that in the end, you'll have more lines of code into your offline scenery building tools than we'll have in all of FlightGear. I don't want to scare anyone off here, but there are some harsh realities here that need to be considered as part of this discussion. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
