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.
We have not been adding features into X-Plane specifically to aid conversion of scenery from MSFS (and I don’t think we will), but sometimes features we want outright help solve conversion issues too. Here are two new features I expect us to ship in version 10 that should help the conversion of overlay scenery packs.
Draped Geometry: I’ve mentioned this feature before; basically in X-Plane 10, the horizontal geometry that sits “on the ground” can be marked for real 3-d draping, rather than just polygon offset. Draping is the process of actually cutting and shaping that geometry to perfectly ‘hug’ the ground – it’s how we can put a runway or taxiway on top of non-flat ground without Z thrash.
In X-Plane 9 you can create draped geometry, but you have to use .pol files; this can be awkward if you want to put an element in many times, share an element with other authors, or have an element on the ground match a 3-d object.
In most of the cases where I have seen serious Z thrash in scenery conversions, simply changing ATTR_poly_os to the new proposed ATTR_draped will fix the problem.
OBJ Elevation Control: X-Plane 10 will allow you to position an object vertically as well as horizontally, probably with something like this RFC.
For scenery conversions, this means that a scenery pack authored to a specific height elevation can be duplicated precisely.
For authors creating new work, this makes certain kinds of scenery possible that would have been very difficult before. For example, we get asked fairly often about LPMA. which features a runway on pillars. You can model as this as an OBJ with a hard surface, but in X-Plane 9 it’s very hard to predict what height that OBJ will be placed at. (Hack/work-around: place the OBJ in the water and model the geometry offset from the runway location. Most scenery packs should have the water at MSL 0.) With elevation control, the runway can be built at the real runway surface height and will be placed their explicitly.
I spend most of the time working on global scenery, shaders, v10, the big ticket items. But there are always little things going on too. A few random things:
I have a JavaScript taxiway-sign editor I’ve been working on – it lets you type taxiway signs with the keyboard, see them using the real sign artwork, and then get the sign code out (you know, that cryptic {^ul,@r}27-9{@@,no-entry} gak) automatically. I was inspired by WordPress’s insanely nice back-end web UI to see if I could make a web-based sign editor that was reasonably usable. The answer is: with jQuery – yes. Once it’s further along, I’ll post it; maybe someone can help make the CSS prettier.
We put another download server up this week; as we transition between hosting providers, we’ll have extra servers for a week or two, so, um, enjoy the bandwidth!
Finally, I’ve been poking (very slowly) at the panel documentation on the wiki. In particular, I’m trying to delete documentation of legacy features. A lot of the complexity in the panel system comes from the interaction between old backward compatibility features and the latest way to make a modern aircraft. My hope is that by documented only the “modern” path, the documentation can be clear, concise, and a lot less confusing to new authors. I figure if you’re reading the Wiki, you want to know how to make a panel now, not how to make one for X-Plane 3 years ago.
The real work of the week was the new road system and debugging the new global illumination code.
An advanced apology to anyone whose comment gets nuked as spam. This blog, like all blogs, gets attacked by spammers who put links in their comments to boost their pagerank.
So if I’m not sure if you’re a real commenter or a spammer, sorry, but I’m going to err on the side of the chainsaw.
The Cessna 172SP isn’t the fastest plane, but it would get you there a little quicker if it was a twin prop.
(This is what happens when I leave the AI planes on while randomly testing rendering bugs in the middle of nowhere. On the bright side, the two planes do shadow each other.)
These four buildings are facade-scrapers, a new feature in X-Plane 10.
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.
