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 hard work on their part, so maybe not such a good idea. > 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. -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
Description: PGP signature
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel