If you have a third party add-on and you haven’t tested it against X-Plane 9, well…honestly it’s probably a little bit too late to fix compatibility bugs now. We’re in RC, and only changes to fix critical bugs are going into the sim; everything else will have to wait for 9.1.
So if you have an add-on and you haven’t tested it against 9.0, for crying out loud, do it now! Submit the bug anyway – if we can’t fix it for 9, we can fix it for 9.1. But…after almost 14 weeks in beta, we’ve got to close this build up.
BTW a minor side note on fuel pumps…
In X-Plane 864, an airplane will run even if the electric fuel pump is off. (However, if the fuel pump failure is triggered and the electric fuel pump is off, either by switch or electrical-system failure, then you’re out of fuel.)
X-Plane 900RC1 restores this behavior; in beta 25, an electrical failure would turn off all sources of fuel. This is wrong for a plane like the C172 where gravity can feed the engine.
In the long term X-Plane does need a more complex abstraction (e.g. does this plane have gravity feed or engine drawn fuel, or engine driven pumps, etc. etc.) but for now the 864 model, while inaccurate and incomplete, causes less problems than beta 25, which was simply wrong for a number of planes.
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 1024×1024, and in X-Plane 9 it is 2048×2048.
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 2028×2048 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.
Generally the size of the DDS texture on disk is a good proxy for the virtual memory that is required to hold your textures.
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.
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 3×3 per DSF and the land use is only 121×121.
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.
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.
I may be fighting a pointless and unwinnable linguistic battle, but I have to try. People very often refer to the default city buildings in X-Plane as “auto-gen” but by any reasonable definition of “auto-gen” they are not really auto-gen at all.
Now these are all made up computer terms, so we can’t really check the dictionary. But “autogen” scenery (short for automatically generated) usually refers to scenery that is created by a flight simulator itself, usually while you fly, and usually by placing 3-d detail in places that match the base terrain. This exists in FSX, and existed in X-Plane up to version 7.63.
X-Plane 8 doesn’t have autogen!!!!!!! X-Plane 8 has scenery that is generated by computer programs, but X-Plane is not the computer program that is doing it. When you see a ton of buildings piled up in New York City, that is not becaues X-Plane looked at the New York city base terrain and said “hrm – some buildings would be nice.”
What actually happens is we analyze New York City when we create the global scenery (before we ever burn the DVD masters) and the DSF generator places all of those buildings in New York City. X-Plane simply gets a huge list of buildings from the DSF and draws them.
I am going to try to coin the term “algogen” (algorithmically generated) to describe these buildings that (like autogen) come from a computer generating semi-random buildings from input data, but unlike autogen, algogen is a process that runs once before the scenery is made.
So how is algogen and autogen different?
- You can’t change the pattern of algogen building placement by editing files in the sim. The algorithm has already been run! You can replace the buildings using an overlay (that excludes the base) or by using a library of models to substitute models.
- We are trading data size for computation. The DSF is bigger because it lists the location of every building in New York, even if they were just algogen buildings, but the job of placing those buildings is less difficult because X-Plane does not have to check each building against each road. That has been done in advance.
- Changing the scenery via an overlay doesn’t change the algogen! Add an airport via an add-on and you have to exclude the buildings. (But if you send that airport to Robin, the next global render will include it and the algogen will skip the airport automatically.)
Note one of the interesting results of algo-gen: X-Plane can’t tell the difference between an alg-gen building and a hand-placed one! They’re all just objects in a DSF. The fact that algo-gen buildings disappear with lower settings is because the sim/require_object property in the DSF header tells the sim which objects are important, and our generator always signals the buildings based on obstacle data as important. But algogen as a process is not visible to X-Plane!
And that’s why I’m spending so many words on trying to distinguish between “algogen” and “autogen” – because the processes are fundamentally different, they’re very different for scenery authors to work with. As a result, authors coming from X-Plane 7 or FSX will be very surprised if they try to understand X-Plane in terms of autogen….they won’t be able to find the autogen config files, and the autogen buildings won’t react to other scenery changes, because they’re not actually autogen at all!
Algogen is a classic pattern of “precompute” vs. “compute-while-fly”. Generally precomputing gives authors more flexibility (in our case, we have an obj engine that can handle a lot of objects, so authors can make their own objects of the same density as algo-gen with the objects placed anywhere) at the expense of making it more complex to edit the existing scenery (edit the mesh and the algogen doesn’t change).
When we started the v8 scenery, two things pushed me toward precomputation:
- In the past, changes in X-Plane’s rendering engine had broken third party add-ons. So a precomputation strategy (by getting the scenery code out of the sim) means that the sim is doing less “interpretation” and thus the interpretation of scenery is less likely to change.
- We wanted to focus on performance, which means getting computation out of the sim whenever we could.
Now that last point isn’t quite as important as it used to be…when we were doing the design (during mid X-Plane 7), dual core for everyone wasn’t on the radar, so the penalty for complex computation while flying is lower (and thus we have more expensive in-flight computation, like forests and completely draped bezier curve-based polygonal pavement).
But I think precomputation is still useful. Even with dual core, the algorithm that places X-Plane’s algo-gen bulidings can take one to two minutes for a 1×1 DSF tile on a very fast computer. That’s still a load time that’s out of the question for us; even on the second core, the DSF wouldn’t be “ready” in time for you to fly it. So one use of precomputation is to run algorithms that are more expensive than you can have in real-time. (That algorithm to pack objects inside an irregularly shaped polygon made by roads and land features is not fast.)
More importantly, precomputing does give us a nice advantage in the use of storage data. We ship about 50-60 GB of final scenery, but the source data is well over 100 GB. When we run the algogen algorithm, we have access to the full set of source data: coastlines, elevation, and land use before any simplification is done and any data is thrown out. So we have the potential not only to do a more complex analysis, but to do the analysis on a larger data set.
The down-side of precomputing is that if integration of all data is saved until sim time, there is the potential for third parties to contribute separate data to the sim via add-ons and still have the integration of those data sets work well. This doesn’t always work out – see complaints in online magazine reviews about combining orthophotos and new road grids in FS2K4…they don’t integrate because neither of those types of resources can be integrated to match the other in real time. But autogen still does a much better job than algogen at this; algogen basically has to be recut when other data changes. (And that is our intention – if you change the road grid, exclude and replace the objects too!)
I figure there are three things that making blogging suited for software:
- A small interested group of users can subscribe to a blog without giving out an email address.
- The information in the blog can be found using a general search tool like Google.
- It’s easy for a busy programmer to post.
I think this last point is not to be ignored – I post a lot here because it’s easy enough to whip up a blog post that I can write one while the sim is booting.
The down-side of this is that blogs are not self-organizing. The blog is chronological, and somewhere within a heap of 200+ posts are detailed information on scenery topics not documented on scenery.x-plane.com.
That’s not good. So I’ll be trying to make a concerted effort to write real permanent documentation for some of the new scenery system topics that I cover. Documentation on DDS is in the works.
Part of the problem is that my interface for updating the X-Plane scenery website isn’t that robust. One of the nice things about the plugin system being a Wiki is that it’s easy to organize and easy to edit. (And one of my frustrations with “support forums” is that they don’t self-organize…they mix questions and answers based on history and not a search key that a user might use, like “what’s wrong with my card.” We’ll be supplementing the Linux forum with a Wiki soon.)
We get a lot of bug reports showing strange reflections in the water. Some of these we can fix easily, and some will be more difficult, if not impossible. There are two fundamental constraints on the water-reflection code:
- A reflective surface (read: water) must be approximately flat to be correct. This is just how the algorithm works. (If you want to see why a non-flat surface fails, try to draw a camera position opposite the reflection plane and trace rays through this “reflection camera”. Draw reflected objects that are close and far from the water and then observe the parallax error you get if the reflection plane curves.)
- We need one “water camera” for each flat reflection plane. You can’t just statically offset when we have multiple elevations. (When drawing your diagrams, note how an elevation change causes a change in reflected angle, not just an offset.)
So the water will always have two problems: the earth is round (so nothing is really flat), and we can have lakes of multiple elevations (and we can’t afford to render a water reflection per lake).
X-Plane tries to get around the non-flat water problem by picking little bits of the water that are flat (and seem useful) and using them to define reflections. This algorithm will always have problems, but at least it can be tuned.
Now there are also some things that we can fix with the water:
- The math in beta 18 is simply wrong, something that will be fixed in beta 19.
- The ocean is built from polygons that are too large; this introduces approximation errors when we try to pick “a little bit” of water to use to figure out our reflection plane.
There is one more problem that I see, especially in airports like PAKT: if there are two water surfaces of different heights that are nearby, X-Plane uses a slanted water plane that tries to include both. This works very badly – the resulting slanted plane doesn’t look even remotely plausible. I’m not sure how soon we can tune this problem.
I get a lot of requests for settings…the email is typically something like:
- Some feature in X-Plane is defaulted to X.
- I like it better when it’s like Y.
- Can I have a setting to change the feature between X and Y.
Raymond Chen has a great posting that I think is very topical: “In order to demonstrate our superior intellect, we will now ask you a question you cannot answer.“
This brings up one of the main reasons why we shy away from more settings: the more complex we make X-Plane’s configuration, the less likely it is that the average user will be able to set the sim up correctly. Settings requests usually come from our most advanced users, but we also have users who have never used a computer before. Really! I’ve been on the tech support calls – they are very nice, but way overextended on the computer side of things. Should we allow them to pick whether scenery geometry is store in AGP memory vs. VRAM?
From our perspective, having a setting that a user doesn’t understand is worse than neutral, it’s actually harmful. Every one of those settings is something that can go wrong with the sim. I removed the ability to set the level of detail bias to positive (in other words, extend the visibility distance of scenery beyond its original design) after about 500 complaints of “low framerate” from users who had maxed this setting out (causing a 4x increase in 3-d processing load) without knowing (1) what the setting was, (2) what it was good for or (3) what the down-side was.
Could we present all the info to make intelligent decisions on the rendering pages? Honestly, probably not beyond a certain point…we would devolve our sim into a lecture on working sets, bottlenecks, and the OpenGL pipeline long before the user got flying. (Wait, that’s my blog! Doh!!!) At some point the sim just has to do its best to do the right thing, or something similar to it. Just as Raymond points out that the default answer to any dialog box is “cancel”, the default answer to any rendering setting is “all the way up.”
When I tell a user who wants a setting that he or she can’t have a setting because some other user will abuse it, the answer is almost always: well why don’t you have two settings screens, a simple and advanced mode?
Besides the irony (of trying to solve the problem of too many settings with another settings), Raymond also points out that no location to hide an advanced setting is ever quite good enough. This is something we have struggled with, choosing command-line options more for to pragmatic reasons than because it’s a great solution.
This doesn’t mean you can’t ask for command-line options…I am just trying to point out some of the thinking on the other side of the coin.
There are a few cases where you cannot use DDS files in X-Plane:
- Airplane 2-d panels (any layer – base, lit, -1 shadow layer, 2-d or 3-d).
- Airplane instrument images.
- Bitmap-based region specification referenced in a library.txt file.
- Any gray-scale/alpha-only texture (e.g. mask files in the scenery system).
Beta 17 is treating cases 1 & 2 as an error; beta 18 will simply stop looking for DDS files in those cases.
Please note that airplane panels and instruments are not compressed right now, so there would be no performance benefit to using DDS in these cases. (If anything, PNG has smaller file size when compression is not used.) If we ever allow compressed panel textures, we’ll probably allow DDS panels at the same time.
Case 3 is just a particular version of case 4 – that is, the region bitmap is black and white (1 channel) so DDS provides no benefit. Use a gray-scale no-alpha PNG!
First, the most salient point: in X-Plane 9.00 beta 16, 2-d panels and 3-d cockpits should both look the way they did in version 8. That is, your v8 plane should look good in v9 without modification. This is due to both:
- A bunch of bug fixes regarding burn-in and night lit layers.
- “3-d” lighting is not applied to the cockpit texture.
On this last point, my hope had originally been that I could apply 3-d lighting to the cockpit and simply make existing content look better. It has become painfully clear to me that this is not possible — existing planes are very carefully tuned to look good despite what I can only describe as “inconsistent” lighting rules in v8. Applying more consistent general 3-d lighting wrecks this tuning.
So new features regarding 3-d cockpits will be opt-in – that is, you will have to change your model to start using them. Existing content will work the way it used to.
I will explain what new features are available in 9.0 and what will come in 9.1 in a separate post real soon.
