In testing some ATC stuff today, I was curious why I saw smoke coming from the water on the left side of the runway. As I got closer, I found a KC-10 rising from the ground like a mighty Phoenix….struggling to get out of the controlling grips of Air Traffic Control. Ben said it reminds him of Free Willy.
And of course the usual disclaimer…the purpose of the video is to have a giggle at the AI plane’s bug…ignore the ugliness of the rest of the situation. The colored lines are used for debugging aircraft routing issued by ATC.
What is the limit to how precisely you can build scenery in X-Plane using WorldEditor?
In this picture, I created a runway “OBJ” exactly the same reported size of the runway, in the same location and orientation in WED. The windsocks are also placed on the exact corners of the runway in WED. This is a typical “MRI” scenery pack – that is, a test scenery package designed to show how well/poorly the sim is performing.
So what do we see?
The alignment of the windsocks with the runways is pretty damned good. It might not be perfect, but it’s awfully close.
The alignment of the OBJ runway and the real runway below it is not particularly good – the heading isn’t quite perfect enough to stay aligned over a 10,000 foot runway.
This lack of precision is a design limitation – that is, X-Plane does not try to provide unlimited precision in scenery authoring. (At some point, increasing precision increases file size and processing time, which would have a detrimental effect on overall system performance.)
In particular, X-Plane tries to provide high quality point-to-point matching. That is, given two locations that are both specified by latitude and longitude, X-Plane tries to get them to be as close together as possible.
What doesn’t work well is trying to correlate a specific location (specified by latitude and longitude) with another location specified by relative location (e.g. from this location, go 50 meters to the west).
Generally, the longer the “arm” of relative location, the worse the precision. in this example, the runway is specified by the center of the ends, and the windsock locations are specified directly. Thus the runway corner is on a 25 meter “arm” from the runway end center. We may pick up a little bit of imprecision on a 25 meter arm, but the correlation is good.
By comparison, the object end is on a 5 km “arm” because it is specified by its center location and heading, while the runway end center is specified directly. As you can see, over a 5 km arm, a fair amount of error is accumulated.
Thus we can come up with a working strategy for scenery placement:
When placement precision is important, keep objects small.
When two scenery elements must be locked together, be sure to use scenery elements that can be specified by exact location and not by a metric distance from another location.
“Looks close” in WED only means “pretty close.”
The hardest part of this work-flow is using art assets other than objects for large scale features. But (for example), a draped polygon is better both for precise positioning over a large area and for polygon offset/Z-thrash, so you probably need to use draped polygons anyway.
An author recently asked me what the relationship was between the size of PNG files on disk and the amount of VRAM X-Plane uses to store the PNG file as a texture. I actually get that question fairly frequently, and the answer isn’t totally obvious.
The first and most important point: the size of a texture on disk in an image file is not the same as its size in VRAM, so changing the file’s size on disk doesn’t save you any VRAM. (It does save you hard drive space, which might be interesting if you are building a huge orthophoto scenery, or maybe download size, which can be handy.)
The size of an image in VRAM is a function of its dimensions, the amount of color information, an whether texture compression is on. The formula is basically this:
size = 4/3 * width * height * bytes_per_pixel
The 4/3 term is due to mipmapping – we save progressively smaller versions of the texture to improve the speed and quality of texturing when your image is far away.
Bytes per pixel varies depending on whether texture compression is on:
RGB, or RGBA, no compression: 4 bytes per pixel.
RGB, compression on (or DXT1 compressed DDS files): 0.5 bytes per pixel.
RGBA, compression on (or DXT3/DXT5 compressed DDS files: 1 byte per pixel.
Alpha-only: 1 byte per pixel.
That first point might be a little bit surprising to authors: when compression is disabled, you don’t save 25% for getting rid of your alpha channel. This is because modern video cards round up the texture from 3 to 4 bytes to keep the image size a power of 2. It is still typically a win to drop the alpha channel if you’re not using it: X-Plane can fill the screen faster if it knows that there is no alpha (and thus no blending) and the RGB-only texture will be half sized when compression is on.
DDS File Size
DDS (Direct-Draw Surface) is a file format designed to mirror exactly what video card want in VRAM. As it turns out, a DDS file is a good representation of how much VRAM your image uses, because it is already in the format that the card wants – including the 4/3 term. So if you need a quick and dirty estimate of your texture’s VRAM use at extreme res, the DDS size isn’t a bad proxy. (Note that when LOAD_CENTER is in use, your texture is reduced in size most of the time.)
PNG File Size
PNG file size is unrelated to VRAM used; PNG files are internally compressed. In fact, PNG files have multiple possible internal encoding schemes; utilities like PngCrush try all of the encoding schemes to see which one reduces file size the most. The key is: none of this translates into VRAM savings. PngCrush may make your downloads faster, but it won’t make your add-ons use less VRAM.
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.)
-tw
t
