Hi Guys, First I must say I have not read the past FG-dev discussion on this ... if someone can point me to a thread title name or date range I will catch up. The 850 apt.dat format came out of about 3 years of banging our head on the problem inside LR, but I suspect that the things we've struggled with are similar to some of the approaches described here.
To try to answer some questions: X-Plane has ended up more and more using a 'compiler' approach to our scenery, where we view the process of making scenery as a series of transformations on data. The final transformation is into some kind of "distribution" format, the assembly code of our scenery, where the format is meant to be fast to read, compact, and things the sim doesn't care about but tools do have been thrown out. Overall this has worked well for us, and I think is appearing a bit in apt.dat 850. In particular, really the apt.dat 850 taxiway layouts should be thought of as a planar map of bezier curves, but X-plane doesn't care, so 850 apt.dat is more of a derivative product of which a planar map is one of multiple possible sources. A topological network that has been 'extruded' into a taxiway set could also be the source. One of the advantages of a compiler approach is that different tools can create simcompatible layout without accepting the same abstractions. With that in mind, apt.dat 850 is low level...if you guys can get an SVG editor to output the kind of format you need, then that's great ! I just recommend that you consider the process a transform and not insist that the intermediate and final formats be the same...the design needs of the sim and the editing tools may be very different. (I should also say, for us they are different because X-plane is a commercial sim, so it's possible that FG can use the editing format as the distribution format where other sims can't. But I think having the two decoupled is useful for backward compatibility, if this is a goal.) ATC and Logical Layout: apt.dat 850 is a total punt - it makes no attempt to provide logical layout, machine-ready analysis of the layout, or things an ATC or AI implementation would need. This came out of pragmatism...we couldn't find a format that enforced these high level constructs, was still expressive enough to do all of the special-case things that authors would want to model real life, and would still be practical to implement. Based on the "compiler" model, a logical layout could be compiled into an apt.dat layout, but an apt.dat 850 layout might not be decompilable. Our assumption was that given higher level layouts, we would separately compile ATC/AI data if/when we need it. I see comments that something is better than nothing and also that this isn't a step in the right long-term direction. I will only say: right now we have _no_ higher level metadata defined in layouts and frankly the way that even the outline of the layout is expressed is a bit kludgy. So to me going to bezier curves is a step away from the wrong direction, even if it isn't a step in the right direction. (Did that make any sense?) I guess what I'm trying to say is: I wouldn't suggest sticking with overlapping quads because bezier curves don't have logical layout. If you can make a logical layout system work, then that's great, but at LR we saw that as out of our current scope. Border Lights: two thoughts...the apt.dat 850 spec specifically defines layouts as made entirely of old or new records...one of the things this implies is that FG or X-plane or any sim only has to generate 'clipped' taxiway lights for an old layout. That code can be skipped for a new layout, where all lights are explicitly placed. The problem of inset/non-inset lights is a tricky one...we're still going up and back on how much of these kinds of effects should be automatic vs explicit. For example, it seemed logical that x-plane would choose inset vs non-inset approach lights by looking at the presence of crossing taxiways, displaced threshholds, etc. On the other hand, we didn't think we could change a taxi line to have/not-have a black stripe based on the underlying terrain pavement. So I'm not sure what's best here...basically anything that could have a logical ruling but is considered too much of a PITA for the sim ends up pushed off to the tools...for our current code base the tools do a lot of work to make scenery pre-digestible and by choosing a similar strategy for airports we risk the same thing happening. But then it's all code that has to get written, whether it's in a tool or the sim's code base. In the end of the day I suppose it's a question of whether inset taxi lights are fundamentally different from non-inset ones or whether they represent two variations of the same concept. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
