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

Category: Scenery

New Python tools for working with airport data

Over the weekend, I published a Python package called xplane_airports. This serves two major use cases:

  1. Parsing the airport data (apt.dat) files used by X-Plane, and asking questions like “does <some airport> support <some feature>?”
  2. Nicely wrapping the X-Plane Scenery Gateway’s API to get information about the airports available there. This includes the ability to download scenery packs and manipulate them just like you would an apt.dat on disk.

If you’re doing any sort of automated analysis or manipulation of X-Plane airports, this should be a huge help.

It’s available via pip now:

$ pip install xplane_airports

And there’s a ton of documentation in the project’s README on GitHub.

Bug reports, feature requests, & pull requests are all welcome. 🙂

Posted in Tools by | 20 Comments

WED 1.7r1

Release candidate builds for WED 1.7 are now available for testing. A big thanks to Michael for leading a lot of this development. He kept all this moving along at a much faster rate than if we’d been left to our own devices! Here is his summary of the changes you’ll find in this version:

Selection of items

When selecting any item in the map pane, WED now prioritizes the items by a what appears to be on top when viewing the scenery in X-plane. So if you click on any .OBJ in the middle of a taxiway – it always selects the .OBJ, line marking or ground painted taxi sign rather than the underlying taxiway. Similarly, it selects the facade or forest rather than anything that is flat and draped on the ground.

Technically, this means object type and LAYER_GROUP rather than WED hierachy based prioritization.

Exclusion zones and airport boundaries are now kindof “hollow” items, they can no more be selected by clicking inside of them, but only by their frame/outline or perimeter. That should greatly help with not having to lock or otherwise get those large area items out of the way.

All items can now be single-click selected, even if they are located within the area of an already select item. This eliminates the need to de-select (CTRL-D) e.g. a taxiway every time the last attempt to click select a .OBJ turned out to be just a bit to far away. And therefore accidentially selected the whole taxiway underneath it instead.

Drag-moves are now subject to some “stickyness” , i.e. the move/copy only starts after the drag exceeds a few pixels. This helps avoiding accidential very short distance drag-moves. Once the item has “broken free”, the item can be moved back to within a single pixel of the initial location, so small moves can still be achieved.

Several bugs that prevented adding bezier handles to nodes under some conditions or selecting very closely spaced items are fixed as well. All operations now require a click no closer than 4 pixels from the “correct” location. Any very closely located items having the same piority (like two nodes of the same polygon) are now selected using a “whatever is closest” strategy, rather than having overlapping bounding boxes prevent access to all but one of them.

Validation warnings and results browser

Some validation issues can now be a warning only, rather than a hard error. This allows WED to try more validation of frequently found problems, even at the risk of creating a few false alarms in rare cases. If such a warning is ignored for gateway submissions, the gateway moderator will determine on a case-by-case base if the issue can in fact be waived or still reject the scenery submission.

After validation, a full list of ALL validation issues will pop up, allowing to browse and zoom to / highlight all issues to help planning out the work required to pass validation. This also allows to select multiple validation errors to e.g. select ALL duplicate vertices in ALL polygons – allowing to fix all with a single editing operation.

New validations

Validation now catches all types of self-intersecting polygons. Previously there were certain cases of bezier-curves that caused taxiways/polygons to stop showing up at certain zoom levels or not at all in X-plane, despite they looked fine in WED or vice versa.

The coordinates and names of runways need to be exactly in sync with the CIFP data used by X-plane for FMC SID/STAR and GPS approaches. For this reason, gateway airports are occasionally edited by a script by “WEDbot” to achieve this, but any user re-submission that touches the airport may break this effort. WED now validates the runways against CIFP data oit obtains direct from the gateway server and requires the runway threshold to be within 10m of the exact location. Note this is the thereshold – the wide white bar only.

There is a separate warning only if the displaced part of the runway (the optional part from the end of the runway to the threshold – with the centerline arrows pointing towards the displaced threshold) mismatches official documentation. Some of the CIFP data mis-states that displaced distance, so it is a warning only. Please thoroughly verify such warnings against current orthoimagery and draw as per current real world markings.

A *lot* of ATC flows on the scenery gateway are non-functional because of misunderstandings how flows work. The most common mistake is to define one flow per runway and then expect that X-plane somehow finds all flows that fit the current weather pattern and uses them all togther. But that’s not how flows work. Validations will now try to find such duplicate condition flows (that are effectively never ever used) and will warn about it.

The airport naming is covered by several new errors (like ALL CAPTIALS – THATS SHOUTING IN THE INTERNET AGE !) and warnings if undesired elements are included in the names.

Smart runway rename

When a runway is re-named due to magnetic variation changes, not only the runway name, but also all ATC taxiroutes, flows and taxisigns need to be fixed up to reflect the changed designation. WED now will detect such edits of a runway “name” property, find all these references, update them and let you know. This greatly helps when the runway validation tells you it’s missing some runway at that airport – which usually means some existing runway was recently renamed due to magnetic variation changes.

More library item previews

Type 1 facades are now displayed in the library preview panel. Please be patient – the more complex “type 2” facades as used in all airport terminals and the new terminal kit are not showing, yet.

Many library items come with multiple variants that X-plane will select at random from when placed in the scenery. For such items, a button will show up to view each variant. But keep in mind – there is no way to tell X-plane to always use a specific one. Its just a true “FYI”, only  …

All forest/facade/object previews will show some textual information about their size and features available.

The World Map in the background now has 9x the resolution and shows true X-plane ground texture colors.

ATC taxi route names are displayed in the ATC TAxi & Flow view – please verify them for consistency, as the X-plane ATC uses and even speaks these names when providing taxi instructions.

Don’t import from the apt.dat for gateway airports

The apt.dat and .dsf formats are lossy, i.e. they contain less information and use less precision than a direct import of the airport from the scenery gateway. WED will now warn anytime it detects such an import for an gateway type airport.

Upon im/exporting to/from the gateway WED will now also show warnings if the gateway is currently not accepting new submissions for that particular airport.

Facade editing

Facades without roof’s or filled areas, like fences and skylights in the XP11.10 terminal-kit are now allowed to have 2 nodes only – previously facades of any type had to have 3 nodes minimum.

Two bugs were fixed, too – these prevented selecting certain wall types in the terminal-kit facades and displayed some facades as being “closed rings”, rather than line-type items in the map window.

Orthophoto import

Georeferenced image “geotiff” import used to require mercator projected, WGS84 referenced coordinates. On Linux and OSX it will now understand pretty much all coordinate systems defined in the EPSG standards – although WGS 84 lat/lon coordinates are still the preferred encoding.

Display speed and memory use

When zooming in at airports with very large, single piece taxiways, the WED display speed used to slow down significantly.

The 64-bit versions of WED (OSX & Linux. Windows is still 32 bits, only) used a lot of RAM with large sceneries, e.g. im/exporting the *whole* global airport scenery (thats what WED is used for at LR, all 28,000 airports in one scenery !) maxed out a 16GB RAM machine. Now its down to near half that and everybody else gets a small speed boost, too.

Preferences menu

Some user adjustable settings (like meter vs feet) are now moved to the File->Preferences (OSX: WED->Preferences) menu, stored in WED’s global preferences and no more loaded/stored with each individual scenery file.

Posted in News, Scenery, Tools by | 6 Comments

Lets Talk About OBJ Importers (For The Last Time)

(This post was edited to reflect a discussion Ben and I had)

A constant request for XPlane2Blender and other exporters maintained by Laminar Research is an import OBJ feature. So, one last time, here is the news: by now an importer is basically never going to be a part of XPlane2Blender, but it could be its own project! It could take years of development to make it very well polished, however.

There are a few projects started on the forums you can checkout if you’d like!

Why Is This Such A Hard Problem?

It is simple to read the vertex table, attributes, animation keyframe table, and turn that into Blender data, some projects can already do this, in fact. The trouble is getting the exact or nearly the exact .blend file back.

OBJs Don’t Save Everything You Want And Need As An Artist

Some of the things things you could never import from an OBJ

  • Window Settings
  • Text Blocks with scripts, notes, or annotations
  • Any non-XPlane2Blender Blender settings we don’t care about
  • Object, layer, material, and texture names
  • A bunch of settings that can’t easily be inferred (more on that later)
  • Blender’s parent child relationships

If the OBJ was produced with comments and correct indentation, you might be able to get some of these things back (likely just a few names.) A large complex Blend file without this stuff is a nightmare of an unorganized mess and would make the rest of the manual reverse engineering process even harder.

Multiple .blend files Can Produce The Same OBJ Content

If A.blend, B.blend, and C.blend can produce the same OBJ, which one should the OBJ be reversed engineered back into? The relationship between XPlane2Blender settings and what appears in the OBJ can be very esoteric and there is not always a 1:1 relationship. Some ATTR_s only appear when certain combinations of settings are used. You may find there are absolutely no good defaults.

A Moderately Smart Importer Would Need To Know Massive Amounts of History Of All Exporters

In order to perfectly solve these ambiguities and produce .blend files that are similar to what originally exporter the OBJ file, it would be incredibly useful to know about the behavior of the exporter that exported the OBJ in question. This means an importer would need to know all the bugs and features of every exporter, and we don’t even know that after developing the exporter. Bugs are waiting to be discovered, or used by artists until they have to be turned into a feature. Our exporter currently struggles to take into account past bugs, and that’s the exporter!

This turns into it’s own ambiguities to solve: “Is this OBJ’s mention of deprecated ATTR_s a choice the artist made. despite the deprecation warning, or was it a bug that this was still getting written, or was this OBJ written before it was deprecated?” Now you’re messing not only with valid or not, but what the OBJ is supposed to look like.

Optimizations Create Further Challenges

Exporters often take optimizations to improve an OBJ’s performance and quality. For instance:

  • Removing duplicated vertices, keyframes, attributes
  • Rounding or changing data on the fly
  • Ignoring or appending ATTRs to handle deprecations or obsolete OBJ features

Now you will have even less information or, now, seemingly incorrect information! OBJs are meant for X-Plane, not humans. As such exporters can take many liberties with the content of OBJs as long as they match what the artist meant. This can result in very complex optimizations that might even break our own guidelines, all to deliver the best (and deliver on time) to the consumer and our artists. This makes developing an importer that reproduces the importer OBJ, either exactly or simply visually matching (let alone animated or textured properly) even harder.

In a raw .blend file, objects are like Lego bricks which get baked into one solid piece. Going in reverse will likely not get the same neat separation. Blender is not smart enough to tell what is a wing shape, what is a wheel shape, what is a throttle level shape. It may be impossible to separate the vertices back into these distinct meshes (especially after optimizations)! Making a “really smart” importer that is shape aware is a brutally hard algorithm that the world’s best computer scientists are still attempting to solve. It may not be challenge you want to take on.

We May Build A Reasonable Importer One Day!

With all these challenges, an importer would have to be willing to not handle all edge cases and not attempt to reverse engineer an OBJ back to the exact .blend file that made it. For instance, a 3 year old OBJ would not be reversed engineered into the .blend file that produced it 3 years ago, especially since an artist would want to then update their assets anyway! Having art assets “marooned” on other exporters or “dead” is a pretty terrible waste of time, likely be more painful than hand fixing all lot of little things. As Ben pointed out “If we can’t make a direct import [.skp->.blend, .ac->.blend] path, OBJ import is the least bad option.

2.49 to 2.7x Converter

A 2.49 converter is a much more manageable project (far on the back-burner.) The complexity of this tool is much more manageable, because the 2.49 is not in active development and you are converting .blend to .blend, not .obj to .blend. Blender to Blender is something which Blender is already very good at.

Posted in Aircraft & Modeling, Development, File Formats, Scenery, Tools by | 2 Comments

XPlane2Blender v3.4.0-rc.1

XPlane2Blender v3.4.0-rc.1

We made it people!

Change log

This release encompasses all of the beta. You can read through the beta notes for more details, but, here are the highlights:

New Features

  • Single button to “Export OBJs”, skipping the file selection box
  • Autocorrecting spot lights – the light points where you point it, not where the parameters tell it to go!
  • X-Plane 11 support for Blend Glass, Normal Metalness
  • New clean UI, better laid out, more consistent look, and some properties smartly hide when they’re invalid or not relevant
  • Support of 1 LOD box
  • Enhanced build number and plugin history to help debug files and track update problems. After installing this rc.1 version, your scene settings should look like this. The green check mark means “most safe” to use.
    rc1_release_pic
  • No more reading the lights.txt file. The list of lights and their parameters can now be found online
  • Though unsupported and largely irrelevant to most authors, a “Plugin Development” section has been added with some neat tools that you probably shouldn’t use.
  • EXPORT directive (really only useful for LR toolchains. Documented here for posterity’s sake)

Important bugs

  • Animations have been optimized
  • Bones, nested bones, and complex parent-child relationships with armatures now work better,
  • Animation types have been synthesized to just Transform, Show, and Hide instead of Loc, Rot, LocRot, Show, Hide

We could not have gotten this far without the incredible support of our beta testers, new authors, bug reporters, and all the wonderful artists who give us the inspiration and energy to make this product better! It has been an incredible journey diving into this facet of the community and I look forward to even more releases, including VR manipulators, full WYSIWYG lights, and more!

Thank you!

Posted in Aircraft & Modeling, Scenery, Tools by | 1 Comment

XPlane2Blender v3.4.0-beta.6

XPlane2Blender v3.4.0-beta.6

Change Log

One big massive bug fix! (and some optimizations!)

#264 caused some people’s lights to be put in the wrong place. The fix involved Ben coming up with awesome math to put things back in their place by a certain offset, and then us creating a way to parse the light.txt file that controls much of the lighting in X-Plane.

This Changes Nothing in Your Blend files!

Seriously! No Blender data should change!

However, It Could Change Your OBJs

XPlane2Blender is now more consistently WYSIWYG! Meaning that if you point a spotlight at a wall, it should show up pointing in that direction, regardless of what a named spill light thinks or the parameters of a param light think.

This is good news for new authors and authors suffering from the bug, but depending on how you’ve been making your lights appear rotated, it could result in needing to change the rotation or parentage of existing lights.

What Lights Are Affected?

All of the following conditions must be true for a light to be affected by this change

  1. Be a Blender non-point light, for instance a spot light
  2. The light’s XPlane Type must be Named or Param
  3. The light’s XPlane Name must be found in the lights.txt file inside the addon’s new resource folder

In rare edge cases, special and less used lights will be excluded from auto correction.

So, as you can see its either somewhat common or very specific which lights are affected. So, if your eyes haven’t glazed over yet,

Please Send Reports Of How This Affects You – Good, Neutral, Or Bad!

We try our best for backwards compatibility and a bug free existence, but we don’t know everyone and their situation until they say hi! If you are faced with large hurdles to continued productivity, please file a bug! Preferably with before and after pictures and .blend files. Automated fixes may be developed for people affected.

This is just one step to a more WYSIWYG XPlane2Blender.

Posted in Aircraft & Modeling, Development, Modeling, Scenery, Tools by | 7 Comments

Break ALL the airports! Correcting runways in WED 1.7 and X-Plane 11.10

X-Plane 11.10 brings a few changes to how airports, the airport gateway, and navdata interact.
Many pilots who try to fly realistic IFR operations with the X-Plane built-in GPS or FMS will have encountered this dreaded window already:

runway 12L not found at Vero Beach Municipal airport

The reason for this is that coded instrument flight procedures (CIFP) come from very reliable sources – Jeppesen or LIDO (depending on whether you get your data updates from Navigraph or Aerosoft), while the runways on X-Plane’s airports come from a community driven, open database: The X-Plane airport gateway.

Unfortunately, the airport gateway community is not always fast when it comes to runway renames or airport expansions, which happen all the time all over the world. The most common reason for a runway rename is a shift in magnetic variation: Runways are named for their cardinal direction relative to magnetic north. While the runway’s orientation with regard to true north is fixed[citation needed], the orientation measured against magnetic north changes over time, as the magnetic pole moves and local magnetic declination changes. Now when the magnetic course of runway 11L changes from 114 to 115 degrees, airports paint new numbers on their runways. 11L-29R becomes 12L-30R. Jeppesen knows about this and changes the runway name in all their data, which ends up in a data update for X-Plane. Meanwhile, the scenery author community over at the airport gateway of course has more exiting things to develop then a runway rename.

To make things worse, runway renames are super annoying in WED. After you renamed the runway from 11L to 12L, you had to go through ALL your flows, ALL your taxiroutes, and ALL your airport signs to change the name EVERYWHERE.

In the past, we have partially solved this problem by running mass renames of runways in the gateway database rather than through WED. If you see a change on an airport made by a user named “WEDbot” (like at this airport) that is usually such a batch-rename.

With X-Plane 11.10 and WED 1.7 there are some big changes that greatly improve the interaction between X-Plane airport data, navdata, WED, and the airport gateway.

Easy runway rename in WED

WED 1.7 has a function that changes all flows, routes and signs for you when you rename a runway end. This makes bringing an airport up-to-date a nearly foolproof operation even for a WED-dummy like me. You don’t need to be a scenery wizard to simply fix an airport anymore.

Silent runway rename in X-Plane

If you have navdata from Aerosoft or Navigraph, and a runway in the X-Plane airport matches a runway coming from the navdata, but the name has changed, X-Plane 11.10 now silently renames the runway at runtime for you. Which means, even if a 11L is painted on the runway, the FMC can load the procedure for 12L and get you there. This only works if the scenery is properly georeferenced and the runway is actually in the right spot – if the scenery was made incorrectly and the runway is not at the right coordinates, this obviously doesn’t work.

Silent threshold fix in X-Plane

Not all scenery authors correctly place displaced thresholds. A bit of confusion exists over when to use the white arrows or the yellow chevrons – and which counts into the runway length and which doesn’t. I teach my student pilots “the only thing you can do on yellow chevrons is crash – anything but crashing on that area is illegal.” Hence this area doesn’t count for runway length. Again, if you work off a properly georeferenced orthophoto, you won’t have any problems. Unfortunately, if you misplace where the (displaced) threshold is, this coordinate problem can feed back into the instrument procedures of this runway. For example, for many non-precision approaches the MAPt of the procedure coincides with the runway threshold, so if those coordinates are off, so will be your missed approach point. With X-Plane 11.10, if a runway in the airport scenery matches a runway coming from your updated navdata, but the threshold is laterally offset from where it should be according to instrument procedure data, X-Plane silently moves the threshold coordinates the GPS/FMS works off to the correct location. This works if the scenery is “good enough” in that the majority of the runway pavement is where it should be, and the thresholds are only off in the direction of the runway. If the whole scenery is ill-referenced, meaning the runway is off other than along its major axis, this obviously doesn’t work.

Silent and not-so-silent feedback

If you have enabled anonymous data collection in X-Plane, whenever your X-Plane silently applies a runway name or runway threshold location fix in the background, it also sends a packet of data to our analytics server, telling us the airport you were approaching and what was up with the runways. Collecting this data from a wide range of X-Plane 11 users will allow us to generate a heatmap, i.e. the most important airports that need the gateway communities’ love. Note that this data is collected only if you are running navdata that is current – we are not collecting reports based on historical data.

Only if both of the above fail, which means the airport has both a problem with its runway numbering and is ALSO poorly georeferenced (runways are in the wrong location geographically) the situation is beyond fix for the new runway logic. Only in this case you will see the dreaded dialog, because the runway simply does not exist in X-Plane, at least not where it should be. In this case, you will be able to submit an automatic report to the gateway website if the problem exists with current navdata. Note that this dialog will come up whether you have enabled data collection or not – but you can still chose to close it without actually posting the report if you don’t want to.
Only this kind of “all is lost” reports are actually visible on the gateway website and the XSG bug database. This allows artists to see the only airports that are actually so outdated that they cannot be fixed automatically. The automatically fixable scenery errors no longer clutter up the gateway airport bugbase.

Any downsides?

The downside to all these changes is that they all actively work to keep the X-Plane default scenery up to speed with the airport changes in the real world. This means that over time, as our global airports follow the real world in terms of runway renames, airport construction, expansions, etc… it will become less useable without up-to-date navdata. That’s the price we have to pay for “as real as it gets”.

Break ALL the scenery!

Poorly georeferenced scenery has a problem beyond affecting the missed approach points of non-precision approaches. It also affects the ability to use the new SBAS (satellite based augmentation system) approaches that are comparable in accuracy to ILS. I always prefer to fly the LPV approach if given the choice. However, the FAS block (final approach segment) comes from the navdata, which means it guides you precisely to where the runway is in the real world. If the X-Plane scenery is poorly referenced, the approach will dutifully fly you into the grass in X-Plane, if this is where the runway would have been in the real world. This is obviously a problem for serious training scenarios. Therefore, X-Plane 11.10 can be started with the commandline option –accurate_runways which will dynamically rewrite the actual scenery in X-Plane after loading an approach, both moving the runway into the correct geo-location and also changing the numbers written on the runway if needed. This obviously only works on default scenery with the procedurally generated runway textures. It will not change custom scenery that uses draped polygons for photorealistic runway textures. Moving the runway into the correct location will obviously also disconnect it from any incorrectly placed taxiways. Also, using this option increases load times for selecting an instrument procedure significantly, since it has to rebuild the airport scenery. So this option is really only there to help you keep limping along with broken scenery, if your operation absolutely requires accurate runways and you can live with some broken taxiways. It is therefore not available as an “official” setting. Do not come to us to complain about the jarring results – make a proper fix in WED instead! The results can be quite disruptive, but at least the approach won’t guide you into the grass:

This LPV approach required the runway to be moved quite dramatically. See the taxiway that was parallel to the runway in the scenery.
A closer look at the situation above. This is an extreme example. This airport scenery had the orientation of the runway badly wrong. Note where the threshold was originally placed by the author where the taxiway now ends in the grass.

Posted in Development, Scenery, X-Plane Usage Data by | 28 Comments

Do Not Reference Libraries By File Path

This is never okay in a library.txt file:

EXPORT  lib/something.obj ../opensceneryx/object.obj

This is a library path that refers to a file outside its own pack by using ../ to go up a directory and hopefully find that OpenSceneryX is installed, at which point it assumes that it knows the internal layout of OpenSceneryX and exports the object.

Do not do this.

This will become a warning as soon as I can write some code.

This will eventually stop working completely, because it’s a terrible idea that I have said multiple times should never be done.

Posted in Scenery by | 17 Comments

XPlane2Blender v3.4.0-beta.3 is out!

https://github.com/der-On/XPlane2Blender/releases/tag/v3.4.0-beta.3


If you have been doing work with manipulators during beta.1, please download this new one and review the notes! Download the latest here: io_xplane2blender_3_4_0_b3.zip

Fixes

  • #ATTR_layer_group_draped causing KeyErrors
  • Reverts bad change to manipulators properties*

Adds

“.beta.3” will be printed on all OBJs. This is not permanent, expect something better in the future

What happened to the manipulators?

A poor decision to change the Manipulator Type (Drag XY, Push, Command Knob, Toggle, Delta, etc) means that if you changed the type of manipulator between beta.1 (or 7fe534ad1f906b7853827 if you constantly check out the latest cutting edge commits [which I do not recommend for this exact reason]), this beta will make those changes irrelevant.

Example, suppose on 8/1/2017 you create a switch and set the manipulator type to Toggle, then with beta.1 you change the type to Push. Beta.3 will show the type as Toggle. All you need to do is go back to the switch and change the type back to Push. The rest of the values you set will still be there. If you created manipulators during the beta, they will be set back to the default “Drag XY” type and will need to be fixed.

This is an unfortunate lesson to be learned, and if you are facing a lot of tediousness (30 manipulators to hunt down and change) or potential errors (you can’t remember how many or which ones you changed) please contact me!

I will personally help you recover the changes you made during beta.1 – present.

 

Posted in Aircraft & Modeling, Development, Scenery, Tools by | 5 Comments
  1. Pages:
  3. 1
  4. 2
  5. 3
  6. 4
  7. 5
  8. 6
  9. 7
  10. ...
  11. 43