What a difference new drivers make. ATI’s latest OpenGL drivers (Catalyst 8.1) seem to work quite well with X-Plane. On two fronts:
- Linux. Turns out all you need to do to make X-Plane happy on Linux with ATI hardware is update the drivers. I’m running with the Cat 8.1 drivers on my MacBook Pro and things look good. Use Catalyst 7.11 drivers or newer! No more MALLOC_CHECK_=1 or –no_threaded_ogl. With the next beta, you won’t have to use –force_run anymre.
- Windows. We were getting reports of corrupt screens on startup, and with the Catalyst 8.1 drivers these reports became very frequent. Turns out our threaded OpenGL code was doing something naughty*. Beta 19 fixes this.
The only known issue I can think of is: if you see corrupt water reflections, run with –no_fbos.
* Well, the way you set up threaded OpenGL on Windows and Linux is not very well documented, so I say naughty in that we made the drivers unhappy. I have yet to find a document that states clearly whether what we were doing is correct or not. We had to guess.
I figure there are three things that making blogging suited for software:
- A small interested group of users can subscribe to a blog without giving out an email address.
- The information in the blog can be found using a general search tool like Google.
- It’s easy for a busy programmer to post.
I think this last point is not to be ignored – I post a lot here because it’s easy enough to whip up a blog post that I can write one while the sim is booting.
The down-side of this is that blogs are not self-organizing. The blog is chronological, and somewhere within a heap of 200+ posts are detailed information on scenery topics not documented on scenery.x-plane.com.
That’s not good. So I’ll be trying to make a concerted effort to write real permanent documentation for some of the new scenery system topics that I cover. Documentation on DDS is in the works.
Part of the problem is that my interface for updating the X-Plane scenery website isn’t that robust. One of the nice things about the plugin system being a Wiki is that it’s easy to organize and easy to edit. (And one of my frustrations with “support forums” is that they don’t self-organize…they mix questions and answers based on history and not a search key that a user might use, like “what’s wrong with my card.” We’ll be supplementing the Linux forum with a Wiki soon.)
Here’s a summary of the new airplane features in 9.0 (and some coming). Hopefully this will give you an idea of what new capabilities are available for modeling planes in X-Plane 9. This list will sound like a broken record – virtually all of these features are optional; you don’t have to recut your finished airplanes to use them in version 9.
2-d vs. 3-d Panel
You may have noticed the new “3-d panel” option in PlaneMaker 9. This allows you to build a separate panel for the purpose of providing the texture to ATTR_cockpit (or ATTR_cockpit_region). You can then:
- Provide alternate instrument artwork in a cockpit_3d folder. (This lets you have perspective artwork for the 2-d cockpit and orthogonal artwork for the 3-d cockpit.)
- Pack your instruments together tightly to save space. (There is a real cost to large panels, so using a 1024×1024 panel for the cockpit object is a lot better.)
The 3-d panel is strictly optional, fully replaces the 2-d panel only for cockpit objects, and is activated by providing a custom panel background in a cockpit_3d folder. (See the “Example Plane-Widescreen+objects” plane in beta 19.)
ATTR_cockpit_region
Cockpit regions are an alternative to using the entire 2-d panel to texture your objects. They provide a few advantages:
- Performance. By requiring a power of 2 and allowing you to use a sub-area of the panel, cockpit regions avoid a lot of wasted computing that ATTR_cockpit can cause.
- Next-gen lighting. Unlike ATTR_cockpit, real 3-d lighting is applied to the panel when you use this attribute. This means that you will get a gradual decrease in light on your geometry (correct based on the angle of the sun) that matches the rest of the object.
Please note that you can mix and match which way you get your cockpit texture and whether you use the 2-d or 3-d panel feature (above) independently. However, you can only use ATTR_cockit or ATTR_cockpit_region in your airplane, not boht. ATTR_cockpit is still supported.
Generic Instruments
Generic instruments let you build instruments that follow some basic shapes (needles, tapes, etc.) that can be tied to any dataref. This both lets you customize particular instruments very precisely or create an instrument driven by a plugin dataref. These instruments are optional in version 9 – the old “premade” instruments are still supported.
New Datarefs
X-Plane 9 provides new datarefs targeted at airplane authors. The datarefs are better organized and have clearer names. But the old datarefs still exist, so legacy planes do not have to be updated.
Generally the entire cockpit should use only sim/cockpit2/ datarefs, and the plane exterior should use only sim/flightmodel2/ datarefs.
One special feature of these two sections: if your plane is used as an AI plane, these datarefs will animate the plane with the AI plane’s control deflections, not the user’s control deflections. So using these datarefs fixes the “AI animation” problem.
Plugins in Aircraft Folder
Version 9 airplanes may have a plugins folder (inside the ACF package) with fat plugins inside them. If you develop a plugin for your airplane, consider packaging it this way — this will allow your users to install the airplane with a single unzip for all platforms and no extra “drag-this-file-here”.
Plugins in the airplane folder is optional – you don’t have to provide a plugin, and plugins that are installed in the main Resources/plugins folder will still work. Still, I encourage you to use this feature because it makes the install process a lot simpler. The X-Plane SDK website will have documentation on fat plugins.
Liveries Folder
X-Plane 9 features a new “liveries” folder. Liveries (replacement exterior paint for airplanes and their attached objects) can be placed in packages in the liveries folder to greatly simplify the process of repainting an aircraft. See the “Example Plane-Widescreen+Objects” for an example.
While the liveries feature is optional, I strongly encourage anyone doing repaints to adopt it. Liveries can be switched by the user in the sim without any file manipulation; there is thus no risk of accidentally deleting or breaking an aircraft.
Large 2-d Panels
In X-Plane 9, a panel can be up to 2048×2048 in size. You pick the dimensions. The panel will scroll horizontally if necessary.
Note that if you use the new 3-d panel feature, the 2-d and 3-d panel do not have to be the same size. I would recommend a large 2-d panel (to fill large monitors) and a smaller 1024×1024 3-d panel (for performance).
Hiding Parts
X-Plane 9 will allow you to hide aircraft parts. Many v8 planes use OBJs to model the plane geometry, and use a transparent ACF texture to hide the ACF. Setting the parts to “not drawn” saves the CPU time that X-Plane would spend drawing the airplane, and is thus more efficient.
Keyframes
X-Plane 9 supports key-framed animation; this is useful for the scenery system, but for airplanes it allows for much more complex and realistic animation. OBJs that don’t have key frames still work.
Manipulators
This is a feature coming in the future: the ability to control how the user clicks and interacts with the cockpit object in detail. In X-Plane 9.0 we only support clicking on cockpit-textured geometry; manipulators will make features like draggable handles a lot more workable.
Global Illumination
X-Plane 9 does not yet offer a lot of control of the in-cockpit lighting environment; we’ll be working on this in future versions. These features will be opt-in…that is, you’ll have to change your model to get the new features, and old planes will work the way they always used to. It is likely that you’ll have to use “modern” airplane-building techniques to use these new features (meaning OBJs, named or custom lights, lego brick instruments ,etc.).
I try not to divert this blog from X-Plane related stuff, but I just can’t resist. Go to the itunes music store and search for:
amichai margolis
Ami has been a friend of mine for years; Orah V’Simchah is the first CD he’s recorded of his own music (I played bass on it). A few time a year he pulls a band together and we play a few gigs. Anyway, enjoy the tracks!
We get a lot of bug reports showing strange reflections in the water. Some of these we can fix easily, and some will be more difficult, if not impossible. There are two fundamental constraints on the water-reflection code:
- A reflective surface (read: water) must be approximately flat to be correct. This is just how the algorithm works. (If you want to see why a non-flat surface fails, try to draw a camera position opposite the reflection plane and trace rays through this “reflection camera”. Draw reflected objects that are close and far from the water and then observe the parallax error you get if the reflection plane curves.)
- We need one “water camera” for each flat reflection plane. You can’t just statically offset when we have multiple elevations. (When drawing your diagrams, note how an elevation change causes a change in reflected angle, not just an offset.)
So the water will always have two problems: the earth is round (so nothing is really flat), and we can have lakes of multiple elevations (and we can’t afford to render a water reflection per lake).
X-Plane tries to get around the non-flat water problem by picking little bits of the water that are flat (and seem useful) and using them to define reflections. This algorithm will always have problems, but at least it can be tuned.
Now there are also some things that we can fix with the water:
- The math in beta 18 is simply wrong, something that will be fixed in beta 19.
- The ocean is built from polygons that are too large; this introduces approximation errors when we try to pick “a little bit” of water to use to figure out our reflection plane.
There is one more problem that I see, especially in airports like PAKT: if there are two water surfaces of different heights that are nearby, X-Plane uses a slanted water plane that tries to include both. This works very badly – the resulting slanted plane doesn’t look even remotely plausible. I’m not sure how soon we can tune this problem.
I get a lot of requests for settings…the email is typically something like:
- Some feature in X-Plane is defaulted to X.
- I like it better when it’s like Y.
- Can I have a setting to change the feature between X and Y.
Raymond Chen has a great posting that I think is very topical: “In order to demonstrate our superior intellect, we will now ask you a question you cannot answer.“
This brings up one of the main reasons why we shy away from more settings: the more complex we make X-Plane’s configuration, the less likely it is that the average user will be able to set the sim up correctly. Settings requests usually come from our most advanced users, but we also have users who have never used a computer before. Really! I’ve been on the tech support calls – they are very nice, but way overextended on the computer side of things. Should we allow them to pick whether scenery geometry is store in AGP memory vs. VRAM?
From our perspective, having a setting that a user doesn’t understand is worse than neutral, it’s actually harmful. Every one of those settings is something that can go wrong with the sim. I removed the ability to set the level of detail bias to positive (in other words, extend the visibility distance of scenery beyond its original design) after about 500 complaints of “low framerate” from users who had maxed this setting out (causing a 4x increase in 3-d processing load) without knowing (1) what the setting was, (2) what it was good for or (3) what the down-side was.
Could we present all the info to make intelligent decisions on the rendering pages? Honestly, probably not beyond a certain point…we would devolve our sim into a lecture on working sets, bottlenecks, and the OpenGL pipeline long before the user got flying. (Wait, that’s my blog! Doh!!!) At some point the sim just has to do its best to do the right thing, or something similar to it. Just as Raymond points out that the default answer to any dialog box is “cancel”, the default answer to any rendering setting is “all the way up.”
When I tell a user who wants a setting that he or she can’t have a setting because some other user will abuse it, the answer is almost always: well why don’t you have two settings screens, a simple and advanced mode?
Besides the irony (of trying to solve the problem of too many settings with another settings), Raymond also points out that no location to hide an advanced setting is ever quite good enough. This is something we have struggled with, choosing command-line options more for to pragmatic reasons than because it’s a great solution.
This doesn’t mean you can’t ask for command-line options…I am just trying to point out some of the thinking on the other side of the coin.
There are a few cases where you cannot use DDS files in X-Plane:
- Airplane 2-d panels (any layer – base, lit, -1 shadow layer, 2-d or 3-d).
- Airplane instrument images.
- Bitmap-based region specification referenced in a library.txt file.
- Any gray-scale/alpha-only texture (e.g. mask files in the scenery system).
Beta 17 is treating cases 1 & 2 as an error; beta 18 will simply stop looking for DDS files in those cases.
Please note that airplane panels and instruments are not compressed right now, so there would be no performance benefit to using DDS in these cases. (If anything, PNG has smaller file size when compression is not used.) If we ever allow compressed panel textures, we’ll probably allow DDS panels at the same time.
Case 3 is just a particular version of case 4 – that is, the region bitmap is black and white (1 channel) so DDS provides no benefit. Use a gray-scale no-alpha PNG!
Just a few basic things:
For airplanes where you don’t want to show the PlaneMaker part (because you’ve rebuilt the plane visually using OBJs):
- In X-Plane 9, set the parts to be invisible – this is faster than drawing them with a transparent texture.
- In X-Plane 8, if the texture is transparent, please downsize it! A 1024×1024 texture that’s fully transparent is just a waste of VRAM!
For any version, any object, avoid using ATTR_diffuse_rgb when possible. You can get the same effect by tinting your texture and save unnecessary state thrash.
First, the most salient point: in X-Plane 9.00 beta 16, 2-d panels and 3-d cockpits should both look the way they did in version 8. That is, your v8 plane should look good in v9 without modification. This is due to both:
- A bunch of bug fixes regarding burn-in and night lit layers.
- “3-d” lighting is not applied to the cockpit texture.
On this last point, my hope had originally been that I could apply 3-d lighting to the cockpit and simply make existing content look better. It has become painfully clear to me that this is not possible — existing planes are very carefully tuned to look good despite what I can only describe as “inconsistent” lighting rules in v8. Applying more consistent general 3-d lighting wrecks this tuning.
So new features regarding 3-d cockpits will be opt-in – that is, you will have to change your model to start using them. Existing content will work the way it used to.
I will explain what new features are available in 9.0 and what will come in 9.1 in a separate post real soon.
Beta 16 should be out relatively soon and includes what are probably the last of the water improvements for X-Plane 9.0. (All future water improvements will be in free patches or future releases.) Here’s what made it into this particular version:
- Water wave patterns now follow the wave settings in the weather-water screen.
- “Fetch” data from the DSFs (information about whether water is subject to ocean waves or not) is used to modulate wave patterns – go to KSAN and set the wave height fairly high. Notice how the waves die out to ripples in some of the bays.
When I last blogged about water, I hadn’t realized that we already have “fetch” data in the DSFs (and have since 820). Bear in mind that the fetch data in the current DSFs is not very good – I am sure you’ll find plenty of strange cases where there are ocean waves inland, or calm areas in the ocean. The algorithm just isn’t that good. New fetch data only comes with new global scenery.
The physics engine is not synchronized with the visual waves, although they both use the same wave height from the weather screen. The physics engine isn’t using fetch yet. I may be ale to address this in a future beta, but I’m not sure.
What I have had to punt on (for now – remember, a ton of new features come to X-Plane in the form of free patches!) is the issue of reflectivity, sparkle, and water color from various view angles. As I explained in my previous post, the way the wave pattern is filtered with view-distance causes the water to look unrealistically calm from far away. Now that we can haev taller waves this is less of an issue (set very high waves to avoid the reflective look as much as possible) but it’s still there.
I have some possible technology ideas on how to address this problem, but we don’t have enough time left in this build to go all the way with them.
One final note on water: Windows users witih Radeon HD hardware can work around the corrupt reflective water issue by running the sim with –no_fbos.
