From fearless leader:
X-Plane 9.68 is here (in Beta) for Mac, Windows, and Linux!
Just some TEENY little tweaks and enhancements to make v9.xx perfect:
- new airport and NAVAID data
- fix for lighting in non-generic instruments with esys (rare bug)
- sound stays on when X-Plane is pushed to background on windows… as requested, and now in sync with Mac version for better consistency
- improvement in the situation saving and loading
Just run your installer (from X-Plane.com) with the BETA options turned ON to get it
Have at it and let me know how it goes!
austin
ps: X-Plane 10 is much, much, much slower in coming along than I planned.. but it is much, much better as well. It is slow because I have raised the bar ridiculously high for this release, simply because I CAN. SO, I am keeping v9 totally bug-free while v10 is developed, which I am hoping to have ready by the end of this year.
I am hoping to have v10 ready quite a bit sooner than that.
One user asked me about slow performance with an overlay scenery he created using GMaps. There are three things you need for fast orthophotos in X-Plane, and unfortunately his scenery is missing one.
Use DDS
I’ve written before about DDS. They key points here for orthophoto performance are:
- Since DDS is already compressed, the CPU has to do less work preparing the texture if it is going to be compressed.
- Since DDS is already pre-minified (meaning the smaller versions of the texture are already computed), if you are not running at ‘extreme’ resolution, the sim can simply load a lower res version. With png, X-Plane must load the full size version and scale it down on the CPU.
- Since DDS is already pre-minified, the sim doesn’t have to compute those minified versions of the texture on the CPU.
All of these things lead to much faster texture load times with DDS.
Use LOAD_CENTER
LOAD_CENTER is a directive that can be put in a .pol or .ter file to tell X-Plane at what location the texture needs to be at maximum resolution; X-Plane will reduce the resolution of the texture as you fly away from that point. LOAD_CENTER is important for orthophotos for a few reasons:
- It saves VRAM, since textures that are far away won’t be loaded at full resolution.
- When combined with DDS, it improves load time. Since some textures are loaded far away, they can be loaded at lower resolution, which (per above) is quick for a DDS file – less data, less load time.
Note that LOAD_CENTER causes X-Plane to reload the textures while you fly, so it requires at least one extra core to work well. It’s really important to use DDS with LOAD_CENTER; otherwise that reload time can get expensive.
Use a base mesh, not draped .pol overlays.
This is probably the most important thing: if you want to cover a lot of area with orthophotos, you need to rebuild the base mesh using .ter files, not cover it with .pol files. There are a few problems with using .pol files:
- Draped polygons are only ‘built’ for areas relatively near the airplane. So even under ideal circumstances, they are going to disappear in the far view. This way of using them (only when near the airplane) is a memory savings based on their intended use: for small surface areas like airports.
- Similarly, since the draped polygons are being built and destroyed as you fly, the amount of extra CPU work while flying is quite a bit higher with .pol files than with a base mesh (which only has to page the actual terrain). So a computer that might be fine paging .ter files can get behind in its work for .pol files. (Authors often use .pol files because they are easy to work with – specify a rectangle and X-Plane does the cutting and slicing…well, that work is happening while you fly, burning up CPU power that could be used to page the orthophotos.)
- Since .pol files cover the base mesh, you pay for your mesh twice – once when X-Plane draws the base mesh and once when it covers over it with polygons. This means twice the VRAM used to draw a frame and twice the fill rate.
If you want high performance orthophotos over an area any larger than an airport or down-town, please use .ter files!
Comments should work again – sorry about that. The anti-spam captcha plugin had a directory permissions problem. We need that anti-spam protection though – without it WordPress is a magnet for spam-bots.
This is a view of the underlying vector data for the current KBOS taxiway layout. It is floating above the ground because the data hasn’t been “draped” onto the layout yet. There are two copies because the data has been debugged once for each DSF tile that the airport spans; when the actual paint is put down, only one copy of the lines will end up on either DSF, so we don’t have double triangles.
These four buildings are facade-scrapers, a new feature in X-Plane 10.
X-Plane 8 and 9 support facades. A facade is a building definition that is extruded to an arbitrary shape and height specified in a DSF. Facades allow us to build custom-shaped buildings that fit a precise footprint. The walls are created by cutting and repeating a grid texture of windows.
With a facade-scraper, two objects are placed in the center of the facade to form a tower. The facade base itself can exactly fit a city block, while the OBJ pair gives us a tower with architectural detail.
This is a wire-frame view; the facade itself is wire frame, and the ground is wire-frame, revealing the two objects. The base of the facade sits on the ground, but the tower can move up and down, with excess underground. This allows us to customize the height of the building to precisely meet the DSF height.
(This facade is a test case that I built out of Alex’s Chrysler building; the UV mapping on the base is pretty rough since I was just creating test files.)
One or two more facade follow-up pictures. Here we have a curved facade airport terminal. There are still some bugs with how the roof and walls go together. A facade definition has two sets of wall definitions: one meant to be curved (with more vertices for smoother curving) and one with fewer vertices for frame-rates when a wall is not curved.
Here is the same picture in wire-frame mode. You can see the second layer of cars. The new facades can have multiple roofs – this feature was specifically put in to allow us to build parking garages.
By request: a series of shadow pictures.
From left to right: no shadows, 1 texture along 500 meters, 2 texture along 500 meters, 2 textures along 5 km, 4 textures along 5 km. The distance is how far into the distance X-Plane tries to apply shadows (longer distances mean more CPU work to shadow more of the world, with less resolution on the shadows) and the number of textures is the number of separate texture shadow maps we apply. The more separate shadow maps we apply, the more resolution we have to work with.
If there’s a take-away point for shadows, it’s this: they’re really freaking tweaky. They can look really good or really bad. The shadows you see here are not at all done; we still have a lot of tuning and optimization to do. But these pictures will give you an idea of why we didn’t ship shadows in version 9 (the way I had hoped to): when they look bad, they look really bad.
I suspect we’ll have rendering settings to let you use more shadow maps to get nicer shadows at lower fps, or tune them down for more speed; we already have this with the reflection detail rendering setting.
One difference between X-Plane 10 development and previous development efforts is that, because we have a fairly large art team (by LR standards), we’ve been developing a lot of the tools for version 10 scenery/airplane development during the main development cycle. In the past, we’ve gotten the sim out, then added the tools later; I think the delay will be a lot shorter this time around, since many of the tools more or less work.
For WED, we have some of the new 10.0-related features controlled by #define; they’ll remain off for WED 1.1 (which basically makes WED a DSF overlay editor for X-Plane 9.0) and then go into a WED 1.2 release. I think the timing will be tight – that is, we’ll get 1.1 finished during or right after X-Plane 10 beta, and then have a development preview of WED 1.2 almost immediately, by exposing the new features we are using internally.
What will be in the next crop of WED features for X-Plane 10:
- ATC taxiway layout editing for the new X-Plane 10 ATC system.
- A few more DSF tricks, like forests that render trees on the polygonal outline instead of the interior.
There are also some 1.2 features that we’ll get eventually that are in rough or partial shape right now:
- Autogen placement (works pretty badly right now).
- Road grid editing (still highly experimental).
WED File Formats
This brings us to WED’s file format. If you’re not a coder, suffice it to say nothing’s going to break…the rest is technical.
WED 1.0 uses a sqlite3 database to persist earth.wed files. This seemed like a good idea at the time – I thought it might be useful to do database-like queries against WED files. Unfortunately, it’s not a good idea.
- WED can’t run against the database, it loads it all into RAM, so the database is wasted.
- Using sqlite3 slows down development time and makes versioning files more complicated.
- The performance of the code that uses sqlite3 is poor.
I really do like sqlite3 as an embedded database, but my use of it is just not well thought out.
So I am planning to replace the sqlite3 database with some other file format. I am planning on doing this before finalizing WED 1.1, to get the change over with before I go any further with the database format.
WED 1.1 will continue to read sqlite3 databases for the purpose of opening legacy projects (both 1.0 and older 1.1 beta projects) but will only save in the new file format.
The new format isn’t yet decided, but the strong contender is a simple XML format that persists each object in the WED hierarchy. This would give us something structured, readable enough to debug, and there are lots of third party tools to work with XML.
If you area third party developer and have any strong opinions on WED’s internal file format, shout at me by email.
If there are two take-away points from this post, they might be this: there are a lot of new scenery system features in X-Plane 10, and I spend most of my day looking at surreal stuff.
Exhibit one: this is a next generation facade. Facades have been in X-Plane since 8.0 – they provide a way to construct a building from a polygonal outline.
In X-Plane 10, the facade engine is greatly enhanced, for the purpose of creating airport terminals. The facade on the left is a partly completed major airport terminal, with some random stuff put in by me for testing. Some of the new facade features:
- Facade walls are 3-d, containing real architectural features.
- Facade walls can support some level of translucency. You can see inside those windows.
- Facade walls can have objects attached – that’s where the jetways come from.
- Facade roof texturing is enhanced, for repeating, tiled roofs.
- Facade roofs can have objects placed at periodic intervals – that’s what all of those cars are. (I just grabbed the first object I found in the library.)
- In version 10 facades can go around bezier curves.
This is the same shot at night. The headlights from the cars illuminate the roof. No special trickery is needed for this – the cars have named lights, the cars sit on the roof, the light hits the roof. That’s the nice thing about global illumination: you attach lights and it just works; you don’t have to worry about what spill has to be baked into what texture.
This is a wider shot of the airport terminal with cars on the roof – as you can see, there’s a lot of cars. Since X-Plane 8, the sim has been able to cope wieth large numbers of objects visible for small distances. This is why we can build 10,000 3-d light fixtures at KORD and it doesn’t affect framerate. X-Plane 10 has some enhancements to the OBJ engine, including instancing, that should let us see more objects from farther away.
This is the matched night picture for the one above; you can see that having a large number of small lights casting global illumination doesn’t fps. With global illumination, the area of the screen the light covers affects fps but the total number isn’t so important.
Here are the cars with shadows turned on; like global illumination, shadowing affects everything, so you don’t have to worry about what scenery element is shadowing what other elements. The cars are on the roofs, ergo the cars shadow the roofs.
(You can see the shadow running out of resolution in the far ground – I still need to do a lot of shadow tuning; they’re really picky.)
Finally, one not totally ridiculous picture. (Poor Tom – I just post his art assets to the web regardless of what state they’re in; this’ll be the last time he sends me an updated library!) The building casts a shadow on the jetway, which shadows itself and the tarmac. It’s not until you take the shadowing away that you realize how much they sell the image.
We’ve received a number of reports over the last month of X-Plane hanging on startup with NVidia graphics cards on Windows. Most users don’t see this, but some do. We fixed one use of off-screen rendering in X-Plane 9.67 and this fixed some of the users with hung video cards but not all.
I am working with the remaining users now; my hope is that we’ll find something we can change in X-Plane to work around the problem. I don’t believe that the code in X-Plane 9.62 was actually incorrect, but it was simple enough to change.
I have also read some posts regarding poor performance on the GeForce 400 series (Fermi cards) vs. the older 200 series. I have no hard data on this, and frankly, a lot of the discussion on the net strikes me as completely speculative.
Fortunately alpilotx has a GeForce 500 series card on order, and he is working with me on next-generation DSF renders for X-Plane 10. From my perspective, the big question about the GeForce 400-500 series (Fermi and beyond) is: how well do they implement the DirectX 11/OpenGL 4.0 feature set? In particular, X-Plane 10 is going to make heavy use of full hardware instancing, and while this has been available on ATI cards since their HD2000 series, the implementation has been partly in software on NVidia DirectX 10 cards.
The question our users want to know is: if I have a preference for NVidia, can I get a DX11-class NV card for X-Plane, or should I move to ATI. By looking at instancing performance, perhaps we can determine if these cards are contenders.
(I am not worried about overall “how many fps” do you get because y’all can measure that now with X-Plane 9.)
Edit: since a number of you have jumped in with performance reports: please post the following performance info in your replies:
- Precise graphics card
- CPU with clock speed
- Results of –fps_test=3 (3 phases) with X-Plane 9.67.
I spend most of my day looking at X-Plane looking bad. If X-Plane looked good, there’d be no reason for me to look at what it was doing. (Poor Tom – I seem to alway
s have one of his planes loaded when I take a goofy screenshot. The Baron looks a lot better when it hasn’t been melted.
Besides pictures looking goofy due to bugs (that intersection was not supposed to have the sidewalks rotated) I often do my testing on old or random art assets I find lying around my hard drive. Those cross-walks aren’t even what we’re supposed to be using; they’re just something Alex sent me months ago to tinker with. Typically most of the scenery isn’t even in the picture to save time loading the sim.
A lot of the time the art assets that I use have been painted over to make debugging easier. The red, cyan, green and yellow intersections have been painted bright primary colors so I can see exactly where the 13 pieces of an intersection end up positioned. The real art assets are carefully drawn to blend together perfectly to create the illusion of a continuous world. Such a world is nearly impossible to debug!
A lot of what I see includes debug markings that don’t even show up in the final sim. The yellow and pink dots show various road grid mesh vertices; the color coding shows the level of mesh vertex duplication. (In this shot, there’s a lot of duplication – yellow – this was taken while I was measuring an inefficiency in the rendering engine.)
So I heed your calls for more screen-shots, but most of the screenshots on my hard drive are like the ones above, not the ones I am about to post; rather the ones that look like you might want to fly the sim are few and far between.
There are still a bunch of bugs in these pictures, but after staring at yellow dots, Dada-esque airplanes, and rainbow intersections all day, I was surprise to see something that looked vaguely like my home planet.
My Mac Pro (2.4 ghz Core 2, 8 cores, Radeon 4870) gets just about 20 fps exactly with those shots; that’s with global illumination and a shadow setting that will be medium; forests and autogen are maxed out. I’m hoping to get a bit more performance out of the sim when I have time to tune shaders, but that’s also an aggressive set of rendering settings on a no-longer-new computer.
