In my previous post I mentioned that the scenery tools are separate code with a separate release schedule from X-Plane. This implies that the updates to the tool won’t be in sync with X-Plane. (The same thing is already true for the AC3D plugin and all of the wonderful third party tools that people have written.)
X-Plane’s scenery compatibility strategy is “backward but not forward”. In other words, if you open old scenery with a new X-Plane and it won’t open or looks different, that’s a bug (please tell us). You should never have to modify your OBJs or scenery if they are correctly made, and the definition of “correctly made” shouldn’t get more strict over time.*
Why no forward compatibility? Well, it’s possible to have syntactic forward compatibility (have X-Plane read a file it doesn’t understand because at the time of release the spec didn’t exist) but it’s not possible to have X-Plane display that file with any kind of sanity.
You could say “just leave out stuff you don’t understand”. Well, imagine if we had done that with apt.dat — imagine if X-Plane 840 tried to display an 850 apt.dat by simply skipping what it didn’t understand. Since taxiways are fully replaced with a new code, 850 layouts would have no taxiways at all if shown in 840. This is certainly unacceptable.
The only way around this would be to require all new features to have “fallback” content, e.g. have the file contain two copies of all taxiways. Since the structure of 850 and 810 taxiways are so different, this would basically require the author to do twice as much work…similar problems happen for animation commands, and missing datarefs.
So the content has to be older than the sim. What about tools?
Well, first, I don’t write the tools with forward compatibility. Since they are all free a user can easily get the newest tools to work (in a sane manner) with new content.
The tools do have to support old file formats though – we don’t usually post old copies of the tools (the AC3D plugin is an exception, since old versions work with old host copies of AC3D). Instead the tools are designed to support restricted file formats. For example, the AC3D plugin will export to OBJ7 or OBJ8 – authors targetting X-Plane 7 can export to OBJ7.
WED only exports apt.dat 850 files – this is by design from day 1, and it will not ever be an apt.dat 810 editor. (Use TaxiDraw if you need to do this.) However, as new X-Plane features emerge (and I am sure they will), WED will have options to target future X-Plane versions, or restrict the export to only features supported by older versions, perhaps with a warning if the WED document contains features that will be lost in an old export.
* One problem we have with this is: X-Plane isn’t a strict validator of scenery file formats, so it is possible to have mistakes in scenery that were always illegal by definition of the file format, but X-Plane doesn’t notice at first. When I detect a case like this, I try to make the problem a “warning” rather than have X-Plane quit, so that authors can get information on buggy files without users suffering too much. X-Plane will print only one warning per package per scenery load to keep things streamlined.
WED went public beta yesterday. You can find it under the tools section of the X-Plane scenery web page.
I want to say thanks to the users who helped me with the alpha testing of WED. These users tested new builds quickly, wrote up great bug reports, and put a lot of effort into using WED at a time when it was really no fun to use.* Thanks guys!!
To reiterate a few points about WED:
- WED 1.0 edits only apt.dat files, not DSFs or DSF overlays. WED will be the platform for additional editing features, but for now it only edits apt.dat files, and it will be like this for a while.
- WED is still in beta, so use caution! Save backups, save often! Save earth.wed files and export to apt.dat for extra safety.
- WED is free and open-source. It is not distributed with X-Plane, and you don’t need to buy X-Plane to use WED.
Enjoy!
* Remember, “alpha” software means “we can test all functions, but they could all be broken”, while beta means “we think there are no bugs that would cause data loss or crashes”. So…while WED was alpha, it tended to crash or trash files, so the alpha testers couldn’t get any real work done.
It’s that time of year – I will be away from all forms of technology next week, enjoying cool mountain air and not having email. When I return I will post an udpate on the status of WED.
Posted in Tools
by
Ben Supnik |
Some very advanced users have asked: can we change lights.txt. The answer is: please don’t.
Lights.txt is not a part of the “scenery SDK”, that is, it’s not a file whose format we will keep the same and allow you to modify. (The fact that it isn’t accessible via the library system is an indication of our intention NOT to make it part of the scenery system.)
The problem is basically this: lights.txt translates named lights into the inputs to our pixel shaders for the hardware-accelerated lights. That pixel shader is really new and likely to change a few times. If the shader changes, we might need new parameters not in lights.txt, requiring a fundamental format change.
For example: those who have poked in the named lights file have noticed that the hardware lights can either have directional or flashing properties. This is because they run on two different shaders, each taking only four input values. This was done a while ago, when we were using low level assembly language shaders. In the future we might merge the two shaders and have 8 params per light. This would give us more flexibility (directional flashing lights), more bus usage (pushing 8 params per light instead of 4) and fewer state changes (we have to change shaders right now).
My point is: we can’t predict what will happen, so we can’t safely expose these parameters. The best thing to do is: email me and request named light types. We can easily have hundreds of named-light types (see how many there already are just for airports!).
Named lights make our lives easier because it tells us WHAT to draw but not HOW to draw it. So when we put in the next evolution of the lights code, we can remap the named lights to look the best they can for the new technology, instead of worrying about how to map the old params to the new ones.
(I appreciate the input from the users who emailed me about this — it gives me more insight into what extensions to the scenery system would be useful.)
The livery system I described in my previous blog entry (proposed independently by several users) would imply a contract between the aircarft creator and livery creator. The way I look at it:
- The livery creator agrees to utilize the texture conventions established by the aircraft modeler.
- The aircraft modeler recognizes that changes in the fundamental texturing scheme of the airplane become much more “expensive” because they potentially invalidate a whole set of liveries.
This is an exceptional situation in X-Plane…we have avoided contracts regarding the layout of images in all previous cases. (Examples: you can’t use the library to replace an OBJ’s texture. You specify terrain via a text file that references the image file, not the image file itself, so information on how to use the texture isn’t part of the contract.)
But in the case of liveries, I think the exception is the inevitable outcome – a livery quite literally is a repainting of an aircraft, and the X-Plane community has been living with the limits of this kind of add-on for a while.
What this means is that it would be appropriate to override object textures in a livery system, but this feature is unlikely to appear anywhere else in the sim.
Any time two independently varying components need to interoperate, a contract is required.
Because X-Plane varies independently of third party add-ons (we release patches, you make new add-ons), any extensible part of X-Plane implies a contract. That contract basically says what legal things the add-on can do and how X-Plane will react.
We have to consider this “contract” with third party add-ons any time we modify the sim, and in some cases it means we can’t change things. How this applies to liveries will become clear later.
Libraries and PNGs
There was some discussion on X-Plane.org about whether it should be possible to share and/or override PNGs via the library system independent of their objects. I say “no” for this reason:
The library system connects independent third party add-ons, that is, components that vary separately. Therefore there needs to be a “contract” any time the library is used, between the package requesting something from the library, and the package fulfilling it.
My concern with PNGs is that a library PNG would have to have a fixed layout. But realistically the kinds of PNGs that people want to share get reorganized on a regular basis. In particular, people want to reference the default sceney PNGs. But where we have a contract, we are limited in what we can change, and reorganizing the default scenery is critical to our ability to grow our content. I agree with Aussie’s comments on x-plane.org that fixed-layout PNGs don’t add a lot of value to the library system.
File System Vs. Text Files
There are a number of design trends in all of X-Plane’s third party add-on systems. One is the use of the file system to specify modifications to the sim. For example:
- Put a “cockpit” folder in your aircraft, we’ll try it first.
- Some files in the aircraft folder must have certain names.
- Sometimes putting _LIT after a texture causes it to be used as a lighting map.
On the other hand, I’ve gone a very different route with the scenery system:
- Libraries are looked up via a text file, not via filename.
- In all scenery cases, the lit texture is specified in a text file, not by filename.
What’s the difference? Well, the file system way seems to be simpler for most users to understand. The text file mechanism is a lot more flexible. (Consider: we have versioning info in a text file, we can have each line in the text file clearly identify a feature, and so there is no risk of a file name being mistaken for a feature.)
Whether we use file names or text files to control extensions, doing so creates a contract, so we must ask: can we easily extend or safely modify the contract later? Can we express what we want using filenames (or text files)?
In the case of the scenery system, I think we need the full expressiveness of text files. Imagine if we wanted to provide a new kind of lighting that uses a different format of texture. Or a way to control at what time of day the lights get turned on? Or what if we want seasonal varying textures, and the rules for how seasons affect the light map aren’t simple? In all of these cases, a file name convention rapidly becomes unworkable.
On the other hand, the airplane system has done reasonably well with filenames. Based on what I see, the problems with airplane distribution mostly come from a lack of features (no livery support, no plugins built into airplanes), not file names as a convention running out of flexibility.
Austin and I were running some numbers on the KSBD demo area DSF as part of a discussion of how instancing will someday allow X-Plane to render more objects. (Instancing is the ability to render multiple simple objects with a single instruction to the GPU…the requirement of one command to the GPU per object means that total object count is bottlenecked by the CPU->GPU connection.)
Here’s some numbers:
KSBD contains 868,220 mesh vertices – at 32 bytes per vertex, we have about 27 MB of geometry per DSF. In one view we picked, about 20% of those vertices were on screen. (But since there are six DSFs loaded, really only about 3% of a DSF mesh is seen at one time at lower altitudes.)
KSBD contains 153,816 objects. Near the airport, we average about 238 vertices per object. (This is a GOOD number – less than 100 vertices would imply that we aren’t sending out enough vertices for each command to draw.) But this means that if we were to simply store all of the objects as one huge object, we would have 1.1 GB of object memory! This is why you can’t just make a single huge object for the world. 🙂
(X-Plane of course stores each OBJ file once, saving a lot of memory. But then we burn CPU power telling each OBJ to be drawn over and over in many places.)
It also explains why forests keep causing people to run out of memory. Consider that only about 3% of the mesh may be visible (when we’re at lower altitudes, where you can see the trees). This means that we need about 30x as much memory to storage geometry as the card can draw. With cards so fast, we easily run out of memory before we max the card out.
Sergio sent me a scenery package with the question: why don’t these two textures appear as the same color in X-Plane (they did in Photoshop). The answer is: gamma correction.
Some background (with much hand-waving): gamma refers to how bright the mid-tones of an image appear. (It’s a lot more complex than that, but that’s what Wikipedia is for!) Basically Macs and some other computers adjust the colors in an image to compensate for the deficiencies of CRTs, while PCs leave them alone. The result is that the same numeric color levels, when sent to Mac and PC hardware, result in brighter images on the Mac than the PC.
Since X-Plane is authored almost entirely on the Mac, the old complaint (around the time of X-Plane 6, with BMPs) was that X-Plane looked too dark on Windows. PNG addresses this issue: the gamma curve of the system an image was created on can be written into the PNG, allowing X-Plane to adjust the colors (making them brighter or darker) depending on what destination system we are running on.
Unfortunately, X-Plane isn’t too brilliant about this, in two ways, one of which isn’t our fault:
- X-Plane assumes the platform default gamma for both Mac and PC (that would be 1.8 for Mac and 2.2 for PC). If you read that background article, you know that this isn’t real clever of us. But it actually is better than doing nothing at all.
- Gamma in PNG files is optional; if we get a PNG file with no gamma information, we make the rather arbitrary assumption that it came from a Mac. Since X-Plane used to be authored on Macs, this seemed like a reasonable thing and in the case of no gamma information, we’re going to be wrong half of the time no matter what.
If you open up the default scenery PNG files in Preview, you can see the gamma inforation – 0.4545. This is 1/2.2, meaning the files are encoded to PC gamma standards. It turns out that one of the textures Sergio sent me had no gamma information, so X-Plane assumed Mac gamma (0.5555, or 1/1.8). Thus the brightness of these textures were being adjusted by different amounts.
My recommendation to authors is simple: make sure that all of your PNG files always have gamma values written into them. Otherwise there is a risk that the default gamma guess that X-Plane makes will not be the one you authored under, causing color shifts.
Ari asked a good question regarding sloped runways and the new apt.dat 850 format:
Am I understanding it right that airport taxiways, ramps and runways are from now on going to be merged into one big mesh, instead of bunch of rectangle pieces overlapping each other? If yes, will this finally allow us turning on sloped runways option in X-Plane without any of the current side effects?
This brings up some interesting questions. First the most basic answer:
- apt.dat 850 prrovides curves, irregular taxiway shapes, which will allow you to create complex taxiway shapes with only one piece of pavement, rather than many overlapping ones.
- X-Plane still honors the order of apt.dat 850 for drawing, so you can also overlap and get visually consistent results.
- We recommend using a smaller number of curved taxiways rather than many overlapping rectangular ones because X-Plane can handles this case more efficiently. It is not necessary to build the entire airport out of one taxiway though.
Now the second part of the second of this question is a little more complex, because the cause of bumps in the scenery changed.
Bumpy Runways in the Good Old Days
Back in X-Plane 806 there was a fundamental problem with the way we did sloped runways that made them virtually unusable: while the corners of each rectangular piece of pavement would sit directly on the terrain (no matter what the terrain’s slope), the area of the taixway was formed by a flat plane. This means that the middle of the taxiway might be above or below the terrain.
Now the real problem comes when we have two taxiways that overlap. Because they are only aligned to the terrain at their corners and not centers, there may be differences in their height when one taxiway’s corner hits another taxiway’s center (which happens a lot). As the airplane travels from one taxiway to another, the elevation of the ground changes instantly, inducing a major jolt to the suspension. At high speeds these damage the airplane’s suspension.
Bumpy Runways Now
In X-Plane 850, we break all runways and taxiways (new and old) into multiple pieces each tiem the terrain underneath them has an edge. The resulting taxiways are then aligned to the mesh at their corners. But since no taxiway center goes over a mesh corner, the taxiway “hugs” the mesh perfectly. And since all taxiways hug the mesh in the same way, there is never a height gap between taxiways.
It’s the Mesh, Stupid
So why do we still have bumps in X-Plane 850 if we so carefully make sure the taxiways exactly reflect the mesh height? Well, you’re effectively driving on the terrain, so any bumps are ones from the terrain. Simply put, even with the new system the usability of sloped runways is only as good as the underlying terrain.
Now our meshes come from SRTM data, which is radar data – it naturally has a certain level of noise and “speckle” which makes it pretty unusable for airports…airplanes are very sensitive to even small bumps during takeoff.
We attempt to “condition” the elevation data for airport use, smoothing out hills and bumps. Unfortunately our algorithm doesn’t always work right. The X-Plane 8 US scenery was way too bumpy to be usable. The 7-DVD set is better, but still makes bumpy airports in a few cases:
- If there was no airport in the apt.dat file at the time of scenery creation, no conditioning was applied, and the underlying terrain is probably inappropriate for draping.
- The scenery creator has a bug that causes airport flattening to fail when it’s very close to water. For example, the big bump in the runway at KLGA is due to a water-airport interaction.
- I think that flattening across DSF tiles can have problems too.
If you’ve been thinking — wow, the diagram for 850 has a lot more triangles (10 vs 4) than the one for 806, you are right. Fortunately, the number of triangles, all part of one taxiway, in an airport layout, doesn’t really affect frame-rate, since this is handled by the GPU.
But this is also a case where a few curved polygons can be much more efficient than several overlapping ones – when we cut up the taxiway based on the mesh, if there is ovelapping pavement, each overlapping taxiway must be cut, multiplying the effects of the mesh on triangle count.
It also turns out that in the real case this is somewhat moot: because X-Plane smooths the airports and then induces triangle borders around the edge of the airport. Since the interior area is so flat, it doesn’t require a lot of triangles, and therefore the trianglse inside an airport tend to be big, so the number of times we have to cut an actual layout is quite small.
Mighty Mighty Bostones? Anyone? Nevermind. Anyway…
…some pictures of WED. (These were taken on a Macintosh, but it looks almost the same on Windows except for the title bars of the windows.)
This is the startup window. WED can edit multiple scenery packages (in multiple windows) but does not let you edit a scenery package until you create and name it. So we show this window when you startup to let you choose between a new or existing project.
The left side is the map view, which provides draggable editing of any part of an apt.dat file. This is part of Aussie’s KSBD layout, which is part of the X-Plane demo. The right side provides a hiearchy-structure view (top) and more detailed editing or properties (bottom).
With the vertex tool, we can drag control handles for any selected entity.
The map view is a “structural” view, not a photorealistic one. The markings on the lines and pavement color change to reflect the settings you pick, but WED does not attempt to reproduce the final result in X-Plane.
Wiht the marquee tool, we get a rectangular edit box around the selection and can thus resize or move whole sets of entities at once.
This is KBOS from 860 imported into WED. WED will import 810 or 850 layouts, but only exports 850 layouts. (It can thus be used as a simple converter.) That background image is automatically downloaded from terraserver and updated as you zoom and scroll the map. Unfortunately terraserver only covers the US; where there is no coverage you can import any BMP, PNG, JPEG or TIFF file and set it as a background image.
Posted in Tools
by
Ben Supnik |
