I’m way behind on documentation, and there isn’t any documentation for this yet, but to clarify:
In the named lights list, spill (casting light on the ground and other stuff in HDR mode) and billboards (a square that faces the camera with a picture of the light from a light bulb) are always separate!
Typically the spill light has the same name as the billboard with an _sp suffix, or the billboard has _bb.
Why did we do it this way?
The lights are kept separate because:
- We do not have enough information from the billboards to know how to make a spill. For example, you have a v9 parameterized landing light billboard on your aircraft OBJ. How big (in meters) should the spill be? We don’t know! The billboard params never included enough information to know things like the size and cone ark for a spill light.
- There may not even be a 1:1 correspondence of spill to billboards. For example, any time there is a multi-lightbulb enclosure, it can be a win to use more billboards than spills; overlapping spills hurt fill rate.
Spills are therefore “opt-in” at the named light level; you opt in by adding a _sp variant.
Note that if you use Plane-Maker’s light level, you get spill for free; that interface is a higher level, simpler “I want this thing” type of interface. It only knows about the basic airplane light types, but it is fairly powerful. For example, you can create multiple landing lights (controlled by multiple switches), and you can use the “generic” lights for utility purposes, like inlet ice lights, leading edge lights, logo lights, etc.
If you haven’t run beta 3 and already been told so, X-Plane 10.10 beta 4 is out. Hopefully we have a beta stable enough for it to last more than 48 hours.
The ability to draw the inside of your Plane-Maker fuselage is going away. In X-Plane 10.10 beta 4 you will still see this geometry if your airplane uses it, but:
- There is no option to enable this in Plane-Maker anymore and
- If you save your airplane in Plane-Maker, the feature is turned off.
I’ve blogged about the path to removing a feature before; the basic idea is that we are not forcing you to update your airplane now, but the next time you go into Plane-Maker to do work on your plane, you will have to fix your use of interior geometry too.
If you really want your interior to look exactly like your exterior, but inside out, it’s not hard to get this effect:
- Export your airplane as OBJs from Plane-Maker.
- Open the fuselage in a 3-d editor and flip the faces.
- Attach your new “interior” in Plane-Maker.
Here’s the overall LR viewpoint on Plane-Maker and drawing:
- OBJs are the way to draw an airplane. OBJ provides all of X-Plane’s rendering features, really good performance, a stable file format, and good tools to edit.
- Visualization of the built-in Plane-Maker geometry is good for simple planes and experimentation, but it is not at all meant for serious graphic work.
- We will not be adding any of the new rendering features to Plane-Maker’s “built-in” drawing.
- We don’t think “I can’t draw X without an OBJ” is a problem; use an OBJ.
In other words, we’d rather focus our effort on a single drawing path, OBJ, and not invent a parallel, inferior second drawing system using Plane-Maker beyond what’s needed to simply say “there is my airplane.” Thus we are not adding new drawing features to the Plane-Maker geometry.
At this point the only thing holding up a public beta of 10.10 is, well, me. I am currently working on a set of related aircraft rendering bugs, and as soon as I can get the car off of jacks, we can go beta.
One of my goals or 10.10 is to close out the issues that stop payware authors from releasing final conversions of their aircraft to 10.10. By final, I mean conversions that won’t need any additional future editing. Right now X-Plane 10.05r1 has a few bugs that cause v10 to look different from v9, different depending on rendering settings, or just wrong. I want to fix those problems in a permanent manner so that authors can release aircraft and not worry about having to update.
Here are my goals for 10.10, roughly in priority order:
- Rendering should be consistent from X-Plane 10.10 onward through the rest of the v10 version run.
- Rendering should be consistent between HDR and non-HDR mode. Authors should not have to create two versions of textures where the HDR and non-HDRs offer the same capabilities. (In other words, while you might have to make two textures to bake lights when in non-HDR mode, you shouldn’t have to make two textures to correct for differences in color-correction between the two renderers.)
- Where possible, non-HDR mode should match X-Plane 9.
The switch of priority between item 2 and 3 is a fundamental change in priority from what I originally intended for X-Plane 10.
Originally I thought that the best thing to do would be to keep non-HDR rendering as close to v9 as possible, so that at least content would look correct with HDR off.
My new thinking for 10.10 is that we should aim for consistency between HDR and non-HDR modes. Realistically, an author is going to have to make at least a few adjustments in moving v9 content to v10; better to have the cost of rendering engine changes be borne out in a v9->v10 upgrade than to have every v10 airplane require double authoring to cope with HDR vs. non-HDR differences. In the long term, it’s best to not have v9 haunt v10 like a ghost years after authors are making exclusive v10 content.
Why is HDR Mode So Weird
This begs the question: why is HDR rendering so weird? Why does it look different from non-HDR rendering, and why doesn’t it look the same as v9? What did you guys do?
There are a number of changes to how we render in X-Plane 10, some specific to HDR rendering, and some sim-wide.
- The entire sim now works with a linear lighting equation. Basically when the sim performs lighting calculations on the GPU, it thinks in terms of photons and not colors, which produces more realistic results in most cases. With lots of light sources, linear lighting is absolutely necessary for combining those lights.
- The order of rendering operations is very different between HDR and non-HDR mode, and the formats that they render into (24-bit RGB vs. floating point, etc.) are very different. HDR is fundamentally a two-pass format.
X-Plane maintains two separate rendering paths for HDR vs. non-HDR and they are quite different in both what happens at each stage and when the stages occur.
Fixing some of the authoring bugs has required further changing the HDR pipeline to allow for correct rendering. The up-side of this change in pipeline is that the new one supports better HDR tone mapping and possibly even better fill rate performance. The down-side is that it’s a lot of complex code to touch and it may take a few betas to work out the bugs.
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
Plane-Maker Will Copy Your Instruments
You may know that in Plane-Maker, you make your own copies of X-Plane’s PNG files to customize the look of the instruments. But did you know that Plane-Maker will copy the images for you?
Select an instrument and type Control-P (which is the default for the command binding “pln/panel/copy_instrument_png”). Plane-Maker will copy all PNGs for that instrument into your aircraft’s cockpit or cockpit_3d folder. This can save you the time spent wading through X-Plane’s cockpit folder to find the right PNG files.
X-Plane Can Make a Panel Image for UV-Mapping
When you are making a 3-d cockpit, you use the 3-d panel as a texture. But how do you know how to UV-map this texture in your cockpit? Often the panel background (panel.png) is blank.
X-Plane can make a snapshot of your panel for you, in the exact size you need to UV map. Use Control-Alt-Shift-Space (Command-Option-Shift-Space for Mac nerds) to run the “sim/operation/make_panel_previews” command in X-Plane. It will make a PNG file in your aircraft called Panel_preview.png – it’s just like Panel.png but with the instruments drawn in – perfect for UV mapping.
Plane-Maker Will Tell You What’s Wrong
That sad face icon in top bar of the Plane-Maker panel editor enables “warning” mode. In warning mode, every instrument that has a potential problem gets a red outline. Select one instrument with a red outline and in the upper left corner of the panel you’ll see a description of what’s wrong.
This picture on the left is from Plane-Maker editing a 3-d panel. (That’s why it is just a “packed” set of instruments with no background; this panel is used as a texture for a 3-d cockpit – each instrument is UV-mapped into the right location.)
The air-speed indicator has been flagged as having a problem, and the text shows it. In this case, the lit texture has an alpha channel, which causes the lit texture to draw incorrectly. Fix the texture and the warning will go away.
I strongly recommend checking all Plane-Maker “red boxes” on your plane – most of the warnings will tell you about problems that would otherwise be very hard to detect.
A quick OpenGL note for plugin authors: if your plugin uses OpenGL to draw (e.g. for a plugin in an airplane that draws a custom glass display) you should:
- In debug mode: always check the OpenGL error state (using glGetError) at the end of each draw callback that you handle. X-Plane will not leave OpenGL errors around, so any error is yours. (To verify that it’s not another plugin, just add a glGetError at the beginning of the callback.)
- In release mode: never check the OpenGL error state, as it can slow down the driver.
An OpenGL error often implies that an OpenGL command did not complete as expected (because a param is bad, etc.) and this can mean that you are not cleaning up OpenGL state for X-Plane!
(And of course you should always use XPLMSetErrorCallback in debug mode to catch plugin errors. Set a break point in your callback to see exactly where the error occurred.)
A number of third party authors (bravely) promised X-Plane 10 updates to their airplanes. And I believe that a tune-up to be X-Plane 10 compatible isn’t going to represent a lot of man hours.
That is, unless you try to do this job now.
I have a number of open bugs where version 9 airplanes don’t load quite right in X-Plane 10. If you have an X-Plane 9 airplane and you try to work around these bugs, a few things will happen:
- You will only be able to work around some of the bugs, as others are pretty hard-baked into the sim.
- When I actually fix the bugs (in the next weeks) your airplane will be “broken” yet again, since “fixing” the bugs now means trying to make a right with two wrongs.
So third party authors: please do file bugs if you haven’t already, and give us a little time to work through them. Please do not try to work around these bugs, only to have your airplane become “re-broken” when we get the sim corrected.
And users: please be patient with your third party airplane authors. They can’t make their plane v10 compatible until we fix some bugs, and if they try they’re just going to get thrashed.
There are some things that do need to be reworked for version 10, particularly for HDR mode. But a lot of the reports I get are just things that are funky in the sim.
How to File an Airplane Bug
Since I am getting deluged with bug reports, support requests, questions, etc. I want to describe the best way to get an airplane compatibility bug to us. By following these guidelines, you’ll make it easier for us to kill off compatibility bugs fast.
- Please file the bug only once. If you have filed the bug and haven’t heard that it’s fixed, you do not need to tell us in every new beta that it is still broken.
- File bugs via http://dev.x-plane.com/support/bugreport.html. We can route this form to whomever we think is best suited to handle the bugs. Please do not just email the last person you conversed with directly.
- Please only file bugs if an airplane looks different in the latest X-Plane 10 build and X-Plane version 9.70. X-Plane 9.70 is the version 9 release that we are targeting – no older version!
- Please get us reproduction materials – preferably a complete ACF pack, and preferably a cut down one if it can be simplified.
- Send us the v9 .acf file, before any modifications. We want to see what your customers would have seen if they just tried to use the plane. If you send us a version resaved in X-Plane 10, we don’t know what happened.
- Please provide illustrations of how the plane should look in version 9 vs how it does look in version 10. We need a reference point.
- Please try to keep reproduction steps as short as possible. If we have to make a 2 hours flight with 400 waypoints to see a bug, that’s a time sink for us.
A number of you have already sent us good bug reports – we will get to them as quick as I can. If all goes well tonight my fires will be out and I’ll be able to jump into this shortly.
Simon and Chip have a whole series of posts reviewing the plane, with lots of nice pictures.
X-Plane 9 allows you to categorize objects as being on the plane’s outside, inside, or glass. X-Plane depends on these flags being right for a few things:
- The draw order of the airplane is determined by the object types – glass is drawn last to avoid translucency artifacts.
- Interior light from the plane is only spilled on the “inside” objects.
- Glass objects are excluded from shadow calculations to avoid having opaque windows in the airplane shadow.
It is important that you use these flags as intended; X-Plane 10 depends on this information as well, and X-Plane 10’s global spill and global shadowing algorithms are more sensitive to incorrect categorization of objects than X-Plane 9’s forward renderer.
In particular, you should have glass for the airplane windows in an attached object tagged as type ‘glass’; do not attach your glass to the cockpit object, which cannot be categorized as glass. If you have an old plane with glass in the cockpit, consider cutting the object in half in a 3-d editor and attaching the glass separately.
(You should also use our prop disc animation, rather than use an OBJ for prop discs; the OBJ format doesn’t contain the z-buffer tricks necessary to make the prop look right.)
For quite a while now, I have been advocating in favor of DDS compression. I am pretty damned obstinate, but eventually if enough people yell at me, I get a clue. I have come to appreciate that there are some cases where DDS compression is not a net win; this blog post explains when it happens and what we might do in X-Plane 10 to work around this.
DDS – The Good, The Bad, the Ugly
DDS is a file format that contains image data pre-mipmapped (that is, the smaller versions of the image that the video driver needs are included) in a format that may or may not be compressed. DDS is virtually always used with a compressed image format (like DXT1 or DXT5). This has three positive effects for X-Plane:
- Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
- Because small versions of the image (the “mipmap pyramid”) is already in the file, we save time down-sizing the image with the CPU, another win for load time.
- Because the image is compressed ahead of time, it can be compressed with a slow high quality compressor rather than a fast low quality compressor, so relative to other compressed images we get an image quality improvement.
The bad is that the DDS file does not contain the original uncompressed file. If the user unchecks “compress textures to save VRAM”, DDS files remain compressed. If the image file contains details that don’t compress well, they’re going to get splatted and stay splatted.
What If VRAM Grew On Trees?
My original heavy arguments for DDS were based on the idea that VRAM is a limited commodity; if we don’t compress textures, the user runs out of VRAM faster and has to go down a level of resolution…and once that happens, everything starts to look ugly.
But what if the user has 1 GB of VRAM? At this point, we’ve limited the maximum quality the user can see because we don’t have the original uncompressed image anymore, only the DDS/DXT version. This can be frustrating to authors who spent a lot of time on their textures.
If you ship PNGs with your airplane or scenery, turning off texture compression will reveal this beautiful, uncompressed image, but now when texture compression is on, the compression will be done by the video driver, and that will look extra ugly.
The Best Of Both Worlds
This is my thinking for version 10. (These are just musings, we haven’t coded this yet.) Currently DDS are preferred to PNG files. We could relax the load rules in version 10 to prefer PNG over DDS when texture compression is off and DDS over PNG when it is on. This would allow authors to ship both PNGs and DDS files and have the right one be picked for the scenario: the pre-compressed one when texture compression is on and the uncompressed one when compression is off.
Quick airplane links:
- Carenado’s Mooney M20 J is out, available on the X-Plane.org store.
- Javier’s T34c Mentor is out, available at X-Aviation.com.
Pictures available in both links.