Hi! Curtis Olson wrote: > On Jan 8, 2008 1:22 AM, Frederic Bouvier <> wrote: > > I was thinking about the parameter we pass to "Terra" to simplify the > initial grid. IIRC, this parameter is always the same, leaving all > *.arr.gz files with the same number of vertices. > > > Yes, that's a good point, and something definitely to think about if > we made such a tile layout switch.
So then we should not use geographical coordinates but rather use a mercator projection, assuming the earth is round, such as: y=dlat x=dlon*cos(dlat) and then impose a grid on that. If I understood it correctly, that is what Fred originally wanted to propose. That would give us a grid in which tile widths vary with their actual linear width. There are some problems with that. What comes to my mind first is that tiles would not be rectangular anymore. They would not be in the geographic coordinate system and at least for the border tiles they would not be in the projected coordinate system. This would lead to clipping problems in TerraGear which - if not solved accurately - could lead to z-fighting-problems or gaps at tile borders, if tiles overlap or "underlap" (is that a word? probably not). Currently we have tile borders that are representable as polygon - more strictly as rectangles - which makes clipping easy. The new tile borders could not be well-approximated using polygons. We could try creating clipping polygons that approximate the borders down to an error of SG_EPSILON, but I'm not sure if that is practicable. The alternative, of using clat, the center latitude of a tile ring as follows y=dlat x=dlon*cos(clat) would give us rectangular tiles at least in geographic coordinates, but would also lead us to the same problem Curt already mentioned: Curtis Olson wrote: > The big problem with the current system is that at every latitude > boundary where the number of tile subdivisions changes per degree, we > have ugly gaps because the tile edge matching code simply can't > account for 2 tiles matching up to 1 tile ... an oversight in the > original scheme. The alternative would be to scale the number of vertices passed to TerraFit by cos(lat)... Cheers, Ralf ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
