I’m back, but things will probably be quiet a bit. A lot of new scenery features will be going into 850, but it may be a while before 850 is ready for test due to how much is going in. I’ll post more as I know it – my work for 850 will be mostly focused around improving the look of airport areas.
I’ll be out of the office for the next eight days; please be patient with bug reports and scenery questions. An X-Plane RC should come out soon and we’ll let it sit a bit to see how it does. I think we got the fog bug fixed!
In version 840 I tried to fix a persistent bug in X-Plane where objects sometimes randomly disappear…turns out I got the math wrong.
The next 840 beta (which I think will be called “RC1”, but I am a poor predictor of these things) has a bug fix to the bug fix. I don’t know how many of these bugs this will fix (some appear to be due to driver issues) but I think we’ll be closer.
I try to avoid politics in this blog, but this article that Jonathan Harris posted to the scenery list is pretty topical to X-Plane.
//education.guardian.co.uk/universityguide2006/story/0,,1726985,00.html
Of course I am biased – low-cost high quality data (SRTM, Tiger, etc.) make it possible for a small company like X-Plane to create high quality scenery. But I would also add two more thoughts:
1. Knowledge is crucial to the healthy functioning of a democracy. Without good digital maps, you can’t apply modern tools to understanding regional trends, environmental problems, electoral districts, etc. Knowledge shouldn’t just be for the rich (or big companies).
2. Geospatial data is infrastructure – free or cheap GIS data make a country a better place to do business. I think in this global economy every national government needs to be asking “what are we doing to make sure our citizens will be competitive on a global level.” There’s no question that having good roads and transportation infrastructure are important for a national economy, but I would submit that having good digital infrastructure will become important too; in that context it’s appropriate for a government to make the data free (and take the local loss in the providing agency) to foster growth, employment, and the well-being of its citizens.
Just my 0.02…
Long time no post – it’s been a busy few weeks, helping friends with projects and traveling. There have been some lively discussions on the scenery list though!
I’ve been tossing around the idea for a fundamental change in the way the apt.dat format handles metadata. It’s subtle but I think it has some far-reaching implications.
Right now the apt.dat format is pretty high level. Let’s use taxiways as an example: a taxiway has a light code that indicates whether the taxiway has blue edge lights. This has two effects:
1. The information about whether the taxiway has lights is preserved.
2. You can’t put blue edge lights down without a taxiway.
I am exploring the idea of entirely separating edge-lights/lines* from taxiways. This would mean that:
1. We’d have no idea about whether the taxiway has lights. There may happen to be lights nearby, but we can’t be sure of where they come from and
2. We can put lights anywhere.
The shift is fundamental because it is reducing the amount of high level data and increasing file size in return for gaining flexibility with a simple system.
Anyway, email me if you have thoughts on this…food for thought.
* The exception will be runways. We will be supporting all existing data in the apt.dat format – nothing’s geting dropped, and there isn’t a real replacement for runways. Generally runways will still be built by saying “this is a runway and these are it’s many properties” and letting the sim do the rest.
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.
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.
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:
So please do not be surprised when the impossible becomes the possible; one of the things that makes flight simulation and enjoyable problem to work on is that new technology constantly unlocks new possibilities and lets us make each version of the sim better than the last in ways that would have been impossible.
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.
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.