On Wed, 2003-01-22 at 18:56, Curtis L. Olson wrote: > 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. >
You're absolutely right and IMHO it should be a long term goal to have a terrain renderer (in a terrain interface architecture why not) that supports long viewing distance and very detailed terrain with good performance at high flying speeds and altitude (for example for military aircrafts). But I agree it's no easy task at all and the current renderer works great for 95% of uses. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
