Re: [Flightgear-devel] Next scenery rebuild.
Josh Babcock wrote: Curtis L. Olson wrote: Jon Stockill wrote: Curtis L. Olson wrote: SNIP It still would be really nice though to be able to place objects at ground level at load time too. Regards, Curt. When this happens, it would be nice to see some cycles dedicated to the problem of slope. A ranch house looks pretty silly hanging out on a 30 deg slope with its foundation exposed. On the other hand, I have seen many buildings in the real world that have ground entrances on floors that are 2, 3 or even 4 floors apart vertically. This would require special building models divided into sets as well as data assigned to each model regarding how it should be oriented on the slope. I'm not sure how this applies to the great guyed antennas up on the hill by KSFO, but they also exhibit a similar problem. It is also worth thinking about this if anyone ever decides to models a set of generic bridges that can be automatically placed. Speaking of which, imagine the following. First, a DB with all the known antenna locations and heights in it. For giggles, let's generate a data set of bridges from our scenery data, and if it's available, dump some pre-existing data-set of water towers in there. Make some sweepingly broad generalizations about what these objects would look like based on their country of residence and assign those values as a base case. Now build a web interface that lets joe FGFS pilot and expert on his home town go browse and add an entry to any of those objects classifying it as looking like this or that type of bridge/tower/tank in that general color scheme. Joe pilot can also, on the honor system, specify a score of how sure he is about the data he is supplying (guess/pretty sure/it's in my back yard). Advertise it. Build a few dozen simple models of various generic types in said color schemes. Now take all that data and feed it into some process to place the right (ie highest scored) generic object at the right set of coords. A little bit of coding, a DB, a web site and some distributed observation and the FG world becomes a much better approximation of the real one. Of course, it would take a while to reap the benefits, but if it is set up with an eye for longevity it will just become more and more valuable as more people add data. You'll find plenty of suitable data in VMAP0. I've tried adding power lines to scenery (well, the pylons, not the wires, although I suspect modeling those would keep the helicopter pilots on their toes) and it really does make a difference - makes navigation easier for a start - you can just follow the pylons all the way to the power station. Adding these things currently involves an awful lot of work though. FGSD provides one solution, but seems to like to segfault on my local scenery, so it's not really an option here. I'm perfectly happy to generate this kind of data - I'd just like to know it's going to be some use before I start. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Jon Stockill wrote: Curtis L. Olson wrote: SNIP It still would be really nice though to be able to place objects at ground level at load time too. Regards, Curt. When this happens, it would be nice to see some cycles dedicated to the problem of slope. A ranch house looks pretty silly hanging out on a 30 deg slope with its foundation exposed. On the other hand, I have seen many buildings in the real world that have ground entrances on floors that are 2, 3 or even 4 floors apart vertically. This would require special building models divided into sets as well as data assigned to each model regarding how it should be oriented on the slope. I'm not sure how this applies to the great guyed antennas up on the hill by KSFO, but they also exhibit a similar problem. It is also worth thinking about this if anyone ever decides to models a set of generic bridges that can be automatically placed. Speaking of which, imagine the following. First, a DB with all the known antenna locations and heights in it. For giggles, let's generate a data set of bridges from our scenery data, and if it's available, dump some pre-existing data-set of water towers in there. Make some sweepingly broad generalizations about what these objects would look like based on their country of residence and assign those values as a base case. Now build a web interface that lets joe FGFS pilot and expert on his home town go browse and add an entry to any of those objects classifying it as looking like this or that type of bridge/tower/tank in that general color scheme. Joe pilot can also, on the honor system, specify a score of how sure he is about the data he is supplying (guess/pretty sure/it's in my back yard). Advertise it. Build a few dozen simple models of various generic types in said color schemes. Now take all that data and feed it into some process to place the right (ie highest scored) generic object at the right set of coords. A little bit of coding, a DB, a web site and some distributed observation and the FG world becomes a much better approximation of the real one. Of course, it would take a while to reap the benefits, but if it is set up with an eye for longevity it will just become more and more valuable as more people add data. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Here's something I think would be handy: Build some offline tool that could load a couple thousand (lat, lon) pairs, then return a list of flightgear scenery elevations for all those points. It would have to traverse the input list of points and load the corresponding scenery tiles and do the ground intersection. Probably some attention should be paid to minimizing tile loads. That's pretty much what I had in mind - something like calc-tile.pl, but with the ability to retrieve the scenery and find the ground elevation. Unfortunately I'm a sysadmin who likes playing with geodata, not a programmer. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set We could still build that from the higher-resolution set by sampling. - SRTM data doesn't cover the entire earth ... They never flew past +/- 6x degrees latitude (where x is a number I don't recall ... greater than 0 but less than 9.) - SRTM isn't released yet for australia. Here are the details: http://www2.jpl.nasa.gov/srtm/coverage.html These are good reasons, but they suggest keeping around the older DEM stuff only where SRTM isn't available. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Josh Babcock wrote: I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set While 2 and 3 sound like very good points, does it make more sense for 1 to use the high res data but process it so that the end result is small? That way you could still exceed the lower resolution for really bumpy parts of the world, and still have great big polys for the majority of the world, which is basically flat. In other words, you can always reduce a data set, but usually you can't increase it. Also, though I haven't worked with TerraGear, I suspect that for a given size of desired output it would produce higher quality scenery as the size of the input data set grows. Is this the case? I ask this not as a criticism, but because I'm curious. You make a good point. I think in the end the answer of which data sets to use (or which data sets could potentially be used) depends on the priorities of the scenery builder and their target application. 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] Next scenery rebuild.
Jon Stockill wrote: Curtis L. Olson wrote: Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. That's why I didn't want to do it at load time, but at generation time - maybe generate the scenery, then have a master list of object positions and model names which can then be added to the appropriate stg files. Here's something I think would be handy: Build some offline tool that could load a couple thousand (lat, lon) pairs, then return a list of flightgear scenery elevations for all those points. It would have to traverse the input list of points and load the corresponding scenery tiles and do the ground intersection. Probably some attention should be paid to minimizing tile loads. I haven't sat down to do something like this, but I could get some mileage out of such a tool if it existed. It still would be really nice though to be able to place objects at ground level at load time too. 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] Next scenery rebuild.
Curtis L. Olson wrote: Jon Stockill wrote: Make sure the tools aren't finding a lower res data set before the higher res set ... Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set While 2 and 3 sound like very good points, does it make more sense for 1 to use the high res data but process it so that the end result is small? That way you could still exceed the lower resolution for really bumpy parts of the world, and still have great big polys for the majority of the world, which is basically flat. In other words, you can always reduce a data set, but usually you can't increase it. Also, though I haven't worked with TerraGear, I suspect that for a given size of desired output it would produce higher quality scenery as the size of the input data set grows. Is this the case? I ask this not as a criticism, but because I'm curious. Josh - SRTM data doesn't cover the entire earth ... They never flew past +/- 6x degrees latitude (where x is a number I don't recall ... greater than 0 but less than 9.) - SRTM isn't released yet for australia. I'd think that most poeple could chuck the lower res data for which they have good SRTM coverage though ... I managed to track it down in genapts eventually - it seems to use the airfield surface it generates, so I guess it wouldn't be easy to generalise for placing scenery objects. Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. That's why I didn't want to do it at load time, but at generation time - maybe generate the scenery, then have a master list of object positions and model names which can then be added to the appropriate stg files. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Roger Andreassen wrote: Sorry to barge in, I have to strange ones: ENDU and ENNK. Has the above mention something to do with these? A big part of the problem with these is that the underlying DEM data is probably not very good for these areas. There is a lot of elevation change in the terrain data over the surface of the airport and that is hard to deal with cleanly. Also, mix in that we flatten oceans and do a bit of massaging of river elevations to try to avoid them running up and down hills. This sometimes mixes badly if a river or stream incorrectly runs through the airport area due to lack of precision in the stream data. I'd like to handle these cases better in the future, but it will take some work and some thought. Again, I'm being selfish by keeping it domestic: I miss Bodø and Svalbard (Longyearbyen), ENBD and ENSB respectively. Is an airport gone in Robin's database does it mean there's no chance to output the scenery? If these are incorrectly missing in his database (especially if they previouisly existed) then please email Robin. He should be due for another data release soon, although I don't know how his own schedule or time constraints are these days. If it's in early stages I'd like to air ideas as they pop up. Thanks for the time and effort put into this, just *wow*. Feel free, ideas are easy. I can always ignore the one's I don't like. :-) Does anyone know how this compares to MS Flightsim's scenery? I know that for the Norwegian fjords they have to build "stairs" near mountains, that means in the bottom of a fjord the sealevel was at 300 ft in the old days (gone days). I know FlighGear is different but just how different, to a non-geek like me. :-) We force oceans to be zero elevation and make the surrounding scenery fit. This usually works pretty well with few artifacts. For what it's worth, the new high quality 3-arcsec SRTM data covers the southern part of norway, but not the northern part. I'm not sure where the cut off is, but there was a limit in how far north the shuttle orbit took them. 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] Next scenery rebuild.
Jon Stockill wrote: Make sure the tools aren't finding a lower res data set before the higher res set ... Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set - SRTM data doesn't cover the entire earth ... They never flew past +/- 6x degrees latitude (where x is a number I don't recall ... greater than 0 but less than 9.) - SRTM isn't released yet for australia. I'd think that most poeple could chuck the lower res data for which they have good SRTM coverage though ... I managed to track it down in genapts eventually - it seems to use the airfield surface it generates, so I guess it wouldn't be easy to generalise for placing scenery objects. Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. 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] Next scenery rebuild.
Curtis L. Olson wrote: It's automatic, but it is done by Robin for airports that don't have specific taxiways as he builds the data file. OK, so it'll be overwritten as updates are committed. Make sure the tools aren't finding a lower res data set before the higher res set ... Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. Right now it just places them in airport environments ... the floating wind socks are on my todo list to fix ... I managed to track it down in genapts eventually - it seems to use the airfield surface it generates, so I guess it wouldn't be easy to generalise for placing scenery objects. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Jon Stockill wrote: I've not had chance to look at the runways file yet, but are the taxiways automatically generated if none are available in the file? It seems there's a generic parallel taxiways with exit points at both ends and the centre added to all the runways. If it's automatic, I'll ignore it, if it's been added to the runways file then I can provide a few corrections. It's automatic, but it is done by Robin for airports that don't have specific taxiways as he builds the data file. The terrain seems far better than the scenery I've been generating - and is presumably from the same source data - this may be due to the chopping of long polys - I'm compiling a current terragear checkout now to see if that's what makes the difference - if not I'll be after your settings for terrafit/arrayfit :-) Make sure the tools aren't finding a lower res data set before the higher res set ... The code that places the windsocks seems to occasionally leave them floating a few feet off the ground, although most seem fine. Is the code used for placing them only suitable for use within the airfield boundary, or could it be used for placing static objects too? Right now it just places them in airport environments ... the floating wind socks are on my todo list to fix ... Amazing effort Curt - this makes the old scenery look positively prehistoric. Thanks, I've got most of the northern hemisphere done now and am starting on the southern hemisphere. 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] Next scenery rebuild.
Curtis L. Olson wrote: Here's a quick status update on my efforts to update the world scenery build. It looks fantastic. I've not had chance to look at the runways file yet, but are the taxiways automatically generated if none are available in the file? It seems there's a generic parallel taxiways with exit points at both ends and the centre added to all the runways. If it's automatic, I'll ignore it, if it's been added to the runways file then I can provide a few corrections. The terrain seems far better than the scenery I've been generating - and is presumably from the same source data - this may be due to the chopping of long polys - I'm compiling a current terragear checkout now to see if that's what makes the difference - if not I'll be after your settings for terrafit/arrayfit :-) The code that places the windsocks seems to occasionally leave them floating a few feet off the ground, although most seem fine. Is the code used for placing them only suitable for use within the airfield boundary, or could it be used for placing static objects too? Amazing effort Curt - this makes the old scenery look positively prehistoric. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next scenery rebuild.
- There should no longer be any wildly oscillating runway surfaces. - There should be no runway surfaces with abrupt cliffs in them. Sorry to barge in, I have to strange ones: ENDU and ENNK. Has the above mention something to do with these? - We have added beautifully modeled rotating beacons, wind socks, and control towers to most airports that have them. The location of these items are stored in Robin's database, so if the position of these items are wrong, we can submit fixes for them. Again, I'm being selfish by keeping it domestic: I miss Bodø and Svalbard (Longyearbyen), ENBD and ENSB respectively. Is an airport gone in Robin's database does it mean there's no chance to output the scenery? If it's in early stages I'd like to air ideas as they pop up. Thanks for the time and effort put into this, just *wow*. - In the new build I have chopped up long polygon edges so that they can follow the underlying terrain shape much better. Now we can have land cover divisions (or roads) through complex terrain without adding unsightly artifacts. In the process of doing this work, I found/fixed a couple bugs in our polygon handling. Does anyone know how this compares to MS Flightsim's scenery? I know that for the Norwegian fjords they have to build "stairs" near mountains, that means in the bottom of a fjord the sealevel was at 300 ft in the old days (gone days). I know FlighGear is different but just how different, to a non-geek like me. :-) Does anyone know how this compares to MS Flightsim's scenery? I know that for the Norwegian fjords they have to build "stairs" near mountains, that means in the bottom of a fjord the sealevel is 300 ft or more. I know FlighGear is different but just How Different, to a non-geek like me. :-) Btw here's the best footage I could find of the control tower at ENGM. I think they looked at something else. ;-) http://www1.airpics.com/viewclean.php?imgid=34462 Regards, Roger Andreassen (norsk) _ MSN Messenger http://www.msn.no/messenger Den korteste veien mellom deg og dine venner ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
On Monday 24 May 2004 16:59, Erik Hofman wrote: > Curtis L. Olson wrote: > > Here's a quick status update on my efforts to update the world scenery > > build. > > > > FWIW, I have been leaving updated notices on my home page for people > > that want more frequent or detailed updates on my progress: > > > >http://www.flightgear.org/~curt > > > > > > I believe I have now completed all my required "prep" work and am about > > ready to launch into a full blown world scenery build. > > A big Hooray for Curtis who has put so much work into this. > > Erik I'd like to second that - well done Curt. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Yep. It is very, very likely that I am going to help Chris on the scenery for the airports... after I am finished with the MD. Regards, Ampere On May 24, 2004 02:07 pm, Curtis L. Olson wrote: > Custom towers should be doable. We may need to do a little work to > think about the best way to handle this, but if you or others are > willing to spend the time creating the models, then we definitely need > to figure out how to easily incorporate them. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
On Mon, 24 May 2004 13:07:06 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > Chris Metzler wrote: >> >> The database that came with 0.9.4 had taxiways mainly just for big >> airports. Will this updated database have them for many smaller >> airports as well? I ask because I've been using David Luff's >> TaxiDraw to make taxiways for the smaller airports in the default >> area in hopes of contributing that work; but if that's not useful, >> I'll do something else. > > The standard answer to this is that you should submit any and all > taxiway updates to Robin Peel in "X-Plane" format for inclusion in his > database. Then they will (should?) get included in flightgear after his > > next data release. This is not well tested, but I look forward to > future success stories once we start contributing taxiway data in > "X-Plane" format. Right (although I've been told to hold off just yet, because there's no easy way to put our stuff in X-Plane format now). But what I'm wondering is what the contents of the database he's got now are, so that I don't duplicate effort. Put another way, is the most-current runways.dat, with the data that'll be incorporated into this scenery build, available in CVS? If so, I can compare it to the current one, see what airports have had taxiways added, and hold off on doing those ones. Thanks, -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 pgpKdrK4v0rr3.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Chris Metzler wrote: This all sounds extremely, extremely cool. Thanks for all the effort you've put into this. I have a couple of questions: Will these still be in separate .ac files, so that they can be replaced if desired? As I learn blender, one thing I've wanted to do (and make available to others) is make distinctive control towers that look like the ones at specific airports, e.g. http://www.npr.org/news/specials/americatransformed/photos/national.tower.jpg http://www.grahametaylor.com/gallery/americasept02/images/America_Sept_2002_0227.JPG Custom towers should be doable. We may need to do a little work to think about the best way to handle this, but if you or others are willing to spend the time creating the models, then we definitely need to figure out how to easily incorporate them. The database that came with 0.9.4 had taxiways mainly just for big airports. Will this updated database have them for many smaller airports as well? I ask because I've been using David Luff's TaxiDraw to make taxiways for the smaller airports in the default area in hopes of contributing that work; but if that's not useful, I'll do something else. The standard answer to this is that you should submit any and all taxiway updates to Robin Peel in "X-Plane" format for inclusion in his database. Then they will (should?) get included in flightgear after his next data release. This is not well tested, but I look forward to future success stories once we start contributing taxiway data in "X-Plane" format. 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] Next scenery rebuild.
On Mon, 24 May 2004 10:34:03 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > Here's a quick status update on my efforts to update the world scenery > build. [ snip ] This all sounds extremely, extremely cool. Thanks for all the effort you've put into this. I have a couple of questions: > - We have added beautifully modeled rotating beacons, wind socks, and > control towers to most airports that have them. The location of these > items are stored in Robin's database, so if the position of these items > are wrong, we can submit fixes for them. Will these still be in separate .ac files, so that they can be replaced if desired? As I learn blender, one thing I've wanted to do (and make available to others) is make distinctive control towers that look like the ones at specific airports, e.g. http://www.npr.org/news/specials/americatransformed/photos/national.tower.jpg http://www.grahametaylor.com/gallery/americasept02/images/America_Sept_2002_0227.JPG > - Robin has made many updates to his airport database which will be > reflected in this new build. This will be most noticable in terms of > many new/corrected taxiways as well as the beacons, windsocks and towers > > mentioned earlier. The database that came with 0.9.4 had taxiways mainly just for big airports. Will this updated database have them for many smaller airports as well? I ask because I've been using David Luff's TaxiDraw to make taxiways for the smaller airports in the default area in hopes of contributing that work; but if that's not useful, I'll do something else. Thanks very much again; I'm really looking forward to the new scenery. -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 pgpM2WBD6p8JD.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Here's a quick status update on my efforts to update the world scenery build. FWIW, I have been leaving updated notices on my home page for people that want more frequent or detailed updates on my progress: http://www.flightgear.org/~curt I believe I have now completed all my required "prep" work and am about ready to launch into a full blown world scenery build. A big Hooray for Curtis who has put so much work into this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel