Going AWOL
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.
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.
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:
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:
On the other hand, I’ve gone a very different route with the scenery system:
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:
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:
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 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.
Since before I’ve been involved in X-Plane, scenery has been broken into tiles. You know the naming scheme…+42-072.XXX is some kind of file for Boston. Perhaps it’s a .env or a .dsf, but what is unchanged is that the world is broken up into bite-sized pieces.
Tiling is very necessary for X-Plane…it allows the sim to rapidly load only the information we are interested in. The world is too big to go fishing for the relatively small amount of data that is loaded at one time.
The source data that is used to build global scenery is also tiled – if you look at the SRTM files, they often have names like N42W072. It’s no surprise that global data requires tiling to make it manageable.
When we produce global scenery, we work on a per-tile basis. We load the raw tiled data* into source XES files (one per tile), then process and convert that XES file into a DSF. By working one tile at a time, we limit how much RAM we need.
But if you used WorldMaker on an airport or city that spanned a tile boundary, you know how annoying tiling can be. With WorldMaker you couldn’t see both halves of an airport at once.
WED will not use tiles. For custom scenery packages, the total data is not so large that we have to tile. When you work on a scenery package in WED, you work on the entire package at once as a single seamless workspace. When you export your work, WED will split the data into tiles as needed. This will mean:
I just finished fixing some bugs in WED regarding the hierarchy view. (To get a sense of what a hierarchy view is like, try AC3D…)
In WED, the contents of your airport layout are viewed in a hierarchy view. This is where you reorder your runways and rename entities. You can also group entities (as many times as you want) to help organize your layouts. (The groups will not be visible in the final apt.dat.)
An airport is, in a way, sort of a super-group…it’s a group of “stuff” (runways, taxiways, etc.) plus it has its own information.
But this leads to some tricky situations:
The result is that there are a number of grouping and drag & drop combinations in the hierarchy that are simply illegal. Cris and I debated this a bit and what we have now is: commands that would produce illegal results simply cannot be executed. (That is, the group command is grayed out if the new group would violate these rules, and the drag & drop won’t show a legal drop if the new order would violate these rules.)
Once we get into beta we’ll see how well this works. The alternatives include:
Also, I am sure there are some illegal configurations I have missed…we’ll have to catch those in beta too.