Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Thu, 20 May 2004 12:45:51 +0100 "David Luff" <[EMAIL PROTECTED]> wrote: > On 5/17/04 at 12:58 PM Chris Metzler wrote: >> >> At any rate, as far as manually placing them and putting that >> capability in TaxiDraw, sure, that'd be cool! In the short-term, >> though, I have another request: a scrollbar slider for the taxiway >> list brought up with the "z" key. >> > > You can use numpad 9 and 3 to scroll the list up and down. (Numpad 8 > and 2 move a selected taxiway up and down in the order). I agree it's > not very intuitive though - I'll try and put in a proper list control > with automatic scroll bar for the next release. That's good, though. Thanks. >> Incidentally, this long list is an illustration of why #2, above, >> might be a good idea in general; would Robin Peel really want those >> 117 small taxiways put in purely for aesthetic reasons? >> > > I'm not entirely sure where the acceptable number of segments / amount > of detail trade-off will end up. Jon Stockill has done some very > detailed UK military layouts with hundreds of segments to show all the > dispersal areas, but I don't think he's submitted them yet. So far the > airports I have done haven't had more than about 100 segments, less than > some of the default ones. I deliberately avoided KSQL after seeing the > massive extra aprons on the aerial photos! Hopefully what is acceptable > to Robin in terms of number of segments vs. detail vs. accuracy will > become more clear after I get some X-Plane export filters in and users > start submitting in a format he can accept. Well, for the purposes of getting more stuff in the default area into CVS, and with the possibility that "aesthetic" taxiways might be handled differently (e.g. put in a separate file, or given a separate identifier than "T" so that it's excluded from export filters if necessary, can be acted on to produce curved taxiway lines, etc.), maybe it makes the most sense for me to just forego rounding interesections right now, and instead just get the taxiways and aprons put in place for places I work on? I can always go back and add the curvature (since playing with KSQL, I know I can do it OK), and by that point maybe we'll have settled on how to treat the additional stuff? Of course, I have no idea how to handle KPAO in either case -- its main feature is a large circular apron for a parking area, with a circular taxiway running its circumference. >> Perhaps a better way of handling curved intersection corners would >> be to generate for each intersection a set of four boolean flags >> indicating whether or not that corner should be rounded, and let >> TerraGear round the corners when it puts the taxiways into the scenery? >> But I bet that requires hard work on their part, so maybe not such a >> good idea. > > > It's a good idea, but as you say requires a lot coding in TerraGear as > well. Better handling of taxiway/taxiway and taxiway/runway > intersections is something that's been mulling in the back of my mind > for ages, but realistically I haven't got a chance of finding time to > work on it in the foreseeable future. I understand. At this point, I think the biggest reason I wish I could code (well, in something other than FORTRAN or the bash shell) is because it's gotta be a bit annoying to people in a project for other people (like me) to come in with ideas for *them* to implement. "Wouldn't X be cool? Why don't you go do X?" [ Two quotes from you ] > There's lots of room for improvement to the airport modelling. I > guess > that ultimately artistic orientated folk will start doing custom > scenery > for certain areas, rather than relying on the automated processing > of > compiled data as we do at the moment. [ snip ] > I hope > that eventually people will start making detailled representations of > their local areas available, in a similar manner to MSFS scenery > designers. Part of MSFS' success at having so many people developing aircraft liveries and a huge quantity of landmarks, accurate airport structures, traffic patterns and gate usage, etc., (seen e.g. in all the stuff on http://www.avsim.com/ and http://www.flightsims.com/ ) is doubtless based on the number of people running it. But I also wonder if another reason is that it's fairly well facilitated. The infrastructure is there, and it's straightforward to use it. My understanding (but I'm not sure; haven't run any MS software since the 80s) is that the software one uses for creating and adding such stuff comes with MSFS, and that the procedure for how to create stuff and how to insert it into the existing scenery/AI/etc. is well-documented. There's little sense of "this is going to take a lot of work just to figure out what *to* do, before actually doing it." And when you've got something you're happy with, there are those websites to make it available to other people, be inspired by what others have done, etc. We hav
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
"Ampere K. Hardraade" said: > Are we using spline for the taxi way at the moment? > No we are not. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Are we using spline for the taxi way at the moment? Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
David Luff wrote: I'm not entirely sure where the acceptable number of segments / amount of detail trade-off will end up. Jon Stockill has done some very detailed UK military layouts with hundreds of segments to show all the dispersal areas, but I don't think he's submitted them yet. So far the airports I have done You told me to wait for the X-Plane export in the next version :-) haven't had more than about 100 segments, less than some of the default ones. I deliberately avoided KSQL after seeing the massive extra aprons on the aerial photos! Hopefully what is acceptable to Robin in terms of number of segments vs. detail vs. accuracy will become more clear after I get some X-Plane export filters in and users start submitting in a format he can accept. It won't be too hard to simplify my stuff if he decides there's too much detail there. Of course. I only say the default airports because then the changes can be easily shown to everyone, by having them committed to CVS. I hope that eventually people will start making detailled representations of their local areas available, in a similar manner to MSFS scenery designers. That's my plan - the taxiways just seemed like a good place to start. I've got a reasonable representation of a t2 hangar now too, and will be working on a c type when I have a few more details, so I can start populating airfields with buildings. -- Jon Stockill ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On 5/17/04 at 12:58 PM Chris Metzler wrote: > >At any rate, as far as manually placing them and putting that >capability in TaxiDraw, sure, that'd be cool! In the short-term, >though, I have another request: a scrollbar slider for the taxiway >list brought up with the "z" key. > You can use numpad 9 and 3 to scroll the list up and down. (Numpad 8 and 2 move a selected taxiway up and down in the order). I agree it's not very intuitive though - I'll try and put in a proper list control with automatic scroll bar for the next release. >To learn how to use TaxiDraw, I wanted to pick an airport and get >going. Since the tutorial docs that come with fgfs suggest starting >out at KSQL, I decided to work on that one. It had some taxiway/ >apron work already, but it didn't match the pics at all. So I went >to work. But to do it right, there end up being a ton of taxiways. >There's a taxiway perpendicular to the runway at each end (2). There's >one that runs parallel to the runway on the southwest side (3). >There's one that runs parallel to the runway on the northeast side; >but it changes surface partway down, and then turns and goes into a >runway end at an angle, so that's three more (6). There are five >short taxiways used to access the runway from the main taxiways: >two that go all the way across, from parallel taxiway to parallel >taxiway; one that connects the runway with one taxiway; and two >that are angular (11). And with that layout, there are 39 corners >that (according to the pictures) ought to be rounded; and using >three at each corner, that's 117 more taxiways (128). And we haven't >even got to the aprons yet. With these kind of numbers, using the >taxiway list to set the taxiway ordering doesn't work, because half >the taxiway list is off the screen. A slider would help. > >Incidentally, this long list is an illustration of why #2, above, >might be a good idea in general; would Robin Peel really want those >117 small taxiways put in purely for aesthetic reasons? > I'm not entirely sure where the acceptable number of segments / amount of detail trade-off will end up. Jon Stockill has done some very detailed UK military layouts with hundreds of segments to show all the dispersal areas, but I don't think he's submitted them yet. So far the airports I have done haven't had more than about 100 segments, less than some of the default ones. I deliberately avoided KSQL after seeing the massive extra aprons on the aerial photos! Hopefully what is acceptable to Robin in terms of number of segments vs. detail vs. accuracy will become more clear after I get some X-Plane export filters in and users start submitting in a format he can accept. >Perhaps a better way of handling curved intersection corners would >be to generate for each intersection a set of four boolean flags >indicating whether or not that corner should be rounded, and let >TerraGear round the corners when it puts the taxiways into the scenery? >But I bet that requires hard work on their part, so maybe not such a >good idea. > It's a good idea, but as you say requires a lot coding in TerraGear as well. Better handling of taxiway/taxiway and taxiway/runway intersections is something that's been mulling in the back of my mind for ages, but realistically I haven't got a chance of finding time to work on it in the foreseeable future. > >> It would still be a job to get them placed >> automatically without them overlapping other taxiways or runways, and >> that would probably require coding in TerraGear. > >Yeah, it does seem like a hard problem. And in the long run -- in some >future world where all the scenery everywhere is in wonderfully perfect, >local idiosyncratic shape -- I guess we wouldn't want auto-generated >signage because they differ somewhat in style from place to place. > >One other sign that would be nice to generate (with the same "avoiding >taxiways" problem) would be the signs that indicate how much runway is >left. > > There's lots of room for improvement to the airport modelling. I guess that ultimately artistic orientated folk will start doing custom scenery for certain areas, rather than relying on the automated processing of compiled data as we do at the moment. Adding buildings to all the base-area scenery airports would make a hell of a difference, and the results could go in CVS. >>> >>> Yeah. I'd like to do this; I'm using it as an excuse to learn Blender. >>> The problem I have at this point is good source photos. >> >> As far as I can tell, a lot of US GA airports have large numbers of >> fairly generic, low, white or light-grey hangars. It would be very good >> to get some of these into the default GA airports, and wouldn't really >> require fancy textures from photos. > >Oh, I agree completely, and that's where I'm starting as I learn this >stuff. At the same time, though, I bet there's a natural tendancy for >all of us to want to fly at airport
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Mon, 17 May 2004 11:38:36 -0400 Josh Babcock <[EMAIL PROTECTED]> wrote: > > When I get done witn my B-29 (months) have plans to do Dulles, then > National and BWI. I also want to do the mall in DC, the major Potomac > bridges, and some of the bigger landmarks around the beltway and > downtown Baltimore. I live in the DC area and have similar interests. Maybe when I learn my way around Blender we can collaborate on some of this stuff. -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 pgpIT7GdBVO5J.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Mon, 17 May 2004 13:27:43 -0400 Josh Babcock <[EMAIL PROTECTED]> wrote: > Chris Metzler wrote: >> >> As an aside, is there a way to travel around the scenery and look at >> it other than by flying? For the purposes of inspecting how models >> look etc., it's nice to be able to pick a vantage point and viewing >> angle; is there anything like that in fgfs? > > try the ufo YAY. This isn't *exactly* what I was thinking, but it does the job every bit as well as what I was thinking (in some respects, even better). Thanks very much! -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 pgphowoc8jJw9.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Chris Metzler wrote: On Sat, 15 May 2004 20:03:07 +0100 Lee Elliott <[EMAIL PROTECTED]> wrote: I seem to recall discussing how we could include specific scenery features on this list sometime in the past but I can't remember if any conclusions were reached. Would it be possible to pull the scenery objects out of the terrain & usage data i.e. the current /Scenery data, and put them in a separate folder? This would mean that the scenery objects would have to include the location data - lat, lon & alt - but that, along with any animation stuff such as warning and night lights, opening swing bridges and rotating restaurants could be defined in XML. A very thing about this would be that a modeller could easily see how his/her work looks in the simulation itself; it wouldn't require regenerating the terrain to do so. As an aside, is there a way to travel around the scenery and look at it other than by flying? For the purposes of inspecting how models look etc., it's nice to be able to pick a vantage point and viewing angle; is there anything like that in fgfs? -c ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel try the ufo Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Sat, 15 May 2004 20:03:07 +0100 Lee Elliott <[EMAIL PROTECTED]> wrote: > > I seem to recall discussing how we could include specific scenery > features on this list sometime in the past but I can't remember if any > conclusions were reached. > > Would it be possible to pull the scenery objects out of the terrain & > usage data i.e. the current /Scenery data, and put them in a separate > folder? > > This would mean that the scenery objects would have to include the > location data - lat, lon & alt - but that, along with any animation > stuff such as warning and night lights, opening swing bridges and > rotating restaurants could be defined in XML. A very thing about this would be that a modeller could easily see how his/her work looks in the simulation itself; it wouldn't require regenerating the terrain to do so. As an aside, is there a way to travel around the scenery and look at it other than by flying? For the purposes of inspecting how models look etc., it's nice to be able to pick a vantage point and viewing angle; is there anything like that in fgfs? -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 pgpM6Lc7JOvnv.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Sat, 15 May 2004 16:31:03 +0100 David Luff <[EMAIL PROTECTED]> wrote: > Chris Metzler writes: >> >> Well, I'm probably talking out of my behind here, and maybe this isn't >> an issue. But I would naively think that having fgfs (or TerraGear or >> whatever) place signs on the basis of taxiway identifiers in the >> runways.dat file could be pretty tricky, if the taxiways were done >> with TaxiDraw. The tutorial suggests laying down lots of short-length >> taxiways in an effort to make curved contours around junctions and >> turns; I can imagine those curved contours having a zillion signs >> around them as a result, if the signs were just laid down on the basis >> of all the taxiways present in the runways.dat file. > > What I meant was adapting TaxiDraw (or fgsd) to allow the user to > specify where the signs would go, and the designation on the sign, and > then export the appropriate format file. This would not be the > runways.dat format, but instead one of the scenery files that designates > where objects are placed - I believe it's .stg. There is apparently > already support for taxiway signage in .stg files (I think) - I believe > it was done in the KJSC photo-scenery demo. I'd be happy to add the > code to TaxiDraw if you wanted to use it for this, it's something I've > been thinking about already. As you say, automatically placing them via > the runways.dat designations could be a nightmare, although I guess it's > possible that you could add names only to 'proper' taxiways that > required signage. Yeah, I was thinking about your last clause earlier: how would "proper" taxiways be identified, so that runways.dat could be used for this? I was considering two possible solutions: 1. Use some odd identifier in the taxiway identifier field to signal apron, or taxiways put in for curvature or small side aprons or whatever. For example, all taxiways whose identifiers aren't "xxx", "aaa" or "bbb" get signs. In the editor, in the properties box for a taxiway, one could ask taxiway type (true, apron, curvature, etc.) and, in the "true" taxiway case, identifier. Then the identifier, or "aaa" or "bbb", gets written to that field when AIRPORTNAME.twy gets written. Signs only get created for true taxiways; ATC only gives directions based on true taxiways, etc. (probably a better option than using the taxiway identifier in this fashion would be to create additional type identifiers for the first column, beyond just "R" for runway and "T" for taxiway; but that changes Robin Peel's format). 2. Put non-true taxiways (perhaps noted as such through the properties box like above) in a second file; signs and ATC stuff only pays attention to things in runways.dat. This has the advantage that the .twy file to send to Robin Peel doesn't have the zillion subjective small taxiways put in for intersection curvature, which I can imagine him not wanting. OTOH (if I understand how things work), it's another file that TerraGear would have to be taught to handle. At any rate, as far as manually placing them and putting that capability in TaxiDraw, sure, that'd be cool! In the short-term, though, I have another request: a scrollbar slider for the taxiway list brought up with the "z" key. To learn how to use TaxiDraw, I wanted to pick an airport and get going. Since the tutorial docs that come with fgfs suggest starting out at KSQL, I decided to work on that one. It had some taxiway/ apron work already, but it didn't match the pics at all. So I went to work. But to do it right, there end up being a ton of taxiways. There's a taxiway perpendicular to the runway at each end (2). There's one that runs parallel to the runway on the southwest side (3). There's one that runs parallel to the runway on the northeast side; but it changes surface partway down, and then turns and goes into a runway end at an angle, so that's three more (6). There are five short taxiways used to access the runway from the main taxiways: two that go all the way across, from parallel taxiway to parallel taxiway; one that connects the runway with one taxiway; and two that are angular (11). And with that layout, there are 39 corners that (according to the pictures) ought to be rounded; and using three at each corner, that's 117 more taxiways (128). And we haven't even got to the aprons yet. With these kind of numbers, using the taxiway list to set the taxiway ordering doesn't work, because half the taxiway list is off the screen. A slider would help. Incidentally, this long list is an illustration of why #2, above, might be a good idea in general; would Robin Peel really want those 117 small taxiways put in purely for aesthetic reasons? Perhaps a better way of handling curved intersection corners would be to generate for each intersection a set of four boolean flags indicating whether or not that corner should be rounded, and let TerraGear round the corners when it puts the taxiways into the scenery? But I bet that requires ha
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Ampere K. Hardraade wrote: On May 15, 2004 01:31 am, Chris Metzler wrote: The problem I have at this point is good source photos. In my opinion, pictures aren't really that useful. Sure, they may give you information on various details, but when you are modeling something, you would find dimensions more helpful. When you have enough numbers, you won't even need pictures. The amount of time it takes for the models to be completed can be shorten trenmendously. The whole modelling experience will also be more enjoyable, as the modellers don't need to work, and rework, and work on the samething over and over again until it "looks right" (which is pretty boring, not to mention fustrating). The only problem is that the numbers are not easy to find. The second most important thing is a set of coordinates: you need them to know where to position various structures. So for those who have GPS reciever, it will actually be helpful if they can walk to the corners of various buildings and record their locations. On May 15, 2004 01:31 am, Chris Metzler wrote: Yeah. I'd like to do this; I'm using it as an excuse to learn Blender. I wouldn't mind doing this also. This will give me a chance to learn Blender as well. So right now, we have three modellers who have expressed interests. ;-) Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel When I get done witn my B-29 (months) have plans to do Dulles, then National and BWI. I also want to do the mall in DC, the major Potomac bridges, and some of the bigger landmarks around the beltway and downtown Baltimore. I also want to make a library of generic towers and write a program to extract US tower positions from the FCC database. I would like to find a place to put a database where people can go and assign the proper type of tower to an entry, since the FAA database only tells you the height and omits water towers. I'm sure the FAA has a databse as well, but I haven't found it. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Sat, 15 May 2004 13:17:46 -0400 "Ampere K. Hardraade" <[EMAIL PROTECTED]> wrote: > > On May 15, 2004 01:31 am, Chris Metzler wrote: > > The problem I have at this point is good source photos. > > In my opinion, pictures aren't really that useful. Sure, they may give > you information on various details, but when you are modeling something, > you would find dimensions more helpful. > > When you have enough numbers, you won't even need pictures. Well, I sorta agree. I do agree that dimensions are the most important thing -- that all the pictures in the world don't matter if you can't get the size and proportions of the structure right. But, OTOH, some level of detail is important, and you can't get that from numbers. Back in 1984, we could get simple buildings lacking detail in MS Flight Simulator, and they looked absolutely awful. Even by standards then, they looked awful to me. I'd certainly like them to look something like the real thing now. -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 pgpLM9cQsx80K.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Sunday 16 May 2004 15:43, Jim Wilson wrote: > Lee Elliott said: > > Incidentally, I've noticed that although the random objects are placed > > randomly, they get placed in the same place each time I run fgfs - for > > example, as well as KSFO I also use EGLL for glide slope and landing > > testing and every time I go in there on 27R there's the same red > > building, in the same place, about half a mile before the runway. To me > > it's already become a landmark:) > > That's a good thing isn't it? > > Best, > > Jim Heh! - I guess it is:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Lee Elliott said: > Incidentally, I've noticed that although the random objects are placed > randomly, they get placed in the same place each time I run fgfs - for > example, as well as KSFO I also use EGLL for glide slope and landing testing > and every time I go in there on 27R there's the same red building, in the > same place, about half a mile before the runway. To me it's already become a > landmark:) > That's a good thing isn't it? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On Saturday 15 May 2004 17:06, Jim Wilson wrote: > Chris Metzler said: > > 7. Are there any guidelines for maximum complexity of 3D models > > for scenery? On one hand, I want to make cool things. But OTOH, > > I don't want to make things which are so cool that they won't get > > used because they're too apt to drag framerates down into the > > dirt. > > I'd take a look at what is there already. If you are adding to the > collection of the generic buildings then keep the geometry super simple and > textures under 64x64. For more complex landmark type models like the > Golden Gate bridge, you can get do more (maybe total of 256x256... e.g. 4 > 64x64 textures) but you will want to make sure for now that there won't be > too many of these in view at the same time. Downtown San Francisco area > is pretty well maxed out now. > > Since so many folks have expressed interest in doing this kind of modeling, > it might be nice to build alternative scenery distributions for specific > urban areas similar to San Franscisco as distributed in the FlightGear base > package. > > Best, > > Jim I seem to recall discussing how we could include specific scenery features on this list sometime in the past but I can't remember if any conclusions were reached. Would it be possible to pull the scenery objects out of the terrain & usage data i.e. the current /Scenery data, and put them in a separate folder? This would mean that the scenery objects would have to include the location data - lat, lon & alt - but that, along with any animation stuff such as warning and night lights, opening swing bridges and rotating restaurants could be defined in XML. Could the routines that place the random objects be adapted to place specific objects? Incidentally, I've noticed that although the random objects are placed randomly, they get placed in the same place each time I run fgfs - for example, as well as KSFO I also use EGLL for glide slope and landing testing and every time I go in there on 27R there's the same red building, in the same place, about half a mile before the runway. To me it's already become a landmark:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
On May 15, 2004 01:31 am, Chris Metzler wrote: > The problem I have at this point is good source photos. In my opinion, pictures aren't really that useful. Sure, they may give you information on various details, but when you are modeling something, you would find dimensions more helpful. When you have enough numbers, you won't even need pictures. The amount of time it takes for the models to be completed can be shorten trenmendously. The whole modelling experience will also be more enjoyable, as the modellers don't need to work, and rework, and work on the samething over and over again until it "looks right" (which is pretty boring, not to mention fustrating). The only problem is that the numbers are not easy to find. The second most important thing is a set of coordinates: you need them to know where to position various structures. So for those who have GPS reciever, it will actually be helpful if they can walk to the corners of various buildings and record their locations. On May 15, 2004 01:31 am, Chris Metzler wrote: > Yeah. I'd like to do this; I'm using it as an excuse to learn Blender. I wouldn't mind doing this also. This will give me a chance to learn Blender as well. So right now, we have three modellers who have expressed interests. ;-) Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Chris Metzler writes: > On Fri, 14 May 2004 23:37:58 +0100 > David Luff wrote: > > Chris Metzler writes: > >> > >> 2. The taxiways that *are* listed in the Airport/runways.dat, > >> typically for major airports, don't have taxiway identifications > >> listed. For example, > >> > >> A KSQL 5 CYN San Carlos > >> R KSQL 12 37.511856 -122.249524 138.09 259975 NARHN NYVN0 > >> 0 NYVN00 > >> T KSQL xxx 37.511303 -122.249374 134.68 260075 YCB > >> T KSQL xxx 37.510796 -122.250015 134.68 260075 YCB > >> T KSQL xxx 37.511108 -122.251083 134.68 2000 200 YCB > >> > >> According to the explanation of the format on Robin > >> Peel's site, those "xxx" should give a taxiway identifier. I presume > >> that FlightGear doesn't use them at the present; but I can imagine > >> that they might be in the future, for ATC or AI, or for default > >> taxiway signs (in the absence of signs placed as 3D models in the > >> scenery). If these are known, such as through an airport chart, > >> should they be put in? If so, in what format (e.g. left-justified, > >> right-justified, zero padded, etc.)? > > > > AFAIK, FlightGear can render taxiway signage based on a text field in > > one of the files (.stg?) - it shouldn't be too hard to adapt one of the > > tools (either TaxiDraw or fgsd) to output it to the .stg or whatever > > files it lives in. Doing it for the base airports would be the way to > > start since then it can go into CVS, then think about the logistics of > > storing the generated data for worldwide airports! > > Well, I'm probably talking out of my behind here, and maybe this isn't > an issue. But I would naively think that having fgfs (or TerraGear or > whatever) place signs on the basis of taxiway identifiers in the > runways.dat file could be pretty tricky, if the taxiways were done with > TaxiDraw. The tutorial suggests laying down lots of short-length taxiways > in an effort to make curved contours around junctions and turns; I can > imagine those curved contours having a zillion signs around them as a > result, if the signs were just laid down on the basis of all the taxiways > present in the runways.dat file. > > What I meant was adapting TaxiDraw (or fgsd) to allow the user to specify where the signs would go, and the designation on the sign, and then export the appropriate format file. This would not be the runways.dat format, but instead one of the scenery files that designates where objects are placed - I believe it's .stg. There is apparently already support for taxiway signage in .stg files (I think) - I believe it was done in the KJSC photo-scenery demo. I'd be happy to add the code to TaxiDraw if you wanted to use it for this, it's something I've been thinking about already. As you say, automatically placing them via the runways.dat designations could be a nightmare, although I guess it's possible that you could add names only to 'proper' taxiways that required signage. It would still be a job to get them placed automatically without them overlapping other taxiways or runways, and that would probably require coding in TerraGear. > > OK, so I interpret your last bit as saying that my interpretation > of what I saw in the archives is incorrect, and that the airport data > is still coming from Robin Peel. Presumably, then, it goes through > some post-processing on the FG end to result in the basic.dat and > runways.dat files? (since those files are similar, but not identical, > to the way it's provided by Robin, according to his web page) And > presumably it's that difference that you're referring to above when > you note that he can't import the stuff TaxiDraw outputs -- because > it's in FG's form, rather than his original form? Just making sure > I understand how this all works. > Curt and Robin know how this stuff works better than myself, but I believe that Robin has export filters to export his data in our basic.dat + runways.dat format, but no import filters. I believe he keeps the raw data in a database, and exports in either X-Plane or FG format, but only imports in X-Plane format. There are some details on his website, the address of which eludes me at the moment. > > Sometimes the DAFIF is definately wrong, > > sometimes user-submitted data is wrong, sometimes the available aerial > > photos have been outdated by new developement. It's just a case of > > making it as good as it can be. > > Well, yeah. I guess what I was wondering was whether there's some > sort of "conflict resolution" procedure. If another source gives > other information, is the DAFIF data assumed to be correct because, > well, you gotta pick something. If there are *two* sources which > agree with each other but contradict the DAFIF data, do you go with > that? If you personally know the placement of an airport is wrong > and can correct it, should you try? I'm just wondering what one > should do (if anything at all) upon encountering s
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Chris Metzler said: > > 7. Are there any guidelines for maximum complexity of 3D models > for scenery? On one hand, I want to make cool things. But OTOH, > I don't want to make things which are so cool that they won't get > used because they're too apt to drag framerates down into the > dirt. > I'd take a look at what is there already. If you are adding to the collection of the generic buildings then keep the geometry super simple and textures under 64x64. For more complex landmark type models like the Golden Gate bridge, you can get do more (maybe total of 256x256... e.g. 4 64x64 textures) but you will want to make sure for now that there won't be too many of these in view at the same time. Downtown San Francisco area is pretty well maxed out now. Since so many folks have expressed interest in doing this kind of modeling, it might be nice to build alternative scenery distributions for specific urban areas similar to San Franscisco as distributed in the FlightGear base package. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Hi Dave. Thanks very much for your reply. On Fri, 14 May 2004 23:37:58 +0100 David Luff <[EMAIL PROTECTED]> wrote: > Chris Metzler writes: >> >> 2. The taxiways that *are* listed in the Airport/runways.dat, >> typically for major airports, don't have taxiway identifications >> listed. For example, >> >> A KSQL 5 CYN San Carlos >> R KSQL 12 37.511856 -122.249524 138.09 259975 NARHN NYVN0 >> 0 NYVN00 >> T KSQL xxx 37.511303 -122.249374 134.68 260075 YCB >> T KSQL xxx 37.510796 -122.250015 134.68 260075 YCB >> T KSQL xxx 37.511108 -122.251083 134.68 2000 200 YCB >> >> TrackArtist.cppAccording to the explanation of the format on Robin >> Peel's site, those "xxx" should give a taxiway identifier. I presume >> that FlightGear doesn't use them at the present; but I can imagine >> that they might be in the future, for ATC or AI, or for default >> taxiway signs (in the absence of signs placed as 3D models in the >> scenery). If these are known, such as through an airport chart, >> should they be put in? If so, in what format (e.g. left-justified, >> right-justified, zero padded, etc.)? > > AFAIK, FlightGear can render taxiway signage based on a text field in > one of the files (.stg?) - it shouldn't be too hard to adapt one of the > tools (either TaxiDraw or fgsd) to output it to the .stg or whatever > files it lives in. Doing it for the base airports would be the way to > start since then it can go into CVS, then think about the logistics of > storing the generated data for worldwide airports! Well, I'm probably talking out of my behind here, and maybe this isn't an issue. But I would naively think that having fgfs (or TerraGear or whatever) place signs on the basis of taxiway identifiers in the runways.dat file could be pretty tricky, if the taxiways were done with TaxiDraw. The tutorial suggests laying down lots of short-length taxiways in an effort to make curved contours around junctions and turns; I can imagine those curved contours having a zillion signs around them as a result, if the signs were just laid down on the basis of all the taxiways present in the runways.dat file. >> 3. Where should the taxiway data go? The TaxiDraw tutorial >> mentions sending them to Robin Peel, for inclusion in the complete >> airport data. Is that still the case? Various things I've read >> in the archives here gave me the impression that these days, >> FlightGear is compiling its own airport data files from the DAFIF, >> rather than getting them from Robin Peel's compilation. The fact >> that the files in Airport/* are similar to, but not exactly the >> same as, those described on Robin Peel's website, seem to support >> that perception. Is that true? If it is, then where should the >> taxiway info be sent to, so FlightGear can use it? > > Please hold off temporarily from sending it to Robin - he can't import > the FlightGear format datafiles that TaxiDraw outputs to his master > database. I'm midway through adding X-Plane data format support that he > can handle to TaxiDraw, and will update the tutorial to reflect that > when it's working and a new release is out. Hopefully in a few weeks. > > However, it shouldn't be underestimated just what a *huge* task it is to > maintain worldwide airport data files. Although noises have been made > on the list about maintaining our own, realistically we are likely to be > getting our data from Robin from the forseeable future IMO. OK, so I interpret your last bit as saying that my interpretation of what I saw in the archives is incorrect, and that the airport data is still coming from Robin Peel. Presumably, then, it goes through some post-processing on the FG end to result in the basic.dat and runways.dat files? (since those files are similar, but not identical, to the way it's provided by Robin, according to his web page) And presumably it's that difference that you're referring to above when you note that he can't import the stuff TaxiDraw outputs -- because it's in FG's form, rather than his original form? Just making sure I understand how this all works. >> 4. Is the information in the airport files considered to be 100% >> accurate? I occasionally see differences between runway lengths >> listed in runways.dat and those listed in other sources, such as >> U.S. state Department of Aviation databases, or U.S. FAA references >> (reproduced at airnav.com). The differences are rarely large -- >> less than 20 feet typically -- but it makes me wonder what's right >> and whether there may be other discrepancies and so on. > > A database that large will never be 100% right. The use of background > photos in TaxiDraw seems to indicate to me that a lot of the smaller > airports are actually positioned up to several hundred meters > incorrectly by the DAFIF data. The biggest discrepancy I've noticed yet is the placement of Meigs Field in Chicago; but while its placement isn't authentic, neither is its very ex
Re: [Flightgear-devel] New contributor questions: taxiway and airport stuff; 3D building/landmark model stuff.
Chris Metzler writes: > > Hi. I've been thinking of ways in which I could help out with stuff for > FlightGear, given that I don't code in C++. Other than providing useful > bug reports and the occasional odd suggestion, I thought of getting my > feet wet by working on adding taxiways to airports that aren't currently > given them. I also thought I might look at airport buildings, taxiway > markers, etc., and at 3D structures for landmarks such as are present in > the San Francisco scenery. > Hi Chris, Making better airports is definately a good thing to do! And the more folk that attempt it the better :-) > If it's at all worthwhile for me to do this, then I have some questions. > > 1. Regarding adding taxiways, I read a bunch of old emails on this list, > and it seems like there's two ways to approach this. One is David Luff's > TaxiDraw, which (as I understand it) is solely concerned with rendering > taxiways, and produces a table of taxiway information for a particular > airport that's in an appropriate format for insertion into the > Airports/runways.dat file. The other is fgsd-taxi, a modified fgsd that > produces taxiway layouts not for rendering, but for AI aircraft to follow. > Do I have this correctly? If so, does it make sense when doing the former > to do the latter, even if the AI is not yet fully implemented, thinking > that then it doesn't have to be added later? > You've got that pretty well correct. At the moment the AI doesn't understand the output from fgsd-taxi, but that should be fairly soon in coming. TaxiDraw actually started out as an AI taxiway editor similar to AFCAD, but when I saw what Bernie was doing with fgsd-taxi I put that on indefinate hold, and only resurrected it as a physical taxiway editor when the need arose. > > 2. The taxiways that *are* listed in the Airport/runways.dat, typically > for major airports, don't have taxiway identifications listed. For > example, > > A KSQL 5 CYN San Carlos > R KSQL 12 37.511856 -122.249524 138.09 259975 NARHN NYVN00 NYVN0 > 0 > T KSQL xxx 37.511303 -122.249374 134.68 260075 YCB > T KSQL xxx 37.510796 -122.250015 134.68 260075 YCB > T KSQL xxx 37.511108 -122.251083 134.68 2000 200 YCB > > TrackArtist.cppAccording to the explanation of the format on Robin Peel's site, > those "xxx" should give a taxiway identifier. I presume that > FlightGear doesn't use them at the present; but I can imagine > that they might be in the future, for ATC or AI, or for default > taxiway signs (in the absence of signs placed as 3D models in the > scenery). If these are known, such as through an airport chart, > should they be put in? If so, in what format (e.g. left-justified, > right-justified, zero padded, etc.)? > AFAIK, FlightGear can render taxiway signage based on a text field in one of the files (.stg?) - it shouldn't be too hard to adapt one of the tools (either TaxiDraw or fgsd) to output it to the .stg or whatever files it lives in. Doing it for the base airports would be the way to start since then it can go into CVS, then think about the logistics of storing the generated data for worldwide airports! > > 3. Where should the taxiway data go? The TaxiDraw tutorial > mentions sending them to Robin Peel, for inclusion in the complete > airport data. Is that still the case? Various things I've read > in the archives here gave me the impression that these days, > FlightGear is compiling its own airport data files from the DAFIF, > rather than getting them from Robin Peel's compilation. The fact > that the files in Airport/* are similar to, but not exactly the > same as, those described on Robin Peel's website, seem to support > that perception. Is that true? If it is, then where should the > taxiway info be sent to, so FlightGear can use it? > Please hold off temporarily from sending it to Robin - he can't import the FlightGear format datafiles that TaxiDraw outputs to his master database. I'm midway through adding X-Plane data format support that he can handle to TaxiDraw, and will update the tutorial to reflect that when it's working and a new release is out. Hopefully in a few weeks. However, it shouldn't be underestimated just what a *huge* task it is to maintain worldwide airport data files. Although noises have been made on the list about maintaining our own, realistically we are likely to be getting our data from Robin from the forseeable future IMO. > > 4. Is the information in the airport files considered to be 100% > accurate? I occasionally see differences between runway lengths > listed in runways.dat and those listed in other sources, such as > U.S. state Department of Aviation databases, or U.S. FAA references > (reproduced at airnav.com). The differences are rarely large -- > less than 20 feet typically -- but it makes me wonder what's right > and whether there may be other discrepancies and so on. > A database that large wil
