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

Why the nerdy recursive acronym for WED?  Sometimes the data just stares you in the face.

I spent an hour today doing inventory on the build-up of WED bugs. That’s a screenshot of one of my bug screeners for the public scenery tools bug base – open bugs in WED 1.2b1 sorted by severity.  Notice a trend?  100% of the crash bugs come from the import/export module.  In fact, export bugs dominate the crash+major category too.

At this point I believe the DSF overlay export code simply needs a rewrite. The current code converts the polygons from my code to CGAL, then attempts to chop them up to fit into DSFs, and then converts them back and exports them. To put it mildly, this code is not working well.

As far as I can tell, CGAL 3.9 (the version we use) has reliability problems on Windows when processing Bezier curves.  I don’t know if it’s a build environment issue, something I did, or their bug, but I don’t trust the code path; we don’t use CGAL’s bezier curve processing for the global scenery project, so we don’t have strong data that this code will ever work.

Why Do We Need to Cut?

The current WED export code chops up your polygons to fit them into the DSF tile boundaries, because everything in the DSF must be contained within the DSF, right?

Well…

There’s actually nothing in the DSF file format to disallow ‘overhang’, e.g. a facade or some other shape that is partly in the DSF.  And for custom airports, having to cut buildings down the middle at lat/lon boundaries is unfortunate – the results can look ugly.

Unfortunately, as of this writing, X-Plane 10 requires the DSF to not “spill over” its boundaries.  But it looks like this could be fixed.

Multiple Export Fixes

This is my plan for fixing WED export, more or less:

  • WED will provide a “target” X-Plane version, e.g. 9.00, 10.00, 10.30, etc. This will select what kind of export features it can use.  If you try to export a project using a feature that cannot be supported (e.g. custom facade walls to a v9 airport) you will get a warning or error, depending on the nature of the problem.
  • WED export will not attempt to cut overlay data on-the-fly; rather it will either export the geometry spilling over the border (if allowed by export target version) or flag the span as an error.
  • An edit menu tool will be provided to cut geometry at DSF borders, for at least some DSF geometry types.

Why make border cutting a manual step?  I think that it will be more useful for authors to see the result of the border cut. For example, when a facade is border cut and has unique wall choices, the author has no control about the wall type of the wall that was introduced to span the DSF border.  With pre-cutting you can slice your facade, then pick a ‘safe’ wall type for the two walls that face each other at the DSF border.*

WED will currently refuse to border-cut some geometry; I think this will continue in 1.2, albeit this will happen in the “cut at borders” command – if you request to cut a bezier type WED may refuse.

* No matter which way you slice it, cutting facades at the DSF border sucks. This is why I think the long term solution is to allow facades to span borders, at least a little bit.

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.

15 comments on “WED: WED’s Export Dies”

  2. That’s a screenshot of one of my bug screeners for the pubic scenery tools bug base
    Nice Freudian slip Ben, you probably meant you where killing bugs on the Mount of Venus ? 😀

  3. Sounds like a lot of work. Why not lock WED for v9, except for any bug fixes (ie., no more additional features), and only one for V10, which gets most of the development effort?

    1. In the long term that’s what we’ll do for sure.

      In the short term it’s a question of the cost of doing multiple releases with multiple betas vs. having ‘optional’ functionality.

      I must admit, I need to look over the feature spec more carefully — I thought (from a while back) that there are features in 1.2 that are highly desirable for X-Plane 9 that warranted a cross-sim build.

      Edit: actually, I think we need an ‘export target’ no matter what. For example, the set of features you can use and still submit an airport to Robin is much lower than what you can do in custom scenery – we won’t accept custom objects in an airport submission, or third party library parts. So if nothing else, we need the idea of ‘export target’ to do DB submissions.

      Add to that that scenery system feautures are sometimes added in point releases, and we’re likely to have multiple v10 export targets, e.g. 10.20, 10.30. At that point, we might as well make v9 an export target and go home happy.

      The author can basically answer one question that he or she should really know the answer to: what is the oldest version of x-plane I expect my users to use/want to support.

      I believe this idiom can work because it is already used for software and OSes – when you build an app, you pick the OLDEST OS you want to support, and the programming tools yell at you if you use a feature that demands the new OS.

  4. Purhaps there still is bugs in the traits class Arr_Bezier_curve_traits_2 within the 2D arrangement of bezier curves? Try upgrading to version 4.2

        1. I did not promise you a 32-bit build in that comment.

          To follow up on the inquiry: I cannot build a 32-bit WED. I do not know if a 32-bit WED can be built for Linux by those with 32-bit distributions. You can download the latest source and try to compile it. I do not have time to work on a port back to 32-bits for WED for Linux.

          1. A Linux user who doesn’t compile from source … Does this mean Linux is now main stream? I didn’t think I would ever live to see the day. (wipes away tears from the eyes)

            Anyways all kidding aside, the current source compiles and runs nicely on 32bit Linux (built it on a small atom processor). Just one question, will MeshTool also receive a similar treatment? As I recall the height map in DSF v10 is not stored as a vector but as a raster. Or will the cutoff for V9 mesh generation be the current MeshTool?

          2. First, thanks for the confirmation that the source actually builds. 🙂 Generally, I’m happy to take patches (or GIT pull requests) from Linux users who have fixed distro/compiler/whatever related problems but I don’t have the time/resources/expertise to go after those things myself. I do my best to not screw up the kinds of cross-platform fixes people send in.

            Re: MeshTool, there is a definite cutoff: MT 2.x will build v9 meshes (which work in v10) and a 3.x stream will build v10 meshes. There is one more patch coming to MT 2.x: RealScenery got me a repro case on a bug I had heard about before (smeared edge textures) and I now have a fix; I’m hoping to get a build of that cut this weekend. (The patch is available in source in the meshtool_200_release branch.)

            I don’t know what the timeframe is on MT 3.x for v10 support, but it’s definitely a different major version. MT exposes the DSF-generating GIS algos we use to make the global scenery, and that stuff got heavily worked over for v10.

  6. Hi elpresidento,

    If you want a 32bit version of WED, you can download a build I did.
    Just navigate to this link and pick the relevant download.

    Good Luck

Comments are closed.