I commented on this before, but, like the Funniest Joke in the World, no one team member has all of X-Plane 10. We’re all working away madly at our own parts, separately. This means that if one of us has code or art that isn’t quite ready for prime-time, it hopefully doesn’t slow anyone else down too much.
I mention this because I see a lot of commentary on the X-Plane 10 preview pictures where the comment is analyzing a part of the picture that actually isn’t X-Plane 10 at all! Those pictures are coming right off of developer machines, and that developer probably has some new stuff and some old stuff. Not only does the developer probably not have everyone else’s parts of X-Plane, but that developer probably has everything except his own work turned off or way down to keep sim load time down. I don’t fly with 20 AI planes when I work on scenery, and Austin doesn’t load full scenery at max res when he works on the flight model.
So when you look at the screenshots, just bear in mind that they are showing one new piece of technology pretty well, and pretty much everything else on screen is going to be hit or miss.
I mean to blog this a while ago, and Austin has moved on to new missives about the future of X-Plane, but:
A while ago Austin posted to the news list describing our approach to global scenery (that is, the scenery that ships with the sim), and he said some, well, rather disrespectful things toward orthophotos:
Orthophotos are garbage. I see this all the time. I am zooming along in an airplane looking that rooftops of WalMarts painted flat onto the ground. And the rooftops are blurry. And pixelated. And with a magenta or purple tint. And with big blurry shears right through the middle of them when they fall between offset satellite passes. It looks just terrible.
So first let me point out a few obvious things:
-
There was never any chance that the global scenery would be based on orthophotos – not in v8, not in v9, not in v10. Simply put, we can’t ship you 900 DVDs in a dump-truck. Orthophotos of any reasonable quality are too large for covering the entire world in the base X-Plane product. This is not a change or new to v10.
-
X-Plane is very capable of handling third party orthophoto scenery. We invested a bunch of engineering in this in the v9 run, and that code is not going away in v10. X-Plane will page orthophotos on multiple cores so that you get smooth flight and crisp images. If you want to see some orthophoto that don’t look blurry or pixelated, look here.
-
DSF-based scenery that works in X-Plane 9 will work in X-Plane 10, unmodified. We are not getting rid of any modern scenery file formats.
Beating Ourselves Up
Austin continues in his rant^H^H^H^Hdiscussion, with this:
Then, to make the 2-dimensional, blurry, pixellated, mis-colored, distorted roof of a WalMart painted on the ground look even worse, if you throw in some REAL roads or auto-generated buildings, they invariably fall ACROSS the roof of the WalMart painted on the ground, compounding the wretched orthophoto with an Escher-like rendering-error. This looks terrible, and is not even plausible.
This is a critique of the version 8 and 9 global scenery. In fact, it is an observation of the fundamental problem with the urban global scenery: we never found a way to synchronize the real-world-driven and real-world derived 3-d scenery (real roads with plausible buildings and forests in between) with the photo-based land-class textures running underneath.
Ironically, this is not a problem with orthophotos (that is, specific photos placed in the world where they belong) per se. It’s really a problem with how to combine 3-d with land class textures. I don’t believe anyone has solved this problem yet for global scenery; if you look at FSX, there isn’t a lot of real world vector data to interfere with the land classes and their autogen.
In fact, orthophotos can look very good when they are combined with 3-d in a correlated way. For example, take a look at this screenshot of FlyTampa’s KBUF . They are using an orthophoto but they are putting matching 3-d on top of it, which makes things look good close up.
The Global Scenery Problem
I’ll leave you with this thought: the problem for the version 10 global scenery is to combine:
- the plausibility that you get from having synchronized 3-d and ground textures.
- the detail we’ve come to expect in photo-based scenery textures.
- the realism you get from using real vector data for the real world.
The current global scenery manages points 2 and 3 but fails pretty badly on point 1. That is what we are trying to address in X-Plane 10.
Put this in the “sometimes bugs make pretty pictures” category…
I’m not sure anyone cares about this kind of thing, but…
These are pictures of a test of the rasterizer. The rasterizer is code in both the DSF creator* and X-Plane that converts polygons into lines or boxes. What good is that? We use it to:
- Plant trees inside a polygonal forest in a DSF.
- Process all of the elevation points inside a polygonal water body when making a DSF.
Etc., etc. These were from a performance test rasterizing the Mississippi delta at 1201 x 1201; because the vector data is insanely detailed (something like 2 million line segments I think) it’s a good test of performance. The blue lines represent a line fit, but the white lines are a “box fit” – that is, they ensure that not only are they “inside” the water, but the area above and below them are too.
* Programming geeks can use this code – it’s in PolyRasterUtils.
This post is a bit of an experiment…we’ll see how it goes. When we cut the global scenery, we do a number of validations: we manually inspect some of the DSF tiles, we examine the Earth orbit textures (which are derived from the DSFs) as a quick way to look roughly at all of the tiles, we have a number of internal consistency checks in the generator, and we can compare our output to some of the input data (e.g. did we lose all of our water) to look for gross bugs. But we don’t have enough resources to manually examine all 18,000+ tiles in detail inside X-Plane.
So: if you have found a defect in a global scenery tile in version 9, please list the tile in the comments section of this post. I will try to give these “previously broken” tiles priority in manual inspection.
Note that the bugs we can expect in version 10 will be very different than in version 9 because we’ve really changed the global scenery generation process in nearly every important way. The underlying algorithms are heavily rewritten and data sources are very different. The goal here is to simply find areas that might have a higher probability of weirdness.
Let me try to be clear about what constitutes a broken tile and what does not. Please read this definition six or seven times before you post a comment.
- Do not report bugs of inaccurate data. If your favorite road is missing, or the coastline is in the wrong place, don’t report that here. That is not a defect in the rendering process; rather it is a limitation in the source data. I am not trying to collect a list of data inadequacies. We have already selected the new data for the new render. “Stuff is in the wrong place” is not a bug for this list!
- Really weird patterns are of interest. For example: I have seen some reports of very long thin bars of land going perfectly north along the edge of the tile, or a comb of mountain and valley, again perfectly vertical. These are bugs in the production process and I do want to know about them!
- Do not report errors in the placement of the 3-d layers (trees, roads, etc.). Since the 3-d layer is being completely rebuilt for version 10, none of these defects will be present in version 10. (They’ll be replaced with a totally new set of weird behaviors!)
- If an airport is too bumpy to use (with “flatten ” turned off in the sim), report this only if the terrain around the airport is grass. Basically the grass means that we tried to “fix” the airport in the v9 render and failed. If there is no grass (the airport is over forest or city) and it is bumpy, do not report it – that means it was added to apt.dat later.
- Do not report mismatches between the airport shape and the grassy patch; this is just the apt.dat file being updated.
If you have something to report (basically incorrect flattening of grassy airport areas and really weird coastline/terrain bugs that are clearly programming errors) please include three pieces of information:
- The DSF tile, e.g. +42-072
- The nearest ICAO of an airport near the bug (e.g. KBED)
- A very short description of what went wrong (e.g. “tall thin vertical lakes running through the entire DSF”).
Please only post defects of the above nature in the comments section of this blog post; to keep things clean I am going to nuke any off-topic comments on this post.
EDIT: see the first Squawk, Arista’s report on LOWS. This is a perfect report: it includes the DSF tile, the ICAOs, a brief but clear description, and it is a bug in how we process the data, not the data itself.
If you are planning on submitting an airport layout to Robin so that it is used to flatten terrain in the X-Plane 10 global scenery, please submit the layout to Robin no later than October 10th, 2010 (that is, 10/10/10).
If you have an incomplete but useful layout (e.g. the airport border is in place but not the taxiway signs, you can still submit it; we only consider border outlines and the pavement itself when flattening, not markings.
You do need both the border outline and all existing pavement. The reason for this is that the airport border is used to change the land class to grass, but water is only converted to land (if we have a coastline error) base on real pavement.
More info on airport layouts and how to submit data to Robin can be found here.
I posted a quick tip on how to create fence-like facades in WED. Basically WED doesn’t handle fences and other non-closed polygons very well, but you can work-around this. A future version will address this more completely.
This is my thinking on the WED roadmap:
-
WED 1.1 will relatively ship soon, without cosmetic and usability improvements. At this point the basic bugs (import/export) are fixed, so best to get out a finished, stable build so that people can at least edit overlays.
-
A future version will provide editing ATC layout information for X-Plane 10. This shouldn’t be too hard to get working, as we already have this in WED now so that we can develop test data for the new ATC system.
-
A future version will provide usability enhancements (e.g. previews of facades, etc.). I don’t have a ton of code done for this yet, but it’s important for everyone using WED for pretty much any purpose.
-
A future version will provide road editing since X-Plane 10 can drape roads.
I don’t know what order those 3 feature will come in, but they will all happen relatively soon after version 10 ships I think.
On my way back from South Carolina a few weeks ago I had some time in the airport to fix the WorldEditor 1.1 export bugs. All of the reports pointed to a single cluster of bugs that are hopefully now fixed in beta 2, and today I finally had time to get the betas posted.
I also cut a new build of MeshTool (2.0RC2) while I was doing builds; this fixes a bug when using orthophotos with varying physics.
So first: you can get the new WED 1.1 beta 2 and MeshTool 2.0 RC 2 on the tools page on the wiki.
The wiki? Yeah. Tyler has been helping me migrate the scenery tools to here. At this point I believe that all of the content on scenery.x-plane.com is now duplicated on the wiki (which also has additional articles).
WED Bugs
If you should find additional WED bugs, after you get over your initial surprise, please file bugs in the scenery tools bugbase. Please do not email me bug reports. WED has to take second priority to version 10 work, so I don’t have time to process bug reports now, and I will lose them. The bug base keeps your bug safe, keeps a record of what happened to it, and can take attachments.
Please do provide the minimal materials to reproduce the bug; simple packages with an earth.wed file are great. Thanks to all of the WED users who filed bugs with repro cases – this made it very easy to retest the export code.
My Polygon is Poly-Gone
It is illegal to have DSF polygons (or airport polygons) cross themselves; finally with beta 2, WED actually makes this case fairly easy to detect.
- If a polygon cannot be exported (because it is self-intersecting), an error message will indicate that some polygons were skipped, and those polygons are selected.
- If you pick “Error-Check Polygons” from the Edit menu, then for every polygon that has a self-intersection, an OBJ is added at the precise point of the self-intersection. Simply select and zoom in on those OBJs – they act as marker pins to show the problem. Delete the OBJs once you have untangled your polygon.
(I did experiment with error checking on the fly, e.g. simply showing red dots in the intersection points as you drag and resize the polygon, but the math is too slow. I am using CGAL to check bezier polygon intersections, and their algorithm is absolutely rock solid, but it can take up to a quarter of a second to recheck the polygon, which is too slow for interactive editing.)
UPDATE: beta 2 hangs when processing beziers. What is very odd is that this happens on the clean release code but not the working copy of WED I fixed the bugs in. Hence, when I checked all of the bug reports, they all passed. I have reopened all bezier-related bugs. I have not yet located the build environment differences causing the problem.
UPDATE 2: the hang on bezier processing was due to a bad compile configuration for a library WED uses, and was Mac specific. Having fixed this, I have recompiled and reposted WED beta 2 for Mac. If you already grabbed WED, re-download it, and make sure you get the version dated September 24th. You can tell you have the right one because the “compiled on” date in the about box will say “Sep 24 2010 19:34:09”.
I wrote up some performance tuning notes for OBJs on the wiki. A few notes on how these rules will change with version 10:
-
Everything on that note applies to version 10 too. If you’ve tuned your model for version 9, that effort will be worth it in version 10.
-
A few rules are even more important in version 10 than before. In particular, I’ve done a lot of performance tuning for OBJ drawing, but you don’t get those wins if you use ATTRibutes. Clean your objects out for maximum speed.
-
One special case: objects with very small vertex count are sometimes extra fast in version 10. For example, in version 9, a tree with 8 vertices and no attributes is horribly slow. In version 10, this tree will be quite fast. So in version 9 you might make the tree have 64 vertices and look nicer; in version 10 by keeping the tree lean and mean, you get a speed improvement.
Normal maps are expensive. A 2048 x 2048 normal map takes 22 MB of VRAM! So make sure you get every bit of image quality you can out of it. Two things to consider:
- Normal maps are uncompressed (because texture compression really screws up the normal map). So per-pixel detail will be preserved. Use it!
- VRAM is allocated for an alpha channel whether you use one or not. This is because the cards need 32-bit pixels for performance. So include an alpha channel in your normal maps and use it to modulate shininess; this can help create the illusion of different materials.
For scenery objects, do not include an alpha channel if you don’t need it. When textures are compressed, the alpha channel does take more VRAM, and X-Plane will hit a faster rendering path for textures with no alpha channel.
