The X-Plane version 8/9 default scenery uses raster land use data (that is, a low-res grid that categorizes the overall usage of a square area of land) as part of its input in generating the global scenery. When you use MeshTool, this raster data comes in the .xes file that you must download. So…why can’t you change it?
The short answer is: you could change it, but the results would be so unsatisfying that it’s probably not worth adding the feature.
The global scenery is using GLCC land use data – it’s a 1 km data set with about 100 types of land class based on the OGE2 spec.
Now here’s the thing: the data sucks.
That’s a little harsh, and I am sure the researchers tried hard to create the data set. But using the data set directly in a flight simulator is immensely problematic:
- With 1 km spatial resolution (and some alignment error) the data is not particularly precise in where it puts features.
- The categorizations are inaccurate. The data is derived from thermal imagery, and it is easily fooled by mixed-use land. For example, mixing suburban houses into trees will result in a new forest categorization, because of the heat from the houses.
- The data can produce crazy results: cities on top of mountains, water running up steep slopes, etc.
That’s where Sergio and I come in. During the development of the v8 and v9 global scenery, Sergio created a rule set and I created processing algorithms – combined together, this system picks a terrain type from several factors: climate, land use, but also slope, elevation, etc.
To give a trivial example, the placement of rock cliffs is based on the steepness of terrain, and overrides land use. So if we have a city on an 80 degree incline, our rule set says “you can’t have a city that slanted – put a rock face there instead.”
Sergio made something on the order of 1800 rules. (No one said he isn’t thorough!!) And when we were done, we realized that we barely use landuse.
In developing the rule set, Sergio looked for the parameters that would best predict the real look of the terrain. And what he found was that climate and slope are much better predictors of land use than the actual land use data. If you didn’t realize that we were ignoring the input data, well, that speaks to the quality of his rule set.
No One Is Listening
Now back to MeshTool. MeshTool uses the rule set Sergio developed to pick terrain when you have an area tagged as terrain_Natural. If you were to change the land use data, 80% of your land would ignore your markings because the ruleset is based on many other factors besides landuse. Simply put, no one would be listening.
(We could try some experiments with customizing the land use data..there is a very small number of land uses that are keyed into the rule set. My guess is that this would be a very indirect and thus frustrating way to work, e.g. “I said city goes here, why is it not there?”)
The Future
I am working with alpilotx – he is producing a next-gen land-use data set, and it’s an entirely different world from the raw GLCC that Sergio and I had a few years ago. Alpilotx’s data set is high res, extremely accurate, and carefully combined and processed from several modern, high quality sources.
This of course means the rules have to change, and that’s the challenge we are looking at now – how much do we trust the new landuse vs. some of the other indicators that proved to be reliable.
Someday MeshTool may use this new landuse data and a new ruleset that follows it. At that point it could make sense to allow MeshTool to accept raster landuse data replacements. But for now I think it would be an exercise in frustration.
MeshTool 2.0 is still a very new tool, so it shouldn’t be surprising that it has grown quite a few features during beta. I am putting three new features in for beta 4 that should help round out the kinds of things an author can put into a mesh.
Land Class Terrain
The next beta will allow authors to specify built-in land-class terrains by shapefile. Landclass isn’t quite as easy to work with as you might think – I’m working on a Wiki page describing how land class works with the mesh.
You can’t invent your own land classes directly in MeshTool, but there are two work-arounds:
- Once you build your DSF, use DSF2Text to edit the header, changing one of our land classes to the one you want. We have 500 + land classes, so you can probably find one to cannibalize.
- Or you can just use the library system to replace the art assets for the land class within the area covered by your mesh. (You can tweak as little as one full tile.)
Water Handling and Masking
Water handling and masking go together to allow you to create an accurate physical coastline. The problem is that X-Plane doesn’t let you specify whether a tile is land or water using a texture/image file. Physics are always determined on a per-triangle basis.
MeshTool 2.0 beta 4 will let you specify whether the physics of an orthophoto that has water “under” its transparent areas will take on its own physics, or the physics of the underlying water. (It can act “solid” or “wet”.) This lets you use orthophotos to model shallow areas and reefs.
The mask feature lets you do both. The mask feature lets you limit MeshTool to working on a single area vector area, defined by a ShapeFile. So to make a single orthophoto have wet and solid parts you:
- Issue the orthophoto command in solid mode.
- Establish a shapefile mask for areas of your DSF.
- Re-issue the orthophoto in “wet” mode.
The second orthophoto command will replace the first only in the wet areas, giving you regions with both types of physics. The README for MeshTool will cover this in more detail.
No Z Yet
Some developers have requested that MeshTool use the Z coordinate in a Shapefile to define the elevation of water boundaries. That’s a good idea, but I can’t code it any time soon. The polygon processing in MeshTool is fundamentally 2-d and has no way to retain the Z information during processing. I will try to get to this feature some day, but for now it’s going to have to wait.
The new beta should be available some time early next week, or now if you build from source.
No posts for two weeks…sorry, I’ve been head’s down with next-gen tech. It’s a little bit too early to blog about this stuff.
I was able to fix a few MeshTool bugs, but I have more problem reports, so I might be able to do a MeshTool beta 3 in a few days if things go smoothly.
940 is final – there might be a 941 maintenance release – we’ll know in a few weeks.
This feature is not in the WED developer preview (because I just coded it) but: WED 1.1 will feature “click-to-split” for edges. With WED 1.1 you can option-click the edge of a polygon or line feature (but not a must-be-straight entity like a runway) to insert and drag a split point.
This will hopefully be a lot easier than the current, convoluted, WED 1.0 technique of selecting the two surrounding vertices and picking “split”, then repositioning the vertex.
Hackers: this features is not yet checked into the tree, so … building from source won’t help you. It’ll be available some time in the next week.
I realize as I write this that I am going to get some comments mocking the fact that X-Plane 940 is on RC, um…13. I don’t decide the milestones for X-Plane, nor do I decide the version numbers. If you want to discuss why X-Plane is 940 (and not 930 or 950) and why it goes beta and RC when it does, email Austin. What follows is all about the scenery tools, not X-Plane.
With that out of the way: I have released a WorldEditor 1.1 developer preview. So I wanted to explain in a little bit more detail what the difference is between a developer preview and a beta. Here is an approximation of the standard definitions of “milestones” – they are what I use for WED.
- Development: not all features are coded, no guarantees about bugs.
- Alpha: all features are coded, no bug is so severe that you can’t at least try a feature. (For example, if WED crashed on startup, it would not be alpha, because you could not test saving files.)
- Beta: all requirements of alpha, also no bugs that cause program crash or data loss.
- Release: no open bugs.
This all applies to known bugs. Beta software may crash and cause data loss – it’s just that we wouldn’t have put it out as beta knowing that this happened.
WED 1.1 is still in phase (1) – development, and the build I posted is a developer preview – a cut of whatever code I had laying around. So: I can’t promise it isn’t going to trash your data or crash! Be even more cautious with the developer preview than you would with a normal beta. You don’t want to run a five hour session without saving your work, and you want to be backing up your work often – the “save” command might trash your entire project.
Why do a developer preview if it’s still so buggy? Some users who know how to compile WED from its source code are already using WED 1.1 and they seem to be enjoying it. So far it appears not to be lethally broken. Given that and the fact that most of the uncoded WED 1.1 features are usability and edge-cases, it seemed like the developer preview could be useful for getting earlier feedback.
One last note: the manual is not updated at all, nor is there any documentation on the new features. Let me be clear: no tech support or help is provided what-so-ever. Do not email me, or X-Plane tech support with “how do I use WED 1.1” questions. If you cannot figure out how to use WED 1.1 on your own, don’t use the developer preview.
The rule is very simple: if you want to put a marking on the ground, your results will be much better if you use a .pol (draped polygon) or .lin (draped line) than if you use an OBJ. In fact, an OBJ is probably the worst way to put markings on the ground.
Requirements for Good Looking Markings
In order for markings to look good you need to have three things happen:
- You need to make sure your markings are at the exact same level as the ground itself.
- You need to use polygon offset to tell X-Plane to tell the video card that these are “coplanar” (at the same height) triangles that must be managed in a special way.
- You must guarantee that the draw order is: the stuff under your markings, your markings, then the 3-d buildings and other 3-d stuff.
With these requirements we can compare .pol/.lin files to OBJs:
- .pol and .lin files always “drape” to the ground, so they always meet rule 1 perfectly. With an OBJ you can set the height of your OBJ to 0 but on sloped terrain this won’t be correct.
- .lin and .pol files are always “polygon offset” automatically, so they always meet rule 2 perfectly. With an OBJ you need to use ATTR_poly_os.
- ATTR_layer_group (or LAYER_GROUP) tell the OBJ or pol/lin in what order to draw, so you can set this correctly in all cases. The default values if you don’t specify a layer group are more appropriate to the task of markings on the ground when you use a pol/lin – that is, by default they meet rule 3 perfectly. By comparison, an OBJ may not be in the right draw order.
So we can see from these 3 rules that you will always get the rules right just by using a pol or lin, but you have to be very careful and may still not get the rules right when using an OBJ.
Performance? Think .pol
When you have a large number of small markings, the performance of a .pol is going to be significantly superior to the performance of an OBJ. For example, imagine an airport where you want to draw on-pavement signs for all taxiways and runways. With an OBJ, to get the height right, you’d need to use a large number of small objects. (With one large object, it will be nearly impossible to make the OBJ markings be on the ground when far from the object center.)
When you use a large number of .pol markings that share one common texture and all have the same .pol file, X-Plane merges them behind the scene into one huge object-like pile of triangles. The cost of drawing all of those polygons will be similar to the cost of drawing just one object! That’s a huge speed win.
Floating Objects Are Wrong
What I see most commonly in scenery packs that are sent to me and have thrashing problems are OBJs that have a height other than 0. This is simply the wrong way to create overlaid geometry in X-Plane, and it will produce artifacts in a wide variety of situations. At best, the “floating” objects will cause airplanes driving over the marking to look like they “sink in”. At worst, the offset you pick will be too small for the video card’s resolution and you’ll get thrash anyway.
There is no one right vertical offset for all scenarios, and even if there was, it would still look ugly! See the above rules for what an OBJ really has to do.
How Do I Get a .pol into my scenery.
Well that is the $10,000 question. I must admit that I don’t know what Overlay Editor’s capabilities are in this regard. WED 1.1 will be able to add draped polygons, including texture coordinate editing of the polygons. I’ve been working on the texture coordinate editor in WED this weekend and am hoping to get some kind of WED 1.1 preview built this week.
With WED 1.1 the process is fairly simple:
- Create your texture.
- Create a single .pol text file that names the texture, so you can use it.
- In WED 1.1 you can select the .pol from the list of resources for your scenery pack, and then use the “polygon create tool” to simply draw the draped polygons into place.
- Once the draped polygons are created, you can select the polygon and open the “texture coordinate editor” tab to edit the way the texture is applied to the polygon.
My hope is that this process will be easier than creating markings using a 3-d editor – you can still edit the texture coordinates, but you can do so directly in WED.
I have set up a public bug database for the scenery tools. The reason is that I don’t have much continuous time to work on the scenery tools – it’s very stop and go and will be for a while. The bug base lets you create a permanent record of a problem that I can’t lose track of in the heat of whatever is on fire today.
WED is almost ready for a beta, but I am just completely swamped with work right now…for WED 1.0 I worked full time on fixing WED bugs for a significant time when WED went beta; this time around I won’t have that kind of time – at least not this year.
So…we’ll see how the bug base works out. My hope is that I can post WED, put it down, and pick up work on it intermittently with the bug base providing a record of what remains to be done.
Regarding other tools, there will be at least one more MeshTool beta with an improved shapefile processing algorithm that will handle broken shapefiles better. The ac3d plugin has some bugs filed against it but it’s possible that they’d be deferred past the 3.2 plugin.
I have said this before, but now it’s finally true: new file specifications are subject to change in the middle of beta!
In particular ATTR_light_level has changed slightly from beta 7 to beta 8. If you are using this feature in your objects, you will need to update your objects.
A new ac3d beta will be posted later today that supports the updated syntax.
You can read about the syntax here.
I get asked about the maximum mesh density in X-Plane a lot.
First, I must note that X-Plane’s mesh is adaptive – the triangles are not arranged in a grid, but rather they’re arranged to maximize the quality of the mesh with minimal triangle count, while preserving the outlines of water bodies and airports. These pictures show a dynamic mesh fit to a section of the grand canyon (both with and without the shaded DEM for reference):
Second, the actual maximum mesh density is almost certainly limited by system resource constraints. The maximum spatial resolution in a DSF is about 0.6 millionths of a foot. You’re going to exceed the maximum number of vertices, or much more likely, the maximum amount of available memory in X-Plane long before you have a grid at that resolution.
(That doesn’t meant that resolution isn’t usable – remember, the idea of the adaptive mesh is to have very high densities in very improtant places, but not everywhere.)
But in practice this is all moot if you don’t code your DSFs by hand – the question that really matters is: what is the highest density mesh that you can use with the current scenery tools.
Until recently, MeshTool was limited to a 1201×1201 (90 meter) input DEM. The input DEM is a simple grid, and the finished DEM is never higher resolution than the input. So until now, it would have been just about impossible to make a really high res mesh, even if X-Plane could handle it.
The most recent changes to MeshTool fix this – MeshTool can now handle a 10801 x 10801 (10 meter) input DEM, which X-Plane should be okay with as well.
This new version will hopefully go into beta relatively soon.
I’ve been hacking at the scenery tools over the last few days…and I think we’re making some progress. I mention this because it can be hard to see the work getting done – there is nothing for months, then a new version of a tool. (Well, now you can watch the code change as it happens. If you don’t think this like watching paint dry, you might be a geek!) I also mention it because two of the biggest improvements aren’t my own – they’re insanely helpful user contributions.
The AC3D Plugin
Version 3.2 is now in beta. Version 3.2 catches the plugin up with all of the latest OBJ tricks, including dataref-controlled LIT levels, manipulators, hard surfaces, etc. This might be more useful for airplane modelers than scenery modelers, but I think the variable _LIT channels can be used for some interesting scenery effects too.
WorldEditor
WED 1.1 will go beta once X-Plane 930 is out of beta, and will feature (very primitive) overlay editing. It’s not a thing of beauty (yet) – the overlay editing features are leaner than the airport editing tools were. But 1.1 will allow you to edit an overlay and airport in one workspace.
I can tell you now that the area where WED 1.1 is weak is preview. But I don’t want to hold off the ability to edit overlays in WED “at all” just because it’s not as nice as it could be (and someday will be).
It should be possible to work on an overlay project in both WED and OverlayEditor – for example, you could build a taxiway layout in WED, using the overlay capabilities for custom pavement and lines, but use OverlayEditor to place 3-d objects (with a 3-d view).
MeshTool
To be blunt, MeshTool in its current form is really hard to use. Part of that is expected – MeshTool is a “back-end” tool like DSF2Text, aimed to simplify the problem of creating base a base mesh for some other program. But even as a back-end, MeshTool is difficult to use because it has bugs in its polygon processing, which often result in cryptic and hard-to-diagnose crashes when used with even relatively simple input data.
The good news is that I have my base mesh generation code running with a new polygon processing library (
CGAL) – the switchover from my old buggy code to CGAL was done by Andrew and contributed back as a patch. I’ve been throwing all sorts of weird data at the polygon cutting algorithms and they are rock solid.
The mesh generation code is part of MeshTool, so the next build of MeshTool will feature these processing improvements. That’s where Janos’ extensive work on the build environment comes in – he’s basically turned the scenery code from a big pile of my mad ramblings into a sane multi-platform project. This will mean a much simpler, faster process for releasing tools, particularly on Windows and Linux.
(Previously once I got a tool working, I would have to waste a few days trying to get the code to work on Windows too, slowing the whole process down.)
I expect to recut the “scenery tool” pack (that is, MeshTool, DSF2Text, and all of those other smaller apps) some time during WED beta, after 930 goes final. If all goes well, there should be native versions of the command-line tools for Linux.
MeshTool Needs a UI
Fixing MeshTool’s polygon processing is necessary, but not at all sufficient to make it a useful tool; to be really useful, it needs a real user interface. I think there are two strong possibilities for this:
- WED could develop base mesh editing. Under this scheme, you would be able to draw land use polygons in WED and create a “DEM” object for the elevation.
- MeshTool could be an output option for QGIS (via some kind of plugin or script).
I don’t know which it will be yet. The advantage of WED is that an author could have all scenery elements in one place. The advantage of QGIS is that it contains advanced GIS features that I will probably never put in WED. It may be that QGIS’s UI is simply not intuitive to less advanced users – I don’t have good perspective on this.
Posted in Tools
by
Ben Supnik |
