I saw a post about this on X-Plane.org…authors sometimes try to make a vehicle (a car, truck, etc) modeled via an OBJ “drive around” using animation translate commands. The problem is that sometimes the objects disappear. Here’s what is going on:
X-Plane uses a bounding sphere to decide whether to draw an object. The bounding sphere is the smallest sphere X-Plane can fit around the entire object; if the sphere is on screen, the object is drawn (even if the object itself isn’t on screen). We do this because we can test whether the sphere is on screen very quickly.
But what if the object has animation? X-Plane attempts to guess how animation might affect the sphere by looking at animation commands and making the sphere a bit bigger where animation might move the object outside the sphere. This process works, well, rather poorly. In particular, X-Plane doesn’t know exactly how your datarefs will change. This results in two error cases:
- If X-Plane assumes the animation is more drastic than it really is, we make the sphere too big. The object will then be drawn even when it is not on screen (because the sphere is on screen because it is too big). This case hurts fps but does not cause objects to disappear.
- If X-Plane assumes the animation is less drastic than it really is, we do not make the sphere big enough, and sometimes the object “disappears” because the object is on screen but the (too small) sphere is not.
Now let’s apply this to objects that are driving around. Usually this is done via a translate animation command where datarefs feed the object’s position.
X-Plane estimates the effects of a translate animation using the largest and smallest key frame values. But the animation engine will extrapolate beyond these key frames. So consider these three cases:
- As your dataref goes from -1 to 1, you translate by +/- 1 meter. In this case, the bounding sphere will be increased in radius by one meter.
- As your dataref goes from -25 to 25, you translate by +/- 25 meters. In this case, the bounding sphere is increased in radius by twenty five meters.
- As your dataref goes from -1000 to 1000, you translate +/- 1 kilometer. In this case, the bounding sphere is increased in radius by 1000 meters.
Note that in all three of these cases, the animation works exactly the same! But by using different dataref and value extremes, X-Plane’s estimate of the effects of the animation (and its change to the boundign sphere) can be quite different.
So…if you animate an object and it disappears, it is probably because the bounding sphere has not been increased, perhaps because a translation animation is being sent values outside its minimum and maximum values.
The problem is of course that to have an object “roam” over a large area, it must have a very large bounding sphere, which means it is being drawn a lot more than necessary.
Lines are a bit long here in Maryland, and we’re not even a swing state. Doesn’t matter! Go vote!
Previously I have blogged about a key choice in file format and scenery system design: will the file format be “specification based” or “reality based”.
Specification based: the format has an exact interpretation of the data. OBJ is an example of this…the format describes triangles and there is only one interpretation of what that triangle could be.
Reality based: the format models real-world concepts; the correct interpretation is “as close to the real world as possible.” The nav.dat file is like that.
I have been reading the OpenStreetMap Wiki and hit upon something I didn’t realize: you can’t use copyright to protect a derived work from a file that simply contains a list of facts!
Now I am a programmer – I am used to writing code, slapping a copyright notice up top, and assuming that it’s now mine…heck, I’m the one getting carpel tunnel from typing it out. But consider the nav.dat file; it contains a giant list of frequencies for navaids. It’s a fact that the BOS VOR is 112.7. Is my mentioning of that fact in this blog a derived work of the nav.dat file? Of course not, and it’s a good thing too because otherwise we wouldn’t be able to state facts without IP conflicts.
The OSM guys believe that they need to change their license to something weirder than the CC-BY-SA license they have now because the CC license uses copyright, you can’t copyright facts, and OpenStreetMap is really just a huge collection of facts.
Now at this point I’ve written six paragraphs too many without the obligatory “I am not a lawyer.” I am not one. And I must admit, my biggest concern with all of this is that it gets confusing and hard to interpret, and I’d be perfectly happy if there were only 3 or 4 licenses out there for everyone, you’d pick your favorite flavor, and everyone would know what it means.
Suffice it to say, it never occurred to me that a criteria of a file format might be “protectability” – that is, does the file format allow an author to specify something other than facts, so that it is elligible for copyright protection?
If you are an author, the good news is: pretty much all of our file formats would meet that criteria:
- OBJ and DSF are essentially 3-d modeling containers (DSF is just a damned wierd one).
- Images are copyrightable, so that takes care of your textures.
- Plugins are code, clearly copyrightable.
- ACF files contain, among other things, 3-d models, see the first point.
- Apt.dat would be the format most at risk of “factualization”, but I think you could argue that the arrangement of bezier curves and attributes is more of an artistic 3-d model than a statement of fact.
But who knows, I am not a lawyer.
(Oh yeah, this whole article is written from an entirely US-centric viewpoint…I am even less qualified to speak of such things outside the US than I am here at home.)
I’m never quite sure about naming names. There are users whose contributions to X-Plane and its scenery system have been immense – we wouldn’t have what we have without them.
But I don’t want to make the decision to blog for anyone else – this blog is part of Laminar Research’s communications to our users, and I don’t want to set up content that leads our paying customers toward third parties who may not want the extra questions/attention.
So I guess for now what I’ll say is this: the work I discuss here on this blog is not a solo effort – I have had the good fortune to collaborate with some really good people, and it has made X-Plane that much better of a flight simulator.
To everyone who has helped me with the scenery system: thank you!!
This thread on X-Plane.org sparked off quite the discussion. Now a lot of this is a discussion of when LR will have an overlay editor – there are a few overlay editing functions that Jonathan Harris’ excellent OverlayEditor apparently does not yet support, sparking this discussion.
(I am not saying that LR should rely on Jonathan to do an overlay editor. But I am saying that the complaints I hear about a lack of overlay editing go down when Jonathan’s overlay editor does everything that the file formats can do.)
But another part of the discussion focused on the problem of mesh editing. In particular, the basic terrain in a DSF is a fully baked output of a complex process that starts with higher level GIS input data. In other words, we start with a raster DEM, polygon coastline, apt.dat file, vector roads, and a bunch of config files and hit “bake” and a DSF comes out the other side, with a lot of processing.
This is very different than FS X, which integrates its data sources on the fly. Why did we choose a precomputed route for scenery? It has some pros and cons. (In understanding how we made these decisions, think back to what scenery was like with X-Plane 7 and ENVs and single-core machines.)
Performance
The main benefits of preprocessing scenery are performance related. When you process scenery data into the final scenery while flying, that computer power takes away from the rendering engine, thus cutting down fps. At some point you have a zero-sum game between how much cost there is to loading scenery and how complex the scenery integration can be; you have to pick very simple scenery integration algorithms to keep fps up.
(This is less of an issue as more cores become available, but is still a factor.)
When pre-processing, we can use algorithms that take minutes per DSF without affecting framerate.
Similarly, there might be scenery processing algorithms that improve fps by optimizing the output triangles – but do we have time to run these algorithms during load? With preprocessing we have all the time in the world because it happens once before the DVDs are burned.
Preprocessing also breaks a similar zero sum game between scenery data size and quality; the source data we use to make the scenery is a lot bigger than the 78 GB of DSFs we cut; if we had to ship the source data, we’d have to cut down the source data quality to hit our DVD limitations. With be-baking we could use 500 GB of source data without penalty.
Format Flexibility and Stability
The second set of benefits to preprocessing are flexibility benefits. (Consider the file format churn of the ENV days.)
– With a preprocessed scenery file, what the author creates is what the user sees – X-Plane does not go in and perform subjective integrations on the scenery later that might change how it looks in a negative way.
- There is no need to revise the scenery file formats to introduce new data sets, because new data sets and old are all processed to the same final DSF container format.
- A wide variety of mesh generation techniques can be employed because the mesh generation is not built into X-Plane. This is a flexibility that I don’t think anyone has really utilized.
- Changes of behavior in the scenery generation toolset can never affect existing scenery because that scenery is already preprocessed; this help compatibility of old file formats.
Integration Issues
There are some real limitations to a pre-processed format, and they are virtually all in the bucket of “integration issues” – that is, combining separate third party add-ons to improve scenery. In particular, in any case where we preprocess two data sources, we lose the opportunity for third parties to provide new scenery to replace one of those data sources and not the other.
Airport is the achilles heal where this hurts us most; while airport layouts are overlays and can be added separately to the scenery system, the elevation of the base mesh below the airport needs to be preprocessed. This is something I am still investigating – a tolerable fix that other shave proposed is to allow an overlay scenery pack to flatten a specific region regardless of the user setting (so an author can be assured of a flat base to work from).
Preprocessing does fundamentally limit the types of third party add-ons that can be done; with version 9 and overlay roads, we are getting closer to letting road add-ons be overlays (see this post).
It appears to me that integration isn’t the primary complaint about the scenery system (the primary complaint is lack of tools) but we’ll have to see once we have mesh editing tools (mesh recreation tools really) whether preprocessing still limits certain kinds of scenery.
Note that a lack of tools or a lack of tool capability is not an inherent limitation of pre-processed scenery. We have an incomplete tool set because I have not written the code for a complete tool set, not because it cannot be done.
(The complexity of writing base mesh editing tools is a function of the complexity of a vector-based base mesh – this is also not related to pre-processing per se.)
Tools
In the end, I think the question of tools is not directly tied to the question of pre-processing. Whether we have scenery that is processed by X-Plane or a preprocessing tool, we have the same issues:
- Good tools require an investment in coding user interface.
- The code to convert source data which users might want to edit (like a polygon that defines a lake) to data the simulator might want to use (like a list of 78,231 triangles) has to be written.
I don’t think either option (pre-processing or in-simulator processing) reduces the amount of work to be done to create a good toolset.
As a final thought, using scenery file formats that are “easier to edit” (e.g. a file format that contains a polygon for water rather than triangles) doesn’t make the total code for scenery tools + simulator any easier; it just moves the task of “processing” the scenery from the tools to the simulator itself.
I always have to hesitate before posting a possible future direction to my blog – our future plans are a road map, a direction we intend to follow, but if circumstances change, our plans change. (This is one of the great powers of software: the ability to be flexible!) Unfortunately in the past, I’ve posted ideas, and then when we didn’t productize them, gotten back “but you promised X” from users. So now I’m a little bit gun-shy.
But let’s try the reverse: what about a feature that I am now pretty sure won’t go into the sim?
We were looking at running the flight model on a separate core from the rendering engine. The idea is that the less work must be done in series with that main rendering thread, the higher the total frame-rate. But now it looks like it’s not worth it. Here’s my logic:
- The rendering engine now runs best on at least two cores, because all loading is done on a second core. So unless you have a 4+ core machine, X-Plane is utilizing close to all of your hardware already.
- The flight model isn’t very expensive – and the faster the machine, the less percent of time the flight model takes (because it does not become more expensive with higher rendering settings).
- Therefore I must conclude: threading the flight model would only help framerate on hardware that doesn’t need the help – modern 4+ core machines.
So why not code it? (Even if the improvement in framerate would be pretty low, it would be more than zero.) Well, besides the opportunity cost of not coding something more useful, there’s one thing that makes a threaded flight model very expensive: plugins.
Plugins can run during various parts of the rendering engine, and they can write data into the flight model. I bounced a number of ways of coping with this off of Sandy, Andy, and others, and I don’t see a good way to do it. Basically every scheme includes some combination of a huge performance hit if a plugin writes data from render time, a lot of complexity, or both.
So the simplest thing to do is to not try to thread the FM against the rendering engine, and instead continue to use more cores to improve the rendering engine.
This doesn’t apply to running more than one FM at the same time (e.g. AI planes and the main plane at the same time). It’s the question of the FM vs. the rendering engine that I think now is not worth the benefit.
With the iPhone and X-Plane 9, we’ve been very busy…with this in mind, I am pleased to announce the latest engineer to join Laminar Research.
“Nubblet” would like you to know that the MacBook Pro is, in fact, “hers”. 🙂
The 2.05 installer is now released – this is a multi-language update that fixes a few bugs and makes the map interface more usable. If you have existing DVDs, you may want to use the new 2.05 DVD installer because it scans the scenery folder very quickly when you pick “add-remove scenery”.
(The old installer would check the signatures of all scenery files – this one simply checks whether they exist.)
No URLs have changed – installers will always have the same file names and live at the same URLs; you can pick “Get Info” or “Properties” to tell their version (or run with –version on Linux).
I have a ton of emails I need to get through, so if you emailed me, I do apologize; I will try to clean out the pending tech support issues, etc. in the next week.
Sometimes I have one of those weeks where all I do is look at crashes and weird behavior. This is turning into one of those weeks. So here’s some status on the various bugs floating around.
I should say: you’ll find a lot of developers blaming the technology providers for bugs (just look at how many OpenGL developers have blamed ATI for their apps crashing). Sometimes it’s the app, sometimes it’s the driver. More importantly:
- You don’t know who’s fault it is until you fully understand the bug.
- The fix for a bug might not be in the broken code. That is, one piece of code can work around a bug in another.
So…you can’t necessarily tell whose fault it was from new drivers coming out, us changing the sim, etc. But…when it’s my stupid code, I’ll admit it openly – no one should think that a bunch of other smart programmers are screwing up on my behalf. (This is also useful to other apps developers, who can know that my bug isn’t the same as their bug, since my bug was in my code.)
X-Plane: we’re happy with 921r2 finally…the final bug (crash on startup on the Mac) was due to an incompatibility between Apple’s OpenAL implementation and special memory allocator (which is really just a wrapper around NEDMalloc). I still don’t know exactly what the rules should be (you try reading the C++ spec!) but for now we turned the allocator off on Mac.
(This brings up another issue about bugs – you can’t tell whose bug it is by whose code crashes, since one piece of code can sabotage another.)
So the next X-Plane release will probably be 930, with new features. We may have a few more language patches if needed.
iPhone: the 9.01 iPhone patch is out, and it improves framerate a bit. We are still seeing crashes on startup for users who have just downloaded the app. Rebooting the phone will fix this, but please see
this post for more info! We need your help to collect more data.
Radeon 9800 on Windows: for the longest time we’ve had users reporting “framebuffer incomplete” errors when using catalyst 8.x drivers, an R300 chipset, and Windows with X-Plane 9.x. I have been trying to reproduce this problem “in the lab” off and on for months, but finally saw it this week. From what I can tell, we’re getting into some low-memory condition and the driver is freaking out in various ways. The command line options people sometimes use to get past this are probably rearranging memory, not saving it. I don’t know why the Catalyst 7.x drivers don’t have this problem. But…at least I am making more progress than I was before. Please see
this post for more info.
Installers: I am working on the 2.05 installer. I have seen a number of users report problems running a full install from DVDs, so I am just starting to investigate that. I will post more when I have something to test. Unfortunately the problems reported are not something we see here.
I’ve rewritten this post about four times now…let me try the brief version.
Basically, X-Plane is not an early adopter of graphics technology. Because of the nature of the rendering we do, we can directly benefit from “more of the same”, e.g. if you simply gave me twice as many objects per second or twice as many polygons, we could make the sim look a lot nicer. So we don’t need to adopt new graphics technologies until they’re proven in games that need them more, like first person shooters. We’re a small company with no influence on the industry, so we write the tightest message we can and use new features when the dust settles.
(From a utilization standpoint, we also provide the best graphics to the most people by using card features that are going to become wide spread, so it doesn’t make sense for us to gamble on vendor-specific extensions that might not become available to everyone.)
With that in mind, there is some cool stuff that people are talking about that maybe someday we’ll get to play with:
- Irregular Shadow Mapping – given a super-programmable card, you can create a rendering scheme that optimizes shadow map creation to remove artifacts.
- Out-of-order blending – the graphics card resorts incoming geometry so that all translucent geometry is drawn back to front. Doing this on the CPU is expensive (and in X-Plane’s case, we often just don’t get it right at all).
- Multiple dispatch to multiple targets. Even on a big multi-chip GPU (a lot of modern cards are two cards stuck together) the only render to one screen or texture at a time, even if there are a lot of parallel elements. This is good for a few big complex scenes but not good for lots of small scenes. I’d like to see all vendors support dispatch to multiple targets – this will make things like dynamic reflection via environment cube maps potentially a lot faster.
- Voxel Octrees. This is the one I hear a lot about – basically it’s a change from 2-d to 3-d data structures on the graphics card to manage fast access to large chunks of graphics data. (Shadow maps, z-buffers, and environment maps are all more or less 2-d data structures.)
Will we see this? I don’t know. Will Larabbee change everything? Who knows…Intel has to build a high-end graphics card to fight ATI and NV’s attempt to get into supercomputing, but if they happen to also build a really nice video card, I can live with that. But I won’t hold my breath – the titans need to duke it out without me!
