Scenery Tools Progress? Yes.

I've been hacking at the scenery tools over the last few days...and I think we're making some progress.  I mention this because it can be hard to see the work getting done - there is nothing for months, then a new version of a tool.  (Well, now you can watch the code change as it happens.  If you don't think this like watching paint dry, you might be a geek!)  I also mention it because two of the biggest improvements aren't my own - they're insanely helpful user contributions.

The AC3D Plugin

Version 3.2 is now in beta.  Version 3.2 catches the plugin up with all of the latest OBJ tricks, including dataref-controlled LIT levels, manipulators, hard surfaces, etc.  This might be more useful for airplane modelers than scenery modelers, but I think the variable _LIT channels can be used for some interesting scenery effects too.

WorldEditor

WED 1.1 will go beta once X-Plane 930 is out of beta, and will feature (very primitive) overlay editing.  It's not a thing of beauty (yet) - the overlay editing features are leaner than the airport editing tools were.  But 1.1 will allow you to edit an overlay and airport in one workspace.

I can tell you now that the area where WED 1.1 is weak is preview.  But I don't want to hold off the ability to edit overlays in WED "at all" just because it's not as nice as it could be (and someday will be).

It should be possible to work on an overlay project in both WED and OverlayEditor - for example, you could build a taxiway layout in WED, using the overlay capabilities for custom pavement and lines, but use OverlayEditor to place 3-d objects (with a 3-d view).

MeshTool

To be blunt, MeshTool in its current form is really hard to use.  Part of that is expected - MeshTool is a "back-end" tool like DSF2Text, aimed to simplify the problem of creating base a base mesh for some other program.  But even as a back-end, MeshTool is difficult to use because it has bugs in its polygon processing, which often result in cryptic and hard-to-diagnose crashes when used with even relatively simple input data.

The good news is that I have my base mesh generation code running with a new polygon processing library (CGAL) - the switchover from my old buggy code to CGAL was done by Andrew and contributed back as a patch.  I've been throwing all sorts of weird data at the polygon cutting algorithms and they are rock solid.

The mesh generation code is part of MeshTool, so the next build of MeshTool will feature these processing improvements.  That's where Janos' extensive work on the build environment comes in - he's basically turned the scenery code from a big pile of my mad ramblings into a sane multi-platform project.  This will mean a much simpler, faster process for releasing tools, particularly on Windows and Linux.

(Previously once I got a tool working, I would have to waste a few days trying to get the code to work on Windows too, slowing the whole process down.)

I expect to recut the "scenery tool" pack (that is, MeshTool, DSF2Text, and all of those other smaller apps) some time during WED beta, after 930 goes final.  If all goes well, there should be native versions of the command-line tools for Linux.

MeshTool Needs a UI

Fixing MeshTool's polygon processing is necessary, but not at all sufficient to make it a useful tool; to be really useful, it needs a real user interface.  I think there are two strong possibilities for this:

1. WED could develop base mesh editing.  Under this scheme, you would be able to draw land use polygons in WED and create a "DEM" object for the elevation.
2. MeshTool could be an output option for QGIS (via some kind of plugin or script).

I don't know which it will be yet.  The advantage of WED is that an author could have all scenery elements in one place.   The advantage of QGIS is that it contains advanced GIS features that I will probably never put in WED.  It may be that QGIS's UI is simply not intuitive to less advanced users - I don't have good perspective on this.