Just a quick note re: comments. Recently this blog has been attacked by spammers who copy existing legitimate comments and re-post then; their user name is a link to a click-harvesting web-site. I am doing my best to mark these comments as spam and not allow them.
Besides that, I am likely to nuke any comments that contain profanity, spam, repeated requests for tech support via the blog, and off-topic comments particularly on posts that have are meant for a narrow discussion (e.g. global scenery defects).
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 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.
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”.
Quick airplane links:
- Carenado’s Mooney M20 J is out, available on the X-Plane.org store.
- Javier’s T34c Mentor is out, available at X-Aviation.com.
Pictures available in both links.
X-Aviation has released the Duchess, pics here.
Carenado is coming to X-Plane, initial pics here.
There have been a few posts about X-Plane 10 in a few random places; here is a summary of all of the version 10 material that’s been previewed so far, and some notes on what is actually being shown.
First we had Paul’s Oshkosh 2010 video:
//www.youtube.com/watch?v=yCoDPNvOMP0?fs=1
I think this has been made clear already, but:
- The base simulator shown here is not X-Plane 10, it is X-Plane 9.
- Many of the airplanes shown here will be released for X-Plane 10.
- This is not showing the new X-Plane weather system or global lighting.
- Some of the content shown here are third party add-ons, available today for X-Plane 9.
The main purpose of this video was to show X-Plane off at Oshkosh; at the time we didn’t have X-Plane 10 in a state where we could do an exclusive version 10 preview.
Then I accidentally leaked two test videos of global illumination. This was strictly accidental: I was looking for a cheap way to post a large video for Austin and Propsman late at night and didn’t think anyone would sift through 191 zip files to find two obscurely named videos. I was wrong, and someone found them on the org. I appreciate that participants in the ensuing discussion withheld judgment; these were early test videos and don’t represent the final feature in any useful way. They do, however show off some of what global lighting will mean.
- This is the Cirrus Jet with landing lights implemented via global illumination. We get two distinct landing lights that cast specular hilights on the fuselage. As the door animates, it opens “into the light”.
- This is the Avanti Piaggio with strobes and beacons implemented via global illumination. The strobes cast light both on the fuselage and on the runway below the plane.
This second movie is typical of the kinds of tests I do: the beacon lighting is just awful – a gross huge red light splatted on the plane for test purposes. When I get the rendering engine code working I usually hand the feature off to Propsman or Sergio to tune the textures and art constants. In this case, the videos are pre-tuning.
Austin has posted three screen-shots of X-Plane 10-related content:
-
This is Javier’s new shuttle, which I believe will ship in version 10. I believe this shot may have been taken in X-Plane 9. So this is not the new weather system.
Some of these screenshots and Paul’s video were shot in X-Plane 9. By the time the new airplanes are finished, they will not be usable in version 9 – they will be version 10 only.
-
Propsman has done work on the lighting system. It can be subtle to see what’s going on here because the old runway lights looked pretty good too, but most of these billboard lights are actually rebuilt.
-
This night shot shows global illumination in the scenery system. The glow on the highway pavement is not rendered; it comes from the 3-d lamps along the side of the road. Similarly, the car headlights spill light on the pavement and each other as they drive. (Note how the highway lines are visible in the headlight spill even when there is no streetlight.)
One difficult problem with rendering a lit highway at night is that the lighting from street lamps on a highway tend to spill light on the surrounding terrain, an effect that is impossible to create with a LIT texture. If you look at the right side of the main highway at the bottom of the picture, you’ll see that the street light is casting light on the grass to the right of the highway too.
I think that that’s all we have posted. At least, it’s all I am aware of. I will go into some of the details of global illumination in another post.
I’ve been working on road processing today; one of the tricky problems with OSM data is that, because an OSM map is often a collection of vectors from separate authors, the results can be a huge number of very small segments, as nearby road features from different data sources cross each other. (Basically you get “thrash” between the two vectors from different sources and our tools solve this by adding a huge number of extra vertices.)
I am trying to run this data through an algorithm called Iterative Snap Rounding (ISR) to reduce this mess of vertices, and for the purpose of this blog article there’s one thing you need to know about ISR: it is really, really slow. So for the next few minutes, I figured I’d start poking at some of the issues that came up at the X-Plane Congress in France this summer.
One question that came up was whether/when X-Plane will go 64 bit. Here’s my current thinking:
We can’t drop 32-bit X-Plane. Too many users have a 32 bit operating system, or a 32-bit CPU. One thing I have been resisting for X-Plane 10 is a ratcheting up of the system requirements to only top-end game machines. While 64 bit is becoming more prevalent and has the potential to be a big win for users who load the sim up with third party add-ons and have a high-end graphics card, plenty of people buy a computer first and then discover X-Plane. Those users will often have a system that is low end (by X-Plane standards).
If we start cranking the system requirements (you have to have 64-bit, you have to have a DX10 class graphics card, you have to have 2 GB of RAM) then more users who might discover X-Plane won’t even be able to run the demo, and that will be bad for X-Plane’s growth.
So the question is not “when will we switch from 32-to-64 bit” – it is “when will we support both 32 and 64 bit.”
I think we will get there during the version 10 run, but I don’t think it’s that likely that we’ll ship 64 bit right out of the box. 64 bit is more of a performance enhancement* than a new feature. The features we have strong motivation to get into 10.0 are:
- Anything that raises the system requirements, because we don’t want to raise system requirements after we ship in a free update.
- Anything that enhances the authoring SDK, where it might be useful for authors to know that every version of X-Plane 10 has a feature.
- Of course, we want to ship any feature that looks really good and gets people excited.
- Foundation features that support other featuers have to go in first. So some enhancements that will ship in 10.0 are there because without them other tech couldn’t be rolled out.
64 bit is important, but it is a feature that only helps some of the user base, and helps by making the sim more expandable; the sim is still usable without it. So we’ll get there, but new features are a zero sum game so I think 64 bit is more likely to be a free patch than in-the-box.
(At this point I expect the various 64-bit OS users who have been asking for a 64-bit app for years to flame the heck out of me and point out that I am a cranky old bastard who doesn’t realize that 64 bit is now everywhere and totally pervasive and that this is therefore the most important thing we could possibly do. Before you dig in, hang on one second, let me put on my asbestos flame-retardant jacket. Okay…fire away. 🙂
Oops…ISR just finished…with a seg fault. Gotta go!
* As a performance enhancement, 64 bit is a weird one; because a 64-bit app uses more memory for pointer-based structures, the same data structures become larger, thrashing on-chip caches more. The real benefit to 64 bits is to allow X-Plane to use more than 3 GB of physical RAM.
Austin attended the French X-Plane Congress last weekend; in response to some questions I have received, I want to clarify what is planned for DSF and X-Plane 10.
X-Plane 10 will extend DSF scenery capabilities by providing a number of new art asset types, as well as extensions to existing art asset file formats. We will not be changing the DSF file format or breaking compatibility with existing DSF scenery. If your DSF scenery works with version 9, I expect that it will work with version 10 as is.
(In fact, it looks like we do not even need to add new DSF extensions; DSF was designed to be a generic container for geometry data and properties, so we can usually extend X-Plane’s scenery system by simply defining new art asset classes and properties.)
An example will illustrate what I mean by extending the art assets, not DSF.
In X-Plane 9, you create a forest (whether in a base mesh or overlay DSF) by creating a DSF polygon referencing a .for (forest) art asset. X-Plane will render this by filling the area inside the polygon with lots of trees.
In X-Plane 10, you will be able to optionally tell X-Plane to put the trees only on the edge of the polygon, rather than filling the entire inside. (This feature will be controlled by using values on the polygon parameter that are larger than 255, at least I think.) This will mean that you can use .for files and DSF polygon not only to create forest areas, but also to create rows of trees along the edges of roads or fields. A row of trees made by a .for file and DSF polygon will render much faster than a large number of individual OBJ-based trees.
This kind of art asset extension is similar to what we have already seen; X-Plane 850 introduced three new art asset types (.str object strings, .lin line paint, and .pol draped polygons) that all produced new rendering tricks using DSF polygons. These art assets were added to provide high performance rendering of airport surface areas. The new art assets didn’t require any change to DSF because the representation of the position of these art assets is something DSF has always done: simple polygons.
DSF won’t last forever, but at least for X-Plane 10 it looks like we can do a third full cycle of the sim using DSF as our base container format for scenery position data.
