I’m not sure if these will make it into X-Plane 9.30 (we’re trying to close down features, but it doesn’t do much good to hold off features that help people make airplanes) but…while I was in Italy I created a few more manipulator types.
The set of manipulators let you change the value of a dataref directly with a mouse-click – the various flavors control how the dataref is changed.
These manipulators are the natural corollary to the command manipulator, which runs a command on a click.
Why have both? Commands are good, but they don’t cover 100% of sim functionality (just like datarefs don’t cover 100% of sim functionality). By having both, it will be possible to control switches and buttons that are best accessed by a dataref change.
For the basics on commands vs. datarefs, see
here.
The generic instruments already write to both commands (via the trigger instrument) and datarefs (via the rotary instrument) – these new manipulators provide the same functionality for 3-d cockpits.
Over and over, whether it is a feature request list for X-Plane or another simulator, I see the same thing: “multi-core support” or “multi-threading” as a feature request.
Now before I continue, I must remind everyone: X-Plane is already multi-threaded and will take advantage of multi-core hardware. How much we use those cores depends on the type of scenery loaded.
The problem is that multi-threading (as a way to use multi-core hardware) is a solution technique, not a problem statement. What is threading going to be used for? If I simply program the other 7 cores of your computer to calculate PI to 223,924 digits have I met the feature request? This probably isn’t what anyone wants.
Implicit in the request for multi-core is (I speculate) a request for better frame-rate. (I did see one user who wanted multi-core to be used for a more accurate flight model. This strikes me as a poor trade-off for hardware based on my understanding of the flightmodel – we would use a lot of hardware for only a marginal accuracy improvement – but I commend the user for stating the problem and not just a possible solution.) But is multi-threading the best way to get framerate?
If I had two patches to X-Plane, one that doubled fps by using two cores and one that doubled fps by using more efficient code, which would be better? To me the obvious answer is: the code that is more efficient. It will run on any hardware (not just multi-core) and if you have multi-core hardware, we still have that second core free for some other functionality.
So to me the feature request should be something like: “higher framerate – and yes I have multi-core hardware”. Or perhaps “more visual detail at the same framerate – and yes I have multi-core hardware”.
All feature requests need to be in terms of problem statements, not possible solutions. This lets us find the set of problems that can be solved together in a coherent manner, and it lets us pick a solution that meets our engineering goals.
X-Plane’s panel system does not have true “masking” based on a bitmap. You can clip an instrument to its rectangular region, but most masks are made by overlaying another layer or instrument on top of the moving parts. Examples include the circular mask for the moving map and the outside of the artificial horizon dial.
If you are using ATTR_cockpit then what you see in the OBJ is just like what you see in the 2-d panel, and the masking problem is simple: pick a mask that matches your background. In particular, if the back of the panel is black, your mask must be black; if the back of your panel has a gradient, the mask must contain a copy of a slice of the gradient.
But there are two cases where this rule does not work the way you might expect.
Masks for 2-d Spotlights
The 2-d spotlight textures (panel-2, panel-3, etc.) have a strange property: they light the background of the panel (the “burned in layer”) per-pixel but the overlays are lit per vertex. This is a cheat to keep the frame-rate high.
Normally this is not a problem – the moving parts are small and look different enough from the background that the lighting mismatch is not visible. But if you have a mask in the 2-d panel and spot lights, it will not match!
Unfortunately there is not much you can do about this. The only thing you can do is to keep the spotlight color uniform over the entire mask region.
Masks for Cockpit Regions
When you use ATTR_cockpit_region, the lighting model for your 3-d cockpit changes: instead of drawing the panel (as you saw it in 2-d), X-Plane calculates the albedo (day-time) and emissive (“_LIT”) components of the panel separately and then combines them with real 3-d lighting.
The good news is that the spot light problem is no longer a problem. Since the spot lights are 3-d and are applied to these final “panel textures”, a mask that matches the background will blend perfectly.
But in order to mask, you need to know which part of the panel texture you are masking (albedo or emissive!). If you are masking the albedo texture (e.g. a mechanical artificial horizon), create a mask that looks just like the panel background.
But for a glass instrument, the moving parts go into the emissive layer. Your mask must be pure black! Where did I get that from? The emissive layer adds light to the object. Black is an absence of adding light. So pure black ‘erases’ any light-only elements (which include all glass EFIS instruments, etc.).
One nice thing about this strategy: you can build a custom glass instrument (with a black mask) and put it over any background. This means you can reuse your art assets no matter how they are positioned on the panel.
After almost three weeks in Europe, I am now back home!
First, I would like to thank the entire team that put together the French X-Plane Congress – it was a wonderful event – you guys did an amazing job! It was great to see so many X-Plane people in one place (including the elusive Marginal!). The French X-Plane community is a strong group and it shows.
I would also like to thank Cris for setting up an informal Italian X-Plane get-together (complete with the Zurich delegation 🙂 for our last night. We didn’t get much sleep, but it was great to see so many people again before we flew back home.
At this point my in-box looks like someone dropped a bomb on it…it’ll take a while to dig everything out. The first priority of business is X-Plane 930 – we’ll do a series of betas over the next week or two that will hopefully put the release to bed. Once 930 is done, I can probably beta WED 1.1 and get back to work on scenery.
Posted in News
by
Ben Supnik |
I’ve had a little bit of time to look at X-Plane 930 performance. The data isn’t 100% conclusive yet, but one performance issue sticks out like a sore thumb: per-pixel lighting hurts fps.
Now, part of this is that the per-pixel lighting shaders are not yet optimized (and perhaps are not terribly well written). I need to take some time to see if I can get some more performance out of them.
But…per-pixel lighting isn’t free – when per-pixel lighting is on, the video card is simply doing a lot more work than it used to. Consider: a typical X-Plane scene might have 250,000 vertices on screen at once. At a minimum, you have at least 750,000 pixels on screen*. Make your window bigger and that number goes up – fast! Turn on 16x FSAA and watch the pixel count get even larger. So the number of lighting calculations done by your graphics card are at least 3x higher with per-pixel lighting and potentially 50x higher. Even if your graphics card has a lot of power, that’s going to cost a bit.
So one option I am considering is making per-pixel lighting a rendering option. This would allow users who want 922-level fps to simply turn it off. In my tests so far, turning off per-pixel lighting gets fps to within a few percent of 922.
(The only reason to have shaders on but per-pixel lighting off would be to have a cheap version of the reflective water. In the long term I want to limit the number of a la carte rendering settings, but for now it seems reasonable to support v9.00 base configurations through the entire version run.)
* In practice, not every pixel on screen requires full shading, e.g. the sky does not require complex shading. But some parts of the screen may be shaded multiple times. This is called “overdraw”. For example, with a runway we pay for our shaders twice – first with the ground underneath the runway, then with the runway itself.
Today Lori and I head to France – we will do a bit of site-seeing before the conference, and then Austin and I will go to Italy to work with Sergio.
So first, my email connectivity will be dubious at best for almost an entire month – if you send me a bug report and hear nothing for several weeks, you’re just going to have to wait…our internet connection in Italy doesn’t really deserve the name “internet connection”, and often doesn’t work at all. (If you need tech support, contact info at x-plane dot com – you should not be trying to reach me for tech support in the first place!)
I fixed a number of beta bugs this week; Austin will probably cut beta 11 before the conference, and then there will be a pause while we’re off the net. Once we get back, hopefully we can kill 930 off. (Most of the crash reports I’ve received turn out to be a single bug in the OBJ-handling code, fixed in beta 11, so hopefully the next beta will be stable.)
Now here is my request to everyone at the conference: please … go easy on me if I cannot remember who you are.
The tricky thing about a conference like this is that I mostly know people in the X-Plane community by an email address; if I see a face it is only once every few years. So if I jumble who you are, what you look like, and what you do with X-Plane, I apologize in advance. It is not a reflection on the merits of what you do, but rather an indication of the disorganized state of my (soon-to-be-jet-lagged) brain.
Posted in News
by
Ben Supnik |
I have received a number of emails bringing up crashes and performance problems in the X-Plane 930 betas – some of the writers are concerned that 930 might be a lame patch, going final with crashes and lousy performance.
To assuage this concern, let me make a few comments on where we are in the beta process, the likely future schedule, and the problems themselves.
The Schedule
X-Plane 930 has been an absurdly long beta. Going into the beta I had the mindset that we should take the beta slowly to have time to discover driver bugs on a wide variety of hardware – why rush and miss something?
I think we took this too far. To run a “slow” beta we have run other development simultaneous to the beta, but that in turn has stretched the beta to epic lengths.
We are starting to try to clamp down and close out the beta now, but it is going to get interrupted again. Austin and I will be traveling to attend the
X-Plane conference in France, and from there we will spend two weeks working with Sergio in Italy. Given how rarely we go to Europe, we cannot pass up the opportunity to work with Sergio in person – we have a few problems in the sim where getting the three of us in one room is the best course of action.
Unfortunately our internet connectivity during the trip will be limited, and we can only bring some of our equipment, so closing out the beta while on the road is really not an option. Thus there will be yet another beta delay. Hopefully when we return, we can close the beta out for good.
Performance Problems
I have seen a number of emails regarding framerate with 930. A few notes on framerate and betas:
I try to save framerate for last in a beta. Most performance problems have two possible causes.
- We communicate with the video card driver in a way that is fast on our systems but astoundingly slow on other systems. We discover this from slow performance in a particular piece of the code on other hardware.
- The new beta does something new that is more expensive than what the old build did, and users have not figured out how to (or do not have a way to) turn this more expensive option off.
The solution to case 1 is to use another driver call; the solution to case 2 is to make sure the rendering options provide a way to turn the feature off. (We simply cannot guarantee that a new, nicer looking feature run without a fps penalty – we can only give you a choice between better visuals and faster fps.)
Either way, framerate work tends to be the last thing on my beta list for this reason: other bug fixes may cause framerate problems, typically in category 1 – that is, a bug fixes makes use of a new driver call that we find out has hurt performance. Thus I try to do all performance fixes at the end of beta when we won’t be adding new code.
This means that in practice, I have spent nearly zero time looking at performance. I am just starting that process this week, so it will be a little bit before I find problems.
Unfortunately often performance problems manifest only in the hardware I do not own – despite having a pile of computers in my office (a pile that seems to grow deeper and less manageable every year) there are just a ton of systems out there. So a lot of the performance bugs will get fixed by users trying experiments and reporting back to me – a slow process despite some of the really great efforts by our users.
Crashes
Crashes sometimes are manifestations of gross code defects, but often they fall into the category of driver problems too. I will be working to piece together the puzzle of strange behavior over the next few weeks; usually the solution is to not do some action that we thought was legal but fails in some hardware cases.
Don’t Panic
As always, my final message regarding the beta is: don’t panic. When it gets quiet over the next few weeks, it is because of travel, and even once Austin and I are back in the office, it will be slightly slow going to piece together problems on hardware other than our own.
This year Austin, Sergio and I will be attending the X-Plane 09 Conference this year, near Paris. I am excited by the turn-out – a number of people in the X-Plane community who all do great work will be there, in some cases meeting each other in person for the first time. And there will be cheese!
The conference is officially French, and I must admit, I don’t speak a word of the stuff. Fortunately, my beautiful and very patient wife will be there, and she speaks French quite well. So I have asked her to translate the rest of this blog post – a greeting to my French readers.
Bonjour. Ecoutez: Ben croit que je traduis le reste de son article sur ce blog, mais il ne parle pas du tout le français. Lorsqu’on était à Cannes, il a essayé d’apprendre à dire “Le chat est sur la chaise” – ce qui lui a fallu deux semaines! Donc il n’a aucune idée de ce que je suis en train d’écrire, et il ne saura pas non plus si traduis sa présentation correctement ou non.
Lorsqu’il commence sa présentation, je vous expliquerai toutes ses mauvaises habitudes. Est-ce que vous l’avez vu travailler? C’est tellement bizarre! D’habitude il ne porte pas de pantalon. Il s’asseoit devant l’ordinateur en buvant du café et en maudissant les “DSFs” – qu’est-ce que c’est? Je lui ai dit qu’il faut porter un pantalon à la conférence.
I am a very lucky man! I will see you all there.
Posted in News
by
Ben Supnik |
It seemed like opposite-day at Laminar Research…Austin saying that an error shouldn’t quit the sim and me saying the error was never okay, ever. Well, I relented: with X-Plane 930 beta 8, if your scenery pack is missing objects, you can still fly. Instead you get a single error message like this:
That is the “non-fatal” error dialog box – you will see it only once for each scenery pack with a problem for each time you run the sim. It means that at least one thing is wrong with your scenery pack, but you need to look at Log.txt to see what’s wrong. For example, you might see this in the Log.txt file:
Failed to find resource 'KSBD_example.obj' at 'Custom
Scenery/KSBD Demo Area/KSBD_example.obj'
Failed to find resource 'KSBD_example.obj' at 'Custom
Scenery/KSBD Demo Area/custom objects/KSBD_example.obj'
Failed to find resource 'KSBD_example.obj' at
'Resources/objects/KSBD_example.obj'
Failed to find resource 'KSBD_example.obj'
at 'Resources/KSBD_example.obj'
***Error with scenery file "Custom Scenery/KSBD
Demo Area/Earth nav data/+30-120/+34-118.dsf"
(/Volumes/RAID/code/design/HLutils/Files/io_dsf.cpp: 503.)
Unable to locate object: KSBD_example.obj
In this case, X-Plane couldn’t find the object KSBD_example.obj – the sim is also listing all of the places it looked. Note that only the first location is a good location – the other 3 are legacy search paths that date all the way back to version 6. It is likely that in the next major version we will trim down our search paths significantly.
A few comments on this whole situation:
-
Authors, do not ignore error messages like the dialog box above – every one of them indicates a condition serious enough that we think you should fix it. Non-fatal errors like these may crash future versions of the sim, or your content may simply stop working.
If you file a bug against a future version of the sim saying your scenery pack used to work and is now broken, and we find that the old scenery pack had errors, we’re not going to fix the bug – we’re going to laugh maniacally and dance around you in a circle while singing “told you so”.
Okay – we’re very unlikely to do that – but if you have errors in your scenery pack, you’re doing something wrong and you need to fix it – treatment of illegal data is not stable between versions of the sim!!
-
I was never very sympathetic to this whole bug report because X-Plane has never accepted a DSF with missing objects – this has been a fatal* error since X-Plane 8.0 when DSF was introduced. So I simply don’t understand why there are any scenery packs floating around with objects missing. Why would you place an object if you don’t want to see it? The whole issue strikes me as a total failure to check quality by authors, since even running your pack once would reveal this kind of problem every time!
-
The motivation to make missing objects illegal comes from version 7 and ENVs. When looking at ENV scenery, I found that a large number of ENV scenery packs were missing at least some of their objects (an error that was silently ignored in ENV). It seemed like we were hiding an error and the result was authors not noticing simple mistakes that might “lose” an object (e.g. renaming an OBJ file).
Hence the “harsh” policy for DSFs – it was in response to a real problem with existing scenery!
- You don’t need to have missing objects just because you use library objects from another scenery pack (that might not be around). Use the EXPORT_BACKUP command in your library and a single blank OBJ as a place-holder for the objects you want from a library that might be missing. OpenSceneryX provides a stub library that authors can include so that their scenery will load without errors even if the OpenSceneryX library is not installed.
Anyway, Austin was right to make the error non-fatal. Besides being a little bit nicer for users who don’t know (or care) why their pack is gone) it lets authors get a list of all missing objects with only one run of the program.
* Fatal? In computer terms, a fatal error is one that makes the program quit, e.g. the error is fatal because it kills the program.
With X-Plane 930 beta 8, we finally integrated the latest version of Max’s Cessna 172 SP. Grab the new beta and try it – he’s added a number of new features that demonstrate some of the newer X-Plane 9 airplane features.
- Real 3-d lighting in the 3-d cockpit. Note how the map light tends to illuminate only some of the cockpit as it fades out.
- 2-d back-lighting on all of the major steam gauges.
- A bunch of parts can now be dragged in 3-d, including the door handles. This is done via manipulators.
- Walls! In 3-d cockpit viewer mode you won’t be able to leave the airplane until you actually open the doors. The cockpit viewpoint is constrained.
- The model has the glass parts separated out for correct shadowing, and the glass works correctly from all viewpoints.
- Panel uses cockpit regions for accurate lighting.
The cirrus jet has been similarly updated. I plan to use the Cessna for a series of tutorials showing how to use these recent X-Plane features.
