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 airports we're familiar with in real life. >Giving them scenery that, in real life, makes those airports distinctive >is fun. > 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. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
