With X-Plane 820 global scenery, you can fly with “sloped runways” (this option drapes the runways like a piece of cloth over the terrain no matter how strange the terrain is) at most locations, but not La Guardia, where there is a huge hump in the runway.
It turns out the problem with KLGA is that there are vertices in the mesh that are adjacent to both water and the airport. The field height is a few meters above sea level, so we cannot decide what height those vertices should be? (Zero for the water, or a few meters for the airport?) In the 820 global scenery, the water wins, pullling down any part of the airport that is coastal.
For the version 9 re-render of the global scenery I am trying to fix this by creating a buffer zone of a few meters around coastal parts of the airport. This assures that we will have at least TWO vertices at the corners of the airport. The inner one can then be at field level and the outer one at sea level. The triangles in between these two “rings” form a sloped transition area (more sloped if the airport is far above water level), allowing the inner area to remain flat.
We’ll have to see how much this helps coastal airports – in hindsight I’m surprised that a lot more airports weren’t as unmanageable as KLGA.
(As a side note, it appears that the SRTM raw elevation data is at its least reliable in airports – there’s something about them, perhaps the metal or concrete or heat that causes a ton of drop-outs and false reflections. So we have to pre-process the airport areas pretty heavily to use them at all – and sometimes this pre-processing doesn’t even work)
For this blog entry I will try to show how to put together taxiway segments to avoid WED problems.
Here we have a 3-way junction, that is, one taxiway ending with another. First, what not to do:
First we have an overlapped solution. This is not good because overlap is wasteful of graphics card power. We also have the problem that the edge markings will overlap. So in the second and third picture, we “cut away” the horizontal taxiway markings by adding vertices. (In picture two we have overlap, in picture 3 we try to end the taxiway right at the intersection.)
The problem with technique two is: we still have overlap (and imprecise markings). The problem with picure three is that we can’t guarantee that the vertices of the vertical taxiway are exactly “on top of” the horizontal taxiway edge. So you may get something in X-Plane that looks more like this:
(Gap exagerated for clarity.) This is a “slivering” problem. The solution is one that is both efficient and nice looking:
In this situation, I have inserted two vertices in the edge of the horizontal taxiway and then used “snap to vertex” to assure that the corners of the vertical taxiway are exactly the same as the “cut points” in the horizontal one. This gives me a connection that will look clean in x-plane with no cracks or slivering and no overlap. My lines also end at just the right places.
(Hint: once you do this, to move all of the overlapped vertices at once, select them all with the marquee tool and drag.)
Another issue I see sometimes with WED layouts is how to draw the “fillets”, or curved taxiways that touch runways. Because the lines are not as smooth in x-plane as WED, often users are surprised when the approximations of the bezier curves cause an overlap and theere is no pavement.
Note that we’re stuck – we can’t use the technique described above because we can’t insert vertices into the runway. So we have to overlap. Less overlap is better – the overlap here is exaggerated to make things clear.
In this curve, we have a control handle only on the bottom vertex. It will overlap as soon as the control handle reaches the other side of the top line. By pulling the control handle down, we restore the curve.
Here we have two control handles – now it is a question of whether the top control handle crosses the top of the taxiway.
Here is one solution – at the expense of more overlap we can simply give ourselves some breathing room with our bezier curve. However, my preference would be to try to keep the control handles below the taxiway top by a wide margin.
I don’t actually know all of the best ways to make an apt.dat file. The format is new and we haven’t had a ton of time to performance test it. But here are some thoughts:
- One thing I know is…it is best to describe the shape you are using with the fewest number of nodes possible. In other words, let bezier curves do their thing, don’t add a ton of vertices to them. And please don’t add vertices to try to make the curves smoother. The best thing is to leave the layout simple and let X-Plane render it. In the future we will allow the user to set the level of smoothness based on his or her hardware. Adding more nodes will hurt quality – we will be able to pick better nodes at runtime than you can in the apt.dat file.
- Avoid overlapping large areas of pavement. Overlap is bad – it hurts framerate by requiring the graphics card to draw the same pixels over and over. As X-Plane supports more advanced shaders for nicer lighting, this cost will be a lot heavier on users.
- Ignoring overlap, the question of whether to have several smaller chunks of pavement vs. one large one is a difficult question. I would suggest moderation – try not to make too many individual pavement elements, but don’t make the entire element one giant pavement either. You may have to experiment to find the best framerate.
I posted previously in my blog that we use airport boundaries to flatten airports when we make the DSFs, as well as place airport grass. Let me clarify this a bit: there are two stages of flattening that we do.
- The flattening in the DSF is a “soft” flattening – we do not completely flatten the area, but rather we try to remove high frequency spikes in the elevation data, so that the airport maintains its overall shape without being unusable. This flattening process is very precise in that it only happens inside the airport area. Because we decide the mesh when making the DSF, we can shape the mesh to flatten only the airport area.
- If flattening in the sim is enabled, we then do a “hard” flatten of an area including the airport and some surrounding area. This flatten is truly flat and destroys any topography for the airport and a lot of surrounding terrain. Because the mesh is already defined, X-Plane is limited in its choices of where it can choose to flatten or not flatten.
Now that first soft flattening is what we use the airport boundary for. In X-Plane 800 the US DSF flattening worked very poorly. For the 820 flattening it worked well for most cases, but had some very specific bugs. (Typically the confluence of water, airport, and/or a DSF tile in close proximity would cause the three different processors for water, airport, and boundaries to come into conflict.)
I am going to try to further improve the flattening algorithm for the v9 render, with the hope of fixing some of the buggy cases from the 820 render. I am sure there will still be some broken cases – with 14,000+ DSF tiles, one of them is bound to be weird…but my hope is that with each re-render we can get closer to a render where users can run with sloped runways enabled and enjoy realistic non-flat runways.
When we make the global scenery, we pre-process the terrain to make flat grassy areas for the airports, using the latest apt.dat data. We will be recutting the scenery again soon for version 9, so if you have a favorite airport that isn’t flat and grassy in v8, you can submit a layout to Robin Peel – notes here.
I do not know exactly when we will be rendering the scenery, so I don’t know how long you have to submit a layout. I can’t make a promise that “if you submit a layout by X it will be in the scenery” – something can always come up that requires us to not use the layout (especially now that we have apt.dat 850 and layouts can contain all sorts of strange things). So I can only say: please consider submitting your layout soon. If it’s only partly done, finish the boundary and submit it to Robin with a note “this is only for global scenery” – you can always finish it and submit again later.
I don’t like it when overlay scenery depends on the underlying base mesh…I’ve been telling authors for a while now on the lists, “don’t assume the base mesh is the global scenery”, and while this actually has been a safe assumption for version 8, I suspect that once we get v9 out the door I’ll have some time to write mesh-editing tools, at which point the user will have a choice of base meshes.
Roads are currently built in MSL space (that is, absolute elevation on the planet) and thus don’t change when the base mesh changes. In a previous post I discussed the idea of having them be AGL based (draped) so that they would “hug” whatever base mesh you have.
First I should say: this isn’t coming any time soon and won’t be in 9.0. But also, upon closer examination, there are a number of ugly issues just below the surface. Consider all of the things that the global-scenery generator does with roads:
- Road type is selected not only from source road data, but from surrounding conditions, some of which are not obviously determined by the final DSF.
- Road bridging is determined based on nearby roads, water, gradient constraints, and available bridge templates.
- Road type is further influenced by bridging considerations.
- Roads are smoothed to try to build the most even access, “hiding” rapid changes in underlying terrain from a high-speed roadway.
- Powerline tower locations are picked from terrain peak to peak with constrained maximum lengths. (The individual segments also controls the span of wires, so introducing new nodes in the draping process might be undesirable.)
The problem therefore with a draped road is that the decision to bridge (both how high and what kind) are dependent on the underlying terrain.
The eventual solution would be to do all of the road processing in X-Plane while draping – but this implies that the author of a custom road grid doesn’t actually have control over how the roads come out. One advantage of the current system is that total control over the roads is provided in the DSF – given appropriate tools, a modeler could very carefully hand-craft the roads with a lot of detail.
X-Plane 9 will feature key-framed animation for the rotation and translation animations (but not the show-hide animations). Basically:
- You can have more than two key frames.
- Interpolation between them is linear.
- Extrapolation off the ends is linear (use two equal-value key frames to clamp).
Key frames will be available for all OBJs: scenery, cockpit and aircraft parts. I will try to post a spec soon – the implementation is very similar to the RFC I posted a while ago.
(If you read the .tcl code in the AC3D plugin, you may have guessed that this was coming.)
Trigger
Now I know somebody is going to ask me: “will this allow me to make an animation X start when event Y happens in the sim?” The answer is: no! Key frames allow you to map the relationship between an input dataref and your geometry in any way you want. But if the input dataref is not changing, the output position cannot change either.
Example: you can use key frames to make complex things happen as the gear deploys. Gear deployment is a ratio that starts at 0 and slowly changes to 1 as the gear deploys (over the cycle time as set in PlaneMaker). So you can use this to make the wheels move forward first, then down.
But you cannot use key frames in the cockpit to make the gear handle move slowly. The gear handle dataref is really a switch – it instantly changes from 0 to 1. If you set up a nice key framed animation, we will instantly jump from the animation position at 0 to the animation position at 1.
In other words, whether or not you have key frames, the timing of an animation comes from datarefs, and datarefs alone. I am not planning any extensions to the OBJ system any time soon that will let you trigger animations from events. In other words, you can’t synthesize timed sequences from an OBJ. (The purpose of OBJs is to visualize things, not model things.)
If you want to create timing data, write a plugin. If you don’t know how to code, I have seen at least one plugin that lets authors “invent” simple datarefs using a text file.
No Spare Datarefs
And while I’m going off on a tangent about authoring and datarefs, we will not be adding any “spare” datarefs. Again, datarefs should be made with plugins, and non-programmers should use a plugin that creates datarefs from text files. We will not be creating any “unused” datarefs in the sim.
Why not? Think of the integration problems. Even if we make 100, what happens if Joe uses “spare dataref 93” in the cockpit of his great 747 and Fred uses “spare dataref 93” for the windmills turning in his scenery pack? Splat.
The naming convention of datarefs start with the company or author who created it – or “sim” for X-Plane itself. This is intentional – it assures that two independent authors won’t use the same dataref name and create conflicts between add-ons!
X-Plane 862 RC1 is out. Just to clear up confusion, this is the next RC after 861RC1 and is just more bug fixes (all bug fixes from 861RC1 plus a few more).
There are two things hopefully working in 862:
- I think we got the optimization settings right – framerates on Windows should match 860. If they don’t, please let me know.
- There is another object-placement bug fix in 862. If you’re still seeing problems with object placement depending on which direction you approach a scenery area from, please let me know.
When I posted about roads a few days ago, I didn’t realize that people had such, um, “strong” feelings about them. At risk of throwing fuel on the fire, here’s the overall state of the road system in X-Plane:
1. Architecture
For all of the problems with the road system, I think the architecture makes sense: DSFs contain directed networks of roads, graphic resources describe how to draw them as scenery, and cars are generated on that road network dynamically. I don’t see the system fundamentally changing – rather, we’ll have extensions to the rendering definitions, more advanced car behavior, and other additions within the existing framework.
(I think this is true for most v8 scenery technology – we have a lot of room to grow without a huge rewrite.)
2. Default Road Data
This is the weakest part of the road system – the data in Europe comes from horribly old sources (VMAP0) and even the US data (from TIGER) doesn’t contain accurate enough flow information to really draw a nice detailed road grid. I don’t see this getting a lot better any time soon…but I think there are three ways this could get better:
- We’ll keep improving how we process the data in the default scenery. (But to some extent, junk data going in is going to produce poor results no matter what.)
- If we can ship overlay roads in v9, users will be able to customize road data. This would be the source of the best road data possible, at least for the relatively small* area where users customize roads.
- Some one (us or a third party) could build an add-on pack that uses commercial navigation-quality roads. I do not think we will ever have this in the sim itself – the pricing of commercial data makes this impossible. (This is not about LR being cheap – this is about not losing money on every sale of X-Plane.)
3. Road Rendering
I believe that while road rendering leaves a lot to be improved right now, it is appropriate to the level of data we have. That is, we don’t have nicely rendered intersections, but with such weird intersection data in the global scenery, even nicely rendered intersections would look absurd.
Once we have better road data (via better generation, or more likely, user-modified data) we’ll incrementally provide improvements in the way roads look, probably including extensions to the .net format that defines their look.
4. Car Brains
Right now the AI for the generated traffic is very simple, and the way the cars drive is crude. But here again I think we need to crawl before we can walk – without nicely rendered intersections (from well-formed data), there’s not a lot of point in working on this.
Summary
The road system will grow incrementally, first by allowing users to insert customized data, then by providing tools to make that data, and then by improving the way the sim draws and drives on this data. It will be an incremental process, and when it comes to roads, version 9.0 will have some evolutionary steps but nothing revolutionary.
* I think in terms of the whole world (14,000 DSFs), so user-contributed data represents a small fraction of the total scenery system. On the other hand, human beings live in clustered areas, so the numerically small number of contributions we receive will have an outsized benefit by being in “important” areas.
Disclaimer: nothing you read in this blog is even remotely like a “promise” about what future X-Plane patches or releases will do. This blog contains my ramblings, not a commitment to future features.
I am looking at allowing road networks in overlay DSFs for X-Plane 9. I’m not sure if this will be possible (this is just an investigation right now). But I realize that…
- The road data in the default scenery isn’t much good. Even in the US, where we have nice data, the roads are chunky, not smoothed, contain invalid flow information, and can have lateral error of up to 200 meters (enough to cause chaos). Of course the non-US road data comes from VMAP0 and is just as good as you’d expect from digitized 1:1,000,000 maps from WWII (which is to say, they’re awful.)
- Therefore there is a lot of interest in replacing the road grid using overlays. This isn’t possible in X-Plane 8 (put a road into an overlay and I think X-Plane will crash pretty hard). If roads could be in overlays, this would let you correct them and exclude the entire underlying layer.
There’s another hitch to this…for historical reasons, the road system uses MSL heights (that is, it exists in absolute space and is pre-placed to “hug” the road grid). At the time, when all scenery load involved a giant pause and y-testing was expensive and the entire road grid was built at once, this helped performance. A number of those fundamental problems have been solved.
But if a road grid is pre-placed (and not “draped” like a .pol file or OBJ) then the roads must be built to a specific set of global scenery mesh. I’d like to see custom meshes start to emerge, and hopefully I’ll have some time in the future to work on tools to make this a lot easier.
So the feature that would go hand-in-hand with overlay roads is AGL-based road heights (that is, the roads only specify when there is a bridge and not exactly how to hug the ground). As far as I can tell from my initial investigation, this is quite a bit more complicated to implement and is probably still a while off. I think that overlay roads could be useful even in their MSL form though.
(One interesting use would be: create roads with no geometry, just car definitions, and use them to overlay routes for ground vehicles in airports.)
