Thursday, September 30, 2010
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.
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.
Thursday, September 23, 2010
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).
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.
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".
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 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.
Tuesday, September 21, 2010
DDS - The Good, The Bad, the Ugly
DDS is a file format that contains image data pre-mipmapped (that is, the smaller versions of the image that the video driver needs are included) in a format that may or may not be compressed. DDS is virtually always used with a compressed image format (like DXT1 or DXT5). This has three positive effects for X-Plane:
- Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
- Because small versions of the image (the "mipmap pyramid") is already in the file, we save time down-sizing the image with the CPU, another win for load time.
- Because the image is compressed ahead of time, it can be compressed with a slow high quality compressor rather than a fast low quality compressor, so relative to other compressed images we get an image quality improvement.
What If VRAM Grew On Trees?
My original heavy arguments for DDS were based on the idea that VRAM is a limited commodity; if we don't compress textures, the user runs out of VRAM faster and has to go down a level of resolution...and once that happens, everything starts to look ugly.
But what if the user has 1 GB of VRAM? At this point, we've limited the maximum quality the user can see because we don't have the original uncompressed image anymore, only the DDS/DXT version. This can be frustrating to authors who spent a lot of time on their textures.
If you ship PNGs with your airplane or scenery, turning off texture compression will reveal this beautiful, uncompressed image, but now when texture compression is on, the compression will be done by the video driver, and that will look extra ugly.
The Best Of Both Worlds
This is my thinking for version 10. (These are just musings, we haven't coded this yet.) Currently DDS are preferred to PNG files. We could relax the load rules in version 10 to prefer PNG over DDS when texture compression is off and DDS over PNG when it is on. This would allow authors to ship both PNGs and DDS files and have the right one be picked for the scenario: the pre-compressed one when texture compression is on and the uncompressed one when compression is off.
Monday, September 20, 2010
The major features that we are putting into X-Plane 10 were decided, for the most part, a long time ago. Those who we met in France two years ago won't be surprised by the major items on the list: weather, ATC, airports, and new scenery, new shaders. For that kind of major feature work, we have to start an initiative very early on. Heck - global sun shadows (which I believe we will ship in v10, God willing) were in the works before version 9.0 shipped - it took that long to get an implementation that was useful! (In fact, the v9.0 version was not released because the quality was bad, which is why I am always nervous about announcing features in advance; it ain't over until it's over.)
So while it's exciting to see so many people discussing X-Plane 10, realistically if a feature is a "big" feature and we haven't started it now, it's not going into 10.0. That train left the station over a year ago.
There have also been two complicating factors that have cropped up during the X-Plane 9 run:
- Microsoft closed ACES, which definitely changes what we want our next major release to look like.
- The iPhone came along - until the first iPhone release, we had no idea that it would be such a big product.
So bear with us - a lot of what I see are good ideas that we will get to soon, even if they don't go in the initial roll-out.
Sunday, September 19, 2010
I would like this relationship to be two-way, with give-and-take. It doesn't seem fair that in every case, we should have to change X-Plane to model reality. So I humbly submit to the X-Plane user community: my requests for changes to reality to ease X-Plane development.
No Wind Near Water
My first request is a simple one: can we simply not have any more wind over the ocean? Ocean waves are hard to model. They are non-sinusoidal, they don't repeat, they're refractive, and they go for miles. If we could simply eliminate the wind, then we could model the ocean as a nice calm glassy lake, which would be quite a bit simpler to get right.
Only One Building
My second request is a modest one: from now on, I would like everyone to live in the same type of uniform house. It can be a nice house (several stories, with a pool in the house), but everyone's house should be the same. We have some new instancing technology for version 10; it reaches peak efficiency when a single building is repeated ad infinitum. So if you could all agree on a single house type, it would be good for everyone framerate wise.
(I realize that some of you in subdivisions in the US that already do this; hopefully the rest of the world can take a hint.)
No More Intersecting Roads
Alex and I have spent just a crazy amount of time trying to cope with what to do when two roads intersect. So my third request is: no more intersecting roads. I would like all roads to cross each other by some kind of overpass. This will eliminate a lot of artifacts.
In fact, for extra credit, if all roads could be aligned to be precisely north-south or east-west in a grid, that would be good for RAM use.
No Variation in Climate
This one isn't so important for me, but I think the art team might appreciate it. It turns out that different parts of the world have different temperature variations and rainfall, and that in turns makes the local color of grass, trees, etc. a bit different. This just makes work for our artists - they have to draw everything several times for the different climates. It would help us out a lot if you could all live in places with the same annual rainfall and temperature variation.
(Just in case this climate thing turns out to be true, I suggest everyone settle on the "hot dry" climate pattern - we have pretty good textures for that.)
Pave the Bay
Finally, when in doubt, use asphalt. We have some new shaders in version 10 that will make asphalt look pretty good.
Anyway, this is my list - I am sure the other X-Plane developers will have other requests. (I suspect Austin's life would be made easier if weather was always CAVOK, and Chris's life would be greatly simplified if there weren't any other airplanes in the sky.)
Do you have any hints as to when this new version of reality might be released, or what its minimum system requirements are?