WorldEditor 1.4 public beta 1is available now. First, the links:
- Download from the WorldEditor page.
- Report bugs on the gateway – the scenery tools have their own tab.
- If you have reported bugs against WED in the past and the bug says “please retry in WED 1.4” or “fixed in WED 1.4”, please go re-check the bug now!
The online user’s manual is up-to-date; pick WED Manual from the help menu to see it and read about the new features.
I’ll try to write some release notes up later but there isn’t a procedure in place for WED for that right now. Some major features:
Download from the X-Plane Scenery Gateway
I think the most important feature of the new build is the ability to directly download an airport from the scenery gateway. This feature is intended for authors and editors who want to modify and re-upload the scenery; in this case direct download has a number of advantages:
- It’s a lot quicker and easier.
- Better data quality: there’s a lot less data precision loss in the direct download because the format used is not binary DSF; overlay elements spanning DSF tiles will not be split when you get the airport directly.
- Version tracking: when you download from the airport, WED knows the scenery ID you downloaded from and sets up a history chain when you re-upload. This sets us up to more easily track changes and understand what are major airport changes vs. minor editing changes.
I think direct download is going to be especially good for bug-swatting. If an airport had one small problem, it used to be that most of the work in fixing it was the import and export; this is now totally automated, so you can just download, edit, re-upload.
Orthophoto Creation
WED 1.4 builds orthophoto draped polygons for you. In this workflow you:
- Import source imagery, e.g. a TIFF or PNG. If it’s a GeoTIFF, WED places it for you. (GeoTIFF placement is fixed in WED 1.4.)
- WED converts the image format to DDS when you build the scenery pack.
- WED makes the draped .pol file for you, and puts a correct LOAD_CENTER directive in place to get paging.
It’s a much quicker and simpler work-flow than the old scheme from WED 1.1 (which was basically a hack I put in for Sergio to get the LOWI demo area built for X-Plane 9).
If you want to make your own .pol files you can still use .pol files directly – WED works either way.
GeoJPEG-2000 Got Kicked Out
I turned off GeoJPEG-2000 support in this beta; our testing indicated that .jp2 was super-unstable and unreliable. I’m not sure whether .jp2 will make it into this release or whether we’ll even keep the feature, but one thing is clear: it’s holding up an otherwise solid beta. There’s no reason why anyone should have to deal with broken GeoTIFF location, crashes on certain library scenery objects, or having to manually download from the Gateway for longer than necessary.
I still need to do more investigation into the crashes we’ve seen but so far the signs don’t look good – there are multiple indicators that point in the direction of .jp2 not being ready for prime-time.
Hmmm,
I can´t help but feel a bit disappointed. Sure, the ability to import from Gateway is great. But since I keep copies of my airports, its pretty much a non-issue for me (even though I did fix a dozen or so airports per the bug-report page).
The biggest letdown for me is that I still can not toggle “google earth” or “bing” maps “on” to get something to draw my taxiways on! I don´t care for orthophotos (can´t really get them for most parts of the world and making them is a huge hassle), and I don´t want to create a photo-underlay.pol (since its not allowed at the gateway!).
All I would like is to show the area I am working on in google-earth for reference.
Overlay editor is doing the very same thing, and the most time-consuming part of airport creation is to go to google earth, make a picture, get the coordinates for the runway, get that picture (shrink, size, pull, drag,…) to match the runway exactly so I can start using it as reference.
I know, I can use the corners of this picture as geographic coordinates, but there is no way to determine those coordinates in the first place (the corner might be in the middle of a meadow).
This is all fine and dandy for authors that do one airport a month and have the time to fiddle with a picture for an hour, but if you are doing 4-5 in a day, this workflow is a huge hurdle and something I feel could be MUCH alleviated. (Try OverlayEditor to see what I mean).
Jan
Ok, I just saw the comment you wrote on my initial request for this feature. I was not aware that there seems to be legal ambiguity – and certainly don´t want Laminar to get into legal trouble (as if you didn´t have your share already…).
When you changed status of my request to DONE I assumed that this would be in WED1.4, hence my disappointment – I wish there was some sort of alerting function that a bug report/feature request was commented upon.
Sorry for the testy comment above, Jan
Right – I think this comment pretty much covers what I was going to say: you’d be crazy to expect Bing or GE in WED because my position on this has been quite unwavering – putting it in WED is a blatant violation of the legal licensing terms of these services, so I am not going to code this.
It _does_ suck a bit because having a legal, high performance, high quality, universal imagery source would be a really, really, really useful feature.
But I have not identified any qualifying service. If anyone has a suggestion, I am open to it, but so far the two I have heard suggested are Bing and GE. 🙁
Re: the gateway, I believe you should get an email every time a comment is added. _However_, if the bug was posted under the _old_ system (Mantis) then you might not get a notification for changes in the _new_ system (Jira).
IF you file a bug under the new system (e.g. on the gateway website) and a comment comes with no email update, please file a bug against the gateway itself (we have a tab for that), and Tyler can investigate.
Not sure if you’ve seen MapQuest before – http://developer.mapquest.com/web/products/open/map – provides open source (OSM) satellite tiles. Can’t guarantee high quality for the whole world but it could at least help with aligning images from other sources 🙂
I think they (OSM) -specifically- negotiated a license with mapquest/yahoo. If there’s a generic open license, please forward it to me.
I think that could be the case, I haven’t seen any other OSM satellite tile sources available.
However, MapQuest offer access to this under a free and open plan:
http://developer.mapquest.com/web/tools/getting-started/platform/licensed-vs-open
From what I interpreted, the licensed plan is more suited for enterprise use, with commercial imagery, etc. However, using the free and open plan should provide access to these OSM tiles.
It looks like what MapQuest offers for free to open source users is pre-rendered tiles of OSM vector map data. But I don’t think this is so useful; if we want OSM we could also download the real vectors directly from the server.
I guess one of the questions is whether OSM is a spatially accurate enough data set to be useful for reference.
Here’s a thought – expose all the wed UI features as a REST API. Then some other clever enterprising user could write a new web-based UI to wed, on top of Google or bing maps. Just like the OSM site!
The more I think about it, the more this seems like a reasonable idea…!
The beta is a step forward for sure, quite like the gateway integration.
One thing that I don’t really like is when I go to “Import from Airport Scenery Gateway”, and each time it re-downloads the list. This is quite good for getting up-to-date submissions, but on my relatively slow internet, it takes a good minute or so, in which I could have manually downloaded from the Gateway and imported the package myself, making this feature useless.
Perhaps caching the list (and maybe updating it in the background when WED is launched) could be better? Then when an airport is selected, it’s downloaded and imported. Would certainly help here in slow internet land 🙂
I’ve only looked at WED recently, in trying to improve my local airports a little. Version 1.4 has been pretty good overall, though I’m struggling with the process of adding any kind of 3d objects.
I haven’t had any bugs with it, which is good for what is technically still a beta. But that aside, there are a few issues I’m having.
The main problem of course is that initially I would like to create something that fits the guidelines for an airport that can be included in the gateway…
I note from an older post that people were mentioning the lack of scenery, and I’ve found this the most difficult part as well.
To begin with it was unclear to me what qualified as custom scenery, but I guess from what I’ve seen the editor object to, combined with what I’ve read, it would be pretty much anything that comes from a 3rd party library, (or you’ve made yourself)
The included standard buildings clearly don’t look like what’s at my local airport. Which is understandable, since having custom buildings for thousands of airports would be unreasonable.
Unfortunately, both the size and the design of the included models is kind of awkward to work with.
For instance, the local airport has rows of two medium hangars right next to one another, and while the included medium hangers are of about the right size and even pretty close to the right design, the extra details they include messes it up.
Specifically, the fact that the hangars have car parking included makes them really awkard to fit into the space.
This is made worse by the area they need to go in being rather confined, and putting them there anyway would result in things ending up on the main apron, which would mess up aircraft movements quite a bit.
I would suggest perhaps, that the default airport models need reviewing to make it easier to build a variety of airports (smaller ones in particular), and fitting them into various layouts better.
For instance. The medium hangars are close enough to what’s at my airport to have been nearly perfect, but the fact that car parking is included makes them fit very badly into the space available.
There’s a set of dual horizontal fuel tanks, which would also work well, but a single tank of the same design would work better.
These are minor things of course, but ironically it feels like what’s needed is default scenery with LESS included details.
Or rather, the details that are included shouldn’t be so situational, and, since it’s generic scenery, should be, well, more generic.
The other option of course is facades
Though I get the basic principles behind it, understanding how what you create in the editor in comparison to what ends up in the simulation is quite unclear.
You cannot get any sense of what it looks like from the side, and if you select a facade from the list of objects, there’s nothing other than the name to help you determine what it looks like. (this might be a bug, or maybe a limitation? I have no idea.)
What I do know is that I seem to have to guess from the name alone what the facade is, what it looks like, and what effect it has on what you try and build with it.
Compared to the included 3d objects, where you can get a preview of what it looks like (although I’ve noticed some larger objects, such as water towers, and some of the control towers don’t seem to fit inside the preview window),
or even the texture preview you get for runway textures – (turns out using these, even the default textures, qualifies as an ‘orthophoto’, and is banned from the gateway. Is that intentional? Or some kind of side effect of preventing people using custom textures?)
Maybe I’m missing something, but having to load the sim each time just to vaguely get a sense of what a building made using a facade ends up looking like makes the process a lot more difficult.
The same could be said for what effect changing the choice of runway type has on the actual markings, but that’s not quite as much of a headache.
The gateway integration is quite useful.
Many of the build tools work quite well, (some slightly less so), it’s not incredibly hard to understand, in spite of the inherent complexity of it.
Anyway, overall I think WED is a pretty good tool, but I did find a few areas of it more problematic than others.
And of course, the problems with default scenery in trying to make things suitable for the gateway.
There could be slightly more variety, but also in general, perhaps more thought given to the way the default 3d models are built.
Flexibility is key. Avoid highly situational details at all costs, otherwise you make it that much more difficult to work with.
If you’re going to force thousands of airports to use a small set of models, it pays to make sure those models are as flexible, and suited to as many situations as is possible.
I’m not quite sure some of the included models that currently exist fit that description very well.
Anyway, I guess that sounds like a lot of complaining. Sorry. XD
Overall I’m having a lot of fun with the editing tools. Better than most I’ve used with other games/simulators. (well, sometimes there aren’t even any tools, but that’s a different issue.)
Oh well, in the meantime I guess I’ll see what I can build that actually does still stay within the rules of the gateway airports. It can’t be THAT difficult, surely?
(Well, I’ve already hugely improved the taxiways, so it’s a start… XD)
Hey Ben,
Following the ever growing success of Airport Gateway and also after watching the screencasts about Airport Flows and Taxi Networks, when I heard Chris Serio say “we’re trying to think ahead to the future”, got me thinking:
Maybe would be nice, while people are still “getting started” with the Gateway (not that started, but not too late either), and expand some options regarding Ramp Start Positions, to retain more and better information regarding Parking Spots. Even if XP doesn’t currently use any of this information, would be nice to have if for the future, and/or available for possible plugins. Specially because parking spot information is not always present on NAV databases, would be a great opportunity to make use of community knowledge here, as people are analyzing each airport and creating it’s Ramp Starts anyway.
I went through ADC and PDC charts of many airports around the world, and in my opinion we could be well suited with the following changes:
– NAME*: Still as it is. The name of the parking spot, accepting only A-Z and 0-9, with guidelines for authors to “keep it clean”.
– APRON: Mainly the number of the Apron, or a few predefined most common variations such as North, West…Cargo, Military. Or none.
– TERMINAL: As for Aprons, the identification of the Terminal, a number, letter, both, or predefined as North, West…
– OPERATION: Type of operation that can happen there. PAX, Cargo, GA, Maintenance, Military…
– TYPE: Extend the options from Ramp Start Type to have something like “Stand”, in order to represent parking spots not attended by bridges/jetways (leaving “Gate” for this one), as Tie-Down is ofter more related to GA, and not as much for a Cargo ramp for example.
I even made a little table, with real-world examples of those options.
http://i60.tinypic.com/28bwprk.png
* At some airports, GA or Military parking positions may not have an identification. I thought that maybe when leaving the NAME field blank, WED could generate something, maybe based on coordinates? Something like:
NamelessStand1 – Coords: S15°52’00.17 W047°54’24.15
NamelessStand1 – Name: S15.17W047.15
NamelessStand2 – Coords: S15°51’59.55 W047°54’24.15
NamelessStand2 – Name: S15.55W047.15
Anyway, I don’t know the internal workings of LR, so it’s just some loose 2-cents. Maybe you find it interesting 😛
Cheers.