[Flightgear-devel] scenery build question
Curt, Do you select which water texture to use based on the VMAP data, or is there something smarter going on like looking at the size of the water body? The reason I ask is that while the water textures we have are quite nice for large bodies of water and man made reservoirs, they don't look anything at all like rivers or small lakes. The Potomac, for instance, goes from a greenish brown to just plain mud colored in spots. River textures could also be made in a way that allows the shallows near the banks to look more realistic. I would be happy to cook up some nice textures with proper colors for rivers and small lakes if you would be able to use them. Josh The water that I drink: http://maps.google.com/maps?ll=38.961778,-77.139602spn=0.015407,0.027275t=khl=en http://maps.google.com/maps?ll=38.909736,-77.091408spn=0.015418,0.027275t=khl=en http://maps.google.com/maps?ll=38.799952,-77.030854spn=0.015442,0.027275t=khl=en Why Canadian beer is better: http://maps.google.com/maps?ll=45.446764,-73.517761spn=0.055604,0.109099t=khl=en But even Niagara isn't really blue: http://maps.google.com/maps?ll=43.078136,-79.073303spn=0.007236,0.013637t=khl=en And of course Old Miss: http://maps.google.com/maps?ll=29.882328,-89.940605spn=0.137438,0.218199t=khl=en ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB (Was: San Jose)
On Tue, 2005-11-08 at 09:19 +0200, Vassilii Khachaturov wrote: I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. btw it looks pretty cute sometimes --- e.g., a skyscraper swallowing a radio tower and thus it looks like a skyscraper with a smaller antenna tower on its top; such things happen in real life as well :) A better example is a skyscraper covering a lighting beacon but the rotating light (white-green) shines through the wall of the building. This collision of objects is located within the perimeter of KSFO. Obviously the building doesn't belong there. And No, it is not a airport building :-) George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB (Was: San Jose)
Erik Hofman wrote: Paul Surgeon wrote: Since it's in the default San Francisco area you can submit it to Erik or Curt or you could sumbit it to the FlightGear scenery database. http://fgfsdb.stockill.org/ I'm just not sure if Curt will include objects from the FG scenery db into the default scenery area. Curt what's the plan with regards to models and the next scenery build? I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. Once that's sorted out I want to sync the base package and the DB prior to a new release. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I was thinking at some point that there should be a system by which FG could figure this out automatically. If every automatically generated object had a unique ID this could be possible. An object loaded from a path listed earlier in $FG_SCENERY (and therefore probably not from the base scenery) that has the same ID could prevent the original object from being loaded. The main drawback I see is that once the ID numbers of the automatically generated objects are assigned they have to be persistent. I don't know it it's possible to do this between releases. Just to clarify, by automatically generated objects, I mean the ones that are automatically generated from other data sources by Curt's scripts. Additionally you could just not allow two objects at the exact same lat/lon. Assuming that the lat/lons in the source data never change that could serve as the unique ID. This would require some additional rules for stacking objects on top of each other. e.g. I have a somewhat generic water tower at KADW with a generic military beacon sitting on top of it. They should definitely be separate objects, but both have the same lat/lon. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB (Was: San Jose)
I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. btw it looks pretty cute sometimes --- e.g., a skyscraper swallowing a radio tower and thus it looks like a skyscraper with a smaller antenna tower on its top; such things happen in real life as well :) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery DB (Was: San Jose)
Paul Surgeon wrote: Since it's in the default San Francisco area you can submit it to Erik or Curt or you could sumbit it to the FlightGear scenery database. http://fgfsdb.stockill.org/ I'm just not sure if Curt will include objects from the FG scenery db into the default scenery area. Curt what's the plan with regards to models and the next scenery build? I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. Once that's sorted out I want to sync the base package and the DB prior to a new release. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB
Erik Hofman wrote: I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. Ooops, I've simply forgotten to care for the dupes. Months ago Frederic sent me a list an I started refining that for inclusion into the DB but I obviously forgot the final steps Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Is this the proper list for FGFS scenery questions? Craig___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Craig Martin wrote: Is this the proper list for FGFS scenery questions? Yes, see http://www.terragear.org Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery files triangles
While looking at the scene graph I saw that the .btg files are generating a lot of leafs. This is not new, but perhaps it is becoming worse each time the source data resolution used to build the tile becomes finer. I have added a few traces in simgear's sgBinObjLoad functions, an example : sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/942058.btg) get_wgs84_nodes.size=1543 get_tris_v.size=0 get_strips_v.size=0 get_fans_v.size=928 leafMap.size=12 local_terrain-getNumKids()=928 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/942043.btg) get_wgs84_nodes.size=1671 get_tris_v.size=0 get_strips_v.size=0 get_fans_v.size=1045 leafMap.size=14 local_terrain-getNumKids()=1045 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/KNUQ.btg) get_wgs84_nodes.size=3500 get_tris_v.size=43 get_strips_v.size=3 get_fans_v.size=0 leafMap.size=33 local_terrain-getNumKids()=46 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/KPAO.btg) get_wgs84_nodes.size=685 get_tris_v.size=11 get_strips_v.size=3 get_fans_v.size=0 leafMap.size=10 local_terrain-getNumKids()=14 We can see that : - tile objects use only fans - airport objects use strips and regular tris - for an equal number of triangles a tile object uses 50 times more leafs than an airport object ; - the number of leafs from a tile has nothing to do with the number of materials ( leafMap ) When the leafs are inserted in the scene graph they are sorted by materials, so my concern is not about OpenGl material switching but rather on the number of calls needed to draw a few triangles. The use of display list has divided the number of calls to opengl, that's why there was a substancial gain. If we do one call per material we can divide this number of calls by 50 for tile objects. And yes I know strips or fans are supposed to be faster than triangles, but no this is not true in the current situation (1000 calls to draw a 10 triangle strips/fans can't be faster than 10 call to draw 1000 regular triangles). Is there a reason why we are using fans and not strips for tile objects ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? http://baron.flightgear.org/pipermail/terragear-devel/2005-June/001219.html Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Erik Hofman wrote: Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? http://baron.flightgear.org/pipermail/terragear-devel/2005-June/001219.html Erik lol ok, I didn't saw that ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? These days, it's usually faster to use indexed vertices. Strips and fans are faster because they reduce the number of vertices that need to be transformed by (and sent to) the hardware by saving 1 or 2 from the last triangle drawn. But modern cards have vertex caches that are much (!) larger than 1 or 2 entries. If someone wants to change the terrain format, I'd suggest trying indexed vertices first -- it's simpler, too. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
On 13 Jul 2005, at 15:36, Andy Ross wrote:These days, it's usually faster to use indexed vertices. Strips and fans are faster because they reduce the number of vertices that need to be transformed by (and sent to) the hardware by "saving" 1 or 2 from the last triangle drawn. But modern cards have vertex caches that are much (!) larger than 1 or 2 entries. If someone wants to change the terrain format, I'd suggest trying indexed vertices first -- it's simpler, too. Whilst wishing to avoid a 'me too' post, I fully agree with this; writing a strip-ifier is a complex job, storing each tile as several, or maybe even one vertex array with indices is easier to generate, involves fewer SSG nodes, and is easier for drivers to optimise on the card, than either fans or strips.James___ 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: 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
[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
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 tiling
hi ;
i am trying to change scenery tiles. i am using fg and ppe under windows xp.
i follow the instructions
http://mail.flightgear.org/pipermail/flightgear-devel/2001-December/002239.html
but i couldnt load the scenery . mostly ppe crashes with the error
viewer.loadModel('KLVK.atg')
Assertion failed: 3*k==nNoOfVerticesForThisFace, file
C:\ppe\plib\src\ssg\ssgLoa
dATG.cxx, line 385
is there an other way to replace tiles?
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Lee Elliott wrote: Hello Jon, I was just wondering if you had done any updates/additions to your models. I thought I'd seen a couple of messages where you'd corrected a couple of things, like the orientation of the Humber bridge but I haven't been able to find them. I also noticed that a few objects seemed to be missing from the Models archive that I have e.g. tilburychimney.ac kingsnorthchimney.ac That was because I got sidetracked coding for the database, and working on an aircraft model - I added a bunch of chimney models last night - there are still a couple missing, but I need to find dimensions for them. I've been working on some code for placing electricity pylons, and hope to be able to do a mass update of these in the near future. I added a tower bridge model yesterday afternoon - that'll be positioned at some point today, and once that's done I'll run another scenery export. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
On Sunday 06 March 2005 14:14, Jon Stockill wrote: Lee Elliott wrote: Hello Jon, I was just wondering if you had done any updates/additions to your models. I thought I'd seen a couple of messages where you'd corrected a couple of things, like the orientation of the Humber bridge but I haven't been able to find them. I also noticed that a few objects seemed to be missing from the Models archive that I have e.g. tilburychimney.ac kingsnorthchimney.ac That was because I got sidetracked coding for the database, and working on an aircraft model - I added a bunch of chimney models last night - there are still a couple missing, but I need to find dimensions for them. I've been working on some code for placing electricity pylons, and hope to be able to do a mass update of these in the near future. I added a tower bridge model yesterday afternoon - that'll be positioned at some point today, and once that's done I'll run another scenery export. :) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
On Thursday 06 January 2005 16:15, Jon Stockill wrote: [snip...] Well if anyone wants to add a few objects to their scenery you may find these useful (files are under 250k each): http://flightgear.stockill.org.uk/testing/FGFS-Models-20050106 .tgz http://flightgear.stockill.org.uk/testing/FGFS-Objects-Europe- 20050106.tgz The first should be unpacked in your FG_ROOT directory, and will add an extra subdirectory to the models directory, the second wherever you've downloaded your scenery to - you'll need to ensure you've got the scenery in the Terrain directory, this file will populate an Objects tree. Enjoy. Hello Jon, I was just wondering if you had done any updates/additions to your models. I thought I'd seen a couple of messages where you'd corrected a couple of things, like the orientation of the Humber bridge but I haven't been able to find them. I also noticed that a few objects seemed to be missing from the Models archive that I have e.g. tilburychimney.ac kingsnorthchimney.ac LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery questions
I have a few questions regarding scenery building. First question : What datasets and parameters are used when building the global scenery? I want to be able to duplicate the scenery building process so that I get *exactly* what is released. For example what sort of max error is used when using TerraFit? Second question : Can I edit the datasets like VMAP0, the DEM and whatever else is used and submit the changes? For example KDCA looks like it's on a table top with small cliffs all around whereas in real life it's practically at river level. The only way to fix scenery problems is to fix the data that gives the problems. What I want to do is fix some data in the datasets, rebuild a scenery chunk and check the results. If I'm not happy repeat the process till the final product looks right. Then submit the dataset changes to be included in the next scenery release. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery download
The graphical interface and the FTP interface links for scenery download are still pointing to Scenery-0.9.5 This is in page http://www.flightgear.org/Downloads/scenery.html Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery download
Frederic Bouvier wrote: The graphical interface and the FTP interface links for scenery download are still pointing to Scenery-0.9.5 This is in page http://www.flightgear.org/Downloads/scenery.html Yes, thanks ... I'm planning to roll up the win32 binary release today (thanks for building the executable so quickly), then sort out the scenery downloads (and hopefully the terrasync tree) and then make a big world wide announcement of v0.9.8 either tonight or tomorrow depending on how fast I progress on these items. Regards, Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] Scenery
Am Montag 10 Januar 2005 17:26 schrieb Christian Mayer: ... I got an answer. They told me that the ministry decided that it'll be a security problem if people could the the coordinates of objects and places easily and quickly from the BayernViewer. The usual stupidity :-( As if it would make a difference, whether I can look up coordinates for free or have to buy a map, if I intend to fly a plane into something. So the alternative would be that I buy the map-data CD-ROM at ebay. They are not expensive (they are made for tramping and bike tours) - but too expensive for looking up just a few locations :( I've the DSAT5 at home. Coordinates are rather crude though. PS: Does anybody know an online map service where you can get the coordniates? For Berlin there is http://www.berliner-stadtplan.com Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Mayer schrieb: Jon Stockill schrieb: I can look up a few positions of objects. What format do you need? Lat/Lon? Just lat/lon, a heading (if appropriate) and the model you want inserted at that point (obviously if it's not a standard one form the Models directory then it'd be nice if you had the model too, so that everyone else gets to see it). I'll archive the Objects tree and my models, and let you know when they're available for download. Argh. The Bayernviewer page doesn't give me the coordinates anymore (the old, non-java version could do that). I write an eMail and hope that they'll add that functionality. I got an answer. They told me that the ministry decided that it'll be a security problem if people could the the coordinates of objects and places easily and quickly from the BayernViewer. So the alternative would be that I buy the map-data CD-ROM at ebay. They are not expensive (they are made for tramping and bike tours) - but too expensive for looking up just a few locations :( CU, Christian PS: Does anybody know an online map service where you can get the coordniates? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4qyllhWtxOxWNFcRAp48AJ98gI8VphyCFeIFLDhFKAlqji6RlgCfWzLo Xva9iA5jbeUODksLKKX6jCU= =FLNU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery questions
At http://www.flightgear.org/Downloads/scenery.html I've noticed there are two colored boxes now for downloadable scenery, yellow and orange. Is one newer, or have more detailed objects? There are _fewer_ transmitter towers or cellular masts in 0.9.7 as there were in 0.9.5. While several were perhaps a little taller than in reality, i know several were valid, that are now gone. What happened? At 45*54.5N 119*30.0W thru 45*56.2N 119*19.2W the Columbia River is still filled with green land and trees, instead of water. Looks like an artifact, filled incorrectly downstream from a road/bridge. Is this an automatically generated landscape? If so, I imagine there is a database of corrections that must be generated and applied. Who's doing this? Thanks, Stewart -- Powered by Linux. Virus and bug free, by design. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: While messing around with my scripts for inserting objects into the scenery (it's now all database driven, with numerous datasets imported) I decided I could do with a few landmarks. Here's a couple of views of the first, also showing off the object positioning: http://flightgear.stockill.org.uk/models/ This looks great. I whish someone would create such a scenery for Germany (or at least Bavaria)... CU, Christian PS: For Bavaria you can get the official 1:5 (or is it even 1:25000) maps and air pictures for free from the net. But they are only in pixel format (not vector format) and the UI isn't that great to do some harvesting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3R4alhWtxOxWNFcRAvrzAKCFT6WzJPm4sbgnDioU9Z5jj4dxgACaAst+ iZO/MIQ77wzI7pGmBd4g2ZE= =ZOzR -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Am Donnerstag 06 Januar 2005 12:16 schrieb Christian Mayer: Jon Stockill schrieb: While messing around with my scripts for inserting objects into the scenery (it's now all database driven, with numerous datasets imported) I decided I could do with a few landmarks. Here's a couple of views of the first, also showing off the object positioning: http://flightgear.stockill.org.uk/models/ This looks great. I whish someone would create such a scenery for Germany (or at least Bavaria)... I've begun some scenery work for the Berlin area. I'd like to see some place/db where you could upload models and coordinates, which creates corresponding .stg files. PS: For Bavaria you can get the official 1:5 (or is it even 1:25000) maps and air pictures for free from the net. But they are only in pixel format (not vector format) and the UI isn't that great to do some harvesting Really??? That's great. In Brandenburg they only provide it commercially with a tremendous price tag (1 per square kilometer - 3 for the whole state Brandenburg) What's the URL? Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
On Thursday 06 Jan 2005 11:43, Thomas Frster wrote: I've begun some scenery work for the Berlin area. I'd like to see some place/db where you could upload models and coordinates, which creates corresponding .stg files. I've also made a start on some UK city and airfield scenery. I was wondering about setting up a collaborative repository for this. (I can get vhost accounts on the cheap with a fair ammount of bandwidth). We could probably start one for the European Scenery (to keep b/w reasonable) so people can come along and download the objects / placements they require. Its probably something that ought to be looked into but I'd like to hear from others who are developing European scenery and would like to place it under a free licence. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Dave Martin wrote: I was wondering about setting up a collaborative repository for this. (I can get vhost accounts on the cheap with a fair ammount of bandwidth). I think the missing of exactly such a repository is the main obstacle for collecting such data. I'd be willing to provide an anonymous FTP upload directory and maintain a collection of everything that arrives there - at least one thing where I could serve the community. I'd suggest that contributions should consist of any sort of archive files that contain everything which is necessary to define the object and it's location like e000n50/e006n51/3056458.stg plus: e000n50/e006n51/EDLN.btg.gz for EDLN. I'm convinced I'll find a way to merge the objects and provide useful packages to Curt and the user community, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Martin Spott wrote: I think the missing of exactly such a repository is the main obstacle for collecting such data. I'd be willing to provide an anonymous FTP upload directory and maintain a collection of everything that arrives there - at least one thing where I could serve the community. ftp://ftp.ihg.uni-duisburg.de/FlightGear/incoming/ at least if everyone agrees upon this. Please add a timestamp into the filename of your contribution to increase the chance not to overwrite other peoples stuff, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
On Thursday 06 Jan 2005 12:54, Martin Spott wrote: Martin Spott wrote: I think the missing of exactly such a repository is the main obstacle for collecting such data. I'd be willing to provide an anonymous FTP upload directory and maintain a collection of everything that arrives there - at least one thing where I could serve the community. ftp://ftp.ihg.uni-duisburg.de/FlightGear/incoming/ at least if everyone agrees upon this. Please add a timestamp into the filename of your contribution to increase the chance not to overwrite other peoples stuff, Martin. Thats great :-) Although I'm a bit dubious about it being anonymous access :-/ Theres a great potential for abuse (don't forget e:mail will be listed in the FG Dev list archive.) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Christian Mayer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: While messing around with my scripts for inserting objects into the scenery (it's now all database driven, with numerous datasets imported) I decided I could do with a few landmarks. Here's a couple of views of the first, also showing off the object positioning: http://flightgear.stockill.org.uk/models/ This looks great. I whish someone would create such a scenery for Germany (or at least Bavaria)... I can position all the navaids for you if you like. If you have any lists of object positions (I've got lighthouses, wind farms, power stations, radio masts, and Ordnance Survey triangulation points in the database so far - but this only covers the UK) then I'd be happy to add them to the data I have and produce scenery object data for you. Just let me know the areas you're interested in. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Frster schrieb: PS: For Bavaria you can get the official 1:5 (or is it even 1:25000) maps and air pictures for free from the net. But they are only in pixel format (not vector format) and the UI isn't that great to do some harvesting Really??? That's great. In Brandenburg they only provide it commercially with a tremendous price tag (1 per square kilometer - 3 for the whole state Brandenburg) If you want the detaild maps (1:500 or so) or air photographs with a very high resolution you have to pay. I don't know the license for using the free data as an data source at the moment. But using it just as an reference should be ok IMHO. What's the URL? http://www.geodaten.bayern.de/bayernviewer/index.html (Java required; page is in German, but not too hard to work with if you can't speak german...) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3T/plhWtxOxWNFcRAoYAAJ9oedEwJAeqAebKdFobJi7GbdgYdACfUhQn xmNf4+pWAKXEcveJ4owGDwQ= =Dvs9 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Dave Martin wrote: On Thursday 06 Jan 2005 11:43, Thomas Frster wrote: I've begun some scenery work for the Berlin area. I'd like to see some place/db where you could upload models and coordinates, which creates corresponding .stg files. I've also made a start on some UK city and airfield scenery. I was wondering about setting up a collaborative repository for this. (I can get vhost accounts on the cheap with a fair ammount of bandwidth). For model positions the amount of data isn't that great - 11899 objects across these scenery sets: e000n40/ e000n60/ e010n50/ w010n40/ w010n60/ e000n50/ e010n40/ e010n60/ w010n50/ w020n60/ is just under 13MB (and compresses to 0.25MB) The models themselves will obviously be larger, but a few suitable generic models really can go a long way to making the scenery look nice. A handful of more specific landmarks improves things further. If anyone has any data they'd like included in the database all I need is lat, lon, heading, and a model name - I have a script which drives the sim to update the ground elevations for the relevant points so that the models sit nicely on the ground. I'm happy to expand the models page on flightgear.stockill.org.uk to include any models that people want hosting. We could probably start one for the European Scenery (to keep b/w reasonable) so people can come along and download the objects / placements they require. Its probably something that ought to be looked into but I'd like to hear from others who are developing European scenery and would like to place it under a free licence. I'm happy for all my models to be GPL. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Dave Martin wrote: Although I'm a bit dubious about it being anonymous access :-/ I have had an anonymous FTP 'incoming' directory on this server for serveral years now and experienced very little abuse. Files that I can't connect to something useful and legal are being removed from time to time. Just for the record: You can upload to this directory, you can't list the directory and you can't download from this directory, even if you know the filenames. I think this is safe enough. My offer would be to _manually_ maintain a small page with a list of everything that has been uploaded, I'll copy the stuff from the incoming directory to the public area. I don't want to urge anyone to agree on this method to distribute FG scenery objects although I'll happily create a site if a 'critical mass' decides that this is indeed a good thing ;-) Ah, BTW, if you want to have your contribution be accompanied by a comment, send me an EMail or better add a small README into your package that you intend to upload, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Martin Spott wrote: I'd suggest that contributions should consist of any sort of archive files that contain everything which is necessary to define the object and it's location like e000n50/e006n51/3056458.stg plus: e000n50/e006n51/EDLN.btg.gz for EDLN. I'm convinced I'll find a way to merge the objects and provide useful packages to Curt and the user community, It's not easy to update an airport like that, since the airport model requires a suitably sized/shaped hole in the terrain. This works well for objects sitting *on* the terrain though, with 1 slight limitation - if 2 people are working on different airports in the same tile then updates from 1 person would overwrite the changes from another if the entire stg file was provided. A database gets around this problem, since objects are only allocated to tiles when the data is exported to the scenery. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Jon Stockill wrote: Just let me know the areas you're interested in. Europe ? ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Martin Spott wrote: Jon Stockill wrote: Just let me know the areas you're interested in. Europe ? ;-)) Which scenery tarballs? I'll get them downloaded, and get on with processing the terrain elevation for the navaids straight away - more detail can be added as people find me info to import. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Jon Stockill wrote: It's not easy to update an airport like that, since the airport model requires a suitably sized/shaped hole in the terrain. This works well for objects sitting *on* the terrain though, with 1 slight limitation - if 2 people are working on different airports in the same tile then updates from 1 person would overwrite the changes from another if the entire stg file was provided. That's why I offered to 'merge' the data. I see, a sole airport object probably was a bad example, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Martin Spott wrote: Jon Stockill wrote: It's not easy to update an airport like that, since the airport model requires a suitably sized/shaped hole in the terrain. This works well for objects sitting *on* the terrain though, with 1 slight limitation - if 2 people are working on different airports in the same tile then updates from 1 person would overwrite the changes from another if the entire stg file was provided. That's why I offered to 'merge' the data. I see, a sole airport object probably was a bad example, Well David Luff is already collecting airport updates on his taxidraw site, and as far as I know the 0.9.7 Scenery already includes all those updates. The advantages of objects sitting on the scenery is that they can be easily updated independantly of the terrain, and distributed seperately. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: Martin Spott wrote: Jon Stockill wrote: Just let me know the areas you're interested in. Europe ? ;-)) Which scenery tarballs? I'll get them downloaded, and get on with processing the terrain elevation for the navaids straight away - more detail can be added as people find me info to import. My town lies in e010n40.tar.gz (as well an Munich and a big part of the Alps)... I can look up a few positions of objects. What format do you need? Lat/Lon? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3UsrlhWtxOxWNFcRAhkOAJ42sVUaU6IAfiFNj0rG5VfejU7YxQCgrw7P zBbKKfkI9gMGlkAJRKxj/BU= =IWTU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Christian Mayer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: Martin Spott wrote: Jon Stockill wrote: Just let me know the areas you're interested in. Europe ? ;-)) Which scenery tarballs? I'll get them downloaded, and get on with processing the terrain elevation for the navaids straight away - more detail can be added as people find me info to import. My town lies in e010n40.tar.gz (as well an Munich and a big part of the Alps)... Excellent - I've done that square already :-) I can look up a few positions of objects. What format do you need? Lat/Lon? Just lat/lon, a heading (if appropriate) and the model you want inserted at that point (obviously if it's not a standard one form the Models directory then it'd be nice if you had the model too, so that everyone else gets to see it). I'll archive the Objects tree and my models, and let you know when they're available for download. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Jon Stockill wrote: Well David Luff is already collecting airport updates on his taxidraw site, and as far as I know the 0.9.7 Scenery already includes all those updates. The advantages of objects sitting on the scenery is that they can be easily updated independantly of the terrain, and distributed seperately. Exactly this was my intention, I didn't aim at reinventing David's wheel (TM ;-)) Apparently you don't want me to collect and distribute such objects and I won't urge you to leave this work to me I actually just made an offer. Feel free to use it or not, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Martin Spott wrote: Exactly this was my intention, I didn't aim at reinventing David's wheel (TM ;-)) Apparently you don't want me to collect and distribute such objects and I won't urge you to leave this work to me I actually just made an offer. Feel free to use it or not, My apologies - I obviously got sidetracked by your example :-) In which case we'll compare notes, and see if we can come up with something that'll work on a global scale. I have a decent stack of data so far, but there's no easy way for people to update it. I can put something together to allow people to visualise the info in the database quite easily, but handling the importing/updating of new/changed data requires some thought. If you've got a database handy I can send you a dump of the database I have so far. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: I can look up a few positions of objects. What format do you need? Lat/Lon? Just lat/lon, a heading (if appropriate) and the model you want inserted at that point (obviously if it's not a standard one form the Models directory then it'd be nice if you had the model too, so that everyone else gets to see it). I'll archive the Objects tree and my models, and let you know when they're available for download. Argh. The Bayernviewer page doesn't give me the coordinates anymore (the old, non-java version could do that). I write an eMail and hope that they'll add that functionality. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3Vt/lhWtxOxWNFcRAuw2AKCcc2hN/zfuqJHl0nqVyr98mA9/lQCfUFcg eDdcYVUJw4SoTLBLKgzgmgU= =vuU/ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Christian Mayer wrote: Argh. The Bayernviewer page doesn't give me the coordinates anymore (the old, non-java version could do that). I write an eMail and hope that they'll add that functionality. OK Well if anyone wants to add a few objects to their scenery you may find these useful (files are under 250k each): http://flightgear.stockill.org.uk/testing/FGFS-Models-20050106.tgz http://flightgear.stockill.org.uk/testing/FGFS-Objects-Europe-20050106.tgz The first should be unpacked in your FG_ROOT directory, and will add an extra subdirectory to the models directory, the second wherever you've downloaded your scenery to - you'll need to ensure you've got the scenery in the Terrain directory, this file will populate an Objects tree. Enjoy. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery, plus an offer
On Thu, 06 Jan 2005 13:21:36 + Jon Stockill wrote: I can position all the navaids for you if you like. If you have any lists of object positions (I've got lighthouses, wind farms, power stations, radio masts, and Ordnance Survey triangulation points in the database so far - but this only covers the UK) then I'd be happy to add them to the data I have and produce scenery object data for you. Jon, are you agreeable to getting this stuff into the downloadable scenery (that is, putting the models into the data tree and making their placement part of the TerraGear/scenery generation process)? Curt, are you? It would be cool to have this stuff in the scenery. On a related note: I have a copy of the FAA's Digital Obstruction File dated May 9, 2004, covering the U.S. and at least some of Canada. This document is released periodically (quarterly?); and as near as I can tell, is unencumbered by IP restrictions, although not released for free. I think it'd be very useful for improving the generic scenery in the U.S. Its contents look like this: NOS V LATITUDE LONGITUDE OBSTACLEAGL AMSL STROBE ACCUR MARK FAAACTION 308294 ST NO S ST CITY DEG MIN SECDEG MIN SECTYPE FREQ HT HT IND H V IND STUDY NO JDATE 284460 --- 300150 01-1307 O AL DAUPHIN ISLAND 30 10 45.00N 088 04 39.00W RIG0236 00236 R5 DY 90SO1578 C92125 235361 01-1472 O AL FORT MORGAN 30 11 20.00N 087 57 10.00W STACK 0193 00193 R5 DY 92SO2230 C96309 238951 01-1459 O AL DAUPHIN ISLAND 30 11 20.00N 088 07 15.00W RIG0240 00241 R5 DY 92SO2229 C93277 234894 01-2567 O AL GULF SHORES 30 13 49.00N 087 52 25.00W BLDG 0223 00242 R5 DN 00SO3180 CA4005 231225 01-2558 O AL GULF SHORES 30 13 49.00N 087 52 30.00W BLDG 0223 00242 R5 DN 99SO3256 CA4005 233277 01-2363 U AL FORT MORGAN 30 14 16.00N 087 52 01.00W TOWER 0300 00317 M N 00SO3108 AA0284 226782 01-1173 O AL DAUPHIN ISLAND 30 15 01.00N 088 04 45.00W TOWER 0201 00205 R5 DY 88SO2440 C89163 245470 01-1330 O AL DAUPHIN ISLAND 30 15 54.00N 088 07 32.00W RIG0186 00186 D5 EY 91SO0652 C91350 233927 01-0196 O AL FOLEY 30 16 46.00N 087 41 33.00W T-L TWR 2 0130 00140 N5 EY C84144 188870 01-2870 O AL ORANGE BEACH30 16 58.00N 087 35 04.00W TOWER 0155 00170 N2 CN 03SO0528 CA3341 239458 01-0291 O AL FOLEY 30 17 12.00N 087 36 23.00W TOWER 0300 00317 Y 66ME0248 D79163 212543 The obstruction types in the list are ARCH, BALLOON, BLDG, BLDG-TWR, BRIDGE, CATENARY, COOL TWR, CRANE, DOME, ELEVATOR, MONUMENT, OBSTACLE, PLANT, POLE, REFINERY, RIG, SIGN, SPIRE, STACK/STACKS, T-L TWR, TANK, TOWER/TOWERS, TRAMWAY, and WINDMILL. Some of these correspond to types of objects that Jon has spent a lot of time creating very nice looking models. I think this would help make scenery in the U.S. and Canada look a lot nicer with very little help. My good news for the new year is that I got a new job. While I'm employed, I'm willing to buy a copy of this file annually for TerraGear to use in object placement, and work on scripts to add to TerraGear to do it, if the interest is there. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpuZAeb06XMU.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
On Thu, 6 Jan 2005 13:13:19 +, Dave wrote in message [EMAIL PROTECTED]: Theres a great potential for abuse (don't forget e:mail will be listed in the FG Dev list archive.) ..those can be shown there as graphics rather than text etc. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Jon Stockill wrote: [...] If you've got a database handy I can send you a dump of the database I have so far. Are you talking about a database containing locations of already existing scenery objects ? I think if we use a database for maintaining object positions around the world we also should place the objects themselves into the database - otherwise you still have to maintain filesystem contents. I welcome every sort of insight in what you've already been collecting. I'm running Sybase and PostgreSQL (8.0pre4) databases, so if you have a dump available in some 'compatible' format I will have a look at it. Usually I'm happy to push everything into a database, so let's see, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery, plus an offer
Chris Metzler wrote: Jon, are you agreeable to getting this stuff into the downloadable scenery (that is, putting the models into the data tree and making their placement part of the TerraGear/scenery generation process)? Curt, are you? It would be cool to have this stuff in the scenery. There is no need to include it in the official release since we now have a Terrain directory and an Objects directory in the Scenery directory. This makes it easy to add additional objects after you have installed the Scenery Terrain. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery, plus an offer
On Thu, 06 Jan 2005 18:30:15 +0100 Erik Hofman wrote: Chris Metzler wrote: Jon, are you agreeable to getting this stuff into the downloadable scenery (that is, putting the models into the data tree and making their placement part of the TerraGear/scenery generation process)? Curt, are you? It would be cool to have this stuff in the scenery. There is no need to include it in the official release since we now have a Terrain directory and an Objects directory in the Scenery directory. This makes it easy to add additional objects after you have installed the Scenery Terrain. I don't mean the official release (although there where appropriate) so much as the downloadable scenery available at e.g. http://www.flightgear.org/Downloads/scenery.html . . .in other words, just as we have radio towers decorating the landscape, having cooling towers and might be good as well; and just as we have control towers and windsocks at airports, having checkerboarded buildings at the airport navaids locations might also look very nice. Yes, it's true that the stuff can (with some effort if you wanna do it globally) be downloaded and installed; but so could be the radio towers and the control towers and the windsocks and so forth. If we know that they're present, and we know their locations, and we have models for them, and it doesn't consume a lot of disk space to include them or bandwidth to download them, why not include them? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp3rt5yJ5hIW.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery
While messing around with my scripts for inserting objects into the scenery (it's now all database driven, with numerous datasets imported) I decided I could do with a few landmarks. Here's a couple of views of the first, also showing off the object positioning: http://flightgear.stockill.org.uk/models/ btw, I'm not sure if I've got the position slightly wrong, or if the river's in slightly the wrong place - I'll work it out later. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] scenery generation
hi all, I have been tring to crate new scenery for australia but have few problems. 1. it appears that fgfs-tools-client stops due to low memory, is it ment to not use the virtual memory ? 2. if it wont use the virtual memory how much is recommened ? 3. is there any information on the other tools, ie the src/Prep/ programs ? thanks jason ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Erik Hofman wrote: I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? I don't know how this scenery loading message/pause was implimented, but ... FlightGear can't load add-on 3d models (like the SFO buildings and bridges) inside the threaded scenery loader because the plib model loader functions are not thread safe in conjunction with opengl. So, FlightGear maintains a queue of models that need to be loaded and then loads them one per frame to interleave the work with rendering. This is extremely inefficient if we are waiting to load all the models. We should modify the code to simply load all the models in the queue (i.e. flush it) at startup, rather than doing one-per-frame and hacking around that with turn draw-otw=false. IMO that would be a *much* better solution. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Curtis L. Olson wrote: Erik Hofman wrote: I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? I don't know how this scenery loading message/pause was implimented, but ... FlightGear can't load add-on 3d models (like the SFO buildings and bridges) inside the threaded scenery loader because the plib model loader functions are not thread safe in conjunction with opengl. So, FlightGear maintains a queue of models that need to be loaded and then loads them one per frame to interleave the work with rendering. This is extremely inefficient if we are waiting to load all the models. We should modify the code to simply load all the models in the queue (i.e. flush it) at startup, rather than doing one-per-frame and hacking around that with turn draw-otw=false. IMO that would be a *much* better solution. I tried that, but it appeared that the queue is also filled at frame rate. So the queue can be quickly flushed but it will be filled as soon as we will render the first few frames. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Curtis L. Olson said: I don't know how this scenery loading message/pause was implimented, but ... The most recent changes from Fred work great. I made the original fix in order to correct the problems doing in air starts near KSFO before the release, without thinking about the frame rate issue. All it did was suspend FDM updates, so despite the observation that there was a delay, scenery was loading at the same rate it always did. snip We should modify the code to simply load all the models in the queue (i.e. flush it) at startup, rather than doing one-per-frame and hacking around that with turn draw-otw=false. IMO that would be a *much* better solution. This sounds pretty much like what the latest patch does. It just holds the splash screen up until the queues are flushed, rather than rendering the whole scene with a popup dialog. (The splash will also reappear during teleports). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery Loading
Hi, I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Hi, On Sonntag, 15. August 2004 12:00, Erik Hofman wrote: I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? Oh, yes please. I have locally disabled that whole machinery around that dialog just because it is unaccaptable to me to wait for about three minutes when I want to try something. So everything speeding up this would be good! Geetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Erik Hofman wrote: Hi, I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? This is my conclusion. Load time is framerate dependent. I am finishing a patch that will speedup this. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Mathias Fröhlich wrote: On Sonntag, 15. August 2004 12:00, Erik Hofman wrote: I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? Oh, yes please. I have locally disabled that whole machinery around that dialog just because it is unaccaptable to me to wait for about three minutes when I want to try something. So everything speeding up this would be good! If you use current CVS, you can set /sim/sceneryloaded-override to true to have the old behavior. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
On Sonntag, 15. August 2004 15:24, Frederic Bouvier wrote: So everything speeding up this would be good! If you use current CVS, you can set /sim/sceneryloaded-override to true to have the old behavior. Very good , thank you. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] scenery paging memory leak
Frederic Bouvier wrote : Durk Talsma wrote: The new scenery (the 0.9.5 release, downloaded using terrasync) Cheers, Durk On Sunday 18 July 2004 23:08, Frederic Bouvier wrote: Durk Talsma wrote: Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Euhhm, yes, I always have turned the real-weather option on by default. Are you using the old or the new Scenery. There was some changes in the animation code to support towers and beacons. It is too late here so I can't have a look right now, but I am thinking specifically of the class SGPersonalityBranch in personality.[ch]xx that stores data for each individual tower. I can't remember exactly but it occured to me that there could be a leak here, keeping states for unloaded towers, but I still have to remember how it was designed. I will look at it tomorrow if nobody beat me tonight. False alert : there is one personality branch for each instance of models and they are deleted by the decimation thread when the tile is unloaded. We must find something else. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery diff
Is there a scenery diff somewhere from 0.9.4 to 0.9.5-pre1, I don't really want to download the whole 80+Mb package again... Birger ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] scenery paging memory leak
Hey guys, Did we introduce a memory leak when paging scenery recently? I left FG running all night (with ATC and AI traffic disabled) and memory usage was stable. Then I went for 2-3 hour flight and just about filled up all my main RAM + Swap on my linux machine before I finally killed landed and exited. I know we were very careful when we set this all up to make sure memory usage was stable during scenery paging and that we didn't leak any memory, but something seems to have crept in along the way with one of the changes. The only thing I can remember recenly is support for terrain/object separation in the directory structure and some sort of simplistic state presorting when loading terrain. Could one of those things be doing this? Has anything else changed? This is not good if someone wants to do long flights Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Curt, I do remember seeing something similar happening, on a long haul test flight between Tokyo and Sydney, which judging from the timestamp on the scenery directory, I did around the 22nd of June. Same problem: Huge memory leak, up to the point where the aircraft became uncontrollable. I reran the same route the next day, and nothing happened. Weird. Anyways, hope that the date of my problem flight may be of any help finding this bug. Actually, I'm testing long range performance right now, doing a 10 hour KSFO to EHAM trip. Memory use appears to be rock solid. Cheers, Durk On Sunday 18 July 2004 21:05, Curtis L. Olson wrote: Hey guys, Did we introduce a memory leak when paging scenery recently? I left FG running all night (with ATC and AI traffic disabled) and memory usage was stable. Then I went for 2-3 hour flight and just about filled up all my main RAM + Swap on my linux machine before I finally killed landed and exited. I know we were very careful when we set this all up to make sure memory usage was stable during scenery paging and that we didn't leak any memory, but something seems to have crept in along the way with one of the changes. The only thing I can remember recenly is support for terrain/object separation in the directory structure and some sort of simplistic state presorting when loading terrain. Could one of those things be doing this? Has anything else changed? This is not good if someone wants to do long flights Thanks, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Durk Talsma wrote: I do remember seeing something similar happening, on a long haul test flight between Tokyo and Sydney, which judging from the timestamp on the scenery directory, I did around the 22nd of June. Same problem: Huge memory leak, up to the point where the aircraft became uncontrollable. I reran the same route the next day, and nothing happened. Weird. Anyways, hope that the date of my problem flight may be of any help finding this bug. Actually, I'm testing long range performance right now, doing a 10 hour KSFO to EHAM trip. Memory use appears to be rock solid. Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Erik On Sunday 18 July 2004 21:05, Curtis L. Olson wrote: Hey guys, Did we introduce a memory leak when paging scenery recently? I left FG running all night (with ATC and AI traffic disabled) and memory usage was stable. Then I went for 2-3 hour flight and just about filled up all my main RAM + Swap on my linux machine before I finally killed landed and exited. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Euhhm, yes, I always have turned the real-weather option on by default. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Durk Talsma wrote: Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Euhhm, yes, I always have turned the real-weather option on by default. Are you using the old or the new Scenery. There was some changes in the animation code to support towers and beacons. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
The new scenery (the 0.9.5 release, downloaded using terrasync) Cheers, Durk On Sunday 18 July 2004 23:08, Frederic Bouvier wrote: Durk Talsma wrote: Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Euhhm, yes, I always have turned the real-weather option on by default. Are you using the old or the new Scenery. There was some changes in the animation code to support towers and beacons. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Durk Talsma wrote: The new scenery (the 0.9.5 release, downloaded using terrasync) Cheers, Durk On Sunday 18 July 2004 23:08, Frederic Bouvier wrote: Durk Talsma wrote: Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Euhhm, yes, I always have turned the real-weather option on by default. Are you using the old or the new Scenery. There was some changes in the animation code to support towers and beacons. It is too late here so I can't have a look right now, but I am thinking specifically of the class SGPersonalityBranch in personality.[ch]xx that stores data for each individual tower. I can't remember exactly but it occured to me that there could be a leak here, keeping states for unloaded towers, but I still have to remember how it was designed. I will look at it tomorrow if nobody beat me tonight. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery search path behavior
I have noticed that with the new Scenery directory structure, FG does not look at mydir/Objects/w080n30/w077n38/1695792.stg unless it finds mydir/Terrain/w080n30/w077n38/1695792.stg. This seems a little broken. If I want to add some objects, I not only have to populate mydir/Objects/w080n30/w077n38, but I also have to put a copy of 1695792.stg and 1695792.gz.btg from the original scenery tree into mydir/Terrain/w080n30/w077n38, and then edit out all the towers and whatnot out of mydir/Terrain/w080n30/w077n38/1695792.stg so they don't get rendered twice, once for mydir and once for the global scenery. I should be able to just add a .stg file with one or two objects to an Objects dir in my private scenery path, have FG find and load those objects, then go on to the global scenery, find the .stg files there and load the terrain and objects from those. I also tried using an empty mydir/Terrain/w080n30/w077n38/1695792.stg but that seems to produce the same behavior. Also, I have not been able to find this logic in the source, it does not seem to be in Scenery. Can someone let me know where to find it? Fixing this logic is probably within my grasp, if I can just find it. Thanks, Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery problem at CYHM
Using today's scenery over TerraSync, I've found an interesting problem at CYHM (Hamilton, ON). Runway 12/30 is where it should be, but runway 06/24 is missing -- there is a big hole in the ground. When you try to start on runway 6, the plane starts up high in the clouds, presumably where the runway is floating. fgfs --airport=CYHM --runway=30 fgfs --airport=CYHM --runway=06 All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery problem at CYHM
On Fri, 18 Jun 2004 14:21:41 -0400 David Megginson [EMAIL PROTECTED] wrote: Using today's scenery over TerraSync, I've found an interesting problem at CYHM (Hamilton, ON). Runway 12/30 is where it should be, but runway 06/24 is missing -- there is a big hole in the ground. When you try to start on runway 6, the plane starts up high in the clouds, presumably where the runway is floating. I just checked this out. Actually, you're not high up in the clouds -- you're in the hole. It starts you with an altitude of 0 ASL; but since that's below local ground level you're in the hole. The AGL altitude is enormous -- around 33000 ft -- because that's how deep the hole is. To see this, take the UFO off of runway 30 and fly it across the hole. Watch your AGL altitude explode. I flew down the hole but didn't find ground at the bottom. Weirdness. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpmArZIoELXb.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery problem at CYHM
David, I think what you are describing is another problem introduced in Robin's latest scenery. For some airports that share the same name with other airports (San Carlos, Crystal, etc.) Robin somehow got multiple entries for the same airport in the database with the runways split between them (and usually the *other* airport with the same name sandwiched in between.) The problem is that the terragear airport generator names the airport scenery file according to apt. id, but in these cases the airport id occurs twice. I am eager to see these (and other) problems fixed in Robin's next data release. Regards, Curt. David Megginson wrote: Using today's scenery over TerraSync, I've found an interesting problem at CYHM (Hamilton, ON). Runway 12/30 is where it should be, but runway 06/24 is missing -- there is a big hole in the ground. When you try to start on runway 6, the plane starts up high in the clouds, presumably where the runway is floating. fgfs --airport=CYHM --runway=30 fgfs --airport=CYHM --runway=06 All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery problem at CYHM
Curtis L. Olson wrote: The problem is that the terragear airport generator names the airport scenery file according to apt. id, but in these cases the airport id occurs twice. I am eager to see these (and other) problems fixed in Robin's next data release. Thanks, Curt -- I took at look at the file, and that's exactly what happened. Given all of the problems in this release of Robin's data -- messed-up runways, hundreds of missing ILS approaches, etc. -- we might want to consider reverting to the previous version until his new system has a chance to stabilize. Have you informed Robin of the problem, or should I drop him a note? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery problem at CYHM
David Megginson wrote: Thanks, Curt -- I took at look at the file, and that's exactly what happened. Given all of the problems in this release of Robin's data -- messed-up runways, hundreds of missing ILS approaches, etc. -- we might want to consider reverting to the previous version until his new system has a chance to stabilize. Have you informed Robin of the problem, or should I drop him a note? I've reported several problems, but nothing relating to this specific airport. Hearing problem reports from multiple sources can't hurt though. Supposedly the next data release is due out real soon now, so I'm a little hesitant to revert, especially since I did a bunch of new coding to support his data format more directly ... a lot of that code would need to also be reverted which wouldn't be a pretty site at this point. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
Matthew Law wrote: That's pretty good scenery! Is that straight from TerraGear or ripped from the MS Scenery add-ons? As I understand it it's a commercial CD containing satellite images of the UK, but processed with TerraGear to match FlightGear's own scenery format. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
As I understand it it's a commercial CD containing satellite images of the UK, but processed with TerraGear to match FlightGear's own scenery format. Maybe the simscreens postings should credit the source and acknowledge the copyright? Mally --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/04 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
Mally wrote: As I understand it it's a commercial CD containing satellite images of the UK, but processed with TerraGear to match FlightGear's own scenery format. Maybe the simscreens postings should credit the source and acknowledge the copyright? At least mentioning that it uses textures based on a commercial product would have been nice. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
On Thu, 2004-01-29 at 08:44, Erik Hofman wrote: Matthew Law wrote: That's pretty good scenery! Is that straight from TerraGear or ripped from the MS Scenery add-ons? As I understand it it's a commercial CD containing satellite images of the UK, but processed with TerraGear to match FlightGear's own scenery format. I forget the name of the CD, but I've seen these in a games shop recently. The do the entire UK as several sets, and also the major airports in high detail. I didn't know if they'd work with fgfs, I might invest in a copy now. I believe it was something to do with the millenium mapping project (some of the photographing flights were flown from my home airport - a couple minutes away from my parents house). Chris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery
Hi, I must admit I've been a long standing fan of tiled scenery like we use right now. It needs some attention but the goal is my favorite. But I must also admit that after looking at the new screen shots from Mat Churchill I might want to change my mind: html http://www.simscreens.net/index.php?sub=categoriespt=al=cntr=sim=14motif=type=keyword=cnt=15sort=1from=0static=yesempty=yes /html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
That's pretty good scenery! Is that straight from TerraGear or ripped from the MS Scenery add-ons? All the best, Matt. On 23:31 Wed 28 Jan , Erik Hofman wrote: But I must also admit that after looking at the new screen shots from Mat Churchill I might want to change my mind: html http://www.simscreens.net/index.php?sub=categoriespt=al=cntr=sim=14motif=type=keyword=cnt=15sort=1from=0static=yesempty=yes /html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery testing
Curtis L. Olson wrote: Can we double the power, add some animation, and perhaps more loosely couple the power plants? Now is when we really could use the ability to drop ordinance. I don't have the POH in front of me, but I would think that those particular engines would certainly need to expel spent fuel now and then. That was my initial intention, but I'm not sure I can get that working in time. Although I must say that the new interpolation animation from Andy might come in handy now ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery testing
I've just been having a look at some of the new airports I've generated, and I've noticed an error with the new ufo model - the great big red anti-collision light from the front is missing ;-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery testing
Jon Stockill wrote: I've just been having a look at some of the new airports I've generated, and I've noticed an error with the new ufo model - the great big red anti-collision light from the front is missing ;-) Heh, I noticed that too recently. I was mostly busy doing other stuff today, I'll see if I can get it updated soon. If some one else feels like doing some updates to it, then don't hessitate to do so. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery testing
Erik Hofman writes: Jon Stockill wrote: I've just been having a look at some of the new airports I've generated, and I've noticed an error with the new ufo model - the great big red anti-collision light from the front is missing ;-) Heh, I noticed that too recently. I was mostly busy doing other stuff today, I'll see if I can get it updated soon. If some one else feels like doing some updates to it, then don't hessitate to do so. Can we double the power, add some animation, and perhaps more loosely couple the power plants? Now is when we really could use the ability to drop ordinance. I don't have the POH in front of me, but I would think that those particular engines would certainly need to expel spent fuel now and then. Regards, Curt. (Unless you are the lead dog, the view never changes) -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Curtis L. Olson writes: Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. Norman Vine writes: - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile It's easy to chop up polygons on tile boundaries, but you are probably referring to airport areas. :-) I am referring to any polygon whether or not they are part of an airport area is immaterial :-) This has been discussed before and I do appreciate the 'pain' factor on the construction side of things but having to special case airports to cross tile boundaries is a killer when it comes to subdivision and or indexing schemes. - Ability to page terrain / textures so continuous flights around the world are still possible. :-) I only say this because I've seen a lot of ROAM type demos that look cool for a small area, but I get the sense that it's a bit trickier to build an entire seamless earth. It's probably been done in commercial games (?) but I haven't seen this done in the open souce world. Hence my smiley, also I am not convinced that FGFS should adbandon using pretesselated scenery in favor of a ROAM approach. This doesn't necessarily mean that we can't have scenery LOD though Modeling the entire world is a good way to keep yourself honest. :-) You are preaching to the choir here :-) I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler We have to be careful though of objects floating up and down noticable as the underlying terrain LOD changes. Yes and the Local Z simplification really only applies to ROAM like tesselations not TINs We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. My understanding is that roads, rivers, lakes, cities, etc. (all that stuff we handle with 2d polygons right now) could be embedded in the aerial photos / textures that we are draping over the terrain, so there would be no need to cut them in as polygons. I am not necessarily suggesting a ROAM approach as the data requirements are humongous both for the textures and the elevations. What I think would be most beneficial is to write an abstract interface for terrain first so that the actual mechanism used is not exposed to the rest of the SIM. What we have is a good start on this. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery engine features.
I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery engine features.
Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : I'll add in a few things: - Ability to cut in polygon models of airports. - Ability to page terrain / textures so continuous flights around the world are still possible. - Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world. - Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes. - I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway. I bet we'll run into other things, but if you are serious about making a stab at this, then I will propose that we a) find a way to do it in parallel to the current system and b) just jump in and start going. I don't think it's realistic to have your first pass encapsulate *all* current functionality of the scenery subsystem. And there will most likely be things we don't consider until we get hit over the head with it. I can think of different situations where each approach would be more optimal than the other, so it probably wouldn't hurt to have more than one way to do things. Best regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Curtis L. Olson writes: Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I'll add in a few things: me too - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile - Ability to page terrain / textures so continuous flights around the world are still possible. :-) - Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world. I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler - Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes. - I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway. We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery engine features.
On 11/14/03 at 12:17 AM Paul Surgeon wrote: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : The ability to drape the textures at differing resolutions at different locations in the scenery. (ie. higher res data immediately adjacent to airports where the pilot is generally closer to the ground and to give good definition on final approach). Some sort of fix or workaround for the stretched-textures-on-cliff faces problem that draped textures suffer from in mountainous regions - possibly the ability to cut in textured polygons on steep faces. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. Norman Vine writes: - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile It's easy to chop up polygons on tile boundaries, but you are probably referring to airport areas. :-) - Ability to page terrain / textures so continuous flights around the world are still possible. :-) I only say this because I've seen a lot of ROAM type demos that look cool for a small area, but I get the sense that it's a bit trickier to build an entire seamless earth. It's probably been done in commercial games (?) but I haven't seen this done in the open souce world. Just a word of advice ... if you are building a scheme and run across some oversite and are tempted to think, what are the chances of seeing this case in real life. Believe me, when you throw all the data of the world at your scheme, you'll see it a lot more than you expected. :-) Modeling the entire world is a good way to keep yourself honest. :-) I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler We have to be careful though of objects floating up and down noticable as the underlying terrain LOD changes. We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. My understanding is that roads, rivers, lakes, cities, etc. (all that stuff we handle with 2d polygons right now) could be embedded in the aerial photos / textures that we are draping over the terrain, so there would be no need to cut them in as polygons. Airports are a bit different though ... unless we have *really* high res data as in less than 1 foot per pixel, we'll want to still model this polygonally. The San Jose demo was interesting, but it still needed better resolution. Just one airport area could easily consume a Gb of texture ram if we wanted to use a nice resolution. But that still wouldn't address all the squashed buildings, and all the nice aircraft painted on the runways in various stages of taxiing, landing, and taking off. Also, you get everything shaded from one particular time of day. There are tradeoff's to every approach. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery file format
Is there any documentation on the binary scenery file format and how FlightGear/SimGear renders the terrain? I've searched through all the docs and have not found anything. And no the doxygen docs are not helping me at all - doxygen does not explain the logic used in the terrain rendering. Is it a tile based sim? Is it using regular grid or irregular grid model? I presume that one can tie ground texture co-ords to vertices's in FG otherwise the aerial photos I have seen in FG would not be possible. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery file format
Paul Surgeon writes: Is there any documentation on the binary scenery file format and how FlightGear/SimGear renders the terrain? I've searched through all the docs and have not found anything. The scenery docs are a little skimpy but maybe this will help get you started outdated but still essentially correct http://www.flightgear.org/Docs/Scenery/SceneryGeneration/SceneryGeneration.html as far as the binary format goes the best doc is probabably the source SimGear / simgear / io / decode_binobj.cxx and sg_binobj.hxx It is a very straightforward binary representation of our earlier ASCII format which was *very* similar to a subset of the WaveFront .obj 3D format http://astronomy.swin.edu.au/~pbourke/geomformats/obj/ HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery file format
Thanks, that helps a bit. Paul On Saturday, 8 November 2003 15:07, Norman Vine wrote: Paul Surgeon writes: Is there any documentation on the binary scenery file format and how FlightGear/SimGear renders the terrain? I've searched through all the docs and have not found anything. The scenery docs are a little skimpy but maybe this will help get you started outdated but still essentially correct http://www.flightgear.org/Docs/Scenery/SceneryGeneration/SceneryGeneration. html as far as the binary format goes the best doc is probabably the source SimGear / simgear / io / decode_binobj.cxx and sg_binobj.hxx It is a very straightforward binary representation of our earlier ASCII format which was *very* similar to a subset of the WaveFront .obj 3D format http://astronomy.swin.edu.au/~pbourke/geomformats/obj/ HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery mirrors
The http mirrors of FG are all straight mirrors of the master site, as are the ftp mirrors. Hence the graphical scenery download page on the http mirrors points back to the master site. Hence it's impossible to download scenery from the ftp mirrors using the graphical interface. It seems to me it might be worth tweaking the http mirror's graphical download page to point to the corresponding ftp mirror if available? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery mirrors
On Wed, Oct 15, 2003 at 12:36:26PM +0100, David Luff wrote: The http mirrors of FG are all straight mirrors of the master site, as are the ftp mirrors. Hence the graphical scenery download page on the http mirrors points back to the master site. Hence it's impossible to download scenery from the ftp mirrors using the graphical interface. It seems to me it might be worth tweaking the http mirror's graphical download page to point to the corresponding ftp mirror if available? This is one of the reasons that relative links are a good idea. As a made up example, a link from http://gnucash.org/en/contribute.phtml to http://gnucash.org/pub/gnucash/sources/stable/ should use a href=../pub/gnucash/sources/stable/ instead of a href=http://gnucash.org/pub/gnucash/sources/stable/; As an aside, it is a good idea to include the final slash when linking a directory. It removes the need for a redirect. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery mirrors
James A. Treacy writes: This is one of the reasons that relative links are a good idea. As a made up example, a link from http://gnucash.org/en/contribute.phtml to http://gnucash.org/pub/gnucash/sources/stable/ should use a href=../pub/gnucash/sources/stable/ instead of a href=http://gnucash.org/pub/gnucash/sources/stable/; As an aside, it is a good idea to include the final slash when linking a directory. It removes the need for a redirect. The difficulty for us is that our web and ftp trees are on separate machines. They aren't even on the same server. Our ftp tree is about 13Gb, our web site is about 100Mb. If we merged all the ftp data in with the web site, we'd kill all our mirrors. I strongly suspect that gnucash can get away with their scheme because their disk space usage is far less than ours. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
