This post is a summary of what is going on with the X-Plane 10 starters. I am working on a more comprehensive X-Plane 10 aircraft update check-list that will include starters.
How the Starters Used to Work
In X-Plane 9.70 and 10.05r1, the starter motor applies a constant torque to the engine to increase its RPM. As you motor the starter without adding fuel and spark, the engine’s drag will increase (due to its higher RPM – pretty much all engines move air when turned and thus have higher drag at higher RPM) and eventually you’ll hit an equilibrium: the torque of the starter exactly matches the drag of the engine and you sit there at a constant RPM. This RPM can be quite high because the starter motor can deliver its torque at any RPM.
The torque of the starter is decided by X-Plane using a formula known only to Austin and a few highly trained monkeys that have secure access to the X-Plane source code. The starter “ratio” you set in Plane-Maker is a scaling factor on that ratio. A scaling factor of 2.0 doubles the torque, and a scaling factor of 0.5 halves it.
Note that the default torque (1.0 scaling factor) varies by engine type and engine size! The justification by this is that if you don’t want to have to deal with starters, you set the starter ratio to 1.0 and X-Plane’s “natural” choice is strong enough to start your engine. In practice, the default torque is surprisingly high for jet engines, but at least they start!
How the Starters Work in X-Plane 10.10 Beta 11
Pay no attention to X-Plane 10.10 beta 11 – the changes for RC1 are quite significant.
How the Starters Work in x-plane 10.10 rc1 (coming soon!)
X-Plane 10.10 rc1 is also a torque-based model, with the starter putting out constant torque. There are two key changes:
The torque is expressed as a ratio of maximum engine torque, not a ratio of an arbitrary default torque. This change the numbering scheme! When you open your aircraft in 10.10 you’ll see the new numbering scheme. For example, the default torque in X-Plane 9 for a jet engine was 50% of engine max torque (see above that jets started really fast), so if you set a starter ratio of 0.6, the net result was 30% of max engine torque. In X-plane 10.10 you will just see 0.3. In other words, what used to be a ‘secret scaling factor’ is now baked in to your starter value.
The starter now has a maximum design RPM; past this RPM its torque will fall off – very very quickly for electric starters, less so for bleed-air starters. The default will be 100% of engine RPM, so for old planes the starter will continue to motor up to equilibrium. You can turn this number down to model the real world: real starters generally can’t put out their maximum torque up to really high RPMs.
For piston engines with electric starters, I recommend setting the maximum RPM very low and the torque fairly high; a real electric starter for a piston engine is going to put out a ton of torque to get your engine to turn over, but it just can’t run that fast.
For turbines, make sure your design RPM is well above your fuel introduction point. From what a number of people have told me, the starter can often be motored quite a bit past the fuel introduction point.
The net of all of this is: no change from 10.05 for existing aircraft, but the potential to fix a number of weird starter behaviors in 10.10 by limiting RPM. (One advantage of the RPM limit is that you can increase the starter torque without getting an absurdly high terminal RPM.)
First a quick note: X-Plane 10.10 Beta 11 is now out. What happened to beta 10? It lasted about 15 seconds, from when it went live to when I realized that aircraft were missing and code signing was screwed up.
We’ve had a few of these “beta bounces” where a beta lasts less time than a Plutonium isotope. The basic policy is this: if we cut a beta and it is live on the net at all, even for one second, and we then realize the beta is borked, we cut a new beta with a new beta number. Thus the very short life span of beta 10 – we didn’t reuse the number 10.10b10 when we fixed the problems.
Why not just reuse the beta number? Because we want to make sure that anyone who accidentally gets the broken beta gets the new beta, and to do that we have to bump the version number. Now that X-Plane auto-checks for updates, people get the new beta within seconds of it going live.
Autogen
A while ago I posted a road map for our autogen cities. Part of the work involved improving the road generation algorithm (a lot of which has been done for 10.10, and some of which still needs more work) and part involved new art assets.
Our original plan was to include the latest art assets with 10.10, but we are now planning on releasing the next round of city art assets with 10.20, the 64-bit version of X-Plane. There are two reasons for this:
The urban assets aren’t entirely done, but they are very inter-dependent. To maximize framerate, Propsman shares as much texture as possible betewen parts of the urban package, so it’s quite tricky to release part of the autogen.
The new autogen does take a little bit more memory. Not tons more, but for a user on the red line with 32 bits, upgraded autogen might require memory that isn’t available.
So rather than take up Propsman’s time finding a way to cut off and release part of the art assets, only to hear from users that thy are out of memory on OS X, we’re thinking it’s better to get on with 64-bit and release the art assets as a whole on a build that can handle them.
I think we may be able to release the new road pack with 10.10, and a number of other art assets are already in the 10.10 betas – new aircraft, upgraded global terrain, and new lights.
I just made the X-Plane 10.10 beta live only to realize that: some of the airplanes are missing. We are reorganizing where the fleet is stored, and the installer didn’t kit them properly. So:
If you ran the update and are now missing some aircraft, you can update back to beta 9 to get them, or wait until tomorrow.
A new beta will be posted tomorrow with the aircraft all present, just in their new locations.
Beta 9 is “live” again until I can get things repacked – should be less than 18 hours.
Sorry about the confusion!
Edit: And…it looks like there’s something weird going on between our software that creates the patches and Code Signing (which we’re just starting to do for Mountain Lion users). So…it might take a little longer than expected to get this beta kitted.
Airplane authors: prepare yourselves! I am now very close to closing the last of my fixable bugs filed against the 10.10 aircraft SDK. This means that the next beta will be the one to test your airplanes against. If there is a problem with your work in 10.10 and you tell us after 10.10 goes final, it may be very hard for us to fix it, so if you’ve been waiting on 10.10 betas, please go get the beta now and be ready to test shortly! If you have been waiting and letting your users try 10.10, start downloading now!
One of the main goals of 10.10 is to have the airplane authoring SDK provide similar visual results when HDR is on and off; another is to have these results remain the same for the rest of the v10 run.
Long Term Future Proofing
Lighting model changes represent one of the trickiest engine changes we can put into X-Plane. When done right they add realism, but they also fundamentally change how an author’s work looks. With 10.10, the v10 lighting model is “done” for the version run, but I don’t think it will be the final model forever. The v10 lighting model definitely contains some compromises to make translucency and v9-style authoring techniques work.
A question came up in the comments as to whether HDR mode with the deferred rendering engine and global lights might become the standard rendering mode for X-Plane 10. I think some day it may be – just as we used to have an option: pixel shaders or not, and now they are always on, I expect that most rendering innovations will eventually become standard over a long enough time frame as hardware continues to scale up.
(We have already seen this in first person shooters: the first ones to feature a deferred rendering engine often provided two rendering modes; now new games tend to be deferred-only.)
We certainly view the deferred engine and HDR mode to be preferred, and that’s why so many effects are HDR only. There are effects we can only do with a deferred renderer, and there are effects that are much cheaper to build into the deferred renderer.
Beyond X-Plane 10
If you are working on an aircraft and you’d like it to work well not only with X-Plane 10, but also X-Plane 11, here are a few things to avoid. These features are supported in X-Plane 10, but we see them as compatibility features, not “good things to use.”
Avoid using the cockpit texture without real 3-d lighting. This happens when you use ATTR_cockpit without GLOBAL_cockpit_lit. The cockpit texture without 3-d lighting is still supported in version 10 but it is not recommended, and you can get some weird artifacts. Over time these problems will get worse (as the lighting model becomes more sophisticated) and a 3-d panel that doesn’t obey the lighting model may not even be possible after X-Plane 10. Fortunately you can use GLOBAL_cockpit_lit to turn on 3-d lighting and in almost all cases it will “just work”.
Don’t use ATTR_diffuse_rgb and ATTR_emission_rgb. Instead, paint the color into your albedo and lit textures and use ATTR_light_level.
Make absolutely sure that everything translucent is marked ‘glass’, and that nothing is translucent unless there is a really good reason. Alpha is really tricky for a deferred renderer! This is good advice for v10 as well.
X-Plane 10.10 beta 10 will be out soon, as well as more detailed instructions on airplane updates.
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.)
[Scene opens with a joystick being thrown across the room in frustration. Camera angle is from the ceiling looking down. A rotating and twisting view creates tension as it centers on the joystick, laying abandoned on its side as the dust settles. Cut away to a different angle. In the background is an iMac with Google Chrome open in the background just barely in focus.]
[In walks developer Chris Serio wearing a pair of Ray-Ban sunglasses. He nudges the joystick with his boot before crouching down and removing his sunglasses to get a closer look.]
Chris: “Looks like someone really had it out for this Joystick”
Ben: “Yeap…tossed it like a salad at Denny’s. What do you think ticked them off?”
Chris: “I bet Google’s behind this somehow…”
Ben: “Google? Really? I thought their motto was to do no harm?”
Chris: “On the contratry…They’re involved in everything!”
[Chris stands up and walks over to the computer…the camera zooms in as Google Chrome comes into focus on the screen]
Chris: “You see this? Chrome…that’s not a coincidence. I want the computer’s ip address…run it through CODIS. Bag it and tag it”
[The camera moves back and zooms out as Chris pulls his sunglasses from his pocket, placing them on his face as he pauses to speak]
Chris: “This Joystick killer’s about to get…..yoked”
[Cut to opening credits as The Who’s “Won’t Get Fooled Again” plays loudly]
Ok so perhaps I’ve seen too many episodes of CSI in my time…but sometimes I must say I do feel like more of a detective than a developer.
The latest weirdness with joysticks is that on Mac only, sometimes they do not seem to work at all. In the log, you’ll see an error message stating that the device could not be opened. I’ve seen it myself before and it’s odd because typically device access is shared between processes. Imagine if your keyboard only worked in your word processor because it demanded exclusive access and none of the other applications on your computer could use it once the word processor was opened. That’d be silly right?
I started killing processes on my system one at a time until the joystick finally started working again. Killing Google Chrome is what did it. Why on earth would a web browser be touching my Joystick hardware?!
After a bit of research and a run through Chrome’s source code (isn’t open source great?), I discovered a new system in HTML5 compliant browsers like Chrome called Gamepad. Gamepad allows new HTML5 pages to access your joystick hardware! Because of the Olympics, the daily Google Doodles have been little mini games which are stealing Joystick access! So Olympics + HTML5 kills Joysticks in X-Plane….amazing.
The solution is a simple change for them. They just need to pass a different flag so that they share the device with other applications. I’ve already filed a bug and spoken with the developer and the fix will likely be in Version 22 of Chrome but for now, make sure your browsers are closed if you appear to be having intermittent Joystick issues on Mac.
Sometimes reality is stranger than fiction…
***EDIT*** I do have to say, I got an immediate response from the engineer in charge of this Chrome feature and within an hour the bug was fixed and checked in for release in future versions. I can’t ask for better support than that.
500. 1 to write the new lighting code and 499 to work out the gajillion ways that backward compatibility gets broken!
Suffice it to say, there are a number of major bugs with aircraft lighting and drawing in 10.10 beta 6. Beta 7 is now out and attempts to fix most of them, but I fear there may be at least one more round of fixing backward compatibility bugs in airplanes.
If you have an aircraft (built-in, third party, or yours) that looks good in either 10.05r1 or 9.70 and looks borked in 10.10b7, please report a bug, particularly if the panel and panel lighting is not working.
Why is debugging aircraft drawing so difficult? It’s a bit of a perfect storm.
The code supports a huge number of individual behaviors. A lot of the airplane drawing code was done incrementally, so even supporting ‘What v9 does’ means supporting the presence or absence of a large number of small features in every combination. You may or may not be using regions, may or may not be using translucency, may or may not be using interior lighting, may or may not be using the 3-d texture, may or may not be using generics, may or may not be using ATTR_lit_level, may or may not be using additive instrument lighting, may or may not be using auto-adjust levels, and I haven’t even started on the per-object check boxes and global OBJ attributes! (This list is a combination of flexibility, combining two complicated systems, panels and objects, and the “little at a time” approach which introduces a number of intermediate authoring modes into the airplane SDK.)
A number of these options are very quirky. Sometimes they have long running bugs, sometimes they’re limited by hardware, and often using two together produces weird behavior.
Often the quirks are useful. Rather than avoiding quirky weird behavior, lots of planes take advantage of it. Bugs become new features.
We didn’t do much in X-Plane 9 to flag, warn, or prepare authors for X-Plane 10. While we knew HDR was coming, X-Plane 9 never flagged or squawked about old authoring techniques, so a “works in v9” plane might work because X-Plane 9 supports lots of old weird stuff.
HDR rendering (with the deferred renderer) is fundamentally different from standard “forward” rendering (what we had in v9) and thus everything above has to be coded twice.
Ironically, the generous backward compatibility of the panel/cockpit authoring system in the past (including the ability to use all of the intermediate use cases of these features) has made backward compatibility worse now by making the problem space much more complex.
Unity For 10.10
As I have posted before, one of my goals is to make X-Plane 10.10 a stable and final authoring platform for v10 planes – that is, fix all of the rendering bugs so that if your plane looks good in v10, it won’t need any more updates or check-boxes changed. 10.05r1 did not meet this criteria because there are problems with airplane rendering in HDR that an author can’t work around – they are bugs in the sim.
As part of that process I am trying to create a single “right” path for authors to use the panel texture in an HDR compatible way. This consists of:
GLOBAL_cockpit_lit gives you the newest lighting path. When this attribute is present, lighting is the same for regions and no-region panels, the panel texture is fully lit by HDR, and transparency works as well with a panel as it does with a regular texture.*
With 10.10 the cockpit object has a full set of plane-maker check-boxes for control over shadowing, LOD, glass, lighting, etc., to make it consistent with the attached objects.
In 10.10 any attached object on an airplane can use ATTR_cockpit or ATTR_cockpit_region as long as the cockpit texture does too. (This means you can mae your panel texture interior for lighting but reuse the cockpit texture in a glass object for a HUD.)
These features provide for all of the authoring techniques I have seen and work with both HDR and non-HDR. Most legacy airplanes can be updated simply by adding GLOBAL_cockpit_lit to the cockpit object and confirming that check-boxes are correct in Plane-Maker.
Logging Problems
With this beta I modified the non-fatal error reporter to handle airplanes. What is the non-fatal error reporter? You know it as:
Error loading the scenery package:
/Custom Scenery/my_awesome_scenery/
The scenery may not look correct.
Please see the log.txt file for detailed error information.
The idea of this message is that it puts up a single user-readable warning that something has gone wrong, while providing details on every error in the log. Authors can see all of their problems in one load of the sim, and the single dialog box is annoying enough to users that authors can’t ignore the problems.
A few things have changed:
Airplanes can now participate in these dialog boxes, so we can give you one message that there are several problems with your airplane.
There is now a “quiet” version of this that logs without the annoying dialog box. This lets us put warnings in that aren’t annoying yet but may become annoying in the future.
The log output goes through the dev console, part of an effort to unify our logging efforts. You can reopen the log file without quitting or browse the dev console on screen.
I was asked a few weeks ago whether warnings in the log hurt performance, and my unsatisfying answer was “it depends on the warning.” But I can tell you this: any problem in your add-on that causes one of these “non-fatal error” dialog boxes should be fixed! We only use it when (1) there is a definite error in your file and thus it is not parsing properly or (2) you are using a very old technique in X-Plane for which a better replacement has existed for a while and the old technique is going away.
Don’t Overuse Translucency
One last note from the * above; this came up when Tom was working on the Baron, but I see it in third party airplanes too. While you can use translucency with the panel, I do not recommend it for building non-translucent elements.
Example: if you have an annuciator panel with warning lights that can flash then…
I do recommend that you build the panel in Plane-Maker using panel texture and multiple instruments layered on top of each other. With GLOBAL_cockpit_lit (or regions) you will get correct 3-d and HDR lighting on this panel, and it will color match the rest of your cockpit object perfect.y
I do not recommend building the annunciators out of clear areas in the panel and layering two polygons in the 3-d object (a back polygon for the back-plate and the panel texture for the front).
Why not overlap 3-d polygons? First, the OBJ format doesn’t provide a good way to overlap near geometry without risking Z errors. Second, and more importantly, you will not get correct lighting by using alpha and multiple layers. The annunciator panel should be affected by 3-d light including the flashlight and shadows from the sun; that won’t work unless you produce a single “baked” annunciator panel in your panel texture. Finally, any time you use alpha in HDR mode, there’s fine print and issues with the lighting, so use it when you really need alpha, not when you can get the job done with a panel texture!
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.
