Tom has a new video on youtube of his just finished Falco. The video shows what screen-shots cannot: that the mouse interactions on the plane are really well crafted.
If you’re just discovering X-Plane (or just discovering that X-Plane’s 3-d cockpits can be very interactive), here’s X-Plane’s “raw” capabilities for manipulation:
- The simplest manipulations are based on mapping the mouse from the 3-d cockpit back to the 2-d panel. This can only be done when the 3-d cockpit is textured using a piece of 2-d panel. This is the oldest way to make a clickable cockpit in X-Plane, dating back to the original X-Plane 3-d cockpits. The advantage of this method is that it’s very easy to set up; the disadvantage is that the mouse click gestures tend to be “flat” in their operation.
- As Tom’s plane demonstrates, you can manipulate just about any dataref or command via a drag along a specific axis. Axes are subject to animation, so there’s a lot of potential for “grabbing” things with this interface.
- X-Plane also supports direct “click” manipulation – this can be handy for buttons where you don’t want to require the user to move the mouse around. There are several types of click manipulation.
Click and drag manipulations can be tied into the plugin system – your plugin sees a manipulation as a change to a plugin-created dataref. This makes it possible to create almost any imaginable mouse effect. If you don’t want to write a plugin, you can still write up the manipulators to any of X-Plane’s datarefs (there are thousands) or commands (we’re getting up toward the 1000 mark on these too).
To create manipulators on your cockpit, you can use the latest plugin for AC3D. A manipulator is a property on a mesh within your object – each mesh can have its own manipulation with its own properties.
X-Plane does not have an IK solver. Rather, movement of “stuff” in your cockpit is indirect.
- Your manipulator changes a dataref as the user drags along an axis.
- The dataref change shows as an animation on your mesh.
Fortunately, ac3d has a “Guess” button for the axis manipulators. If you set a mesh to be manipulated by dragging along an axis, the guess button will examine your animations and suggest an axis that will create the most “natural” looking animation for the manipulation. For example, if you have a throttle handle that rotates, the guess button will provide a drag axis perpendicular to the throttle (to push the levers); if you have a throttle lever that pushes, the guess button will make a drag axis that runs along the lever.
I’ve been on the road a lot for work, so my apologies to everyone whose email I am sitting on. Most of my time these days is being spent on new next-gen tech. But there are a few things I’m hoping to get done in the short term:
Cut a new time-demo test. This might seem like a low priority item, but it’s not. Apple, ATI and NVidia all run continuous automatic tests of their video drivers, with many applications and games. They have rooms full of computers that continuously run through 3 minute sections of Quake and Call of Duty, etc. If they introduce a driver bug while doing new development, these machines catch the problem immediately.
The new time demo (based on 945) will have a number of features to make X-Plane a more useful test case. If we can make X-Plane into a test case, then they can catch bugs early, and that means you don’t have to see them.
Bring WED 1.1 to beta. The only thing holding it back is the DSF exporter, and I did have about two hours to poke at it last week. I’m hoping if I can find just a few more hours, I can finish off the exporter.
Examine 950 bugs. I have half a dozen bug reports against 950 beta 1. 950 will be a small beta but also a slow one, because Austin and I have a lot of other things on our plates. If you haven’t heard back from me on a bug report, probably it’s still on my to-do list.
We’ll see how much of that I can get to in the next week.
There’s basically one reason why WorldEditor developer preview 2 is a “developer preview” and not a real beta: the DSF overlay export code isn’t complete.
The problem is that, unlike an airport, an overlay has to be “cut” to the DSF tile boundaries. This is made slightly tricky by the fact that the overlay can have (1) bezier curved segments and (2) a UV map on those segments. My existing toolkit of polygon editing routines doesn’t handle this case yet.
I have no idea when I will have time to complete this code. It is the number one piece of code that, if I had a quiet single afternoon of unexpected time to code, I’d pound it out. If I were stuck in an airport with my laptop, I’d pound it out. It should give you some idea of how busy things are that it still isn’t done.
In the meantime, there is the scenery tools bugbase. By filing a bug, your issue won’t get lost even if it’s a while before I get to it.
A few quick rants about the bug base:
- Most likely the first thing I’ll do when I do get to your bug is just ask you for more info. Consider the bug to be as much a business card so I can make contact as well as a bug report.
- Some bugs may get kicked out.
- Do not file X-Plane bugs in the scenery tools bug base! The scenery tools bug base is not where we store sim bugs.
Do not bother to ask for direct bug base access for X-Plane itself. You cannot have it. The ratio of submitted “bugs” for X-Plane to actual bugs is at least 10:1. That is, 90% of you think that you should file a bug when you have a tech support question. Now you might be in that 10% (particularly if you’ve made it all the way down to this blog post), but we can’t set up open infrastructure with those numbers. My hope is that the scenery tools are self-selecting to the point where people who are using developer-preview tools know what a bug report is.
I just finished fixing some bugs with WorldEditor and DSF precision. A WED user was seeing draped polygon tiles exporting with alignment error, and the culprit turned out to be DSF precision. This begs the question, how precise are the lat/lon coordinates in a DSF?
DSFs are based on 16-bit coordinates, for a precision of one part in 65536. Now before you go screaming that 16-bit is dreadful, here’s the key: those 16-bit coordinates are interpreted within an arbitrary sub-rectangle of your tile, called a “pool”. If we only had one pool covering the DSF we’d have 1.5 meter precision. But by having many smaller pools, we can have high resolution within a pool.
All of the current DSF writing tools from Laminar Research are based on DSFLib, and DSFLib will create a number of pools along a pair of offset grids. In practice what this means is that you specify a number of pools across the DSF.
In WorldEditor 1.1dp2 the DSF exporter uses 8 pools. Since a DSF is about 100 km across, each pool is 12,500 meters in size, and the internal resolution of each pool is 19 cm. This is pretty good but there are cases where you can see the limits of precision. The new code (which will be in preview 3 or beta 1) uses 32 pools, for 5 cm precision.
If you use DSF2Text, you can simply use the DIVISIONS command to specify how many pools you want.
WorldEditor’s internal representation is 64-bit floating point, which gives precision better than 1 mm.
In MeshTool 2.0, you can specify how wet orthophotos are handled. There are three possibilities:
- The orthophoto has no alpha-based water. The alpha channel will be ignored.
- The orthophoto has alpha-based water. Draw water under the alpha, but for physics, make the triangles act “solid”.
- The orthophoto has alpha-based water. Draw water under teh alpha, and for physics make the triangles act “wet”.
The reason for 2 and 3 is that the X-Plane physics engine doesn’t look at your alpha channel – wet/dry polygons are decided on a per triangle basis. (The typical work-around is to use the “mask” feature in MeshTool to make some parts of the orthophoto be physics-wet and some physics-solid. This is described in the MeshTool README.)
Whenever possible: don’t use alpha-based water at all. It is certainly easy to set all of your orthophotos to alpha-water + physics-solid, but there are three costs to this:
- You eat a lot of fill rate. X-Plane manages alpha=water by drawing the water underneath the entire orthophoto, then painting over it with the orthophoto. This is fill-rate expensive. If you know there is no alpha, tell MeshTool, so it can avoid creating that “under-layer” of water.
- If the terrain is very mountainous, you may get Z-buffer artifacts from the layering, particularly for thin, spikey mountains (which probably aren’t wet anyway).
- The reflection engine tries to figure out the “surface level” of the water, but it doesn’t understand the alpha channel on top of the water. So all of that water “under” your mountain or hill is going to throw the reflection engine into hysterics.
Limiting the use of water under your orthophotos fixes all three problems.
A few quick notes on the various betas floating around:
X-Plane: with the 9.4x series we are trying to fix small one-off bugs and improve stability. The BK-117’s throttles will be fixed in the next beta, and we fixed a crash with a third party orthophoto scenery pack.
This goes for any beta, but: if you have an add-on that used to work on an older build (especially 940) and it does not work, please report this immediately! There are no intentional add-on compatibility breaks in this patch.
WorldEditor: apparently developer preview 2 doesn’t contain the latest texture coordinate editor (TCE) code, so I will try to cut a preview 3 soon. The texture coordinate editor is a new small editor that lets you specify the texture placement on draped polygons. This facility lets you create custom markings. (The current TCE in preview 2 apparently doesn’t have snap to grid and a few other useful features.)
What’s holding us back from a real beta? The problem is that the DSF export of draped polygons cannot split bezier curved polygons (especially with texture coordinates) across the boundaries of DSF tiles. Since I don’t have an algorithm implementation for this yet, I’m not sure how soon I will be able to fix it. For now, don’t try to export a DSF polygon that spans DSF tiles.
MeshTool 2: beta 4 seems to be a keeper. I hope to cut an RC some time in the next week. (You can see the results of MeshTool 2.0 in these FranceVFR preview pics.)
First, Merry Christmas and seasons greetings to, well, pretty much everyone – it’s been great to hear from everyone over the last week. I had a chance to poke at the scenery tools and have posted two new beta builds:
- MeshTool 2 beta 4.
- WED 1.1 developer preview 2.
You can download them both here.
MeshTool 2 beta 4 should be the last MeshTool beta short of bug fixes – that is, I’ve taken feature requests during the MeshTool beta, but I think we have what we need. Future feature enhancement will go in a later version.
Besides some useful bug fixes, there are two new features in this beta:
- You can specify a specific land class terrain with a shapefile.
- You can control the physical properties of orthophotos (are they wet or dry) with a shapefile without cropping out the water. This is useful for authors who want to use translucent orthophotos to create tinted water effects like coral or shallow sandy bottoms.
The WED developer preview simply puts up more bug fixes. WED isn’t quite beta because of one nasty limitation: the code that exports UV-mapped bezier curves doesn’t handle polygons that cross DSF boundaries. This code is going to be very difficult to get right – the combination of bezier curves, polygon cutting, and UV maps is a bit of a witches brew. Since WED isn’t really complete without this, I’m not calling the build a beta.
Also a docs update: I have posted the WED and Ac3d manuals in PDF form directly on the website. The AC3D manual (and motivation to do this) are thanks to Peter, who converted the manual from readme-text to PDF. I was shocked to realize the ac3d README is almost 20 pages. Hopefully having the manual in PDF form will help people realize just how much documentation is crammed in there.
I have two fundamental “rants” about flight simulator scenery, and the way people discuss it, market it, compare it, and evaluate it. The rants basically go like this:
- Mesh resolution (that is, the spacing between elevation points in a mesh) is a crude way to measure the quality of a mesh. It is horribly inefficient to use 5m triangles to cover a flat plateau just because you need them for some cliffs.
- At some point, the data in a very high mesh becomes misleading. You have a 5m mesh. Great! Are you measuring a 5m change in elevation, or is that a parked car that has been included in the surface?
X-Plane uses an irregular mesh to efficiently use small triangles only where they are needed. I have some pictures on this here.
But it brings up the question: how good is a mesh? If you make a base mesh with MeshTool using a 10m input DEM (the largest DEM you can use right now), the smallest triangles might be 10m. But the quality of the mesh is really determined by the mesh’s “point budget” – that is, the number of points MeshTool was allowed to add to minimize error.
MeshTool beta 4 will finally provide authors with some tools to understand this: it will print out the “mesh statistics” – that is, a measure of the error between the original input DEM and the triangulation. Often the error* from using only 1/6th of the triangles from the original DEM might be as little as 1 meter.
I spent yesterday looking at the error metrics of the meshes MeshTool creates. I figured if I’m going to show everyone how much error their mesh has with a stats printout, I’d better make sure the stats aren’t terrible! After some debugging, I found a few things:
Vector features induce a lot of “error” from a metrics standpoint. Basically when you induce vector features, you limit MeshTool’s ability to put vertices where the need to be to reduce meshing error. The mesh is still quite good even with vectors, but if you could see where the error is coming from, the vast majority will be at vector edges.
For example, in San Diego the vector water is sometimes not quite in the flat part of the DEM, and the result is an artificial flattening of a water triangle that overlaps a few posts of land. If that land is fairly steep (e.g. it gains 10+ meters of elevation right off the coast) we’ll pick up a case where our “worst” mesh error is 10+ meters. The standard deviation will be
The whole question of how we measure error must be examined. My normal metric is “vertical” error – for a given point, how much is the elevation different. But we can also look at “distance” error: for a given point, how close is the nearest mesh point from the ideal DEM?
“Distance” mesh point gives us lower error statistics. The reason is because when we have a steep cliff, a very slight lateral offset of a triangle results in a huge vertical error, since moving 1m to the right might drop us 20 meters down. But…do we care about this error? If the effective result is the same cliff, offset laterally by 1m, it’s probably more reasonable to say we have “1m lateral error” than to say we have “20m vertical error”. In other words, small lateral errors become huge vertical errors around cliffs.
Absolute distance metrics take care of that by simply measuring the two cliff surfaces against each other at the actual orientation of the cliff. That is, cliff walls are measured laterally and the cliff floor is measured vertically. I think it’s a more reasonable way to measure error. One possible exception: for a landing area, we really want to know the vertical error, because we want the plane to touch pavement at just the right time. But since airplane landing areas tend to be flat, distance measurement becomes a vertical measurement anyway.
So there I am working with a void-filled SRTM DEM for KSBD. I have cranked the mesh to 500,000 points to measure the error (which is very low, btw…worst error 3m and standard deviation less than 15 cm.
But what are those horziontal lines of high density mesh?
I wasn’t sure what those were, but they looked way too flat and regular. So I look at the original DEM and I saw this:
Ah – there are ridges in the actual DEM. Well that’s weird. What the heck could that be?
This is a view with vector data – and there you go. Those are power lines.
The problem in particular is that SRTM data is “first return” – that is, it is a measurement of the first thing the radar bounces off of from space. Thus SRTM includes trees, some large buildings, sky scrapers, and all sorts of other gunk we might not want. A mesh in a flight simulator usually represents “the ground”, but using first return data means that our ground is going to have a bump any time there is something fairly large on that ground. The higher the mesh res, and the lower the mesh error, the more of this real world 3-d coverage gets burned into the mesh.
So Do We Really Care About 5m DEMs?
The answer is actually yes, yes we do, but maybe not for the most obvious reasons.
The problem with raster DEMs (that is, an elevation as a 2-d grid of heights) is that it doesn’t handle cliffs very well. A raster DEM cannot, by its very format, handle a truly vertical cliff. In fact, the maximum slope it can create is based on
arctan(cliff height / DEM spacing)
Which is math to say: the tighter your DEM spacing, the higher the maximum slope we can represent for a given cliff at a certain height. Note that the total cliff height matters too, so even a crude 90m DEM like SRTM can represent a canyon if it’s really huge**, but we need a very high res DEM to get shorter vertical surfaces.
So the moderated version of my rant goes something like this:
- High res DEMs input DEMs are necessary to represent small terrain features that are steep if we are using raster DEMs.
- High res meshes are not necessary – we only need res for part of the mesh where it counts.
- Let’s not use mesh res to represent 3-d on the ground, only the ground itself.
There is another way to deal with elevation besides DEMs, and in fact it is used for LIDAR data (where the resolution is so high that a raster DEM would be unusable): you can represent a as a series of vector contour lines in 3-d. The beauty of contour lines is that they represent cliffs no matter how steep (up to vertical), and you don’t need a lot of storage if the ground is not very intricate.
The meshing data format inside MeshTool could probably be made t
o work with contours, but I haven’t seen anyone with high quality contour data yet. We’ll probably support such a feature some day.
* Really this should be “the additional error”, because when you get a DEM, it already has error – that is, the technique for creating the DEM will have some error vs. the real world. For example, if I remember right (and I probably do not) 90% of SRTM data points fall within 8m vertically of the real world values. So add MeshTool and you might be increasing the error from 8m to 9-10m, that is, a 12-25% increase in error.
** For the SRTM this might be a moot point – the SRTM has a maximum cliff slope in certain directions defined by the relationship between the shuttle’s orbit and the latitude of the area being scanned. The maximum cliff at any point in the SRTM is 70 degrees, which can be represented by a 247 m cliff using a pair of 90m posts.
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?”)
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.