In my previous post I described Z thrash and how polygon offset is used to fix it. Now we can look at draping and runways.
The fundamental problem with sloped runways is that a runway is made up of tiles, but the ground underneath it may change slopes in unrelated locations. The following diagram illustrates the problem.
This is a side view of a sloped runwy: the green line is the underlying bumpy terrain and the black line is the runway, divided into multiple tiles. Recall from last time that we can only avoid Z-thrash using polygon offset if the two polygons are truly coplanar. Therefore, we can look at four ways to handle the situation and evaluate them for quality:
- In the top picture, the runway simply runs right through the terrain. This case won’t work, with or without polygon offset. In some cases the terrain is on top, and in some cases the runway is on top. The gap between the runway and terrain might be quite large for a significantly sloped runway.
- In the second picture, we move the runway up to clear all but the tallest part of the terrain. This won’t Z-thrash, but it will look pretty bad. There can be a large gap between the runway and the terrain; if you run your airplane off the side of the runway, you’re going to fall. The gap between the runway and terrain will be quite noticeable.
- The third picture is close – each runway tile is clamped to the terrain. But this still isn’t good enough; while most runway tiles now sit on the ground perfectly, a few will take a ‘short cut’ over or under the ground, like the case I have circled in red. So we’ll have less Z thrash, but some parts of the runway will still be broken.
- The last picture is what we really need: we break the runway tiles up into even smaller pieces where the terrain makes a change. The last tile on the right is now two tiles, each of which can sit perfectly on part of the terrain. Only in this last case can we apply polygon offset and get a nice clean runway.
This last case is exactly what X-Plane does. This technique is called draping – the sim ‘drapes’ the overlaid runway tiles on top of the runway like a rug. The sim breaks the tiles into pieces so that each tile can sit perfectly on the underlying terrain.
The real work of draping is not just in figuring out where the terrain below the tile is, it is in cutting the tile into the appropriate pieces that can ‘sit right’. The following pictures show this process in 3-d.
This is a screen-shot of a small piece of taxiway at KSAN. I have drawn in the outline of the draped polygon in yellow and the terrain triangles in blue. (The terrain triangles are quite large, so we can only see part of them running through the scene.
This is a wire frame of the problem at hand: we need to insert the yellow polygon into X-Plane, but we need to make sure that no triangles that we generate cross the blue line. The blue lines essentially represent “ridge lines” in the underlying mesh.
If we just had to draw the yellow polygon, we could triangulate it using the thick gray lines shown in this picture. However, this would not be good; the big gray triangle in the middle of this picture runways right across a blue line – there’s no way that this big gray triangle can “drape” properly across the ridge line.
This is what actually ends up happening. The gray lines are cuts we need to triangulate the polygon; the red line are cuts we need to not cross the ridge line, and the purple lines are cuts we need to ensure that everything is broken down into triangles (since that’s what the video card really wants). Once we have this triangulation, we can place every vertex on the ground and it will “drape” the way it should.
In my next post I’ll describe how you can use draping in your scenery to create images on the ground without Z thrash.
This is already done by X-Plane 9 and it not a novel feature for X-Plane 10, yes?
That is correct – in fact, draping a runway was introduced in version eight!! (850 to be exact.) Part 3 will cover this more, but what is new in version 10 is that draping is being used in more places in the code, and is available inside OBJs for the first time. The internal draping code has also been optimized to make more efficient use of memory.
When we see an airplane part or a building roof flickering (similar to what you have explained in the first part), is it the same issue?
Will these artifacts be better handled in version 10?
It is only the same issue if the model was created with coplanar polygons…most of the time this is _not_ the case with airplanes. See my previous comments re: airplanes and zoom. It’s on my bug-fix list for v10.
Ben,
Will the unevenness of a runway affect airplane physics (accel/decel) in any way, or is it just a visual trick?
I believe that it does affect physics – that is, your plane will gain and lose acceleration as you go up and down hill, etc.
Hi Ben,
But can’t you first cut the polygon into multiple pieces to folow the underlaying scenery , and then triangulate?
Mabey it would result into less triangles?
a enthusiast user of x-plane from the Netherlands
That is an astute comment! In fact we have looked at cases where we pick up a few triangles due to the order of operations (e.g. cut then triangulate vs. triangulate, cut, retriangulate might cut 6 tris to 4, which adds up when repeated a lot).
The main problem is one of code structure: a lot of times the polygons that are coming in are not guaranteed to be convex, which makes the cut operation trickier.
I do have a note to some day look at providing ‘native’ quad draping, because the quad case is the convex polygon case that comes up most where we could save a few tris.
One question, the global scenery source is SRTM?
If so, are you using the latest corrected version withouth the voids that plagued the first releases?
This is the latest correted version:
//srtm.csi.cgiar.org/
The source is SRTM. For v9, we back-filled voids ourselves with our own filling algorithm and a composite of data sources; for v10 we will probably be compositing data sources again; we’re not sure if CGIAR will be one of them or not..it’s on the list.
Why not CGIAR directly?, all voids are already filled
The other possibility is to use ASTER, with a 30m resolution for the rest of the world…
We are looking at CGIAR now. We have not made a final decision. We will need to come to with licensing terms with them as the data set is not free. I do not remember why we didn’t use it for v9; CGIAR is also revised so the properties of CGIAR now may not have been the same as what was available 4 years ago…we’re definitely looking at the current CGIAR now.
Re: ASTER – has it been processed yet, or is it still only ‘raw’ data that’s available? RAW unprocessed ‘research’ DEMs can be problematic.
Great!
About Aster, still on research grade, the increase in resolution is significant, but there is a lot of noise and artifacts. Check a comparision I made
//i.imgur.com/dQaLi.gif
At the end, you have to determinate what is more important accuracy or definition.