I fear one of the main points of my last post was perhaps lost in the excited discussion of how to cope with conflicting crowd-sourced airport submissions. The engineering principle is:
Fix real bugs, not hypothetical bugs. Solve real problems, not hypothetical problems.
By this I mean: it’s invaluable to wait until you actually have evidence of a problem before you design the solution. Without a real data point showing what the bug is, the solution might not actually fit the problem as it actually happens. In a program as complex as X-Plane, particularly when third party content is thrown in, it’s hard to predict in advance what is going to go wrong.
In the previous case (coping with conflicts) the key here is that I want to see a few conflicts before I choose a plan. I see proposals for a revision system, public logs, a registery, a voting system…any one of these ideas might be the right solution, but we don’t know yet because we don’t have two people submitting buildings.
The same principle applies to another issue that was brought up a while ago:
Won’t all of the default airports look the same since they all use the same library?
First, to be clear: we’re not trying to make the default library airports look like the real world airports, we’re not trying to duplicate custom scenery, and if people submit buildings for all 20,000 airports in X-Plane there’s no way we’re going to have 20,000 control tower libraries in the library.
But there is a valid issue: what if people heavily use the assets? Won’t we start to get a “sameness” either between two airports or within an airport as we use the library more and more?
This brings up the second half of “fix real bugs”:
Identify possible solutions, but don’t use them until necessary.
I am not worried about collisions of airport because there are a huge number of possible solutions, many of which are easy to implement and have been proven to work well in the real world in other problems. In other words, the problem of merging crowd-sourced data is a solved problem, and we can use the right existing solution when we have enough data to pick that solution.
The same thing applies to repetition in the library: we have ways of fixing repetition. I want to develop a few airports and see what looks repetitive before asking our artists to spend their time making more stuff* but we at least know how we can fix the problem when the time comes.
Options to Deal With Repetition
So what are the safety valves here? How can we deal with repetition in the library? There are a few ways:
- Every object in the library can have multiple real OBJ models for each “virtual” object. X-Plane picks randomly among the choices, so we can always add more real objects. We already do this for cars. (There are something like a dozen cars and trucks backing up one or two library entities.)
- Some of the library elements are .agp (autogen-point) files – these files are mini-scenes made up of other objects, and the objects referred to within the scene are also subject to library variation. So we can have a mini-scene where some of the decorations are constantly changing.
- The facade engine contains some fairly flexible rules for picking which segments of walls go where, so there’s a lot of potential to break up the order of facade walls.
- We can add more types of facade walls to a given facade without hurting X-Plane’s performance.
All of these changes can be put into an X-Plane update.
In summary, there are a lot of ways we can make the library more diverse and less repetitive, and as we see the library get used (and certain elements become over-used) we can add more variation to keep things looking fresh.
* For example, it wouldn’t make sense for me to ask Tom to make 50 variants of the administration building if almost no one places it in any airport. We need to see what kinds of assets get used the most and then make decisions.
A quick note on an issue that apparently came up during the X-Plane Town Hall (I have not had a chance to listen to any recording or read a transcript; Austin just pinged meo n this):
What if two people submit library buildings for the same airport?
We actually already have to cope with this since we already crowd-source taxiway layouts.
My view is: we’ll put infrastructure in place when the problem occurs; there are a lot of of ways to cope with collisions of contribution, and the problem has been solved in many cases already. So I want to wait and see what kind of collisions occur and then pick the best method (whether technological or organizational) to deal with them.
Robin already tracks who submitted data, so we have the basis to identify when there has been a change or a possible collision.
WED 1.2 is in beta now — thanks to the users who have taken the time to submit WED bugs (which go here, btw). Tyler is working on an update to the manual, and I’ll try to find some time to squash bugs.
But how do you share an airport with terminals with the rest of the X-Plane community? At the X-Plane developer’s conference, we reiterated that we want to extend our crowd-sourced airport data collection to include terminal buildings and ATC routes, as well as the pavement layouts that Robin already curates for us.
To be clear: you do not have to share your WED creation to use WED! WED can be used for custom scenery and your own private creations; submitting your work for sharing with the community is optional!
Here is our thinking on submitting airports:
- Submitted airports will in the future contain three types of data: taxiway layouts (in an apt.dat), ATC taxi route data (also in the apt.dat) and library airport building placements.
- We will not accept custom art assets! The public database of airports is meant to be location data only! Custom scenery is great, but the purpose of the public database is to populate the world, not to crowd-source the art-creation process.
- WED will have a “package for submission” export option that properly bundles everything into a single file in a format useful for Robin.
- The package for submission option will do some basic validation, to catch problems like custom objects in the library, or possibly erroneous data.
You will also still be able to say “Build Scenery Pack” to create a custom scenery pack for your own use – WED 1.2 is meant to support both the crowd-sourcing and custom scenery work-flows.
The “package for submission” work is still in progress; Robin and I will test this out privately while WED is in beta so that test submissions don’t flood the data collection process.
Posted in Tools
by
Ben Supnik |
This is why.
Let me anticipate the inevitable “why don’t you just use Google Maps” question: to the best of my understanding, tracing your airport vectors off of Google Maps imagery is an unlicensed use of their service and would result in a derived product owned by Google. That’s pretty much a deal breaker.
OSM’s use of background imagery to trace (in Potlatch) comes from specific license agreements between OSM and the image provider – in other words, the image providers are “donating” to OSM by giving them a specific license to trace without ownership issues.
Anyway, I am open to other ideas. (Except for “no, you didn’t read the license right, Google really doesn’t mind if you use their imagery for free to create your own data set”. I am not open to that! 🙂
Posted in Tools
by
Ben Supnik |
I have updated the WorldEditor page to link to the new builds of WED 1.2 beta 1. This is the first beta of WED 1.2, which we showed at the X-Plane developer’s conference in SC a week ago. A few hilites:
- Finally, a real airport import dialog box – when you import a dialog box, WED will let you pick a subset of airports to grab. So now you can open the entire apt.dat file from Robin and just pick the airport you want.
- There is now a library preview pane for objects, autogen scenes (.AGP files) and draped polygons.
- WED 1.2 supports all of the new v10 overlay editing extensions, e.g. forests as tree lines, facade wall-type control, etc.
Tyler and I are working on a 1.2 manual but it’s still chaotic enough that I think it isn’t even ready as a beta document.
Last weekend I was in Columbia, South Carolina for the second X-Plane developer’s conference – that is, the US meeting. I’ll try to write that up later, but first a quick note on WED 1.2. We had Tom Kyler on site, and his demonstration of WED 1.2 with the new lego brick objects turned out to be the surprise hit of the weekend. It’s one thing to say “we’re going to crowd-source airports” – it’s another to show the pieces in action.
WorldEditor 1.1 is released, and WED 1.2 is available as a “developer preview” – it’s that developer preview we showed at the conference. A real “beta 1” will be out shortly.
What’s a developer preview? It’s an incomplete beta. In this case we didn’t have all of the features of 1.2 in place, but I wanted to get it out there for people to poke at. Tom set up Seattle using the developer preview, so clearly it’s “usable” – albeit with a heavy dose of caution.
My plan is to get WED 1.2 beta 1 released some time this week, with every planned feature except for “submit-to-Robin”, which he and I should probably test internally a bit while we make sure that WED’s output is solid.
Note that if you are making custom scenery, there’s no reason why you can’t use WED 1.1 for now – it’s finished and stable. WED 1.2 has usability and v10 updates, but overlay editing has been available in WED 1.1 for a while.
After WED
After WED, the next scenery tools priorities will be:
- Getting ac3d and Blender 2.49 caught up for version 10 technology. For Blender 2.49, I am trying to merge my
hackingchanges with Jonathan’s, so that users of the public scripts can use my v10 mods without having to rework content. I will send these to Jonathan, and also post some of our newer scripts (e.g. autogen-editing).
- MeshTool 2.x will write v9 meshes, but a new 3.0 version will be needed to make “v10”-style DSFs; this is on my todo list.
What About That Program That Simulates Airplanes?
It’ll take a bit to get through the scenery tools because we are also mid-patch for X-Plane. 10.10 will be the next “patch” with new features. It looks like we will post a 10.06 first with some new translation files that have come back to us from a number of sources.
One complaint we hear a lot from tech support is that the 747 knobs are hard to control in the 3-d cockpit. Javier and I did some investigation into this; this post describes what we found, what we are changing, and what why I don’t think the scroll wheel probably shouldn’t be used to affect the 3-d cockpit.
Hard To Drag
The fundamental problem is that it’s hard to control the autopilot knobs in the 747 by dragging with the mouse. Large drags make only a small change in the knob, so it takes forever to dial in an autopilot altitude. You’d think the solution is simple: change the scale for dragging on the knobs, right? Well, not quite.
It turns out that the “sensitivity” of the knobs to dragging is a function of the way you turn your head in the cockpit. Sit in the default 3-d position, turn your head 30 degrees to the right and drag and the knobs turn quickly. But look straight ahead, slide to your right, and drag and they are very slow.
The problem is one of perspective, and this is where it gets interesting for authors. The drag axis manipulator (which lets you make the 3-d cockpit respond to dragging the mouse) measures its drag in meters. But the distance on the screen that the drag distance takes up (in meters) depends on where the camera is placed and at what angle it is turned. This can lead to some very strange effects: in some views, a 500 pixel drag moves the altimeter only a few hundred feet, while in other views, 500 pixels moves tens of thousands of feet.
Screen Space Dragging
For real physical parts like a lever (a part that moves as you drag it), dragging in meters makes perfect sense; it lets authors match their animations to their manipulations.
But for a drag that doesn’t have a real-world correlation (e.g. you drag on the knob and the knob spins but it doesn’t move) having the camera angle affect the drag distance results in panels that can be used only from certain viewpoints.
To fix this, we are introducing a new “pixel” drag axis – unlike the current drag axis, the distance over which the user can drag is specified in pixels, so that the “sensitivity” to the mouse is the same no matter what view angle the user has. I will post details on this when we go beta.
The Mouse Wheel
While I was working on pixel drag axis, I looked at using the mouse wheel to turn knobs, something our users asked for. And while the prototype seemed ‘clever’, after some arguments with Chris I came to a bit of an inescapable conclusion: the mouse wheel for changing parts of the panel is the wrong tool for the job.
The problem with the wheel is that in the rest of the universe it is use to manipulate view information. This is true in X-Plane 10.05 as well (and it works well), but things get quite tricky once the mouse wheel is added in. Some of the problems:
- Making the mouse wheel zoom and manipulate (e.g. if you are over a knob it manipulates the knob, otherwise it zooms) risks surprising results. A user who wants to zoom might accidentally “bump” a cockpit knob, something that’s pretty frightening to a real pilot.
- We looked at requiring once of the buttons to be held down while mouse-wheeling, but that’s not a gesture you see anywhere else in the universe – effectively one of the two uses of the wheel is “buried” and we might as well only use the other. Furthermore, if we are going to require a click, the user might as well just drag on the knob itself.
- If we have to pick one or the other (zoom or manipulate), zoom is by far the most consistent thing, the thing that fits with the host OS.
- If we make the option a preference (e.g optional mouse-wheel on knobs) so few users will enable it that authors won’t be consistent in adding support to their cockpits, and the system will never get momentum. (We can’t just add “mouse wheel automatically” because the sim doesn’t know how much one click of the wheel should change a given dataref.)
We tossed the mouse wheel idea around, but in the end we concluded that the wheel should be a view/zoom/scroll function, not a data change function – we couldn’t find any example apps that used the wheel to change the contents of the screen. In the end, authors need to make clicking work well, and we need to provide manipulators (like the screen-space drag manipulator) to make that possible.
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
Plane-Maker Will Copy Your Instruments
You may know that in Plane-Maker, you make your own copies of X-Plane’s PNG files to customize the look of the instruments. But did you know that Plane-Maker will copy the images for you?
Select an instrument and type Control-P (which is the default for the command binding “pln/panel/copy_instrument_png”). Plane-Maker will copy all PNGs for that instrument into your aircraft’s cockpit or cockpit_3d folder. This can save you the time spent wading through X-Plane’s cockpit folder to find the right PNG files.
X-Plane Can Make a Panel Image for UV-Mapping
When you are making a 3-d cockpit, you use the 3-d panel as a texture. But how do you know how to UV-map this texture in your cockpit? Often the panel background (panel.png) is blank.
X-Plane can make a snapshot of your panel for you, in the exact size you need to UV map. Use Control-Alt-Shift-Space (Command-Option-Shift-Space for Mac nerds) to run the “sim/operation/make_panel_previews” command in X-Plane. It will make a PNG file in your aircraft called Panel_preview.png – it’s just like Panel.png but with the instruments drawn in – perfect for UV mapping.
Plane-Maker Will Tell You What’s Wrong
That sad face icon in top bar of the Plane-Maker panel editor enables “warning” mode. In warning mode, every instrument that has a potential problem gets a red outline. Select one instrument with a red outline and in the upper left corner of the panel you’ll see a description of what’s wrong.
This picture on the left is from Plane-Maker editing a 3-d panel. (That’s why it is just a “packed” set of instruments with no background; this panel is used as a texture for a 3-d cockpit – each instrument is UV-mapped into the right location.)
The air-speed indicator has been flagged as having a problem, and the text shows it. In this case, the lit texture has an alpha channel, which causes the lit texture to draw incorrectly. Fix the texture and the warning will go away.
I strongly recommend checking all Plane-Maker “red boxes” on your plane – most of the warnings will tell you about problems that would otherwise be very hard to detect.
I finally finished up an update to the OBJ8 specification, as well as the forest specification – see here for the documents. These specifications are mostly of interest only to developers who are working on scenery exporters.
The OBJ specification is very thick – here are some of the hilights of what’s new.
Global Lighting
In X-Plane 10, you create global spill lights by attaching a light to an object. (Thus, spill can come from any object-bearing part of the sim – an airplane, custom scenery, etc.)
One way to do this is with the existing named and parameterized lights – these features existed in version 9, but in version 10 there are some spill lights added to the light list.
What may be of more interest to custom authors is the new LIGHT_SPILL_CUSTOM command. This lets you build a completely customized spill light. You control its size, color, shape and direction. You can even optionally run the light through a dataref, giving a plugin custom control of the light.
Draping
In X-Plane 10, an object can contain geometry that is “draped” on the ground – that is, X-plane will subdivide, bend and modify part of your object mesh so it sits perfectly on the ground even if the ground is sloped. ATTR_draped makes this happen.
This feature is a much better alternative to using ATTR_poly_os to make marks on the ground. Draping produces objects with better performance, and the geometry always sits on the ground with no artifacts.
As an added bonus, you can optionally use a second, different texture for the draped part of your object from your regular object. (Internally the draped geometry actually becomes something like a .pol file – this is why it can have its own texture.)
Draped geometry makes it much easier to make airport markings. If you want a parking spot, simply draw it on a quad, make it draped, and drop it into place with WED. Tom uses this heavily in our airport library.
Draped geometry also makes it easier to have ground markings that match the object they come with. For example, if you want a house and the house comes with a driveway texture, you can make the driveway texture a draped quad and when you place the object, the draped driveway is always in the right place.
Global Attributes and Instancing
In X-Plane 10, it is possible to set a few key attributes (blending and shininess, among others) globally for the entire OBJ, rather than using an ATTR_ to change part of the object.
These global attributes make hardware instancing possible. In hardware instancing, X-Plane draws many objects with a single instruction to the CPU. In order for this to happen, X-Plane must be able to draw the entire object without needing CPU intervention mid-object. This means an instanced object has to be free of animation, attributes, and a few other features.
The global attributes let you set things like shininess and still have a single-call draw object, ready for instancing. Alex uses these heavily in the urban autogen, and it really helps performance.
My fear is that global attributes are going to be a source of confusion for authors. When should you use them? How do you add them? This is my thinking:
- Modeling program exporters should allow an author to identify an object as “for instancing” or not.
- Authors should check “for instancing” for any object that is heavily repeated. (A car or a single tree or a static airplane, for example.)
- The modeling program can then try to prefer global attributes for instancing objects but not for regular ones, which should come very close to optimal behavior.
Conditionals
Conditionals are simple logic statements that include or ignore parts of an art file based on the rendering settings. In particular, they let you change an OBJ based on whether HDR is on or shadows are on. For example:
IF GLOBAL_LIGHTING
TEXTURE_LIT my_airplane_hdr_LIT.png
ELSE
TEXTURE_LIT my_airplane_LIT.png
ENDIF
In this example, which LIT texture the OBJ uses will depend on HDR.
Because the conditionals can be used anywhere in the OBJ, you can change any aspect of the OBJ to customize for HDR. You can replace a texture, remove lights, add more geometry, etc.
I don’t know how heavily people will use conditionals, but they give authors the option to make one file tuned for both HDR and non-HDR, shadows and non-shadows.
I think the two most common uses of conditionals will be:
- Providing alternative LIT textures when HDR is on or off. Note that only one texture is ever loaded (when the HDR rendering setting is changed, X-Plane unloads one and reloads the other) so this does not increase VRAM.
- Removing drop shadows that are baked into a model when shadows are on.
That second case would look like:
IF NOT GLOBAL_SHADOWS
ATTR_draped
# This is the shadow geometry
TRIS 300 6
ATTR_no_draped
ENDIF
When global shadowing is turned on, the entire set of draped geometry disappears, removing baked vs. real shaodw conflicts.
Among other things, I am working on more file format documentation for X-Plane 10. Most of the tools you need for scenery are right there in X-Plane 10.0r1, because our art team needed them.
But there is one feature that slid by: a global shadow disable for an object or art asset. I am adding this directive (it will be called “NO_SHADOW”) to a bunch of places in the scenery system. Typical use would be to completely exclude geometry from shadowing, which will also improve performance (less work for X-Plane to do). The directive will be available in 10.05.
There is one exception: you can disable shadowing in an airplane by disabling the “shadow” check box in 10.04, and “glass” tagged objects from v9 planes are not shadowed.
