Originally I came up with this bright idea of doubleing the tile width at various increasing latitude thresholds in order to maintain a minimum tile width. That way the tile loader/pager could make some assumptions about how many tiles to load to cover the current visibility distance. And it keeps the tiles from getting really thin at extreme latitudes.
However, the tile loader can now check the actual width of the tiles and load the appropriate number, so the initial reason to vary the tile width is no longer valid. However, if the tiles get too narrow at high latitudes, we could still need to load upteen gazillion of them to cover moderate visibility distances when we are near the poles.
So my question is this ... what would people think of perhaps doubling the equatorial tile width, and then keeping the width of all tiles fixed to the same value at all latitudes.
One *huge* bug that would be fixed is that we would eliminate the unsightly cracks at the boundaries where the tile width changes, since the terragear tools never handled that special case of edge matching correctly.
This would involve minimal changes to the FlightGear side of things, but could cascade quite a bit through terragear (and would require me to rerun all the data preprocessing to split up all the data along the new tile boundaries.) It would also require some thought if we want to maintain compatibility with the old scenery (which would be an excellent idea, especially in the short term.)
The more I think about this, the more I like the idea. Even at pretty high latitudes, I think we'll still have reasonable tile sizes (i.e. around 1000m width at least.) Other than the work involved to make the change, can anyone think of any major downsides to making this change?
Regards,
Curt.
Phil Cazzola wrote:
This is a minor bug fix for sgBucketDiff().
If you crossed the bucket size boundary, the answer for dx could be wrong.
E.g.
going from 0:0, 21:7 to 0:7, 21:7 would give you dx = 7 (correct)
but going from 0:0, 21:7 to 0:3, 22:0 would give you dx = 6 (instead of 7)
Previously it differenced the center longitudes of the buckets. When you
cross a boundary, the center point of the larger bucket now lies on the edge of the smaller
bucket.
The result was a dx with an integer + 1/2 bucket, which rint() was rounding to the nearest even int.
This function only seems to be used in TerraGear. Source, test cases and results attached.
Can someone with the keys review this and check it in?
Thanks, Phil Cazzola
$ cvs diff newbucket.cxx Index: newbucket.cxx =================================================================== RCS file: /var/cvs/SimGear-0.3/source/simgear/bucket/newbucket.cxx,v retrieving revision 1.3 diff -r1.3 newbucket.cxx 274,278c274,282 < double c1_lon = b1.get_center_lon(); < double c2_lon = b2.get_center_lon(); < double diff_lon = c2_lon - c1_lon; < double span; < if ( sg_bucket_span(c1_lat) <= sg_bucket_span(c2_lat) ) { ---
double diff_lon=0.0; double span=0.0;
SGBucket tmp_bucket; // To handle crossing the bucket size boundary // we need to account for different size buckets.
if ( sg_bucket_span(c1_lat) <= sg_bucket_span(c2_lat) ) {
283a288,299
diff_lon = b2.get_center_lon() - b1.get_center_lon();
if (diff_lon <0.0) { diff_lon -= b1.get_width()*0.5 + b2.get_width()*0.5 - span; } else { diff_lon += b1.get_width()*0.5 + b2.get_width()*0.5 - span; }
Test 1 x passed Test 1 y passed Test 2 x passed Test 2 y passed Test 3 x passed Test 3 y passed Test 4 x passed Test 4 y passed Test 5 x passed Test 5 y passed Test 6 x passed Test 6 y passed Test 7 x passed Test 7 y passed Test 8 x passed Test 8 y passed Test 9 x passed Test 9 y passed Test 10 x passed Test 10 y passed Test 11 x passed Test 11 y passed Test 12 x passed Test 12 y passed Test 13 x passed Test 13 y passed Test 14 x passed Test 14 y passed Test 15 x passed Test 15 y passed Test 16 x passed Test 16 y passed Tests completed Total errors = 0 Test 1 x passed Test 1 y passed Test 2 x passed Test 2 y passed Test 3 x passed Test 3 y passed Test 4 x passed Test 4 y passed Test 5 x passed Test 5 y passed Test 6 x failed! Expected: 7, acutal:6 Test 6 y passed Test 7 x failed! Expected: 7, acutal:6 Test 7 y passed Test 8 x passed Test 8 y passed Test 9 x passed Test 9 y passed Test 10 x failed! Expected: 7, acutal:6 Test 10 y passed Test 11 x failed! Expected: 7, acutal:6 Test 11 y passed Test 12 x failed! Expected: 7, acutal:6 Test 12 y passed Test 13 x failed! Expected: 164, acutal:162 Test 13 y passed Test 14 x failed! Expected: -164, acutal:-162 Test 14 y passed Test 15 x failed! Expected: -164, acutal:-162 Test 15 y passed Test 16 x failed! Expected: -164, acutal:-162 Test 16 y passed Tests completed Total errors = 9
------------------------------------------------------------------------
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
