The addition of airport buildings to the default installation of X-Plane in 10.25 makes it much more important than it used to be to prioritize your scenery packs. It also makes it much more important that custom scenery exclude the scenery below it.
I have heard reports of users going into X-Plane and deleting the airports we ship to deal with conflicts. This is way more work than necessary, will be undone by the updater, and simply isn’t necessary. So this post will explain how you can sort out scenery conflicts without having to change content.
Some Light Reading
I try not to write up documentation in the blog – it’s not really useful to require users to search 900+ posts to find something I mentioned off-hand in a beta four years ago. So I wrote a knowledge base article. Please go read the entire article. I’ll go get another cup of coffee.
Let me summarize how things are supposed to work:
- Custom overlay scenery packs should be higher priority than our airports. If you went out and got a custom scenery pack, you almost certainly want to see it, not our work. (Note that if you get X-Plane, run it once, then install custom scenery, this is what happens automatically.)
- Custom overlay scenery packs should have exclusion zones to mask out the scenery below them, whether it is autogen, airports we ship, or rogue trees that have decided to invade a runway. (The need to exclude what is below you is not new – this has been in the sim since X-Plane 8.
- Mesh scenery packs should be lower priority than our airports if you want to see our airports on top of custom mesh scenery. (This step is not automatic.) Mesh scenery excludes everything (think of the mesh as one giant excluzion rectangle) so you can’t have overlays below meshes.
Where Theory Meets Practice
My favorite Farside cartoon ever is a picture of two sets of engineers standing next to the ends of two highways that were clearly meant to connect – the highways are misaligned and do not connect. The caption: “Where theory meets practice.”
And like the cartoon, the reality of scenery packs doesn’t meet the theory in a few ways:
- Some custom airport overlays don’t have exclusion zones. There was nothing under them in the past, so the authors didn’t bother to exclude.
- Some users have their global scenery at the wrong priority level. The easiest way to have this happen is to delete scenery_packs.ini – the prioritization is lost and our airports end up on top.
- If you install a base mesh into X-Plane, it goes to the top of the priority list, which is stupid; it needs to be below all of the overlays.
What is particularly concerning is that users way of fixing this (going in and editing the actual scenery packs) is probably making the situation more complicated, not less. Here’s what I think needs to happen:
- Custom scenery authors need to start excluding their scenery. This isn’t a new rule; I consider it a bug to ship an airport without exclusion zones. If you have a custom scenery pack and it doesn’t have exclusion zones, ask the author to add them. It is not that hard to add a few exclusion zones in WED.
- Users need to stop deleting their scenery_packs.ini. The .ini file is there to help you resolve conflicts, but it won’t work well if you constantly delete it. Once you set up your priorities properly X-Plane will not change them! Put your base meshes on the bottom, default airports in the middle, custom scenery in the top, and you are ready to go.
- X-Plane needs to get the priority of base meshes correct when they are first installed – the fact that users have to go and ‘fix’ the scenery packs list is really annoying. We are looking at ways to fix this now, but unfortunately we don’t have any plan that we can execute in 10.25. This is high priority for a future update.
- X-Plane needs to keep its own overlay scenery (the airports we ship, the demo areas) at a lower priority than any custom overlays that users add. This is the expected behavior and should be totally automatic.
Exclusion Zones and Custom Scenery
A number of authors have rightfully complained that the exclusion zone is a blunt object and doesn’t provide a way to carefully integrate autogen and custom scenery.
I agree, but I consider the problem to go significantly beyond exclusion zones; there is no way for a custom overlay to “edit” base vector data (e.g. to say “I want to move that road over there.”) The underlying data doesn’t have any kind of identifier to refer to it, and the underlying data can change if we recut and take newer OSM data.
I think the future solution to this lies not in more precise or powerful editing in overlays, but rather in the fact that we’re getting more network bandwidth, and the global data we have access to is getting better. Therefore the solution is to (1) push updates to the base scenery and (2) ensure that the base scenery is correct. With this process working, misalignments between custom scenery and the default scenery will be less important, and authors can simply fix small but ugly bugs in the base scenery (via OSM) and the result will be better scenery alignment in an update.
It is possible to include exclusion zones in an airport you share with the global airport database for inclusion in X-plane; some authors have already done this.
There are some cases where an exclusion zone is a must-have:
- If the airport gets a new runway, there will be autogen in the location where the old runway used to be; a draped polygon + exclusion zone can “clear” the area for airport.
- If the airport has trees on the runway (a bug in the default scenery) you can “fix” the bug with an exclusion zone.
The global shared default airports are one case where I don’t think we need complete exclusion in an overlay – they are meant to be the lowest priority overlay, and therefore don’t need to exclude other scenery.
Therefore the solution is to (1) push updates to the base scenery and (2) ensure that the base scenery is correct.
Crowd sourcing scenery with quality control is a great idea. Success will require a motivated crowd. One of the great motivators is the idea of mutual sharing (particularly when credit is assigned). You have used prizes to motivate too.
A challenge is to keep a motivating workflow; I see two looming barriers.
(1) There may be a lag between doing the work and reaping the benefit. This is significant when editing OSM to see the result in a future sim update. There is also a delay between sharing a scenery via sim update and receiving end-user thanks.
(2) Management of conflicting submission and/or low quality submissions, may demotivate.
Have you had any thoughts on these potential issues?
We’re discussing the submission process internally now.
There is a problem with testing scenery exclusions zones. That is, you have to exclude things that may appear in the future – whatever they may be. How do you test for what may occur in the future? You can’t, so you simply exclude everything you can exclude in a 1km radius of the airport.
It makes you wonder why the airport boundary doesn’t simply exclude everything that can be excluded since anything not excluded may appear in the future and compromise your scenery.
I’m sure scenery developers in the past – keen on keeping frame-rates high, have avoided adding anything that is not absolutely necessary. Including excessive exclusions. Do exclusions have any significant cost in cpu – or is the excluding cost offset by not rendering excluded bits?
Exclusions don’t cost you anything in fps. They cost you a little of time at load to examine data and see if it needs exclusion. But they’re pretty fast, and if you exclude something, you don’t pay for it later (either in setup or fps).
The airport boundary doesn’t exclude things because it isn’t obvious what we’d want to exclude. For example, OSM highways often enter the airport area, and that’s usually a good thing. (Also the exclusion system needs AABBs, not polygons, but we could convert the boundary polygon directly to exclusion zones IF we thought it was a good idea.)
I totally agree with Ropeless,
A simple page that lists the airports,authors,like/dislike (rating) will be a great boost for the authors. The rating should be implemented (simple counter + captcha) that allow the simmers to vote.
The scenery that receive high “dislike”, might be reviewed and re-considered by Laminar team.
Simple intuitive and rewarding.
I had some idea about automatic generated exclusions. It should be not so complicated to make a programm which analyses the apt.dat of airports. There it could get the top left and bottom right koordinates. Than it would generate a scenery just with exclusions.
The user can than bring this exclusion scenery between default scenery and his other sceneries.
Why not make the airport boundry double as an exclusion zone?
i think so too. might be better to have ‘inclusion’ zones if really required…
Ben: Your descriptions above are a great help. Could you expand a bit on the way exclusion zones work and how they affect roads in particular. IE: When you place an exclusion zone, and it overlays an object or a road, what is the criteria for its amount of overlay to mask the underlying object, and are excluded “types” masked with different rules? (forests, objects, roads, fences & facades).
Because exclusions are necessarily global “squares” the pain of producing a precise exclusion will benefit very much from the above requested into.
Thanks again!!
Hrm – there are no docs on exclusion zones? I better write something specific. 🙁
creating my airports with wed i do not have scenery/osm information available anyway. i’dd be more than happy with everything excluded by default within airport boundaries…
I agree that the airport boundary should function as an exclusion zone maybe with a yes /no choice in WED. Some of us want to add things that are near the runway but not necessarily part of the runway,i.e., a big building that is against a taxiway and do not want trees growing into or next to it. If we can include the object inside the airport boundary, and that was part of the exclusion zone, we could make the airport look more like the real thing. If there is a conflict about a road being inside the exclusion zone maybe a road object could be available to drop in to recovery the lose of the road. I know that was available in OE. I can imagine people would be willing to give up a few feet/mile of road to get the benefits of boundary/exclusion zone.
Fred