WorldEditor 1.4 is almost ready for beta, and among its new features (there are several big ones) one is very important to the X-Plane Airport Gateway:
- WED 1.4 can browse airports on the gateway and download scenery packs directly into the WED workspace.
“Direct download” is really important for a few reasons, some of which might not be obvious:
- It saves time. Getting a gateway airport, even if you just want to look at it, is much faster when you don’t have to download the scenery pack, unzip it, install it, then import it into WED. Once you use direct download, you’ll wonder how you lived without it.
- It prevents mistakes. We have seen airport submissions where a user clearly downloaded a scenery pack, imported only the apt.dat (but not the DSF files) and then uploaded it. We cannot take scenery packs like that, because they fundamentally remove the 3-d data from the airport. (A fundamental policy of the gateway is that if you upload a scenery pack and one already exists, yours can’t be worse than the existing one in some way. We have to always move forward.)
- It provides ancestry information. When you download and then upload directly from the Gateway in WED 1.4, WED provides the scenery pack ID of the original pack as the “parent” of the new pack. This means that when Julian goes to look at an upload, he can look at the “original” and more rapidly spot problems. If your pack is the same as the original except for taxi signs, he only needs to inspect taxi signs.
- It prevents data loss. DSF is a slightly lossy data format – that is, if you get your data back out of a DSF file, it won’t be exactly the same as what you put in. (It is like a JPEG image in that regard.)
More on that last point: DSF stands for Distribution Scenery Format – it was meant as a way to make final scenery packs; it was not meant as an interchange format for continuous editing. So users are constantly importing and exporting DSFs to do work, small rounding errors (“bit rot”) will creep into our 3-d, and features that were perfectly aligned might not be well aligned after 4 or 5 edits.
The internal format for scenery on the gateway is not binary DSF files, so doing round trips to the gateway has much less “bit rot” than importing scenery packs.
Finally, DSFs are tiles; if your airport spans a DSF boundary, all DSF features (polygons, fences, etc.) get split along the DSF boundaries.
So if you import a scenery pack that you downloaded, you’re getting the split version, which is harder to edit and work with.
The internal format of scenery packs on the gateway is not split, and thus you can edit the original in almost the same form as it was uploaded.
WorldEditor 1.4 beta should becoming in “weeks” (and hopefully not that many weeks); I’ll post here when we are ready for beta testers.
really nice to know that a new version of WED is coming!
The thing I didn’t like about WED1.3 is that creating photo-scenery using GeoTiffs is more complicated task… we need to manually create POLs for each Tiff , in WED1.2 there was a special command for that (that’s why I’m still using WED1.2).
But I saw a new command for importing orthophotos , however it’s a bit buggy as GeoTiffs that used to be imported OK in WED1.2 , aren’t imported in WED1.3.
So is there any changes coming in terms of creating a photo-scenery pack in WED1.4?
In WED 1.4:
– Geolocation works on GeoTIFF and GeoJP2K (for those who are into jp2k).
– orthophotos are created using the new process: pick an image, we locate it, we build the .pol for you.
So I think it fits your needs: no manual creation, correct auto location.
Sounds great!!
Will the pols will include LOAD CENTER?
And also , will it be possible to import multiple GeoTiffs per one import?
Really looking forward for the new procces.
Yep – one of the big wins here is that the load center data is done for you, and is correct – that stuff isn’t easy to calculate by hand.
I think right now it’s one at a time. I don’t have cross-platform import dialog box UI code for all 3 platforms…once we get that, we can make almost all menu functions multi-file.
will it be possible to use WED in ‘full 3d’ mode just as we use the Overlay Editor with having 3d/perspective view of the 3d objects we place?
No.
This is good news! But I know this has been asked in past but is it possible to include a WMS overlay feature WED 1.4 ? Because it is a really cumbersome process to have to manually download an image and align it before you can begin tracing facades, and placing buildings for your airport.
First: I don’t think WMS is going into 1.4. 1.4 is nearly feature complete so I can’t delay it (and delay critical featuers and bug fixes) to go START WMS now.
But WMS is not a bad idea. Here’s what I need:
– A bug report with the feature request (in the WED bug base) if it doesn’t exist.
– That bug report needs to include a reliable WMS I can test with that provides useful coverage of some area.
Love that post. Will be waiting for new wed thank you
Great news for this WED-addict!
Especially the ability to immediately get a picture underlay which is aligned correctly will increase my productivity by like 20% – entirely too much time was lost in making google-earth images, geo-referencing and aligning them.
I even used Overlay Editor sometimes to place some “helper lines” in my scenery, because that program supports direct display of Bing data.
The other three major speed and convenience bumps in WED for me are
1.) previewing facades (and what height properties they can achieve)
2.) showing data from my X-Plane installation (where the navaids are, where the roads run, where autogen areas are)
3.) Exclusion zones that are free-sizeable polygons and actually work as expected (i.e. not having to use “roads” to suppress power lines, actually excluding features whenever within the rectangle, not only checking for the position of the features “node”)
Interesting about the .dsf being lossy – does the same apply to the WED´s .xml file? Or the apt.dat?
Thanks again for improving the tools that we need to improve “our” simulator!
Jan
Both apt.dat and WED’s XML file are lossy in that they use text representations of binary floating point numbers…but the precision you get is very high, and I think the long term results don’t generate.
DSFs are lossy – you get a finite number of bits per feature. The encoder can choose how to allocate the bits and in most cases can provide very good precision (although I have fixed some bugs where our encoder was not precise enough). But it’s not designed for round tripping; the change to the data from the encoder will depend on the particular data encoded.
So you save a project as DSF and your house.obj moves a little bit. You import it, and then edit the whole project and save it again. The house is going to be moved in a -different- way due to a different set of objects to encode, but it will be moved -from- the already erroneous position. Thus you will potentially accumulate error through repeated round trips.
That sounds like incomplete feature, though I understand the benefits of direct download.
Lets hope this will be fixed in the future.
I’m not sure which part you consider to be incomplete; I would describe the whole thing as a “design limitation”. DSF is not meant as an interchange format; it’s being used for not-the-purpose-it-was-designed-for.
So my word picking was not the best, I should have written that the feature is bogus in away since, and I quote:
— Start Quote —-
small rounding errors (“bit rot”) will creep into our 3-d, and features that were perfectly aligned might not be well aligned after 4 or 5 edits.
— End Quote —-
As much as I love WED, this limitation needs to be considered before multi exporting and importing scenery.
Suggested workaround:
Can it be that when we want to export a custom scenery, WED will pick the original DSF and then “add” the 3D objects to it, from the WED definition file, that way WED file will hold the modified locations of 3D objects in space and the DSF will be built a new every time and not on the previous customized DSF (if possible)
Hi,
I’m sorry, but I still don’t get it. What did I miss here:
1. DSF is not an exchange format.
2. WED’s DSF import and export features are inappropriate for a work-flow that involves repeated (or indefinite repeated) import/export cycles.
3. The gateway is -not- based on DSF exchange.
Therefore:
– it is critical that we provide BOTH sides of direct data exchange with the gateway (without .dsf files) to make gateway _editing_ safe.
– this is what we are doing in 1.4.
Are you just saying that we really need to ship 1.4 with direct gateway import to call the gateway “complete”? Or are you suggesting that WED really needs a DSF-based exchange work-flow?
@snagar, The lossy that Ben mentions for apt.dat and WED’s XML files are not like the lossy you get with importing DSFs. If you always use the original WED XML to produce the DSF, the DSF will not lose anything. However, if you import a DSF into WED, then export (make a new DSF), the new DSF will have lost information compared to the original DSF. “bit-rot” only occurs in the second scenario, which is why the gateway does NOT use this.
Right – I did round-trip testing with the Gateway text format and numeric output stabilized after one round trip. This is definitely not the case with binary DSF.
hi happy new yar to xplane team, i have a question, when tesselation implementation for xplane 10?
I cannot comment on the release date of future un-announced features.
Good news about WED improvements 🙂
Thank you for all the improvements.
Will there be an update of the WED-Manual covering the new/altered features? It seems to me that the existing manual describes an early WED built.
The WED manual should be in sync with 1.4 when it comes out; Jennifer has already caught up on a bunch of user-manual back-log and has already done some work with in-development 1.4 builds.
Hi Ben,
Is there a change log somewhere? Can’t tell from Mantis what’s in & what’s out.
No – for 1.4 I think we may (for the first time) have real release notes but they are not compiled yet. The source tree is public so you can browse the GIT commits, but they’re not really a feature list.
An operating principle of the WED 1.4 is more or less clear and in addition to feeling of enthusiastic anticipation one question have arise. Will be release WED 1.4 for Linux? Thanks.
Yes. But it is possible that it will not be available for beta as quickly as the Mac/Win versions. I am actually not sure about the build status of the Linux version – if there are still problems getting all of the libraries to work on all Linux platforms, I will not delay Mac/Win beta for Linux.
Of course, it is open source, so if you want a Linux build you can have it -before- everyone else by cloning the GIT repo and compiling it yourself.
The main problem is that the packaging of libcurl is different on different distros, so it’s not trivial to build a single version of WED that works on all versions of Linux.