Update: WorldEditor 1.3.2 is out now and has new certificates to work with the gateway; get it here!
I screwed up: WorldEditor 1.3.1 contains a certificate that allows it to authenticate that the X-Plane Scenery Gateway is who it says it is before WED transmits your user name and password during an airport upload. And this certificate expires in about two hours.
Last night we cut a new build (1.3.2) with a new certificate with a much longer time range, but Tyler said that for some reason the new certificate did not work. So it’s most likely that we’re going to run out of time before we get a new WED build posted. Here’s what this means:
You will not be able to upload airports to the gateway with WED 1.3.1.
Once WED 1.3.2 is available, you will be able to upload airports using WED 1.3.2.
Every other function of WED will keep working.
The Gateway’s public web page will keep working.
I’ll post an update here when we can get WED 1.3.2 “live” – unfortunately it will probably be more than two hours. I’m hoping to have this solved by the end of the day.
I will also cut a new WED 1.4.0 beta with the latest bug fixes and an updated certificate. That should be available tonight.
As a side note, I think that everything that is “must fix” for WED 1.4 is fixed, so this will be a WED 1.4 release candidate. We are deferring jpeg-2000 support out of WED 1.4 entirely so we can ship it.
TL;DR: 10.36 works around the latest NVidia driver – let X-Plane auto-update and everything will just work the way it should.
X-Plane 10.36 is out now – it’s a quick patch of X-Plane 10.35 that works around what I believe to be a driver bug* in the new NVidia GeForce 352.86 drivers.
10.36 has been posted using our regular update process and has been pushed to Steam, so if you’re running 10.35, you’ll be prompted to update. The update is very small – about 10-12 MB of download.
With this patch, you can now run the latest NVidia drivers. I have no idea if those drivers are good (I have anecdotal reports that they’re both better and worse than the last drivers, but these kinds of reports often have a large ‘noise’ factor**).
We patched X-Plane because we can cut an X-Plane patch faster than NVidia can re-issue the driver, and the driver issue was causing X-Plane to not start at all for any users, which was turning into a customer support mess. Past NVidia-specific patches have been to fix bugs in X-Plane, but in this case, we’re simply avoiding a pot-hole. I hope that NVidia will get their driver fixed relatively soon so that people installing from DVDs with older versions of the sim won’t be stuck.
Update: NVidia fixed this bug in the new 353.06 drivers!
[OpenGL, Windows 8.1 -x86/x64]: GLSL shader compile error. [1647324]
* The bug is that #defines defined within a function body don’t macro-substitute, but #defines outside a function body too. The work-around is to move some #defines out of function bodies. If anyone can find a reason why #defines can’t be in function bodies, please shout at me, but it’s a pre-processor.
** We’ve had reports of huge fps improvements and losses on beta updates where we’ve made only cosmetic changes to the sim.
Note: this issue has been resolved – please see here!
I’ve received a few bug reports about this today: NVidia’s new 352.86 WHQL drivers for Windows do not work with X-Plane 10. I’m contacting Nvidia now to figure out what has happened.
In the meantime, to fly X-Plane, use the previous 340.52 WHQL driver.
I’ll post more when I learn more; we’ll resolve this with either a driver update or an X-Plane update, based on what has actually gone wrong and which can happen first.
Update: NVidia was able to suggest a work-around in our shaders that avoids what I think is a driver bug. Since we can cut an X-Plane build faster than NVidia can re-release their drivers, I have cut X-Plane 10.36 rc1.
You can get 10.36 rc1 by running the updater and checking “get new betas”; the updater will run even with the newest NVidia drivers.
10.36 rc1 is identical to 10.35 except for version number and a single shader change, but it’s also highly untested; I wanted to get it posted ASAP to accelerate the process. So please give it a try and file a bug if it doesn’t work like 10.35 (but working with the new NVidia drivers.)
Update 2: Sigh…this is what happens when I try to rush out a patch. The 10.36 patch’s free space calculation is totally borked. This will be fixed some time today. (This will be the third time I cut a patch.)
Update 3: the meta-data on the 10.36 rc1 patch is fixed – if you haven’t installed it yet, try again; you’ll need 30-40 MB of disk space, not 30-40 GB. 🙂
Update 4: Steam users – 10.36 will be available for Steam in a day or two; until then, please run older, functioning drivers.
I’ll post about X-Plane 10.40 next week – but just a quick note: apparently the Rift will ship Windows-only first:
Our development for OS X and Linux has been paused in order to focus on delivering a high quality consumer-level VR experience at launch across hardware, software, and content on Windows. We want to get back to development for OS X and Linux but we don’t have a timeline.
That’s from a much longer blog post describing the Rift’s hardware requirements and the difficulty of moving that many pixels at that high of a framerate with ultra-low latency. (The tl;dr version is that if you have a Windows laptop you probably won’t be able to run the Rift on it.)
I don’t know what the failure mode will be for not meeting requirements, e.g. will the Rift simply not run, or will it do the best it can with degraded performance.
To state the obvious, if there isn’t an Oculus Rift SDK and driver for OS X or Linux, then X-Plane can’t support those operating systems.
Last night I posted new versions of WorldEditor, MeshTool, and our command line tools. Follow the “tools” menu on this page to find them – developer.x-plane.com is the official home of our Laminar Research’s scenery tools. (We’re migrating scenery.x-plane.com and wiki.x-plane.com to just be on this site.)
Please remember that the scenery tools bug share the gateway bug reporter; please search the gateway bug reporter before you report a new bug – maybe your bug has already been reported. (You do not need to log in to Jira to search!)
WED 1.4 Beta 2
I have packaged a README with WorldEditor, and including release notes on all fixes since beta 2; bugs filed to the gateway reporter are also updated. Unfortunately I do not have release notes dating back to 1.0.
At this point there are still a number of Linux UI bugs, and Geo-JPEG 2000 support is still out. At this rate I expect to not ship Geo-JPEG 2000 support in WED 1.4 at all.
MeshTool 3.0 Beta 1
This is the first public beta of MeshTool 3 – so far there aren’t new features compared to MeshTool 2; the main change is that MT3 builds X-Plane 10 style DSFs using X-Plane 10 land classes. It is therefore appropriate for add-ons that target X-Plane 10 only.
I have linked to the config and land class files for both versions of MeshTool on the download page; it is important you use the right land class and config files for your project. (Upgrading MeshTool without replacing the config file or land class data won’t work.)
Scenery Tools 15-3
This is a recut of the command line tools. Not much has changed.
ObjConverter is no longer included; right now we don’t have a compiling version for Windows, and frankly I can’t think of a good reason to use this tool ever.* If ObjConverter was, for some reason, part of your workflow, you can still download it from the 12-2 tools release; email me and I can also explain how to use a different, better option to convert your objects.
DDSTool now defaults to sRGB gamma on input files. Both the old and new version read gamma information from your source PNG file, but if the PNG file is not tagged properly (and it’s very easy to have tagging go wrong, particularly when Photoshop** is involved) you would get classic Mac gamma in the old version. This is basically never what you want; the new recommended work-flow is to always work in sRGB, use the new DDSTool, and you’ll always get the right results.
* ObjConverter tried to convert 3DS and DXF files directly to OBJ. But since there is no standard encoding of animations, materials, and other X-Plane specific data in 3DS, the converter could only copy the mesh and texture map. This made it appropriate only as a way to get from one 3-d program to another.
But even this use is not a good way to move your data, because it strips out animation and meta-data. My suggestion is that you export directly from 3DS using an export script, or open the source 3DS or DXF file in a modeler that has native X-Plane support like Blender or ac3d.
X-Plane’s OBJ format is not meant as a way to move your models between programs; it is meant only as a final destination format for shipping your scenery.
** The problem with photoshop isn’t that it writes the PNG files incorrectly, rather the problem is that Photoshop is way too smart; it writes a full color profile when libpng only understands a few simple constructs like sRGB and gamma. So what I was seeing was libpng not understand the sRGB color profile from Photoshop because the encoding was too complex.
Defaulting to sRGB is a bit of a band-aid, but it also is what everyone should use all of the time.
Tyler is migrating the website to new hosting, and so the old server has decided to flip us one last middle finger. Needless to say, if you’re seeing this page, you probably waited for 30 seconds to get it. 🙁
I have WED 1.4b2 ready, as well as a cut of the command line scenery tools pack and MeshTool; I will post all of them once the server is migrated. Not a lot of good posting the files if you can’t download them.
Hopefully the website will be full speed again early next week, if not sooner.
UPDATE: Tyler says the site migration is finished. If you’re still having problems accessing X-Plane.com, demo downloaders, or sim updates, give him a shout at tyler@x-plane.com.
X-Plane 10.40 will have an option to load a larger local region of DSF scenery. For as long as I have been involved in X-Plane (back to X-Plane 6 as a user) the local scenery region was 3×2 tiles (each 1×1 degree in latitude and longitude). With this option, the region is 4×3.
What this gets us is the option for a longer viewing distance before we have to transition from the higher detail DSF scenery tiles to the lower resolution whole-planet render. In X-plane 10 the planet render actually has shape, but the resolution is low; if you see it up close, it does not look good.
Some fine print:
You will only be able to use this option in the 64-bit build of X-Plane. The 32-bit version does not have enough memory.
Combining extended DSFs with heavy third party scenery may be unacceptably slow. For example, Alpilotx was able to run extended DSFs with the HD meshes, but his computer has monstrous amounts of RAM (64 GB I think??). I’m pretty sure extending with the UHD meshes is a non-starter.
Load time shouldn’t be too bad; this change also includes a re-work of the DSF loader that takes better advantage of multi-core hardware. If you have a 4-core machine your DSF load time shouldn’t be worse, even with extended DSFs.
Here are two sets of pictures taken over the demo area at extreme res on my PC; this shows the interaction between atmospheric scattering and loading more DSFs. The camera is at about 30k feet.
Normal DSFs, no scattering
Normal DSFs, with scattering
Extended DSFs, no scattering
Extended DSFs with scattering
The combination of pushing the transition to the planet “out” away from us and using scattering to remove color detail starts to get something that looks more like the real world.
Note that to get the match-up in the lower right, you must have Earth Orbit textures (which come with any full install) and you must be in extreme res or the planet starts to get fuzzier.
Here’s another set.
Normal DSFs, No Scattering
Normal DSFs, Scattering
Extended DSFs, No Scattering
Extended DSFs, Scattering
In the long long term, I expect the planet to improve in render quality (with at least a 2x boost in image quality, and perhaps better than that in mesh shape), and I expect scattering and other lighting to improve in quality.
I do not expect to further extend the DSF box beyond 4×3; I think that the planet can improve to further “bridge the gap.”
Philipp and I will be at the 13th German Flight Simulation Conference in Paderborn this weekend. (Well, I am crossing my fingers that I can still make it despite the lufthansa strike.)
If you ask about the OcRift in person I won’t be able to just delete your comment. 🙂
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.
X-Plane 10.35 is now officially released! If you run X-Plane, it will prompt you to update. Lots of details here!
I’m still trying to get WED 1.4 to public beta – that’s high priority right now!
X-Plane 10.40 is currently in development. Austin has some new features that he’s letting people test-drive; I’ll post more about 10.40 in a few weeks.
