Conventional 3-d games like first-person-shooters and racing games are just full of cheats in the rendering engine. And that is not a bad thing! By cheat I mean they find clever ways to optimize performance that make the game look good while doing less work. The result: better framerate, better graphics.
I look at these games with a bit of envy because those cheats are often inapplicable to general purpose flight simulators for two reasons:
- The unrestricted viewpoint of a flight simulator is incompatible with a number of optimizations that on-the-ground or movement-constricted games can apply.
- Since a lot of our content comes from a third party, we can’t apply restrictions and optimizations across the entire set of content for the sim.
Despite these limitations, rendering-engine specific optimizations are beginning to creep into X-Plane as the engine becomes more powerful. These options and optimizations are unsurprising to anyone used to making 3-d game content but new to X-Plane itself.
What Is a Light Group?
Light groups are a cheatoptimization available in many 3-d rendering engines. The basic idea of a light group is that the author of 3-d content can create 3-d lights, meshes, and then specify which lights apply to which meshes.
There are two big advantages to light groups:
- Lights are expensive in traditional (non-deferred) rendering engines; by restricting which lights affect which objects, an artist can reduce the average number of lights applied to their 3-d meshes, which is good for framerate. (Using light groups to remove lights from objects that are out of the light’s range can be done automatically by a pre-processing tool.)
- Lights in games often do not cast shadows, either because the engine can’t support this (this is the case for X-Plane now) or just because shadows are expensive to generate. With a light group, artists can get correct results without shadows by simply marking geometry that is shadowed by the light as not in the light group.
As an example of the second case, imagine that you have two rooms separated by an internal wall and a powerful light source in one room. If the light source casts shadows, the unlit room will be dark because the entire room is shadowed by the internal wall. But if the lights do not shadow, the light from the lit room will “leak out” into the second room.
With light groups, an artist simply marks the second room as not being part of the light’s group, and the rendering engine doesn’t even consider the light. The dark room renders faster and has no incorrect light leakage.
Light Groups in X-Plane
X-Plane implicitly has two light groups: the exterior of the user’s aircraft, all AI aircraft and the entire world, and the interior of the user’s aircraft. In X-Plane 9, landing lights don’t light up the cabin interior, and the 3-d lights inside the cockpit don’t light up the runway or the landing gear.
In X-Plane 10.05r1 HDR mode was not supporting these light groups correctly; one obvious example was the Piaggio tail landing light spilling light on the cabin seats. This is now fixed in X-Plane 10.10. Just like X-Plane 9, your choice of “interior” or “exterior” for Plane-Maker objects matters for lighting!
Light Groups and Spill
What if you include spill manually by attaching a named light that casts spill to an object? What light group should the spill cast light on?
My idea to resolve this is:
- Spill lights attached to “exterior” Plane-Maker objects will be part of the exterior light group and only light up the aircraft exterior and surrounding scenery.
- Spill lights attached to “interior” Plane-Maker objects will be part of the interior light group and only light up the aircraft interior.
- Scenery-attached spill lights will light up everything. (Perhaps this should be “exterior” instead? I am not sure!)
For a non-enclosed aircraft (E.g. an old biplane with no cabin) you would not use the interior light group at all – everything would be exterior and all lights would affect everything.
If an aircraft has two light groups (interior and exterior) and a light affects both, you can simply include the spill light in two objects; the spills are cheap. This also means you could make effects. For example, if the spill light does actually light up the interior a little bit, rather than having the actual landing light blast the cabin with directional light, you could include an exterior spill for the landing lights themselves and a second interior spill that is omnidirectional, dimmer, and tinted, to represent the reflected light that makes it into the cabin.
I’m way behind on documentation, and there isn’t any documentation for this yet, but to clarify:
In the named lights list, spill (casting light on the ground and other stuff in HDR mode) and billboards (a square that faces the camera with a picture of the light from a light bulb) are always separate!
Typically the spill light has the same name as the billboard with an _sp suffix, or the billboard has _bb.
Why did we do it this way?
The lights are kept separate because:
- We do not have enough information from the billboards to know how to make a spill. For example, you have a v9 parameterized landing light billboard on your aircraft OBJ. How big (in meters) should the spill be? We don’t know! The billboard params never included enough information to know things like the size and cone ark for a spill light.
- There may not even be a 1:1 correspondence of spill to billboards. For example, any time there is a multi-lightbulb enclosure, it can be a win to use more billboards than spills; overlapping spills hurt fill rate.
Spills are therefore “opt-in” at the named light level; you opt in by adding a _sp variant.
Note that if you use Plane-Maker’s light level, you get spill for free; that interface is a higher level, simpler “I want this thing” type of interface. It only knows about the basic airplane light types, but it is fairly powerful. For example, you can create multiple landing lights (controlled by multiple switches), and you can use the “generic” lights for utility purposes, like inlet ice lights, leading edge lights, logo lights, etc.
I have updated the OBJ8 specification with the new X-Plane 10.10 commands. This blog post explains why we added some of these commands.
Pixel-Space Drag Manipulator
The pixel-space drag manipulator is a new axis manipulator whose drag length is measured in screen pixels instead of meters; its drag axes are always screen aligned, but it works both horizontally and vertically.
The goal of this manipulator is to make draggable knobs that:
- Have a good response speed for both slow and fast drags via a non-linear curve and
- Have the same drag sensitivity no matter what camera angle.
The axis manipulator has the problem that it works in 3-d; depending on how you look at the manipulation target (both position and rotation) the sensitivity of the drag can change radically.
Recommendation: use the regular drag-axis manipulator for levers and other physically moving items. Use the pixel-space drag manipulator for drags where the underlying target does not move, like knobs. Use button-type clicks for anything that just toggles – it’s easier on the user.
No Shadows
Three new attributes (GLOBAL_no_shadow, ATTR_no_shadow, and ATTR_shadow) allow you to exclude part or all of your object from shadow casting. Shadows can make certain types of geometry, like grass billboards, look silly; excluding them from shadows fixes artifacts.
Note that ATTR_no_shadow is different from ATTR_shadow_blend..
- ATTR_no_shadow: the geometry simply does not cast a shadow! This is meant to exclude objects like vegetation.
- ATTR_shadow_blend: the geometry does cast a shadow, but only if the alpha is greater than a certain ratio. This is meant to make windows with tint cast shadows correctly.
Recommendation: fix shadowing bugs using ATTR_no_shadow for non-instanced objects, and GLOBAL_no_shadow for instanced objects. Use the Plane-Maker check-box for parts on aircraft.
GLOBAL_cockpit_lit
This attribute lets you have your cake and eat it. In X-Plane 9, ATTR_cockpit gives you alpha blending, but ATTR_cockpit_region gives you correct 3-d lighting. You have to pick one or the other.
In X-Plane 10.10, GLOBAL_cockpit_lit gives you both. It makes ATTR_cockpit use 3-d lighting (while maintaining translucency) and it makes ATTR_cockpit_region respect alpha translucency (while maintaining cockpit lighting).
You can add this attribute to any airplane. This attribute should make it easier for authors to adopt correct 3-d lighting in their airplanes.
Recommendation: use GLOBAL_cockpit_lit on any airplane that uses ATTR_cockpit to change to 3-d lighting for your panel texture. Also see here for more guidance.
…between myself and X-Plane’s deferred rendering engine. It is a battle to get correct alpha blending behavior when scenery objects fade with distance. Current casualties include a good chunk of the existing HDR shader code and my sanity. Once there is a victory (no guarantees it will be me) we’ll cut beta five.
(Oh come on, I know at least some of you are Dr. Who fans…)
If you have not read the news, OpenStreetMap will be removing their non-license-compatible roads this week. I stopped following the debate on this years ago, but basically they changed open licenses and have had to drop contributions that could not be re-licensed from the original authors. My understanding is that the amount of data that will have to be nuked will be very small.
If you have already contributed to OSM even remotely recently, you probably agreed to the new license terms and your data is fine.
My thought: after the redaction is finished would be a great time to check your home town and help put back any lost roads, etc.
Propsman sent me this rather zen bit of OSM the other day…
I certainly hope they won’t have to redact it. 🙂
(Seriously though, one of the major data quality problems with X-Plane is people creating train platform and building footprints out of actual train tracks. If you are working on an area, please check the tagging of stations and platforms to make sure they’re not actually railways!)
I do not have a schedule or plan for recutting from new OSM data – it’s an aspiration right now but there’s a lot on the short list we have to deal with first (like 10.10).
If you haven’t run beta 3 and already been told so, X-Plane 10.10 beta 4 is out. Hopefully we have a beta stable enough for it to last more than 48 hours.
The ability to draw the inside of your Plane-Maker fuselage is going away. In X-Plane 10.10 beta 4 you will still see this geometry if your airplane uses it, but:
- There is no option to enable this in Plane-Maker anymore and
- If you save your airplane in Plane-Maker, the feature is turned off.
I’ve blogged about the path to removing a feature before; the basic idea is that we are not forcing you to update your airplane now, but the next time you go into Plane-Maker to do work on your plane, you will have to fix your use of interior geometry too.
If you really want your interior to look exactly like your exterior, but inside out, it’s not hard to get this effect:
- Export your airplane as OBJs from Plane-Maker.
- Open the fuselage in a 3-d editor and flip the faces.
- Attach your new “interior” in Plane-Maker.
Here’s the overall LR viewpoint on Plane-Maker and drawing:
- OBJs are the way to draw an airplane. OBJ provides all of X-Plane’s rendering features, really good performance, a stable file format, and good tools to edit.
- Visualization of the built-in Plane-Maker geometry is good for simple planes and experimentation, but it is not at all meant for serious graphic work.
- We will not be adding any of the new rendering features to Plane-Maker’s “built-in” drawing.
- We don’t think “I can’t draw X without an OBJ” is a problem; use an OBJ.
In other words, we’d rather focus our effort on a single drawing path, OBJ, and not invent a parallel, inferior second drawing system using Plane-Maker beyond what’s needed to simply say “there is my airplane.” Thus we are not adding new drawing features to the Plane-Maker geometry.
When I saw this near KMSY in New Orleans my first thought was: oh hell, what bug created that? All of the roads seemed to run over these channels of water, as if someone had created mini-rivers for them. I assumed bad OSM data.
Then I looked the area up on Google and…no, they actually built the road over water intentionally.
View Larger Map
X-Plane 10.10 Beta 3 is here. To avoid having to type it each time, all of the info about betas is now on the release notes page here. Please read it carefully! Please: no bug reports on the blog, only on the bug report form!
You may have noticed the large number of joystick-related bugs in X-plane 10.10, something that is unusual for X-Plane betas. There is a reason for this: Chris totally rewrote the joystick IO code from the ground up for 10.10. We had been living on the same old dubious code for perhaps 5 years before; the new stuff is literally brand new.
Chris is working through the joystick bugs at a pretty quick pace. We will continue to push betas frequently as long as there are bugs that interfere with us collecting other bug data (e.g. crashes, joysticks totally inop, etc.); then we’ll slow the pace of betas down to get more fixes in per beta.
What possessed us to send Chris off into HID land on a quest for new IO code? The new IO code is meant to support a number of features, a few in 10.10 but most coming in a future build:
- Hot swapping (here now).
- Correct hat switch operations (here now).
- Preferences bound to more than one stick without resetting (here now).
- Automatic configuration (coming in the future).
- Better descriptions of the hardware in the UI (coming in the future).
- Ability to easily open source the Linux IO code (coming in the future).
The new code sets up a unified interface to the hardware, with the hope of sharing configuration info and being able to open source the low level IO code.
The long term goal is to make it really easy to work with X-Plane joysticks: plug it in, go through the absolute minimum configuration just once, and you’re flying.
What, You’re Not Root???
Linux nerds: X-Plane 10.10 moves from the joystick API to the input API for joystick IO.* The input API gives us a modern interface with better meta data about the hardware. However we have seen cases where the access control list on the “event” device for the joystick isn’t user-readable even when the “joystick” device is.
Chris is still discussing what we can be done with knowledgeable Linux types, but my view is: this seems like a bug. If the device is safe for users as a joystick, it’s safe as an input event source, and it shouldn’t be necessary to make a udev rule and/or chmod the device entry to use the joystick-type device. So perhaps at some point we can push corrected udev rules up into upstream distributions.
But this isn’t something that Chris and I have any expertise in; if you are a Linux X-Plane user and have expertise in the area, please keep an ear open for when we get closer to a resolution on this issue.
(In the meantime, you may have to take the sudo-hammer to your joystick in 10.10.)
* Our preferred interface would be a HID interface, but we don’t have our own HID descriptor parser; we use the OS X and Windows one. There are two show-stoppers to speaking raw HID. One is the lack of a parser on Linux and one is that the raw HID-as-report device has similar permissions problems to the ones mentioned above for weird joysticks, except the permissions are root only all the time.
So some day in the future perhaps we’ll get to reading raw HID (which would give us perfect similarity to Mac/Win) but for the time being we expect to ship on the unified input interface.
***CHRIS’S EDIT*** I _think_ I’ve squashed all kinds of Joystick related crashes and Joystick calibration issues. These are issues where the stick would not move smoothly from one end of travel to the other. I also think I’ve squashed issues where certain devices/axis were just not showing up. If you have a device that’s still having problems with Beta 3…PLEASE FILE A BUG REPORT. I definitely want to know about it. Always include a Log.txt from a sim run that had the device attached.
One of the changes to X-Plane 10.10: custom scenery packs now are tracked in an .ini text file called “scenery_packs.ini” that sits in the custom scenery folder. This blog post explains how the .ini file works and what problems it was trying to solve.
The Old Days
Long ago, in X-Plane 10.05r1 (and every version before it dating back to X-Plane 8) X-Plane would load custom scenery packs in alphabetical order from a folder called “Custom Scenery”. This simple convention was a work-around for not being able to “manage” scenery pack load order.
In the old days, you could change priority of a pack by renaming it and disable it by moving it to a different folder. I have a number of packs called a_Some_Overlay and z_Base_Mesh and I’m sure others do too; I also have a folder called Custom Scenery (Disabled) that I dump stuff into.
Unhappy Installers
The problem with the old way is that users have to manage scenery packs by renaming and moving them. If an installer has installed a pack, it won’t be able to find what it installed again. We started to see this with X-Plane reinstalling the Aerosoft custom scenery packs that come with the global edition of X-Plane; users would delete or reprioritize the pack and our installer would not be able to update the pack because it had moved.
scenery_packs.ini: Explicit Priorities
scenery_packs.ini simply contains a list of scenery packs to load in priority order: top of the file is highest priority. Listing the pack as SCENERY_PACK_DISABLED disables loading entirely.
This means that a user or third party utility can now organize and prioritize scenery without having to rename files. Installers will still be able to find their installations and packs can have their “factory” names.
How Does scenery_packs.ini Get Updated?
What happens if the file system and scenery_packs.ini are out of sync? Here are the rules:
- Any scenery pack listed in scenery_packs.ini but not present is removed from the .ini file on load.
- All scenery packs present in Custom Scenery but not in the .ini file are added to the top of the .ini file in alphabetical order.
Note that this means that your new packs are installed in alphabetical order relative to each other, but they are installed with higher priority than any existing packs.
We can’t easily install new packs in alphabetical order compared to all packs because all packs may not be in alphabetical order if the packs have been reorganized.
Ways to Reorganize Scenery
There are a few work-flows I can think of to easily re-prioritize scenery:
- Edit the .ini file. It’s just a list of files, and can be reordered as desired.
- Remove some packs, run x-plane, quit, and add them back. Those packs will go to the top of the list.
- Delete the .ini file. The entire file will be rebuilt in alphabetical order.
The Future
Someday I do hope we’ll have a UI to organize scenery, but we don’t have one yet and won’t have one for 10.10. My thinking is that it’s still an improvement to not have to gum up scenery packs with prefixes to control their load order. But this does cause some work-flow changes. (If you want to continue to use alphabetics, simply delete the .ini file after editing.)
See here for release notes with a list of bug fixes, and file bugs here. (BTW, if you are going to email one of us to ask if you should file a bug, please just file a bug. 🙂 It’s quicker for us that way and for you too!)
If you already have 10.10 beta 1, simply launch it – the auto-update will kick off much earlier during load. If you don’t have beta 1, you need to run the DVD installer or demo installer and update with “Get new betas” checked.
And if you would be even remotely sad if your computer sprouted legs, stood up, grabbed your USB joystick and threw it out the window, don’t install betas. Everyone will get 10.10 once it is final – install the beta only for testing purposes, not for flying enjoyment!
Posted in News
by
Ben Supnik |
