From: Curtis O. <cur...@gm...> - 2012-01-20 11:43:50
|
On Fri, Jan 20, 2012 at 12:09 AM, Martin Spott <Mar...@mg...>wrote: > A agree with all of the above. Creating all four edges for a stand- > alone tile sounds reasonable and creating just N/E when S/W are > available isn't that bad either. Anyhow, as far as I understand, > "fgfs-construct" was made for a workflow where _at_minimum_ two new > edges are being created with a new tile. > > It's missing the feature to smoothly align a tile with a surrounding > box of four edges which are given from a previous terrain build. > Trying to insert a single tile, or a chunk of just a few tiles > connected tiles results in strange artifacts in almost every second > case. > That is curious -- it should do fine in that situation. Originally the tile scheduler would build every other tile in every other row, and then come back and file in so eventually it should have hit this situation many times. My thinking was that in a "typical" situation with let's say 25 build nodes, if the scheduler assigned adjacent tiles to the build nodes, there could be a "race" condition when tiles decide if they own an edge or not. But by interleaving the schedule, there should never be a situation where two build nodes are ever working on adjacent tiles. The behavior you are describing definitely sounds like (a) a bug, or (b) constructing an isololated/surrounded tile with new land cover data such that it's impossible to get a correct match with the adjacent neighbor (built with different polygon data.) Situation (b) could easily happen if you are changing data or changing build options compared to the previous build. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org |