Category: News

X-Plane 11.20 Beta 2 Is Out

It’s like beta 1, but without the missing art asset. 🙂

We’re working on beta 3 now, which will have some fixes for rendering bugs. A few notes:

  • This is not going to be a typical eight-week beta. Please go check your add-ons this week.
  • The biggest area of code change for VR that affected other parts of X-Plane was the rendering engine. I’ve fixed 3 rendering bugs where I broke something while restructuring the renderer for VR, and none were surprising. Please check your aircraft or scenery pack for visual defects and let us know!

Steam users: we should have beta 2 up shortly.

Posted in News by | 17 Comments

WED 1.7r1

Release candidate builds for WED 1.7 are now available for testing. A big thanks to Michael for leading a lot of this development. He kept all this moving along at a much faster rate than if we’d been left to our own devices! Here is his summary of the changes you’ll find in this version:

Selection of items

When selecting any item in the map pane, WED now prioritizes the items by a what appears to be on top when viewing the scenery in X-plane. So if you click on any .OBJ in the middle of a taxiway – it always selects the .OBJ, line marking or ground painted taxi sign rather than the underlying taxiway. Similarly, it selects the facade or forest rather than anything that is flat and draped on the ground.

Technically, this means object type and LAYER_GROUP rather than WED hierachy based prioritization.

Exclusion zones and airport boundaries are now kindof “hollow” items, they can no more be selected by clicking inside of them, but only by their frame/outline or perimeter. That should greatly help with not having to lock or otherwise get those large area items out of the way.

All items can now be single-click selected, even if they are located within the area of an already select item. This eliminates the need to de-select (CTRL-D) e.g. a taxiway every time the last attempt to click select a .OBJ turned out to be just a bit to far away. And therefore accidentially selected the whole taxiway underneath it instead.

Drag-moves are now subject to some “stickyness” , i.e. the move/copy only starts after the drag exceeds a few pixels. This helps avoiding accidential very short distance drag-moves. Once the item has “broken free”, the item can be moved back to within a single pixel of the initial location, so small moves can still be achieved.

Several bugs that prevented adding bezier handles to nodes under some conditions or selecting very closely spaced items are fixed as well. All operations now require a click no closer than 4 pixels from the “correct” location. Any very closely located items having the same piority (like two nodes of the same polygon) are now selected using a “whatever is closest” strategy, rather than having overlapping bounding boxes prevent access to all but one of them.

Validation warnings and results browser

Some validation issues can now be a warning only, rather than a hard error. This allows WED to try more validation of frequently found problems, even at the risk of creating a few false alarms in rare cases. If such a warning is ignored for gateway submissions, the gateway moderator will determine on a case-by-case base if the issue can in fact be waived or still reject the scenery submission.

After validation, a full list of ALL validation issues will pop up, allowing to browse and zoom to / highlight all issues to help planning out the work required to pass validation. This also allows to select multiple validation errors to e.g. select ALL duplicate vertices in ALL polygons – allowing to fix all with a single editing operation.

New validations

Validation now catches all types of self-intersecting polygons. Previously there were certain cases of bezier-curves that caused taxiways/polygons to stop showing up at certain zoom levels or not at all in X-plane, despite they looked fine in WED or vice versa.

The coordinates and names of runways need to be exactly in sync with the CIFP data used by X-plane for FMC SID/STAR and GPS approaches. For this reason, gateway airports are occasionally edited by a script by “WEDbot” to achieve this, but any user re-submission that touches the airport may break this effort. WED now validates the runways against CIFP data oit obtains direct from the gateway server and requires the runway threshold to be within 10m of the exact location. Note this is the thereshold – the wide white bar only.

There is a separate warning only if the displaced part of the runway (the optional part from the end of the runway to the threshold – with the centerline arrows pointing towards the displaced threshold) mismatches official documentation. Some of the CIFP data mis-states that displaced distance, so it is a warning only. Please thoroughly verify such warnings against current orthoimagery and draw as per current real world markings.

A *lot* of ATC flows on the scenery gateway are non-functional because of misunderstandings how flows work. The most common mistake is to define one flow per runway and then expect that X-plane somehow finds all flows that fit the current weather pattern and uses them all togther. But that’s not how flows work. Validations will now try to find such duplicate condition flows (that are effectively never ever used) and will warn about it.

The airport naming is covered by several new errors (like ALL CAPTIALS – THATS SHOUTING IN THE INTERNET AGE !) and warnings if undesired elements are included in the names.

Smart runway rename

When a runway is re-named due to magnetic variation changes, not only the runway name, but also all ATC taxiroutes, flows and taxisigns need to be fixed up to reflect the changed designation. WED now will detect such edits of a runway “name” property, find all these references, update them and let you know. This greatly helps when the runway validation tells you it’s missing some runway at that airport – which usually means some existing runway was recently renamed due to magnetic variation changes.

More library item previews

Type 1 facades are now displayed in the library preview panel. Please be patient – the more complex “type 2” facades as used in all airport terminals and the new terminal kit are not showing, yet.

Many library items come with multiple variants that X-plane will select at random from when placed in the scenery. For such items, a button will show up to view each variant. But keep in mind – there is no way to tell X-plane to always use a specific one. Its just a true “FYI”, only  …

All forest/facade/object previews will show some textual information about their size and features available.

The World Map in the background now has 9x the resolution and shows true X-plane ground texture colors.

ATC taxi route names are displayed in the ATC TAxi & Flow view – please verify them for consistency, as the X-plane ATC uses and even speaks these names when providing taxi instructions.

Don’t import from the apt.dat for gateway airports

The apt.dat and .dsf formats are lossy, i.e. they contain less information and use less precision than a direct import of the airport from the scenery gateway. WED will now warn anytime it detects such an import for an gateway type airport.

Upon im/exporting to/from the gateway WED will now also show warnings if the gateway is currently not accepting new submissions for that particular airport.

Facade editing

Facades without roof’s or filled areas, like fences and skylights in the XP11.10 terminal-kit are now allowed to have 2 nodes only – previously facades of any type had to have 3 nodes minimum.

Two bugs were fixed, too – these prevented selecting certain wall types in the terminal-kit facades and displayed some facades as being “closed rings”, rather than line-type items in the map window.

Orthophoto import

Georeferenced image “geotiff” import used to require mercator projected, WGS84 referenced coordinates. On Linux and OSX it will now understand pretty much all coordinate systems defined in the EPSG standards – although WGS 84 lat/lon coordinates are still the preferred encoding.

Display speed and memory use

When zooming in at airports with very large, single piece taxiways, the WED display speed used to slow down significantly.

The 64-bit versions of WED (OSX & Linux. Windows is still 32 bits, only) used a lot of RAM with large sceneries, e.g. im/exporting the *whole* global airport scenery (thats what WED is used for at LR, all 28,000 airports in one scenery !) maxed out a 16GB RAM machine. Now its down to near half that and everybody else gets a small speed boost, too.

Preferences menu

Some user adjustable settings (like meter vs feet) are now moved to the File->Preferences (OSX: WED->Preferences) menu, stored in WED’s global preferences and no more loaded/stored with each individual scenery file.

Posted in News, Scenery, Tools by | 6 Comments

Now Serving 11.20b1

X-Plane 11.20b1 is the first beta that includes non-VR improvements. Full release notes are here, but a non-comprehensive short list of the most exciting additions is:

  • Gateway airports
  • Terminal Kit additions
  • Customizable Jetway Kit
  • Custom landmark pack for Sydney, Australia
  • Better syncing of aircraft location in multiplayer and external visuals
  • Improved night lighting textures in far views

Formation flying: this beta includes Jörg’s new code to improve network sync, both for external visuals and multiplayer/formation-flying. X-Plane now calculates the total latency between machines and adjusts network aircraft to compensate, with error correction. This means you see your friend flying where he is, not where he was when X-Plane sent an aircraft position update over the wire 100 ms ago.

Night lighting: X-Plane’s night lights come from the autogen, but for performance and memory reasons, X-Plane doesn’t build autogen far from the aircraft. Petr has added night lighting textures for the far view to fill in the night sky. Here’s a comparison at KSEA (looking toward KBFI) at about 10k feet.

New Sydney landmarks:

Steam users: the beta will be up on Steam over the weekend if we don’t find any major problems.

This is going to be a relatively short beta – most of the technically risky stuff went into the VR previews. We still have a plugin bug with fuel flow to fix, and Linux performance problems to investigate. Third party authors: please try your add-ons on an 11.20 beta soon.

Posted in News by | 70 Comments

X-Plane 11.20 VR6: Can We Break the Curse

X-Plane 11.20 VR preview 6 is out, and if preview’s 2 and 4 are any predictor, it’s going to be a dreadful disaster, as all of the even number previews have been so far.

But maybe not! Maybe we can break the curse – after all, Star Trek did it with Nemesis. Anyway, VR6 is available for public beta. Steam users – we’ll post it on Steam tomorrow if we haven’t found a major problem, otherwise we’ll go right to 7.

Highlights:

  • Asynchronous Space Warp (ASW) works for the Oculus Rift.
  • No more white instruments.
  • No more crashes loading some third party aircraft.
  • The xPad won’t follow you around as you teleport around the tarmac.

Depending on how things go, this might be the last VR preview! ASW and xPad teleportation were the last two big VR specific issues; if things go well, we’ll produce a general 11.20 beta for everyone with the other features mixed in. I’ll post about that next week if VR6 doesn’t have to be recalled for insubordination.

Posted in News by | 119 Comments

We Are Now Just Like Star Trek

Fellow nerds^H^H^H^Htrekkies^H^H^H^H^Hnerds are aware of the even-odd phenomenon – for nine films, every other Star Trek movie was pretty bad, then the next one would be okay. VR previews are now like that, with VR2 and VR4 being fatally broken. We’re planning to just skip 6 entirely.

Anyway, I broke VR4 – my code to put a loading screen in the Oculus Rift had a side effect of killing the render resolution on the HTC Vive and WMR-based headsets. Since I only have the Rift (Chris has one of everything) I never saw the bug; since I thought my change wouldn’t affect anything outside the Rift, Chris didn’t re-try the Vive.

So, VR5 is now up – this should restore the Vive/WMR headsets to the performance of VR3.

We can confirm that ASW is not working in VR4 or VR5 – we’re looking at this now, but for VR4 and VR5 you’ll see ATW but not ASW, regardless of Oculus debug settings.

(Edit: the first version of this post confirmed no ASW in VR5. ASW is off in both VR4 and VR5 because the native rift SDK is not permitting ASW for X-Plane. A number of commenters were concerned that they would lose ASW by going from VR4 to VR5. You will not! ASW is already off in VR4; if you like VR4’s performance, you clearly don’t miss ASW.)

(Edit 2: We have a very promising lead on the ASW issue for Oculus. We have it working again here but I want to do more testing before I declare victory. We do not need any more information. Nothing you can do on your end will fix this. If you think you’re fixing it by “jiggling the handle” you’re probably just falling into placebo effect. If everything goes well we will have an update to fix this over the next day or so).

Posted in Development, News, VR by | 146 Comments

X-Plane 11.20 VR4 Is Live

****EDIT: There’s apparently an issue for people running the Vive and WMR where they’re seeing reduced resolution. We’re looking into it and will post an update as soon as possible.

****EDIT2: We’ve found the issue affecting Vive and WMR. We’re testing a fix internally and will release an update hopefully in the next 24 hours. Please do not submit any more bug reports about Vive/WMR resolution.

11.20 VR4 is Live on the servers. Aside from the usability fixes that Ben already mentioned, the major ‘feature’ in VR4 is…Oculus users will no longer need SteamVR. If you downloaded it just for X-Plane, go ahead and remove it. It will no longer be necessary.

As we said we would do from the very beginning, we investigated the relative performance of X-Plane through the native Oculus SDK versus SteamVR and what we found, through data collection, is that the overall experience for Oculus users was better by going through the Oculus SDK directly. I know many of you are thinking “Duh! I told you that a month ago ya big dummy!” and yes…yes you did. Fortunately/Unfortunately, we try not to make engineering decisions based on gut feelings and anecdotal evidence when we have a way to collect actual numbers. We wanted to tackle a majority of the usability issues affecting everyone before we looked into performance.

In the various A/B tests that we performed, we found that going to the Oculus SDK directly got us about 25% improvement in frame rate. This does not necessarily indicate that there’s anything wrong with SteamVR itself. There are several factors influencing the performance in VR. First, Oculus has their “home”, that little bachelor pad where you hang out while waiting for games to load. SteamVR has their “home” as well. When you use SteamVR, BOTH are running on your machine. Those houses are not free and X-Plane is already CPU bottlenecked so anything consuming CPU resources is going to directly affect performance. (I noticed an Autodesk updater in my task manager that was stealing 5% of my CPU consistently. That too was decreasing my performance….every bit matters!). Going directly to the Oculus SDK removes the SteamVR house from the equation.

Sure, getting 25% improvement is a huge win, but that’s NOT the biggest win. The biggest win, in my opinion, is that Asynchronous Space Warp (ASW) works MUCH better even at very low frames rates down to about 22.5fps. It appears as though the timing of the frames is critical for ASW to work properly. Being at 22.5, 30, 45, 90fps feels smooth! Being in between those frame timings seems to make ASW lose its mind creating an annoying judder; the opposite of what ASW is supposed to be doing for us. Oculus seems to be V-Syncing us to hit those intervals, allowing their algorithms to make reliable timing decisions and predictions. It’s my suspicion that SteamVR was just not hitting those intervals, causing ASW to flip out.

TLDR; Performance for Oculus will be on par with what Vive users have been seeing all along. The smoothness of the rendering seems consistent even down to 22.5fps. If you’re a Vive user, you will still, of course, need SteamVR as that IS your native SDK. If you’re a WMR user, you will still need SteamVR. I have not seen any reprojection issues with WMR like we have with Oculus. Supposedly the upcoming versions of SteamVR have some performance improvements coming for WMR users as well so we’ll be sticking with SteamVR for all headsets other than Oculus. That can always change in the future…based on data.

Posted in Development, News, Uncategorized, VR by | 106 Comments

A Few Usability and 3rd Party VR Notes

We’re starting internal and private testing of VR preview 4 – if it goes well, we’ll release it early next week. A few notes on usability:

Have Your Mouse Cake and Eat It

We got a metric ton of “bug reports” that users couldn’t click “Disable VR” when using the 3-d mouse. I put bug reports in air quotes because disabling click zones on the main monitor when using the 3-d mouse was totally intentional! (In other words, I broke that button on purpose.) My thinking was that you might click on “Disable VR” by accident while in the headset because you don’t know what the 2-d mouse is hovering over while clicking.

In VR4, we have a solution to the problem of whether the 2-d or 3-d mouse is the “intended” cursor when a click happens: we read the headset’s “on the user’s head” sensor and disable the 3-d mouse (temporarily) when you take the headset off.  So you can be clicking in 3-d, take off the headset and immediately click “Disable VR” and we figure it out. This feature is great for developers who need quick access to 2-d debug tools like the texture browser or DataRef editor. Read More

Posted in Development, News by | 33 Comments

X-Plane 11.20 VR3 Is Live

It’s basically VR2 with the crashes and chaos fixed. The plugin system in VR2 had a bug that seems to have caused plugins to go completely crazy and cause weird rendering settings changes.  This should be fixed in VR3, but check your settings to make sure they match what you expect.

VR3 also fixes the sim not starting on older Linux installations.

EDIT: VR3 is now available as a Steam public beta too.

Posted in News by | 126 Comments

Some Bugs in VR2

We’ve seen a few critical bug reports over the weekend, so:

  • We’re going to hold off on the Steam release of VR2.
  • VR3 should be out really soon – basically as soon as we can get these critical bugs fixed. We’ll put that on Steam.

Some notes:

  • VR2 won’t launch on some versions of Linux due to a plugin DLL problem. We don’t have a fix for that; we have to fix the sim.
  • The HOTAS Warthog causes the sim to crash if it’s plugged in. We’re fixing it.
  • If you have any other hardware that either won’t calibrate or crashes the sim, please do file a bug! Commenting on the blog does not count!  If you’ve commented on the blog, even if LR staff has replied, file a bug. Only bugs go somewhere that get tracked.
  • We’ve seen reports of plugins crashing that did not crash in VR1. If a plugin is now crashing in VR2 that didn’t crash in VR1, please report it! It’s useful to know whether the plugin crashes in VR2 even if VR is not being used.

Anyway, we’ll try to stabilize this stuff in VR3, then move on to more investigations WRT Oculus performance, and fixing other VR bugs like xPads floating in the air.

 

Posted in News by | 46 Comments

X-Plane Desktop VR2 Preview Released!

Set your updaters to grab the latest Beta and you’ll find yourselves with VR2 Preview Release. We put a lot of time into this release in an attempt to tackle as many of the usability issues of the VR1 release as we could. (Steam users — VR2 should be available as a public beta on Steam sometime this weekend, as soon as Philipp gets it uploaded.)

Important Note: If you are trying to run VR2 on an X-Plane install that was previously running FlyInside’s plugin, you might experience a crash on startup. We suggest installing VR2 to a fresh copy of X-Plane on your hard drive. If you can’t do that, you might need to uninstall FlyInside and reset your X-Plane preferences.

EDIT: There is currently a known issue with the Thrustmaster HOTAS causing the sim to crash. We’re looking into this and once it’s fixed, we will release VR3 which will address this issue and possibly others should they arise in the next 48 hours or so. For now, if you want to use VR2, you’ll need to do so without your HOTAS.

I’ll enumerate the major headliner features/improvements and talk about them individually, but first, let me be clear what is NOT in this release. This release will NOT dramatically improve the performance or reduce judder for any VR platforms. The goal of VR2 is to address usability for all users. Read More

Posted in News, VR by | 126 Comments