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.
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.
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.
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
