X-Plane 8.40b2 introduces the ability to attach multiple objects to the aircraft. This is a very powerful new feature.
Currently these objects are not part of th physics model. This may change during the beta, or not. Please do not attempt to do real work based on the beta - an X-Plane beta is a test version of the sim and may change radically due to bugs we discover. Until X-Plane is final please try features and report bugs, but do not assume the features will continue to work the same way.
Friday, February 24, 2006
Wednesday, February 15, 2006
Cockpit Lighting Weirdness
A few authors have asked me why the lighting looks different for the parts of a 3-d cockpit that use the panel. Here's what's going on:
The 2-d panel has 3-part lighting: the base background is lit by the ambient light levels with no regard to lighting angles. (Since the panel is 2-d we're not really in a position to light different parts of the panel differentially.) The panel is then additionally lit by the cockpit flood lighting and any instrument gauges are further lit by the instrument brightness, for example an EFIS.
The 3-d panel is then built by taking an image of the entire 2-d panel. Here's where things get tricky. The image of the 2-d panel has already been darkened by the ambient lighting levels and brightened by the flood lights.
If we were then to apply directional 3-d lighting (the way we do for normal lighting) we would further dim the panel (which would make it too dark) and we would dim the EFIS and other instruments.
But since we don't apply directional lighting, the panel texture does not match teh surrounding non-panel geometry in a 3-d cockpit.
There are a few possible things we can do about this:
1. We can leave things the way they are and require 3-d panels to carefully use the clickable parts only for small areas to minimize the visual impact of the lighting effects.
2. We can build the 3-d panel separately out of multiple textures. This would allow us to do truly correct 3-d lighting, but would have some pretty big performance implications. The 2-d panel would have to be rendered multiple times, and the total VRAM requirements would increase by several megabytes. Since the panel is never compressed or resolution-reduced, VRAM is a serious consideration.
3. We could disable all 3-d lighting for the 3-d cockpit. This would cause all geometry to match, but give the 3-d cockpit a flat look. Authors would have to build their 3-d lighting into their texture.
None of these options is ideal.
The 2-d panel has 3-part lighting: the base background is lit by the ambient light levels with no regard to lighting angles. (Since the panel is 2-d we're not really in a position to light different parts of the panel differentially.) The panel is then additionally lit by the cockpit flood lighting and any instrument gauges are further lit by the instrument brightness, for example an EFIS.
The 3-d panel is then built by taking an image of the entire 2-d panel. Here's where things get tricky. The image of the 2-d panel has already been darkened by the ambient lighting levels and brightened by the flood lights.
If we were then to apply directional 3-d lighting (the way we do for normal lighting) we would further dim the panel (which would make it too dark) and we would dim the EFIS and other instruments.
But since we don't apply directional lighting, the panel texture does not match teh surrounding non-panel geometry in a 3-d cockpit.
There are a few possible things we can do about this:
1. We can leave things the way they are and require 3-d panels to carefully use the clickable parts only for small areas to minimize the visual impact of the lighting effects.
2. We can build the 3-d panel separately out of multiple textures. This would allow us to do truly correct 3-d lighting, but would have some pretty big performance implications. The 2-d panel would have to be rendered multiple times, and the total VRAM requirements would increase by several megabytes. Since the panel is never compressed or resolution-reduced, VRAM is a serious consideration.
3. We could disable all 3-d lighting for the 3-d cockpit. This would cause all geometry to match, but give the 3-d cockpit a flat look. Authors would have to build their 3-d lighting into their texture.
None of these options is ideal.
Tuesday, February 14, 2006
But you said that was impossible!
There have been a few cases where we've dismissed a feature request as "impossible" - only to then implement it later. There are a few reasons why this happens:
- Sometimes we're just wrong...we didn't understand an algorithm or know of a technology. Later research gives us a clue.
- Sometimes the underlying technology we use changes, either OpenGL and the operating system. (The joystick bundle was totally necessary for X-Plane through 832 since it was a CFM application - 840 is Mach-O, allowing us to run bundleless for the first time.)
- Sometimes we have to make changes in our own code. A feature that is near impossible in one version could be one line of code in the next. This is because so much of our features depend on underlying systems. We spend a lot of our time working on the underlying systems to make multiple features possible at once.
Sunday, February 12, 2006
Emailus Overloadus
It's winter and I seem to have caught another case of Emailus Overloadus, also known as a clogged in-box. If you emailed me in 2005 and haven't heard back, please ping me again. If you've emailed me in the last six weeks, I apologize for the extended delays; I am trying to get to everyone in the next week or so. Sadly email seems to come in faster than I can answer it.
Friday, February 03, 2006
Fast Framerate with Old Scenery
I was investigating Anacortes, WA with version 7, 8 US and 8 global scenery this morning and had a (probably obvious thought): if your framerate is inadequate with the new global scenery, use the old scenery!
What's important to understand is: the amount of work to be done is defined by the scenery, but the capacity of the sim to do that work is defined by your hardware and the version of the sim! In particular, 835 is definitely faster than 820, which was faster than 800, which is faster than X-Plane 7. So you can use X-Plane 835 with old scenery and get a much higher framerate.
In the Anacortes area I'm seeing framerates in the 60s with global scenery, 90s with the US DSFs, and 120s with V7 scenery. In a direct comparison with all settings controlled, X-Plane 7.63 runs this airport at 52 fps, while X-Plane 8.35 runs the same scenery at 110 fps.
There are two things going on here: in newer versions of the sim we can use newer, more efficient techniques to talk to the card. These techniques are invented by the graphics card vendors to allow applications to take advantage of the ever-growing power of graphics cards. So a new X-Plane has an advantage over an old one in the way it utilizes modern hardware - hence the framerate improvements.
We are also "spending" that performance dividend to provide more realism. Here you can compare the look and framerate of the v7 ENV (top) vs the v8 DSF (bottom). We are utilizing higher performance to make scenery more realistic, but if you'd rather have the framerate just load up the old scenery. It still works, and it's very fast.
What's important to understand is: the amount of work to be done is defined by the scenery, but the capacity of the sim to do that work is defined by your hardware and the version of the sim! In particular, 835 is definitely faster than 820, which was faster than 800, which is faster than X-Plane 7. So you can use X-Plane 835 with old scenery and get a much higher framerate.In the Anacortes area I'm seeing framerates in the 60s with global scenery, 90s with the US DSFs, and 120s with V7 scenery. In a direct comparison with all settings controlled, X-Plane 7.63 runs this airport at 52 fps, while X-Plane 8.35 runs the same scenery at 110 fps.
There are two things going on here: in newer versions of the sim we can use newer, more efficient techniques to talk to the card. These techniques are invented by the graphics card vendors to allow applications to take advantage of the ever-growing power of graphics cards. So a new X-Plane has an advantage over an old one in the way it utilizes modern hardware - hence the framerate improvements.We are also "spending" that performance dividend to provide more realism. Here you can compare the look and framerate of the v7 ENV (top) vs the v8 DSF (bottom). We are utilizing higher performance to make scenery more realistic, but if you'd rather have the framerate just load up the old scenery. It still works, and it's very fast.
Thursday, February 02, 2006
It's a miracle anything works...
Two bugs we resolved today ...
One user couldn't use our installer - it always failed on the file FA-22_cockpit_OUT.obj.zip. After reporting this to us, he figured out that parental-access controls in his router were banning the file due to a certain 4 letters in its name. I feel lucky that the user diagnosed the problem because I never would have figured that one out!
Also we've had reports that X-Plane 832 is slower than 816 when used in a two-monitor instructor/visual configuration. Finally we figured out what this was - a bug in my code: I programmed X-Plane to reduce CPU usage when a "dialog box" is up (the instructor station is one such dialog box) to play nice with other programs. But of course in two monitor mode the dialog box is up and you're flying, so reducing CPU usage kills framerate. This will be fixed in 835.
What's funky about this second bug is the reason why Austin and I could not reproduce it: the bug only happens if you do not touch the mouse! Austin and I, while trying to debug, would mouse around and click on all sorts of things, and this would hide the bug. Real customers, in real applications, don't touch the mouse while doing commercial training. (UI programmers who understand how mouse cursor updates are done in Win32 and Mac OS will understand this behavior.)
If there's a moral to this post (and there probably isn't), it's that bugs are hard to catch and reproduce because there can be system differences between users and developers that are very subtle - assumptions so basic that they don't get questioned.
One user couldn't use our installer - it always failed on the file FA-22_cockpit_OUT.obj.zip. After reporting this to us, he figured out that parental-access controls in his router were banning the file due to a certain 4 letters in its name. I feel lucky that the user diagnosed the problem because I never would have figured that one out!
Also we've had reports that X-Plane 832 is slower than 816 when used in a two-monitor instructor/visual configuration. Finally we figured out what this was - a bug in my code: I programmed X-Plane to reduce CPU usage when a "dialog box" is up (the instructor station is one such dialog box) to play nice with other programs. But of course in two monitor mode the dialog box is up and you're flying, so reducing CPU usage kills framerate. This will be fixed in 835.
What's funky about this second bug is the reason why Austin and I could not reproduce it: the bug only happens if you do not touch the mouse! Austin and I, while trying to debug, would mouse around and click on all sorts of things, and this would hide the bug. Real customers, in real applications, don't touch the mouse while doing commercial training. (UI programmers who understand how mouse cursor updates are done in Win32 and Mac OS will understand this behavior.)
If there's a moral to this post (and there probably isn't), it's that bugs are hard to catch and reproduce because there can be system differences between users and developers that are very subtle - assumptions so basic that they don't get questioned.
Wednesday, February 01, 2006
Boston Drivers
Last night I was looking at what it will take to put animated cars back on the roads in X-Plane. (I can't say if or when they will come back...that's a subject for another blog entry.) I found something that's going to be a little tricky.
Simply put, the road data we use in the US (Census TIGER data) does not contain directional information. It might tell us a street is one-way, but it doesn't tell us which way it goes!
In fact, the data doesn't even say which highways connect to each other! The road data is "flat". If two highways cross each other we see this as a four-way intersection. In the original US DSFs the roads were built with this flat pattern - sometimes you'd see a 10-way intersection of limited access highways.
In an attempt to clean up the highways for the global render I wrote some code that attempts to evaluate junctions for traffic flow. Basically it knows that two limited access highways at right angles cannot intersect and it moves one up in the air as a bridge. This process iterates a bit in an attempt to make a junction that is fully real-world navigable.
One advantage of processing the roads in this manner is that often it will remove bogus junctions, allowing us to continue straight roads. This both reduces file size and improves the look of the roads. (Our road junctions still look terrible - a throwback to a time when road-creation paused flying and therefore speed was at a premium over visual quality.) Unfortunately this "layering" code sometimes goes haywire and does some pretty strange things:
The good news is: DSF files do have a notion of direction, so if we ever get better road data, the sim and file format will be ready. The bad news is: the current DSFs have a road grid that may be similar to driving in Boston.
(As a side note, I grew up driving in Boston, so none of those rules seems even slightly unusual to me. What did surprise me was: when I moved to Washington, DC I found the rule that the cheaper car has the right of way turned on its head. I've never been cut off by more reckless BMWs and Mercedes in my life. You can speculate about what this says about the culture of our capital.)
Clearly X-Plane's car engine needs to address this in some manner. There are two cases that are tricky: one way roads that end at the destination of other one-way roads (leaving the car with no legal route) and one-way roads whose origin is not connected to anything but the origins of other one-way roads (giving cars no way to reach the road). The later case is not really a problem - it just means the road will have no traffic; the later is more of a problem as it requires the car to do something illegal to get out of the situation. I am still looking at what we can do about this but my guess is that cars are going to have to employ some Boston driving to get around the X-World.
Simply put, the road data we use in the US (Census TIGER data) does not contain directional information. It might tell us a street is one-way, but it doesn't tell us which way it goes!
In fact, the data doesn't even say which highways connect to each other! The road data is "flat". If two highways cross each other we see this as a four-way intersection. In the original US DSFs the roads were built with this flat pattern - sometimes you'd see a 10-way intersection of limited access highways.
In an attempt to clean up the highways for the global render I wrote some code that attempts to evaluate junctions for traffic flow. Basically it knows that two limited access highways at right angles cannot intersect and it moves one up in the air as a bridge. This process iterates a bit in an attempt to make a junction that is fully real-world navigable.
One advantage of processing the roads in this manner is that often it will remove bogus junctions, allowing us to continue straight roads. This both reduces file size and improves the look of the roads. (Our road junctions still look terrible - a throwback to a time when road-creation paused flying and therefore speed was at a premium over visual quality.) Unfortunately this "layering" code sometimes goes haywire and does some pretty strange things:
- A highway may be put in a high layer in one junction and a low layer in an adjacent one; the result is a highway ramp that "dives" down at a steep angle to try to meet all of its crossing restrictions. The layering code isn't smart enough to find optimal junction ordering when there are many junctions nearby.
- Sometimes the number of layers just gets huge, creating a massively tall junction. (But then, in Los Angeles perhaps this is realistic!)
The good news is: DSF files do have a notion of direction, so if we ever get better road data, the sim and file format will be ready. The bad news is: the current DSFs have a road grid that may be similar to driving in Boston.
(As a side note, I grew up driving in Boston, so none of those rules seems even slightly unusual to me. What did surprise me was: when I moved to Washington, DC I found the rule that the cheaper car has the right of way turned on its head. I've never been cut off by more reckless BMWs and Mercedes in my life. You can speculate about what this says about the culture of our capital.)
Clearly X-Plane's car engine needs to address this in some manner. There are two cases that are tricky: one way roads that end at the destination of other one-way roads (leaving the car with no legal route) and one-way roads whose origin is not connected to anything but the origins of other one-way roads (giving cars no way to reach the road). The later case is not really a problem - it just means the road will have no traffic; the later is more of a problem as it requires the car to do something illegal to get out of the situation. I am still looking at what we can do about this but my guess is that cars are going to have to employ some Boston driving to get around the X-World.
Subscribe to:
Posts (Atom)