Thursday, July 10, 2008

The Future of WED

WED 1.0 has gone RC. The onLinkly change from beta 5 is that I have the latest manual changes from Tom (including Cormac's illustrations of taxiway signs). Both of them did some great work - the WED manual is a lot nicer than the docs I have done myself for the other tools.

A while ago I posted a tools update...has anything changed? Not a whole lot.
  • WED is definitely the future of the "heavy" scenery tools (ones with extensive UI) - it has a lot of infrastructure for features like multiple undo, multiple selection, hiearchial editing, etc.
  • The next big feature for WED will be some kind of overlay editing. I don't think this will happen very soon though - my todo list is pretty out of control.
  • In the long term, I think WED may provide a visual way to do MeshTool-like operations. In other words, you'll be able to build a base mesh in WED by specifying polygons for airports, applying orthophotos, and importing one big DEM per tile.
  • I don't think that WED will ever be a DSF editor - that is, you won't be able to open an existing DSF, move a single node, and re-save it. This just isn't high on my priority list.
To this last point, how are you supposed to fix scenery if you can't edit DSFs? Well, I'll try to post more on that over the next few weeks, but the short answer is that we need structured edits to source data.

A DSF is a compiled result of a very complex set of processes. The vertex that you adjust in the mesh to fix a mountain top may not exist in the DSF if another user submits an updated airport layout, even if they are fifty kilometers apart. (All parts of the DSF affect each other through the adaptive irregular mesh.) So I don't want to take user submitted corrections to the final DSF because those changes would be lost at the next render.

We've been down this road before - when the V6 global scenery was done, the plan was: now we'll take user-edited ENVs. The problem was that this plan assumed that we'd never re-render the ENVs again, which proved totally wrong - we re-rendered them at the end of the v6 run with improved algorithms.

What we need to do is identify what components of the source data are reasonable candidates for user editing, and set up processes (similar to Robin's collection of apt.dat data) to gather data and share it.

(We are looking at OSM - it is still under investigation!)

7 comments:

Alejandro Garcia said...

About something like apt.dat way of updating data, I have a question: Would there be some kind of "trusted people"? Because we have a problem in apt.dat, you do your work, accurate and updated but someone else can redo your work just destroying it, and that's annoying.

Would be great if (some time after the release of this future tool) is there any kind of trusted fellow partners who keeps an eye on some parts of the world (maybe each one his country)before the changes are official.

Just a thougth

Anonymous said...

"how are you supposed to fix scenery if you can't edit DSFs? "
Yes how could we edit sceney ? This is a long time now that a lot af people are waiting for a World Maker wich work with DSF.

Unknown said...

I personally fixed a number of gross landform errors using DSF tools and doing some painful hand editing on text form. Why/how work on an airport layout far away would invalidate this? I can understand a very near airport may do so due to flattening. I think you need to explain this a little more.

BTW, you should give some priority to fix the flattening algorithm so it will not mess up the shorelines, create water cliffs etc. Water should be flat and horizontal in all cases.

What is OSM?

Anonymous said...

OSM = www.openstreetmap.org

And it would be great if we could use their data to create the DSF's. If OSM continues improving their data at the current rate we will quickly reach a level that can never be matched by scenery makers in the X-Plane community. In some places OSM is already used in free roadplanning software.

I would like a small patch system that would enable us to do detail area's on top of the DSF (for things like Courchevel and Mont Saint-Michel).

Anonymous said...

Ben, I don't believe that it is a not very high-priority topic the possibility to edit the wireframe of a DSF. In countries that we don't have complete, correct and of high definition information, the only way to solve the problems is to editing the DSF.
You can create land "Overlay" but in those areas there will always be water or nonexistent mountains that disable to use the option "Runways follow the contour of the land."
Regrettably, I am not a programmer, but I don't believe that it is very difficult to create a program that it shows us the wireframe in 3D and it allows us to add triangles or edit their points and heights.
I could achieve it in form manual, for some triangles. But to edit an entire area of false lakes or coast is quite difficult.
On the other hand I want to know as making him arrive some suggestions for the future versions of WED.
Thank you for your excellent work and many people with the appropriate tools will be a great army working for it X-Plane. Instead of some few ones making everything.

Benjamin Supnik said...

"In countries that we don't have complete, correct and of high definition information, the only way to solve the problems is to editing the DSF."

This is not true. Given a broken DSF I can think of at least THREE ways to fix it:

1. Edit the DSF data directly.
2. Edit the source data and rebuild the DSF.
3. Edit the source data and let somebody else rebuild the DSF.

My issue continues to be this: since we rebuild the DSFs with every major release of X-Plane, any "fixes" to the DSF (and not to the source of the DSF) are guaranteed to be lost. It's a losing battle.

Let's say you move a vertex...is this because you want to:
- adjust the effective elevation.
- fix a coastline
- change an airport boundary
- change the texturing

There's no way to know, and any one of these could conflict with the source generator (the DEM, the coastline file, future apt.dat edits, and improvements in the default textures).

So I recommend (2) or (3)!

Unknown said...

Ben, you recommend to edit source data (options 2,3 in your list).

But that data is not available to us users is it? If it is, where is it, and where is the spec to work with it?

Alternatively, a user who goes thru the trouble of correcting base DSF could send in the modified DSF, or may be even a diff between before and after states of DSF text files, and attach an explanation of purpose.

Can this change, then, be incorporated in the source data by Laminar?

Jollive, PM me at .org, and I can point you to a solution to fix bad water bodies, without having to edit base DSF. At least you will not see them.