Wednesday, May 28, 2008

More Scenery Features

Since X-Plane 9 went final I've been going in about 5 different directions with the code, and as a result my posts have diverged pretty far from my charter within the company, namely scenery. Here's some of what I'm looking at on the scenery front:

Texture Paging

Texture paging is a new feature where X-Plane can change the resolution of orthophotos while you fly. The big limitation of orthophoto-scenery right now is that X-Plane loads every orthophoto at the maximum user-defined resolution when the underlying DSF/ENV is loaded. This can cause X-Plane to run out of virtual address space and crash. With texture paging, only the nearby textures are loaded at high resolution.

Far away textures may be low res, but you'll never notice because they are far away (and thus you're seeing them over only a few pixels on screen anyway.

The cost of this technique is that textures are being loaded over and over and over. But this cost is made less painful by two features:
  • DDS texture loads are very fast and cheap, especially at very low resolutions.*
  • With the next major patch, texture loading will be entirely on a second core (if you have one) and can even span multiple cores.
This feature will require modification of scenery packs in that you'll have to add some "paging" information to your .ter files; I will try to get a preliminary spec posted soon. Because you only have to modify text files, it should be possible to create "paging patches" to existing DSF orthophoto sceneries that are fairly small.

I do not know if paging will be available for .pol files. My guess is yes, but I reiterate that using .pol files for large areas of orthophotos is a bad idea! Make a new mesh!

Improved Multi-Core Performance

This is going to be an on-going process through the entire v9 run and beyond, but basically with every change to our rendering engine (and we make some serious modifications with almost every patch to keep it modern and competitive) we try to move toward using the new hardware (meaning machines with 2-4 cores) more efficiently. Some of this will be in 920, although my guess is we'll need at least one more patch after 920 to really see the improvement.


It's going to be a little bit before I can put more time into the various scenery tools. My top priority is to keep up with user feedback and work on MeshTool. Hopefully we'll also declare WED final soon. But for now, since I am working on cockpit and airplane modeling features, my next set of work will probably be for the airplane authors.


I do want to put additional shader work into v9. I realize I am at the edge of provoking a bunch of rants in the comments section, so let me save you some time:

"Hey Ben, stop working on eye candy and create some more tools. I don't want a shader feature that makes my 1.2 ghz G4 with a GeForce 2 MX run any slower. You should finish the tools so they do exactly what I want!"

Okay, I admit, that was totally unfair...there is a lot of truth in the complaints about shaders vs. tools.
  • I really do try to keep an eye on system requirements, particularly once we shipped. I'm going to try to prioritize shader features that improve existing rendering techniques, rather than introduce new rendering techniques, so we don't seriously lower fps during the version run. But also bear in mind that shaders can be turned off, and there are users who have GeForce 9s and such.
  • Tools are very important, hence the effort to get MeshTool out. But tools without engine work aren't very useful either; most of the engine work we do is needed to keep performance up so that new scenery (made with those new tools) don't bury the sim. For example, MeshTool without texture paging would be a could easily make a MeshTool scenery that you can't fly.
So in planning what goes out when, I look for clumps of features and tools that can go together to make some sense: WED to use apt.dat 850, texture paging to go with MeshTool. It wouldn't make sense to defer texture paging to make the next tool while MeshTool is waiting for engine enhancements.

* A DDS already has all of the smaller-version pre-compressed textures in the file. So loading a DDS at low res involves loading a small amount of data from disk to memory and sending it to the graphics card.

By comparison, a PNG file only contains the maximum size, so to load a PNG at low res, we load the largest size, shrink it on the fly, then apply DDS compression.


Anonymous said...

Hi Ben, regarding shaders coding (maybe stupid question): would it be an option that somebody from community could contribute in coding shaders? Or it is not possible because one would need to know how the rendering engine works on a low level?

Anonymous said...

Hi Ben, all sounds good. Can you enlighten us on when you will be working on the lighting issues? The SIM is entirely too dark.