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.
We listened to some feedback and decided to bring mouse-look back but in a new and totally rewritten way. Originally, it was removed because as a MODE, it was confusing. Many users would pick it thinking it was “the” 3D cockpit mode and then be horrified that they weren’t able to use the mouse for anything else. Mouse-Look is no longer a MODE…there is only ONE mode which is 3D cockpit mode. This is the mode where you right click and drag to move your head and then use the scroll wheel to zoom…but now if you double right click, the view mode is locked into “mouse-look” so you can let go of your mouse button and the camera will still track the mouse movement. To get out of the mode, just right click again or switch views and it’ll disable. This works for users with a mouse and for users with a trackpad.
Quick-Look views have been fixed so that they now smoothly transition from one preset to another preset within the cockpit – without recentering each time. I do have to make an apology that your existing presets will no longer work with Beta 6 until you go to your aircraft folder and rename your preferences to *_view_prefs.txt. They used to be called *_prefs.txt. They won’t be lost or deleted, X-Plane just won’t see them until you rename them.
One other neat feature to note…it’s a really simple feature but I think it adds a nice touch of realism. As Tom was working on the Baron he said to us that since so many users like to start their planes from cold-dark-cockpit mode, they should have a way of using a flashlight so they can see what they’re doing before they get the plane powered up. What a great idea! So that’s what we did! Most aviators use a red flashlight to preserve their eye sensitivity so in the View menu, you’ll now see a way to Toggle on and off the Red flashlight. You can tie it to a keyboard or joystick button as well. There’s no menu entry for it but if you’d prefer a white flashlight, there’s a command for that as well so you can pick what you like best. Like all of the other fancy dynamic lighting in the sim, the flashlight only works with HDR enabled.
I’ll leave you with a little video demo of it to see while your X-Plane is updating to Beta 6 in the background.
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.
Once Ben is done fighting his war on HDR arthropods, Beta 5 will make its way out to the masses. In it, you’ll find some very cool updates to the view system that we think will make sim-life much easier, more intuitive and more useful.
The first change is the removal of the “mouse look” in 3D mode. This was the mode where the mouse controlled your camera orientation just by moving the cursor around without clicking. We had some feedback on the feature and agreed that it’s really not a very useful mode. The mouse is needed to click on various things in the 3D cockpit and to have your head bobbing around while you’re trying to do that was just annoying.
To look around in 3D mode, you can still of course right click and then move the mouse to adjust the camera angle. You can also use your scroll wheel to zoom in and out of things. This has been in the sim throughout the 10.x run and will remain the primary means of controlling head movement (unless you use your keyboard or Track IR of course). Since many people find the right-click/scroll gestures to be intuitive and useful, I’ve gone in and made things more consistent. Now, no matter what view you’re in, if head movement or zoom is possible, it’s done with right click and scroll. It used to require a LEFT click and scrolling was not an option. This should immediately help people who had trouble with the left clicks activating their mouse-flying box.
The final change is a pretty important one. We’ve added a system called “Quick-Look” (QL from this point on). Technically, you already have QL but I didn’t want to point it out to everyone until I had time to make some improvements to the system which I’ve done for Beta 5. QL allows you to get a view just the way you love it…and then save it to a hot key/cmnd that you can recall at any time later to go right back to the same spot.
For example, suppose you’re flying the default King Air and you find yourself frequently positioning your head, tilting down and zooming in on the throttle quadrant to see how you have the aircraft configured. This can take some time to setup and if you do it often, it can really get tedious. Let’s assign it to a QL then! Get the view the way you like it, and assign it to QL1. Now, no matter what you do to your views, when you press QL1, your head position, orientation and zoom goes right back to your memorized view of the throttle quadrant. It’s not just for 3D cockpit mode either. It works in all aircraft-relative views so 3D Cockpit, Ridealong, Chase, Circle, Forward with Hud etc. The reason for that limitation, is that these views are saved a little differently than other things in the sim. These are aircraft specific preferences. This is necessary so that your views for the Cessna 172 stay with the aircraft and don’t interfere with views for the King Air etc.
Currently, you get 10 QL views per aircraft and they’re saved/recalled anytime you switch aircraft. The QL keys are number-pad 0-9 by default. So for example, to recall QL3, just press the 3 on your number pad. To save a view to QL3, just get the view the way you like it, then press CONTROL + Num-pad 3. CONTROL is the default modifier key to do memorization. Like most of the commands in X-Plane, these are customizable so you can wire them up to any button combinations that you want. Also, you can use your joystick buttons as well to recall saved views.
A word of caution…some of you may have already discovered the QL system in earlier betas. That version is a fairly limited prototype (it only works in cockpit mode) so please do not report any view bugs prior to testing Beta 5. Lastly, your aircraft QL view preferences are going to get trashed with Beta 5 so please don’t spend hours tirelessly getting your views perfect for dozens of aircraft.
***EDIT*** Here’s a quick video I took of some sample views that I setup in the default King Air.
…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.
As you are hopefully already aware, the Joystick subsystem of X-Plane was completely rewritten for X-Plane 10.10. It uses a much lower-level method of communication to essentially talk directly to the devices so that we have complete access to their capabilities instead of being limited to what a “middleman” layer of software feels like telling us…which is how things used to work.
While most of the bugs have been fixed as of 10.10Beta 4, there still remain a small subset of devices that are still having problems. Let me list the known open issues:
Even after calibration, some devices still show their axis max limited to about 75% of what it should be when viewed on the Axis tab of the Joystick Dialog. In other words, pull the yoke toward you and it goes to 0, push the yoke away from you and it goes to 75% instead of 100%. This is not a joystick bug at all but in fact a UI bug that’s been around all along but just never visible until now. This has been fixed in 10.10Beta 5 which is coming soon. You can also go to the “Null Zone” tab and see that your axis does in fact have it’s full range of travel.
Some hardware does not appear at all on Linux. This is not a bug! This is a security feature of the Linux operating system. The problem is, Linux is a multi-user operating system and it has to worry about permissions to devices that are attached to the system. Take a keyboard for example…imagine if another user logged in could see everything you were typing because he had read permissions on your device! Linux locks down permissions on devices that are not part of an exception. The way to create an exception is to create a UDEV rule. If you don’t know how to write a UDEV rule, google it a bit..they are not very complicated for the average linux user. If you’ve chosen linux as your operating system, we hope you possess the skills to configure it. Here’s a simple sample rule:
Here the VID is 0x06A3 and the PID is 0x0BD4. These are unique codes that identify that brand/model of joystick and the rule says “When you see this device, chmod 666 it.” One way of finding your VID/PID is by doing “lsusb -n”.
Some devices have hat-switches that appear to “stick” in the ON position. This is fixed in 10.10Beta 5 as well.
Last but not least, there are some devices that have particular AXIS or HAT SWITCHES that simply do not work. So far, I’ve seen a Logitech G25 clutch pedal and a Logitech G940 hat switch that doesn’t work. It works in the windows calibration screen as well as X-Plane 10.05R1 but not in the latest version.
Here’s where you guys come in. If you have one of those two Logitech devices, please let me know if yours is working just fine or if you have the problem as well.
I’m also interested in hearing about other devices that are having the #4 issue as well.
Lastly, if you are having any other kinds of Joystick problems that do NOT exist in 10.05R1 but that DO exist in 10.10 that haven’t already been mentioned, please let me know.
You can file a bug and please include a Log.txt file from 10.10Beta 4 as well as a description of what’s not working properly and on which device.
(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).
Having such a small development team, it’s very difficult for us to test ALL conditions in which X-Plane is being used. Each of our offices are littered with joysticks, laptops, desktops, loose video cards, hard drives and various other hardware. We do our best to always be making steps in the right direction but it’s a losing battle to keep our testing internal. A prime example is the recent Joystick debacle. I rewrote the entire Joystick subsystem on 3 platforms and tested it on all 3 platforms on all joystick hardware I own, and Ben and Austin did the same. We worked out all known bugs and then shipped it…and immediately we found hardware that caused crashes 100% of the time. Once those were fixed, other devices were still broken…some devices didn’t even meet USB compliance and we had to work around that issue as well. I can’t possibly own every USB Joystick device on the market so how on earth do we get the product to be as stable as everyone wants it to be?
The answer is simple…we rely on ambitious and courageous users to take the plunge and help us test it. Being a Beta tester is a bit of a thankless job. Sure you get an early look at the new goodies but it can be very frustrating since often, you can’t enjoy them without crashes, artifacts and other annoying bugs. Most users are happy to provide their feedback via the bug form, and now with the new automatic crash reporting system, we’re finding and fixing crash bugs in record time. A prime example is the Joystick crash. Within minutes of releasing 10.10Beta 1, I was aware of the crash and had all of the information that I needed to solve it. And within 24 hours, we had a new build that took care of it. But that’s only useful for crashes, it doesn’t help us learn about visual artifacts or other problems. That’s where we need YOU.
After reading through the forums, it’s become clear to me that many people are just not exactly sure what it means to Beta test software so I’ve come up with my own list.
Keep two copies of X-Plane. If you care to ever fly X-Plane for enjoyment, ALWAYS keep two copies of the simulator on your hardware. One on a stable release that you use for enjoyment, the other on the latest beta for test purposes only. Your sanity will thank you later.
Don’t use the beta for recreation time. If you’re only in the mood to fly and have fun that night, stay away from the beta copy unless you don’t mind your flight getting cut short. Too many users expect to fly for 6 straight hours and become enraged when the sim crashes on short final. That’s Murphy’s law!
Always stay on the LATEST beta. Users often say “The latest beta broke XYZ, how do i go back to the previous beta?”. The answer is you don’t and you shouldn’t. That defeats the whole purpose of beta testing! During a beta process, the code is often changing very rapidly. If we’re on Beta 6 and you’re still submitting bugs on Beta 2, you’re wasting your own time and you’re not helping the product. It’s important you keep up with development.
Blame us, not your system. If it worked in Beta 3 but it’s broken in Beta 4, do NOT tear your machine to pieces trying to figure out the cause of the problem. Report it and let US figure it out. Time after time, I see users change their drivers, install service packs, uninstall and reinstall X-Plane, update their OS etc trying to solve the bug…when it’s probably OUR bug…not your computer’s.
Beware of the placebo effect! _EVERYTHING_ affects frame rate. Time of day, clouds, location, aircraft, view angle, view direction, addons, plugins etc etc. Sometimes we’ll release a simple patch that does nothing but fix one bug that was unrelated to the rendering pipeline. I’ll poke my nose in the forums to get some feedback and see 10 users who all of a sudden claim to see some massive fps increase in performance and 10 users who see a massive decrease in performance. I role my eyes at the claims because it’s not a controlled experiment. For example, if you’re the type of person who flies with real world weather enabled, flying one day with clear skies may get you 60fps while the next day you may see 40fps with overcast. Heck, even departing from a different runway than the previous day can result in different frame rates. Running with the command line fps_test IS a controlled experiment. THAT’s the only way to be sure you’re seeing a change in performance. Don’t trust your instincts, gather data in controlled experiments.
Always read the release notes (http://wiki.x-plane.com/beta) for each new version. They’ll tell you what bugs are supposed to be fixed as well as what new features have been added. If you see a bug that’s claimed to have been fixed yet it’s still happening to you, that’s when you write a new bug report. If we didn’t claim to fix it, it’s probably not fixed in that particular beta.
We need a Log.txt! When submitting a bug, ALWAYS ATTACH the Log.txt from THAT sim run. Even if you don’t think the Log.txt is applicable, attach it anyway. Tell us in as much detail as you can what you were doing at the time.
We already know about your crash. Because of the new automatic crash reporter, there’s no need to submit a manual bug report for crashes! Let the system do its thing. If you remembered some details after the fact that you want to tell us, then go ahead and file a report. Of course, if the auto-crash reporter didn’t load up for whatever reason, that’s a good time to file a manual report.
Tell us who you are and what you know. We really appreciate users who enter their email and comments into the crash report form. It gives us a way to contact you to get more information. This was invaluable to me when attempting to fix the joystick issues earlier in 10.10. A handful of really helpful users made the research a breeze.
Stop staring at the fps counter! It seems that many users are obsessed with their fps counter. “It went up this beta. It went down this beta. It stayed the same this beta.” Yes, the framerate is ONE useful metric to determine the software’s performance but it’s not the ONLY one and often it’s not the right one. Turn it off and fly! Enjoy the simulator. Sometimes there’ll be a bug in one beta that increases fps as a side effect because the sim is no longer drawing what it’s supposed to. Suddenly, some users are thrilled to see a 20% boost in performance and perhaps they don’t notice that half of the usual streets aren’t being drawn any longer. Ben fixes the streets and in the next Beta, all of a sudden they lose their 20% performance gain and are outraged that we “broke things again.”
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.
