Request Base fix for Orbiter 2016?

[4throck]

Displaying pictures and coordinates is useful.
Imagine that you are importing data and want to see if boundaries match, if changes propagate up and down the tree, etc.
Useful to have visual feedback without having to load Orbiter.

But as you say it won't help directly with bases. That's why I mentioned OBM.

 

[Face]

But as you say it won't help directly with bases. That's why I mentioned OBM.

That's what I thought. I don't plan on doing a full-blown base editor program, it is also not the focus of OT3. Your best bet is to get the author of OBM interested in this regards.

 

[4throck]

We agree 100%

I just sent a PM to OBMs author.
Also checked OBM's manual and files for an email, but no luck.

 

[gattispilot]

OK. So I guess the next step is to edit the elevation tile?

So I open it in paint,.... I assume the elevation is a color. So to flatten an area I would get the area and use the same color, right.
I want the same flatten height to be 0.

 

[Face]

OK. So I guess the next step is to edit the elevation tile?

So I open it in paint,.... I assume the elevation is a color. So to flatten an area I would get the area and use the same color, right.
I want the same flatten height to be 0.

That's the idea, yes. Use e.g. the color-picker tool to get the color of a pixel there, then use a paint tool to draw e.g. a full circle with that color. I think you'll have to repeat that for the level 8 and 7 tile too, so you see it also while zoomed out. Try it out.

I've checked if MsPaint conserves the PNG metadata, and indeed it does. So once edited and saved, "ele2png <root_dir> Elev /<lvl>/<latidx>/<longidx>.png" should convert it back to the corresponding *.elv file to test it out in Orbiter.

 

[gattispilot]

Thanks. I might make it higher so I can see where it is so I can move it.

"ele2png <root_dir> Elev /<lvl>/<latidx>/<longidx>.png"

So i understand "
ele2png c:\orbiter2016\textures\Moon Elev/9/
Not sure about the latidx and Longidx?


I guess back up the ele tile

 

[Face]

Thanks. I might make it higher so I can see where it is so I can move it.

"ele2png <root_dir> Elev /<lvl>/<latidx>/<longidx>.png"

So i understand "
ele2png c:\orbiter2016\textures\Moon Elev/9/
Not sure about the latidx and Longidx?


I guess back up the ele tile

No. That means more like:

ele2png c:\orbiter2016\textures\Moon Elev /09/000006/000030.png

For example, that is. <latidx> is the latitude band index, <longidx> is the longitude band index, just as described by Martin's documentation. Please always mind the spaces between the root path (up to folder "Moon"), the layer denotation "Elev" and the tile address ("/09/...").

You do not need to back up the *.elv file if you always just extract it from the archive, anyway.

BTW: I have upgraded the excel sheet with pixel positions for the given long/lat in a specific tree level for both surface and height-map format:

 

[gattispilot]

Ok. I save the tile and converted it. But now all my moon textures are gone? I saved in the archive. folder. Do I need to put it back in the tree?

 

[Face]

Ok. I save the tile and converted it. But now all my moon textures are gone? I saved in the archive. folder. Do I need to put it back in the tree?

You do not have to manipulate the archive folder. If you edited and saved the PNG at level 9, all you have to do is put in the CLI I posted before. It would then overwrite the *.elv file and it is ready to go.

 

[gattispilot]

Ok Thanks.
So I edited and saved. Then ran this:

C:\Users\John Gattis>ele2png c:\orbiter2016\textures\Moon Elev /09/000006/000030.png
/09/000006/000030.elv
File already exists! Overwrite? (YnAsc?) y

Y - Yes, overwrite this file - upper case mandatory
n - No, skip this file
A - All, overwrite all existing files without further notice - upper case mandatory
s - Skip, all existing files will be skipped without further notice
c - Cancel, stops executing immediatly
? - Help, show this help - default

(YnAsc?) Y

Weird I get the moon textures now. But not flat.

Is there a color for 0 elevation? Fo one couldplace a vehicle there and it ride on top?

It looks like one could build the ramps going up to the launchpad.

 

[Face]

Ok Thanks.
So I edited and saved. Then ran this:

C:\Users\John Gattis>ele2png c:\orbiter2016\textures\Moon Elev /09/000006/000030.png
/09/000006/000030.elv
File already exists! Overwrite? (YnAsc?) y

Y - Yes, overwrite this file - upper case mandatory
n - No, skip this file
A - All, overwrite all existing files without further notice - upper case mandatory
s - Skip, all existing files will be skipped without further notice
c - Cancel, stops executing immediatly
? - Help, show this help - default

(YnAsc?) Y

Weird I get the moon textures now. But not flat.

Is there a color for 0 elevation? Fo one couldplace a vehicle there and it ride on top?

It looks like one could build the ramps going up to the launchpad.

The overwrite warning is logical, because there already is an *.elv at that address.

I don't know what you did to your textures, but when I tried your tile position, the terrain was as flat as it can be.

You can make an arbitrary color mapping with the "-r" option. However, why do you want 0 level? That would make it a deep hole high platform. If you take one color of the surroundings, it will better match the terrain. Perhaps you can share the edited tiles so we can take a look?

BTW: Normally the color mapping is dynamic RGB, meaning the lowest height of the whole tile is the "lowest" color (deep blue), and the highest height is the "highest" color (cyan). If you use grayscale, the lowest height of the whole tile is black and the highest is white. However, using "-r0" you can use the fixed range, meaning that according to the tile's precision (either 8-bit unsigned or 16-bit signed), the lowest height available will be the "lowest" color, and the highest height available the "highest" color. Using "-r <low_value>:<high_value>" you can assign any value to that colors. If you assign too narrow a range for the tile values, you'll get a warning.

Taking your level 9 tile as example, its dynamic range is -3218:900. Obviously it is not easy to determine what exactly zero level is in that range. If you use "-r -3220:3220", zero level will be in the middle of the 16-bit LUT, which is dark orange (0xFF8E1D). If you use grayscale instead of color, the middle is value 32768.

---------- Post added at 23:08 ---------- Previous post was at 21:54 ----------

This is the level 9 tile with a "zero-level-cake" in the crater. :lol:

The tile was created with the range and color noted above. A ShuttleA placed there shows me altitude 3m, which is AFAIK the COG height of the ShuttleA.

 

[paddy]

IF and a big IF, we where to put a long term stay base on the Moon, would they not clear and area of "pot holes" and rocks. I would therefore expect a large cleared area, a "bit" like what is shown in the picture in post 51.

Please keep this thread going, we ( I mean you gents ) could soon have a way of mixing OBM and the new surface tiles.

 

[GLS]

Instead of overwriting the files in the Elev folder, shouldn't we be putting them in the Elev_Mod folder?

 

[Face]

Instead of overwriting the files in the Elev folder, shouldn't we be putting them in the Elev_Mod folder?

That should be possible, too. Just add an alpha channel to the PNG, make the areas that should be untouched transparent, and use the layer "Elev_mod" instead of "Elev" in the ele2png call to convert the PNG to a modification *.elv .

I'm a bit on the fence about the actual usefulness of the mod layer TBH. On the one hand, I can understand the idea of not manipulating the terrain via addons directly. On the other hand, if you manipulate the terrain for addons with mod tiles, how do you deploy them, anyway? It won't work with archives, because they are too big and a global "namespace". If you just deploy cache tiles and use Orbiter's cache-before-archive feature, you could have done so with the normal ones, too.

IMHO the mods would make sense if they could be in separate folders for each addon and all those merged on the fly. That way an addon X deploys its tile A with only some changes in e.g. the lower right corner, and addon Y also deploys its tile A with some changes in the upper left corner, and it would work. As it is now, there would be a collision problem for the user to solve: should they use the tile from X or Y? Granted, the transparency information would make it easier for yet another tool to merge it, but the user experience is already botched.

So... on the fence...

 

[GLS]

The understanding I got from reading the documentation is that devs changing the .elv files should place them in the Elev_Mod folder, so the original terrain information isn't lost.

In SSU, I was levelling runways this way and it works.

Anyway, yeah, there might be conflicts between addons having different elevation needs.

 

[4throck]

Not that different from having two Apollo add-ons, or different versions of Cape Canaveral. The user must choose what to use or setup separate Orbiter installs.


Having real terrain forces one to think realistically. That means building bases on areas that are already flat, and choosing the best spots within those areas.

It can be done (in theory) by loading the elevation PNGs into OBM (as normal ground textures), so that you can see where the base objects will be...

 

[Face]

The understanding I got from reading the documentation is that devs changing the .elv files should place them in the Elev_Mod folder, so the original terrain information isn't lost.

Yeah, I read that so, too. But the original terrain information isn't lost, anyway. Just remove the tile in Elev, and the original archive will be used. That's why I said there is not much sense in using Elev_mod currently. Just my opinion, of course.

 

[gattispilot]

So I did this:

it seems to work. I placed a DG and LER-General vehicle and it seemed good
Thanks.

 

[BrianJ]

Hi,
I wonder if anyone can help me with using Treeman?

I'd like to flatten out an area of terrain for a launch pad, SLC-17 at Cape Canaveral, lng.-80.5660630 lat. 28.4455200

I did manage to use treeman and ele2png to modify a level 15 .elv file, but it causes Orbiter to go crazy if it's in the Textures/Earth/Elev/15 folder (white earth, no textures, random mesh extending to infinity etc.!)

Here's my method:

I got a list of all the tiles that contain the location using Face's Xel spreadsheet (many thanks, and also for treeman).

/04/000000/000000
/05/000000/000001
/06/000001/000002
/07/000002/000004
/08/000005/000008
/09/000010/000017
/10/000021/000035
/11/000043/000070
/12/000087/000141
/13/000175/000282
/14/000350/000565
/15/000700/001131
/16/001400/002262
/17/002801/004525
/18/005602/009050
/19/011205/018101

Using this list and treeman to extract the .elv files, it generated an Elev folder with level 04 to 15 sub-folders, and the relevant .elv files:

/04/000000/000000.elv
/05/000000/000001.elv
/06/000001/000002.elv
/07/000002/000004.elv
/08/000005/000008.elv
/09/000010/000017.elv
/10/000021/000035.elv
/11/000043/000070.elv
/12/000087/000141.elv
/13/000175/000282.elv
/14/000350/000565.elv
/15/000700/001131.elv

Using the above list and ele2png, I generated a .png from each .elv.
Using Photoshop I modified the lowest level /15/000700/001131.png, using a solid colour to fill the relevant area.

Then used ele2png to convert the modified /15/000700/001131.png back to
an .elv file.

It all looked like it worked OK, but as I said, using my modified .elv tile causes Orbiter to have a nervous breakdown.

Any ideas as to why it's not working for me?

I attach my Textures/Earth/Elev file with the all the .elv files including the level 15 which breaks my Orbiter, also attached the modified .png used to generate the level 15 .elv.

Many thanks,
Brian

 

[Face]

I did manage to use treeman and ele2png to modify a level 15 .elv file, but it causes Orbiter to go crazy if it's in the Textures/Earth/Elev/15 folder (white earth, no textures, random mesh extending to infinity etc.!)

Sounds like you did nothing obviously wrong. I'll take a look.