Tutorial on how to convert 2010 bases to 2016 bases

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Hey.

Has anyone tried to convert Orbiter 2010 bases over to Orbiter 2016? If so, what was the procedure? I want to get the SSU bases (Vandenberg, Edwards and White Sands) converted but I have no idea where to start.
 

jroly

Donator
Donator
Joined
Jan 26, 2014
Messages
404
Reaction score
1
Points
18
It should be fairly simple, you would need to flatten the terrain around the bases using a utility tool, beta 2016 comes with the tool now but I am not sure if it works well.

I would like to see Orcus Patera converted.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Now that the beta has gone into RC status, any update on this?
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
Bumping for attention again.

In the same vein: is there a simple way to determine altitude at the touchdown point on each runway and pad, without manually flying each one? I.e. can you ask for terrain alt at a lat/lon position?
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
is there a simple way to determine altitude at the touchdown point on each runway and pad
Maybe we could use:
oapiSurfaceElevation ( Planet,lon,lat ) ?
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
I just started to look into the possibility of converting the Baikonur bases from 'Historical Spaceports" to 2016 format. So far, I've managed to script the tiles needed by the bases into the new format. Discovered the unfortunate side effect of the new tile system is that all tiles, even for the bases, are now lumped in the planet data set, and cannot be referenced from separate folders, isolating them from other "potentially competitive" addons: tile deployed by any addon will affect all other addons. In another side effect, tiles cannot be time-conditioned anymore: once deployed, tile will look the same in year 1910, 1961 or 2050. Are my assumptions correct, or did I possibly miss some customization logic somewhere?

After converting tiles, I am now trying to fix the terrain elevation, as default elevation has very rough accuracy (e.g. having a big hump at the location of the huge MIK building, and distorting the pieces of the building that go there from the base configuration file). I figured out how the tile structure and the tileedit app (too unresponsive and fragile to my test, but workable). But now I have the following resolution level problem.

- best elevation tiles available in Baikonur area are level 13.
- custom surface tiles that I am trying to deploy are level 19.
- editing level 13 elevations for level 19 images is too rough to be practical.
- maximum elevation level supported by 2016 is 17.
- minimum practical elevation level in a rather flat Baikonur area is probably no less than 15 (and only if 17 turns out to be too tedious, usually the more detail - the better).
- tileedit has a limitation: it can edit the elevation tile only if original tile OF THE SAME LEVEL exists.

This leads to a problem: if I want to edit level 17 elevation tile, I have to create it first. And I do not want to start from scratch with the empty tile: full-size level 17 tile is a much big area, than I need to modify. I don't care about most of its remaining surface, plus this surface contains relevant data in its upper levels of the quad tree (at level 13) that I want to preserve ant that I should somehow be able to propagate from level 13, rather than reinvent myself on a new virgin tile.

I did not find any reference on how I can take a corresponding piece of data from elevation tile 13 and generate a downstream approximation of subsequent layers (like 15 or 17) that will resemble the upstream data as close as possible, giving the good start to fine-tuning level 17 in elev_mod tree. So, my question is: does a step-by-step procedure or tool exist for such operation? Has anyone encountered any similar problems?
 

fort

Active member
Joined
Mar 19, 2008
Messages
1,017
Reaction score
20
Points
38
I just started to look into the possibility of converting the Baikonur bases from...

I think that there is always an hélas unsatisfying solution like taking one or some elv coming from KSC at level 16, 17, under..; renaming this or those .elv to match the Baikonour coordinates; put it or them in the right folder, and edit in tileedit with the elevations values requested.

Don't know if this could work. I made some experiment like that few months ago but too short to see all the possible problems coming with that sort of tweak when really implemented.
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
I think that there is always an hélas unsatisfying solution like taking one or some elv coming from KSC at level 16, 17, under..; renaming this or those .elv to match the Baikonour coordinates; put it or them in the right folder, and edit in tileedit with the elevations values requested.

I tried this, of course, before writing my post :). It does work indeed, but has two major drawbacks:

1. KSC is at sea level, Baikonur averages ~100m. So, you need to update every single pixel of the copied tile to match the new location, which is very tedious in tileedint (and usually exceeds tiledit's very thin stability timeframe :) ).

2. Elevation info in the new tile has to be re-invented from scratch and won't match the upper levels of quad tree. Even the flattest parts of Baikonur are not as flat as Florida :)

Tileedit actually shows the "stretched" tile produced from the upper level (13). It just cannot save it into elev tree, and, because of that, cannot save the elev_mode either.

In general, I feel all we need is just some more diverse and better quality tools to work with the tiles. Tileedit is only a start. Format is documented, so, hopefully, it is only a matter of time (hopefully a short one).
 

fort

Active member
Joined
Mar 19, 2008
Messages
1,017
Reaction score
20
Points
38
I tried this, of course, before writing my post :). It does work indeed, but has two major drawbacks

I used tileedit to take informations about tiles, their levels, positions, and take a look at the tileedit part for elevation in the in the intention to understand how it works but without great attention.

I saw that stretched tiles but as it was not my first interest...your description in fact brings some aspects of the problem for wich one i was ignorant.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
In general, I feel all we need is just some more diverse and better quality tools to work with the tiles. Tileedit is only a start. Format is documented, so, hopefully, it is only a matter of time (hopefully a short one).

Yes, precisely. If it helps, I could upload the tileedit sources. Most people probably won't have access to Matlab to modify this directly, but even so it might be useful for somebody implementing an alternative.
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
Another quick idea: to make some kind of tool or even a simple converter-generator (could be even, better, a script-friendly command-line utility) that can convert a simple 256-bit "heat map style" bitmap into an elevation tile. This way, elevation tiles can be quite freely prepared in just any graphic editor as "heat" bitmaps, split or resized to any desired resolution, then quickly converted to .elv as the last step of the workflow. And then tileedit would only be needed for minor remaining fine-tuning.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Another quick idea: to make some kind of tool or even a simple converter-generator (could be even, better, a script-friendly command-line utility) that can convert a simple 256-bit "heat map style" bitmap into an elevation tile. This way, elevation tiles can be quite freely prepared in just any graphic editor as "heat" bitmaps, split or resized to any desired resolution, then quickly converted to .elv as the last step of the workflow. And then tileedit would only be needed for minor remaining fine-tuning.
face is working on such a tool: http://www.orbiter-forum.com/showthread.php?t=37452
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Yes, precisely. If it helps, I could upload the tileedit sources. Most people probably won't have access to Matlab to modify this directly, but even so it might be useful for somebody implementing an alternative.

I've now uploaded the tileedit sources to github: https://github.com/mschweiger/orbiter-tileedit

(Why git?!? I hear you gasp - well, you have to go with the times occasionally, and SVN is apparently very much yesterday's geek chic ...)

The code isn't documented (I didn't expect to share it), but it's not very complex and should be fairly self-explanatory.

Waiting for those pull requests ...
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
(Why git?!? I hear you gasp - well, you have to go with the times occasionally, and SVN is apparently very much yesterday's geek chic ...)

Thanks for sharing. What makes me gasp more than that it is git controlled, though, is that it is GPL ;).

---------- Post added at 07:26 ---------- Previous post was at 07:20 ----------

If I understand the code correctly, tileedit effectively clears the lat/lon ranges from the ELE data (it is marked TODO). Is Orbiter ignoring those values?
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
If I understand the code correctly, tileedit effectively clears the lat/lon ranges from the ELE data (it is marked TODO). Is Orbiter ignoring those values?

Hm, yes, good point. Orbiter does infer the ranges from the [lvl,ilat,ilng] indices of the tile, rather than the values stored in the file. Nonetheless, I should write the correct values to the header files, if only as a sanity check, even if they are redundant.
 
Top