X-Plane 9 will feature key-framed animation for the rotation and translation animations (but not the show-hide animations). Basically:
- You can have more than two key frames.
- Interpolation between them is linear.
- Extrapolation off the ends is linear (use two equal-value key frames to clamp).
Key frames will be available for all OBJs: scenery, cockpit and aircraft parts. I will try to post a spec soon – the implementation is very similar to the RFC I posted a while ago.
(If you read the .tcl code in the AC3D plugin, you may have guessed that this was coming.)
Trigger
Now I know somebody is going to ask me: “will this allow me to make an animation X start when event Y happens in the sim?” The answer is: no! Key frames allow you to map the relationship between an input dataref and your geometry in any way you want. But if the input dataref is not changing, the output position cannot change either.
Example: you can use key frames to make complex things happen as the gear deploys. Gear deployment is a ratio that starts at 0 and slowly changes to 1 as the gear deploys (over the cycle time as set in PlaneMaker). So you can use this to make the wheels move forward first, then down.
But you cannot use key frames in the cockpit to make the gear handle move slowly. The gear handle dataref is really a switch – it instantly changes from 0 to 1. If you set up a nice key framed animation, we will instantly jump from the animation position at 0 to the animation position at 1.
In other words, whether or not you have key frames, the timing of an animation comes from datarefs, and datarefs alone. I am not planning any extensions to the OBJ system any time soon that will let you trigger animations from events. In other words, you can’t synthesize timed sequences from an OBJ. (The purpose of OBJs is to visualize things, not model things.)
If you want to create timing data, write a plugin. If you don’t know how to code, I have seen at least one plugin that lets authors “invent” simple datarefs using a text file.
No Spare Datarefs
And while I’m going off on a tangent about authoring and datarefs, we will not be adding any “spare” datarefs. Again, datarefs should be made with plugins, and non-programmers should use a plugin that creates datarefs from text files. We will not be creating any “unused” datarefs in the sim.
Why not? Think of the integration problems. Even if we make 100, what happens if Joe uses “spare dataref 93” in the cockpit of his great 747 and Fred uses “spare dataref 93” for the windmills turning in his scenery pack? Splat.
The naming convention of datarefs start with the company or author who created it – or “sim” for X-Plane itself. This is intentional – it assures that two independent authors won’t use the same dataref name and create conflicts between add-ons!
When I posted about roads a few days ago, I didn’t realize that people had such, um, “strong” feelings about them. At risk of throwing fuel on the fire, here’s the overall state of the road system in X-Plane:
1. Architecture
For all of the problems with the road system, I think the architecture makes sense: DSFs contain directed networks of roads, graphic resources describe how to draw them as scenery, and cars are generated on that road network dynamically. I don’t see the system fundamentally changing – rather, we’ll have extensions to the rendering definitions, more advanced car behavior, and other additions within the existing framework.
(I think this is true for most v8 scenery technology – we have a lot of room to grow without a huge rewrite.)
2. Default Road Data
This is the weakest part of the road system – the data in Europe comes from horribly old sources (VMAP0) and even the US data (from TIGER) doesn’t contain accurate enough flow information to really draw a nice detailed road grid. I don’t see this getting a lot better any time soon…but I think there are three ways this could get better:
- We’ll keep improving how we process the data in the default scenery. (But to some extent, junk data going in is going to produce poor results no matter what.)
- If we can ship overlay roads in v9, users will be able to customize road data. This would be the source of the best road data possible, at least for the relatively small* area where users customize roads.
- Some one (us or a third party) could build an add-on pack that uses commercial navigation-quality roads. I do not think we will ever have this in the sim itself – the pricing of commercial data makes this impossible. (This is not about LR being cheap – this is about not losing money on every sale of X-Plane.)
3. Road Rendering
I believe that while road rendering leaves a lot to be improved right now, it is appropriate to the level of data we have. That is, we don’t have nicely rendered intersections, but with such weird intersection data in the global scenery, even nicely rendered intersections would look absurd.
Once we have better road data (via better generation, or more likely, user-modified data) we’ll incrementally provide improvements in the way roads look, probably including extensions to the .net format that defines their look.
4. Car Brains
Right now the AI for the generated traffic is very simple, and the way the cars drive is crude. But here again I think we need to crawl before we can walk – without nicely rendered intersections (from well-formed data), there’s not a lot of point in working on this.
Summary
The road system will grow incrementally, first by allowing users to insert customized data, then by providing tools to make that data, and then by improving the way the sim draws and drives on this data. It will be an incremental process, and when it comes to roads, version 9.0 will have some evolutionary steps but nothing revolutionary.
* I think in terms of the whole world (14,000 DSFs), so user-contributed data represents a small fraction of the total scenery system. On the other hand, human beings live in clustered areas, so the numerically small number of contributions we receive will have an outsized benefit by being in “important” areas.
Disclaimer: nothing you read in this blog is even remotely like a “promise” about what future X-Plane patches or releases will do. This blog contains my ramblings, not a commitment to future features.
I am looking at allowing road networks in overlay DSFs for X-Plane 9. I’m not sure if this will be possible (this is just an investigation right now). But I realize that…
- The road data in the default scenery isn’t much good. Even in the US, where we have nice data, the roads are chunky, not smoothed, contain invalid flow information, and can have lateral error of up to 200 meters (enough to cause chaos). Of course the non-US road data comes from VMAP0 and is just as good as you’d expect from digitized 1:1,000,000 maps from WWII (which is to say, they’re awful.)
- Therefore there is a lot of interest in replacing the road grid using overlays. This isn’t possible in X-Plane 8 (put a road into an overlay and I think X-Plane will crash pretty hard). If roads could be in overlays, this would let you correct them and exclude the entire underlying layer.
There’s another hitch to this…for historical reasons, the road system uses MSL heights (that is, it exists in absolute space and is pre-placed to “hug” the road grid). At the time, when all scenery load involved a giant pause and y-testing was expensive and the entire road grid was built at once, this helped performance. A number of those fundamental problems have been solved.
But if a road grid is pre-placed (and not “draped” like a .pol file or OBJ) then the roads must be built to a specific set of global scenery mesh. I’d like to see custom meshes start to emerge, and hopefully I’ll have some time in the future to work on tools to make this a lot easier.
So the feature that would go hand-in-hand with overlay roads is AGL-based road heights (that is, the roads only specify when there is a bridge and not exactly how to hug the ground). As far as I can tell from my initial investigation, this is quite a bit more complicated to implement and is probably still a while off. I think that overlay roads could be useful even in their MSL form though.
(One interesting use would be: create roads with no geometry, just car definitions, and use them to overlay routes for ground vehicles in airports.)
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.
Jonathan Harris suggested I look into .dds as an image format for X-Plane. I think he’s got a good idea.
First, what is DDS? It stands for “direct draw surface”, but as a file format, it’s basically a file whose structure is the same as the memory layout for a texture in DirectX. It’s a simple image format but it does two useful things for X-Plane (or any other 3-d application):
- It can contain compressed images using the same compression OpenGL and DirectX use (DXT compression).
- It can contain mipmaps – smaller versions of the same image.
Now before things get out of hand, using .dds files in X-Plane would not mean converting X-Plane to use DirectX!! .dds is simply an agreement about how to arrange a file. You can easily write code to load a .dds file into an OpenGL application, and that is what we would do.
There would be three fundamental benefits to using DDS files:
File size on disk (and download).
PNG is a losslessly compressed file format. This kind of compression (the internal algorithm used by PNG is the same as ZIP files) preserves the image, but the reduction in image size is a function of how “simple” the image is. Images with a lot of detail and high frequency information (rapid changes in color) do not become much smaller than the amount of VRAM they use when compressed in a PNG. A lot of the terrain textures we use (4 MB in VRAM) are still 3 to 3.5 MB on disk!
By comparison, the texture compression used by OpenGL is lossy – the image looks worse. But the image is reduced by a factor of 4 to 8, every time. So one of these images (4 MB in VRAM when uncompressed) would be 1 MB with S3TC compression (available in a DDS file). Even for very simple PNG files, you rarely see such a reduction in size, so .dds files would be smaller, meaning faster updates and downloads.
(Another thought: if a PNG file is smaller than its VRAM requirement, it means the PNG file has lots of areas with the same color. This means the PNG file is WASTING VRAM! We encourage our artists to make use of every little pixel in an image, and this means that PNG files that are well-created for X-Plane tend to get relatively little benefit from PNG’s internal compression.)
Load Time
Image load time is a significant factor in X-Plane. There are several reasons why DDS files could load a lot faster than PNG.
- The actual DDS file is smaller – less data to load and process means faster performance.
- Because the DDS file can contain smaller copies of the image, X-Plane doesn’t have to load a huge image and reduce its size using the CPU – it can just load the small version in the file.
- When compressed textures are used (and they almost always should be, see my previous blog post) it takes CPU power to compress the image, slowing down load. A DDS file containing a compressed image can be sent directly to the card!
Image Quality
Now one is a little bit tricky. First, please review my previous blog post, which argues that texture compression is the best way to maximize VRAM. A DDS file will look better than a PNG file when texture compression is on. Here’s why:
The S3TC compression formats specify an EXACT way to “uncompress” and draw a compressed image. But there are MANY possible ways to compress the image. Remember that S3TC is a lossy compression – the compressed image is only an approximation of the original.
Well, it turns out that algorithms that find the best approximation of an image using S3TC are slow. So we can’t use the highest quality compression inside X-Plane when compressing PNGs for the graphics card – it would be too slow.
But the image in a DDS file is already compressed — because someone else has compressed it when creating the scenery. When converting the scenery from PNG to DDS that author can use a very slow, very high quality compression algorithm to make the DDS files. It might take 12 hours to convert the entire package from PNG to DDS, but who cares? It’s something you do once and then everyone enjoys better looking images.
In other words, because the compression is done ahead of time for a DDS file, a higher quality algorithm can produce better approximations of the original images. Since we want to use compression anyway (to optimize our use of VRAM) this is a good thing.
When is DDS not appropriate?
Any time an image must not be compressed, DDS is inappropriate, and PNG is best. There are three basic cases in X-Plane where we avoid compression (see my previous blog entry for the real examples):
- Any time we need to preserve tiny detail accurately, like lettering and text.
- Any time the alpha channel needs to be smooth.
- Any time a texture is magnified so large that small color changes between two pixels is noticeable. (For example, compressing the color washes used for the sky make obvious artifacts.)
DDS wouldn’t replace PNG, it would augment it.
Austin and I have this debate over and over when we find a case where third party content doesn’t work right with X-Plane (but did in the past due to X-Plane’s permissiveness):
- If we code X-Plane to work around the problem, users get to enjoy the scenery, and authors will never fix the problem.
- If we code X-Plane to abort, users get grumpy, and authors fix the problem real fast.
What to do? A few versions ago I implemented the scenery warning system (the spanking system) to try to get the best of both worlds. I just discovered another problem that illustrates how this works well.
Before WED some authors made apt.dat 850 layouts by hand using a text editor, and sometimes they forgot to include a closing code on their rings and chains. I can hardly blame them, writing an apt.dat file by hand is very difficult, and I am impressed (and grateful) that they did this.
The apt.dat 850 spec is clear:
- Pavement chunks (line code 110) must comply with the following:
- Chunks MUST terminate in a segment point of type 113 or 114.
- Linear features (line code 120) must comply with the following:
- Linear features must terminate in a point of type 113, 114, 115 or 116.
- Linear features do not need to be “closed”.
- Airport boundaries (line code 130) must comply with the following:
- Boundaries MUST terminate in a segment point of type 113 or 114.
- Boundaries must be a closed loop and cannot contain holes. As with pavement chunks, the airport boundary cannot overlap itself.
So, you must have one of the closing codes at the end of a boundary, taxiway, or line. But X-Plane 860 doesn’t check this and simply assumes a “closed ring” if no code is provided. With X-Plane not telling authors, the authors never caught this mistake.
So now that I know about this (and now that X-Plane needs the end codes to be right, due to other bug fixes) it’s time for the spanking system. In future versions of X-Plane:
- Custom scenery packages with no ending code on a polygon block will automatically be adjusted to be “ring”-type on load-in, for compatibility with X-Plane 860.
- A detailed message will be printed per polygon in the log.txt file.
- A single alert box will be shown to the user saying “there is a problem with the custom scenery pack XXX”.
The idea is for the dialog box to walk a fine line between being unobtrusive enough for users and annoying enough for authors.
I’ve posted WED beta 2.
The executive summary regarding split beziers: use beta 2 and re-export your layout and you should be more or less fine. There is no need to avoid them anymore.
Also a note on the source code: I will update the source code base of WED about every two weeks during beta, or whenever anyone asks me to post latest, whichever comes first. If no one asks, this will mean the source code is slightly behind the latest binary beta, but I think we can live with that…it takes a while for me to ball up and post the source code. (Again, if you want the current source code now, you are absolutely entitled to it – send me an email and I’ll post ASAP.)
I will make sure the code is updated when WED goes final, of course I expect a new binary beta about every 3 or 4 days until we get it mostly shaken out.
A thread on X-Plane.org referenced whether program should be labeled beta. I am definitely guilty of leaving some of my old programs labeled as beta, when I should have done one more build and marked them as final. I will try to avoid doing this in the future! But WED is definitely beta material right now.
Thanks to everyone who reported bugs in beta 1 – the feedback was very high quality. The new download’s README contains the list of bug fixes.
Posted in Tools
by
Ben Supnik |
In my previous post I described a bug where, when we have a split vertex in an apt.dat layout, X-Plane would draw taxiway lights all over the place. Fortunately, there is a workaround.
Remember that a split vertex is represented as two or three colocated vertices with one or two zero-length segments connecting them. The bug is that zero-length segments cause lights and lines to go haywire.
The fix is therefore simple:
- Programs that write apt.dat files can simply set the attributes on the zero-length segment to none.
- Future versions of X-Plane (with a real bug fix) can join taxiway lines even when there is a zero-length “break” in the attributes.
This picture shows the results – a split vertex with no attributes on the zero-length segment.
The next WED beta will automatically export split vertices this way – there will be no need to patch X-Plane or change your WED layouts.
