On Wed, Mar 24, 2010 at 1:43 PM, Martin Spott <[email protected]>wrote:
> 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 downside (or the thing to watch out for) is as the number of points in
the tile is reduced relative to the number of pre-defined points along the
edge, you will begin to have "star" type patterns emerge. As an extreme
example, imagine a low-detail tile with only a single elevation point at the
center. In that case you will have a series of long skinny triangles
radiating from the center of the tile out to the edges in a star type
pattern.
If the tile edges change slope from point to point, then these long skinny
triangles will could/will have significant slope differences compared to the
adjacent triangles. Add diffuse lighting effects and suddenly these long
skinny triangles jump out at you and look very unnatural. I've tried hard
to minimize these in the current scenery generation scheme, but in a few
places they still show up ... often when there is an interior point that
lies very close, but not quite on the edge of a tile.
But like any engineering approach, you have to pick a way to do it, and you
get all the good and all the bad. The trick is to maximize the good aspects
and do whatever you can to minimize and hide the deficiencies. So in this
case, you probably have to find a balance and not build low level of detail
tiles with too few interior points ... it may take some experimentation and
tuning.
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,
Yes ... the less paying work I do, the more my wife complains; and the less
FlightGear work I do, the more all of you complain. :-) One way or another
there's always someone beating me up on any given day. :-)
But it's all in good fun most of the time. :-)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
