Wednesday, April 28, 2010

What's Next for Scenery Tools

Last week I finally was able to post some scenery tools builds. This begins the beta period for WED 1.1 (WED with DSF overlay editing) and a release candidate period for the AC3D plugin and MeshTool. I expect the WED beta to take a while; as long as the program is reasonably functional in beta form (e.g. not losing data) there isn't a huge rush to package it up relative to other priorities.

WED will continue to evolve as the primary visual editor for scenery. This will include editing air traffic control data for the new ATC system and editing roads once X-Plane is ready for road overlays. (See this post for why road overlays aren't quite useful in the sim yet.)

I'm not sure what the next features for MeshTool will be - this may depend on user feedback. One thing is clear: MeshTool is not easy to use. Building a base mesh is a complex and low level process, with lots of possible pitfalls. So whatever features MeshTool develops, usability has to be a goal.

There is one more scenery tool I would like to create: a remote render farm. Right now you can make custom base meshes with MeshTool. In the future it will be possible to make edits to the source data used or global scenery (by editing OpenStreetMap itself). You can also edit the apt.dat file and submit the results to Robin.

But once you edit OSM, how do you get a new scenery pack? Using MeshTool is complex, and MeshTool is really aimed at the orthophoto crowd. Waiting 2 or 3 years for the next X-Plane release isn't a good solution.

My idea is to set up a computer to do "remote global scenery" requests. I would set the computer up to periodically pull down new data updates and recut tiles as requested, then post them publicly. This would allow users to edit the source data and then put in a tile request to get the tiles back, without ever having to know how to make scenery. The tiles would reflect all changes from all users.

Such a service wouldn't be of interest to the most advanced authors who want to create a truly original scenery pack, but for authors who want to fix specific problems, this process would be much simpler. I hear the question "how do I fix the lake behind my house" all the time; a remote render farm could be part of the answer.

9 comments:

Love the idea about a remote scenery request system. I think it could be huge, certainly lowering the threshold for authors to improve the terrain without having to do all the hard work of sourcing the data and figuring out how to tackle MeshTool. This could be a killer feature of X-Plane X in my opinion.

But will scenery authors be allowed to include the modified scenery tile along with their overlay scenery pack? Requiring a user to download additional files from another site could be a deal breaker. Very few user actually read the instructions or readme file. If you have a overlay scenery that requires the modified scenery tile to run and look right then that could be a cause for concern...

I think they would be allowed to, as long as all of the input data sources were under a reasonably open license. This is true for _most_ sources (which are either under an open license or public domain). We have a few data sources that we have to get explicit non-repeatable permission for, but we could even sub out a comparable data source until the issue can be resolved.

The proprietary parts of the scenery system (e.g. art assets) are all referenced by the library, so users don't need to copy them.

1. We will not accept ATC data before a working sim that can USE that data is available in some form (beta or shipping).

Our experience with user submitted data is that user submitted data that cannot be tested in a real app suffers from quality control.

2. In the past, tools have lagged new formats available in the sim, sometimes quite severely. In this case I think we will do a little bit better; it turns out the ATC data is complex enough that we need WED to even make mock-ups.

So there is ALREADY code in WED to edit ATC data.

I do _not_ recommend that anyone try to USE these features...the file formats aren't final yet. But having the stub code means that we'll be most of the way done when the code is finalized and the tools release should come quickly.