If you have ever textured an airplane, then you know that you can’t use the same texture for both sides of the plane if there is writing on the fuselage. The writing will be horizontally mirrored on one side.
The same thing goes for normal maps – you can’t mirror a normal map without getting bogus results. Think of your normal map as a real 3-d (slightly extruded) piece of metal. If you are seeing the text go the wrong way, the metal must be facing with the exterior side pointing to the interior of the airplane.
Having your normal map flipped does more than just “inset” what should be “extruded” – it completely hoses the lighting calculations. In some cases this will be obvious (no shiny where there should be shiny) but in others you will see shine when the sun is in a slightly wrong position.
The moral of the story is: you can’t recycle your textures by flipping if you want to use normal maps.
Now before you come at me with pitch-forks, I don’t hate photo-realistic scenery, and X-Plane’s performance with orthophoto-based scenery is very, very good. But…the term “Photo-Realistic”…it makes me crazy. Here’s why:
First, photo-realistic scenery links the use of photographs in scenery to realism in its very name, and I don’t buy it.
Yes, some photo-based scenery packages are realistic looking, by today’s standard of flight simulation. Some are not. Just look at any old photo-realistic package to see what I mean…realistic is a relative term, defined by how much fidelity we expect, and that expectation has steadily gone up. Even with a modern package, a photo-based scenery pack might not be realistic if the photos are not used well.
(For example, is a package that uses orthophotos on the mesh but provides no 3-d in a city still considered realistic now? What kind of review would such a package get?)
Nor do photos have a monopoly on realism. They can look nice when well used, but I would put Sergio’s custom panel work up against any photo-based panel. (Sergio does not manipulate photos for his panel, he constructs them from scratching. He has thousands of photos for reference, but the pixels you see are not originally from any photo.)
Second, the term photo-realistic (in the scenery world) is most commonly applied to scenery that applies orthophotos to the terrain mesh in a non-repeating way. But orthophoto base meshes don’t have a monopoly on the use of photographs, which can be used to form land-class textures or to texture objects.
Okay, so “hate” is a strong word. But I feel some frustration whenever I see scenery discussed in terms of “photorealism”.
I’ve had a few inquiries about environment maps, normal/specular maps in more places than just OBJs, etc. The short answer is: a lot of these future rendering engine enhancements are good ideas that we like, but we have other features that are already partially implemented that we need to productize first.
In particular, one of those half-finished features not only could use to be shipped, but also affects the way just about every other rendering effect works. So better to get these features finished first, and build new effects within the context of these “new rules”.
Here are some of the ideas that I’ve heard kicked around:
- Environment maps on the plane – I like it, it’s not that hard to do, and the framerate hit could be ramped up and down with detail. See above about finishing other features first.
- Next-gen texturing on runways (wet runways, environment maps, bump mapping) – I like all of it. The runways really need to be addressed comprehensively, not piece-wise, in order to find a rendering configuration that meets our scalability and efficiency needs. (In other words, we can’t just burn tons of VRAM on the runways, and we need a way to render them that works on low and high end computers with one set of art assets.)
- Normal mapping on the ground. I like it, but I wonder if this isn’t part of a bigger idea: procedural texturing on the ground. E.g. if we want to add detail on the ground, can we add it with multiple layers at different resolutions with a shader adding yet more detail.
Generally speaking, it’s not that hard to push a feature out from one part of the rendering engine to the other. For example, normal maps on facades (if anyone cares 🙂 would make sense and be a fairly trivial change. I hesitate on polygons only because the ground might require something a little bit more sophisticated.
Going Crazy With Choices
Here’s a straw man of why polygons might be different: draped polygons can’t have specular shininess right now, and I don’t think anyone is complaining. So it’s a bit of a waste to use the alpha channel of a normal map for shininess. Perhaps it could be used for something else like an environment mapping parameter.
Hrm…but we would like to have environment mapping on airplane objects too someday. Well, we could go two ways with that. We could just use the alpha channel for shininess and environment mapping…not totally unreasonable but it wouldn’t let us have a glossy non-reflective material, e.g. aluminum vs. shiny white paint.
Math nerds will realize that the blue channel in normal maps can be “reconstituted” from the red and green channels by the GPU (at the cost of a tiny bit of GPU power). That would give us two channels to have fun with – blue and alpha. Perhaps one could be shininess and one could be an environment mapping material.
Well, shininess is still no good on the ground. But…perhaps that would be a good place to store dynamic snow accumulation? Hrm…
My point of this stream-of-consciousness rant is that the design of any one rendering engine feature is heavily influenced by its neighbors. We’ll get all of these effects someday. If there are features that are really easy, we can get them into the sim quickly, but the only obvious one I see now is using bump maps on other OBJ-like entities (which at this point would mean facades).
In response to so many bug reports I say:
Please temporarily remove your third party scenery, airplanes and plugins and retry. Do you still see this bug?
And in response I get:
No – the bug was with XXX. Thanks!
But…but…but…we’re not done yet! The point of removing the third party add-on is divide-and-conquer: to see if the bug is in the core of X-Plane or is caused by an X-Plane-add-on interaction.
If the add-on used to work but no longer does, I want to know where I can get the add-on, who created it, and when it used to work, so I can investigate further! If an add-on stops working because X-Plane was updated and the add-on is not doing anything naughty, that is still an X-Plane bug.
So please: don’t give up on the bug just because removing the add-on makes it go away…there is still more to debug!
The rule is very simple: if you want to put a marking on the ground, your results will be much better if you use a .pol (draped polygon) or .lin (draped line) than if you use an OBJ. In fact, an OBJ is probably the worst way to put markings on the ground.
Requirements for Good Looking Markings
In order for markings to look good you need to have three things happen:
- You need to make sure your markings are at the exact same level as the ground itself.
- You need to use polygon offset to tell X-Plane to tell the video card that these are “coplanar” (at the same height) triangles that must be managed in a special way.
- You must guarantee that the draw order is: the stuff under your markings, your markings, then the 3-d buildings and other 3-d stuff.
With these requirements we can compare .pol/.lin files to OBJs:
- .pol and .lin files always “drape” to the ground, so they always meet rule 1 perfectly. With an OBJ you can set the height of your OBJ to 0 but on sloped terrain this won’t be correct.
- .lin and .pol files are always “polygon offset” automatically, so they always meet rule 2 perfectly. With an OBJ you need to use ATTR_poly_os.
- ATTR_layer_group (or LAYER_GROUP) tell the OBJ or pol/lin in what order to draw, so you can set this correctly in all cases. The default values if you don’t specify a layer group are more appropriate to the task of markings on the ground when you use a pol/lin – that is, by default they meet rule 3 perfectly. By comparison, an OBJ may not be in the right draw order.
So we can see from these 3 rules that you will always get the rules right just by using a pol or lin, but you have to be very careful and may still not get the rules right when using an OBJ.
Performance? Think .pol
When you have a large number of small markings, the performance of a .pol is going to be significantly superior to the performance of an OBJ. For example, imagine an airport where you want to draw on-pavement signs for all taxiways and runways. With an OBJ, to get the height right, you’d need to use a large number of small objects. (With one large object, it will be nearly impossible to make the OBJ markings be on the ground when far from the object center.)
When you use a large number of .pol markings that share one common texture and all have the same .pol file, X-Plane merges them behind the scene into one huge object-like pile of triangles. The cost of drawing all of those polygons will be similar to the cost of drawing just one object! That’s a huge speed win.
Floating Objects Are Wrong
What I see most commonly in scenery packs that are sent to me and have thrashing problems are OBJs that have a height other than 0. This is simply the wrong way to create overlaid geometry in X-Plane, and it will produce artifacts in a wide variety of situations. At best, the “floating” objects will cause airplanes driving over the marking to look like they “sink in”. At worst, the offset you pick will be too small for the video card’s resolution and you’ll get thrash anyway.
There is no one right vertical offset for all scenarios, and even if there was, it would still look ugly! See the above rules for what an OBJ really has to do.
How Do I Get a .pol into my scenery.
Well that is the $10,000 question. I must admit that I don’t know what Overlay Editor’s capabilities are in this regard. WED 1.1 will be able to add draped polygons, including texture coordinate editing of the polygons. I’ve been working on the texture coordinate editor in WED this weekend and am hoping to get some kind of WED 1.1 preview built this week.
With WED 1.1 the process is fairly simple:
- Create your texture.
- Create a single .pol text file that names the texture, so you can use it.
- In WED 1.1 you can select the .pol from the list of resources for your scenery pack, and then use the “polygon create tool” to simply draw the draped polygons into place.
- Once the draped polygons are created, you can select the polygon and open the “texture coordinate editor” tab to edit the way the texture is applied to the polygon.
My hope is that this process will be easier than creating markings using a 3-d editor – you can still edit the texture coordinates, but you can do so directly in WED.
I was revisiting Bézier curves today. First I should say that the current scheme for handling Bézier curves in apt.dat and DSF is horribly convoluted – I am looking to replace the syntax with something less weird for the next set of features that use them. But I was also looking at the problem of generating curves from high-density line data.
Did you know that a Bézier curve can have any number of control points? This picture illustrates:
Each curve has one more control point than the last. Zero control points is of course a line segment, and two control points is a “cubic” Bézier, which is what we have now. (Note that having one control point in WED does not give you the one-point quadric Bézier you see here. WED gives you a cubic Bézier with one control point on top of an end point.)
But it also show: having tons of control points are not particularly useful for modeling a shape in detail – a string of connected cubic Bézier is probably just as good. And the high-order Bézier doesn’t really trace out the control points, so it’s not a good way to convert line segments into a curve.
There are a few changes to 940 regarding airplane lights…I will try to get some permanent documentation on the Wiki, but here’s the basic ideas:
There is a new “type” of light in the OBJ8 format, called a parameterized light. A parameterized light is somewhere between a named light (totally as-is, can’t be modified, simple to use) and a custom light (totally complex, can do anything, requires a lot of work). In a parameterized light, you control just one or two aspects of the light.
Parameterized lights are aimed at airplanes, not scenery, because typically parameterized lights are customizable and slow.* The goal is to give airplane authors some flexibility without having to invent a huge number of named lights.
Consider, for example, landing lights. A landing light could vary based on what switch controls it (we have 16 now), how big it is (many authors have pointed out that one size does not fit all) or how wide it’s view angle should be. (Lights that are inset in a structure might not be easily viewable from the side.) With a parameterized light, we can provide one light definition with 3 parameters instead of a huge matrix of lights.
Generic lights are a new collection of 64 lights that can be used for any purpose, sort of like misc wings, misc bodies, and sliders. The main difference between a landing light and a generic light is that the landing light halo won’t show up on the runway when a misc light is turned on. They are meant to be used for logo lights, inlet lights, etc. A series of new named lights will “listen” to the generic switches.
(Tip: combine ATTR_light_level with generic lights to have a light turn on and your lit texture appear at the same time.)
Finally, there is now a plugin override for the beacons and strobes (and in the systems model there can be up to 4 separate sets of beacons and strobes flashing at different times). With parameterized lights you can make two sets of strobes and use a plugin to control when they flash.
The combination of these three things let an author create an airliner that models all of the various lights and their behaviors.
* Slow needs some qualifications here. There are two code paths for lights, the fast and slow path. The slow path IS pretty fast, just not as fast as the fast path. The fast path is expected to be able to draw at least 10,000 lights in a single frame on low-end hardware, while the slow path is expected to be able to draw at least 500 lights per frame on low-end hardware.
500 lights is a lot for one airplane, especially if you have to place them by hand. And most modern computers will easily do thousands of slow lights.
Basically slow lights are not appropriate for scenery objects in the library that might be placed a huge number of times: OBJs attached to roads (e.g. street lights), OBJs used for buildings, taxiway lights. The are plenty fast for airplanes. In the X-Plane world, slow doesn’t really means slow, just slower than something else.
A quote from the .org:
I actually did try the demo before I bought it, and I found it sorta arcadish as I took off with a King Air 200 and performed barrel rolls on t/o lol! That kind of tuned me out!
I don’t mean to pick on that particular poster – we hear that a lot, particularly from people who use MSFS. Andy Goldstein points to Bob Hoover as a counterpoint.
More generally, the criticism is that since X-Plane will allow you to do things in commercial airliners that you’ve never seen in real life, X-Plane must not be realistic. And phrased like that, you can see the possible flaws in the reasoning:
- How do you know your control inputs match real life?
- How do you know the real plane is physically incapable of doing such a thing?
The first is the age-old problem of consumer joysticks – to really maneuver an airliner hard you have to put a lot of pressure on the controls – they put up a lot more resistance than a $20 SideWinder.
The second is an issue of falsifiability again – the absence of evidence is not evidence of absence.
Now in truth there are things that X-Plane models and X-Plane does not model. If you load up the airframe too much with fail-on-over-G on and the G limits are set correctly, X-Plane will start removing parts as you try to fly a 747 like an F-16. But we don’t necessarily simulate some of the internal things that might go wrong. For example, accelerations on the fuel system might potentially cause flow to the engines to fail, stalling an engine. I don’t know how much of this Austin simulates, but we certainly don’t simulate the geometry of the fuel lines and the fuel as a fluid flow. So there may be cases where a maneuver is impossible for logistic but not aerodynamic reasons (e.g. you could do it but you’d lose your engines).
With that in mind, here are a few youtube links:
- Bob Hoover flies a Commander like an aerobatic glider – thanks Andy!
- Roll an airliner? It’s safe, really!
- The 757 has a lot of power – thanks Andrew.
- I have no idea what happened here…I thought the Airbus computer prevents you from doing this kind of thing.
On that last video: the first time I flew with Austin in his Cirrus (this is before he traded it for a Columbia) he pulled the same maneuver: take-off, very slow rate of climb to pick up speed, and then: yank. Our climb rate was well over 2000 fpm in a single-engine prop for a while.
(Logistic note: please don’t interpret this post as an invitation to contact me regarding any aspect of the flight model – when it comes to the physics engine I am just another user, with no special insight. Physics is Austin’s domain, definitely not mine!)
One last comment about driver crashes: I try to be fair about the distinction between causation and correlation when it comes to driver bugs; the piece of software that “fixes” a bug may not be the piece of software that contains a bug, and work-arounds happen in both directions between drivers and apps.
Similarly, seeing “ATI” or “NVOGL” in your crash report does not imply a driver bug. It does imply that the crash happened in the driver, but the driver crash may be a proximate cause, while the ultimate cause may be in X-Plane. (Sometimes the stack crawl is also just plain wrong, depending on the severity of the crash.)
OpenGL drivers need to be very, very fast; the whole point of buying that shiny new GPU was to get faster framerates. So driver writers have to make trade-offs about how much error checking they do when an application passes in junk data. If I were writing a driver and debating an error check that would slow performance and prevent a crash of an application that passed illegal data (but not the machine), I might very well skip the error check and say “if the application doesn’t want to crash, it should pass better data.”
Of course, it’s not up to me, and it’s not always up to the driver writers; the OpenGL specification actually dictates what outcome are acceptable in various error conditions. Quite often, “program termination” (read: the application crashes but the machine does not) is an allowed response to certain kinds of bad data from the application to the driver, particularly where checking the data would slow performance for all applications and the application should know better.
My last blog post may have expressed some negative views toward software upgrades:
I know I’ll take some slack for this, but: why did you all go and grab an OS update so fast? What have you gained? The down-side is lost time and application compatibility problems…was it worth it?
That blog post was of course not my real opinion, but rather a recreation of the evil Ben. Always upgrade your software to the newest version whenever it comes out!
