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™.
But what about Tessellation support for POLs so we can use the Occulus Rift in 128 bit mode and do non-linear fog to the expanded DSF rendering load with the DX11 wrapper and Ambient Occlusion in 16xMSAA with multithread rendering for Intel GMA Graphics?
Oh no….. My soul.
A dreams comes true! Last three strings like a glass of water in the desert.Thanks Ben.
I’m just starting with WED as I want to improve the scenery for my local airport. In your post from January you mentioned “there are several big ones” (features) to come. One problem I currently have with the editor is that I cannot rotate polygons (the “rotate” option only rotates the polygon’s texture by 90°) in WED 1.3. Why would I want to? AFAIK there’s no other way to paint gate numbers etc. on the ground but to use polygons textured with the characters from, for example, OpenSceneryX. I can’t draw rectangles directly but it’s not a big problem to create one by aligning 4 vertices of a polygon “by eye”. I thought I could just duplicate & align, scale and rotate them – however rotation is currently not possible unless I manually move vertices around which doesn’t look well when done “by eye”. 🙁
Not sure if I’m just missing something here but it would be great if it was possible to rotate polygons (or rectangles) freely. As you explained in your previous posts normally this would be a lossy operation due to an accumulation of rounding errors – unless you keep the original geometry and then apply the rotation angle just before rendering which I’m quite sure is the reason it isn’t already possible. There already is a “heading” field when creating polygons but I couldn’t figure out what it does yet. Also, that field doesn’t seem to be available once the polygon has been closed. Unless this is just a “newbie problem” I really hope that’s one of the big new features to come in 1.4 (if there was a list of changes, I missed it somehow).
@ EnQ,
This is not a support area, so you may want to go actually read the manual and even read/watch some tutorials. Rotating polys works just fine.
Here is the excerpt from the manual.
—————————–
Transforming and Rotating Shapes
After having created a shape, you can manipulate it: you can stretch it, scale it, or rotate it. To do so, use the marquee tool and select the entity. When you do so, a bounding box appears around the entity. By clicking and dragging one of the box’s nodes, you can stretch the shape. By holding down the Alt key, you can cause the bounding box’s nodes to become rotation nodes; by clicking and dragging a node, you can rotate the shape.
Sounds like a good solid plan. I run XP on windows 8.1 and OS X and could include Linux if really need be (I’d have to reinstall in a VM), so I am happy to run betas on either platform.
I has been back to WED1.2r3 from WED1.3r1. New WED 1.3r1 unlearned to do a draped polygon unlike WED1.2r3. So, in this point I have one question, will can make the draped polygons by WED1.4?
I’m not sure exactly what you mean by the loss of “do a draped polygon”, but if something _broke_ in WED 1.3 and you haven’t already, please _file a bug_.
http://gateway.x-plane.com/bugs/view
I mean that WED 1.3 have no item called ‘Make draped polygons’ in Edit menu unlike WED 1.2. I think it’s not a bug, because the latest WED Manual does not have this item too.
Right – “Make draped polygons” was replaced with “Import Orthophoto”.
Basically in the old system there was a one-off command to turn overlay images to polygons – this was a big hack to let Sergio make the LOWI demo area in v9.0.
In WED 1.3 and later, orthophotos are supported natively:
– The draped orthophoto primitive in WED can (optionally) reference a SOURCE image as its resource.
– When it does, WED will write a .pol file and convert the image to DDS format as part of the export.
This lets you bring in orthophotos without having to hand-create and hand-edit .pol files.