Question Hand made 2016 elev tiles

[paddy]

The following has to be read with the understanding that I have a 32bit Win10 set up. I do not want to upgrade to 64bit as my hardware is old I had trouble with video drivers, plus the whole dual boot game got messy.

Martin has given the internals of an elevation tile, detailed header, how much data et al.
There are spreadsheets out there which can convert from an old surface tile naming convention to the newer Orbiter 2016. i.e. a tile which fits the bill in OBM can be mapped to a tile which would work in Orbiter 2016.

Could I not then, make a grayscale bitmap which follows the runway, shows hard standings for landing pads and areas for buildings. A kind of pencil drawing of the base if you will. Import this as a surface tile to OBM. Now using OBM place runway, landing pads, meshes and such where they need to go. Save Base and its tile(s)

Add the required header to the OBM tile, rename it and put it in the right folder.

Would that not give me a base that is flat where my “stuff” needs to go.

I accept it would only look OK in and area which is quite flat in any case and as I fly higher other tiles would “kick in” and modify the view but by then I am safely up in the air (vacuum )

I am thinking of a spreadsheet with 100 cells as the header and 259 times 259 cells as placeholders for the grayscale. Another sheet does the maths to convert addresses. The finished sheet is saved as a text (csv style) files and then renamed.

Or am I blowing smoke from my bot bot!

 

[Face]

The following has to be read with the understanding that I have a 32bit Win10 set up. I do not want to upgrade to 64bit as my hardware is old I had trouble with video drivers, plus the whole dual boot game got messy.

Is this a complicated way to say "I can't use tileedit"?

Martin has given the internals of an elevation tile, detailed header, how much data et al.
There are spreadsheets out there which can convert from an old surface tile naming convention to the newer Orbiter 2016. i.e. a tile which fits the bill in OBM can be mapped to a tile which would work in Orbiter 2016.

Elevation tile does not equal surface texture tile. You can't just save a grayscale image in a folder and it magically appears as elevation tile. That's the whole point of OT3's ele2png: to do the conversion between conventional picture and Orbiter's elevation format.

Could I not then, make a grayscale bitmap which follows the runway, shows hard standings for landing pads and areas for buildings. A kind of pencil drawing of the base if you will. Import this as a surface tile to OBM. Now using OBM place runway, landing pads, meshes and such where they need to go. Save Base and its tile(s)

What about the projection distortion? How does OBM handle that?

Or am I blowing smoke from my bot bot!

Perhaps not that, but you remind me of an old cartoon:

 

[fort]

The following has to be read with the understanding that I have a 32bit Win10 set up. I do not want to upgrade to 64bit as my hardware is old I had trouble with video drivers, plus the whole dual boot game got messy.

Is this a complicated way to say "I can't use tileedit"?

On another side if paddy had shortly said: "I can't use tileedit", there would probably have been someone to ask him: "why ?" So...

 

[Face]

On another side if paddy had shortly said: "I can't use tileedit", there would probably have been someone to ask him: "why ?" So...

Do you know that his intention is to say so? I don't know this, that's why I've asked the question if it is just a complicated way to say that.

I can of course assume that he wants to express that, but instead I tend to seek confirmation.

If the sentence had started with "I can't use tileedit, because <blablabla>", I wouldn't have asked that question.

The way it is now, it looks like he wants to propose a Excel-based tile editing workflow, because that's the only way you can edit them on 32-bit systems.

 

[paddy]

I am missing 32 bits not the will to learn. As I understand tileedit requires 64 bit .

As for the grayscale.
By going grayscale I am cutting down on the variation in height levels. i.e. can vary by 256 metres not 16.7 million meters. Rome might have been built on 7 hills, rome airport sure as heck was not.

If I have read the PDF right you can set a ref height in the header and then use the gray scale to add some variation. If I end up with a boring flat 1km by 1km field at least when I land, my DG4 will not slip down the hill while my back is turned!

As for using OBM. It will take a 256 by 256 bit map and make it fit at which level you want. Some tiles map to "squares", some to "rectangles" and at the very low levels they are VERY trapezoid, but OBM sorts it.


This was my point about the pencil drawing of the "airport". This fat black line is the position of the runway, this gray area is the landing pads. This shaded area will stop the scene from being too bland.

I still thank you for your response(s).
and yes I am looking for an excel 32bit fix ( for small areas)

---------- Post added at 04:23 PM ---------- Previous post was at 01:20 PM ----------

Nobody said treeman was 32bit!!! So at least now I can get at the right ele file!

 

[Face]

As for the grayscale.
By going grayscale I am cutting down on the variation in height levels. i.e. can vary by 256 metres not 16.7 million meters.

If you refer to the standard color mapping of ele2png, you are probably mistaken. First, ele2png can't add resolution to the signed 16-bit or unsigned 8-bit formats, it just maps them to colors to give the usual false-color display of heights. Second, ele2png also does grayscale conversion, if you think that to be a better display.

If I have read the PDF right you can set a ref height in the header and then use the gray scale to add some variation.

Well, you can have tiles with 8-bit unsigned values, adding to the double precision offset value.
I get the impression that you think it is a text-format of some sort, though, which it is not. You can't just use Excel to produce some comma separated values, then rename that to *.elv . You have to encode it as bytes. And the encoding as bytes is different for those fields that are stored as floating point (e.g. offset height) or integer (e.g. the 8-bit values).

As for using OBM. It will take a 256 by 256 bit map and make it fit at which level you want. Some tiles map to "squares", some to "rectangles" and at the very low levels they are VERY trapezoid, but OBM sorts it.

So OBM corrects the projection distortion? That's cool. Does it also support editing the tile and back-port to the distorted tile? This you'd need to "do a pencil drawing".

---------- Post added at 18:35 ---------- Previous post was at 18:34 ----------

Nobody said treeman was 32bit!!! So at least now I can get at the right ele file!

Nobody said it was 64bit-only, either! :lol:

 

[DaveS]

So OBM corrects the projection distortion? That's cool. Does it also support editing the tile and back-port to the distorted tile? This you'd need to "do a pencil drawing".

Yes. It comes fully equipped to make a base in Orbiter. It also used to be able to download imagery from NASA's LandSat server and convert it into usable surface tiles but that seems to have died unfortunately. Here's the OBM manual for an overview of it's capabilities: https://www.dropbox.com/s/t4rxxrqt5ozt187/OBM Manual V2.0.3.pdf?dl=0

 

[Face]

Yes. It comes fully equipped to make a base in Orbiter. It also used to be able to download imagery from NASA's LandSat server and convert it into usable surface tiles but that seems to have died unfortunately. Here's the OBM manual for an overview of it's capabilities: https://www.dropbox.com/s/t4rxxrqt5ozt187/OBM Manual V2.0.3.pdf?dl=0

How do you edit the tile within the undistorted view? All I can do is edit the tile in its source. In the object mode, I can't edit the displayed file. That would be needed to have a tight coupling between objects and terrain editing. Sure you can guess it, but it is a bit cumbersome.

OBM would just need that function, and it would make base creation really easy. What a pity that it is not open-sourced.

 

[DaveS]

How do you edit the tile within the undistorted view? All I can do is edit the tile in its source. In the object mode, I can't edit the displayed file. That would be needed to have a tight coupling between objects and terrain editing. Sure you can guess it, but it is a bit cumbersome.

I personally doesn't have any experience with editing tiles but from what I can tell by reading the manual, it has to be done outside OBM (the base files are stored locally in two locations, the Orbiter 2010 directory and My Documents which holds the raw files until the base is loaded into Orbiter).

So the tiles are stored as *.jpg files in My Documents (these are what you need to edit in your image manipulation tool of choice) and when you're done editing them, you need to click on the Force Render Base Files button to update the OBM cache. The Load Base Into Orbiter button will take the raw files and convert/copy them into the Orbiter 2010 directory.

 

[Face]

I personally doesn't have any experience with editing tiles but from what I can tell by reading the manual, it has to be done outside OBM (the base files are stored locally in two locations, the Orbiter 2010 directory and My Documents which holds the raw files until the base is loaded into Orbiter).

So the tiles are stored as *.jpg files in My Documents (these are what you need to edit in your image manipulation tool of choice) and when you're done editing them, you need to click on the Force Render Base Files button to update the OBM cache. The Load Base Into Orbiter button will take the raw files and convert/copy them into the Orbiter 2010 directory.

Well, I have just played around with it, and they are stored as PNG (even if you import it from *.jpg) and you can't edit them inside the undistorted view. If you edit or save them, you get the distorted PNG just as it is stored as DDS.
If I didn't miss some feature, that is. Your confident "Yes" to my question gave me the impression there is such a thing.

 

[DaveS]

Well, I have just played around with it, and they are stored as PNG (even if you import it from *.jpg) and you can't edit them inside the undistorted view. If you edit or save them, you get the distorted PNG just as it is stored as DDS.
If I didn't miss some feature, that is. Your confident "Yes" to my question gave me the impression there is such a thing.

I think I misunderstood your definition of undistorted view.

 

[paddy]

UPdate
It would seem many of the tools are 32 bit, sorry about that.
Modding the ele file seems to work.... I now have my not quite flat runway 100 meters or so up in the "air".

Start fresh in the morning.

---------- Post added 07-02-17 at 08:33 PM ---------- Previous post was 07-01-17 at 09:19 PM ----------

re -ran treeman on my "Hi-res" moon archive.

The result is folders 2 through 12 ( with all the files inside.
New numbering system is old system (OBM) number minus 12 ! (Martin's PDF file).
i.e. OBM level 2 is "2016" level 14 !!!

This would mean that I do not have, nor is there, an elevation tile for even the highest (biggest) OBM tile.

There are 256 folders in \textures\moon\elev\12 which means the at the lunar equator one tile is 0.7031 degrees. In turn that file has a byte which maps to 0.7031/256 degrees. In short a runway 10.5 km long just fits on a OBM level 1 tile which is a QUARTER of the size of the smallest orbiter2016 elev file.

Where is the terrain elevation data coming from

 

[Face]

There are 256 folders in \textures\moon\elev\12 which means the at the lunar equator one tile is 0.7031 degrees. In turn that file has a byte which maps to 0.7031/256 degrees. In short a runway 10.5 km long just fits on a OBM level 1 tile which is a QUARTER of the size of the smallest orbiter2016 elev file.

Where is the terrain elevation data coming from

According to my calculation, on the moon one level 12 data-point (keep in mind they are not necessarily bytes, they could be words as well) is about 80 meters.

Moon radius is approx. 1737km, meaning that circumference is 10913km. Half of that is covered by the latitude bands (the folders), so one band is 21km wide. Dividing that by 256 data-points gives me 83m.
Now a 10.5km runway would cover 126 data-points on level 12 if oriented north/south. If you have east/west components, that gets a bit tricky, because depending on the latitude, the longitudinal width of a data-point varies.

I think 126 data-points are enough to encode a bumpy road. I also think that with higher-resolution tessellation, the data-points of low-resolution tiles are bi-cubic spline interpolated.

 

[paddy]

Understand the maths and accept that two adjacent points are 80 meters apart. I barely understand the

bi-cubic spline interpolated

but can see how it be used to smooth out changes, instead of presenting as fixed steps at 80 meter intervals.

I should be able to use ele2png to get a level 12 png, feed it into "Fireworks" and convert it into 4 times level 13 tiles and then turn them into .elv files

Zero success. 99.99% sure it is down to me but plodding on.

daft things keep tripping me up i.e. my base is in the lower left of a given tile \12\000125\000248 and should end up in \13\000250\000497. are the other level 13 tiles \000251 or \000249 (\000496 or \000498) OR do I just forget about those three other level 13's
Sleep, tea, and a clean sheet of paper maybe. One thing for certain it is not going to be an EXCEL style fix????

 

[jacquesmomo]

my base is in the lower left of a given tile \12\000125\000248 and should end up in \13\000250\000497.

are the other level 13 tiles \000251 or \000249 (\000496 or \000498) OR do I just forget about those three other level 13's

mmm I don't realy understand what you mean, about numeration, but if this can help you : (of course it is not the Moon but the Earth, and these tiles are res 12 and 13).

here are the color code : \Textures\Earth\Surf\12\000119\00178.dds

Res 12 :

Res 13 :

So, if your res 12 tile is \12\000125\000248
your 1st res 13 tile (in the corner up and left of your res 12 tile) will be :
000125 x 2 = 000250
000248 x 2 = 000496
and finally = \13\000250\000496

the next (on the right or East) \13\000250\000497
(or the next (on the down or South) \13\000251\000496)

And in an other way, if you take the 4 res 13 tiles (to have one res 12 tile)
"\13\000250\000496.dds" + "\13\000250\000497.dds
+ "\13\000251\000496.dds" + "\13\000251\000497.dds

you merge the 4 and resize to 512x512 (so total size : 2)
then its name will be \12\000125\000248.dds
because :
000250 : 2 = 000125
000496 : 2 = 000248

:tiphat:

 

[paddy]

Yes I see. No mater what the starting level a tile "2" will give rise to a tile "4" a tile 10 will make a smaller "20"
A tile "6" must make 12 and 13. A level "7" gives the 14 and 15.

Simple... now it has clicked

 

[Face]

I barely understand the
<snip>
but can see how it be used to smooth out changes, instead of presenting as fixed steps at 80 meter intervals.

Nice read on that: https://www.giassa.net/?page_id=274

 

[4throck]

Just a few general comments:

- Elevation tiles share borders with their neighbors. Take that into account if you are hand editing.

- Changes should be carried up and down the tree. You can edit an individual tile/level, but don't be surprised if you get strange results.

- If you can export elevation into matching Orbiter2010 tiles and import into OBM, of course it will work for object placement.

-I find that the 2016 tile system works very well if you are adding terrain for an entire planet. Going from a global heightmap PNG and generating tiles using Face's tool is not complicated and it works.

- I suggest breaking the workflow into steps. Probably OT3 does 80% of what's needed, but people are unfamiliar with command line settings. I speak for myself, I've used it but I don't know it in detail.
Breaking it down allows for examples to be given and possible integration with future GUI tools.

 

[paddy]

Thanks to Face, post 17. I have worked on voice over IP and have had to explain how voice becomes 64000 bits per second. Then comment on how different systems can give very good voice but lower bit rate.

I so very much wish I had had that article to hand. At the time of writing this I have only read about two minutes of it and my understanding has gone up 500%.
Again Thanks.

 

[Face]

I so very much wish I had had that article to hand. At the time of writing this I have only read about two minutes of it and my understanding has gone up 500%.
Again Thanks.

Nice to hear. You're welcome.