On Wed, Mar 24, 2010 at 5:13 PM, Curtis Olson <curtol...@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 10:41 AM, Tim Moore wrote:
>
>> While on this subject, do you scenery guys have any thoughts about
>> different levels-of-detail in scenery tiles?
>>
>
> Yes, in the initial scenery design phase we had a very extended discussion
> about level of detail. There are many ways to do this, but consider ...
>
> - Any static level of detail scheme is going to have to account for tile
> edge matching. This is a non-trivial (tm) problem. No matter what you do
> will yield artifacts and issues matching up the edge of a tile at a higher
> level of detail with a tile at a lower level of detail. There are a number
> of ways to work this. We could create skirts around all tiles to try to
> hide the problem, but you will still see feature discontinuities depending
> on what angle the seam is viewed from. You could create transition ribbons
> that bridge the polygon edge of one tile to the polygon edge of another
> tile, but the number of permutations are high, so this is difficult to deal
> with. You could turn off clearing the depth buffer each frame and not draw
> sky below the horizon and just let the open pixels in the cracks smear along
> from the previous frame. We had a SME (subject matter expert) at the time
> who detailed about a dozen different approaches along with their pluses and
> minuses.
>
> I think skirts at a slightly less-than-vertical angle are the way to go. It
doesn't matter if skirts of adjacent tiles intersect.
> His recommendation (as someone who had been there, done that for just about
> every possible approach) was that he had the best overall results just using
> a simple single level of detail scheme.
>
> Not long after we committed to our single level of detail (triangle soup)
> sort of terrain meshing approach, ROAM type approaches became more and more
> popular. These approaches minimized the amount of geometry that had to be
> pushed across the system bus to the graphics card each frame and thus
> maximized details and rendering rates. There we some really neat demos
> floating around the implemented variations of the basic scheme that expanded
> or collapsed triangles depending on various screen space and distance
> parameters. Initially most of these schemes were for small areas, they
> didn't account for larger round world environments, and didn't have good
> ways to handle features cut into them (like airports or land use areas.)
> Over time, there were dynamic level of details algorithms that did start to
> account for some of these more difficult challenges that our original scheme
> already accounted for.
>
> But then the world of graphics cards changed again, and consumer level
> graphics cards started storing more geometry and scene information right on
> the card. This meant less work every frame pushing the geometry across the
> system bus, and graphics cards could draw much more geometry each frame than
> previous generations of graphics cards could do.
>
> (My interpretation) This ability of newer graphics cards to draw insane
> numbers of polygons every frame tipped the balance of power away from ROAM
> (dynamic level of detail schemes intended to minimize polygon count) and
> back towards triangle soup approaches. So good news, FlightGear's terrain
> scheme is back in style again! Well sort of anyway.
>
> ROAM, and any scheme that computes triangles on the CPU, is definitely out
of fashion. People are still working hard on level-of-detail for terrain,
but these days the interest is in methods that run entirely on the GPU. If
you have a detailed near field, you will quickly overwhelm your GPU with the
n-squared number of polys if you try to keep that detail over the entire
scene.
> As Tim points out, there are still good reasons to implement some sort of
> level of detail scheme. It would be great to draw terrain out to 200+ miles
> so we can see a high mountain at a great distance just like real life. It
> would be great to be able to do orbital simulations and accurately draw the
> earth from the perspective of outer space.
>
> If this indeed is something we think is worth exploring then we should come
> full circle to the discussion we had in the late 1990's about exactly the
> best way to handle the seams between adjacent tiles of differing levels of
> details. Note this is a much different challenge from drawing stand-alone
> models at different levels of detail at different distances. In a tiled
> word scheme, it is the seams between adjacent tiles that get you. (And as I
> mentioned before, FlightGear isn't 100% immune to problems at tile seams ...
> we've done our best to hide and minimize these, but even so some issues have
> snuck through and exist today.) If we want to have this discussion we
> should probably split it off into a separate thread because the number of
> issues to consider explodes into a big discussion on it's own.
>
> I don't think we need to do anything too fancy. I'm a fan of "Chunked LOD"
approaches that switch in different pieces of a mesh instead of changing
discrete polygons. But a real LOD scheme that goes all the way out to the
full earth would let us fully integrate with OSG's DatabasePager and allow
us to easily support terrain paging for multiple views.
Tim
------------------------------------------------------------------------------
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
