Tools Archives - Page 12 of 17

Deep In the Goo

No posts for two weeks…sorry, I’ve been head’s down with next-gen tech. It’s a little bit too early to blog about this stuff.

I was able to fix a few MeshTool bugs, but I have more problem reports, so I might be able to do a MeshTool beta 3 in a few days if things go smoothly.

940 is final – there might be a 941 maintenance release – we’ll know in a few weeks.

Posted in Development, Tools by Ben Supnik | 2 Comments

This feature is not in the WED developer preview (because I just coded it) but: WED 1.1 will feature “click-to-split” for edges. With WED 1.1 you can option-click the edge of a polygon or line feature (but not a must-be-straight entity like a runway) to insert and drag a split point.

This will hopefully be a lot easier than the current, convoluted, WED 1.0 technique of selecting the two surrounding vertices and picking “split”, then repositioning the vertex.

Hackers: this features is not yet checked into the tree, so … building from source won’t help you. It’ll be available some time in the next week.

Posted in Development, Tools by Ben Supnik | 4 Comments

A Developer Preview

I realize as I write this that I am going to get some comments mocking the fact that X-Plane 940 is on RC, um…13. I don’t decide the milestones for X-Plane, nor do I decide the version numbers. If you want to discuss why X-Plane is 940 (and not 930 or 950) and why it goes beta and RC when it does, email Austin. What follows is all about the scenery tools, not X-Plane.

With that out of the way: I have released a WorldEditor 1.1 developer preview. So I wanted to explain in a little bit more detail what the difference is between a developer preview and a beta. Here is an approximation of the standard definitions of “milestones” – they are what I use for WED.

Development: not all features are coded, no guarantees about bugs.
Alpha: all features are coded, no bug is so severe that you can’t at least try a feature. (For example, if WED crashed on startup, it would not be alpha, because you could not test saving files.)
Beta: all requirements of alpha, also no bugs that cause program crash or data loss.
Release: no open bugs.

This all applies to known bugs. Beta software may crash and cause data loss – it’s just that we wouldn’t have put it out as beta knowing that this happened.

WED 1.1 is still in phase (1) – development, and the build I posted is a developer preview – a cut of whatever code I had laying around. So: I can’t promise it isn’t going to trash your data or crash! Be even more cautious with the developer preview than you would with a normal beta. You don’t want to run a five hour session without saving your work, and you want to be backing up your work often – the “save” command might trash your entire project.

Why do a developer preview if it’s still so buggy? Some users who know how to compile WED from its source code are already using WED 1.1 and they seem to be enjoying it. So far it appears not to be lethally broken. Given that and the fact that most of the uncoded WED 1.1 features are usability and edge-cases, it seemed like the developer preview could be useful for getting earlier feedback.

One last note: the manual is not updated at all, nor is there any documentation on the new features. Let me be clear: no tech support or help is provided what-so-ever. Do not email me, or X-Plane tech support with “how do I use WED 1.1” questions. If you cannot figure out how to use WED 1.1 on your own, don’t use the developer preview.

Posted in Development, Tools by Ben Supnik | Comments Off

Marking the Ground? Use a .pol or .lin.

The rule is very simple: if you want to put a marking on the ground, your results will be much better if you use a .pol (draped polygon) or .lin (draped line) than if you use an OBJ. In fact, an OBJ is probably the worst way to put markings on the ground.

Requirements for Good Looking Markings

In order for markings to look good you need to have three things happen:

You need to make sure your markings are at the exact same level as the ground itself.
You need to use polygon offset to tell X-Plane to tell the video card that these are “coplanar” (at the same height) triangles that must be managed in a special way.
You must guarantee that the draw order is: the stuff under your markings, your markings, then the 3-d buildings and other 3-d stuff.

With these requirements we can compare .pol/.lin files to OBJs:

.pol and .lin files always “drape” to the ground, so they always meet rule 1 perfectly. With an OBJ you can set the height of your OBJ to 0 but on sloped terrain this won’t be correct.
.lin and .pol files are always “polygon offset” automatically, so they always meet rule 2 perfectly. With an OBJ you need to use ATTR_poly_os.
ATTR_layer_group (or LAYER_GROUP) tell the OBJ or pol/lin in what order to draw, so you can set this correctly in all cases. The default values if you don’t specify a layer group are more appropriate to the task of markings on the ground when you use a pol/lin – that is, by default they meet rule 3 perfectly. By comparison, an OBJ may not be in the right draw order.

So we can see from these 3 rules that you will always get the rules right just by using a pol or lin, but you have to be very careful and may still not get the rules right when using an OBJ.

Performance? Think .pol

When you have a large number of small markings, the performance of a .pol is going to be significantly superior to the performance of an OBJ. For example, imagine an airport where you want to draw on-pavement signs for all taxiways and runways. With an OBJ, to get the height right, you’d need to use a large number of small objects. (With one large object, it will be nearly impossible to make the OBJ markings be on the ground when far from the object center.)

When you use a large number of .pol markings that share one common texture and all have the same .pol file, X-Plane merges them behind the scene into one huge object-like pile of triangles. The cost of drawing all of those polygons will be similar to the cost of drawing just one object! That’s a huge speed win.

Floating Objects Are Wrong

What I see most commonly in scenery packs that are sent to me and have thrashing problems are OBJs that have a height other than 0. This is simply the wrong way to create overlaid geometry in X-Plane, and it will produce artifacts in a wide variety of situations. At best, the “floating” objects will cause airplanes driving over the marking to look like they “sink in”. At worst, the offset you pick will be too small for the video card’s resolution and you’ll get thrash anyway.

There is no one right vertical offset for all scenarios, and even if there was, it would still look ugly! See the above rules for what an OBJ really has to do.

How Do I Get a .pol into my scenery.

Well that is the $10,000 question. I must admit that I don’t know what Overlay Editor’s capabilities are in this regard. WED 1.1 will be able to add draped polygons, including texture coordinate editing of the polygons. I’ve been working on the texture coordinate editor in WED this weekend and am hoping to get some kind of WED 1.1 preview built this week.

With WED 1.1 the process is fairly simple:

Create your texture.
Create a single .pol text file that names the texture, so you can use it.
In WED 1.1 you can select the .pol from the list of resources for your scenery pack, and then use the “polygon create tool” to simply draw the draped polygons into place.
Once the draped polygons are created, you can select the polygon and open the “texture coordinate editor” tab to edit the way the texture is applied to the polygon.

My hope is that this process will be easier than creating markings using a 3-d editor – you can still edit the texture coordinates, but you can do so directly in WED.

Posted in Development, Modeling, Scenery, Tools by Ben Supnik | 3 Comments

Scenery Tools Bug Base

I have set up a public bug database for the scenery tools. The reason is that I don’t have much continuous time to work on the scenery tools – it’s very stop and go and will be for a while. The bug base lets you create a permanent record of a problem that I can’t lose track of in the heat of whatever is on fire today.

WED is almost ready for a beta, but I am just completely swamped with work right now…for WED 1.0 I worked full time on fixing WED bugs for a significant time when WED went beta; this time around I won’t have that kind of time – at least not this year.

So…we’ll see how the bug base works out. My hope is that I can post WED, put it down, and pick up work on it intermittently with the bug base providing a record of what remains to be done.

Regarding other tools, there will be at least one more MeshTool beta with an improved shapefile processing algorithm that will handle broken shapefiles better. The ac3d plugin has some bugs filed against it but it’s possible that they’d be deferred past the 3.2 plugin.

Posted in Development, Tools by Ben Supnik | Comments Off

ATTR_light_level Changed!

I have said this before, but now it’s finally true: new file specifications are subject to change in the middle of beta!

In particular ATTR_light_level has changed slightly from beta 7 to beta 8. If you are using this feature in your objects, you will need to update your objects.

A new ac3d beta will be posted later today that supports the updated syntax.

You can read about the syntax here.

Posted in Cockpits, File Formats, Modeling, News, Scenery, Tools by Ben Supnik | Comments Off

So How Big of a Mesh Can You Build?

I get asked about the maximum mesh density in X-Plane a lot.

First, I must note that X-Plane’s mesh is adaptive – the triangles are not arranged in a grid, but rather they’re arranged to maximize the quality of the mesh with minimal triangle count, while preserving the outlines of water bodies and airports. These pictures show a dynamic mesh fit to a section of the grand canyon (both with and without the shaded DEM for reference):

Second, the actual maximum mesh density is almost certainly limited by system resource constraints. The maximum spatial resolution in a DSF is about 0.6 millionths of a foot. You’re going to exceed the maximum number of vertices, or much more likely, the maximum amount of available memory in X-Plane long before you have a grid at that resolution.

(That doesn’t meant that resolution isn’t usable – remember, the idea of the adaptive mesh is to have very high densities in very improtant places, but not everywhere.)

But in practice this is all moot if you don’t code your DSFs by hand – the question that really matters is: what is the highest density mesh that you can use with the current scenery tools.

Until recently, MeshTool was limited to a 1201×1201 (90 meter) input DEM. The input DEM is a simple grid, and the finished DEM is never higher resolution than the input. So until now, it would have been just about impossible to make a really high res mesh, even if X-Plane could handle it.

The most recent changes to MeshTool fix this – MeshTool can now handle a 10801 x 10801 (10 meter) input DEM, which X-Plane should be okay with as well.

This new version will hopefully go into beta relatively soon.

Posted in File Formats, Scenery, Tools by Ben Supnik | 4 Comments

Scenery Tools Progress? Yes.

I’ve been hacking at the scenery tools over the last few days…and I think we’re making some progress. I mention this because it can be hard to see the work getting done – there is nothing for months, then a new version of a tool. (Well, now you can watch the code change as it happens. If you don’t think this like watching paint dry, you might be a geek!) I also mention it because two of the biggest improvements aren’t my own – they’re insanely helpful user contributions.

The AC3D Plugin

Version 3.2 is now in beta. Version 3.2 catches the plugin up with all of the latest OBJ tricks, including dataref-controlled LIT levels, manipulators, hard surfaces, etc. This might be more useful for airplane modelers than scenery modelers, but I think the variable _LIT channels can be used for some interesting scenery effects too.

WorldEditor

WED 1.1 will go beta once X-Plane 930 is out of beta, and will feature (very primitive) overlay editing. It’s not a thing of beauty (yet) – the overlay editing features are leaner than the airport editing tools were. But 1.1 will allow you to edit an overlay and airport in one workspace.

I can tell you now that the area where WED 1.1 is weak is preview. But I don’t want to hold off the ability to edit overlays in WED “at all” just because it’s not as nice as it could be (and someday will be).

It should be possible to work on an overlay project in both WED and OverlayEditor – for example, you could build a taxiway layout in WED, using the overlay capabilities for custom pavement and lines, but use OverlayEditor to place 3-d objects (with a 3-d view).

MeshTool

To be blunt, MeshTool in its current form is really hard to use. Part of that is expected – MeshTool is a “back-end” tool like DSF2Text, aimed to simplify the problem of creating base a base mesh for some other program. But even as a back-end, MeshTool is difficult to use because it has bugs in its polygon processing, which often result in cryptic and hard-to-diagnose crashes when used with even relatively simple input data.

The good news is that I have my base mesh generation code running with a new polygon processing library (CGAL) – the switchover from my old buggy code to CGAL was done by Andrew and contributed back as a patch. I’ve been throwing all sorts of weird data at the polygon cutting algorithms and they are rock solid.

The mesh generation code is part of MeshTool, so the next build of MeshTool will feature these processing improvements. That’s where Janos’ extensive work on the build environment comes in – he’s basically turned the scenery code from a big pile of my mad ramblings into a sane multi-platform project. This will mean a much simpler, faster process for releasing tools, particularly on Windows and Linux.

(Previously once I got a tool working, I would have to waste a few days trying to get the code to work on Windows too, slowing the whole process down.)

I expect to recut the “scenery tool” pack (that is, MeshTool, DSF2Text, and all of those other smaller apps) some time during WED beta, after 930 goes final. If all goes well, there should be native versions of the command-line tools for Linux.

MeshTool Needs a UI

Fixing MeshTool’s polygon processing is necessary, but not at all sufficient to make it a useful tool; to be really useful, it needs a real user interface. I think there are two strong possibilities for this:

WED could develop base mesh editing. Under this scheme, you would be able to draw land use polygons in WED and create a “DEM” object for the elevation.
MeshTool could be an output option for QGIS (via some kind of plugin or script).

I don’t know which it will be yet. The advantage of WED is that an author could have all scenery elements in one place. The advantage of QGIS is that it contains advanced GIS features that I will probably never put in WED. It may be that QGIS’s UI is simply not intuitive to less advanced users – I don’t have good perspective on this.

Posted in Tools by Ben Supnik | 8 Comments

A Bit More Open Source

Thanks to Janos (“sothis” on the .org) we now have a GIT repository of the scenery tools, with public browsing of the scenery tools code.

(Non-programmers – this basically means that source code updates for the scenery tools will now be available every hour, rather than every now and then when I get around to it. The rest of this post is for programmers.)

The X-Plane tools code have always been open source, in that the LR-created code is distributed under the MIT/X11 license (which basically says “do whatever you want, don’t sue us”). The public repository makes the process of getting the code a lot simpler:

The master code is actually in CVS, but this public GIT repository is updated from CVS once an hour, so this code is very close to the latest we have.
The full version history, tags, and other information that might be useful to a programmer are all present.
The web interface supports online browsing of the code, as well as downloading a “snapshot” of the entire tree (as a zip, gz, or bz2 file).

Git is, to put it mildly, a confusing tool if you don’t already use it. However, the web interface allows you to simply fetch the code from a given date. If you are a git user, git cloning is supported via http, and we are working on getting the git daemon running too. The repo is read-only; if you want to send us a patch, contact me.

(Git users will note that most of my checkin comments are really lame. This is a bad habit that comes from using CVS too much. CVS’s checkin comments are per-file, not per-group, which makes them somewhat useless to search on. Typically CVS users rely heavily on tags. The bridge from CVS to git tries to group them into a single commit, which helps reveal the actions taken on the source code.)

Posted in News, Tools by Ben Supnik | 2 Comments

Out of the Office

Starting Wednesday I will be out of the office – Lori and I are going on a 2+ week trip to India!

So first, the obvious: your comments to the blog won’t show up until I get back and can moderate them. Similarly, I will be even less on email than I am now. I am trying to dig out my tech support emails as much as possible before I go!

I will announce this before I go: I finally got an end-to-end render of a global scenery tile using CGAL 3.3.1. Andrew did the original work on this, modifying parts of the scenery generation code to handle his NZ scenery. I’ve been working on the rest of the algorithms and finished it today.

This doesn’t mean very much immediately, but it…

Will fix the instability bugs in MeshTool.
Will address missing antennas and obstacles in the global scenery.
Provides a solid basis for building scenery out of just about any kind of data.
Provides a bunch of nice tools for writing better algorithms, which means nicer looking scenery.

The next steps will probably be to create a new release of the tool set, including perhaps a bug-fixed Mesh Tool, etc.

Posted in News, Tools by Ben Supnik | Comments Off

Category: Tools