There have been plenty of rumors and semi-official posts regarding the upcoming major revision of X-Plane (X-Plane 9). I have been trying to keep my mouth shut about it…the problem with pre-announcing anything is that the upside to us is small (at best we do what we said) and the downside is large (at worst we don’t do what we said and people get grumpy). No one complains if XP9 turns out to have no-pause scenery load and it’s a surprise…but plenty of people complain if we say “there won’t be pauses” and then they are.
But…the situation is becoming mildly absurd…plenty of info is out there, and saying “the upcoming major release”, etc. just feels political and weaselly. Austin would be disgusted.
So listen: I am going to try to provide some info on X-Plane 9. This info is subject to change. This is what we think is going to happen to the best of our knowledge. The release is still a ways away and enormous changes will happen. When things change, do not bitch to me that “you promised X” would happen. I do not promise anything. This info is provided to try to help those making add-ons for X-Plane plan appropriately.
With that in mind…I will try to post some more details on the authoring environment in the next few days. For now, here’s some very basic guidance on compatibility and hardware requirements:
- The hardware requirements will be at least as high as X-Plane 8. If your machine is gasping and wheezing on 8, it’s not going to be any better on 9.
- X-Plane 9 will depend more heavily on pixel shaders. If your hardware doesn’t have pixel shaders (GeForce 2-4, Radeon 7000-9200) or has really crappy shaders (GeForce FX series) you will miss out on a lot of the cool stuff in v9, and possibly have the scenery look worse (but faster) than v8 (as we move features from the CPU to pixel shaders).
- Scenery that opens in x-plane should open in X-Plane 9 unmodified – if the scenery works in 8 but not 9, report it as a bug!
- Plugins that work in v8 should work in v9 without modification.
Finally, we are trying to finish up X-Plane 861…this is a bug-fix patch for version 8 – it contains no new features, but it does fix a few nasty bugs, some of which cause crashes. So if there is any new feature, it’s coming in 9, not 861. Version 8 has been out for a very long time, so I will accept no argument that v8 should have more features than it does now. It’s been a long run!
(One of my main goals with 861 is to try to fix any weird behavior for third party scenery add-ons, so that a scenery add-on looks the same in v8 and v9. If we left the bug in 861 and fixed it in v9, authors would have to hack the scenery to make it work with v8, and then remove the hack and republish for v9. By trying to fix the authoring bugs in v8, at least when possible, it lets authors publish one package for both versions. Of course, v9 will have new features, so I expect some v9-only scenery will emerge pretty quickly.)
I’ve heard a few reports that 861 is slower than 860. I think this is rather unlikely given the code changes made in the 861 patch, but I take all performance issues very seriously!!
I can’t get X-Plane 861 to run slower than 860, so here’s the data I need:
- If you are seeing this, start by getting a simple case, e.g. sitting on the runway staying still, with a known viewpoint. The conditions have to be reproducible and stable — “overall the sim is slower” isn’t quantitative, it’s an impression. Ranges of fps aren’t precise enough.
- If you are using third party add-ons, strip ’em out. Does the fps problem go away? If not, good, let’s get a case that uses only the simplest setup. If the fps problem does go away, let me know what add-on it is…perhaps a particular add-on exacerbates a performance problem.
- You can put the 860 x-plane app into an 861 folder – do this for all regressions to make sure you’re using the same prefs file, etc. etc.
- Of course most useful is: run the fps test – if you can send me comparative fps-test logs, this is the most useful thing because it controls virtually all variables!
With that in mind, please email me log files, pref files (if you must use a specific prefs combo to see a problem), etc. Please do not just tell me descriptions – that’s not precise enough!
In order to maximize X-Plane’s framerate, you need to start with the lowest settings and work your way up. Can you start with the highest settings and work your way down? No! Here’s the problem:
X-Plane’s framerate is determined by the slowest part of the system…whether it’s your CPU, AGP bus, or any of the parts of your graphics card (pixel shaders, lack of VRAM, lack of internal card memory bandwidth). Whatever the problem is, the graphics are drawn in an assembly line, and the rest of the hardware sits bored while the slowest part finishes its backlog.
So…why not start with the highest settings and turn them down? The answer is that when the framerate is slowed down by component A, changes in the load on component B won’t show as a difference of framerate, because component B isn’t the slowest. So as you turn down settings, you’re not seeing the real effect. (The safe thing to do would be: turn B back to its old setting, then retry.)
What I recommend is: start on the lowest settings possible – you’ll see a framerate that’s about as high as your system can go (limited by the FM and the speed the card can turn a frame around). Then turn settings up, one at a time, by one notch. Each time you see a fps hit, back off one setting and continue somewhere else. This way you won’t load up one part of the system so heavily that you are limiting the speed despite everything else.
A few scenery bugs fixed in 861:
- Some apt.dat layouts can hand 860 – I think this is fixed in 861. If your layout caused problems, retry 861RC1 first!
- Objects won’t change their position as you approach an airport from different sides. If you were seeing inconsistent object positioning, definitely try this release.
I am going to take Marginal’s suggestion: in the future, ATTR_no_depth will be mapped to ATTR_poly_os 1, and ATTR_depth will be mapped to ATTR_poly_os 0. As far as I can tell, historically the ability to turn off all depth buffering was a misguided attempt to do the kind of things that ATTR_poly_os is meant for.
This implementation will hopefully help any content that is (for some reason) still using ATTR_depth and ATTR_no_depth…modern OBJ generators like the Blender plugin and the AC3D plugin never use this old attribute.
I get a fair number of emails where users send me a link and say “can you make X-Plane/WED look like this?” I’ll beat you to the punch this week…I wish WED looked like this.
Unfortunately it probably never will for three reasons:
- X-Plane’s time to create the structures you see is slow enough that editing the real world in real-time would be difficult. We try to load things on another thread while you fly to help smooth this.
- Our scenery creators do a lot of work to build the DSFs before you fly – minutes per DSF…again, from the time the raw data changes, a lot of computation happens.
- We’re trying to keep our tool set open source, but the X-Plane rendering code is closed source, so it would have to be rewritten (a huge task), e.g. WED would need an alternate editing engine.
(Of course if it was rewritten, it could be done so to fix points 1 & 2.)
Still, we must all dream. 🙂 🙂
Posted in Tools
by
Ben Supnik |
Almost two years ago, I posted this blog entry, pointing out that some legacy OBJ commands are, well, evil.
My inclusion of ATTR_poly_os in that blog post was a little strange – when used correctly, ATTR_poly_os is the right way to overlay decals on the ground, and it is fully supported. (The message is just, I suppose, that if you need a huge number for your poly_os, something is really wrong.)
Now ignoring ATTR_poly_os, you might notice that the AC3D plugin exports almost none of those dubious attributes. But what about flat shading? Flat shading isn’t necessary, but you were allowed to use it.
So I came to my senses and modified the AC3D exporter – the exporter will now never use ATTR_shade_flat – instead it uses smooth shading and per-vertex normals, avoiding an unnecessary attribute no matter what you do in AC3D. 99.99% of the time this will yield fastest framerate?
Why wasn’t the plugin always like this? I thought it was, and only discovered today that I hadn’t finished this optimization.
I am interested in proposals for an airport-vehicle system in X-Plane. I will explain exactly what I am looking for, but first I must note the oddity of this request:
99.99% of the time, users give us too many implementation details on a feature request. Usually we want to know what you want, and not how you want it done. Example:
Bad: please implement VBOs for the 3-d clouds.
Good: please improve frame-rates when 3-d puff clouds are used.
If you ask for something too specific, we can’t tell what you really want – there might be a better implementation.
So normally the feature request is what’s useful, not the implementation.
In this case, however, I am interested in a proposed system for third party control of airport vehicles. If you have an interest in this, please write up a proposal and email me. Forgive me bashing you over the head with this, but often I get flooded with email on this.
- Please do not email me on this unless you have a full proposal for a system by which authors can control ground vehicles. Please do not email me asking for other features, telling me which type of truck is your favorite, or asking for user-level features. My goal here is to get feedback on how third parties would like to be able to customize a ground vehicle system. If you don’t understand the difference, please don’t email on this subject.
- I cannot promise that I will do anything you say, in particular, only that I will read and carefully consider anything that’s sent to me that makes sense.
- and I cannot say when this will be used (not that soon though — if we’re only in the RFC stage we’re only beginning to look at this). This is not a feature announcement.
I will try to respond to proposals quickly, but I’ve been pretty badly swamped by email, so it could take a few weeks!
In my previous post I described the underlying problems that make translucency in airplane cockit objects tricky. That gives us the background to understand how X-Plane draws cockpit objects and why.
The actual draw order for airplane-related objects is this:
- Far away weapons.
- All of the airplanes that we are not inside (this means the user’s plane in an external view, and AI planes all the time). For each of these planes, the external cockpit object is drawn first, then the parts, then the attached objects in order.
- Clouds and puffs and other such environmental phenomena.
- The geometry of our plane, if it is to be drawn and we are in an inside view.
- The attached objects in order for our plane, if internal geometry is drawn and we are in an inside view.
- Weapons that are very close to the plane.
- The inside cockpit object, if we are inside the plane.
A few things to note about this draw order:
- Note that weapons appear twice in the category of “near” and “far”. This is all about the clipping plane – if a weapon is close to us, it must be drawn with the cockpit object, late in the draw cycle, when we are doing “close” things. Weapons are treated dynamically – they change where they are in the draw cycle depending on their position in space. This is necessary because a weapon starts out real close (just off your wing) and then goes real far away.
- The user’s airplane is special-cased when we are in an internal view … at that point if external things are being drawn, they are done in the later “close” view with the cockpit.
- The external cockpit object is (strangely) quite early in the draw order. There’s really no good reason for that. What’s particularly annoying is that it’s inconsistent with the internal draw order. The main point of internal/external cockpit objects is to let you simplify your cockpit object in external view for performance.
Is there a sane way to set up an X-Plane 860 aircraft with translucent geometry? I’m not 100% sure about this, but it looks to me from the code like the correct thing to do might be:
- Put any translucent windshield/canopy/etc. in the last attached object.
- Put only the interior panel (and not the canopy) in the cockpit object.
This works because in the external view the canopy is drawn last, and in the internal view, the panel is more or less guaranteed to be closer than the canopy, which is good enough.
Today is Rosh Hashanah, the Jewish New Year. In Jewish tradition it is also thought of as the birthday of the world. If you’re reading this blog, you probably have some interest in how X-Plane attempts to simulate the world on your computer. The attempt over the years to create a higher fidelity simulation has led me to a deeper appreciation of the subtlety, complexity, and beauty of the real thing.
(Nothing makes you realize how rich and intricate the world is than trying to model it with a few million triangles and ending up with something that looks completely crude.)
X-Plane’s digital world isn’t the only way that we interact with a proxy instead of the real thing. When we drive instead of walk, eat packaged food from a supermarket, talk on the telephone instead of talk in person, our technology becomes a proxy for our relationship with our direct natural environment – the planet, plants, animals, and other human beings.
Now I’m not saying that any of these things is bad. I’m not about to become a dairy farmer, and without the internet we couldn’t create X-Plane at all. But I think it’s important on this day, and hopefully every day to take time for activities that put us in direct contact with the world. Consider a few questions:
- How does what I eat affect the world?
- How does my travel affect the world?
- What impact does my home have on the world?
- Am I leaving the world in better condition for the next generation or worse?
Please … take a few moments to consider the world, the only home we’ve ever had.
When I was in the Dolomites a few years ago with Sergio we were looking at the dolomites from his friend’s balcony – mile after mile of beautiful mountains and rolling hills. I looked at him and said “God has more polygons than we do.” It was a joke at the time, but I think that the act of really observing the real world and realizing that the digital reality and technology we create can be a proxy and an addition but never a replacement is critical to understanding the responsibility for stewardship we have over the planet. Are we taking good care of our most precious gift?
