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.
We’ve been quiet on the Android front for X-Plane 10 Mobile but typically around here, quiet is a good thing because it means we’re busy!
We’ve put in a lot of effort and we’re at a point now where we’re going to begin testing the product. More on that in a minute…
First, I’m excited to say that for the first time, our iOS and our Android products will be the same! In the past, Android came around much later than iOS did and the Android operating system and the devices running it were quite a bit behind Apple’s so we had to make our Android product different. This is no longer the case. Google offers all of the same amenities that we’re currently using on iOS. We will have leaderboards, achievements and multiplayer. The product itself will be effectively identical. It’s the same X-Plane Engine, flight model, scenery packages, aircraft etc. There will be no teaser screenshots because…well….it looks exactly the same as all of the iOS screenshots that we’ve already been posting.
Our goal, once the Android version is released, is to keep the iOS and Android products simultaneously up to date. If a new feature is added to one platform, it will be available on the other platform almost immediately (store approval times permitting).
Testing, testing…1,2,3
We’re going to begin testing relatively soon. I have a few odds and ends to tie up before we’ll be ready to go but i’d say in the next week or so we’ll begin our first round. If you want to be considered to be a tester, you can click on the link and submit a request. There’s no guarantee that you’ll get in. We can’t play favorites.
This testing will be slightly different from the norm. Typically we let users Beta test our products to find some bugs early and help us stabilize. With Android however, our goal is to release an early Alpha version to a small number of users and then slowly increase the size of the test group until we’re confident that it’s running properly on a wide range of devices. Then we will expand the group even more and begin Beta testing per usual.
Why are we doing things differently? With iOS, we had one operating system version to worry about (iOS 8) and twelve different devices (every supported iPhone and iPad) running one brand of GPU to test against. Between Ben, Tyler and myself, we essentially own one of everything. On Android, we have three (4.1.X, 4.4.X and 5.X) operating system versions, four major GPU manufacturers and (wait for it….) over six thousand different devices. Needless to say, we do not own one of everything! We need to ease into the testing to find driver issues and other device-specific problems early which is why we’re doing the Alpha test.
We’re mainly focused on testing the Android-specific pieces because 90% of the code is the same as what’s running on iOS which has already been thoroughly tested.
When will it be released?!
As soon as it’s ready! Awwww (sad face), I know you hate that answer…but it’s true. Our goal is to release it as soon as testing shows that it’s stable! This will probably be in a number of weeks, not days but also not likely months.
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.
Despite many of the Lufthansa Pilots being on strike, Ben made it to Paderborn for the 13th FlightSim Conference in Germany. The event was held at the Paderborn airport, where the airport fire brigade pulled out two of their fire engines to the tarmac – the freed up hangar space was then used as the exhibition floor.
The FS Konferenz starts with a developer’s dinner, were FSX and X-Plane developers drink beer together talk about the development experience, then has a day of public exhibition, talks and interaction with users and ends in the traditional “captain’s dinner”.
We are extremely satisfied with this year’s conference. Not only were there more exhibitors and more visitors than last time, but also the impact of X-Plane is growing steadily. This became evident not so much in the public exhibition space, but in the little ad-hoc sessions we had with other developers. FSX developers who would not have touched X-Plane with a ten foot pole a few years ago were now asking us questions: How do I make a great landclass scenery? How do I make my add-on work with the X-Plane weather engine? How can I make 3d grass next to the taxiway in a way performance doesn’t suck? How do I program a gauge for X-Plane?
I think we are in for a round of new add-ons that will finally come to X-Plane.
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.
We should have had WED 1.4 beta days ago, but we do not. And the reason we do not is that some .jp2 files from the USGS do not import properly into WED. Others do, but going the ones that don’t are very common, and going beta with .jp2 files not working is asking for one hundred copies of the same bug to be filed within a day.
I now have a nasty hackworkaround for the problem: WED recognizes the particular projection that the problematic .jp2 files have and replaces the projection information with something the libraries we use can understand. This is a very brittle work-around but for now it’s all I can do. I’ll post again when the beta goes live.
