Hi Curt,
Curtis Olson wrote:
> 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.
The topic you're talking about is highly familiar to me (even without
thinking about LOD), it's teasing me almost every second week, so you
can be assured that we're seriously going to take care about it :-)
The basic idea for coping with it is indeed to build an 'empty' grid of
tile boundaries - in the first step, just containing elevation data,
land cover to follow at a later step - to which all the corresponding
tiles have to match.
Obviously this leads to an increased triangle count at the tile borders
of lower detailed tiles, in order to match this elevation grid, but
together with the ability to build tiles of wider coverage this effect
should be easily outweighed by far.
> [...] 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.)
While we're at it I'd like to point out that we're regularly getting
bitten by the way how some of these issues have been addressed in the
past (I don't plan to go into detail here). Therefore we're obviously
feeling a noticeable impetus to make the Scenery build system less
static.
This doesn't mean that we're planning to revamp the entire Scenery
layout in a single, huge step. Instead we're aiming at turning every
individual processing step from a mandatory item into an option, thus
allowing for incremental improvements.
> 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.
The polygon clipping library is segfaulting - even though the data it's
being fed is topologically consistent - and it's author (of the
library) has been unable to provide a clue wether it could be fixed.
Therefore the step you mention here has been without option and the
delay is mostly caused by the fact that the involved people are facing
varying workload during their day job - which is not always predictable
when you're working on a freelance basis.
That's life. Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
------------------------------------------------------------------------------
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
