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.
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.
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.
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™.