I'm going to be more or less out of the office next week - the Amichai Margolis band is playing a series of shows in Florida. I'm going to have to take the laptop - we're too close to going final to miss a week of bug reports, but hopefully the next beta will stick for a while. (Initial reports indicate that the video driver initialization changes we made are fixing crashes and not causing new ones.) There will be a beta 23 shortly to address other bugs.
I wanted to take a moment to thank all of the users who have helped me debug video card compatibility problems remotely. I now have seven installed operating system configurations in my office, and it isn't nearly enough to see all of the problems we hit in field. Looking back at my in-box this week is a reminder of how patient you all have been in trying test builds, sending log after log, helping get to the bottom of some very tricky issues.
Things are going to be a bit busy for the next few weeks - once I get back we'll be finishing up the last few bugs, so it will take a little while to get back to questions about scenery, plugins, etc.
Sunday, February 17, 2008
Thursday, February 14, 2008
Instability in Version 9
One of the reasons why the X-Plane 9 betas have had so many more crash bugs than version 8 is that we introduced loading DSFs on a second core. This feature makes scenery loads much slower and (by using the second core) impacts fps less while they happen.
The problem is that I'm still fumbling with code that will allow this in all cases. (That would be three operating systems, two hardware vendors, and a myriad of drivers, some new, some quite prehistoric.)
Beta 22 will be out soon, and will contain the fourth major rewrite of the OpenGL setup code for X-Plane 9. So far the initial tests look good, but we never know until we let a lot of users try the code and find the new edge cases.
It's relatively easy to tell if your instability is related to the use of OpenGL with threads: simply run the sim with the --no_threaded_ogl option. If things become a lot more stable, it's a threaded GL problem. Mind you --no_threaded_ogl is more of a diagnostic than a workaround; without threaded OpenGL, the sim will pause when loading scenery.
(Also, to clarify, you'll find talk on discussion groups and game forums about "threaded drivers". Threads are a programming abstraction that can utilize multiple cores. What I am talking about is X-Plane using multiple threads to load scenery - in our case this requires interfacing with OpenGL. But a threaded driver is different - it's just a graphics driver that's been optimized for multcore machines. These two concepts are totally different; you don't need a threaded driver to use X-Plane 9, and a threaded driver won't make X-Plane 8 load without pauses.)
The problem is that I'm still fumbling with code that will allow this in all cases. (That would be three operating systems, two hardware vendors, and a myriad of drivers, some new, some quite prehistoric.)
Beta 22 will be out soon, and will contain the fourth major rewrite of the OpenGL setup code for X-Plane 9. So far the initial tests look good, but we never know until we let a lot of users try the code and find the new edge cases.
It's relatively easy to tell if your instability is related to the use of OpenGL with threads: simply run the sim with the --no_threaded_ogl option. If things become a lot more stable, it's a threaded GL problem. Mind you --no_threaded_ogl is more of a diagnostic than a workaround; without threaded OpenGL, the sim will pause when loading scenery.
(Also, to clarify, you'll find talk on discussion groups and game forums about "threaded drivers". Threads are a programming abstraction that can utilize multiple cores. What I am talking about is X-Plane using multiple threads to load scenery - in our case this requires interfacing with OpenGL. But a threaded driver is different - it's just a graphics driver that's been optimized for multcore machines. These two concepts are totally different; you don't need a threaded driver to use X-Plane 9, and a threaded driver won't make X-Plane 8 load without pauses.)
Thursday, February 07, 2008
GeForce 7 and Water Performance
A number of Windows and Linux GeForce 7 users have discovered that the command-line option --no_fbos improves their pixel-shader framerate a lot. Windows and Linux Radeon HD users have also discovred that --no_fbos cleans up artifacts in the water. Here's what's going on, at least as far as I can tell. (Drivers are black boxes to us app developers, so all we can do is theorize based on available data and often be proved wrong.)
Warning: this is going to get a bit technical.
FBO stands for framebuffer object, and simply put, it's an OpenGL extension that lets X-Plane build dynamic textures (textures that change per frame) by drawing directly into the texture using the GPU. Without FBOs we have to draw to the main screen and copy the results into the dynamic texture. (You don't see the drawing because we never tell the card "show the user".)
We like FBOs for a few reasons:
When do we use FBOs vs. copying? Well, it's pretty random:
Mipmapping
There is one more element: mipmapping. A mip map is a series of smaller versions of a texture. Mipmapping allows the video card to rapidly find a texture that is about the size it needs. Here's an example: imagine you have a building with a 128x128 texture. If you park your plane by the building, the building might take up about 100x100 pixels on the screen; your 128x128 texture is a good fit.
Now taxi away from the building and watch it get smaller out your rear window. After a while the building is only taking up 8x8 pixels. What good is that 128x128 texture? Its' much too big for the job. With mipmapping, the card has a bunch of reduced-size versions of your texture laying around...64x64, 32x32,16x16, 8x8, 4x4, 2x2, 1x1. The video card realizes the building is tiny and grabs the 8x8 version.
Why not just use the 128x128 texture? Well, we'd only have two options with this texture:
We don't mipmap our dynamic textures very often; the only ones that we do mipmap are the non-pixel-shader sun reflections and the pixel-shader sun reflections.
ATI
As far as we can tell, the current ATI Catalyst 8.1 drivers do not generate mipmaps correctly for an FBO-rendered texture. This is why without --no_fbos ATI users on Windows or Linux see very strange water artifacts. --no_fbos switches to the copy path, which works correctly.
At risk of further killing my track record of driver bugs in v9, we do think this is a bug. We have good contact with the ATI Linux driver guys so I have hopes of getting this fixed.
nVidia
It appears that the process of creating mipmaps for FBO textures is not accelerated by the hardware on the GeForce 7 GPU series. This is why GeForce 7 users are seeing such poor pixel shader performance, while GeForce 8 users aren't having problems.
Now poor performance is not a bug; there's nothing in the OpenGL spec that says "your graphics card has to do this function wickedly fast". Nonetheless, what we're seeing now is unusably slow. So more investigation is needed -- given that the no-FBO case runs so quickly, I suspect the hardware itself can do what we want and it's just a question of the driver enabling the functionality. But I don't know for sure.
Warning: this is going to get a bit technical.
FBO stands for framebuffer object, and simply put, it's an OpenGL extension that lets X-Plane build dynamic textures (textures that change per frame) by drawing directly into the texture using the GPU. Without FBOs we have to draw to the main screen and copy the results into the dynamic texture. (You don't see the drawing because we never tell the card "show the user".)
We like FBOs for a few reasons:
- Most importantly, FBOs allow us to draw big images in one pass even if the screen is small. For example, if we have a 1024x1024 dynamic texture but the screen is 1024x768, then withou FBOs we have to draw the image in two parts and stitch it together. That sucks. With FBOs we can just draw straight to the texture and not worry about our "workspace" being smaller than our texture. This is going to become a lot more important for future rendering features where we need really-frickin' big textures.
- It's faster to draw to the texture than to copy to it.
- If you're running the sim with FSAA, then we end up using FSAA to prepare all of those dynamic textures. In virtually all cases, we don't need the quality improvements of FSAA, so there's no point in taking the performance penalty. When we render right into the texture, FSAA is bypassed and we prep our dynamic textures a lot faster.
When do we use FBOs vs. copying? Well, it's pretty random:
- Pixel shader reflective water and fog use FBOs.
- Cloud shadows and the sun reflection when pixel shaders are off do not use FBOs.
- The airplane panel uses FBOs if the panel is 1024x1024 or smaller; if the panel is larger than 1024x1024 we draw from the screen and patch things together. So the P180 and the C172 are using different driver techniques!!
Mipmapping
There is one more element: mipmapping. A mip map is a series of smaller versions of a texture. Mipmapping allows the video card to rapidly find a texture that is about the size it needs. Here's an example: imagine you have a building with a 128x128 texture. If you park your plane by the building, the building might take up about 100x100 pixels on the screen; your 128x128 texture is a good fit.
Now taxi away from the building and watch it get smaller out your rear window. After a while the building is only taking up 8x8 pixels. What good is that 128x128 texture? Its' much too big for the job. With mipmapping, the card has a bunch of reduced-size versions of your texture laying around...64x64, 32x32,16x16, 8x8, 4x4, 2x2, 1x1. The video card realizes the building is tiny and grabs the 8x8 version.
Why not just use the 128x128 texture? Well, we'd only have two options with this texture:
- Examine all 16384 pixels of the texture to compute the 64 pixels on screen. That sucks...we're accessing VRAM sixty four times for each pixel. Accessing VRAM is slow, so this would kill performance.
- Simply pick 64 pixels out of the 16384 based on whatever is nearby. This is what the card will do if mipmapping is not used (because option 1 is too slow) and it looks bad. Thsoe 64 pixels may not be a good representation of the 16384 that make up your building side.
We don't mipmap our dynamic textures very often; the only ones that we do mipmap are the non-pixel-shader sun reflections and the pixel-shader sun reflections.
ATI
As far as we can tell, the current ATI Catalyst 8.1 drivers do not generate mipmaps correctly for an FBO-rendered texture. This is why without --no_fbos ATI users on Windows or Linux see very strange water artifacts. --no_fbos switches to the copy path, which works correctly.
At risk of further killing my track record of driver bugs in v9, we do think this is a bug. We have good contact with the ATI Linux driver guys so I have hopes of getting this fixed.
nVidia
It appears that the process of creating mipmaps for FBO textures is not accelerated by the hardware on the GeForce 7 GPU series. This is why GeForce 7 users are seeing such poor pixel shader performance, while GeForce 8 users aren't having problems.
Now poor performance is not a bug; there's nothing in the OpenGL spec that says "your graphics card has to do this function wickedly fast". Nonetheless, what we're seeing now is unusably slow. So more investigation is needed -- given that the no-FBO case runs so quickly, I suspect the hardware itself can do what we want and it's just a question of the driver enabling the functionality. But I don't know for sure.
Wednesday, February 06, 2008
The Limits of Orthophotos and Meshes in X-Plane
I get asked a lot about the limits of meshes and orthophotos in X-Plane. I'll try to answer this, but the answer isn't as simple as most people expect.
Texture Limits and Orthophotos
The maximum single texture size in X-Plane 8 is 1024x1024, and in X-Plane 9 it is 2048x2048.
I believe the maximum number of unique custom orthophotos that can be attached to a single DSF is at least 32768.
In practice, that number is pretty useless because X-Plane loads all textures for a DSF at the highest user-allowed res when the DSF is loaded. That means you tend to load a lot of textures. Every system is different and drivers have a lot to do with RAM efficiency, but generally you'll run out of virtual address space and crash the sim before you can attach 32768x2048x2048 of pixels.
X-Plane has no limits on how the texturing is applied - that is, you can use your 2028x2048 texture to cover an entire tile or a single meter. So again, the limiting factor on the resolution of your orthophotos is how much total area you want to cover and how much RAM you can spend (remember RAM is also used for mesh complexity, 3-d models, etc.).
You do not need to have enough VRAM to hold all loaded orthophotos; the video driver will paeg the textures into VRAM. Virtual address space is the limiting factor. How far you push it depends on a lot of subjective things:
It should be noted that these limits on texturing (due to X-Plane blindly loading a lot of stuff at once) affect all scenery types: objects, draped polygons, very complex airplanes, plugins, and not just terrain mesh orthophotos.
Getting Past the Texture Limit
It will take a future extension to the rendering engine to get past the current limits. Basically X-Plane will have to load textures at lower resolutions when they're farther away. I don't know when that is coming, but when it happens, it will increase the total amount of image data a DSF mesh can contain, because the limiting factor will be how much data is in the small area the user is looking at (since the rest can be stored at much lower res for far-away views). At that point the limiting bottleneck will be resolution (smaller means more data at once), not total image data.
Mesh Limits
Unfortunately, limits to the mesh are even more vague than limits to texture usage. X-Plane uses an adaptive mesh - basically you can put your vertices wherever you want. So the highest resolution you can achieve might be much smaller than 1 meter resolution, but you can only do this for a small area before the total mesh size gets too big. But this is okay - the intention of DSF is to let you put a lot of detail where you need it.
I believe that once again memory provides the first limitation to the mesh. That is - you'll run out of memory loading your insanely huge mesh long before you hit a limit to the DSF container structure. And once again, even the RAM limit isn't a hard limit because that virtual address space is shared with texures. Your mesh density limits actually go down when your textures go up because it's a zero-sum game.
Estimating Memory
Here are some ideas on how to estimate your memory footprint:
Texture Limits and Orthophotos
The maximum single texture size in X-Plane 8 is 1024x1024, and in X-Plane 9 it is 2048x2048.
I believe the maximum number of unique custom orthophotos that can be attached to a single DSF is at least 32768.
In practice, that number is pretty useless because X-Plane loads all textures for a DSF at the highest user-allowed res when the DSF is loaded. That means you tend to load a lot of textures. Every system is different and drivers have a lot to do with RAM efficiency, but generally you'll run out of virtual address space and crash the sim before you can attach 32768x2048x2048 of pixels.
X-Plane has no limits on how the texturing is applied - that is, you can use your 2028x2048 texture to cover an entire tile or a single meter. So again, the limiting factor on the resolution of your orthophotos is how much total area you want to cover and how much RAM you can spend (remember RAM is also used for mesh complexity, 3-d models, etc.).
You do not need to have enough VRAM to hold all loaded orthophotos; the video driver will paeg the textures into VRAM. Virtual address space is the limiting factor. How far you push it depends on a lot of subjective things:
- If you expect your users to also run with a lot of trees, 3-d objects, cars on roads, and some plugins, you can't use a lot of RAM.
- If you expect your users to have /3GB in their boot.ini and use nothing but your add-on, you can use a lot more RAM.
It should be noted that these limits on texturing (due to X-Plane blindly loading a lot of stuff at once) affect all scenery types: objects, draped polygons, very complex airplanes, plugins, and not just terrain mesh orthophotos.
Getting Past the Texture Limit
It will take a future extension to the rendering engine to get past the current limits. Basically X-Plane will have to load textures at lower resolutions when they're farther away. I don't know when that is coming, but when it happens, it will increase the total amount of image data a DSF mesh can contain, because the limiting factor will be how much data is in the small area the user is looking at (since the rest can be stored at much lower res for far-away views). At that point the limiting bottleneck will be resolution (smaller means more data at once), not total image data.
Mesh Limits
Unfortunately, limits to the mesh are even more vague than limits to texture usage. X-Plane uses an adaptive mesh - basically you can put your vertices wherever you want. So the highest resolution you can achieve might be much smaller than 1 meter resolution, but you can only do this for a small area before the total mesh size gets too big. But this is okay - the intention of DSF is to let you put a lot of detail where you need it.
I believe that once again memory provides the first limitation to the mesh. That is - you'll run out of memory loading your insanely huge mesh long before you hit a limit to the DSF container structure. And once again, even the RAM limit isn't a hard limit because that virtual address space is shared with texures. Your mesh density limits actually go down when your textures go up because it's a zero-sum game.
Estimating Memory
Here are some ideas on how to estimate your memory footprint:
- Run X-Plane over ocean to get an idea of the baseline memory use that the sim needs without extra scenery.
- Load your mesh without textures (move the textures away) to find the cost of the mesh itself. (I am going on the assumption here that you can rescale your mesh using whatever mesh generation tool you're using).
- The size of DDS textures is a good proxy for the memory used.
Tuesday, February 05, 2008
MeshTool: The Seeds Are Sown
Last night I created the "seed" files for MeshTool. Let me explain what these files are and why we'll need them.
MeshTool is a wrapper around our irregular-mesh generation code. It will allow third parties to create base mesh scenery without having to create triangulations. Just like DSFTool saves people the work of having to encode DSFs (with point pools, command lists, and all that ugly stuff), MeshTool saves people the work of having to create their own triangulations.
MeshTool is a low level tool - you provide a text input file and some data. It's designed to be an engine underneath tools like PhotoSceneryX, not an end in itself.
MeshTool will create "default" land-use terrain that approximately matches the global scenery, water, and custom orthophoto-based terrain. You (or a program you use) provide a text file that describes the boundaries between custom photos, land, water, and airports. You must also provide a SRTM-style HGT file for elevation.
How does X-Plane know what land-use should go on what terrain? That's where the seed files come in. Our global scenery is generated from a set of rules that take into account morphology (land height and slope), approximate climate, and general land use. You provide the terrain shape via the HGT file, and we provide you with a seed file that contains climate and land use for that DSF tile.
Why do we provide the seed file rather than letting you find and create climate data? Well, our rules are tuned for a very specific pair of data sets; by providing the exact climate and land use data that we use, we assure that the rules files work correctly. The purpose of MeshTool is not to customize land use terrain, and we do not provide a mechanism for it. The purpsoe of MeshTool is to let you put orthophotos and new coastlines into the base mesh.
The good news is: seed files are tiny. They are typically 4 kb-8kb each; the entire data set is 322 MB total. That's because the climate data is only 3x3 per DSF and the land use is only 121x121.
I hope to get MeshTool into some kind of testing within the next few weeks; if you are a programmer and would like to feed MeshTool from your own program, please contact me and perhaps I can arrange an alpha copy. I will also post the seeds as soon as I can.
MeshTool is a wrapper around our irregular-mesh generation code. It will allow third parties to create base mesh scenery without having to create triangulations. Just like DSFTool saves people the work of having to encode DSFs (with point pools, command lists, and all that ugly stuff), MeshTool saves people the work of having to create their own triangulations.
MeshTool is a low level tool - you provide a text input file and some data. It's designed to be an engine underneath tools like PhotoSceneryX, not an end in itself.
MeshTool will create "default" land-use terrain that approximately matches the global scenery, water, and custom orthophoto-based terrain. You (or a program you use) provide a text file that describes the boundaries between custom photos, land, water, and airports. You must also provide a SRTM-style HGT file for elevation.
How does X-Plane know what land-use should go on what terrain? That's where the seed files come in. Our global scenery is generated from a set of rules that take into account morphology (land height and slope), approximate climate, and general land use. You provide the terrain shape via the HGT file, and we provide you with a seed file that contains climate and land use for that DSF tile.
Why do we provide the seed file rather than letting you find and create climate data? Well, our rules are tuned for a very specific pair of data sets; by providing the exact climate and land use data that we use, we assure that the rules files work correctly. The purpose of MeshTool is not to customize land use terrain, and we do not provide a mechanism for it. The purpsoe of MeshTool is to let you put orthophotos and new coastlines into the base mesh.
The good news is: seed files are tiny. They are typically 4 kb-8kb each; the entire data set is 322 MB total. That's because the climate data is only 3x3 per DSF and the land use is only 121x121.
I hope to get MeshTool into some kind of testing within the next few weeks; if you are a programmer and would like to feed MeshTool from your own program, please contact me and perhaps I can arrange an alpha copy. I will also post the seeds as soon as I can.
Monday, February 04, 2008
No Answer Does Not Mean Go Ahead
Every now and then I see a comment in an X-Plane forum somewhere to the extent of:
"Joe Author made this great scenery pack for FS2K4, I tried to contact him about a port. I got no response, and the pack is free anyway, so I've posted my conversion."
Simply put, you can't do that, at least not in the United States. Copyright law is very clear on this subject: if you don't hear back from the author, the default is that you do not have permission to create a derived work.
(The fact that the original package was "free", meaning cost zero dollars, is not at all relevant. The author retains his rights to his own work even if he doesn't charge money.)
A simple thought experiment reveals why it has to be this way: if I was giving away my new program as a promotional period and went on vacation, and you decided to post a derived work because (1) it was free and (2) you hadn't heard from me, I would have no way to stop an illegal use of my work that I did not ever want (nor ever indicated that I wanted). "Free" plus "no one is home" is simply not a high enough bar to protect authors.
"Joe Author made this great scenery pack for FS2K4, I tried to contact him about a port. I got no response, and the pack is free anyway, so I've posted my conversion."
Simply put, you can't do that, at least not in the United States. Copyright law is very clear on this subject: if you don't hear back from the author, the default is that you do not have permission to create a derived work.
(The fact that the original package was "free", meaning cost zero dollars, is not at all relevant. The author retains his rights to his own work even if he doesn't charge money.)
A simple thought experiment reveals why it has to be this way: if I was giving away my new program as a promotional period and went on vacation, and you decided to post a derived work because (1) it was free and (2) you hadn't heard from me, I would have no way to stop an illegal use of my work that I did not ever want (nor ever indicated that I wanted). "Free" plus "no one is home" is simply not a high enough bar to protect authors.
Subscribe to:
Posts (Atom)