First, we’re not going to get an OBJ materials model in 930. 930 is crammed full of stuff, and I don’t want to add anything more! I am not sure when we’ll get OBJ materials, or even if this is how it will go down. But this is what I am thinking:
- Materials will be controlled on the “batch” level, that is, by using ATTRibutes. You’ll be able to change materials mid-object.
- Materials will be grouped into “material classes” – the material class will be mutually exclusive. So if we have a metal material class and a “plastic” material class, you won’t be able to combine them.
- There will be some kind of material class that corresponds to the current behavior, and all of the existing attributes will keep working; probably there will be a newer, cleaner way to state in an OBJ what you can already do now.
- You will set all material class parameters at once. This simplifies the syntax and assures that we don’t have any strange mix & match combinations.
To this last point, consider that OBJ currently has a number of strange cases where you can set attributes that don’t have any effect. For example, you can set the shininess while drawing the cockpit texture (which is unlit). Code like this has historically been buggy, partly because it’s not necessarily obvious to a human reader what the object should do.
I do not yet know how normal and gloss maps fit in. Normal maps may be useful to multiple material classes; gloss maps are somewhat material class specific (in that if a material class has no concept of gloss, the gloss map is moot). It is definitely advantageous to pack a normal map and gloss map into a single texture (a la blender).
The main point of material classes is to create the infrastructure for complex extensions to the material system in a clean way. Adding additional attributes creates an NxN problem – for each new attribute I add, I have to consider how it interacts with every other attribute. By comparison, a new material class by definition shuts all other material classes off.
I’m always a little bit nervous about posting grand new initiatives … if we don’t actually do the initiative, invariably someone comes out of the walls later to say that we “promised” a feature that we didn’t do. But road maps are important. So, bearing in mind that this is not an official announcement, and that nothing has been decided yet, here are some areas of active investigation:
- An airport art asset library. Sergio already started this process by making some aircraft OBJs and other elements (like custom pavement types) available in the libraries that ship with X-Plane. We are looking at extending this over time to include more useful elements for building airports.
- Sharing airport building placements the way we do airport layouts. Right now, airport layouts are shared in a communal database under the GPL license. An airport building database would work the same way – it would be a collection of placements of airport buildings, GPLed and redistributed with X-Plane. The idea would be to make it easy for people to add simple buildings to their local airport and share the results with everyone.
- Using OpenStreetMap (OSM) for roads. We’ve been looking at OSM for a while, but it’s too soon to announce a plan.
- Sharing obstacle data with FlightGear. We already share airport layout data with flight-gear; this would be a similar initiative. We looked at OSM for this, but FlightGear’s data needs are a lot closer to ours. This is still in discussion; the FG guys are a sharp bunch, so I think we’ll able to work something out.
One of the common threads for all of these ideas is that X-Plane community members have dug into them before we have. This is not surprising, and I think it is a good thing!
Another common thread is that these are all open data sharing initiatives. Collaborative data sharing has come a long way since we redesigned the scenery system, starting in version 8.0. My hope is that over the next several months we can make some of these ideas a reality.
But first I have to fix my 930 beta features. 🙂
As of X-Plane 9, life was simple: ATTR_cockpit and ATTR_cockpit_region caused your triangles to be textured by the panel, and they could be clicked. ATTR_no_cockpit went back to regular texture and no clicking.
Well, it turns out that secretly ATTR_cockpit was two attributes jammed into one:
- Panel texture – that is, changing the texture from the object texture to the panel texture.
- Panel clickability – that is, mouse clicks are sent to the 2-d panel and act on those instruments.
With X-Plane 920 and the manipulator commands, this “clickability” aspect is revealed as a separate attribute, e.g. ATTR_manip_none sets no clickability, and ATTR_manip_command makes a command be run when the triangle is clicked. These attributes can be applied to any kind of texture – panel texture or object texture.
So how does ATTR_cockpit work in this context? Basically you can think of ATTR_cockpit as two “hidden” attributes:
ATTR_texture_panel
ATTR_manip_panel
and similarly, ATTR_no_cockpit is likeATTR_texture_object
ATTR_manip_none
With this you can actually get any number of combinations of attributes, but the code is sometimes unexpected. In particular: if you want a manipulator other than the panel or none, you have to specify it again. Example:# set command manip
ATTR_manip_command hand sim/operation/pause Pause
TRIS 0 3
ATTR_cockpit
# we now have to reset the cmd manipulator!
ATTR_manip_command hand sim/operation/pause Pause
TRIS 3 3
ATTR_no_cockpit
# we have to reset the cmd manipulator again!
ATTR_manip_command hand sim/operation/pause Pause
TRIS 6 3
Similarly, if you want the panel manipulator, you may have to reset the cockpit!ATTR_cockpit
TRIS 0 3
# now make the mesh not clickable
ATTR_manip_none
TRIS 3 3
# Mesh clickable again
ATTR_cockpit
TRIS 6 3
The good news is: this isn’t nearly as wasteful as it seems. X-Plane’s object attribute optimizer is smart enough that it will remove the unnecessary attributes in both cases. In the first one, what you end up with is one manipulator change (to the command manipulator), and the panel texture change is done without changing manipulator state at all. In the second case, you end up with the manipulator change, but the panel texture is kept loaded the whole time.
In other words, even though the double-attributes or duplicate attrbibutes might seem to be inefficient, the optimizer will fix them for you.
One reason you might care: the cost of panel texture is one-time – that is, you pay for the size of the panel texture once per frame. But the cost of manipulatable triangles is per-triangle! So having more is bad. With ATTR_manip_none, you can use the panel texture but not have it be clickable, which can be a big performance win.
930 will handle manipulatable triangles a lot faster than 920 — but that’s still not a good reason to have all of your triangles be clickable!
This article is still
unfinished, but I am trying to put together some info on how to detect performance problems like too many clickable triangles.
The X-Plane export plugin for AC3D doesn’t handle panel textures very well. The current plugin tries to identify cases where you have used your panel background as a texture – this queues it to generate ATTR_cockpit. This scheme has a number of problems:
- The search paths for the panel background are not up-to-date. The plugin doesn’t know about the new naming conventions or the cockpit_3d folder.
- The scheme doesn’t address panel regions at all – there is some support for them but it doesn’t work well.
- Most important: panel editing is not WYSIWYG. Since you are using the panel background as your texture, you can’t actually see where all the moving parts are! Doh!
That last point is perhaps the most important one, and it is why, for the next version of the plugin, I am introducing panel previews.
Basically a panel preview is a screenshot of your panel with the instruments on it, sitting in your cockpit_3d/-PANELS- folder. AC3D will recognize and use the panel preview when possible. This will solve problems (1) and (3) – there will be only one naming convention for previews, and they will be screenshots of the panel in action, so you can texture with a preview of the instruments.
Plane-Maker 930 will contain a facility to generate panel previews; if you are using X-Plane 920, you can generate the preview manually by taking a screenshot in X-Plane.
For panel regions, we will have one preview file for each region (e.g. Panel_preview0.png, panel_preview1.png). This addresses issue 2 – usage of the region previews will invoke ATTR_cockpit_region.
Finally, I am moving the panel sub-region information from the preferences to the .ac file (hopefully) so that it will be saved with your plane.
Hopefully this will make a work-flow which is much simpler. To make a 3-d cockpit you will simply pick “generate previews” in Plane-Maker, and then start using the previews as textures.
I really like what he’s done with the new page – see it for yourself here!
When you make an airplane, you customize some of the images and sounds by simply putting a wav or png file in your aircraft package, with the same name as X-Plane’s default. This is “file name” substitution.
What is good about file name substitution is that it is very, very simple.
But file name substitution has some limitations:
- If you need to provide multiple versions of a file, there is no way to do this. You can at most replace one file with one other file.
- There is a risk of “file name collision” – so file name substitution is only appropriate when we can be sure that a folder is only used for one simple purpose.
- The file name cannot easily encode a lot of information about how the file is to be used. We use _LIT to indicate an emissive texture, but imagine trying to encode every aspect of a .ter file in a file name (all of the projection parameters, physics parameters, texture clamping and alpha managemnent, paged texture loading). You’d end up with a file name like my_tex_na_42.23E_72.32W_conc_pd_5000_4000_nw_LIT.png. You can’t tell me that that’s an easy file to work with!
The scenery system hits all three of these limitations, and it deals with them in two ways:
- Texture files are almost always referenced from a text file. The text file provides a place to put all of the important parameters about the texture.
- The library system maps art assets to virtual file paths, avoiding collisions and allowing multiple files to be mapped to one virtual path.
Cristianno wrote this awesome tutorial, which shows how the library system works.
Microsoft extended Windows XP sales yet again, more or less. But rather than rant about how the Vista user experience makes me want to tear my fingernails off or how brain-damaged it is to try to put DRM into drivers, let me instead focus on Windows as an example of the cost of contracts.
I have
ranted in the past about how the boundary between X-Plane and a third party, or the plugin system and third parties, or even two third parties, is a contract. Consider:
- The named light list forms a contract between X-Plane and objects, e.g. X-Plane guarantees that there will be a named light called “airplane_landing” and that it is a good choice for landing lights. (This implies that X-Plane won’t change what it looks like to be inappropriate for landing lights, and that third parties won’t use it for inappropriate uses, like airport apron lights.)
- XPLMGetDataf forms a contract between the plugin SDK and plugins, guaranteeing that there will be a function in the XPLM called “XPLMGetDataf” that takes a dataref and returns its value. (This implies that Sandy and I won’t rename it or change its arguments or remove it all together, and that plugins won’t pass non-datarefs in as arguments.)
- Even a paint kit forms a contract – the airplane maker is essentially saying “the tail will be mapped to the upper left of the texture, and I won’t remap my UV” and the livery maker is saying “I will put an image in the upper left corner that looks like a tail.”
By comparison, the clouds are not a contract – there is no way third parties can customize the look of the clouds, so we can change the algorithm by which we create them pretty much at will. We could switch to a volumetric approach for all clouds or even go back to 2-d without worrying about third party interaction.
Okay – that’s a lot of words about contracts…what does that have to do with Vista? Well…
The Cost of Changing the Contract
Two major aspects of why Vista has been a worse experience for users than Windows XP come directly to the need for Microsoft to change contracts.
- For years, applications have run on Windows with admin rights. This is not good – it means that any process can do serious damage to the system if hijacked – and on Windows processes get hijacked on a fairly regular basis!
- For years, audio and video drivers have run pretty much unprotected. This was good from a performance perspective, but also caused a lot of BSODs. On Windows, drivers are third party components and are quite possibly not checked by Microsoft (especially video drivers) so letting them run without protections is risky.
In both cases, the problem is that the old contract is both (1) poorly designed* and (2) being used by a lot of third parties. What choice did Microsoft have? Continue to let apps run in admin mode and hijack the whole machine any time the user picked up a virus? Or change apps to run in user mode and hope that the applications didn’t depend on this guarantee?
(At this point,
Raymond might go ballistic and point out that the Windows API doesn’t really promise admin rights and apps should not have been doing all of these naughty behaviors in the first place. I don’t know what the Win32 API declares…the difference between what a platform declares and what it does is important enough to warrant another post. Certainly with X-Plane we have to worry a lot about third parties depending on behavior that was unintentional but turned out to be useful.)
Vista has been a difficult transition because it changed a bunch of rules (that needed to be changed). In the long term, I am sure that both of these decisions are for the better — eventually applications won’t be counting on administrator rights, so we won’t have to fume about UAC (or shut it off), and a hijacked web browser won’t be nearly as dangerous.
On the video driver front, the Vista experience is pretty reasonable now – there has been a lot of improvement since Vista first came out. I expect applications and UAC to take a lot longer – video drivers get revised quite frequently; applications seem to linger around forever.
I’m Not Signing That
If we end up with a situation like this in X-Plane (the contract is used heavily by third parties and not well designed) we only have two options, and they’re both bad:
- Break the contract. Third party content stops working, users are angry, authors are angry.
- Stick with the contract and mitigate as best we can. Usually this means writing more code (slows down new features), using a less optimal implementation (lowers frame rate), etc.
This is why my first reaction to any file format extension is: “is this going to be a PITA in a year”? The benefit might be visible now, but the cost could plague us indefinitely.
What You Want, Not Where You Want It
If you would like to request a feature, tell me what you want, not where you want it implemented. I bring this up because many of the feature requests I get are very specific and describe an implementation, not a goal. (To draw an analogy, it’s as if I call a general contractor and say “dig a big hole right here” without telling him “it is for a swimming pool”.)
The reason “what not how” is so important is because many of the “how” implementations that people send me involve creating new contracts with third parties. I am going to try to design the feature with the minimum contractual obligations – that is, to do just what is intended and hopefully not much more.
But if I can’t tell what you are trying to do, I can only say “I won’t code this implementation – the cost of long term support due to contractual obligations outweighs the usefulness.” It might be that there is another way to implement the feature that would not put a long term burden on the scenery system or airplane SDK and still provide all of the benefits.
* Poorly designed? Or perhaps well designed for a previous problem – if the problem changes, the design might not be appropriate. Or perhaps not even designed at all – sometimes contracts evolve without a lot of central planning. All of these things have happened in X-Plane. In the case of Windows, I suspect it’s the previous-problem case — that is, what made sense for much smaller computers where the scope of what could be done was quite limited no longer makes sense for big modern computers that are capable of a more expensive and robust solution…just my speculation.
You might not believe this (due to the general lack of scenery system documentation) but I do spend some brain power thinking about X-Plane documentation for third parties!
Consider two approaches to documentation:
My question is: which of these approaches is more “readable” or “clear” to you as a third party? Each one (the formal website vs. the Wiki) has pros and cons, but I can’t judge “usability” of the documentation myself. Is it easier to find things on the website? On the Wiki? Comments welcome!
(I need to decide where to put future documentation, hence the question “which works better for those who read the documentation.)
It looks to me like we could afford a few landing light halos on most (but not all) hardware. This gets a bit tricky in terms of how we make this available to authors…
- We have to allow access without breaking old planes.
- There will be two distinct cases due to very different hardware.
So…I have posted an RFC on the X-Plane Wiki. Please post your thoughts on the discussion page!
One option (not really discussed in the RFC) is to do nothing at all. Basically I hit upon this during some routine refactoring of the shaders. The whole issue can be deferred indefinitely.
Why wait? Well, I don’t believe that an incremental increase in the number of landing light halos is the future. Our end goal must be some kind of truly global illumination, hopefully without a fixed lighting budget. It may not make sense to add a bunch of complexity to the aircraft SDK only to have all of those limit become unnecessary cruft a short time later.
(I think I can hear the airport designers typing “why do the airplane designers get four lights and we get none? Give us a light or two!” My answer is: because of the fixed budget problem. We can allocate a fixed budget of lights to the user’s aircraft because it is first in line – we know we either have the lights or we don’t. As soon as we start putting global lights in the scenery, we have to deal with the case where we run out of global lights. For scenery I definitely want to wait on a scheme that isn’t insanely resource limited!)
Programmers: yes – Dx10 hardware can do a hell of a lot more than 4 global lights. Heck – it can do a hell of a lot period! For example, it can do deferred rendering, or light pre-rendering. A true global lighting solution might not have anything to do with “let’s add more global lights a few at a time.”
I want to revisit the question of whether (and how) the livery system should be extended. In particular, it is my opinion that the livery system should not be extended to allow:
- Replacement of OBJs used for modeling the airplane or cockpit.
- Alternate or modified ACFs*.
- Generally, the livery system shouldn’t be used for changing the plane’s behavior – it’s just paint!
I have commented previously in three parts that the livery system is meant to make easy the integration of third party paint without (a) violating copyright, (b) requiring byzantine installation instructions or (c) requiring the painter and original author to coordinate. I have received requests from a number of very talented airplane authors, asking for the livery system to cover a whole range of new features, most of them involving configuration. I will try to explain in this post how I think should should be handled.
First, to be clear: an aircraft file is the .acf file that contains the X-Plane specific data needed to simulate the plane; the aircraft package is the folder containing that .acf file. A livery is a painting scheme for the 3-d model of the airplane, and a configuration is an instance of a plane with certain features, e.g. with or without G1000, with P&W; vs. Rolls Royce engines, etc.
Configurations of an aircraft should be created by putting more than one aircraft file
(.acf) in a single aircraft package. Because the graphic and sound resources needed for the aircraft are accessed relative to the .acf file, you can build a family of aircraft with some common aspects and some unique aspects to each plane.
Files used by an aircraft fall into three broad categories:
- Files found by a fixed formula using the .acf name, e.g. be20_paint.png. Let’s call these “file-specific”.
- Files found by a fixed formula without using the .acf name, e.g. the contents of the aircraft plugins folder. Let’s call these “package specific”.
- Files that are explicitly named in the .acf file, like airfoils and OBJs. Let’s call these “flexible” (since this naming scheme could be used in any way).
Here’s how the important files in an aircraft break down:
- The aircraft paint scheme is file specific.
- The aircraft panel background is package specific (but you can effectively have each file use a different panel background by setting the panel type differently for each plane).
- Sounds are actually either, which effectively makes them flexible. Non-generic instruments are package-specific.
- Objects, generic instruments and airfoils are flexible.
In other words, if you can live with duplicating your aircraft paint files (and I suspect that in most cases either the plane is built by objects, or the modifications in each configuration warrant paint changes anyway), then every other feature can be set to package or file specific, allowing you to build a group of aircraft around a single real-world plane.
Now if there are aspects of a multi-configuration aircraft package that don’t work right now, we can look at possible changes to the sim to make this work. But it appears to me that just about everything necessary to make multiple configurations is already available in the sim now.
As a final note, the question here (livery vs. multi-file aircraft pack for configurations) is one of file formats, and thus of data organization and contracts between authors and programmers. It is not a question of user interface. The user interface can be reshaped to make multi-aircraft packages look like liveries, or liveries look like multi-aircraft packages. But I suspect that most of the interest in extended liveries is on the file-format side.
* The one exception for liveries is the tail number — given the strange state where the tail number, as painted into the livery, is also written into the ACF, it wouldn’t be bad to be able to override this property. Some people are already doing this using plugins.
