Note: This post is a boring discussion of the state of the scenery tools. If you use MeshTool or you work on the scenery tools code – or would like to modify MeshTool’s code – read this post! If you just want to know the status of the Oculus Rift or whether we’ve changed X-Planes’ fogging model, a little bit of your soul will die if you read this post.
Last weekend I discovered that MeshTool 3.0 seemed to “just work” for OS X; when I mentioned this on the blog I received a number of “I’d like a copy” emails. When I further emailed with those authors, I found that they all wanted a Windows build.
Unfortunately the Windows build of the scenery tools was in a state of disarray. The Windows build was until recently based on running mingw and trying to make Windows look like Linux. This has a few problems:
- Windows is not Linux.
- Mingw is often a lower-tier priority (or non-priority) for the developers of the libs the scenery tools use.
- It’s not easy to get a fully functional mingw environment to begin with.
A while ago Ted moved WorldEditor to MSVC. This was a pretty big win: debugging actual problems with WED is about a billion times easier in MSVC (which has one of the best visual debuggers, um, ever) than trying to use gdb via mingw on Windows. It also sets WED up to be worked on by actual real developers; if you are a programmer and Windows is your preferred platform, MSVC is mandatory; gcc/mingw/gdb is a foreign country.
So in response to MeshTool for Windows being borked due to mingw/Windows issues, I horse-traded with Chris: I’d do a bunch of his dev tasks if he’d port MeshTool to MSVC.
Will he succeed? I don’t want to say yes until it’s a done thing, but as of yesterday he did have MeshTool running, only to discover that libtiff was missing AdobeDeflate support. But I think his efforts do look promising.
The Plan
So here’s my plan for scenery tools:
- MSVC will become the supported compiler for all scenery tools: WED, MeshTool, and the various command line tools (DSFTool, DDSTool, etc.).
- The scenery tools will come with an MSVC .sln/.proj set to support them.
- We will let mingw support die. (If you want to make mingw work, send me patches, I’ll take them! But no one involved now has the expertise to keep mingw working, and it is already significantly broken.)
- Gcc/Makefiles will be the supported platform for Linux, working on modern distros.
- X-Code 3 will remain the supported compiler on OS X until we have time to do a Yosemite upgrade. (A Yosemite upgrade is badly needed, but it’s also just a ton of work; I have not had time to even start on this.)
- “RenderFarm” (the internal DSF tool we use for global scenery) will be the only non-MSVC-ported tool.
For libraries, Mac and Linux will continue to use the “libs” archive that exists now, which is a series of tarballs and a makefile that creates a static library pack for WED/Meshtool to use. Libs is a GIT submodule.
For libraries, Windows will use a different sub-module that contains source materials and already-compiled Windows binaries for all needed libraries. Windows users will simply have to get the submodule from GIT and they can immediately compile WED. (This is already how WED on MSVC works, but we’ll form a submodule so that the main repo doesn’t get huge.)
For libraries, when we get to Yosemite, we may move OS X to a precompiled-binary strategy; we’ll have to see what the state of libraries is.
32-vs-64-bit
Right now the Linux scenery tools are compiled to the native ABI of the machine they are built on; binary builds are built on Ubuntu 12.04 LTS 64-bit, so those are 64-bit builds.
Windows is currently a 32-bit build; I believe Chris is working on both 32 and 64-bit support.
Mac build are limited to 32-bit due to the use of legacy APIs.
The long term direction of the scenery tools is 64-bit only! At some point the “next” version of the scenery tools may be 64-bit only builds, and this may happen within the X-Plane 10 version run. The scenery tools are free and not part of X-Plane itself; we don’t consider ourselves to be under any obligation to maintain 32-bit support indefinitely.
For the scenery tools, 64-bit support is a win because it allows the tools to access relatively huge source data sets. There are global DSFs that currently can only be built on Linux because they require a 64-bit RenderFarm to load all road data without crashing.
Whither Betas?
There’s some restructuring to the various projects’ we’re doing as a result of all of this; I’m going to hold off WorldEditor beta until we’re done. I’m hoping this will end in “days” – that’s all of the time Chris and I allocated for it. Therefore hopefully:
- WED 1.4 public beta 1 next week. (I think I said that last week – I forgot to schedule in time to get the flu.)
- MeshTool 3.0 public beta 1 next week too. We’ve run a private beta on Mac/Linux and confirmed that MeshTool 3.0 basically works. We’ll do a Windows build publicly.
We should also have a 10.35 release candidate Real Soon Now™.
Ben posted a few weeks ago about our quest for “One Bug Base to Rule Them All“—our goal of cleaning up the fact that we had no fewer than five bug bases running, each for different products, with no communication between them.
This situation is understandably confusing—bugs that dealt with the Airport Scenery Gateway wound up in the WED database, bugs filed against WED wound up in the X-Plane database, and so on.
I’m happy to report that we’ve taken the first steps toward unification: today, we have just one place to report issues with:
- any of the scenery tools (WED, MeshTool, the AC3D plugin, etc.),
- airports and scenery packs in the Gateway or in X-Plane, and
- the Scenery Gateway itself.
All you need to do is:
- Create a free Scenery Gateway account and log in.
- Click the “Report a Problem” link in the navigation at the top of the page.
- Use the tabs to select the type of bug you’re reporting: does it deal with an airport/scenery pack, the Gateway site, or the scenery tools?
- Fill in the reporting form with as much detail as you can, and hit Report Issue.
In the future, we’ll move to a similar system for the plugin system and X-Plane itself. At that point, we’ll have one page (probably on the main X-Plane site, rather than the Gateway) with a tab for all the things you might need to file a bug for.
First, X-Plane 10.35 beta 2 is live. If you had beta 1, X-Plane will ask to update. A few bugs that made beta 1 unmanageable are now fixed:
- No more crashes when using multiplayer.
- Joystick axis assignment UI works.
- EFIS App support is back in.
See the full release notes for more.
EFIS App networking support will remain in X-Plane for the life of v10. We thought that no one was using this option, and interestingly, none of the bug reports were from actual EFIS-App users. (If you are using EFIS app with v10, maybe drop us a line? EFIS app has been discontinued for a very long time.)
It turns out that a third party app is using EFIS App’s network output. This is sort of weird; the output is labeled for EFIS App and isn’t a published “thing. On the other hand, it’s really easy to figure out how the option works and jump on it, and that’s apparently what the developer did.* So we won’t pull it until a major version break.**
WorldEditor Soon
I think we’ll get a WorldEditor 1.4 public beta early next week; I’m just going through the last beta-stopping bugs now.
Linux Nerds: I need help with this bug. Basically we don’t have a way for me to compile a cross-distribution WED release on Ubuntu (Debian) without CURL going somewhat haywire.
If we don’t come up with anything better, my default action is going to be to compile on Ubuntu and if it doesn’t work on your distribution, you can rebuild from the open source. That’s not awesome, so if anyone has a better idea, I’m interested. (But: doing several builds on several VMs for several distros is not on the table. I can’t spend that kind of time on Linux build process.)
MeshTool Anyone?
I have a build of MeshTool that can build X-Plane 10-style DSFs (with the new terrains). If you’d like to try it, please let me know.
Edit: if you want to try an early private beta of MeshTool, please email me. My goal is to have 2 or 3 users try a private build first to make sure it more or less works; then we’ll do a public beta.
* It turns out that the EFIS App output is just the regular data output on another port. More modern options like Xavion and Foreflight really have their own proprietary protocols.
It begs the question of whether we should intentionally have a ‘handshake’ with our own app to guarantee that we don’t have to do third party compatibility on what we consider our own internal interfaces.
** There’s an easy work-around for the authors if they want their product to keep working with the next major version: go back to using X-Plane’s regular UDP data output, which is actually a published thing.
Posted in News
by
Ben Supnik |
The X-Plane scenery tools are open source; their bug database is open too, so that anyone working on the project can see the status of all bugs.
We recently merged the scenery tools bug base into the gateway bug base; in the process I audited about 70 open WED bugs, and finally closed all of the bugs where the original filer did not provide adequate materials to reproduce the bug. Typically these bugs had been sitting, waiting for user feedback for at least a year.
I’m looking at the feature request list next; it is also about 70 items long and needs some auditing. The old bug base had about a million “levels” of bug status, so it was easy to leave a bug in some partial state and ignore it forever. The new bug base does not, so I think I need to either set the feature request as something we want or kill it.
One problem: a lot of the WED feature requests aren’t feature requests at all; they are requests for changes in the underlying scenery system. E.g. if you say:
Allow WED to edit the height of the underlying terrain of the global scenery.
The only possible response is “unable”; WED cannot do this because the DSF file format cannot include this information; if you had some way to edit such data in WED, there would be no place to save it in the scenery pack that is built.
Really the request needs to be two-part:
- Allow overlay DSFs to change the underlying mesh heights of the global scenery underneath them.
- Provide an interface and exporter in WED to export the new “mesh modifier” added to the scenery in point (1).
The first change is a change to X-Plane and its file formats; the second one is to the scenery tools.
I don’t blame authors for filing the bugs against WED – as far as authors are concerned, WED is their interface to the scenery system; they want to see something new in WED, and if I do (1) and not (2), the job is not done.
But…the bug base is also my todo list, and having an item on the wrong todo list is a good way for it to get “lost”. If I look at mid-term feature requests for the scenery system in X-Plane, I will not find anything in WED.
I haven’t figured out what I am going to do with this, but one possibility is to simply move all valid feature requests on the underlying scenery system out of the WED bug base and into the X-Plane one. This will have the side effect of taking them private, but if the feature request is a legitimate one, I don’t think the original poster will need to provide more information.
This idea has been on my todo list for a while; I’m hoping to be able to squeeze it into X-Plane 10.40.*
Right now, you can place static aircraft in an X-Plane scenery pack using the library; if the aircraft come from our library, they can go into the gateway. If you use third party scenery packs for custom scenery, you can get even more aircraft types.
But this is not an ideal solution.
- If you don’t place static aircraft, airports with AI planes disabled look empty.
- If you do place static aircraft, they can conflict with real pilots on Pilot’s Edge, VATSIM, or any other online network.
- If you use the AI, X-Plane will park AI planes at the ramp starts, so you must not put ramp starts where the static planes are.
This is a clearly inflexible and non-ideal solution.
Here’s my idea for a fix: X-Plane places static aircraft at real apt.dat ramp starts dynamically based on library paths and apt.dat information.
This way:
- AI planes and static planes do not conflict.
- An airport can be “emptied out” for online flight.
- The level of static aircraft can be turned up and down based on hardware capabilities.
- We can vary the static aircraft over time and take advantage of ramp types in the apt.dat file.
My thought is to do this sooner (e.g. 10.40) so we can all be working on gateway airports that place static aircraft the new “right way” for future expansion. The longer we place static aircraft as OBJs, the more cleanup we will have to do.
* We have two release sizes: big and small. 1040 is the next ‘big’ release where crazy stuff can go and this feature is just barely complex enough that it needs a big release. Also, 1035 is already in beta so it missed that boat.
X-Plane 10.35 beta 1 is out – this is mainly a release to get hundreds of new and updated airports out into the world. There are also a number of bug fixes and some features and improvements to the sim.
- Release notes – including a list of all of the airports.
- Bug in the sim? Report it here.
- Borked airport from the X-Plane Airport Gateway? Report it…here! (You use your gateway account to report bugs with airports on the gateway – or to fix those bugs by updating the airport!)
X-Plane 10.35 beta 1 is meant to be a short, tight release to get out airports; I’d like to have the whole cycle over and done with in a week or two. We’ll do a larger longer release in the future where we put in bigger features and more code change and let it sit for a while, but this one has been kept lean.
If beta 1 turns out to be reasonably stable, I’m going to look at cutting a beta 1 of WED 1.4 next.
Posted in News
by
Ben Supnik |
Every now and then someone tries to set a taxiway in WED to “transparent”, and it pretty much never does what the author expects. Here’s a brief explanation of what’s going on.
Runways
“Transparent” is one of the many built-in surface types that runways can take on in X-Plane; more commonly you would pick asphalt, concrete, or grass. So what is a transparent runway?
The answer is: it is a runway with:
- No texture. That means you see nothing where the runway is. (This is fast by the way; we are not drawing the runway with a 100% clear texture, we actually don’t even place the polygons.)
- No physics. The runway does not change the physics from the underlying ground.
At this point a sane author is thinking: then what does a transparent runway actually do? Why have a no-op?
The answer is: user interface and lights.
- A transparent runway is still a runway; and thus X-Plane can know “hey, there is a runway 3L at KXYZ airport.” X-Plane even knows where the runway is (since the transparent runway has ends and a width) and can thus start your aircraft ont hat runway.
- A transparent runway has approach lights and all other types of runway lights. A few of the common approach light fixtures with “rabbit” strobes are incredibly annoying to build by hand (you can do it, but you basically need a plugin, a gajillion objects, and super-human patience).
So the transparent runway lets you do the graphics and physics with draped polygons and leave the hard things (user interface and lights) to us.
The primary thing to note: the physics are up to you too, and the expectation is that you’ll do the physics with the same tool you’ll use for the graphics. So if you put a draped .pol file down, you can set its surface type (with the SURFACE directive) to match the visuals of the texture you are using.
Taxiways
Taxiways follow the same logic, and thus they are really quite silly.
- Physics and graphics are up to you – the taxiway does nothing.
- There really isn’t anything else to a taxiway; it isn’t part of the UI, and you can place taxi lights directly using light/line strings in WED. You don’t actually need the taxiway polygon.
The fact that you can make a transparent taxiway in WED is actually a bug – the UI simply knows all surface types and does not have special code to say “hey, for a taxiway this is silly!”
What Transparent Taxiways Are Not
Transparent taxiways and runways are not a way to get the physics without the graphics. Instead, get the physics by putting a surface directive on your draped polygons.*
* There is one inefficiency here: if you have a huge draped orthophoto that covers a wide area, it will contain imagery that spans multiple surfaces: grass, concrete, etc.
Here is my suggestion: overlay a second polygon (with a repeating texture at very high res) with some kind of “grit” overlay. Place this only on the areas with concrete (or asphalt, depending on the kind of grit you use) and set the overlay’s surface type to match the overlay’s appearance. This way the polygons you must place for physics correctness at least add visual value too.
It’s very simple: if you want to file a scenery bug, it goes to the bug report form if it is actually a problem with X-Plane or the implementation of X-Plane’s core libraries. If the functionality actually needs to go into WED it goes into the public scenery tools code base, but if it’s a problem with the existing airport data, it goes into the X-Plane Airport Gateway bug database. Plugins have their own bug database. Simple, right?
Given the above, I can’t really be annoyed when authors, developers and users file their bugs in the wrong place. We have five bug databases running now, some public, some private, using three different bug database packages on at least three different servers, implemented in three different back-end languages.
The good news is: Tyler is creating the one bug database to end all bug databases.
Now, if you fly X-Plane and you don’t develop add-ons and you don’t create airports at the airport gateway, I won’t fault you if you don’t care at all. The rest of this post is going to be an (even more) boring discussion of bug databases. Go look at pictures on airliners.net; I won’t fault you for not finishing this post.
For the three of you still here: basically we are creating one unified bug database. The bug database is mostly private (to meet our internal development needs) with a front-end with variable access for authors to contribute. Bugs on some products will remain totally public (e.g. scenery tools), some bugs will private, and there may even be bugs where you can only see what you filed, a la Apple’s “Radar” bug filing system.
Gateway Airport Bugs
This all started when Tyler built a bug report system around the X-Plane airport gateway; it lets you use your airport gateway identity to report bugs on gateway airports. Thus a front-end to a real bug database was born. The front-end lets you have a single user log-in for both uploading airports and reporting bugs.
Scenery Tools Bugs
Tyler has now begun the next step: merging the scenery tools bug database into the new bug database. Thus the scenery tools bug database is temporarily closed to new submissions. All existing bugs will be transferred, but if you don’t have a gateway login you’ll need one to file future bugs.
The scenery tools bugs will remain fully public; the code repository is open source, so the bug base should be as well.
A small number of users have direct access to the scenery tools code repository, e.g. they contributed enough that we gave them their own set of keys. Those users will get direct bug base access as well; however, I think in the long term the front end will include all of the functionality that almost all users will need.
I’m hoping that the migration will be complete within a week or two, and be ready for WorldEditor 1.4 public beta.
Plugin Bugs
The X-plane plugin system has its own bug base; if the scenery tools bug database merge goes well, we’ll merge plugins next. The plugin bug base is a public bug base, like scenery tools, and will probably remain that way.
X-Plane Bugs
I don’t know what we are going to do with X-Plane bugs. The current bug report form does not go directly into our bug base, and I continue to say that that is a good thing: way too high of a percentage of the “bug reports” we get on X-Plane itself look like this:
Help! I just bought X-Plane 10 and it does not work; when I fly I do not see anything! Please help!
Steps to reproduce: Fly the sim!
If you have experience in software quality assurance, you can understand why I don’t want “bugs” like that piling up directly in the bug database; most of the bug reports have to get forwarded to customer support.
There is a bug in 10.32r1 Steam Edition – some kind of interaction between Steam and Gizmo causes Gizmo to crash. Since Gizmo is loaded on startup, this means users of popular add-ons like Skymaxx Pro can’t fly.
We are working on this now and I am hopeful we’ll have some kind of fix tomorrow. I’ll also post more details about the bug once we have more info. The crash affects X-Plane 10.32r1, Steam edition on OS X only, as far as we know.
In the meantime: if you get a crash on start with X-Plane 10.32r1, please file a bug. Please include your Log.txt file and any crash logs that you see go by. In particular, if a plugin is having problems only on the Steam edition (but not the Global edition of 10.32r1) or if a plugin besides Gizmo crashes, I would like to see it!
UPDATE: We have determined that the crashes are caused by Steam introducing an ABI breakage of the libstdc++ runtime when we use one of their distribution tools. We are now working with an engineer at Valve software to solve this. In the meantime, the Steam distributed X-Plane has been rolled back to 10.31.
UPDATE 2015-01-21: Thanks to quick help from Valve software, we were able to re-release X-Plane 10.32r1 on Steam today which now gets along fine with plugins again.
X-Plane 10.32 is now final – you’ll get an auto-update message when you run X-Plane.
Coming soon:
- 10.35 – we still have code to put the finishing touches on, but the plan is to release more Gateway airports in 10.35. This will not be the last gateway release (obviously 🙂 so if your airport was approved too late to make the cut, we’ll try to get the next release out soon. (Our goal is to keep gateway airports flowing rapidly so that everyone can get the full benefit of everyone else’s work easily.) I am hoping for public beta within a week.
- WED 1.4 – will include GeoJpeg2000 image support, improved orthophoto overlay creation, and importing directly from the Gateway. Again, I am hoping for public beta within week.
If you would like to know the status on the Oculus Rift, I suggest you comment on this post (even though it is off topic), any other post that is still open for editing, and every additional post we make (no matter how off topic) until Philipp posts an update; while he has not responded yet, he did assure me that he will make a statement if he gets at least 275 off-topic comments on the Rift.*
* This last paragraph is completely false, just another case of me being snarky and poorly behaved on the interwebs.
The real number is 374 posts. 😉
