On Tue, Jan 17, 2012 at 11:49 AM, Martin Spott <martin.sp...@mgras.net>wrote:
> 1.) As far as I can tell there's still no reliable solution for
> creating proper, smooth seams between a newly built terrain tile and
> the adjacent, old tiles.
> The "fgfs-construct" honours two flags "--no-write-shared-edges" and
> "--use-own-shared-edges" which were meant to serve as a solution when
> the "Shared" directory of the previous full terrain build is available,
> but the underlying mechanics don't work in every case. Sometimes the
> success seems to depend on how flat the terrain is, sometimes the
> result looks just random.
>
The original code saved a directory tree of all the shared edges between
tiles. The tile that is built first is the one that gets to define the
points along the shared edge and all subsequent tiles must use those.
The world tiling scheme used tiles that were a preset width referencing
longitude (i.e 1/8th of a degree). But as you proceed towards the poles,
tiles get skinnier and skinnier. So at a couple predefined latitudes we
expanded the tile width (in terms of longitude, i.e. 1/4 degree, then 1/2
degree.) However we never accounted well for the seam between changing
tile widths. Essentially 1 tile would match up with two adjacent tiles and
there would be cracks.
But other than that unfortunate oversight, any cracks/gaps between tiles
would be a bug. Or it would mean that the source data changed for one
tile, but not for the adjacent tile. The "right" thing to do would be to
(a) remove the affected shared edges and (b) rebuild all the affected tiles.
>
> 2.) I think I've successfully built CORINE-based terrain on a single
> "fgfs-construct" process up to the size of "--xdist=10 --ydist=10",
> (which covers an area of 20 degree longitude and latitude).
> "I think", because I didn't fly the terrain in FG, but on the disk it's
> been a chunk of plausible size. In order to let "fgfs-construct"
> process such a large section on a single run, I've removed the entire
> cpu-time and mem-alloc limit section from src/BuildTiles/Main/main.cxx
>
> Surprisingly there seems to be another limit with really large areas.
> Supplying the flags "--xdist=19 --ydist=18" (around a center at
> "--lon=9.875 --lat=49.375", but there's no difference with "--lon=10
> --lat=49") seem to work nicely (test is still running, but looks good
> so far), but just swapping the numbers for xdist and ydist or selecting
> any bigger number for either of them results in "fgfs-construct"
> pretending to having finished successfully, but writing not more than
> approx. 30 MByte of terrain tiles to the disk.
>
It's possible that I included a "sanity" check for size -- the mem/cpu
limit is there because the construction process could hang in an infinite
loop for some tile if the source data did not play nice, rather than have a
build node hang up infinitely, I wanted to log a failure so I could (a) go
back and investigate the specifics of the failure and (b) the build node
could leave the problem tile and continue to build other tiles and not be
taken out of the game.
The original intent was for fgfs-construct to be called once per tile with
a distributed network of build nodes and a master server passing out work
to any node that became free. Having fgfs-construct build many tiles
across a range was more of an after-thought added as a convenience for
testing -- it wasn't ever intended to be the primary run mode of
fgfs-construct.
We all like bug free code, but logically correct code can get thrown for a
loop when you give it arbitrary limited precision numeric/floating point
data.
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
