X-Plane Developer Live Q & A
For those that missed it, here’s the recording of today’s live video Q&A.
For those that missed it, here’s the recording of today’s live video Q&A.
A new release candidate is now available for X-Plane 11.02. There aren’t many bug fixes listed on the release notes page, but we think (hope!) we’ve fixed the new issues introduced in r1 and sneaked in a couple other improvements such as:
There’s a new 11.02 release candidate available – if you had the 11.02 beta, you’ll be notified to auto-update. In a break with previous policy, this RC is available now on Steam as a beta, despite us not having had time to kick the tires. (Normally we wait 24 hours to make sure the beta isn’t nuclear before posting it to Steam.)
Release notes here. This build has some work Sidney did to improve pauses and stutters when loading orthophotos. Also, by request from X-Plane users at FSConn: a new art control gives you writable access to the fog ratio (for fog hackers) – set “fog/fog_be_gone” to…well, whatever makes you happy. I can’t promise this art control will be around forever, but right now it works and is writable (unlike “fog/std_deviation_cutoff”, which is controlled by the sim to match real world observations).
We’ve gotten a number of requests for video of the conference. Chris just posted these on our Youtube channel:
And the accompanying slides:
This is the original of Chris’s VR demo – he looks super dignified with the HMD on.
Finally, here’s video of the panel discussion from Saturday afternoon.
This one wasn’t recorded by us. There was a “serious” video camera at that event, so if there’s video with a direct feed from the mixer, I’ll post it.
I just got back from Flightsimcon (I live close enough to Hartford that it’s a day trip for me), but the show is still going on, and as you might have heard, we have X-Plane set up with built-in VR at our booth — you can try it! Austin, Philipp, Chris, Marty, Alex and Jim will all be there tomorrow, so stop by if you can.
If you’re local, stop by tomorrow – seeing the MD-82 cockpit in real stereo 3-d is something else. I’ve been working on VR support (on the rendering side) for the last few weeks and it’s really made me appreciate what our art team does.
I also wanted to say thanks to everyone there who has been supporting X-Plane, and also to the rest of the LR team who didn’t attend but who did the hard work that made today’s announcements possible.
There is video of our presentation – if there isn’t a better recording, Chris taped the thing, so we’ll get it posted probably some time this week.
Posted a few minutes ago: WorldEditor 1.6 release candidate 1. RC1 has a bunch of key bug fixes, is gateway-ready now, and can edit X-Plane 11 truck routes.
To get this beta you’ll need to run the updater and click “Check for New Betas” – we won’t ever prompt you to install a beta when you have a final release of X-Plane. Here’s the Release Notes. Please file bugs using the Bug Reporter!
11.02 is a small maintenance patch. Our main focuses were:
As a small beta, I’m hoping the entire beta period will be less than two weeks.
X-Plane 11.02 should be out this week; we’re down to one bug, whose fix I am verifying now. There have been a number of questions about performance, so to start, here is some info on three things we’ve done to make 11.02 faster than 11.01.
8-bit Water. The dynamic FFT-based ocean wave textures we stream in X-Plane 11 are floating point textures in 11.01 (F32 on the CPU, F16 on the GPU). This was an easy decision for getting the tech working, but as it turns out, transferring the textures to the GPU is slow, particularly on the NVidia drivers.*
For 11.02, Sidney has rewritten the shaders to cope with 8-bit waves. The results look almost the same, but the amount of data transferred is 4x smaller, and more importantly, 8-bit RGBA is the path most likely to be handled well by the driver, so this should be a win.
Sidney also wrote some code to transfer the textures asynchronously, but we’re holding off until 11.10 for that, as it may require debugging or behave weirdly on some drivers.
Faster Car Bucketing. The cars have always cost more CPU than they should, and profiling indicated that 90% of the work was in moving the cars around in our scenery system as they drove. The code to “rebucket” them has been modified and is now significantly cheaper. We are not turning the car density up yet (it’s not that fast), but at this point with the cars at the highest setting we ship, they now take 2-3 ms total to compute, which means they have no frame rate impact. I’d like to bring the density up in the future if we can get further performance wins, which I think we can.
Better Core Scheduling. If you’ve been reading carefully, you should be shouting at the screen about now about how the hell something that takes 2-3 ms total is “free” – 3 ms means that if you were running at 60 fps you’re down to 50. That’s not free?
I am declaring the cars free because they now run in parallel to the flight model, and it’s very likely that the total flight model work takes at least 2-3 ms, even without AI planes. The third optimization is a big cleanup of the multi-core scheduling that we do within a frame.
X-Plane uses multiple cores both to load background scenery as you fly and to speed up some calculations within a frame. As of now, the major “per frame” multi-core computations are:
X-Plane 11.01 was not scheduling these particularly well – here’s a picture.
What you’re seeing is X-Plane kicking off the FFT water too early, and that work blocks X-plane from completing AI aircraft calculations. The big red bar up top is the sim waiting (and FPS dying) because the AI planes weren’t done in time.
(The bottom ‘track’ with nothing on it is an IO thread that’s waiting in case we need to do UDP I/O. Since I had IO off, it is efficiently sleeping. This profile is on a 4-core machine so we couldn’t have stuck work down there.)
Here’s 11.02:
We start the (newly optimized) cars as early as possible so they complete at about the same time as the flight model; we get all DSF work done immediately, and we don’t start water until the very end. In the meantime, the main thread is free to go do the actual frame rendering.
This is just an incremental step for multi-core use; we have been steadily adding more multi-core work for the last few years, and we’ll be adding more in future X-Plane 11 updates. For example, X-Plane 10.50 re-structured the renderer, separating the work of discovering what to draw (“culling”) from the work of actually drawing. In X-Plane 11, we can do that culling on multiple cores, improving total framerate.
I don’t have great numbers on what kind of performance change you’ll see in 11.02; it’s actually hard to measure the improvements here with the FPS test because the FPS test runs a replay (and not the actual flight model) and doesn’t run long enough to generate car traffic. But we think it should be a good incremental improvement.
* It is not a bug that this case was slow for the NVidia driver; no OpenGL driver is contractually obligated to do anything in a particular time frame. It was slightly surprising in that NVidia seems to go farther than other GL vendors to optimize less common and less efficient code paths.
NVidia does normally allow for complete threading of CPU-side driver work, so it’s possible they thought there was no need to optimize this case directly since it would be on a worker thread; by comparison, Apple does not use a general worker thread for their driver but does use a worker thread for all CPU-based texture transfers, at least as far as we can tell by profiling X-Plane.
The FMOD development guide now contains a link to the FMOD starter project generator.
If you want to make an aircraft that is FMOD enhanced, you must start with this starter project! If you already have an FMOD project, please copy the events into this new starter project.
When can an FMOD project be shared?
We are working on more documentation on how to use FMOD, but with the sample project, you have everything you need to create an FMOD-enhanced aircraft.
X-Plane 11.01 is now final, both via our installer and Steam. We’re going to do one more bug fix release (11.02); at this point it looks like Gateway airports will go into a separate 11.05 release to give authors a little bit more time to work with WED 1.6, but we’re still discussing this internally.
In terms of timelines and releases:
That’s a lot of stuff in that second bullet point – there is basically no chance that all of that will make it into 11.10; we have enough long term efforts going on at once that some will go into 11.10 and some into 11.20 or something later. I don’t even know which of those things will be in 11.10 – basically, what’s ready around when we get to 11.10 will be released, and we’ll do another release when more features build up.