RE: RE: [Flightgear-devel] Scenery size constraints
Erik Hofman wrote: >Harald JOHNSEN wrote: >> Alberico, James F wrote: >> >>> 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 4 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. >Hi Jim, >It good to see some big names showing up on the list. This might give >the project a boost to get to the next level. You certainly mean Harald, not me, unless you are commenting on the ugly format of my name here. :-) >>> What I think I've learned so far from debugging: ... ... >At this point Curtis is the one who is most involved in these things. He >is attending the MathWorks International Aerospace and Defense >Conference 2005 and will be back tomorrow. It might be best to send him >a private copy of your mail also. That's a good idea. Thanks. Harald JOHNSEN wrote: >> I think that the only side effect will be that your new binary will be >> incompatible with current scenario files, >> perhaps that changing short to unsigned short could be enought. Erik Hofman wrote: >Curtis already mentioned he wanted to change the layout of the tiles >which probably breaks backward compatibility. So if it would be >necessary this change could be adopted as well. Thanks, Harald and Erik. An unsigned short for that item would help me for my specific purpose. Curt and others can determine which direction to take the project. A key question will be whether 65k or even 32k nodes far exceeds any reasonable performance expectations for the foreseeable future. Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery size constraints
Harald JOHNSEN wrote: Alberico, James F wrote: 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 4 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. Hi Jim, It good to see some big names showing up on the list. This might give the project a boost to get to the next level. 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. At this point Curtis is the one who is most involved in these things. He is attending the MathWorks International Aerospace and Defense Conference 2005 and will be back tomorrow. It might be best to send him a private copy of your mail also. 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. I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. Curtis already mentioned he wanted to change the layout of the tiles which probably breaks backward compatibility. So if it would be necessary this change could be adopted as well. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery size constraints
Alberico, James F wrote: 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 4 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 I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. But I am wondering if you won't have problem when rendering, isn't there an hardware limite on the number of tris we can send to glDrawElements and glDrawArrays in the plib code ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery size constraints
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 4 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
