First, I appreciate everyone’s cooperation with the RFC on scenery; we’ve had an ongoing discussion in our developer Slack as well as the comment section, and I don’t think I had to nuke any off-topic comments. The feedback was wide-ranging and there’s no one clear answer but it does give us a really good picture of how the scenery system is working (and isn’t working).
It’s Friday, so let’s do something completely different – her’s some show and tell from a few things people have been working on things week.
Light It Up
Alex has been recalibrating the runway and airport lights for the new photometric lighting engine. This spurred an internal discussion about how best to calibrate artificial light sources. Does the author specify the luminance of the bulb before a tinted plastic housing goes on top (this way is good if you have the bulb specs from the internet) or based on what you’d measure when the finished light is tested? (This way matches FAA specs for airport lights.)
After going back and forth a few times, our answer is “well, both”, and we have a system that now allows this, which should solve use cases for both aircraft (where often the bulb properties are known because you can look up replacement parts) and for airports (where the FAA has standards for the light’s final results).
Something to keep in mind: urban airports are quite dark compared to their surroundings. Ther are very few light sources near the runway that aren’t tightly controlled for brightness and direction. I used to fly over KLAX on a regular basis at cruise altitudes (commuting from San Diego to San Francisco for work) and KLAX was always an inky black void in the sea of lights that is the LA basin; at 34,000 feet no runway lights are pointed up at us.
Wet Surfaces
Petr and Sidney have been working on the weather surface shader, which applies water and other weather effects to surfaces. This is how we dynamically make the pavement wet when it rains.
The shader is tricky because the effect of a surface being wet changes a lot once the water forms a real puddle. When I took my kids to their swim lesson, I couldn’t help but notice the useful reference material all over the place.
A rough wet material – reflections change with angle in X-Plane and real life
Stop Writing on the Windows
I must be a dad, because I get annoyed when my kids get finger prints all over the windows when they “write” things in the frost on a cold day.
Turns out Sidney does the same thing.
What you’re seeing there is programmer art. Programmer art is when the programmers make their own texture files to test code. In this case, Sidney is testing the defrosting system for windscreens, which use a special texture to specify the pattern of defrosting. This lets artists control the defrosting effect and get faster defrosting near vents.
Another “behind the scenes” thing you can see here: that popup window is a set of internal controls for testing, debugging and developing the windscreen effects. The parts of these internal controls that are generally useful will become third party developer tools (like the texture browser and particle system editor in X-Plane 11).
Cessna In Spaaaaaaaace
Daniel rewrote the planet shader. In X-Plane 12, water is treated separately from land (so that it can be 3-d). The new planet shader shows a far view of water and a far view of land at the same time and correctly shows atmospheric scattering, which is normally pre-calculated in a special “froxel cache” for regular scenery.
If you haven’t noticed the pattern, it’s that the art team’s screenshots all tend to look good enough to ship, and the programmer’s screen shots tend to be very, very silly. In this case, the Cessna in space is pretty silly, but what we were looking for was the smooth atmospheric effects all the way out to the horizon.
Here’s one more goofy programmer screenshot:
I was calibrating the runway lights according to Alex’s spec, and typed an extra 0 into one of the internal art controls by accident. The result was this fantastic screen shot.
What you’re seeing is: the billboards for the runway environment are accidentally huge and are filling up the entire reflection cube map. The reflective underside of the Cessna wing picks up this blue lights and it looks like a rave.
Since my last Vulkan update, we now have the full sim running natively with Vulkan and Metal! There is still a pretty big list of random things turned off or bypassed to make this happen, but we can fly in the cockpit and use the sim.
Here’s some stuff that is now working:
Using regular and HDR rendering, and SSAO on metal.
Flying with Vulkan on AMD, NVidia, and Intel drivers.
Hardware stereo rendering on OS X – this never existed before Metal because the Mac GL drivers didn’t support it. Hardware stereo rendering is necessary for VR support.
MSAA on Metal – with the restructuring of our code, you’ll be able to change MSAA settings without restarting. I don’t know if this code works on Vulkan right now; it might.
Here’s some stuff that does not work yet:
Plugins are bypassed right now. We have not yet written the plugin-OpenGL-interop layer.
VR only works when using OpenGL as the driver; we need to write some new VR code to pass Metal and Vulkan frames directly to the OVR and Rift APIs.
Screenshots/Movie capture are a work in progress – that’s what I’ve been working on this week.
We still have a number of visual bugs, so screenshots are an important feature so we can run our automated test system. The test system takes hundreds of screenshots of the sim in many configurations and compares them to 11.30 to catch bugs introduced by the new Vulkan and Metal back-ends. Clearly I’ll have to fix my color problems first.
One fun aspect of this port: Metal and Vulkan copy Direct3D’s convention where the viewport Y axis points down and not up. This resulted in a whole series of weird “it’s upside-down again” bugs, most of which have been fixed.
The world is drawn correctly but the atmosphere around it is upside down.
(That airplane might look silly, but at least all of the image is consistently upside down. That’s because the only remaining upside down code is the movie/screenshot capture code itself.)
We should have some performance numbers to post next week; right now our primary focus is fixing bugs, particularly bugs that bring the whole machine down.
Here are a few more pics of things that have gone wrong during development.
We’ve been breaking X-Plane apart so we can put it back together with a revised flight model, shaders, joysticks, and particles. All these changes have resulted in some interesting effects at times. Here are some of the best mistakes I’ve seen as we’ve been hammering away at 11.30. Enjoy! Read More
Normally we try not to pre-announce new features before they are complete, but it’s been kind of an open secret around the company that we are working on native VR capabilities for X-Plane. Austin mentioned it on a Facebook Live stream, and Chris posted pictures of un-boxing his OcRift and Vive.
So today I’m going to show you a sneak preview of something that I’m just too excited not to post: X-Plane 11’s new Pirate-VR™ mode*.
There are two major challenges to integrating VR with a general purpose flight simulator:
Performance. X-Plane typically runs at 30-40 fps on a high-end system on a single monitor. How do we render a stereo image to two eyes without cutting frame-rate in half?
Usability. How do users interact with the complex cockpit buttons and switches using 3-d “wand”-type controllers that ship with today’s VR head-mounted displays?
Pirate-VR™ mode solves both of these problems.
When rendering to the head-mounted display, we simulate an eye-patch over the left eye.
By blacking out the left eye, we are able to recover quite a bit of framerate and run a stereo render at over 40 fps; minor optimization should get us to something fluid for the HMD.
In Pirate-VR™ mode, both of your hands are replaced by large metal hooks. Since it is pretty much impossibly to safely operate the over-head panel of an MD-82 with hooks for hands, we can skip 3-d interaction testing on most of the cockpit, simplifying VR interaction quite a bit.
I can’t announce when Pirate-VR™ will ship, but for scallywags who will be joining us at FlightsimCon in Hartford** this year, I think we’ll have something you’ll really want to get your hooks into.
* Yes, it is, of coarse, pronounced “Vee-ARRRRRRRRRR!”
** Update: my wife points out that the correct pronunciation is HARRRRRRRRtford.
Now that we have announced X-Plane 11, I can finally post goofy screenshots and videos from v11 development. Sometimes a bug makes delightfully goofy results, and Austin liked this one so much he wanted me to share it.
I am working on 3-d water for X-Plane 11 – we have a working prototype, but I am not sure if this will make the shipping 11.0 product; it still has a lot of bugs and rough edges.
Traditionally in X-Plane if you don’t have terrain installed, you just get water. This isn’t really an intentional design decision; we just defined “no DSF” as “all water” so that we could avoid shipping DSFs for the huge chunk of the Earth’s surface that is covered with ocean.
But we always have airport data, so in X-Plane you would get an airport floating in the middle of the water! While this was completely goofy and is a huge source of tech support calls (which is why X-Plane 10.50 now offers to install scenery whenever you hit this case) you could, if you really wanted to, land at this water-world airport.
Until now. Now that the water is 3-d, the peaks of the waves actually cover the 3-d buildings and make the entire airport as usable as…well, as it really would be if built in the middle of the ocean.
(This is about the point in the post where I would insert a snarky climate change comment, but I’ll let XKCD do the talking.)
Scenery developers might wonder: why is it that when the water level falls the runway lights and signs are revealed – but where is the pavement? The answer is in the comments.
This rather odd 747 picture is from a quick test I did to make sure the shadow options in Plane-Maker were working right after beating the shadow code silly with a hammer. The wing objects have been marked “interior only” for shadows, and since we are in an exterior view…the wings don’t cast shadows. 🙂
Now this is a totally silly way to use the feature, but there is a legitimate use: mark as many of your interior objects as “inside shadow only” as possible; for example, in the 747 the interior passenger cabin object can be marked as interior only – it doesn’t cast meaningful shadows on anything outside the airport.
By marking an object as no-shadow in Plane-Maker you save the sim the work of drawing the object, which is good for fps. If your airplane is used for an AI plane, this makes AI plane drawing less expensive.
In fact, you save it the work of drawing it multiple times. X-Plane using a shadowing technique called “cascading shadow maps”. Basically X-Plane renders different parts of the world at different resolutions, so that the closer shadows (that can be seen in more detail on screen) have a higher resolution. The user’s plane ends up being drawn in a lot of these rendering passes, and as a result the cost of high-geometry-count objects in an airplane can be amplified several times over by shadows. So savings in object-shadow count matter!
(Given the choice of turning off shadows in Plane-Maker or via GLOBAL_no_shadow, use Plane-Maker; it stops drawing earlier and thus saves more CPU.)
