On Thu, May 19, 2011 at 10:56 AM, Stuart Buchanan <stuar...@gmail.com>wrote:
> Going off-topic: one thing I have been thinking off is generating lower
> resolution BTG terrain files using terragear and then loading different
> resolution files depending on distance. So tiles far away would use a
> lower resolution height map and wouldn't include line and point features.
> I've still to investigate to see if this would make any real difference
> both
> in terms of I/O and graphical performance. Anyone got any ideas?
Ideas on this subject have been batted around since the earliest start of
the FlightGear project. I say that only to point out that the existing
system didn't get created blindly or without serious thought. There are
flaws and short comings though so it certainly is worth revisiting the
subject periodically.
The issue of level of detail: generally it's a good strategy to consider,
but the hardest part when doing this with terrain tiles is dealing with how
they match up against their neighbors of differing levels of detail. Any
mismatch of points and lines along the boundary will show up as visible
cracks which are really ugly. We've discussed several strategies for
ensuring the tiles match up, or hiding the seams ... none are ideal or
without cost.
At the time the current system was developed we strategized that avoiding
LOD might be a bigger net win that trying to cruft up some convoluted
strategy to hide or avoid cracks. It also made life simpler.
We also strategically decided to invest our resources into a TIN based
terrain system rather than a ROAM based. So we skin our terrain surface
with an irregular mesh of triangles that uses smaller triangles in higher
detailed areas (like mountains) and uses much larger triangles in areas that
are generally flat. We have a somewhat sophisticated algorithm to adapt an
optimal TIN to a regular gridded set of terrain data within some set of
constraints (achieving some minimal error tolerance, and/or limiting the
total number of vertices per tile.)
After we had our TIN based system implemented, ROAM based systems (such as
Victor) suggests became very popular. Then a few years later as graphics
cards became *much* more powerful and capable of storing arrays of geometry
data on board, TIN based system started coming back into popularity. It's
my understanding that much of the optimization strategies for ROAM
algorithms need to happen on the CPU and are hard to push out to the video
card to even take advantage of the newer video card features. So our
clothes are once again in style!
I'm not hear to suggest one approach is necessarily better than another,
just to say that a lot of thought and work has gone into the current system,
even though it isn't perfect.
Here are a couple other thoughts to consider ...
GoogleEarth/osgEarth type systems look incredible from altitudes of a few
thousand feet on up. But if you ever put your view point very close to the
ground and try to look at roads or airports, you'll see that all the great
imagery washes out and all that depth and shadow goes away and you just see
an ugly mishmash of unintelligible pixels. We need to look good in some of
these situations ... flying a 3 degree glide slope means we are looking at
the airport surface nearly edge on. This is a worst case scenario for
polygon texturing schemes.
We need to be able to populate the world with dynamic objects (other
aircraft) and land marks (buildings, bridges, etc.) If we use a LOD scheme,
the local terrain height for any given point in the distance will change ...
and object could be partially buried when viewed from a distance, then as we
fly closer and get a new LOD level it could suddenly be floating, and then
when we finally get close it could be at ground level. How do we deal with
that? I'm not saying there aren't ways it could be handled, but it needs to
be carefully considered.
Also, we need to be able to query the terrain elevation at each wheel and
contact point of our own vehicle as well as query the terrain elevation of
any arbitrary point that is in view. Many of our subsystems depend on the
terrain system providing this feature and we have a highly optimized system
to do this right now. Any new scheme will need to be able to do fast height
lookups of any arbitrary point ... and how will our subsystems behave if the
altitude is constantly changing as the LOD changes ... in a ROAM scheme this
can be nearly continuous.
We have done quite a bit of work to model airport surfaces that follow the
lay of the land. Our airports are not perfectly flat (just like in the real
world). The elevations at the ends of each runway are usually at least a
little bit different -- again trying to match the real world. Again ... not
perfect, but a lot of work has gone into making some pretty clever and at
least at the time, novel features that no other sim dared touch. And
airports go beyond just their surfaces ... there is also lighting (a big
one) and signage to consider ... these are things that a system like
googleearth for as good as it is, has no real facility to handle.
So if we do toss out the current system and replace it with a new one, do we
also toss out the existing airport models and design a new method to
represent and render airports. That is a *lot* of work for someone.
So yes, this is all great, let's have these discussions. It's worth looking
at what the current trends are in the graphics world. There are always
better ways we could do something, and always ways we could improve our
current implementation. But at the same time, there is a lot of work and a
lot to think about. I personally (i.e. just me) have several man years
invested into the current terrain system -- not counting the incredible
amounts of work that others have invested. I can get over my emotional
attachment to my work (I hope!) :-) But there is some significant
complexity and hard work required to achieve results in terrain modeling and
rendering ... especially for a system that is supporting a flight simulation
engine and isn't just a generalized viewer.
Regards,
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
