Request Orbiter 2016 Surface Tile import/export tool.

[Loru]

As mentioned here I'm asking fellow developers to provide community with tool that'd extract height and texture data for particular tile and covert it to msh format along with saving texture in temporary direction, and after editing of those files in 3rd party software properly incorporating them back into orbiter folder structure.

1. Advantages

- improving base developement time
- flattening only parts of base that need to be flatten (runways, launchpads etc)
- adding terrain features that can't be incorporated via heightmap and seamlessly merging them with scenery (vertices at the base of terrain feature match exactly to orbiter's terrain)

eg:

2. Feature list. - more detailed descrition later in the post

- GUI
- area selection - selcet tiles to extract
- subdivision tool - to locally increase terrain resolution (simple interpolation might do the job.
- export to external apps - basically it'll save msh (subdivided or not terrain file in msh format along with texture in dds or png format
- basic terrain + height points display
- selection files to import back to orbiter
- import function (either via putting it back to archive or just placing them with correct names and paths to local orbiter installation).
- generating txt or log file with list of files being imorted back to orbiter (so user can pack it as an add-on).

3. Selected feature description

- area selection - user should be able to enter base origin point and highlight tiles (left clisck) he wants to extract. Good idea would be to display current texture in this place (grabbed from orbiter), along with grid so user can choose which tiles he needs for this base visually instead of comparing it to google maps or something.

- subdivision tool - prior to export to external files user should be able to subdivide heightmap and texture. That can be done by simple drop down menu item with values like 2x, 4x etc.

- export to external apps - with this user should be able to export files to working directory (specified by user). Function should create msh file (it's text format and it's already compatibile with orbiter so let's keep it consistent) with height vertices being base of a plane.

Important: resulting mesh file should be 1:1 scale consistent with orbiter units.

File should be UVW mapped so user can edit both texture and msh file

example of exported file:

- basic terrain + height points display - - top down projection on texture with height points (few pixel wide) shaded dependent on height.


- import function - either via putting it back to archive or just placing them with correct names and paths to local orbiter installation. I'm inclining to second option as incorporating multiple bases in the same area might break archive or result in missing files for one base after overwiting tiles with another one.


Feel free to PM me if you need clarification on some points. Unfotunatelly my coding skills can be summed up with this awesome program

10 print "Loru can't code"
20 goto 10

So I cannot help you with coding side, however if you need GUI elements (icons, arrows, points etc) or help with testing I'm all eager to participate.

 

[fort]

Hello Loru,

I'm not sure to understand, but is all the meaning of this, oriented as: a new base made of a mesh with a texture on it ? Not something merged with *.tree files or at least, Surf, Elev, Mask files...in the cache ?

 

[SolarLiner]

I think it would be better as an import/export tool for an existing 3D program (i.e: Blender), because you don't have to reinvent the butter knife (to badly translate a french saying) and you'll be presented with an already fully featured 3D environment to work with - and the only GUI to code will be the options for the importer and exporter.

 

[Face]

I think it would be better as an import/export tool for an existing 3D program (i.e: Blender), because you don't have to reinvent the butter knife (to badly translate a french saying) and you'll be presented with an already fully featured 3D environment to work with - and the only GUI to code will be the options for the importer and exporter.

But how would you do the selection mentioned?

 

[DaveS]

But how would you do the selection mentioned?

Maybe through GUI similar to the current Tile Edit. Tile Edit isn't really bad, it's just that it was whipped up in hurry and is unoptimized and relies on a 826 MB runtime file. If something like [ame="http://www.orbithangar.com/searchid.php?ID=5607"]Orbiter Base Maker V2.0.3[/ame] could be done but that natively implements the 2016 terrain/tile details as well as the runway lights extensions offered by D3D9Client, that would be a great base making utility.

 

[Face]

Maybe through GUI similar to the current Tile Edit. Tile Edit isn't really bad, it's just that it was whipped up in hurry and is unoptimized and relies on a 826 MB runtime file. If something like Orbiter Base Maker V2.0.3 could be done but that natively implements the 2016 terrain/tile details as well as the runway lights extensions offered by D3D9Client, that would be a great base making utility.

I meant my question more in relation with the idea of having it implemented as modeling software importer/exporter. I think Loru's outline needs the selection as important part of the workflow, and starting with a modeling software would perhaps make that part harder to implement.

 

[DaveS]

I meant my question more in relation with the idea of having it implemented as modeling software importer/exporter. I think Loru's outline needs the selection as important part of the workflow, and starting with a modeling software would perhaps make that part harder to implement.

That's why I used [ame="http://www.orbithangar.com/searchid.php?ID=5607"]Orbiter Base Maker V2.0.3[/ame] as an example. It doesn't rely on any outside programs and it has a really good interface. On the surface it wouldn't be much different than Tile Edit, relying on a top-down perspective. Elevation view would be pretty as it is now, color coded. Introducing a third-party program would just mess up the work-flow. What I'm thinking is that you would be able to switch between "Surface view" and "Elevation/Terrain view" for proper editing of elements.

 

[Face]

That's why I used Orbiter Base Maker V2.0.3 as an example. It doesn't rely on any outside programs and it has a really good interface. On the surface it wouldn't be much different than Tile Edit, relying on a top-down perspective. Elevation view would be pretty as it is now, color coded. Introducing a third-party program would just mess up the work-flow. What I'm thinking is that you would be able to switch between "Surface view" and "Elevation/Terrain view" for proper editing of elements.

I'm a bit confused now. OBM looks like a 2D program, while Loru talked about a 3D mesh to be used in a full-blown modeling program. I also thought that a 2D presentation might be more approachable, though.

EDIT: A bit more explanation:

It seems to me like there are 2 ideas:

#1 Modeling tool chain:

• Use the proposed tool to select tiles and export to MSH.
• Edit MSH to your liking with modeling tool.
• Use proposed tool to import MSH into texture tree.
• Operation is 3D based.

#2 Base editing tool:

• Use the tool to view, edit and save 2016 bases.
• No other program (besides Orbiter of course) involved.
• Operation is 2D based.

 

[Loru]

Face:
What I need from this tool is to grab height from orbiter terrain files and produce 3d grid with vertices coresponding to height nodes in orbiter native terrain file.

In GUI there is no need for any 3d (display wise) as msh would be edited in 3d modelling program. (virtually it's first your #1 Modeling tool chain)


SolarLiner:
I've chosen msh format because it's well understood within orbiter community, it's relativelly simple and text based, and there are tools to export/import it to various 3d modellers. Other way we'll spend next year arguing for each favourite format.

 

[jangofett287]

As I understand it, the elevation is stored as what is basically a heightmap, so representing the datapoints as vertices would be a bit misleading, because the vert's would only be free to move in the up/down direction.

 

[Loru]

As I understand it, the elevation is stored as what is basically a heightmap, so representing the datapoints as vertices would be a bit misleading, because the vert's would only be free to move in the up/down direction.

As I outlined in 1st post, the reason converting it into 3d file in 1:1 scale and retaining UVW mapping is to allow base designer match terrain to 3d object he's placing in base and match 3d objects to perfectly fit terrain( all in 3d modeller).

Yes - editing terrain in 3d modeller will be limited to up/down movement but that's not a problem IMO.

Sure - limited editing capability of the tool itself like defining terrain points' heights could be usefull and shading them could help visualize height.

 

[Andronicus]

Long-time forum lurker here... this thread drew me out of hiding to finally register and make my first post. :tiphat: I've wanted a tool to edit terrains since I started playing around with the beta several months back.

It seems to me like there are 2 ideas:

#1 Modeling tool chain:

• Use the proposed tool to select tiles and export to MSH.
• Edit MSH to your liking with modeling tool.
• Use proposed tool to import MSH into texture tree.
• Operation is 3D based.

#2 Base editing tool:

• Use the tool to view, edit and save 2016 bases.
• No other program (besides Orbiter of course) involved.
• Operation is 2D based.

Myself, I'd prefer to do the dirty work of editing/creating terrain in a 3D environment like Blender, and if I had to pick just one option I'd choose #1. I recognize however that there are a lot of simple edits that might be easier done in a more basic tool -- like flattening selected vertices under a runway, for example. And that might be more comfortable for users who aren't 3D savvy who just want to tweak a base a little.

IMHO the perfect tool would:

• Select tiles (with or without bases)
• Create/edit bases on those tiles
• Perform simple terrain edits (raise/lower/set the height of vertices)
• Export a 3D mesh of the selected tiles for users to edit in a modeling program
• Import a 3D mesh and save as a terrain file at a user-defined resolution

Alternatively, it could export/import 2D greyscale heightmap files for detailed editing. There are some pretty nice 2D terrain editors out there. I'm familiar with Wilbur, just stumbled across l3dt. This method might be better for turning maps of Earth or other body terrain into Orbiter terrain (easier to find those in 2D form). It may also be easier to create lower-resolution versions of edited terrain this way - just combine, scale down, and import the edited images.

3D export/import might be best for editing tiles near the poles though, where lat-lon scale gets freaky. So maybe both? :hmm:

 

[Loru]

Alternatively, it could export/import 2D greyscale heightmap files for detailed editing. There are some pretty nice 2D terrain editors out there. I'm familiar with Wilbur, just stumbled across l3dt. This method might be better for turning maps of Earth or other body terrain into Orbiter terrain (easier to find those in 2D form). It may also be easier to create lower-resolution versions of edited terrain this way - just combine, scale down, and import the edited images.

Basically any decent 3d modelling program has heightmap to mesh conversion. Advantage to use it in 3d modeller is that you have much more precision than by playing with greyscale heightmaps.

But that's only my humble opinion.

 

[jedidia]

I don't quite get how you would go about re-integrating the mesh... It would be converted back to a heightmap when you re-integrate it into the archive, so where's the advantage? Or do you mean to use the generated terrain as a base mesh? That would mean that the terrain would not be landable...

 

[Loru]

I'll give you proper explanation tomorrow. Got few things to do at the office.

 

[DaveS]

I don't quite get how you would go about re-integrating the mesh... It would be converted back to a heightmap when you re-integrate it into the archive, so where's the advantage? Or do you mean to use the generated terrain as a base mesh? That would mean that the terrain would not be landable...

I think it's just as a guide to properly align custom meshes, not something that would be editable.

 

[Andronicus]

Basically any decent 3d modelling program has heightmap to mesh conversion. Advantage to use it in 3d modeller is that you have much more precision than by playing with greyscale heightmaps.

But that's only my humble opinion.

Totally agree, especially when it comes to matching terrain to base objects as you mentioned before. Heightmaps would just be a useful intermediate option between simple tweaking in the base editor and full-on 3D manipulation. But I'd prefer to have mesh import/export before heightmaps, if it's a question of priorities.

---------- Post added at 11:45 PM ---------- Previous post was at 10:32 PM ----------

I think it's just as a guide to properly align custom meshes, not something that would be editable.

As I see it, you'd want to be able to edit and re-integrate it into the texture stack. Say you're putting a runway on a base and need to flatten hills or add landfill to make it work.

Technically you could do that in the proposed base editor or as a 2d heightmap that you then import, but it's easier on the modeler if you can make everything in one place, then save the terrain and custom meshes to their respective files for Orbiter.

 

[Face]

Technically you could do that in the proposed base editor or as a 2d heightmap that you then import, but it's easier on the modeler if you can make everything in one place, then save the terrain and custom meshes to their respective files for Orbiter.

Easier for those who know their way around modeling software. I'm not sure if the usual base designer fits into that category.

 

[Andronicus]

Easier for those who know their way around modeling software. I'm not sure if the usual base designer fits into that category.

True, and a good point. I suppose that's why I said "modeler"

I guess the simplest view is, power users (like Loru and myself) would like to have mesh export/import. The "usual base designer" might not need or want that... simple vertex height editing in a based editor might be plenty, or 2D heightmap export/import for fancier work. I do think export/import of some form is crucial.

I've thought more about the 2D vs 3D e/i options today. 2D is definitely simpler, since Orbiter's texture tree is built on an equirectangular map grid. As long as you're exporting and importing square tiles (or blocks of square tiles), everything's good. That's easy to do with 2D heightmaps. 3D gets wonky, though. We'd want meshes to be to scale in all dimensions (otherwise there's no benefit to the modeler). So the program would need to scale the tile longitudinally into a more-or-less narrow strip on export. That's more development work, but not too terrible.

Importing would be messier, though. If someone's edited the mesh terrain and added vertices (very likely), you'll need to interpolate those into Orbiter's data points AND scale the result back to a square tile. Could get ugly, plus you're counting on someone to provide a mesh with exactly the right dimensions for the tile they want to overwrite.

Thus, for general user experience and ease of development, 2D e/i might be friendlier. Personally I'd prefer that to nothing or a messy process. I can turn heightmaps into meshes and vice versa if I need to.

What do the devs here think? I know Loru's original request was for 3D, but I think this needs to be considered.

 

[Face]

I guess the simplest view is, power users (like Loru and myself) would like to have mesh export/import. The "usual base designer" might not need or want that... simple vertex height editing in a based editor might be plenty, or 2D heightmap export/import for fancier work. I do think export/import of some form is crucial.
<snip>
What do the devs here think? I know Loru's original request was for 3D, but I think this needs to be considered.

Indeed. To me it all boils down to what kind of audience this tool should attract, as well as how big that audience is.

I don't really know if all base designers are more of the "power users" wanting the 3D thing, or more of the casual users, being happier with the 2D thing.
How many custom base addons are there - 50? How many base designers are active in the community - 10-30?

What about older bases, with the original designer having left? Is the 3D option a higher barrier for new-comers to take over, or is it the more restricted 2D option.

I'm inclined to think that the easier implementation route of the 2D thing might make more sense as an immediate roadmap step. As in:

• polish 2D work chain first to give the community a fast path for migration once 2016 is out
• implement 3D later to give detailed control to power users for new development