On Wed, Mar 24, 2010 at 12:37 PM, Martin Spott wrote:
> We do. The current idea is 'simply' to render a certain range of
> sceneries at differently detailed levels (by doing polygon
> simplification at database level) and to connect these sceneries into
> some XML structure which takes care of the LOD-vs-distance equation.
> This tree is meant to be built at tile-level, which means that every
> tile is no more referenced by the corresponding .stg-file but instead
> by an XML file which refers to the various binary scenery tiles - in
> whichever file format might be appropriate (certainly starting with our
> well-known BTG).
> Sooner or later we'd like to drop the fixed tile numbering scheme -
> still keeping it as an option, but not mandantory - in favour of a
> schema where the area which is covered by the respective tiles is being
> defined in the respective XML files, thus allowing for variants where
> low-detail tiles may cover a wider area.
Hi Martin,
What you describe covers the aspect of managing and selecting different LOD
versions of the same tile, however I believe the much more difficult issue
is selecting and implementing a scheme to address the seams/cracks between
two tiles of differing LOD's.
And getting rid of the fixed tile numbering/layout scheme certainly would
add flexibility, but you would have to recover the entire world with some
new scheme should you choose to diverge from the existing scheme. It would
be hard to handle the transitions between an area covered with the old
scheme and an area covered with the new scheme. I'll be the first to point
out that there are many aspects of the current scheme that are sub optimal,
my point is not to defend the current approach here ... I have had various
ideas for new schemes from time to time too. I just want to add information
and perspective for those that are interested in this area of FlightGear.
What I would be in favor of doing is extending the scenery management
interface so we can turn off the existing scheme and turn on one of possibly
many alternative schemes. There are many other approaches to doing world
scenery and some of them are very tantalizing and would be fun to explore.
As you know there has been a tremendous amount of thought and effort that
has gone into the current scheme, from the lowest level of obtaining and
organizing raw GIS data to processing that data and finding ways to
seamlessly merge it together and resolve conflicts ... all the way to
generating 3d scenery out of the back end and rendering it in real time.
The system is far from perfect and the door is left wide open for someone
to build something newer or better. Martin and Jon and others have been
working on better systems to manage the raw data that feeds into the
terragear system. The only real point I wish to make in this reply is to
caution that with the current world scenery system there are many difficult
issues that have been thought about and addressed ("solved" may be too
strong of a word in many cases.) There are many issues that wouldn't even
be considered in the immediate discussion because they have always just
appeared to work and no one has had a problem or given them any thought at
all.
Even something "small" like redoing the current polygon clipping approach
has turned into much more effort perhaps than what was original anticipated.
Certainly the "old" approach had it's limitations and difficulties, but I
was able to nurse it through the entire world scenery data set to produce a
full build. Life has gotten more complex as people have defined more
detailed polygon areas which magnifies the short comings of the original
approach, but I suspect the real issues are less in the polygon clipping
routines themselves and occur more down stream in the later processing of
those clipped areas.
When you come up with an algorithm, and then throw the entire world at it,
you will most certainly run into every possible degenerate case imaginable,
and quite a few that are hard to even imagine. :-)
So I appreciate that people are thinking about some of these issues and
discussing possible improvements, and hopefully I can add some perspective
to the discussion to keep in mind some of the additional challenges that
should be considered.
Best regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
