RE: [Flightgear-devel] New texture draw method

[Curtis L. O. <cu...@fl...>]

Norman Vine writes:
> Perhaps.
> 
> But I am seeing errors around most airport 'inserts' and chances are
> that these don't all live on tile boundaries.  :-)

There is another issue.  The land use land cover data introduces
additional intersections that airport can't account for in advance.
Take a close look at these and see if they happen at a point where
ground cover changes.

> This leads me to believe that there is probably a different resolution
> in the 'airport stuff' then in the overall tile 'stuff'

I don't think "resolution" is the correct term ... just that there are
intersections created later that the airport hole generation code
doesn't know how to account for before hand.  I think skirts around
the airport and holes should help a lot with these if that is the way
we choose to handle it.

> This kind of thing is a major PITA

People for the Ingestion of Tasty Animals???

> and compounded when working with 2D geographical data in lat lon
> space rather then a local projection in that the the 'ground
> resolution' is not the same in the 'x' and 'y' directions.  FWIW I
> do almost all of my planar geometric operations < polygon clipping
> ect > in a local gnomonic projection < ie the center of the data is
> the center of the projection > then reproject the results nack into
> 'global space'.  IMHO this works much better in that the 'working
> space' is as close to the 'ground space' as I can get and is still a
> relatively 'cheap' operation

I didn't follow all that exactly, but I don't think it's the source of
the problem in this particular case ...
 
> All things said though IMHO imperfect as FGFS might be
> It is looking  "pretty darn good" :))

Lot's of room for improvement, but we have come a long ways ...

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       FlightGear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org