EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

For about a year there has been a subtle bug in how X-Plane draws taxiways: if you build an S-curve shape out of a single bezier and it is almost perfectly symmetrical, X-Plane would go “nah, why bother” and replace it with a single straight line segment.*

So in 10.30 I fixed it, and the result was a bunch of broken airports with missing pavement.  (YMML is high on this list!)

It turns out that these airports have authoring errors – typically a segment of pavement that should be straight instead being formed by two overlapping beziers.  This is definitely wrong, but due to the bug, X-Plane would simplify the overlapping S curve into a single straight segment and the layout would work.  Only now that X-Plane correctly renders the S curve does the taxiway fail (because taxiways may not have overlaps).  So two wrongs may not make a right, but they do make a “hey, that looks okay, let’s ship it”.

Note that the overlaps depend on the rendering setting of X-Plane – a different S curve is formed at different rendering settings; the overlap that causes the taxiway to disappear may only appear at a particular rendering setting.

For 10.31 I am going to undo my bug fix. This doesn’t make me happy, but I think it is necessary:

  • We have no idea how many airports have their taxiways broken by this bug.
  • Authors have no easy way to detect this problem, other than re-testing every airport at every rendering setting.
  • Even if an airport looks okay at all rendering settings, future rendering settings may cause the problem.

This is too much uncertainty to solve ‘by hand’.  So my plan is:

  • Undo the code change for 1031.  YMML and friends comes back.
  • Develop validation code in WED to detect this kind of authoring error.
  • Ship that version of WED so new authoring work will be checked.
  • Run the WED code on all airports and make a list of ones that need repair.
  • Fix all of the known problems in the airport gateway.
  • Redo the code change so X-Plane is correct.

This isn’t going to be a quick process, but then it can’t be, because third parties have apt.dats shipping now that only work when X-Plane has the buggy taxiway code in place.  So we need to ship WED and then give third parties enough time to go back and check their layouts and fix them if necessary.

I expect to get a 10.31 beta with the taxiway code changed back this week.

For WED validation, I have some test code to detect errors but it isn’t ready yet.  The problem is that it’s not good enough to detect errors with overlapping beziers**; we have to consider two bezier curves near enough to each other that with the error in rendering introduced by WED’s rendering settings, we get an overlap.  (So authors, better be safe than sorry in creating your pavement.)

If there’s a moral to this story, I think it’s this: when we (LR) don’t provide good tools for authors to validate that their work is correct, the resulting body of work will end up with subtle errors.

 

* X-Plane renders beziers by measuring how far the mid-point of the curve is from the average of the ends.  As long as this distance is ‘too far’ and the iteration count isn’t too high, X-Plane divides the bezier in half and repeats the process.  In this way beziers are broken into enough line segments to approximate the bezier within a minimum error limit.  The rendering settings control the error limit.

The bug: if the curve was a ‘balanced’ S curve the mid point of the curve was the average of the end points and X-Plane went “great, no error” and stopped dividing.

** Which is already not an easy problem – the analytical solution for bezier intersection is a 9th order polynomial!

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

26 comments on “Dude, Where’s My Taxiway?”

  1. is long range visibility expected for 10.31? is there any release notes preview what to expect for 10.31 release? thanks!

      1. Not to pester, Ben, but I’ll echo Manuel’s interest. I read your blog religiously, and I know that 10.31 is final bug fixes for 10.30. However, 10.30 was originally going to have the long range visibility enhancements, but got pushed back…hopefully just a bit. I think you mentioned 10.35….in other words, theoretically it’s next. Bezier curves on taxiways are no doubt of interest to airport designers and their creative lot, but there’s cool stuff that’s been suggested in past posts that are really, really capable of pressing a lot of folks’ hot buttons. Mine included…. 🙂 Fixing the moon/sun appearing below the horizons, seeing distant terrain as something more than a cloud of dirt and grass…..soon?

        1. 10.31 is a small bug fix patch. Its goal is to fix small bugs that should not have made it into 1030 but did, soon.

          So no ‘new’ stuff is going into 1031.

          2. Ah…I have nothing to say about 1035 at this time. Mostly because we don’t have a clear plan yet. (We have a bunch of code that we’d like to finish up and it’s not clear what order it’ll go in or when.)

  2. I know some major Canadian Airports have been effected. The ones I’ve noticed so far are, Vancouver, Calgary, Toronto, Ottawa. I think Toronto is fine. Then again, these are just the default landscapes. One thing I noticed missing are the runway turnoff lights, ie. the green lights (centre taxi) and taxi signs to indicate a taxiway turn off.

  3. Until I read this post, I had only one problem. It’s a quality of the Bezier curve lines. Beautiful smooth curve line in WED don’t want to look like curve in reality. The line consists of short straight ones. My attempts to increase a number of node without result. All hopes to 10.31.

    Cheers
    Youri

  4. Thanks, Ben. Are you saying that a crucial condition is “taxiways may not have overlaps”? What does that mean exactly? Is it wrong to use slightly overlapping pavement (of different surfaces) to get visual effects, like abutting asphalt and gravel?

    1. The rule is (and always has been):

      – The contours of a single polygonal taxiway/pavement polygon (or .pol) must not intersect itself.

      So you can’t make a single taxiway in a figure-8 shape to get two pavement areas.

      Two -different- taxiways -can- overlap. However, if they share snapped vertices this is not necessary, and you should get a precisely matched pavement junction. (If you have different nodes in the two overlapping pavements, subtle cracks may appear.

  5. FWIW,

    We have a new YMML in the works – completely redone from ‘first principles’ with new taxiways and such — so hopefully any self-intersecting beziers and/or inheriting bad taxiway data from the original apt.dat will simply ‘disappear in a puff of logic’ when we push the final out.

    Andras is working on a new HDMesh for OZLand, so it’s a good time to get this continent all fixed up in prep =)

    1. That would be great – in the long term it’ll be one less airport to need repairs.

      For what it’s worth, I hand-fixed YMML as part of diagnosing the bug, with buggy experimental intersection-finding code in WED and it took about 20 minutes to fix. So with good tools it shouldn’t be too hard to fix some of these problems.

  6. as it has been said, long range visibility – progressive and as much realistic as possible in a dynamic lighting environment (HDR) with beautiful clouds and adequate fog are THE essential features we want to see improved, please . (the S curve bezier taxiway can wait)

    thanks.

    1. Funny you should say that, Rudy. I had a similar gut reaction.

      Then again, here’s another take: Ben is doing something publicly with this blog that takes precious time away from wrangling code. He doesn’t do it often, so when he does, it has to be valuable. This post might seem trivial, but then again, when there’s a bug in the code that gets fixed and it turns out that it breaks things users and third party developers have created, something has to be done, and that required a bit of fessin’ up here. Not all developers will do that. And since a lot of creative folks, myself included, use this blog to stay current with every nuance of X-Plane development, this is a good place to let folks know critical details regarding a bug, or a flub, and what’s to come as a result.

      So while this post may seem trivial in terms of the bigger picture, it has great value for folks that put together the airport scenery that X-Plane needs. And these people are worth a lot to LR and the community since X-Plane depends on third parties almost exclusively to populate airports beyond the demo scenery area. It’s one of the most frequent new user complaints over on the .Org, and the new airport building tools have gotten a good deal of well deserved attention as a result.

      I desperately want greater visibility range at altitude, and there’s a good sized bit of work already done on that, as we saw in an older post. So I have faith that it will happen eventually. If not on 10.35, then maybe 10.40. Who knows? I don’t think either Ben or Austin do either, as priorities can be extremely dynamic in a small company.

      So Ben, thanks for the friendly non-committal reply to my earlier post, enjoy yet another cup of coffee and keep on pounding the keys. I may pester, but I do appreciate what you do, and I think that goes for all of the user base, no matter how often we seem like a PITA. 😉

    2. Others have responded to this more eloquently than I was going to…I was just going to write something snarky like “don’t fix bugs in other people’s features, implement MY feature!”. 🙂

      I do agree that the bezier S curve bug was a small one and people want visibility badly. But the result of the S-curve bug is a major regression bug in 1030, so now it’s important.

  7. Hello Ben, can you post a picture or pictures of what you are saying (see below)? I’m trying to look for the errors you mention but since the airport is complex, no luck yet.
    thanks
    Ralph
    “It turns out that these airports have authoring errors – typically a segment of pavement that should be straight instead being formed by two overlapping beziers. This is definitely wrong, but due to the bug, X-Plane would simplify the overlapping S curve into a single straight segment and the layout would work. Only now that X-Plane correctly renders the S curve does the taxiway fail (because taxiways may not have overlaps).”

      1. Hi Ben, I found the error after 2 days of searching with a fine toothcomb using WED. It was indeed an overlap. The scenery came from FS2004 and was probably converted using a conversion tool. I had a great learning curve. Your link above helped a lot.
        thanks
        Ralph

  8. Rudy
    I here you.
    But I think you’ll find , particularly reading through the many posts at the org concerning 10.30 that reliability ( non crashing at start up ) , steady reasonable frame rates (30-40), accurate systems and flight model take priority for most users who don’t own military grade computers .LR have to strike a balance-many users demanded better cloud modelling etc. ,then complain about performance when all the eye candy melts their systems. Personally THE most important item for me e.g. would be a completed AV-8B cockpit , been hoping for 2 years.Its not realistic for me if I’m looking at a 2d cockpit from v8 even if I could see miles and miles of beautiful clouds;)
    T

  9. Ben, on a related note:

    I’ve given the X-Plane library’s custom pavement a try, wanted to use some asphalt for runway shoulders and such, but I noticed that all custom pavement is in layer group ‘markings -1’, which kind of seems to negate the flexibility the layer system was designed for in the first place 😉

    Would it be possible to put them in a layer group between taxiways and runways, e.g. ‘taxiways +3’ or ‘runways -3/-4?’
    I realize this will affect airports that rely on the current layering, but I doubt that it will be many…

    anyway, I like the WED validating stuff 🙂

  10. Hey Ben,
    sorry that this post is a bit out of topic … 🙂
    I assume that you did see the Dynamic Super Resolution that Nvidia published with the new drivers for the 900 series , and it’ll follow for the 600 and 700 series in the next drivers I think.
    As I understood it works almost like SSAA that is in XP , while it’s more gentle on performance.
    I didn’t try it myself because I have and old GTX 460 , but do you think that it’s possible that as a user I can run lower AA in XP while DSR is on , and get basicly the same result with higher perforamnce , that let’s say 4XSSAA + FXAA?
    And mainly , should it work with XP or you , the developers will need to do some code stuff in order to take advantage on that ?

    1. First, if the tech press stuff is correct, you can go turn on DSR without app intervention. We’re certainly not planning to do anything to support it.

      And…from what i can tell, DSR isn’t a whole lot different from what we do with 4x SSAA in HDR mode. I would expect the performance hit would also be almost exactly the same; the technical description of DRS I found is “render the image bigger and down-size” – that’s exactly what HDR SSAA does. (In nerd lingo, our SSAA is called OGSSAA for ‘ordered grid’, which just means the sub-sample points aren’t rotated).

      So my expectation is: you won’t get better speed. You might get better performance; for example, their down sampling filter might be better tuned. But this is just a small fraction of the cost of the anti-aliasing.

  11. That’s the kind of answer I was hoping to hear… so it’s likely just a mistake, not a choice XD

Comments are closed.