I posted WorldEditor 1.2 release candidate 4 a few days ago. If you are using a WED 1.2 beta, please grab this latest release candidate. If we don’t see any show-stopper bugs in a few days we’ll call it final.
Thanks to Mathias for finding and helping squash the last few bugs; the bugs in the release candidates have all been oddball cases where clicking with multiple mouse buttons induced multiple commands at the same time; the program was usable by avoiding these cases, but in the rare case WED could crash. Release candidate 4 should fix that.
Posted in Tools
by
Ben Supnik |
WorldEditor 1.2 Release Candidate 1 is now available here. Please try it! If you have a scenery project you use, please export using WED 1.2 rc1 and report a bug immediately if the export does not work! My thanks to the testers who have helped find the bugs in the 1.2 beta run.
If we don’t find any new show-stopping bugs, WED 1.2 will go final in a week or so.
Update: There is a bug in WED 1.2r1 on Windows that stops all art assets from being found in the library. I think this is responsible for all of the bugs reported against the RC. (This was from a change I made while my PC was down that I should have checked on Windows.) RC2 will fix these bugs.
Update 2: Release Candidate 2 is now uploaded; this fixes the one underlying bug that caused a lot of reports. The bug was that art asset location from the library was broken on Windows. This caused failed previews, facades that were rings and not fences, and red question mark objects. This is fixed in RC2.
I’m not sure what will go into the next WorldEditor release, but X-Plane 10 scenery usability features are on my short list.
- The ability to create and edit X-Plane 10 road overlays.
- Better options for managing overlay orthophotos for airports. (The current “make orthophotos” command is a stop-gap.)
- Possibly the ability to create base meshes (by importing data – WED would then run MeshTool for you, so that you don’t have to write a script).
The C: drive on my Windows box died over the weekend. I mention this so that you can ask this question now (when my drive failed) and not later (when your drive fails):
What’s your plan if you have a hard drive failure? Do you back up regularly? Could you rebuild the machine from original install disks? Would the amount of time it took to restore the machine be acceptable?* If you make backups, would the data loss between what you had and the latest backup be acceptable?
The problem with hard drives is that they fail infrequently; my wife has never experienced a hard drive failure in the decade+ that she’s owned a laptop. The result is that I’ve known too many people who haven’t given the problem of hard drive failure much thought until they had already lost data. A hard drive is an electro-mechanical device…with moving parts…that spin really really fast. It’s amazing they don’t fail more. Think about backups now!
For backup these days I like 2.5″ USB drives – they’re fast enough, small, store a ton of data, and they don’t require an annoying power cable. You could use one to back up several computers.
Nag over…WED 1.2 is almost done – the remaining bugs are Windows-related and will need to wait for a replacement C: drive, which is in transit. So perhaps we’ll get an RC1 going this weekend.
Update: when the replacement drive arrived, I used Trinity Rescue Kit to boot from CD and do a drive-to-drive copy using the tool ddrescue. I do not recommend anyone ever have “I’ll rescue my drive” as a data safety plan – it’s a terrible plan. But…in my case I appear to have gotten lucky; the rescued image is bootable. This is a nice-to-have in that it saves me a few hours of reinstalling Windows + MSVC from scratch. (On the other hand, I don’t get that minty-clean feeling of reinstalling Windows from scratch with a clean registry.) So…chkdisk is running now and I should be able to kill off remaining WED bugs “real soon now.”
* For my Windows and Linux setups (two drives that are alternately used in one machine) my approach has been “rebuild it when it fails”. For Linux this has already worked well – my Linux drive died a while ago and a total rebuild from a new Ubuntu install DVD was quite fast. We’ll see this week whether putting a Windows box back together can be done in a reasonable amount of time.
Posted in Tools
by
Ben Supnik |
Two updates to the scenery tools today:
WorldEditor: WED 1.2 beta 3 is now out – see the WorldEditor page for download links. Beta 3 fixes the broken orthophoto exporter from beta 2, fixes jammed file-open dialog boxes on OS X, and has a handful of other fixes.
WorldEditor is open source, so you can see the exact changes made here.
I am hoping that WED 1.2 beta 3 will be totally stable and usable; the remaining open bugs are mostly UI quirks. If we find more work-stopping WED bugs, I’ll try to cut a new beta once a week until they’re fixed; after that WED can sit for a few weeks, then go final.
MeshTool: MeshTool 2.1 is released. This is an incremental update to MeshTool 2.0 with bug fixes and a new “contour” option that lets you use a shapefile to force specific contour lines into your DSF. See the README for details, and the MeshTool page for download.
I have done some work on MeshTool 3.0 but it’s not ready for beta yet.
Posted in Tools
by
Ben Supnik |
WorldEditor’s “Make Draped Polygons” feature is a stop-gap and a hack, and someday it will be replaced with something better.
I mention this as I debug it because there are feature requests in the bug base to enhance its operation; I think I will replace it with a more fundamentally useful (and less awkward) interface before adding more functionality.
“Make draped polygons” was born out of a hack to WED to allow Sergio to finish his LOWI custom scenery pack before WED 1.1 was even public beta. In other words, it was a crude attempt to get draping into WED before the real UI work was done.
I am resisting the urge to nuke the feature now because there isn’t something to replace it yet. But in the long term, what WED needs is better tools to work with imagery and manage the text files that are needed to create ground imagery around an airport.
This new UI will be after the 1.2 release; for now the goal is to get 1.2 stabilized and finalized.
Posted in Tools
by
Ben Supnik |
WorldEditor 1.2 beta 2 is now available for download here. First, a few notes about WED betas:
- WED 1.2 is in beta – be sure to back up your work, as it has been known to crash.
- The scenery tools are open source – you can view the WED source code here.
- The scenery tools have their own public bug base. So please report all WED bugs here.
Please be careful to report X-Plane bugs to the X-Plane bug reporter page and WED bugs to the scenery tools bug base. Moving bugs to the right place just burns time that could be spent fixing bugs.
What’s New?
Pretty much all of the changes from beta 1 are in the area of exporting scenery.
WorldEditor now has the concept of an export target – the version of X-Plane you want to export. It currently knows about four possible targets:
- X-Plane 9.70 (that is, the final version of X-Plane 9)
- X-Plane 10.00 (that is, any version of X-Plane 10 back to the earliest)
- X-Plane 10.21 (that is, the current latest version of X-Plane 10)
- Robin’s database
Changing the export target can change how export works to optimize for that version of X-Plane; it also programs the “Validate” command to detect possible problems specific to that version. Examples:
- If you set the export target to X-Plane 9.70 and export a DSF overlay with forests in “line” mode, validate will catch the error – line-based forests are new to X-Plane 10.
- If you set the export target to “Global Airport Database” and use your own custom OBJs, validate will catch the error – for sending data to Robin you must use our library objects.
“Export for Global Airports” is now available on the File menu – this exports a single zip file that you can send to Robin. The zip file contains an apt.dat and one .txt file per airport with the DSF overlay data.
The exporter itself has been heavily rewritten (view the git logs to see what a blood bath it was) – this should hopefully fix all crash-on-export bugs, particularly on Windows.
So the hope is that this beta will (1) let people send their airports to Robin and (2) let custom scenery authors work without crashes on export.
Posted in Tools
by
Ben Supnik |
Tom asked a good question in the comment section of a previous post: what is the difference between DSF mesh formats for v9 and v10. Here’s the story:
Mesh: In X-Plane 8 and 9, the terrain mesh is stored as a set of triangles in 3 dimensions; each corner of the triangle has a latitude, longitude, and altitude. The shape of the mesh comes from the location of those triangles and the heights of each corner.
Mesh + DEM: X-Plane 10 can also handle a new extended DSF with raster (array) data. In this mode, the mesh contains triangles (just like it did) but they contain only latitude and longitude. The elevation for the entire DSF tile is stored in a 2-dimensional array of elevations (a raster DEM). When X-Plane 10 loads this format, it reads the height for each triangle out of the array of elevations to “rebuild” the 3-d triangles at load time.
X-Plane 9 supports only the original “mesh” DSFs.
X-Plane 10 supports both the original mesh DSFs and the new Mesh + DEM DSFs.
Therefore, old scenery from v9 loads fine in v10. But you cannot load the new v10 global scenery in v9.*
Why Did You Guys Do This?
Moving elevation data out of the triangles and into a separate raster layer actually makes the DSF smaller.** That’s a nice-to-have, but that’s not why we did it.
DirectX 11 class graphics cards can enhance meshes on the fly, on the GPU via tessellation. We wanted to shift the DSF elevation mesh toward raster data so that we would have the full source raster to feed into the GPU. In this configuration, we can make a low resolution mesh, give the graphics card the full data and say “go to town.”
If the graphics card can ‘enhance’ the mesh quality, this solves a problem we have now: there is no rendering setting for mesh complexity. Right now everyone uses the same meshes, so we have to limit mesh detail to meet the specs of low-end supported computers. With GPU-enhanced terrain, users with more powerful systems can crank up the detail.
We’re not ready to code this yet, but one first step was modifying the DSF format to be ready for tessellation. We did this with the X-Plane 10.0 global scenery, and a nice side effect was smaller DSFs.
What About MeshTool?
MeshTool 2.0 writes DSFs with the classic “mesh” format, and it uses the v9 global terrain definitions to fill in land classes where there are no custom orthophotos.
MeshTool 3.0 will write DSFs with the new mesh+DEM format, and it will use the new v10 terrain definitions.
Therefore, MeshTool 2.0 will make v9 scenery (that can be loaded in v10) and MeshTool 3.0 will make v10-only scenery.
* There are also a million other v10 0nly features that the global scenery requires that v9 does not support. Besides not supporting Mesh + DEM, v9 doesn’t support the new terrain shaders, the new draped road system, or the new autogen!
** The space savings come from two places: first, we don’t need to save terrain normals. Instead we calculate them since we have the full DEM. Second, we use 7-zip compression, and it actually gets better compression ratios on less heavily encoded data. So the raw raster DEM compresses better than the highly encoded triangulation mesh. The triangle mesh encoding format was designed a long time ago for classic pk-zip, not 7-zip.
Here’s a quick round-up on the state of scenery tools, as of 10.21 release candidates…
WED: WorldEditor 1.2 beta 2 is “in the can” and should be posted tonight. I’ll post more about the changes for beta 2 in another post, but beta 2 should fix any major beta bugs that were stopping people from getting work done, and opens up the path to submit airport buildings to Robin for collection in the global database.
MeshTool: I have a few bug fixes for MeshTool 2.0 and will cut a MeshTool 2.1 patch probably in the next week. If you use MeshTool 2.0 and woud like to test the patches now, let me know. The MeshTool 2.x builds will build v9-style DSFs, compatible with X-Plane 9 or 10.
I now have a prototype of MeshTool 3.0, which will produce X-Plane 10-style DSFs (E.g. with X-Plane 10 landclasses/terrain, and the X-Plane 10 DEM-in-DSF style storage). I am working on the XES files authors will need.
Note that having a prototype is a long way from having a stable beta; in particular, X-Plane 10’s new DEM system has never been tested with really huge DEMs – there could be significant bugs before MeshTool 3.x is ready to go.
The script format for MeshTool 2.1 and 3.x are the same, so you can easily create a MeshTool project and cut your scenery twice, once targeting X-Plane 9 and once targeting X-Plane 10.
Blender 2.49: I uploaded my patches to Jonathan’s scripts to GitHub – that “v10scenery” branch actually works for airplanes too and contains:
- Jonathan’s original work and
- Ben Russell’s manipulator exporter and
- Ondrej’s manipulator exporter for 2.49 and
- All of my modifications to support new v10 attributes and other stuff.
The idea is to have a unified Blender 2.49 script that is totally v10 ready and can directly export older projects.
Blender 2.6x: I also submitted a patch or two to Ondrej’s Blender 2.6x scripts, found here. I think that with their current status and those bug fixes, they should be totally usable for aircraft development.
A comment about Blender: I know that some of you have tried to use Blender 2.49 and were absolutely horrified. I have heard plenty of authors absolutely refuse to touch Blender 2.49, and I do not blame you at all.*
Blender 2.6 is different. The UI is completely redone and it is significantly less astonishingly weird. I was able to install Ondrej’s scripts, build an object, animate it, add lights, and export it using the user manual only to install the scripts; everything else I was able to do with a few good guesses about how the program might work. That’s a huge step forward from Blender 2.49 in terms of usability.
So I think Blender 2.6 with X-Plane export has the potential to be a really good intermediate modeling program for authors. It has all of the power tools you need in a 3-d editor (solid UV unwrapping, visual key-frame animation, non-destructive editing), and if you really become an expert, the hard core features are there (e.g. render baking), so you won’t have to change editors later.
The X-Plane integration is really clean too. Unlike Blender 2.49, Blender 2.6 allows plugin scripts to augment the core user interface, which is exactly what Ondrej has done. The result is that custom X-Plane properties are visible directly in the main UI with your editing properties. This makes full editing of X-Plane features straightforward.
So I believe that my next scenery-tools step (besides running out the betas for WED and MeshTool) will be to submit a few more patches for the Blender 2.6 scripts, to bring in direct support for some of the v10 scenery features. I think these changes should be straightforward, as it’s basically “more attributes, more check boxes”.
(I think the 2.6 scripts are not yet ready for major intensive X-Plane 10 scenery development – we need to get a few key v10 attributes in to allow authors to get maximum performance from their scenery packs. These attributes are not important for airplanes.)
* When I first started using Blender 2.49 to support our internal team, I basically had to have Propsman on the phone for a few hours going “click this box, now hit the space bar” and me going “what?!! seriously?! what the @#$@# did that button do!??!” In other words, Blender 2.49 is totally usable…as long as you have an experienced modeler to use it for you!
(I will say this though: once you overcome the Blender 2.49 learning curve, which takes about six months (!) the actual key strokes to use it are super-fast and efficient, which is why I think very experienced 2.49 modelers tend to look at 2.6 and go “who cares”?)
Posted in Tools
by
Ben Supnik |
Why the nerdy recursive acronym for WED? Sometimes the data just stares you in the face.
I spent an hour today doing inventory on the build-up of WED bugs. That’s a screenshot of one of my bug screeners for the public scenery tools bug base – open bugs in WED 1.2b1 sorted by severity. Notice a trend? 100% of the crash bugs come from the import/export module. In fact, export bugs dominate the crash+major category too.
At this point I believe the DSF overlay export code simply needs a rewrite. The current code converts the polygons from my code to CGAL, then attempts to chop them up to fit into DSFs, and then converts them back and exports them. To put it mildly, this code is not working well.
As far as I can tell, CGAL 3.9 (the version we use) has reliability problems on Windows when processing Bezier curves. I don’t know if it’s a build environment issue, something I did, or their bug, but I don’t trust the code path; we don’t use CGAL’s bezier curve processing for the global scenery project, so we don’t have strong data that this code will ever work.
Why Do We Need to Cut?
The current WED export code chops up your polygons to fit them into the DSF tile boundaries, because everything in the DSF must be contained within the DSF, right?
Well…
There’s actually nothing in the DSF file format to disallow ‘overhang’, e.g. a facade or some other shape that is partly in the DSF. And for custom airports, having to cut buildings down the middle at lat/lon boundaries is unfortunate – the results can look ugly.
Unfortunately, as of this writing, X-Plane 10 requires the DSF to not “spill over” its boundaries. But it looks like this could be fixed.
Multiple Export Fixes
This is my plan for fixing WED export, more or less:
- WED will provide a “target” X-Plane version, e.g. 9.00, 10.00, 10.30, etc. This will select what kind of export features it can use. If you try to export a project using a feature that cannot be supported (e.g. custom facade walls to a v9 airport) you will get a warning or error, depending on the nature of the problem.
- WED export will not attempt to cut overlay data on-the-fly; rather it will either export the geometry spilling over the border (if allowed by export target version) or flag the span as an error.
- An edit menu tool will be provided to cut geometry at DSF borders, for at least some DSF geometry types.
Why make border cutting a manual step? I think that it will be more useful for authors to see the result of the border cut. For example, when a facade is border cut and has unique wall choices, the author has no control about the wall type of the wall that was introduced to span the DSF border. With pre-cutting you can slice your facade, then pick a ‘safe’ wall type for the two walls that face each other at the DSF border.*
WED will currently refuse to border-cut some geometry; I think this will continue in 1.2, albeit this will happen in the “cut at borders” command – if you request to cut a bezier type WED may refuse.
* No matter which way you slice it, cutting facades at the DSF border sucks. This is why I think the long term solution is to allow facades to span borders, at least a little bit.
I had a chance to work this week on the Blender 2.49 scripts; here’s a quick update on the status of the scripts and what the next steps are.
Blender 2.49 for Internal Scenery Development
Relatively early in X-Plane 10 development, we picked Blender 2.49 for our scenery development environment. We did this for a few reasons:
- The two artists doing scenery (Alex for cities, Tom for airports) both used Blender 2.49 as their primary 3-d tool.
- There was already a completely functional OBJ exporter (Jonathan’s XPlane2Blender scripts, version 3.09) that produced highly optimized OBJ output.
At the time, some developers were already migrating to Blender 2.5, but Ondrej’s exporter was only partly written. Since we didn’t need any Blender 2.5 features and schedule time was of primary importance, we decided to stick with 2.49 (to avoid the delay of our artists learning a new environment and the delay of having to wait for or develop for ourselves a complete and fully optimized exporter).
The result is that I augmented Jonathan’s scripts to:
- Fully support X-Plane 10 OBJ extensions like instancing, the new GLOBAL attributes and draped geometry.
- Export some of the other v10 data types (autogen, facades, roads). Exporting non-OBJ stuff is really complicated, and the rules to use Blender to make the right meta data are not trivial.
Other Scripts
There are other variants of the scripts floating around: both Ondrej and Ben Russell added partial manipulator export to the 3.09 scripts to help aircraft authors. Ondrej has also created a new branch (the “3.20” scripts) that target Blender 2.50 and newer.
There’s one technical point tot note about Blender that might not be obvious: for all practical purposes. Blender 2.4x and Blender 2.5x might as well be completely different programs! They have totally different scripting interfaces and they don’t even use compatible versions of the Python language. Supporting Blender 2.5x is a from-scratch effort and the scripts are totally unrelated to anything you can use on Blender 2.49.
There is no way to use my Blender 2.49 scripts on Blender 2.5; this is just a decision that the Blender developers made – they created a major fork in the Blender world. So when you read about Blender 2.49 vs Blender 2.50, consider that difference to be as major as Blender vs AC3D or Blender vs 3DS.
Recent Work
This week I had time to integrate both Ben and Ondrej’s manipulator export code into my 2.49 scripts, and I also added the remaining missing OBJ8 commands that are useful for aircraft developers. This means that my scripts are now more or less ready for aircraft use as well as scenery use, and they provide a forward path for Blender 2.49 users who use either Jonathan, Ondrej, or Ben’s scripts. This brings me closer to my goal: making a complete set of 2.49 scripts, current to X-Plane 10.
I have a few more loose ends to tie up, but I am hoping to get the scripts pushed to github for Jonathan (and anyone else who wants them) in the next week. There is still a lot of documentation to add.
