Request Orbiter 2016 Surface Tile import/export tool.

[Loru]

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.

Andronicus: I think users will work within limitations and stick to given vertices and not add another. That's why I added subdivide option in my proposition so on export to 3d modeller you get final mesh lat/long resolution of height file and should not move vertices in horizontal plane.


Face: Well. I didn't suggest any 3d for the tool itself at all at all. Limited per height point editing capability could be implemented IMO in numeric fasion. How about something like this?

(Note color coded height points)

 

[Andronicus]

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

Face: That roadmap makes sense to me.

Loru: I think that sounds good with the subdivide feature. I like your interface proposal, too. :thumbup: (Just needs tile navigation.)

 

[martins]

Good to see the activity on this topic. I'd like to register two requests of my own:

1. Any tile-editing utility should make sure to propagate any changes made to a tile through the quadtree, i.e. interpolate the edits to all other levels. The user should not have to apply his edits to different levels manually. Not only would that be tedious and unneccesary, it also opens the potential to inconsistencies.

The changes should at least be propagated downward (to the lower levels). Whether upward propagation is a good idea is debatable. On the one hand, it can be useful to apply rough changes at a low level, let them propagate up, and then do the fine detail at high spatial frequencies at the higher levels. On the other hand, propagating the changes up might override previous edits at the higher level [*]. It may be good to allow the user to choose if changes should be propagated up.

Interpolations should at least be linear (better cubic). Do not just leave out every 2nd row and column when interpolating down, otherwise you will end up with too rough and random results at the lower levels.

2. When editing elevation tiles, be careful about the overlap regions at the tile edges. If a user edits a tile at the edges, the edits should apply to both involved tiles (or all 4 for edits in the corners). Again, the changes should be propagated through the quadtree for all involved tiles.


[*] If you want to include a really cool feature: When propagating edits up the quadtree, you could replace only the low-frequency content, but keep the original high-frequency content. In other words, FT both tiles, add the low-resolution tile to the highpass-filtered high-resolution tile, then iFT back. The filter cutoff should probably not be sharp, but allow for gradual merging at frequencies across the transition. Might need some experimentation, or maybe allow user control.

 

[marcogavazzeni]

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

First:sorry for my bad english :facepalm:

I believe that the question is not how many "power users" will be using the 3d , but how many users will use the bases or the landscapes built with maptiler 3d.
I believe that if modeling the terrain becomes easier , the "power users" will increase.

The Main Orbiter feature is the terrain in 3D, it would be a shame not to be able to create bases or scenery , this is just my opinion .

 

[jacquesmomo]

The Main Orbiter feature is the terrain in 3D, it would be a shame not to be able to create bases or scenery , this is just my opinion .

sorry again for my bad english :facepalm:
It is also my opinion!

 

[NukeET]

How I finally leveled Niven.

2 personal observations are in order first:

1. It may have been easier to get a ham sandwich by going through a pig's backside lol, than to meticulously follow all the directions concerning texpack, treeman, and tileedit. It is too tedious for the casual Orbiter user. I had to RTFM several times in order to work it all out.​

2. If one were a low power user before this process, one would turn into a high power user if the process is seen to a successful completion. Ironically, a high power user HAS to use some pretty low power commands via the command prompt window.​

Now for the details:

Without Face's treeman utility, I wouldn't have known how much disk space was needed to unpack all of the Moon's elevation data. Turned out to be 21.5 GB. Really? 21.5 GB!? Fortunately, I had plenty of room (total HDD size = 1TB). I ended up copying just the files I needed closer to the root of my hard drive in order to make fewer mistakes typing the commands. This also had the advantage of having a working copy (to which edits were applied) and just copying the Elev_mod.tree file back to the original.

It took a little over an hour to unpack all the Elev files in order to use tileedit to modify the right tiles.

I did 3 iterations (modify-pack-copy-run Orbiter to see result) before I suspected (and checked) the base's configuration file, Niven.cfg. No problem there - but I did notice problems getting the entire base leveled because it spanned tiles in places. 2 more iterations and was then done with the immediate base. Plus another 2 more to get the nuke plant area leveled.

I had to get precise Lon and Lat data from Orbiter runs in order to determine where, using tileedit, to make the next guestimate. A higher power interface/utility may need some kind of base info "overlay"(?) to easier facilitate the editing process.

Here's a heads up for tileedit: the elevation data display window color codes the different elevations for that tile - and changes the color codes if the resolution changes, or a nearby tile is selected. Thought I was losing my mind at first.

Fortunately, I'm on holiday this week. Tomorrow I'll tackle converting the surface tiles from the old format to the new format.

 

[ao7g]

Just adding a few cents...

Some years ago ( in Orbiter 2010 ) I tried to develop a lunar base, placed inside tycho crater.

Orbiter 2016 was not here, so for 3d terrain I used the mesh created by 4thRock, found at OrbitHangar here :

[ame="http://www.orbithangar.com/searchid.php?ID=6134"]Tycho mesh[/ame]

Creating, painting the textures, adjusting with the mesh, or/and adjusting the mesh with the textures, playing with transparencies was very tedious, so it was unfinished and never made its way to OrbitHangar.

Maybe the project was too challenging...

Now that 3d is implemented in 2016, the task would be different and maybe more easy...

What I'm most waiting for is a tool to export the chosen *.elv files in a heightmap, so as to modify it ( = flattening the terrain, or even bumping it as necessary ) in an external program, then reimporting it in the *.elv format.

The 3d way is more ambitious and promising... but doesn'it it require more work from the programmer(s), and more time before it would be available ?

2 cents added...