Update: the comments form is fixed – sorry about that!

I’ve been working a bit on scenery tools this week. Here’s a road map of some of what’s coming up.

WED and the X-Plane Scenery Gateway

We are working on a release of the latest scenery gateway airports for X-Plane 10.45. Like all releases, we’ve found problems with airports that WED does not detect. So I will try to release a new version of WED with stricter validation soon.

Airport Parking Spots

Austin is working on new code to place static aircraft at unused ramp parking spots. I’l describe this in more detail in another post, but here are some key points:

  • As an airport author, you simply place ramp starts, not static aircraft.
  • X-Plane will feature some new static aircraft in the update.
  • Third parties can further add to the static aircraft and have them be used via the library system.
  • There will be a revision to the apt.dat format that stores more data per ramp spot and a WED update to support this new data.
  • Since there may be scenery now with static aircraft on top of ramp starts*, we will auto-remove static aircraft from ramp starts in the gateway export as a temporary measure until authors can resolve the situation and post the fixes to the gateway.
  • We are not removing the old static aircraft from the library, but we will be hiding them from WED’s library so that authors use ramp starts instead of placing them by hand.

Static aircraft in parking spots will ship next year, not this year, but is planned as a v10 update.

Scenery Tools on OS X

I made significant progress this week porting WED for OS X to 64-bit and modern Mac APIs. This effort basically meant rewriting the OS-level UI code in WED to be new AppKit based calls instead of the old Carbon API.

What this means is that developers will be able to build all of the scenery tools on a modern Mac running Yosemite or El Capitan with X-Code 7. Since Chris has already updated the projects to compiled WED in MSVC, a developer can build all of the common scenery tools from the most widely used open source IDEs.

It also brings us closer to a 64-bit WED on Mac, which is desperately needed since OS X provides the least amount of usable address space to 32-bit apps. I am not sure of the 64-bit status of the Windows WED build; it may need more work on the libraries.

Will It Blend

This might be the most significant scenery tools development: we’ve been working with Ondrej (der-On on Git-Hub) on new features for the Blender 2.7 exporter. This will include:

  • Much better animation support. Complete WYSIWYG animation of data blocks and bones, with no work-arounds needed. Bone animations match Blender 2.49 so you can move your projects forward.
  • Modernized material support including instancing for a really clean work-flow that takes advantage of X-Plane 10’s features.
  • Updates for the latest OBJ features.
  • Our plan is to create a migration script to bring 2.49 projects into 2.7, converting the special tags used for an X-Plane 2.49 export into 2.7.

Many of our artists still use 2.49, but there’s no question that 2.49’s days are numbered. It’s a question of when it stops working on OS X, not if. With the migration step, we can move our projects forward without artists having to redo work.

Like the previous 2.7 exporter, this one is open source and will be free, and should be able to export existing 2.7-type projects with no modifications – we are trying to maintain full backward compatibility.


* This situation is slightly silly – if the user picks the ramp start to fly, the user will be on top of a static aircraft.

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.

22 comments on “Scenery Tools Update

  1. Sure hope there is going to be a fail safe for static planes that will remove them if you pick that ramp start.

    i.e. start x-plane, x-plane puts statics, change ramp start, if x-plane put a plane there it will remove it. Or we are back in the “someone put a static on the ramp start”.

    1. Since Austin is still working on the implementation, I don’t know the definite answer, but my expectation is that when you re-initialize a flight, the static aircraft spawner (and dynamic aircraft spawner) can wait to see where YOU pick and then fill in the blanks – the two spawners need to not step on each other either. (Some time ago, maybe 1035, I set the dynamic spawner to try to keep each dynamic plane away from the others).

      If you maintain a continuous flight without restarting, well, don’t taxi into an occupied ramp position. 🙂

      1. “If you maintain a continuous flight without restarting, well, don’t taxi into an occupied ramp position. :-)”

        Well that goes without saying, as long as ATC does not send you to a spot with a plane in it. Since no way to pick what ramp you want (with ATC) after landing.

  2. Ben, I hope this system will examine and honour the equipment type flags on the start points. Otherwise Austin will probably get a whole new bunch of “there are jumbo jets spawning in the GA parking area” type complaints. Having the equipment type honoured on each gate/ramp for AI aircraft spawning would be welcome.

  3. Could you place a warning in WED rather than hide the static aircraft?
    I’m thinking of the airports that have statues of aircraft, the static aircraft are the closest approximation.

      1. Thanks, there are quite a few “hanger queens” that can be quite iconic among the locals, so I’d hate to lose the ability to place static airplanes. Otherwise, sounds great!

  4. excuse me sir,

    but, a while ago, you have mentioned about a possible development of an adequate X-Plane .obj export plugin for 3ds max, has been there any further progress on that matter?

  5. Any plans for an update to the AC3D plugin Ben?

    Its good to read that the blender plugin is being updated, but the AC3D one is lacking some features, such as the Anim_Loop command, and the X-Plane Properties Window has problems when lots of objects are selected.


        1. Maybe I’ve missed something in a new release but:
          – AC3D doesn’t actually support animation. My plugin tries to hack animation into place via plugin trickery. It’s barely usable. For example, you can’t edit your model unless it’s in its rest pose because the editor itself doesn’t know the crazy animation things the plugin has done.
          – Therefore there’s really no hope of doing skeletal animation, which is how the next-gen OBJ format is going to work. Every real 3-d modeler can do this.
          – AC3D doesn’t let you move a mesh without editing its vertices (or animate this way).
          – As you said, it doesn’t bake.
          – The number and power of modeling features, such as slicing, topology operations, UV unwrapping…it’s not in the same class as serious 3-d modeling programs.

          1. Thanks for the info. I’m still finding it pretty usable, but i wasn’t aware of its shortcomings. Makes sense that you wont be updating the plugin now!

  6. Hi Ben,

    Any chance to have a TMS viewer inside WED ? In know these are most of the
    time in transverse Mercator whereas WED is in spherical but on the scale of an
    airport the induced inaccury would not be a real issue.
    As you know many (most) of X-Plane runways are off by a few meters, sometimes
    more, I guess the reason is that not all users are able to provide the right geotiffs
    to WED and work with misplaced photos .

    Another suggestion : you have mentionned many times that WED development was
    difficult and time demanding. JOSM is a highly developed tool that works like a charm and has advanced tagging features (in addition to TMS, WMS capabilities and even
    reprojection of coordinates) . Wouldn’t a unique script to turn OSM files (with appropriate tags defined by you) to dsf (and back) a much easier way to go ?

    (sorry if this has already been discussed before)

    1. Hi Oscar,

      Please file a bug against WED for Mercator projection. If you have a good real-world example where (1) the error of not having a real projection causes an error and (2) the use case is realistic, please attach it so I can see what’s going on.

      Regarding JOSM, I’m not sure what problem you’d be trying to solve – WED and JOSM sort of work in different problem domains.

  7. Hi Ben,

    You read it too quickly I am afraid, I said the exact contrary, in particular I do not blame any WED bug but just point the lack of one (important to my mind) feature.

    I repeat :
    (1) WED does not have an automatic TMS viewer capability
    (2) therefore many users end-up stretching their orthophotos “by hand” when building their apt.dat file (of course I know it is not the right way to do it but this
    is just a fact) and THAT leads to wrongly placed runways.
    (3) I mentioned that perhaps you didn’t include such a viewer because that would imply some additional reprojections (which few viewers are able to) but said that EVEN not doing a reprojection wouldn’t be noticable on the scale of an airport (and you ask me to prove the contrary to what I said).

    On the second point: my viewpoint is that WED and JOSM are both tools to encode vector data (one in OSM format, the other in DSF, this a essentially a matter of translation). Since the latter is largely developped and also very good, I suggested the possibility to build upon it rather than building things from scratch (but I admit it is probably too late now).

    1. Ah – my mistake – I totally mis-read this.

      Yes, a TMS server is a possibility. But…where will the tiles come from? File a feature request with a -specific- tile server that we can use within our license that is useful to X-Plane users and I will take a look. (In the past, the only requests I have gotten have been Google and Bing – both license-incompatible.)

      I’m not that excited about WMS…I think the world has basically figured out that serving pre-cut tiles is a much better architecture than having the server do a bunch of poorly scaling server-side image processing every time the client scrolls. 🙂

      Re: JOSM, at this point so many of the high priority feature requests in WED are very X-Plane specific:
      – WYSIWYG Taxi sign editing
      – WYSIWYG facade editing and facade textured previews
      – Output to MeshTool
      – Writing DSF road networks

        1. Somewhere on the road map is to have -every- art asset have some kind of reasonably WYSIWYG (within the limits of 2-d orthographic projection) preview!

  8. One can use NoniMapView to download 4096×4096 px tiles including the lat/lon for each of the for tile corners in any zoom level and use a script which positiones the downloaded tiles via manipulating the file earth.wed.xml.
    This is exact.

Comments are closed.