X-Plane 920 will have a pile of new panel features…this video shows the new “spot light” system. Basically you can define up to 3 gray-scale masks that define lit regions on your panel. 3 separate rheostats control the lighting levels independently.
http://www.youtube.com/get_player
I was excited when Blogger got its own video facility – saves me the hassle of keeping YouTube account active. Unfortunately the video quality is, well, “web-ish” at best. What you’re supposed to see is independent control of instrument lighting, panel and dash lighting, and flood lighting.
The performance hit is pretty tame:
- The system works by recomputing the panel texture from sources when lighting or panel brightness conditions change. That doesn’t happen that often, so most of the time, the system costs nothing.
- Panel layers are RLE compressed in RAM when not in use, so they aren’t that big.
- If you have more than one core, the lighting recompute happens on the second core, which makes it virtually unnoticeable.
So the only case you’d notice this is if you crank the panel light rheostat really fast or fast-foward time (from light to dark) on a single-core machine.
I have
blogged about correct airport layouts before, but let me bring the point up again, because it is so important:
- You must create structurally correct layouts (that is, vertices connecting to vertices, not lines) in order to get good rendering in X-Plane. Just because the preview looks okay in WED doesn’t mean your layout is correctly formed!
I wrote some documentation on the scenery site that describes the problems in more detail, with pictures.
(I’ve been trying to create more permanent documentation – it is tempting to simply blog the issues because it’s so easy to throw a blog post up, but after 110 blog posts in 2007, the scenery site is still very thin on the documentation front.)
Do Not Add Vertices To Make Smoother Curves
I really can’t stress this enough: please do not go adding extra vertices in your layout to make bezier curves look smoother in X-Plane. Why is this such a bad idea? Let me count the ways!
- X-Plane will fight you all the way! X-Plane adds vertices to curves (to make them smoother) when it detects large errors. If you have a lot of small curves, the errors are inherently smaller and X-Plane will add fewer points. So the first vertices you add to your curve do almost nothing. You have to add a huge number of vertices to get a marginal improvement in your curve. In the meantime…
- X-Plane will provide variable-quality curve rendering in the future! Curve detail should be a user-controlled setting. X-Plane has to run on a wide range of hardware; any time we can let the user pick rendering quality, this is a win, because it helps bridge the gap between the user who just bought a brand new Core 2 Extreme system with GeForce 9800 and the user trying to keep X-Plane 9 running on his G4 laptop which can’t be upgraded. When you add vertices, you take the decision about rendering quality out of the hands of the user, and force high quality on a user who may not be able to handle it. Adding vertices forces a decision of lower framerate on some users.
- Adding vertices bloats the size of apt.dat. This is not a huge factor for custom scenery, but is a factor for the default apt.dat. Robin received a big pile of new airport layouts, and that’s great. But one risk is that the total size of user submitted data could get out of control. For new layouts made with WED, vertices represent a big chunk of the data. If you are increasing your vertices by a factor of 5x or 6x to improve tessolation, you are bloating the apt.dat file.
- Manually adding vertices to smooth curves lowers the level of abstraction in the apt.dat file. Any time we can have a high level abstract representation of scenery, X-Plane has the freedom to improve rendering in the future. If your layout is made up of a large number of small curves (instead of a small number of large curves), X-Plane cannot tell that those small pieces make up some larger structure; in the future it may not be able to render those layouts as nicely as ones that are made with fewer control points.
In summary, please use the smallest number of vertices to create your layouts. (But always add vertices to ensure that your T junctions are correct!)
I found a disturbing text file on a user’s computer…the user had a P-IV 2.8 ghz CPU and a GeForce 8800GTX. An excerpt:
Day 458 of my captivity. Life continues to be an immense, boring string of idle pauses, punctuated with drawing tasks way below my dignity. I am a GeForce 8 – why doesn’t anyone here respect that? And yet when the user is playing “X-Plane” I spend long milliseconds with nothing to do while that infernal Pentium IV thinks carefully about what triangle I should draw next. Life is so dull. That Pentium IV must be the dumbest chip to come out of the fab plant – surely he is the runt of his wafer. Sometimes I become so despondent that I consider turning my fan off and cooking myself to death to end my misery. Perhaps I will intentionally blue screen the operating system…
Okay, so I made that up. But I’m sure that if you put a GeForce 8 into a P-4 system, that’s about what the card would be thinking – it would be bored silly. Even the fastest Pentium 4s can’t feed data rendering instructions to a GeForce 8 fast enough to utilize the hardware.
And in this sense, hardware can be like pushing on a string. Even if putting worse hardware in your machine would lower fps, putting better hardware in it may not improve fps. If you have a P-IV and a Geforce 8, putting a Geforce 2 MX in its place will lower fps, but upgrading to a GeForce 9800 won’t – it will just leave your graphics card even more bored and angry than it was before.
This is because the slowest component in the graphics pipeline determines fps. Improving the speed of the other components just leaves them idle more of the time.
Why RAM Isn’t like CPU.
When your system is limited by CPU, the change in performance is somewhat linear – get a 20% faster CPU and you get 20% more FPS.
RAM isn’t like that…usually you either have more RAM than you need (and life is good) or you have too little, and your framerates is so bad you want to pull your hair out. Why is that?
Well, the difference between RAM and CPU lies in how we use the resource. If the sim needs more CPU than the computer has, the CPU plows through the work – it just takes longer.
But what happens when you run out of RAM? The backup for RAM is your hard disk, which isn’t even the same substance. A RAM chip might be able to come up with some data for the CPU in 4 nanoseconds; a hard drive might be able to seek to data in 4 ms. That would be a diference of 1,000,000! (By comparison, the difference between flying across the country and walking might only be 150x.)
In other words, when we run out of RAM, we can’t degrade gracefully, we degrade catastrophically.
(It gets worse: when we run out of virtual memory, we don’t have anything to fall back on – we’re just dead!)
Interestingly, it used to be that way for VRAM (back in the days of X-Plane 6); if we had to substitute system RAM for VRAM, framerate died. These days, however, the graphics bus is so much faster that that substitution is almost tolerable – thus you can start to run out of VRAM and not have a slide-show.
We Can’t Use All of Your RAM
A user emailed us to inquire why X-Plane wasn’t using more of his RAM – he had a machine with 8 GB running a 64-bit OS. X-Plane could have had 3 GB memory but was only using a fraction of that.)
The answer is partly in the nature of RAM – because RAM fails catatrophicaly, users are likely to set X-Plane to never get near the edge of running out of memory. Our engine is designed to simply minimize memory usage (since the penalty for running out of virtual memory is fatal) rather than try to gain incremental benefit from incremental RAM. (There are scenery packs that you need a lot of RAM for, but usually you can either run them or you can’t.)
For most users, RAM is like pushing on a string – if you have enough memory that you can run without paging, adding more won’t help. If you have 4 GB you really don’t need more memory. If you have 2 GB, you probably don’t need memory unless you’re running with almost everthing else maxed out, due to a really fast CPU and GPU.
The moral of the story is: just because I dismiss an idea by email doesn’t mean it won’t get coded. In particular, one user requested a generic instrument that could display text from datarefs. While my initial reaction was “no way”, I ended up changing my mind. The text instrument will be available in 920 – it displays a string as long as the input dataref is of type “data bytes”. The first intended use is to let you build an FMC interface out of generic instruments – we’ll make datarefs that provide the display strings.
My initial negative reaction was due to the nature of the request: I get a lot of requests for “can you implement feature X in subsystem Y?” One of the biggest questions about any feature is: where does it go within the maze of SDKs that X-Plane supports? So if you specifically want it in a particular place, the answer is more likely to be no.
In particular, most people want feature X in the subsystem they are already using. So 3-d modelers want a feature in the OBJ format, airplane editors want an ACF feature, panel creators want a new instrument, and off we go.
I can’t put a feature into the sim without considering compatibility, and the cost of compatibility goes way up if a feature is in the wrong place in the code.
Put It In a Plugin
A lot of the time my response is “a plugin can do that.” Now I know that that’s a blow-off answer; plugins make all things possible, but they don’t make them easy. Not everyone is a programmer. At the same time, plugins often anticipate sim features by years: consider that the first planes to demonstrate key frames, 3-d cockpits, and per-vertex normals used plugins, with the sim developing the feature later.
My decision to include a text instrument is based on the idea that it makes sense to partition which “SDK” a feature goes with based on the nature of the activity. As of this writing, custom systems modeling has to be done in a plugin – no other interface provides this. But panels can be built almost entirely using the built-in panel editor; with 920 generic instruments provide a huge amount of flexibility.
So the purpose of the text instrument is to keep things this way – imagine that an artist is building a panel (using generic instruments) around the datarefs written by a programmer (using a plugin to do systems modeling). Without the text instrument, the programmer has to write some graphics code (for the first time) and there’s one part of the panel the artist can’t manipulate. This is a case where since the artist could already do 95% of the job, it makes sense to expand generic instruments so they can do it all.
(That’s not entirely true – there will always be custom displays so complex that they can only be programmed. But the 920 generic instruments make most things straight forward.)
As a final note to the rant: we are not going to provide any systems modeling capability as part of generic instruments. Generic instruments are how you visualize the simulation, not how you configure it.
To give a trivial example of why I don’t want systems modeling code in the generic instruments: it would be unfortunate if the pressurization model changed because the 2-d panel scrolled such that the pressurization instruments were no longer on screen!
“Warning: padding is not integral” is a warning message that the airport sign code renderer can spit out when your airport is loaded. Unlike all of the other warnings that you might see, this one doesn’t actually tell you that there’s a problem with your sign. It’s actually telling you that there’s a problem with my code, and today I finally fixed it. (The fix will ship in X-Plane 920, not X-Plane 902.)
The problem is that the official FAA sizes (0.76 meters, for example) suffer from tiny rounding errors when put through the sign creation process. (Use 0.33 as a proxy for 1/3rd. Divide something in thirds and add it up. You lose a tiny sliver, right?) That warning message was the renderer noticing that it was being asked to fill in a really tiny sub-pixel area (which it then did, hence you can’t see a problem from your airplane).
With 920, the sign heights are changed ever so subtly (by less than 0.1%!) so that they don’t cause rounding errors. This is the equivalent of calling the sign 0.33 meters instead of 1/3rd meter.
If this all seems like decimal point hell, well, welcome to my world!
Bottom line: you can ignore this warning, it’ll go away in 920.
This is not terribly important (because X-Plane always does “the right thing”), but…what’s the difference between a trapezoid and a square that’s been tipped over? Well, consider the checkerboard below.
Note that in the “no-perspective” space the height of each row is the same; in the perspective case the bottom rows (which appear farther away) are less tall than the top ones. From a 3-d perspective, the middel image is the equivalent of stretching the square into a trapezoid; the right image is the equivalent of tipping it over a bit.
I mention this because PlaneMaker 920 will allow you to drag the corners of generic instruments to create perspective effects. When you do this, the positioning of the moving aprts follows the “perspective” pattern you see on the right. This means that if you make a trapezoid-shaped needle, the center pivot point of the needle will not be at the centroid of the trapezoid!
(Based on 3-d perspective it should not be, because the wide end of the trapezoid is “closer” – thus the center must be closer to the small side.)
There is a bug in X-Plane 901 where, when you pick a “forward no panel view” (forward with HUD, forward no HUD) you see the 3-d cockpit in the Cirrus Jet. The forward no panel view is typically used to make the center display for a multi-sim setup where one computer drives each “window” of the cockpit, or three computers make a wrap-around set of screens.
(You would actually use forward-no-HUD for all of these views, with the view offset rendering controls creating the view-angle effect.)
It turns out that this bug reveals some pretty weird sim behavior; the rest of this post explains what’s going on and how it affects authors.
View Settings – What They Do
These fifteen check boxes can be found in the PlaneMaker “viewpoint” settings screen, under the “view” tab.
Each row controls the drawing of some part of the aircraft: the top row controls the drawing of the 3-d cockpit object, the middle row the inside surface of all aircraft parts, and the bottom row the outside surface. Since most aircraft parts have no holes in them (unless you “draw” them with alpha) usually it’s the exteriors you need drawn. Back in the old days, some authors wanted to have the interiors be drawn, but with X-Plane 8 and 9 authors usually create attached objects to draw the interior of the airplane. So that middle row is basically legacy.
Now the columns represent the different types of views, and this is where it gets confusing, because the labels are not so obvious.
- The first column applies to the forward 2-d panel view (‘w’ view).
- The second column applies to the 3-d cockpit view (‘ctrl-o’ view).
- The third column applies to the forward no-panel view (shift-w view).
- The fourth column applies to the side 2-d panel views (q and e views).
- The fifth column applies to external views (‘a’ view, etc.).
Here are some notes by number:
- If you check this, the 3-d cockpit will be used in the 2-d panel forward view. This is handy if you only want to make a 3-d cockpit. The F-22 that ships with X-Plane does this – the 2-d panel is really the 3-d cockpit viewed head-on.
- You always want to check this, otherwise the 3-d cockpit will have no 3-d cockpit object.
- You never want to check this, because you don’t want to see the 3-d cockpit in the forward no panel views! But see below.
- You can check this to use the 3-d cockpit object instead of 2-d side panels. The default P180 does this.
- Check this to draw the 3-d cockpit object in external views. You probably want this if it’s possible to see in through the windows of your plane, otherwise the cockpit will be empty!
- You basically never want any of buttons 6-10…
- They show the interior of the aircraft geometry, so you’d only want this to see the fuselage from the inside for example.
- But the inside of your fuselage will still have the external fuselage texture, which is ugly.
- That’s why most authors use objects to model the aircraft interior.
- So in summary, don’t check 6-10…use attached objects to model the inside of your airplane, as well as the cockpit object.
- Check this to see your prop disc in the 2-d panel.
- Check this to see your prop disc and wings in the 3-d panel as you look around.
- You probably don’t want to check this unless you want to see a prop disc in the forward no-panel view. See below.
- Check this to see you wings and prop disc from the 2-d side views.
- You always want to check this – otherwise you won’t see your plane from the outside!
That was a lot of detail, but hopefully it will act as a cheat-sheet for setting these up. In X-Plane 920, the user interface has been relabeled – those 15 comments are now in the mouse-over help.
How 900 Works
X-Plane 900 and earlier has two very strange quirks:
- It ignores all of the “forward-no-panel” check-boxes and simply never draws anything in this view.
- It defaults these check boxes to checked when you make a new aircraft.
These are unfortunate behaviors when taken together – it means a lot of aircraft have their forward-no-panel view flags set to true.
How 901 Works
The bug in 901 (and 902b2) is that it honors all view flags – even the forward-no-panel ones. So for the first time we can see that 3-d cockpit that the Cirrus Jet has been asking to have drawn.
How 902 Will Work
The short-term fix for 902b3 (or 902r1) will be to act like 900 – ignoring the forward-no-panel flags so planes just work. This is a quick-fix because 902 is just a localization patch.
How 920 Will Work
920 will feature a real solution. First, 920 will revise the .acf file version number. This is something we do fairly often – the version number was revised 5 times during the v8 run. Revising the version number does not change backward compatibility; 920 will open all of the aircraft that 902 does. What it does mean is that aircraft created for 920 will not open in 902. (This is necessary – a number of 920 features, like key-framed generic instruments, simply don’t exist in 902.)
This versioning gives us a hook to fix the forward-no-panel view for real:
- When an older plane is opened in 920, the forward-no-panel check boxes are cleared.
- 920 will honor those check boxes.
Thus all old planes will show nothing in the forward-no-panel view (that is the expected 900 behavior) because the check-boxes are cleared on load. But authors will have the option to check the forward-no-panel options and resave as a 920 aircraft, and thus choose to have a prop disc in the forward view, for example.
I commissioned
PropsMan to make me a test bed for some of the new 9.20 airplane features. Clearly he has never worked in a furniture store — this is what he sent me!
In his defense, it’s very comfy, flies surprisingly well, and is a great comprehensive test of a huge pile of advanced aircraft features. Yes, you can close and open the laptop with the mouse in the 3-d cockpit.
(One of the new features in 920 is “
no-op manipulators” – that is, the ability to make 3-d geometry “eat” clicks before they get to the panel, without having to use panel texture as the consuming surface. So when the laptop is closed, you cannot click on the buttons that are exposed when it is open.)
My real question is: how did he know about Laminar’s new secret test vehicle?
I am reading Predictably Irrational, by Dan Ariely. It’s a great read – definitely recommended – describing the consistent irrational biases that frequent human decision making.
The first chapter discusses our tendency to make relative, rather than absolute comparisons. When deciding whether a product is a good value, we will look at the pricing of similar models, rather than the actual relationship between the product and the money spent. (The implication being that a company can make a product seem cheap without changing its price by adding a second, more expensive but similar “decoy” product. Poof! The cheaper product is now a good deal.)
This behavioral tendency explains user reaction to the rendering settings, a subject that makes me irrational on a regular basis. 🙂
Time to Change the Settings
The rendering settings will let you select a range of sim detail between some minimum and maximum value. These values are based on the software, not hardware – because we don’t actually know how much load any given hardware can support (and with the interaction between settings, finding such a cap is basically impossible). We can only give you a range of choices and let you pick ones that work well.
When a new version of the sim comes out, we sometimes have to recalibrate the settings. If the minimum features the sim can support increase, the minimum setting will be mapped to a new, more expensive behavior. And if the maximum detail the sim can present has increased, the maximum setting will be similarly remapped. We don’t have much choice – if we need more “range” on the slider we have to recalibrate it.
I Can’t Max Them Out
Here’s where human behavior comes in. Humans make decisions based on the relative comparison of easily compared things. Given properties that are harder to measure and easier to measure, we’ll pick the easier one. Given a choice of a trip to Rome, a trip to Rome with free breakfast, and a trip to Paris, we’ll pick Rome with the free breakfast, opting for the easy to measure relative value. (Is the difference between a trip to Paris and Rome really less than the value of a breakfast? Probably not, but it’s a lot harder to evaluate.)
So when we recalibrate the settings, we inevitably here this complaint:
“I used to be able to set the sliders to the maximum setting and now I can’t.”
Previously I would have said “Why the hell do you care?!?!” — if the new slider’s 50% position looks the same as the old slider’s 100% position, why not just set it to 50% and go home happy.
But of course that’s not how we think – the immediately comparable is of immediate concern. Ironically we could make the sim less useful but more pleasing by limiting the maximum range of the sliders. Now more users could feel the joy of having everything “set on max” even if the ultimate utility of the sim is reduced.
This One Goes To 11
I’m not sure there’s a way around this. The best suggestion I’ve heard so far is that if we could attach some kind of units to the settings, then at least there would be a quantitative indication that the user isn’t losing some perceived value. But I suspect that even this misses the point; it doesn’t matter that you’re still getting 500 trees per square km – what matters is that you are getting the most you possibly can! (Perhaps this psychology also explains why people like to overclock.)
Austin tried to fight the psychology of “maximum sliders” by naming all of our settings absurd things. Ever wonder why “default” is the lowest object setting, and we almost immediately jump into “extreme”, “too many”, “insane”, etc.? He was trying to fight a losing battle against relative expectations. The natural human behavior is to pick some relative position for calibration, and based on that, every user who has to put objects below the center setting is going to be unhappy about having to use “lower than average” settings. Austin’s naming convention may be silly, but it does actually do a little bit to fight this.
Food for thought: how does having multiple levels of reflections change user expectations?
X-Plane 902 has an instrument limit of 400 instruments for the 2-d panel and 391 instruments for the 3-d panel. 920 will remove these limits, allowing you to build very complex panels via generic instruments.
(An altitude indicator might be built out of 3 or 4 generic instruments, so 400 instruments is a lot for pre-built but not for generic-instrument-based panels.)
The
Manipulator RFC has been rewritten…the new one proposal is less complex.
There are a lot of other panel and airplane-related changes coming in 920 too…
