Blog

Split Beziers Part 2: The X-Plane 860 Bug

In my previous blog post I defined a split vertex in an airport layout and described how they can be simulated in an apt.dat pile using multiple points.

Now that WED is in public beta and people can easily make split beziers, many have noticed the “split bezier” bug in X-Plane 860:

This is a vertex that is split…on the left you can see what it should look like – on the right you can see what it does look like. There are two problems going on:

  1. The taxiway lights have gone crazy at the split vertex. (This is what everyone sees.)
  2. The taxiway line is a bit jumbled at the split vertex too.

It should be noted that this bug will can also happen for any vertex (even unsplit) in rare occaisions due to interactions with the mesh. Same symptom, same buggy code, different cause.

The good news is:

  • There is a workaround that will make the lights look correct and the lines acceptable in X-Plane 8.60.
  • The workaround will be implemented inside WED – no need to change anything.
  • When X-Plane is fixed, it will make the lines correct too.

In my next post I’ll describe the fix and what the results look like.

Posted in Development, File Formats, Scenery, Tools by | Comments Off on Split Beziers Part 2: The X-Plane 860 Bug

Split Beziers Part 1: What’s a Split Bezier

(This blog entry explains the background of split beziers – the next parts will explain the bugs that they cause and the workarounds.)

In apt.dat terminology, a split vertex is any vertex of a polygon where the control handles on either side of the vertex are not exact mirror images. (When there is only one control handle it is therefore by definition split!)

You need a split bezier any time you want to:

  1. Have a sharp corner between two curves and control the tangents of the curves or
  2. Have a sharp corner between a truly straight segment and control the curve of the next segment.



Split Beziers and apt.adt

Now here’s the rub: the apt.dat format does not allow for split beziers – each curved point has only one control handle – the other is calculated by x-plane by mirroring…thus no vertex can ever be split.

(This is due to a total lack of brains on my part when working on the apt.dat format, which is quite embarrassing considering how long I spent thinking about it.)

The Hack

There is a way to simulate a split bezier: if you use zero-length segments (that is, multiple points on top of each other), you can create a shape that works as if it is split.

In its simplest, a split bezier can be created by using 3 vertices.

  1. The first vertex uses the control handle of one side.
  2. The second vertex is not curved.
  3. The third vertex uses the control handle of the other side.

Why does this work? Well, a bezier curve between a curved point and a straight point has zero length if the two points are on top of each other. So what we’ve done is inserted two zero-length segments. The result of this mess is that the control handles on either “side” of this cluster of points can be different!

Is the second point really necessary! Yes! The reason is this: if we simply had the first and third point (two bezier points with different control handles), X-Plane would draw a loop from the first to the second. Remember: two colocated points with ONE control handle form a zero-length curve, but two colocated points with TWO control handles form a loop.

(To see this for yourself, just draw some examples in WED or photoshop. 🙂

Line Continuity

There is one more wrinkle we have to add to the puzzle in order to understand how this works, and what the pitfalls are: line continuity.

A bezier path (taxiway edge, linear segments, etc.) is made up of one or more bezier curves. Each curve has zero or more attributes.

When X-Plane draws the actual taxi lines and lights, it looks for continuous adjacent bezier curves with the same attribute and makes sure the linkage between those attributes is correct.

(This linkage is computed separately for each type of property. So if you have taxiway lines on two segments and lights on one, the taxiway lines will still link!)

The picture above shows a correct vs. an incorrect link. When dealing with unsplit beziers and non-curved points, linkage is pretty much automatic, it just works.

But there is a pitfall to our above hack for split vertices: we have three points on top of each other. They must all have the same attributes in order for linkage to work. A “break” in the continuity of the line for one of the zero-length segments still counts as a break in linkage. The picture on the right was produced by creating a split bezier and removing the double-yellow-line attribute from the second of three vertices.

In my next post I’ll explain the bugs that this causes in X-Plane 8.60.

Posted in Development, File Formats, Scenery, Tools by | Comments Off on Split Beziers Part 1: What’s a Split Bezier

Another Confession – Exclusion Zones

An overlay DSF can define exclusion zones – rectangles where scenery from lower priority DSFs is not shown. Exclusion zones are organized by entity type – that is, you must make a separate exclusion zone for objects vs. forests.

The problem with exclusion zones in X-Plane 860 is that the implementation of exclusion zones isn’t quite right for lines and areas.

Essentially any element of a DSF is zero, one or two dimensional:
0d – Points (objects, very small facade objects).
1d – Lines (beaches, roads, large facades with no roofs, bezier lines and bezier object chains).
2d – Areas (large facades with roofs, bezier pavement, forests)

The problem is that X-Plane eliminates any entity if and only if one or more of its vertices intersects an exclusion zone.

This can be wrong in two ways:
– If an entity intersects the exclusion zone, it is deleted entirely, rather than having the exclusion zone subtracted.
– If an entity surrounds or goes through an exclusion zone without a vertex being in the zone, it is left alone.

Posted in Development by | Comments Off on Another Confession – Exclusion Zones

So Why Doesn’t X-Plane Look Like This?

Every now and then someone sends us this:

//www.xtremesystems.org/forums/showthread.php?t=117500

The question is of course, why doesn’t X-Plane look like that yet?

Now there’s a lot of reasons why flight simulators don’t look like first person shooters…you can definitely optimize any game content for a specific viewpoint — X-Plane’s lack of constraints on the camera position (you can put the camera quite literally ANYWHERE on the Earth at any time of day, atmospheric condition, and orientation) means that there are going to be views that don’t look so hot. And the global scope of X-Plane means that we have to focus on quantity to a certain extent over quality. (If we made KSBD look totally awesome and didn’t ship any state but California in global scenery, where would we be.)

I’ve been working lately on pixel shaders and lighting…when you look at those shots, the total integration of a number of great lighting effects is responsible for a lot of the look. But…I think there’s a more fundamental issue that pixel shaders and carefully made content wouldn’t address.

Simply put, X-Plane’s LOD system isn’t scalable enough.

In order to get images that look that good you need to put a huge amount of detail up close near the camera, where the user can see it, but not put that detail in the background. (Imagine if every tree in those scenes was done in the detail of the foreground – the polygon count would be unmanageable.)

But X-Plane’s scenery SDK (the interface by which scenery content is specified to X-Plane, in other words, “the file formats”) lacks really strong LOD capabilities.

  • The terrain mesh is fixed – you can use LOD to eliminate overlay details, but you can’t actually simplify terrain.
  • The cost of LOD in objects is high enough to prohibit really gradual LOD. No morphing is provided.
  • Textures are mipmapped but loading is not variable, so our VRAM budget doesn’t benefit from LOD and locality of textures in X-Plane space.
  • Generated geometry (roads, trees, etc.) don’t have any LOD except “eliminate whole feature”.
  • There is no far view of 3-d clouds.
  • Airport layouts are tessolated at only one complexity.

I could go on and on…the bottom line is, X-Plane’s rendering model is very static.

Why did we do that? Well, it seemed like a good idea at the time. In particular, recalculating LOD is very expensive on the CPU and at the time we had only one core. Recalculating LOD would cost more in lost fps than it would benefit in offloading the GPU. So we went for static meshes that we could blast out to the card “real fast”.

What you might not know about those screenshots is what kind of hardware it’s running on:

//www.gameklip.com/v/1606/

Yep…four cores, and overclocked by over a ghz. (I can only speculate that shortly after the clip ends the machine caught on fire. 🙂 In a multicore environment we can apply additional CPU resources to dynamically rebuild the environment to increase the “LOD range” (difference between the near and far view).

In fact, we already started to do that! In X-Plane 830 we modified the sim to build 3-d content (roads, forests, etc.) on a second core while flying, instantiating only the close ones. This saved RAM and improved the overall performance of the sim, and it increases our LOD range.

(Even if something isn’t drawn, it has a cost just to exist – by saying that things that are really far away don’t even exist we improve performance.)

As you can see from the above list, there’s still a lot to do on the LOD front. But the scenery system is continually growing – new features for the various primitives and improvements to the engine will let us continue to improve sim efficiency.

Posted in Development, File Formats, Scenery by | Comments Off on So Why Doesn’t X-Plane Look Like This?

That’s one biiiiig polygon

Something I’m seeing now that WED is in beta: airport layouts with the entire taxiway structure made from one really complex polygon.

I’m not really sure if this is a good idea. First the potential problems:

  • I suspect that the creation of the taxiway layouts can get slow when the number of sides in the airport layout is really huge and there are holes. I don’t know this for a fact because we let the OpenGL libraries do the heavy lifting. Because this loading is done on a second CPU, it might not be noticeable to all users.
  • The pavement can have only one texture direction per polygon, so multiple polygons may be necessary.
  • Certainly in WED having a few large complex polygons slows down editing — if all else is equal, the tools work better with smaller polygons.

Now…overlapping pavement is generally bad (that is, there is a performance cost), but more sides are also expensive. More thoughts:

  • The more square feet of overlap, the worse. So a small overlapping intersection is not so bad, but avoid layering a huge polygon on top of another huge polygon, which just strains the video card.
  • Fewer segments are better. Consider two crossing taxiways…8 segments with overlap, but 12 by making a plus.
  • But wait – the above example is misleading…if you need to change the light types so the blue taxiway lights don’t cross the intersection then you’ll need to add 4 more segments, so now it’s 12 and 12 – a wash. (In this case, having one big polygon is probably easier to manage.)

And for performance…

  • Try going to your layout from far away and watch the last step of loading…if it starts to take a long time to “preload” things it means your layout might be a bit complex.
  • Do not expect X-Plane to become faster at loading airport layouts…the limiting factors are proportional to complexity, so if you have a killer polygon now it’ll be pretty expensive later too.

One other note, from a conversation with Tom…WED splits vertices into a fixed number of segments (per zoom level) so splitting a bezier makes it smoother. X-Plane does not! X-Plane splits beziers based on the overall curvature, so adding more nodes without changing the shape has no effect.

So please do not try to use the split command to make X-Plane “smoother”. We’ll provide a rendering setting for this some day. The current value was chosen because anything smaller looks awful and you have to make it a lot bigger (read: a lot slower fps) to get an even marginal visual improvement.

Posted in Development, File Formats, Scenery, Tools by | Comments Off on That’s one biiiiig polygon

Scenery Tools and Compatibility

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.

Posted in File Formats, Scenery, Tools by | Comments Off on Scenery Tools and Compatibility

WED Lives!!

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.

Posted in Scenery, Tools by | 7 Comments

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.

Posted in Tools by | 2 Comments

Don’t Change lights.txt

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.)

Posted in Development, File Formats, Scenery by | 1 Comment

Liveries Part III: Image Contracts

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.

Posted in File Formats, Scenery by | Comments Off on Liveries Part III: Image Contracts