Blog

The Global Scenery is Special (for now)

In X-Plane 8 the global scenery was installed in the “default scenery” folder, which normally contains most of the built-in artwork to make X-Plane (and the global scenery) work.

In the X-Plane 9 beta it is installed in the custom scenery folder. But the sim recognizes it by name and makes sure custom scenery is higher priority than global scenery. This is imperfect but works. In the future we may do something different. Survival tips:

  • The log file tells the priority of all scenery packages.
  • Don’t rename or move the global scenery – leave it where it was installed.
  • Custom scenery will always trump global scenery.
Posted in File Formats, Scenery by | Comments Off on The Global Scenery is Special (for now)

A Road by Any Other Name

In X-Plane 9, road networks can be in DSF overlays. And in X-Plane 8 or 9, road types can be customized using a road.net file.

Within the road definition file, each road type can contain:

  • “Segments” (textured quads that make the roads)
  • Objects (placed along the road)
  • Wires (for powerlines)
  • Car lanes (that vehicles drive along)

The interesting thing is: none of these types are mandatory. So you can use any of these features without the others.

“Cars” are just objects too. So one way to make a vehicle drive around an airport would be:

  1. Create a road definition file with a new road type. That road type only has a car lane which references your vehicles OBJ model.
  2. Make an overlay DSF with this new road type, drawing the path the vehicle OBJ will randomly take.
  3. Package the overlay, .net file, and OBJ all together and you’ve got randomly generated vehicles moving around.

As Marginal pointed out on the .org forums, roads are currently not draped, so using them in overlays is a total PITA. This is something I hope to address in the 9.1 time-frame…draped roads are an important feature, but a little bit too invasive for the v9 betas.

Posted in Scenery by | 3 Comments

NVidia: 2 Ben: 0

I found the root cause of another NVidia specific bug, and once again it’s my own stupid code. If you Google for driver bugs, you’ll find plenty of grumpy developers ranting about how card X does this wrong thing and card Y does that wrong thing…I figure it’s only fair to follow up and say “yep, that one was mine.”

Like the previous nVidia-only crash, this was a case where X-Plane was always doing something wrong, but only some drivers had problems with the behavior. So the crash was NVidia-specific, but X-Plane caused.

I believe that this bug was manfiesting itself either as a message that “scenery shift took more than 30 seconds” or some kind of crash. One of the problems was that the diagnostics for this particular bit of code were really bad. So we’ve improved things a bunch…

  • There is more careful error checking during scenery shift, and those error messages are reported.
  • If the sim does crash, some new code will output a crash log on Windows that helps us isolate what actually happened.

Beta 12 will be out soon with the fix that caused problems on NV hardware as well as the improved diagnostics. So you may find that the sim just works better, but if it does still crash or report errors, please tell us – now we’ll have log files that will let us diagnose the problem a lot faster!

Posted in Development by | Comments Off on NVidia: 2 Ben: 0

“Driver Bugs”

I have spent perhaps the last two weeks tracking down driver-related problems. But the term “driver bug” is heavily overused (blog around and you’ll see that many OpenGL developers get frustrated…) A few examples of the gray areas:

  • Sometimes there will be a bug in application code that shows up only on certain hardware. Drivers are concerned with making video cards go fast, not spanking programmers who don’t know what they’re doing. This is exactly what happened to me in beta 2 with the crash-on-nVidia-with-C172 bug. This was just plain broken code in X-Plane, but for some reason the ATI drivers didn’t have a problem with it (probably because they were performing an optimization which let them ignore the bogus call I made). NVidia specific, but not NVidia’s fault!
  • On OS X with the Radeon 9600XT, runway lights don’t show up. Adding an extra line to the pixel shaders “fixes” the problem. I believe the problem is in the driver (or the shader compiler more specifically) but by changing the code to the shader we work around the problem. A change in X-Plane addresses the problem, but not X-Plane’s fault!
  • The “36061” errors that some users have been seeing turn out to be because (through a very convoluted chain of events) X-Plane was asking the video card to operate in a mode that it could not operate in. Turns out this can be fixed by changing X-Plane’s code (fix will be in beta 12) or by getting new drivers. This one wasn’t really a driver bug – more that the drivers were limited in a way X-Plane did not expect. (Our fault for being picky!)

The situation is fundamentally tricky – games are integrators of other people’s technology – as such, we get blamed by the end user for a fault anywhere in the system. At the same time, it’s way too easy to turn around and blame the part supplier, and unfair when the source of the bug hasn’t been identified.

I am looking now at problems on Windows with dual core machines and nVidia cards. The problem goes away both by changing a registry setting that affects the driver and by changing X-Plane’s code. So I think it’s too soon to tell on this one.

Posted in Development by | Comments Off on “Driver Bugs”

A Tools Update

I’ve spent perhaps the last two weeks almost entirely looking at driver-related graphics bugs. I should note that these are often not driver bugs, and the issue of whether a bug is in the sim or a driver is a lot stickier than you’d imagine, but I’ll blog about that later.

In the meantime, where do we stand on scenery development tools? Here’s a rough summary.

General Strategy

The scenery tools are not targeted to X-Plane 8 or 9 – they’ll export content for both (but if you use new V9-only features, your content will be v9 dependent).

There’s been one structural change in v9 that’s worth mentioning: version 9 allows road networks in DSF overlays. This cleans up the scenery model a lot…roads are more like objects and forests than like the base mesh, so now all of the 3-d elements can be in an overlay. This is particularly useful because you might want to adjust the road and objects nearby all at once.

Given that we have no road editing tools right now, I think there is one case where the tools will be v9-centric: I do not think I will ever provide a road-editing tools for DSF base meshes with roads. I do think I will add road editing to the list of overlay features that will eventually end up in WED.

This means that if you want to customize roads, you’ll have to do it in version 9. This is an inevitable outcome of the scenery system structure…replacing the entire base mesh to edit the roads is not a great idea.

WED

WED is in beta 4, and I think it will go final as soon as I have time to make it official. At this point most of the open bugs I get are usability issues and enhancement requests, not real bugs. We’ll get more usability features into WED in the future.

Please don’t send me WED bugs now (or attach them as blog comments). I’ll put out a formal last-call for WED bugs when I have time to dig in.

The future plan for WED is to add DSF overlay editing with all legal overlay types (which is now everything except beaches and base mesh).

AC3D

The AC3D export plugin already supports new v9 OBJ features – key frames and panel regions. These tools are available now!

Tools

The “tools” are the set of other scenery apps: DSF2Text, ObjConverter and ObjView. We’ll be adding two new tools soon:

  • DDSTool is a PNG->DDS converter. There are already other programs (many free) for both platforms that can do this conversion, but we wanted something easy and drag & drop when we were doing the in-house conversion, so I coded DDSTool (based on the Squish library). We’ll make it available to authors.
  • MeshTool is a base-mesh generation program. We’re still working out the details on this, but basically it will generate DSF base meshes from raw DEM data and polygonal coastlines.

I am restructuring the tools to be entirely command-line-based (except for ObjView) with a single “drag & drop” UI that wraps all of the tools. So if you use the mouse, you’ll use the one drag & drop application to do all your DSF2Text converions, 3DS->OBJ conversions, PNG->DDS conversion, etc. This is mainly to cut down the number of apps I have to build, but it should also declutter workflow a bit.

MeshTool

I’ll post more on MeshTool once we have more details, but here are the main points:

  • MeshTool will not have a UI. It will take text files and process them. It is designed to provide a building block on which people can write more advanced tools. In other words, MeshTool gives other programmers our mesh algorithms just like DSF2Text gives other programmers our DSF-packing algorithms.
  • MeshTool will not be an editor. It will create NEW meshes from RAW DATA, not from previous meshes. There are a lot of reasons why I do not want the mesh-creation workflow to be “take the global scenery and hack it”. So MeshTool lets you build your own.
  • This means you will need your own elevation and coastline data for MeshTool! You can’t use what shipped in the global scenery! However, since the data that ships the global scenery is freely downloadable and widely available, I don’t think this is a problem.
  • MeshTool will be able to “burn in” orthophotos into a mesh. This is probably its most important feature. Right now the only way to make orthophoto-based scenery is to use overlay polygons, but the performance of .pol files with a lot of scenery is really poor under version 9. MeshTool will let people build photo-sceneries that take full advantage of the framerate that X-Plane can deliver!

MeshTool should address some of the common issues I’m hearing with orthophoto sceneries (slow performance with a ton of .pol files, no ability to fix the coastlines or remove underlying base terrain, no ability to fix elevation).

MeshTool will create new default landuse terrain where there are no orthophotos or water. This is important because the elevation data can be customized. If you take an existing DSF and somehow edit the elevation points (for example, use DSF2Text and just start editing) and raise a grassy field, you’ll have grass going up a cliff. But if you pass the raw elevation data to MeshTool, it will build a rocky cliff over steep elevation, creating more plausible scenery.

MeshTool should be in the post 9.0 final time-frame, as will all the other tool reposts.

Posted in Tools by | 10 Comments

I will reply (soon)

At this point my in-box has approximately 180 emails from the month of December regarding X-Plane 9. So while I appreciate all of the feedback we’ve gotten (bug reports, performance, etc.) it’s going to take a while to reply. If you haven’t heard from me, don’t panic! I hope to answer a whole pile of emails next week.

In the meantime, I’ve been working on improved crash logging on Windows. Right now when we have a crash on Windows, all we know is that (1) X-Plane crashed and (2) what DLL we crashed in (which is always us or the video driver – not useful).

Coming soon, X-Plane will catch the fatal crash, examine memory to see what was going on, examine its own EXE to figure out the names of the functions going on, and output it all to a crash log that users can send us to get a much clearer picture of what’s going on. This information is called a “backtrace” – we’ve had it for the Mac or a while (OS X provides back-traces automatically with a crash) and it’s really useful.*

So my top priority is all of the users who are seeing problems during scenery load, and a new build with a back-trace should help to reveal what’s really going on.

I’m also working on putting additional timing and performance information into the sim so we can learn more about why some users have poor performance. So far here’s what I’m seeing:

  • 8800 users seem to have great performance. If you have this card and don’t have good fps, adjust your x-plane settings and NV control panel settings – this card can bring it.
  • 8600 users sometimes have performance problems – not sure why.
  • Older nvidia GPUs (7600, 6800) sometimes have performance problems with the new eye-candy features – I am investigating.
  • The pixel shaders seem to slow down the new HD2x00 Radeons a lot more than expected…I still need to investigate this. This is the most surprising datapoint – the X1600 does very well, so I would expect newer GPUs to at least have that level of performance. I think this is something we might be able to address.

However not all of the reports are consistent, so I think it’s too soon to make some calls on recommended hardware. The only thing that’s clear is that most 8800 useres who we do careful perf experiments with end up with huge framerates.

* Microsoft provides some back-trace facilities, but since we don’t use their compiler tools, we had to roll our own.

Posted in Development by | Comments Off on I will reply (soon)

V-Sync – Problematic in Practice

To those who have sent performance info: thank you, but you probably won’t hear for me for a week. I’m up to my eyeballs in reports and it’s going to take a while to get through them.

I finally found the code that allows X-Plane to turn off V-Sync. This should help nVidia users who are having framerate problems.

The basic idea is this:

  • X-Plane tells the graphics card to draw a lot of stuff.
  • The video card accumulates this “todo” list and works on it while X-Plane runs.
  • X-Plane indicates that the entire frame to be seen is done and tells the card to show the results.
  • Eventually some time later the card finishes the todo list and then shows it to the user.

V-Sync relates to the question of when this last step happens. When V-Sync (vertical sync) is off, the card shows the results as soon as it is done drawing.

But when V-Sync is on, when the card finishes drawing the world, it then waits until the monitor is done drawing its frame, and then shows the results. Without V-Sync we can have a situation where the top half of the monitor is showing a new frame and the bottom half is showing an old frame. (This is called “tearing”.)

So normally V-Sync is good because it prevents tearing. But the problem with V-Sync is that a frame can only be shown when the monitor refreshes. The video card has to wait until this happens, and this slows our framerate down.

In particular, most users have their monitors set to 60 hz. If X-Plane can only produce frames at 50 hz, the video card will have to further slow the framerate down to30 hz (one x-plane frame for every two monitor refreshes). If X-Plane falls below 30 hz, we end up with 20 hz (one X-Plane frame for three monitor refreshes), and if X-Plane goes below 20 hz, we would clamp at 15.

So when monitor refresh is on, there can be large framerate hits for small losses of performance in the sim, and a real risk of getting locked around 20 fps.

(The minimum framerate in X-Plane is intentionally set to 19 so that we won’t fog up if the video card clamps us at 20 fps.)

So when beta 11 comes out, you may get some framerate back if you haven’t already hacked your graphics card’s control panel settings. If you still want v-sync, you can always set it this way in the control panel. But most users I’ve talked to are happy to have it off.

In an only vaguely related note, one of the reasons to have high frame rate is to have a smooth flight model. But Austin has now put a new setting in the operations-and-warnings dialog box: you can pick how many times per graphics frame the physics run. The normal ratio is 1:1, but for fighter and acrobatic pilots, you might find that you can get a nice feel at lower fps (20-30) by setting a higher ratio.

Posted in Development by | 3 Comments

Cores and Drivers and Vsync

Random thoughts:

Update your drivers! Version 9 uses driver features that version 8 does not. Just because version 864 works doens’t mean that your drivers are up to date and bug free! First thing to try when weird things happen in version 9 is a driver update.

If you have 60 fps and a rendering setting cuts it to 30, you probably have vsync on – that is, your graphics card can only run at an even divisor of your refresh rate. The next hit will be 20, then fog. Change your monitor refresh rate to 75 or 80 hz. If the framerates all change (to 80, 40, 20, etc.) it must be v-sync. Turn v-sync off for better framerates under heavy load. Nvidia users, you need to turn v-sync to off, not application controlled.

X-Plane 900b7should be able to put sustained load on three cores – if you’re recording a QuickTime movie, one core draws the world, one compresses QuickTime frames, and one rebuilds 3-d as you fly. So…I guess we’ve already hit a point where a quad-core machine has some benefit over a dual-core machine. (I think we’ll start to see more central features use more cores during the v9 run.)

The new forests rebuild 3-d very frequently – dual core users who run on “tree hugger” should see utilization of 75% or higher on both cores, depending on video card power. (If your CPU usage isn’t 100% then probably your video card is holding you back – turn down FSAA.)

Posted in Development by | 2 Comments

Now we can talk v9-performance

I think we’re reaching the point where I can start looking at version 9 performance in detail. Over the past few betas we’ve fixed some very general and global performance problems and also some crash bugs. Now we’re reaching the point where some users have fast performance and others don’t, and it doesn’t quite match up to the hardware the way we’d expect.

The biggest single complaint I’m hearing is “pixel shaders slow may machine down”. This is expected, but the level of slow-down we’re hearing about (2x, 3x, 4x fps loss) is a lot higher than we’d expect.

Here’s a very basic test case you can try:

  1. Start with shaders off, no FSAA, 4x anisotropic filtering, and a texture res that doesn’t push your card too far (“very high” for 256 MB cards). Tune objects to get between 30-50 fps all the time. Keep forests to “none” for now – they use the second core, so better not to bring in another variable for testing. Measure fps while on the ground somewhere, so that the camera isn’t moving around. Pick a view that has no panel at all, like shift-w (forward-no-HUD view). Use the default 747.
  2. Now turn shaders on. Turn water reflection to none, turn volumetric fog off. What’s the new fps (keeping the same forward-no-HUd stationary 747)?
  3. Now turn volumetric fog on (water is still “none”). What are the fps now?
  4. Finally turn water reflections to “default”. What are these fps?

I’d like to know these four fps numbers because they show the incremental degradation to performance as settings are slowly brought in.

Now if these numbers come out okay, but some real configuration that you tried was terrible, tell me, what’s the delta? (For example, did you have FSAA cranked up when you were testing? What was the texture res?) That will tell me the delta between controlled situations and real-world usage cases.

It will probably take me up to a week to get back to performance reports. Best venue right now is probably: send me an email with attachments for your log.txt file. Please don’t post performance to the blog comments section, I think the thread will get unreadable.

It’s too soon to evaluate whether you need a new video card. I’m hearing reports of GeForce 8800 users with low performance – and yet I have good performance on an X1600. This implies that there’s a driver call we make that isn’t fast in some cases that we need to replace with something better. Let’s get that worked out before you go out shopping!

Comments Off on Now we can talk v9-performance

Key Frames, AC3D, and Compatibility

I’ve posted the first beta of the AC3D X-Plane export plugin version 3.1 on the scenery web site. This plugin contains support for key frames and panel regions, two new version 9 features.

Generally, the scenery tool code is not part of the X-Plane code. There aren’t version 9 and version 8 scenery tools. There will always be one set of scenery tools that let you optionally use the v9 features or not.

An example is the AC3D plugin. Everyone can use the new plugin (and a few small features apply to X-Plane 8 too, like a less sluggish animation UI when editing large objects). If you use key frames, your object will only work with v9 – if you don’t, it will work with v8.

More specifically on key frames: a traditional v8 animated object is really just a key framed object with only two key-frames. So the UI has changed very little – basically where you only had two key frames (points of correspondence between the dataref and animation) in the old plugin, you can now use the “add” button to add more.

I will try to add features to the scenery tools to warn when v9 features are being used, so that if you want your scenery to run on v8 and v9, you can check for v9-only feature usage.

Posted in Scenery, Tools by | Comments Off on Key Frames, AC3D, and Compatibility