Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 40000 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them.
What I think I've learned so far from debugging: 1.) The FGFS FGBinObj reads with no errors. 2.) The access violation occurs during leaf generation. 3.) The breakage occurs shortly after the texture coordinate index exceeds the max value of a short (32767) and goes negative. 4.) The symbols (e.g., tris_tc) that carry the read-in indices are of type int 5.) Examination of the TerraGear bin writes, and the FGFS reads reveal the indices are stored as short types. 6.) So, my conclusion is the scenery of the 1-arcsec tile is limited to 32767 nodes. (or maybe polygons?) And, TerraGear will truncate any index above that when writing to the binary file. I'm a newbie to TerraGear/FGFS details, so please correct me if I'm wrong about any of this. I would appreciate any comments on what mess might result from any attempt to store/read ints, rather than shorts, to expand the scenery resolution. From a performance standpoint, the capacity of the short type may far exceed anything practical at the present time. Comments on that aspect are welcome, too. Thanks!! Jim _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
