Re: Problem solved with the lakes

Corrubia, Stacie K wrote:

>OK --- I found the text that controls the texture in the lakes and
>Rivers data -- it was set to default not Stream or lake.  But I am not
>too sure why since I think that I ran it with the same command that I
>used when it worked.  
>  
>

I believe that when you prep the vmap0 data and extract the lake/river 
data, you need to specify the layer type in the command line options ... 
perhaps something subtle got missed there?

>A question on how the VMAP data is combined with the terrain DB though
>--- will the objects with #2D ID's be mapped onto the elevation of the
>underlying terrain?  So possibly I could have a river with "terrain
>type" undulations instead of a flattened water level?  Does the same
>hold true for all 2D type objects such as Roads, lakes, etc?  If I
>wanted a flat water level, would I have to edit the terrain DB first
>then use this modified foundation?  Would the same hold true for airport
>runways?
>  
>

A very good question.  Generally 2 D areas are simply drapped over the 
underlying terrain.  The elevation of any new points that are introduced 
into the mesh by polygon areas, is simply interpolated from the original 
terrain grid data.

There are a few exceptions to this rule.

1. Any point that is part of a triangle marked as ocean area is forced 
to zero elevation.

2. Points that form an adjacent lake area are averaged so lakes should 
be flattened.  However, this is only done within individual tiles, so 
lakes that span multiple tiles can develop artifacts.

3. Triangles that form rivers are slope limited.  This doesn't prevent 
rivers from running up and down hills, but it reduces the problem.  The 
amount of limitation can be tuned in the terragear code.  The problem is 
that the river data doesn't match the terrain data all that well.  If 
you do a small amount of flattening, you get rivers that run up and down 
the hills.  If you do a large amount of flattening, you get rivers that 
cut through ridges and leave a *lot* of cliff face artifacts when they 
don't follow the terrain data very well.  What we have now in the 
default code is a compromise.  What I'd love to have someday is better 
lake and river data ... I day dream about it quite often. :-)

4. Roads are handled very much like rivers except we use a much smaller 
amount of flattening.

>Why is it that I see some interesting cliff like artifacts between the
>roads and surrounding polygons?  Is there something different that I
>need to do while running terrafit?  Maybe increase the max number of
>polygons to modify the error number? 
>  
>

Take a close look at one of these next time you bump into it.  What I'm 
sure you will see is that roads, rivers, etc. can sometimes have very 
long segment lengths (1km or more.)  If you drop this into the middle of 
some complex terrain, you will get strange artifacts as you try to match 
up a 1km straight line with surrounding terrain.  Terragear can only 
adjust the elevation at the endpoint of the segment.

In order to reduce this problem, I added a --max-segment= option to the 
tgvpf tool.  Here you can specify the longest allowed line segment (in 
meters) that tgvpf will output.   tgvpf will subdivide the segments in 
it's output to ensure that none exceed your specified limit.  This gives 
more elevation adjustment points so that roads can better match the 
underlying terrain with fewer artifacts.

I have been using --max-segment=400 which is a balance between 
introducing too many additional polygons versus trying to match the 
underlying terrain perfectly.  You still will see some artifacts in some 
areas, but they are *greatly* reduced and generally the roads look 
pretty good.

As an aside, at some point I'm tempted to play around with fitting a 
curve through the road points both in X,Y and also in Z and then 
resampling the road points.  This should give more natural looking roads 
if done well.

You also mentioned airports ... airport surfaces are created 
independently ... still from the same terrain grid, but it is filtered 
and averaged (to hide sampling errors and noise) and then we fit a nurbs 
surface through the resulting points to achieve a naturally smooth 
curving surface that still follows the original terrain quite closely 
and blends well with the surrounding terrain.  There are paramenters in 
the code to tune the smoothed grid size as well as an overall slope 
limit.  The problem we are faced with is that if there are odd spike are 
a lot of elevation change in an airport area, we don't know if that is a 
sampling error/noise (most likely case) or if it is a real world feature 
(happens once in a while.)  At some point I'd like to be able to specify 
these tuning parameters on a per-airport basis.

The hole that is cutout from the terrain, carries over the airport 
surface smoothed elevations.  This is then blended into the surrounding 
terrain.  I am probably being quite generous with myself when I use the 
word "blend". :-)  But in most cases you don't see any artifacts between 
the airport and the surrounding area because the airport surface 
construction algorithm is pretty darn good.  Where you do see artificts 
is generally with smaller airports embeded in terrain.

Regards,

Curt.

-- 
Curtis Olson        http://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d


_______________________________________________
Terragear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/terragear-devel
2f585eeea02e2c79d7b1d8c4963bae2d