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.
Randy forwarded me a very detailed email message from the features list about water. First a few notes:
- I don’t read the features list – I’m only blogging this because Randy forwarded it my way.
- Procedural water (that is, procedural waves with the sky as a reflection) is a default shader option because when we first looked at it, it seemed to be “low cost”. Some hardware really chokes on this option. But one trend that’s clear: I have not seen any hardware that can do volumetric fog but has trouble with water. When it comes to expensive computations, vol-fog is the the heavy effect. If your card can run with vol-fog even remotely well, you’re not going to get any kind of fps boost by turning off water. So the question of whether procedural water can be optional is one of whether the water looks good (which I will discuss below), not one of performance.
- I’ve received plenty of emails about how we can “cheat” on the reflections to make them faster. To be honest, these ideas aren’t very useful…you really need to know how the rendering engine works on a low level to find good ways to cheat on reflection quality.
(It’s not enough to make the reflection texture less good looking, you have to do so in a way that makes it take less time to render! We’ve basically already taken all the optimizations we can – that’s what that water reflection detail popup does. Keep it on a lower setting.)
So with that in mind I’d like to bring up three issues with the reflective water and give you some idea of the roadmap. I should say that when I list features as coming in the 9.xx or 10.xx time frame what I really mean is: some depend on new global scenery and some do not. It’s possible that we may do a ton of water work in 9.1 or we may not do any more for five years. I can’t really make a good prediction on future features after 9.0, except that they’ll be, um, really cool. 🙂
Water Weather Settings (9.00)
X-Plane currently provides a global wave height setting. X-Plane 9 beta 15 ignores this setting and simply creates calm water. This is simply a link-up between the physics and the shader that I had not gotten to until now. I believe that beta 16 will address this; the water wave height will match what you dial in. This still is only a baby step, but there will at least be a workaround for the mos common complaint (the ocean looks like glass) in that you can set the wave height to 10 meters.
Water Properties (9.xx, 10.xx)
Now Peter brings up an important point: the properties of how the water look vary with their location. First I must point out an architectural issue: you can’t do a great job of computing “fetch” (open runs where wind builds up waves) in the sim because the area adjacent to the current water may not be loaded. That is, if X-plane doesn’t have the pacific ocean loaded, how can it know that the waves hammering San Francisco can be pretty big? So I have always viewed fetch as something to pre-compute into a DSF mesh.
(This does bring up an architectural issue…how can we have properties on open ocean with no DSF mesh? The answer might end up being that we do have to provide water-only DSFs for bays and inlets that are large enough to cover a whole tile.)
Now it turns out that (secretly) the DSFs have contained a very crude version of fetch since 8.20. In version 8 we didn’t really have the shading power to visualize it (I did have some experimental code once) and in version 9 it is not yet hooked up. The fetch calculation isn’t very good, but it does exist. In the long term, we’ve talked within the company about including bathymetric data (water depth) and even water properties like clarity and the color of the goo in the water. Improving the water metadata would be a next-global-scenery feature, and we don’t recut global scenery very often.
(The DSF format is flexible…you can encode just about as much extra data into the mesh for water as you want – it’s not a format change.)
So I think you may see some improvement in the water as we utilize existing fetch data in the mesh, and some improvement as we encode more meta-data into the mesh. Note that to do any of this we need to change the sim a bit…right now it assumes a constant wave height – this would no longer be true. I think these kinds of improvements will start during the 9.x run but not be in 9.0.
Filtering Errors (9.xx)
This is the most technical issue with the water, relating to how the graphics hardware works. The problem is that the way the far-view of the water is computed is too reflective due to down-sampling.
In real life, if I am in front of a body of water with 6 inch waves, I will see two things:
- Near me, I will see the waves themselves. Part of the waves will be dark, because their surface normal faces me, so the Fresnel equation says I see down into the water, where I see the bottom (or if it’s deep enough, darkness). Part of the waves will be at an angle to me and act reflective, picking up colors from the sky and maybe surrounding terrrain. So my waves are going to be a mix of the sky color and some kind of dark color, with the color contrast allowing me to see the shape of the wave.
- Farther out, the waves will be smaller than my eyes can distinguish and I’ll start to see a more consistent water color, which is a mix of all of the various sky color inputs and darkness. The particular mix might depend on the chop and shape of the waves and angle to the sky. The important thing is: there is scattering of the reflection at a level smaller than my visual acuity, so I see sky color, but I don’t see a sky reflection, and that color is darkened by the Fresnel equation.
Now in X-Plane the problem is this: the water waves are built up procedurally from a noise texture. As we get farther away, that wave texture is reduced in quality. Unfortunately, the graphics hardware averages together the wave shape, not the resulting color from the wave shape.
So instead of getting sky + deep = darker blue for the water, I get peek + trough = flat water! In other words, at a far distance the waves are canceling each other out before color lookup, giving us a perfect mirror in the far-ground.
This is fundamentally an implementation problem – I bring it up only because it’s a counter-intuitive one. In the immediate future, the “glass lake” problem will become less because filtering only kicks in like this when the waves become less than one pixel – with the option for taller waves coming, the waves should be visible farther out. In the longer term we’ll probably put in new shading code to address filtering problems.
Reflection Positioning Bugs (9.0, 9.xx)
As of beta 15 I thought I had fixed most of the reflection positioning bugs (that’s what happens when something reflects in the wrong place in the water) – the geometry for this is made complicated by the Earth being round. I don’t expect to nip all of these bugs in 9.0 but I do hope to get most of them, and I will keep working on this as bug reports come in.
Wave Shape (9.xx)
Finally, our wave shapes are quite primitive – it’s just shaped procedural noise designed to look tolerably like water. We have a framework into which we can insert more complex wave equations (at the cost of some framerate). I don’t know what the future will bring in this area. The v9 water sets out a new foundation onto which we can do more complex water. But we have to crawl before we can walk.
For years now I’ve been harping about ways to keep the number of batches down in your scenery. A batch is a single submission of triangles to the graphics card for drawing. Batches get rendered fast even if they contain a ton of triangles, but changing modes between batches is not very fast, so a few large batches is hugely better for performance than a large number of tiny batches.
To play that broken record one more time, there are two ways that you (a scenery designer) can cut down the number of batches):
- Use a small number of larger textures instead of a large number of small textures, preferably sharing textures between similar scenery elements that are placed nearby. X-Plane will do its best to merge the content that uses those textures into single batches. We call this the “crayon rule.”
- Use less attributes in your objects. Attributes usually require a new batch (after the graphics card mode has been changed due to the attribute). So if you’ve got 1000 attributes in your object, you’ve got a problem.
Well, with X-Plane 9 I have a new broken record: avoid overdraw!
Overdraw is the process of drawing pixels on top of other pixels on screen. It happens any time we use blending to do translucency, and any time we use polygon offset to build the image in layers.
Overdraw is bad because with X-Plane 9’s pixel shaders, most users are slowed down by the graphics card’s ability to fill in pixels (pixel fill rate), with those complex shaders being run for every pixel. If you are at a screen-res of 1200×1024 looking at the ground with no objects, that might be 1.2 million pixels to fill. But if there is an overlay polygon covering the ground, we have 2.4 million pixels to fill! That’s a huge framerate hit.
Right now there’s not much you can do about overdraw. Once MeshTool comes out I will post some guidelines on how you can limit overdraw.
We took a step in the v9 global scenery to limit overdraw: in X-Plane 8 the global scenery tried to hide repetition of flat textures by drawing them over each other with offsets. In X-Plane 9 this is done in a pixel shader (e.g. the texture is analyzed and swizzled in the shader and then drann once), cutting down the number of times we must draw.
If you turn pixel shaders on and off in a flat area like Kansas you might see this if you compare the screenshots – the farm textures are more repetitive without shaders. This gives faster fps to everyone (with or without shaders) by eliminating overdraw.
Sandy and I are working on a major revision to the plugin SDK (all the old stuff will work, we’re just adding new things) that should be available in X-Plane 9 soon. The new “2.0” SDK APIs include some new functionality for working on scenery.
- Plugins can find the height of the ground at a given location, which is necessary to draw in the 3-d world in a realistic way (e.g. vehicles that drive on the ground in a sloped airport environment).
- Plugins can load and draw OBJ files using X-Plane’s built-in facilities. I’ve posted OBJ drawing code in the past, but this makes things even easier.
- Plugins can lookup virtual paths in the library to find artwork from scenery packages.
This makes a number of scenery-system concepts available to plugins.
I’ve been resisting OBJ-drawing support in the SDK for a while, but a few things changed my mind:
- We’ve moved as much drawing in X-Plane to OBJs as possible and it’s been a big win. A lot of the dynamic elements are OBJs, they’re used in scenery and cockpits and airplanes. Using OBJ files means our artists (who are not programmers) can customize just about every aspect of the sim. So by providing a file format with a rich tool chain to plugins, hopefully we are helping third parties streamline content development.
- With pixel shaders, X-Plane’s 3-d drawing environment has become complex and hard for third parties to safely augment. By encoding drawing at a higher level via pre-built OBJs (which can be animated via plugin-driven datarefs) we can insulate plugins from drawing-environment changes.
I’ll try to get it fixed soon….it’s a bit frustrating, because it’s the second time in the last week that I made a change to X-Plane to try to improve performance, tested it on my hardware, then discovered in-field that it helps some machines but screws up a lot of others.
The fog was a screw-up though…it’s broken on the 9600XT and I have one of those.
(I’m not entirely sure what the minimum graphics card for volumetric fog will turn out to be…right now we let you use it no matter how slow it makes the computer, but generally it’s been sort of a performance problem…it’s just a very expensive algorithm that needs some kind of restructuring.)
If you have content that worked in 864 but does not work in 9, please file a bug! Please do not assume we intentionally changed the file formats to break compatibility…I would rather get the bug report so we can fix X-Plane than have you change your work.
For every author who changes his or her work in response to a bug (an accidental breaking of compatibility), we’ll have dozens of users who find their add-ons not working but not knowing how to fix it themselves.
With that in mind, beta 16 will have two fixes:
- Some panels were showing the default instrument backgrounds over custom panels. This will also be fixed in the next beta.
- Lit customized overlay parts were not showing. This will be fixed in the next beta.
So if you see those bugs, please check your plane against the next beta when it comes out. If you find other problems, please file a bug!
X-Plane 8 didn’t care much whether you used ATTR_cockpit in scenery objects or other strange places. It would simply show the cockpit panel texture, and if it hadn’t been updated, you might see an old one, and if it had never been used, maybe you’d see the random (but colorful) contents of memory. Similarly if you could get close enough to another airplane to look in the window, you’d see your own panel, since there is only one panel texture (for the user’s airplane) in the entire scenery system.
This is a bigger problem in X-Plane 9.
- Because the panel texture can be expensive for big panels, we are a lot more aggressive about not setting up the panel texture if we can avoid it. This means that sometimes the texture doesn’t exist at all. This is why in beta 14 you get an error if you do a formation flight having only been in “w” (forward 2-d) view…the panel texture doesn’t yet exist, but the exterior view of the Cessna tow plane uses it.
- With panel regions there can be up to four panel textures, so you can see the potential for anarchy.
- Panel textures aren’t even the same size any more, causing the wrong-panel-in-AI-plane problem to look even weirder than before.
So in beta 15, the panel texture is replaced with a dummy white texture for:
- Any cockpit object for an AI plane.
- Any scenery objects that are illegally using the panel texture.
This prevents crashes and other nasty stuff. If you want to make the panel be visible in your AI plane, consider using LOD to make a non-panel-texture “fake” cockpit image (at a very small res) at farther LODs. My guess is that in normal usage of the sim you’d really have to do something dangerous to get close enough to see the hack.
We did discuss live panels for all planes (for all of about 3 seconds), but the live panel texture in 3-d is so expensive that it’d be prohibitive to most users for even one AI airplane, let alone 20!
If you create plugins, airplanes, or scenery for X-Plane and haven’t tried your add-ons with X-Plane, please do so soon!! It’s much easier for us to fix backward-compatibility problems while we’re still in beta. Beta 14 introduced some bugs (that should be fixed in beta 15 real soon) but I think we’re reaching the point where you can do compatibility testing.
We’re working on a public Linux beta – see here.
