That take the longest to program. This may surprise non-programmers, but won’t surprise anyone who has done UI development before.
Example: in WED, there is a spreadsheet-like view (the “property” view) that shows text-based information, usually with a list of runways or taxiways in one direction and different aspects of them (name, displaced threshhold length, surface, etc.) on the other.
In WED, if you press the tab key while editing text, WED will move to the next editable field, first across, then down. Furthermore, it will scroll the view as needed so you don’t need to adjust the scrollbars while working. The result is that you can, for example, use the mouse to select all of your taxiways, and then rename every single one of them from the keyboard with the tab key without ever going back to the mouse.
It’s a small UI feature that can make a big difference in how long it takes to work on a project, and takes surprisingly long to code.
Posted in Tools
by
Ben Supnik |
Sergio and I were discussing the future of facades today. Facades are DSF polygons that are extruded into buildings by pushing up the polygon into a roof and texturing the roof and walls from a single texture using some simple formulas. The rules for facades are very simple – we originally thought them up for the purpose of creating buildings that precisely fit a city grid no matter what the block spacing.
The problem with facades is that the rules make very simple buildings – especially the roofs. So we want more powerful facades and the question becomes: how best to do this? There are two possibilities and I mention them here because they underscore what I think is the largest overarching design decision when creating a flight simulator scenery system.
1. We could make the facade builder in X-Plane smarter (write new rules).
2. We could write a stand-alone tool that converts the DSF polygons (plus a rule file) into OBJs that are then placed directly into the overlay.
This second strategy would turn the facade from a type of scenery element into a tool for making OBJs. We would be “pre-compiling” our facades.
Here are some of the considerations:
SPACE VS SPEED
Precompiling primitives is a space-vs-speed trade-off. For any given algorithm, it’s usually faster to pre-build the entities and load them from disk than to build them in the sim. But pre-building means more files on disk, meaning bigger downloads, more DVDs, etc. Building up buildings from facades inside X-Plane is actually a form of compression.
EASE OF DEVELOPMENT
This is one criteria where I think pre-compiling scenery is a clear win: it’s easier to build a stand-alone facade-to-OBJ converter than to implement it inside X-Plane. X-Plane is a relatively unfriendly place to build scenery algorithms because it’s busy being a flight sim.
STABILITY VS UPGRADABILITY
If we make OBJs out of facades using a tool, the objects will look the same even if we create a new version of the tool. This is good in that it means that custom scenery won’t change how it looks, but it is also a limitation because improvements to facade technology require rebuilding a lot of objects to take effect.
(Another aspect of this: if the objects made from the tool use a texture, that texture can’t have its shape changed even if we make new rules, because some objects will be on users machines that were built with the old rules.)
X-Plane mostly errs on the side of pre-building scenery, and this is the one area where we really take it on the chin for that decision: the inability to easily create a new composite look from changes to some parts of the scenery. (Airports that don’t cause grass to appear under them is an example of this.)
Perhaps some good questions for weighing these options are:
1. Would an author care whether the facade looks exactly the same in the future?
2. Are there enhancements coming along in this technological area that we would not want to miss out on for older scenery?
OTHER CONSIDERATIONS
Information loss: when we turn a facade into an object, the original polygon information is lost. Is it important that we ship the actual base polygons that make up buildings, or are the OBJs that represent them good enough?
Contextual Information: often we know more about a given situation when making scenery than when displaying it. Could we do better at building up a facade inside the sim (where we have context from other scenery packages), or when creating the sim (where we have a much larger dataset)?
I realize this blog post will probably just inflame a bunch of email about how the scenery tools aren’t available yet, but I’ll answer the question and take the flames, because it’s a fair criticism and scenery tools are a fair feature request.
The long term direction of scenery tools is this:
- Scenery tools will be separate from the X-Plane distribution, free, and open source. (This separation allows us to post scenery tool source without posting X-Plane source, and to use GPL code in the scenery tools.)
- A few very basic editing functions (like adding nav-aids) are integrated into the sim to allow instructors to correct nav data during a training session.
- WorldMaker therefore is no longer a scenery editor at all.
So why haven’t we killed it? We’ve been tempted to. But it will serve a long term purpose in the scenery tools ecosystem: it will be a small-footprint 3-d scenery previewer.
Because the scenery tools don’t use X-Plane code, the scenery tools will have two limits to their previewing capabilities:
- There is always the risk that with different code, the tools will preview scenery differently from X-Plane’s final render.
- Because the scenery tools don’t use X-Plane’s renderer, we basically have to rewrite viewing code in the scenery tools from scratch. That’s a lot of code, so for a while the preview in the tools will be limited.
Running X-Plane and the scenery tools at the same time isn’t a great option – since X-Plane loads a lot of scenery, and a weather model, and a plane, and then tries to run at max fps, it tends to be a bit of a pig in terms of system resources. WorldMaker will be a viewer that can reload your scenery quickly so you can have a 3-d view of what your end result will look like that will match X-Plane.
Posted in Tools
by
Ben Supnik |
This is a description of what I am planning for the anatomy of the “full scenery tools”. Until now we have only published small utilities (ObjConverter, DSF2Text, etc.). The next scenery tools release should cover a lot more, including the first versions of WED.
First of all, WorldMaker is not part of the next-gen scenery tools. WorldMaker is slowly going away, as functionality in WorldMaker is either moved directly into X-Plane for “live” use (navaid editing) or into the scenery toolset.
The new scenery tools will be a single distribution for all tools. In other words, instead of a download for each tool, you will download one archive that contains all of our tools and support files. They will live together in a single “install” folder.
The distribution will not be based on our installer – more likely they will just be a zip file. The scenery tools total size should be small enough that there is no need to do incremental installs. There is no need to put customized files in the scenery tools folder _ever_, so simply replacing it should be a non-issue.
The scenery tools will be completely separate from X-Plane itself and will have their own release schedule and versioning. The scenery tools contain no x-plane code and will also be available in source.
Some undecided issues:
- What to call the main visual editor. The working name has been “WED” (WorldEditor) but that’s so similar to WorldMaker that I fear total confusion. I am open to naming suggestions.
- Whether to make a distribution or each platform or simply put all the EXEs for all the platforms in one download. I don’t think code size will be so huge as to prevent this.
- Whether to allow the scenery tools to be installed in any folder or to require them to go in /Program Files (Windows), /Applications (Mac) or /usr/local/bin (Linux).
One more change: currently I provide a GUI version and a command-line version for some converter apps. With the new scenery tools, I will provide a command-line version for each converter (like now) and a single GUI tool that can do ANY of the conversions that ALL of the command-line tools do.
In other words, for users who want a UI, you will be able to do model->OBJ conversions, ENV->DSF Overlay conversions, OBJ->OBJ conversions, and DSF<->TXT conversions in a single application. This “swiss army knife” GUI application will be extensible and will be our “master converter”.
So the new scenery tools should include:
- Many command-line tools for low level operation.
- A swiss army knife GUI converter tool.
- A visual scenery editor (WED).
- The AC3D OBJ export plugin.
I do not know what the release date of all of this will be, and I do believe that the tools will come out in stages – that is, the first WED will not edit meshes, the AC3D exporter may not be included in the first release, etc. I don’t want to hold up the availability of useful code (like a WED that can edit apt.dat 850 airports) because other parts are missing (like an AC3D exporter version 3.0).
Please do not email me to ask about release dates; now that X-Plane 850 is final, I am working on scenery tools today. I will post more info as I have it.
Posted in Tools
by
Ben Supnik |
