When I tore my shoulder playing frisbee and went to the Doctor, he took an X-Ray. Why? Well, that’s obvious: my skin makes it hard for him to directly inspect what was wrong inside my shoulder; the X-Ray shows right through the skin – in that case, it revealed a torn ligament.
It’s the same way with X-Plane. If I want to see what’s really going on in the sim, using real test cases makes life hard. Our artists try hard to hide the underlying mechanism of the sim and instead create a seamless plausible experience. In a good scenery pack you can’t see where one object ends and another begins, or what is a beach and what is an orthophoto.
So my life as a developer is a lot like a radiologist – I spend a lot of time looking at the inside of the sim, and I do this by using test art assets. A good test case is easy to build and clearly identifies the underlying mechanism in the sim. What follows are a few examples of the kinds of test cases we use.
This was one of the original global lighting tests. I needed to see if the lights performed on a large scenery, so I used George Grimshaw’s KBOS, and installed two custom lights. The lights are intentionally primary colors (green and red) so make the blending and mixing completely clear.
This is a test airplane panel to look at the effect of odd-sized instruments and resized panels on pixel clarity. The test case goes through every alignment possibility using art-work that has 1-pixel lines to show blurring. This is a test pack of roads – the pack contains one of every kind of road. The sim is put into a debug mode that labels the road with its code. Using this, we can quickly inspect the entire road art asset pack to see if any road types are buggy. This is a very early version of the roads – one of the original mockups. (That’s why a lot of the roads are missing whole sections.)
Here’s another road test – in this case, there is a custom scenery pack that replaces the cars with colored axes, making it easy to debug the alignment of the cars relative to hills and highways.
These two are test autogen packs; the markings allow me to debug the code that places autogen elements in the sim. The real autogen elements blend together, making it impossible to spot bugs; these ones show alignment errors clearly.
This is an older shot from the weather system with the shadowing vectors on – the lines all over the clouds show the measurement of light going into each part of the cloud. Since clouds can be soft and nebulous, the lines show clearly what would otherwise be hard to visualize.
This test object was built by propsman and exercises approximately 100 different features of the version 10 pixel shaders. In this case, each shader ‘trick’ has a piece of artwork with a clear label to show which part of the shader is where. The real art assets use the shaders in subtle ways that make them hard to debug, but in this case, if the albedo is missing (for example), it’s really obvious.
This is a piece of DSF with the beaches replaced with a beach calibration texture. The beaches are solid and have numeric markings to show which part of the texture is being applied at any given time.
Why show these? My point is this: I spend most of my day looking at the sim with test artwork to see what’s really going on. Many of the art assets I work with are specifically built to test – others have been hacked to find bugs. When I take a screenshot, it is usually to illustrate a particular point about the sim; the rest of the picture probably contains random junk that built up on my hard drive.
So: the marketing people will get you nice pretty screenshots that you can get excited about, but for the time being, most of the pictures here are designed to illustrate only one specific point, and are not at all meant to illustrate what the final X-Plane 10 will look like. You’re welcome to speculate all you want on the rest of the picture, but you’ll be using an X-Ray to look for a skin rash.
a·twit·ter (-twtr)adj. Being in a state of nervous excitement
Anyway, Laminar Research is now on twitter…a bit late to the party but at least we showed up and we brought some munchies so it’s all good. Please follow us and help us spread the word.
In my previous post I suggested a few ways that we will try to ease the introduction of new rendering technology in v10: complete compatibility when the feature is off, close-as-possible compatibility when it’s on, and a simple path to migrate to fully using the new tech.
But: if you’re doing something that should be illegal, we can’t help you. And this can be tricky because X-Plane 9 doesn’t always complain about illegal content.
Propsman just hit a case of this: he ran one of his old plugins on an X-Plane 10 development build* and discovered that (unlike X-Plane 9) it accidentally disabled most of X-Plane 10’s drawing.
It turns out that his plugin wasn’t quite adhering to the OpenGL guidelines for X-Plane plugins. But the particular state he was leaving altered had no visible effect on X-Plane 9. That’s not the case for X-Plane 10. So he’ll have to fix his plugin; the fixed plugin will work correctly with both X-Plane 9 and 10.
Unfortunately, it can be hard to find these kinds of problems without a build of X-Plane that actually has problems when you violate a rule. So if you make a third party add-on, when we finally do have beta builds available, I encourage you to check your add-ons for possible plugin or authoring mistakes that might actually cause problems in X-Plane 10.
*Let me nip this one in the bud before it gets out of control: Propsman is one of five authors who are working on the new art content for X-Plane 10. These five authors have development builds of X-Plane 10. No other authors have X-Plane 10. We are not giving out copies of X-Plane 10 right now. We are not loking for testers. Do not ask me for a copy of X-Plane 10. Do not ask me to test X-Plane 10 early. If you send me an email angling for early access, I am going to mark your email as spam in Thunderbird.
Two more pictures from the test package Tom sent me. These illustrate both some cool things that happen in X-Plane 10 with global lighting and the process of adopting the new features. Our strategy for the new rendering features in X-Plane 10 is 3-fold:
When the new features (shadows and global lighting) are off, scenery that works in version 9 should just work. So users always have the option to turn off the new features, use existing scenery, and get some fps back.
We try to minimize the artifacts between new features and old scenery.
We try to minimize the amount of rework necessary to be fully compatible with new features. For example, switching from ATTR_poly_os to ATTR_draped is a simple search-and-replace job.
The hangar during the day, with shadows with visible skylights, required some bug fixing in the engine, and a new attribute. Normally an object is either blended or not blended. The problem is that a blended object doesn’t let light through for the purpose of shadows. (Even with the “bug”, the hangar with shadows still looked pretty good!)
X-Plane 10 introduces a new OBJ attribute, ATTR_shadow_blend, that will make an object translucent for rendering (note the grime and dust on the windows) but fully transparent for shadows (hence the skylights let light through). The attribute works the same as ATTR_no_blend syntax wise, making the update quick.
(You don’t have to use this attribute, but without it, the sim may not be able to produce quite as nice shadows. Note that this attribute is not necessary for objects marked “glass” on an airplane – they are already handled by a separate process.)
There’s a second bug, visible in both pictures, but more visible in this second picture; the static airplane, which is from version 9, contains a ‘fake’ shadow, consisting of a single quad on the ground via ATTR_poly_os. During the day, we have a double-shadow (both the one generated by the sim and the fake one) and at night the fake shadow does not go away.
With X-Plane 10, this kind of problem (a technique that is useful in X-Plane 9 clashes with new rendering settings) can be addressed via the conditional OBJ commands. The conditional commands let you specify that certain parts of the OBJ are only to be used if the user has shadowing off (or global lighting off), for example. Thus the old shadow works for users who turn off shadows, but goes away when the sim takes care of it. The same technique can be used to have two versions of LIT textures (or even remove LIT textures) when global lighting is turned on and off.
Poor Tom…he sends me his work in progress (at my demand) so I can more easily investigate sim bugs and I turn around and post it to the developer blog.
Tom is working on the new airport scenery library. This is something that Sergio had started to work toward with version 9 (you’ll note that in version 9, a lot of the custom elements from LOWI are actually in the library), but with version 10, the goal is to have a complete set of library art assets. This will facilitate:
Casual authors creating detail at local airports without having to create their own 3-d models.
The X-Plane community to share default airport structures in an open source database, the way we already do for taxiway layouts.
The spill lighting in these pictures comes from version 10’s global illumination – there is a light source at the top of each light pole, and it casts light down onto whatever happens to be below. There are a few reasons why we think this is going to be a great feature for scenery creation:
It’s really easy to use. A light source is part of an OBJ (like light billboards now – in fact, the light source is added to an OBJ using LIGHT_PARAM or LIGHT_NAME) so adding lights is as simple as placing objects in OE or WED.
Since the lights simply throw spill, you don’t have to worry about whether the light is aimed at an object that you can then “draw” lighting onto.
The lights are fully dynamic – if yo animate the object, the light moves. If you drive your airplane under the light, the airplane is lit up.
With X-Plane 9 (or any rendering engine that can’t do global lighting) you have to “bake” lighting in order to create night effects. In other words, you have to draw the light effect onto the textures the light shines onto. With real lights, you don’t have to set up any baking or complex texturing layout, you just place the light and you’re done.
Not having to bake is good for plausibility. In real life, light shines all over the place – in the case of the fuel depot picture, the light illuminates not only the asphalt road, but also the grass nearby. When creating LIT textures, the author is forced to constrain light effects to parts of the scenery that actually have LIT textures. (We had to do this for X-Plane 9 – the lights on the highway don’t ever illuminate the ground nearby, because we can only light the LIT texture.) Global lights give you spill onto all sorts of nearby surfaces for free, without setting up a ton of complex baked textures.
(The global lights do not cast shadows – only the sun does that. The shadow below the airplane at night is a bug – more on that tomorrow.)
A third party developer recently asked me what the purpose of panel regions was, and how they were meant to be used.
Now I blogged about this before, and if you’ve read the post you are probably thinking: “Ben, were you high when you came up with panel regions?”
Sadly, the answer is no, but that doesn’t make panel regions any less weird. This post explains what happens. (Sound nerds: see the end for the moral of the story.)
One thing to note: the panel texture is expensive. Because the sim re-draws it every frame, it has to sit in VRAM all of the time – thus it puts more pressure on VRAM than regular OBJ textures (which can be paged out when not used). No matter how you do your panels (the old way, the byzantine way, or the new way), make your panel texture as small as you can – it’s worth it!
The Short Version
The short version is this:
Always use the 3-d panel.
Keep your 3-d panel as small as possible – pack it tight!
Make your 3-d panel a power of 2 in each dimension, e.g. 2048 x 1024.
Use one cockpit region in your object, that matches the size of the 3-d panel.
The long version explains how we got here.
You Might Ask Yourself, “How Did I Get Here?”
In order to understand how we ended up in this situation, remember that panel regions were invented before the 3-d panel existed, and they were invented for X-Plane 9, which runs on some fairly old video cards.
Going into X-Plane 9, we wanted to simultaneously fix a bunch of problems with using panels as textures for 3-d cockpits.
The 2-d panel supports alpha; the technology to do this was at the time expensive and hurt performance of the 3-d cockpit as a whole.
The 2-d panel contains a lot of wasted space. The texture space dedicated to the cockpit windows is not useful in a 3-d model.
The 2-d cockpit might be huge; version 9 introduced 2048 x 2048 panels. Authors have a motivation to make the 2-d panel huge to cover a large monitor.
The 2-d cockpit includes 2-d spot light and shadow effects, which are expensive to prepare for the 3-d panel texture.
The 2-d cockpit might not be a power of 2 – at the time, this meant wasted VRAM.
The panel texture was drawn in 3-d by simply drawing the 2-d panel. Thus the panel textured area of 3-d cockpits didn’t respond to real-world directional lighting.
The panel region system fixed all of these things:
A panel region is a sub-area of the panel, and it must be a power of 2. This fixes items 2, 3, and 5.
A panel region ignores alpha and ignore spot lights. This fixes items 1 and 4.
A panel region is drawn with correct additive lighting, fixing item 6.
In other words, ATTR_cockpit_region fixed everything wrong with ATTR_cockpit.
3-D Panels Make For Chaos
It’s about at this point in our story that things start to go south design-wise. At the time (near version 9 beta) the panel system was in sort of a never-never land, not really my code, not really Austin’s code, being driven by one-off requests. There was no road map.
Shortly after we got the panel region system working, we added the “3-d panel”. The 3-d panel is an entirely separate parallel panel whose only role was to be “the panel texture” for 3-d cockpits. We realized we needed this because often the 2-d cockpit is useless for 3-d texturing.
Consider the overhead panel. If you have an overhead panel in 2-d, it’s going to be drawn at a crazy perspective, to make it look sane in a forward view. But to texture a real 3-d overhead panel, you need an orthographic texture, taken straight on.
Once we had a 3-d panel, a lot of the reasons for panel regions were gone. The 3-d panel could be tightly packed, with no windows, no alpha, and it didn’t need to be enormous. In other words, the 3-d panel solved most of these problems better than panel regions did.
Had I used my brain, at this point I would have simply merged the two features together and gone home and life would have been really simple. But instead, I let the two features co-exist. This makes for four combinations – we can have the 3-d panel without panel regions (generally a poor idea) and we can have the 2-d panel with panel regions (which is arguably unnecessary). And I let the 3-d panel be as unrestricted on the 2-d panel, which was just silly.
It should also be noted that having no alpha in the panel and a power of 2 panel size aren’t as important as they used to be, and can be overcome with modern hardware. They were important for version nine though.
So the bottom line is: you still have to use a panel region to tell X-Plane to use real additive lighting, and to guarantee that you’re going to use a power of 2, no-alpha texture. But the “region”-ness (the ability to pick out parts of the panel) isn’t useful since you can now create a separate packed panel for 3-d cockpits.
Thus the recommended practice: use the 3-d panel, pack it tight, and use one region to get additive lighting.
Clean-Up?
Can anything be done to simplify and clean up the panel creation process? I’m not sure.
For the authoring environment, there are three things we can do to make life easier for panel authors:
Introduce new commands that are simpler. For example, we could set up a single OBJ command that uses the entire 3-d panel with additive lighting – this command would provide the interface that always should have been there. Of course, this would be yet another command, making the “full” system (including backward compatibility) even more confusing.
Simply change the behavior of existing commands. I am always hesitant to do this, because it has the potential to break older airplanes. But the current system does provide a number of feature combinations that make very little sense. There might be some things that we could do that could simplify the system for authors. (For example, we could use new modern correct additive lighting even for ATTR_cockpit if the 3-d panel is used, since it’s almost always the right thing to do.)
We can provide Plane-Maker “hints” to encourage people not to use the strange un-recommended paths. This would hopefully start to shape the set of airplanes to use the features we want without breaking any airplanes.
None of these options is great, but my gut feeling is that if we start with 3, we might be able to go to 2 – that is, we can start encouraging people to use the 3-d panel with one full-size cockpit region, the preferred way to use the system.
Epilogue: What Have We Learned?
If there’s a moral of the story it’s this: when it comes to features that affect how third party content is created, think twice, cut once. Once you design a bizarre interface and everyone starts using it, it’s nearly impossible to fix, and the “cost” of maintaining backward compatibility in the sim goes up for years.
This is why I have said no to any and all incremental proposals for sound features in X-Plane. There is no question we need better sound support. But I believe that the future format of sound is (1) not particularly obvious in terms of today’s sound system and (2) not likely to look anything like what we have now.
If we put in incremental sound features one at a time, every one of them will have to be heavily modified to work with future sound features. There’s no easy way to add just a little bit here, just a little bit there. In other words, it’s the panel system all over again.
When there is a mature, modern design, it is possible to add incremental features quickly and cheaply. This is the case with OBJs – we’ve been able to add new features (mostly in the form of new attributes) one at a time and it more or less just works, because the basic OBJ design is solid, and adding new attributes doesn’t radically change the system. The same thing is true for adding new properties to generic instruments.
But when a feature fundamentally changes the structure of authoring, there’s a big penalty for not getting it right the first time. The panel system continues to be a pain in the ass to maintain and confusing to use because some major features were thrown together ad hoc without a good plan. I don’t want the sound system to be like that.
I wasn’t going to post this video, but…what the heck. So first, Chris sent me a link to this video a while ago. Since Chris and I are both ATC nerds who used to work the Boston region on VATSIM a gajillion years ago, we thought it was pretty cool.
So when Robin stopped by the other day and I was showing him the in-progress ATC system (and to everyone’s surprise it didn’t just crash despite being under heavy construction that day) I made this video.
Like the other ATC video, this is taken with X-Plane 10 using version 9 airplanes and George Grimshaw’s custom KBOS v2 (I think this is the official convert that’s posted to x-plane.org).
We’ll probably make a better version of this video once the system is further along; on the day that I took the video, incoming AI traffic was disabled due to work on the code, hence you see a lot of planes leave on 22R, but no one ever lands on 27. This is life with in-development version 10; we all have our pieces of code work on and on any given day, someone else’s area might be under construction.
(BTW, we’ve moved the old video to YouTube. As much as I get secret enjoyment from forcing everyone to download a QuickTime H264 video that won’t play on some browsers, we like having YouTube provide our bandwidth for free a lot better. Click the graph to see the main website spike when we started hosting our own video.)
In a previous post I discussed some of the hang-on-start problems we were seeing on NVidia cards. Since these started relatively recently, but the sim code hadn’t changed much, we thought maybe there was a driver issue.
Since then we’ve collected a few more data points:
Some users with older cards are seeing problems starting X-Plane – there are shader-compile errors in the log file when this happens. Our shaders haven’t changed.
Some users with newer cards see rendering artifacts: typically the cloud shadows will darken some terrain triangles, but not others, which make the terrain look very weird with broken cloud cover.
Some users still see a hang on startup which is “fixed” with –no_fbos.
Now here’s the interesting thing: the shader compile errors and rendering artifacts appear to be happening with the 270.61 drivers; going to the 260.99 drivers seem to help.
So if you have NVidia hardware, there are a few data points I am looking for. Please post a comment if you meet any of the following:
If you have the 270.61 drivers and see either visual corruption, crashes or hangs, please try going back to 260.99 and post your results, including what card you have.
If you have the 270.61 drivers and a new card (GeForce 400 or 500) and you do not see corrupt cloud shadows, please post so – we need to know if the bug only affects some users.
If you have the 270.61 drivers and an old card (GeForce 7xxx or older) and you can run without crashing, please post so – we need to know if the crash bugs only affect some users.
As always, we don’t know if this is a driver bug or an X-Plane bug, and who “fixes” the bug may not be an indication of whose fault it is. We will work around the bug even if it is in the drivers, and sometimes this kind of problem is due to X-Plane doing something naughty that some but not all drivers tolerate. We won’t know if this is really a driver bug until we have a full diagnosis.
Edit: These bugs are Windows/Linux specific; Macintosh users will not see them, nor do they have driver version numbers that match the normal NVidia scheme.
A while back I described some of the new lighting features in version 10, including lighting calculations done in linear space. The very short version of this is: X-Plane 10’s lighting will be more physically realistic, and this is important when you have a lot of lights shining all over the place.
The change doesn’t affect how you author content (you still texture your models and we shine the sun on them) but it has been a source of bugs, as we find all of the different parts of the sim that use lighting equations. In the picture on the right, the landing light hasn’t been updated, and as a result, it lights up the city 2 miles away. The picture on the left has the landing light turned off.
I kind of like the right hand version, but that’s why I’m not in charge of the overall “look” of the sim.
(Will the runway lights look that “splattery”? Probably not, but I don’t know; Alex will be in charge of the final decision. That picture is zoomed in, which makes the lights look a lot bigger, but also the tuning of the runway lights for size is only partially done right now.)
A commenter asked if we were planning to use a GPGPU API in X-Plane 10 or beyond. I really can’t answer for the far future, but I can say that we aren’t planning to use GPGPU for X-Plane 10. This post will explain a little bit about what GPGPU is and why we haven’t jumped on it yet.
Every new technology adoption has an adoption cost. So the question of GPGPU isn’t just “will it help” but “is it better than the alternative uses of our time”. For example, do we spend time coding GPGPU, or do we spend time optimizing the existing code to run faster on all hardware? But this post is about GPGPU itself.
GPGPU stands for General Purpose programming on Graphics Processing Units – the Wiki article is a bit technical, but the short of it is: graphics cards have become more and more programmable, and they are highly powerful. GPGPU technologies allow you to write programs that run on the GPU other than graphics.
There are two major APIs for writing GPGPU programs: OpenCL and CUDA. OpenCL is designed to be an open standard and is heavily backed by Apple and ATI; CUDA is NVidia specific. (At least, I don’t think you can can get CUDA to run on other GPUs.) I believe that NVidia does support OpenCL with their hardware. (There is a third compute option, DirectCompute, that is part of DX11, but that is moot for X-Plane because we don’t use Windows only technologies.
If that seemed confusing as hell, well, it is. The key to understanding the alphabet soup is that there are API standards (which essentially define a language for how a program talks to hardware) and then there are actual pieces of hardware that make applications that use that language fast. For drawing, there are two APIs (OpenGL and Direct3D) and there are GPUs from 2+ companies (ATI, NVidia, and those other companies whose GPUs we make fun of) that implement the APIs with their drivers.
The situation is the same for GPGPU as for graphics: there are two APIs (CUDA and OpenCL) and there is a bunch of hardware (from ATI and NVidia) that can run some of those APIs.*
So the question then is: why don’t we use a GPGPU API like OpenCL to speed up X-Plane’s physics model? If we used OpenCL, then the physics model could run on the GPU instead of on the CPU.
There are two reasons why we don’t use OpenCL for the physics engine:
OpenCL and CUDA programs aren’t like “normal” programs. We can’t just pick up and move the flight model to OpenCL. In fact, most of what goes on in the flight model is not code that OpenCL would be particularly good at running.
For a GPGPU program to be fast, it has to be running on the GPU. That’s where the win would be: moving work from the poor CPU to the nice fast GPU. But…we’re already using the GPU – for drawing!
And this gets to the heart of the problem. The vast majority of the cost of the flight model comes from interaction with the scenery – a data structure that isn’t particularly GPU-friendly at this point. Those interactions are also not very expensive in the bigger picture of X-Plane, particularly when the AI aircraft are threaded.
The biggest chunk of CPU time is being spent drawing the scenery. So to make X-Plane faster, what we really need to do is move the graphics from the CPU to the GPU – more time spent on the GPU on less time on the CPU for each frame of drawing we run through.
And the answer for why we don’t use OpenCL or CUDA for that should be obvious: we already have OpenGL!
So to summarize: CUDA and OpenCL let you run certain kinds of mathematically intense programs on the GPU instead of the CPU. But X-Plane’s flight model isn’t that expensive for today’s computers. X-Plane spends its time drawing, so we need to move more of the rendering engine to the GPU, and we can do that using OpenGL.
* Technically, your CPU can run OpenGL via software rendering. The results look nice, but aren’t fast enough to run a program like X-Plane. Similarly, OpenCL programs can be run on the CPU too.
This was one of the original global lighting tests. I needed to see if the lights performed on a large scenery, so I used George Grimshaw’s KBOS, and installed two custom lights. The lights are intentionally primary colors (green and red) so make the blending and mixing completely clear.
effect of odd-sized instruments and resized panels on pixel clarity. The test case goes through every alignment possibility using art-work that has 1-pixel lines to show blurring.
This is a test pack of roads – the pack contains one of every kind of road. The sim is put into a debug mode that labels the road with its code. Using this, we can quickly inspect the entire road art asset pack to see if any road types are buggy. This is a very early version of the roads – one of the original mockups. (That’s why a lot of the roads are missing whole sections.)
Here’s another road test – in this case, there is a custom scenery pack that replaces the cars with colored axes, making it easy to debug the alignment of the cars relative to hills and highways.
This test object was built by propsman and exercises approximately 100 different features of the version 10 pixel shaders. In this case, each shader ‘trick’ has a piece of artwork with a clear label to show which part of the shader is where. The real art assets use the shaders in subtle ways that make them hard to debug, but in this case, if the albedo is missing (for example), it’s really obvious.
This is a piece of DSF with the beaches replaced with a beach calibration texture. The beaches are solid and have numeric markings to show which part of the texture is being applied at any given time.
-tw
t
