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?
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.