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.
I think I have mentioned draping repeatedly, as well as Z thrash, without ever clearly explaining what either of these things are. I happen to have some pictures from recent work on draping, so here’s the basic situation.
What Is Thrash?
Warning to OpenGL purists: I’m going to play fast and loose with a number of OpenGL rules. Basically what I say here is the worst case. Sometimes things work out better than I describe, but if you don’t handle the worst case, you’re going to have problems some times. Nitpickers, consider yourself “on notice”.
When drawing 3-d polygons in OpenGL, if two polygons are coplanar, most of the time they will experience “Z thrash” – that is, the hidden surface removal hardware on the graphics card removes some parts of one polygon and some parts of the other, often removing different parts on each frame in a flickering pattern. The results look like this:
In this picture on the left, we see the raw result of coplanar airport polygons on top of the sandy desert terrain that is the airport surface area. As you can see, the graphics card has been a bit random in deciding whether the runways are “hidden” by the ground or not. If you could see the camera moving, you would see that the pattern of missing taxiways ‘flickers’ as the camera moves.
If there is an overall take-away point so far, it’s this: you can’t just layer coplanar triangles without getting a mess.
(What about moving the runway slightly higher than the pavement? This would have several problems. First, the amount we’d have to move them is horribly dependent on camera angle and video card Z-buffer performance. Second, we’d see the gap between layers; for markings that really do need to be coplanar, like a rubber mark on a taxiway, this would appear as a bug.)
The Cure is Worse Than the Disease
Fortunately if we have truly coplanar geometry, OpenGL gives us a weapon to fight this: polygon offset. Polygon offset is a cheat that tells the video card: “listen, if you ever have doubts about the runway and the ground, favor the runways by a little bit.” It’s a little bit like putting a spread on a football game: the ground would have to be closer than the runway by a margin before we stop seeing.
When we have coplanar geometry, we can use polygon offset to handicap the geometry we want on top. Problem solved, right? So why do I keep writing blog posts with titles like: The Sordid History of ATTR_poly_os or The road to hell is paved with ATTR_poly_os?
Polygon offset has three problems that can bite you:
- The amount of ‘margin’ you get depends on the camera angle. This can make for some truly bizarre effects. The only way to safely manage this is to carefully minimize the margin. (This is a problem for the programmer, not the artist.)
- Because the margin must be minimized, the geometry really has to be coplanar – small cheats can exceed the margin.
- The margin you give your top polygon applies to anything else that is nearby, which can cause even more weird artifacts. For example, if you polygon offset a taxiway, it can start appearing through the nose wheels of airplane. That’s another aspect that must be carefully controlled.
If there’s a take-away to polygon offset, it’s this: polygon offset can help fight Z-thrash, but it must be used in a very narrow set of cases, and it must be used very carefully.
In my next post I’ll describe how X-Plane uses draping to fight Z-thrash for sloped runways.
One of the comments on the suburban preview screenshots I’ve heard in a bunch of places is “I hope it’s not going to be that dark” or “could you guys add more light”?
At this point, light levels in our previews are not reflective (no pun intended) of how the sim will really look. The reason is simple: the light model is not fully debugged (who am I kidding — it’s not even remotely debugged) and it only takes one light model bug to completely throw off the light levels. So I think light levels are going to be a case where the sim’s lighting looks a bit funny right up until the last bug is swatted – it’s just the nature of those kinds of bugs.
To give you an idea of how much change there is in lighting from version 9 to 10, here’s a short laundry list of sim changes that affect lighting:
-
Dynamic Exposure. X-Plane 10 reduces the effect of emissive (_LIT) textures base on the brightness of the sun. In X-Plane 9, emissive textures have the same impact regardless of time of day; thus a lighting effect that looks good at night will look too strong during the day. (In real life, you eyes would adjust for the sun and the artificial light would seem less bright.)
-
Linear Light Mode. This gets confusing fast, but basically, our eyes perceive light in a non-linear way; we are more sensitive to low light levels than bright light levels. Computer graphics mimick this behavior; the result is that most computer lighting models are physically incorrect in some circumstances. Using the non-linear eye-based behavior has been the norm for while because it was cheaper hardware-wise, but these days it is possible to do physically correct linear lighting. We are adding this wherever we can; the correctness varies with rendering settings since physically correct lighting is more expensive GPU-wise and we don’t want to hurt fps for low-end users.
-
Deferred Rendering. X-Plane 10 has two rendering modes: a forward renderer (which is a lot like X-Plane 9) and a deferred renderer that supports global illumination and an HDR rendering space.* This creates a certain amount of chaos because the code for forward and deferred rendering are separate, and they seem to develop separate, unrelated lighting bugs.
-
Global Illumination. X-Plane 10 supports global illumination in deferred rendering mode, which means that thousands of lights can light up any part of the scenery system. Thsi means that (for the first time) an object may be lit by dozens of light sources at once. It turns out that the linear light model is a lot more important when we have more than one light source. (In fact, Alex and I realized that we needed a linear light model when looking at highways lit by streetlamps.)
-
New Light Billboards. X-Plane, like most flight simulators, uses billboards (textured squares that face the camera) to draw the light effects near a light source, like glare and bloom. The shape, textures, and equations for the light billboards are heavily revised in version 10.
-
Clouds. The weather system is being rebuilt, including new shaders for cloud puffs. Since cloud puffs aren’t like solid buildings or airplanes, they have their own shaders with their own light characteristics. We are also experimenting with increased ground visibility, which affects fog.
If there’s a take-away point, it’s this: lighting isn’t just one piece of code in X-Plane – it’s the sum and interaction of a large number of features, all of which are being heavily worked over. Only when all of the features work correctly and work together in harmony will we have what appears to be sane lighting.
* Some users may confuse HDR, which just means an image with increased dynamic range for light levels, with the more common effects that games ship once they have an HDR render: bloom and tone mapping. Bloom is when bright light sources “blow out” and splat light around nearby areas; tone mapping is a technique to visualize that high dynamic range on a normal monitor – often it is used to simulate your eyes adjusting to variable light levels.
I do not think we will ship bloom in version 10.0; I experimented with it and found it had almost no value. First, there are very few scenes in a flight simulator where bloom is that useful; it seems to be a lot more useful for interior rendering, like you’d see in a first person shooter. Second, X-Plane already has a number of bloom-like effects, including halos around lights via billboards, sun glare, etc. With most of the important cases already covered by ad-hoc effects, my early experiments with bloom weren’t very promising. We may revisit bloom later, but I don’t think it’s as important as other effects for now.
Similarly, I don’t think we will have dynamic tone mapping because we will have an overall dynamic exposure control running all of the time. Again, the value of tone mapping is more obvious with first person shooters, where you can go from interior to exterior and you want the world to be ‘overpoweringly bright’ for a while. By comparison, pilots do their best to preserve their night vision, and the interior of an airplane is designed to match that; instruments auto-calibrate their brightness to the overall light levels, making tone mapping less important.
A few days ago Tyler posted some pictures of the “auto-gen”* for X-Plane 10’s global scenery.
First, a few notes on hardware and performance: Propsman took these pictures on a new iMac, so that’s a core i5 and a Radeon HD 5000 series GPU – that is, a pretty decent system. Hardware technology continues to advance rapidly (especially on the GPU front), so there’s a big difference between a ‘decent’ system bought today and even a hard core system from two years ago.
I don’t know what your performance will be like. I do know that the system is performing well enough so far in its not-really-all-that-optimized form that we think we can ship it, and more importantly I know that we can turn the level of detail down in a number of ways to lighten the load as needed.
The most expensive feature you see here is the real-time 3-d global shadows. Heavy shadowing combined with heavy 3-d does add up and hit the system hard, but I think we’ll be able to have intermediate shadow settings that should be more affordable.
X-Plane 10 will use hardware instancing if your GPU is capable of it, and it makes a big difference in the amount of 3-d you can show.
X-Plane 10 is also quite a bit more fill-rate intensive than X-Plane 9; if your GPU is having fill-rate problems with version 9, some version 10 features will be out of reach. In the past, X-Plane has been light on fill-rate, so we’ve had users running with cut down cards (like a GeForce 8400) without realizing that their card isn’t that fast.
Some users have asked about architecture and localization. I expect we will not ship out of the box with multiple local regions; however, the library system allows us (or any third party) to provide new artwork sets for local, architecturally reasonable buildings.
Finally, it might be a bit difficult to see in these pictures (because they are focused in on the detail), but the 3-d buildings you see here work with the real-world roads. In the past, we’ve had a clash between the buildings and roads vs. the terrain texture. This is a problem we are solving for X-Plane 10.
* Auto-gen, meaning bulk buildings that populate the world in urban areas…whether it’s really auto or gen or anything like autogen in the past is a complex discussion that will have to wait.
Alpilotx pointed me toward a thread on the org discussing Austin’s work on the weather system. The thread turned into a bit of a he-said-she-said with regards to Outerra and whether it could some day be combined with X-Plane.
This blog post will be a discussion of various general approaches to scenery and the trade-offs we have to consider, e.g. plausibility and realism, procedural vs. algorithmic and data driven design. But first, a brief note on Outerra. As I have said before, we are already aware of Outerra, so there is no need to email us. The bottom line is that we have a set of mostly done features for X-Plane 10, our goal is to finish X-Plane 10, and we are not even spending one brain cell considering putting a new rendering engine into X-Plane while we are trying to get 10.0 done.
Defining Some Terms
One of the problems with comparing scenery system approaches is that a real productized approach to scenery rarely fits into a perfect bucket or matches a single theoretical techniques. So here are some approximate terms, designed to generally describe an approach. They’re not going to be perfect fits, and even the definitions will fluctuate in different contexts and forums.
- We can say scenery is plausible when it looks like it might exist somewhere in the world. Plausible means that roads don’t go straight up over a cliff, trees don’t grow in the ocean, etc. In other words, plausible scenery is scenery where absurd things don’t happen. Plausible scenery is great when you don’t know what an area should look like. A lack of plausibility is often a bug.
- We can say scenery is realistic when it correlates closely with what is really present at a given location on the Earth. So if there really is a lake behind my house, realistic scenery has that lake. Plausible scenery might have a lake, a forest, or something else believable for where I live (the Northeastern United States). A giant sandy desert would not be plausible for my location.
- We can say scenery is procedural if the detail in the scenery comes from some kind of algorithm that produces results. For example, a fractal coastline is procedural.
- We can say scenery is data driven when the detail comes from some source of external input data. Our mountains are currently data driven – that is, the mountain shape basically comes directly from the DEMs we use.
- We can say scenery is artist driven if the look of the scenery comes from art assets created by an art team.
- We can say scenery is algorithm driven if part of its look comes from the transformational process that converts data from one form to another.
(I’m sort of drawing a line in the sand here with procedural vs. algorithmic, but what I’m trying to contrast is a program that generates ‘information’ out of thin air vs. a program that creates information out of other information. For example, in X-Plane 9, European capillary roads were procedural. We had no real data, so I wrote an algorithm that made them up in a manner that was consistent with underlying terrain. In version 10, these roads will be algorithmic; we take OSM data and then do some processing to make it suitable for X-plane. This is definitely a line in the sand kind of definition.)
So Are We Plausible or Realistic?
So the first question is: is the goal of X-Plane global scenery plausibility or realism? The answer is: a bit of both. Austin’s posts on the subject virtually always bring up plausibility. The reason for this is simple: he is not too worried about the amount of realism we’ve put into the scenery, but he is not happy with the bugs. He wants the bugs gone. So every time he and I speak, he says “and make sure it’s plausible!”
But we’re not going to remove realism just to fix plausibility bugs. I expect that the next global scenery render will be at least as realistic as the last – that is, we’re going to use better data and we’re not going to make up data where we had real information before.
There are limits to realism. We don’t expect the global scenery to ever be as realistic as a custom scenery package for a small matter. But realism does matter. Part of the joy of flying in a flight simulator is seeing the real world. Where we can have more realistic global scenery, we consider it to be a win, and we are always looking to be more realistic than the last render.
Plausibility for the version 10 render is going to take two forms:
- Bug fixes. Any time something screwy happens, it’s not plausible. Sometimes these are code bugs that must be fixed, and sometimes they are data conflicts. For example, the water data sasys “water” but the elevation data says “hill”. Combine them and you get water going up a hill. We have to write code to resolve this, somehow.
- We are reworking the way cities are rendered, because even at their best, the old approach, procedural buildings with algorithmic roads over land class photos, did not look plausible, even at its very highest setting. So this is a feature request to fix a plausibility problem.
Algorithmic or Procedural
I’ve discussed this before (and forgotten about the post). But to expand the discussion, we need to consider not only algorithmic and procedural data processing, but whether we are driven by procedural generation, input data, assets created by artists, or some combination. (In practice, all systems require a mix of data, art assets, and procedures and algorithms, it’s a question of the blend.)
I’ve been working on global scenery for a few years now, and over time I’ve come to appreciate the importance of artist input (via art assets) into any scenery process. Simply put, if you want scenery to look good, you need to make it reasonably straight forward for people who are good at making pretty pictures to control the look of your visual results. A few years ago I viewed the scenery process as strictly a question of data conversion and visualization, but now I see it as finding a way to merge art assets and data into a cogent final product, with the art assets being used in a way that the artists can control. In practice, this often means making sure that the art assets come in a format that artists are comfortable with or can learn without too much pain.
As I said in the previous post, our approach is becoming more algorithmic and less procedural as higher quality source data becomes available. (For example, we don’t have to generate European roads when we can import and reprocess them.) But our approach over time has always been heavily artist driven. By this I mean: our input data is algorithmically processed into a final form that makes sense only in the context of art assets, and we have a pretty good idea of what those art assets will look like when we design the algorithms. To use roads as an example again, our task with OSM is to convert OSM road data into a road network that will visualize nicely with road art assets created by an artist.
Procedural Compression
One way to view procedural scenery is “creating lots of information from little or no information”. But another wa
y to think of it is as a compression technology. As was correctly pointed out on the org forums, you use less storage specifying the overall location of a forest than you do specifying every tree individually. The compressed form (store the forest location) can be equally plausible. It will be less realistic if the original tree locations were based on real world data, but it will be equally (unrealistic) if the original tree locations were procedurally generated. Put another way, pushing procedural processes out of the scenery generation process and into the flight simulator makes DSFs smaller.
When I first started working on X-Plane 8 DSF scenery, not only was DVD size a factor, but so was load time; we had one core and it wasn’t a very fast core. Anything we could do to make loading faster, we did. Thus we pushed a lot of work into the scenery generation process, including procedural processes, to keep load time down.
Times have changed; we now have dual core machines as a baseline, and often quite a few more cores. Thus over time we are starting to move procedural processes back into the simulator, trading load time (which runs on multiple cores) for generation time and file size. So perhaps a more accurate statement would be: our scenery generation process is becoming more algorithmic and less procedural, and X-Plane itself is becoming more procedural. This is driven both by more input data (which must be processed up front) and more compute power on the host (which lets us shrink file size, and thus use DVD space for other things).
X-Plane 10
Here’s how this plays out in practice in version 10:
- Some (but not all) of the building placement work* has been moved into X-Plane; a bit of expensive precomputation is still done at DSF generation time.
- Some (but not all) of road processing has been moved into X-Plane; a lot is still done at DSF generation time.
- Where possible, we are moving from a multi-layered approach to terrain to a pixel-shader-based approach to terrain. This cuts down overdraw and uses the GPU more efficiently. (The simplest example: in X-Plane 8 and 9, cliffs have separate terrains from hills. In X-Plane 10, a single terrain sits on both the cliff and the hill and changes its appearance based on the actual slope; this texture change is computed by the GPU.)
In other words, X-Plane 10 is making the logical evolution to better balance the computing resources we have to improve plausibility and realism.
At this point I can say with 99% confidence that X-Plane 10 will feature bezier curved roads. In X-Plane 9, a road is a line segment; you can simulate curved roads by using a lot of line segments, but the global scenery roads are pretty chunky.
X-Plane 10 allows for a road to be a bezier curve, allowing the specification of smooth curves with a small amount of data. This sets us up to trade off visual quality and performance using a rendering setting.
A few notes for authors:
- Like all of the new v10 road features (and pretty much all of the new v10 scenery features), you don’t have to use bezier curves in your roads. They are there as an option if you want them.
- X-Plane 10 will not make curves for you; road data that is defined as line segments in the DSF will be rendered as line segments. (This follows the principle that DSFs contain pre-processed scenery data, and the sim shows DSFs exactly as they are written.)
Pay No Attention to the Documentation
The DSF specification alludes to bezier curved roads; this “old way” of encoding curves was never supported in the sim – all versions of X-Plane ignore this data. The “old way” was how we thought we might do curves some day.
The version 10 curve encoding is different; the “old way” will continue to be ignored in version 10. So: do not use the DSF spec to try to make curved roads now. I will post detailed documentation on curved roads once version 10 is available to authors.
I have been stingy with pictures of next-gen global scenery for one reason: it’s really hard to get a nice shot of the global scenery that doesn’t show unfinished features. With something like global lighting I can zoom in and show just the new trick, but with global scenery, I can’t take a picture of a new house without showing a city block that looks funky due to a bug and a road that isn’t finished. Posting a working shot of the global scenery where some sub-systems have bugs and artifacts would just freak everyone out.
I figure if it’s obvious that the shot isn’t a production shot, I can get away with posting it though.
A lot of the times when I work on the rendering engine, it is with test textures like this. Our art team does their best to hide the seams between different art assets, so that the scenery looks like one continuous world. The problem for me is that the better they do, the harder it is for me to tell if the underlying shaders are doing what they should do.
So alpilotx sent this test: it’s all of the Innsbruck area painted with a test texture. What’s new and interesting here is that the flat, hill, and cliff areas are all shaded by a single shader that selects between multiple textures (and rotates the textures) based on the underlying mesh.
We are adding the cliff shader to version 10 for a few reasons:
- Often we can get better cliff and hill definition by processing in the shader than by painting different triangles with different textures; our ability to control the transitions using different .ter files is limited.
- Using one slope-sensitive shader saves over-draw and triangle count, which makes the DSFs faster and smaller.
- Some day we may have the GPU distorting mountains on the fly to make them more mountainous. If we do, we need the GPU to also apply the correct textures; if the cliff areas are precomputed then they won’t respond to GPU distortion.
If I could have a dime for every email I have received that asks some form of “will X-Plane 10 have X” (where X is a feature or enhancement), I wouldn’t need to actually work on X-Plane anymore. (If you think your email triggered this post, well, there are approximately 100 other users who have asked the same thing.)
Simply put: I have no idea and I’m not going to try to answer these questions any more. Here’s why:
For as long as I have been involved with X-Plane, Laminar Research has provided free patches to the simulator throughout a major version run, and those patches have included not only performance enhancements and bug fixes, but also major new features.
So the question “will X-Plane 10 have X” can really mean one of two things:
- Will X-Plane 10.0 have feature X immediately ‘on the DVD’?
- Will X-Plane 10.x ever have feature X in a free patch before the major version run is over.
I can answer the first question, because we are relatively locked down on what features are still on the table for 10.0 vs. what must wait, but I think it’s at best confusing to do so. If a feature isn’t on the DVD, it might be in a free patch within weeks; it might be available by the time you get your DVD. Whether a feature is on the DVD is of interest to us as we plan our release, but I don’t think it actually makes a huge difference to users with internet connections.
Consider 64-bit – it’s something we want to look at during the version 10 run but we’re not going dig into it until after we get 10.0 out. So will 10.0 be 64-bit? No. But there will probably be a 64-bit patch available for free. I think you can see why I don’t want to post “X-Plane 10 will not be 64 bit.”
I cannot possibly answer the second question, because versions run over several years, and what we code for the end of the version run will depend on market conditions and technology that don’t exist now. One of the nice things about patching X-Plane frequently is that we can revise our plans as conditions change.
Consider the question “how many cores will X-Plane 8 utilize” had you asked the question during X-Plane 8.0. When X-Plane 8.0 came out, the answer was “only one” and we had no road-map to change that. For that matter, multi-core machines were rare and exotic beasts at the time, so multi-core wasn’t a priority.
Within the three years of X-Plane 8’s major version run, we ended up supporting multi-core for scenery mesh loading, something that couldn’t have been easily predicted at the beginning of the version run.
Finally, a note on release planning: now is absolutely not a good time to ask for features. The features that will ship in X-Plane 10.0 have already been determined, and since we’d like to ship X-Plane 10 sooner rather than later, I don’t think there’s anything you can say that would make us add a feature to 10.0.
All future features are going into a 10.x “bucket” for planning purposes. Since Austin, Chris and I are up to our eyeballs in code and the art team is red-lined too, we’re not spending any time sifting through 10.x buckets right now. If you send us a feature request, the very best case is that we dump it in a holding list for later; the worse case is that we lose track of the request in the chaos.
That doesn’t mean that we don’t care about 10.x. It’s just that we are very much heads down in the 10.0 release now and won’t look up until it’s done.
I have mentioned a few of the scenery engine features coming in X-Plane 10 that will be of interest to authors: global illumination, conditional parts of OBJs (to cope with variable rendering settings). There is another general feature coming that will make authoring scenery a lot easier, I hope.
X-Plane 9’s rendering engine has the ability to drape geometry. Draped geometry are meshes that are ‘dropped’ onto the terrain and hug the underlying base mesh perfectly. The most common example of this is the runways: because the runways ‘drape’ the ground, the runway shows any curvature and bumps from the underlying base mesh. This is who we create sloping and non-flat runways.
Authors can drape geometry as well, using a draped polygon (.pol) primitive in an overlay. Such draped geometry is useful any time you want to add more “paint” to the ground, e.g. to put down a taxiway, parking markings, dirt, grass, a driveway for a house, you name it.
There is one case in X-Plane 9 where you cannot drape geometry: in an object. In an object, all geometry is aligned to the object, and will only interact nicely with the ground if you get lucky. For example, if you model a house with a sidewalk, the sidewalk won’t “sit” on the ground if the ground turns out to be sloped. You can use ATTR_poly_os to hide the artifacts, but ATTR_poly_os really can’t cope with mismatches between the OBJ and the terrain under it.
X-Plane 10 will introduce a new object attribute: ATTR_draped. Draped geometry in an object is actually draped down onto the terrain when the object is placed in the scenery. This means that the draped part of the object will hug the ground perfectly with no interference or Z thrash. You get all of the quality of a draped polygon with the convenience of an OBJ.
There are a few possible uses for ATTR_draped:
- Any time a 3-d model needs some ground details attached to it, e.g. the driveway near a house, draped geometry provides a good fit with the ground and good alignment with the object.
- Any time you want to include a pre-made ground decal (E.g. a painted parking spot on a taxiway), the ground detail can be modeled as an object using draped geometry.
ATTR_draped will facilitate creating and sharing custom details for airports and streamline the authoring process.
This is my expectation for scenery compatibility in X-Plane 10:
Scenery based on DSFs, OBJs, and other version 8/9 file formats should work with X-Plane 10 unmodified.
This includes orthophoto scenery based on DSFs – we’re not throwing that code out.
The new rendering engine features for version 10 (and there are a lot of them) are extensions – new ways to render things, new types of art assets.
I do believe that we may drop support for ENV scenery files in version 10. We’ve had DSF for six years now, and ENV’s capabilities (a 500m mesh, very limited orthophoto resolution) aren’t useful to today’s users. You can use DSF2Text/XGrinder to extract custom object placements from an ENV for use in a new overlay.
We may also drop support for OBJ version 2. (Yes, we still load OBJs version 2.) OBJ version 2 is the OBJ file format from X-Plane 6, the one before OBJ 7. If you have any old OBJs (version 2 or 700) you can use XGrinder to automatically batch convert them to OBJ8.
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.
