Project Orbiter texture tree tools (OT3)

[Face]

Quick notice: my first guess of having to do with 16-bit LUT was wrong. The tile in question uses the 8-bit type for elevation data, and ele2png produces simple 10-bit LUT (the "standard" colormapping) for those tiles.

I think it can't be actual error accumulation either, because some data-points are completely wrong whereas others are simple off-by-one errors. Might be a systematical error that I never noticed due to mostly working with -16 type elevation data.

---------- Post added at 15:52 ---------- Previous post was at 13:00 ----------

Fixed the round-trip bug with type 8 elevation tiles: http://www.snoopie.at/face/beta/ot3.zip .

 

[GLS]

Quick notice: my first guess of having to do with 16-bit LUT was wrong. The tile in question uses the 8-bit type for elevation data, and ele2png produces simple 10-bit LUT (the "standard" colormapping) for those tiles.

I think it can't be actual error accumulation either, because some data-points are completely wrong whereas others are simple off-by-one errors. Might be a systematical error that I never noticed due to mostly working with -16 type elevation data.

---------- Post added at 15:52 ---------- Previous post was at 13:00 ----------

Fixed the round-trip bug with type 8 elevation tiles: http://www.snoopie.at/face/beta/ot3.zip .

Many thanks!
One question: you didn't implement the elevation tile integration to lower resolutions?

 

[Face]

One question: you didn't implement the elevation tile integration to lower resolutions?

Not yet, because the overlap makes it a bit complicated. If there is a need for that, I can look into it.

 

[GLS]

Not yet, because the overlap makes it a bit complicated. If there is a need for that, I can look into it.

It would be a nice thing to have when 2 or more adjacent tiles are edited, because as we move away from them, the tile furthest away will "unload" first (i.e. load a lower level) and that will show a discontinuity in the elevation because that lower level tile isn't edited.

 

[astrogull]

ELV Tile Splitter

It would be a nice thing to have when 2 or more adjacent tiles are edited, because as we move away from them, the tile furthest away will "unload" first (i.e. load a lower level) and that will show a discontinuity in the elevation because that lower level tile isn't edited.

Yesterday I published the addon Elv Tile Splitter, which solves most of the problems when making new elevation tiles and integrate them in the existing tiles. Scale, stitching, merge, split and also stitch the new tile to tiles of a lower level.(https://www.orbithangar.com/searchid.php?ID=7109)

Stitching to a lower level still is a problem, because, at least on my laptop and graphic card, Orbiter2016 generates new elevation points as soon as you insert a higher level elv tile, even more points then are available at the higher resolution level. You can check this with a treeman list of AntilopeValleyScn package and look for level gaps.

Of course one can allways resize the background tile, say 16 x for a level+4 increase to generate a map and split in into 256 tiles. That way the discontinuity is moved out of sight. This is at least some kind of a solution, but not a satisfying one.

 

[GLS]

Yesterday I published the addon Elv Tile Splitter, which solves most of the problems when making new elevation tiles and integrate them in the existing tiles. Scale, stitching, merge, split and also stitch the new tile to tiles of a lower level.(https://www.orbithangar.com/searchid.php?ID=7109)

Stitching to a lower level still is a problem, because, at least on my laptop and graphic card, Orbiter2016 generates new elevation points as soon as you insert a higher level elv tile, even more points then are available at the higher resolution level. You can check this with a treeman list of AntilopeValleyScn package and look for level gaps.

Of course one can allways resize the background tile, say 16 x for a level+4 increase to generate a map and split in into 256 tiles. That way the discontinuity is moved out of sight. This is at least some kind of a solution, but not a satisfying one.

Right now I'm busy with other things, but when I get back to terrain editing I'll check this. Thanks!

 

[Face]

Yesterday I published the addon Elv Tile Splitter, which solves most of the problems when making new elevation tiles and integrate them in the existing tiles.

Great work! It's nice to see that OT3 inspired people to work on the tree toolset. :thumbup:

 

[Face]

There is a new version of treeman and ele2png in this updated OT3 package: http://www.snoopie.at/face/beta/ot3.zip .

Nothing big, just added the "Label" layer to treeman and a metadata file feature to ele2png.
With the later, the need for editors to preserve the PNG comment holding the metadata is gone. Now ele2png knows about 4 metadata modes, with the default one producing both comment and file on write, and reading comment first, then falling back to file if none is found. This solves the problem of lossy editors that drop the comment.
It also allows for external editing of the metadata. If you have data from external sources, you can create a metadata file with the following content:

vmin=<lowest> vmax=<highest> scale=<scale> offset=<offset> type=<type> padding=1x1 colormap=<colormap> smin=0 emin=0 smean=0 emean=0 smax=0 emax=0 latmin=0 latmax=0 lngmin=0 lngmax=0

Note that there is no newline at the end of the single line. Values in angle brackets should be filled according to the picture data, constant values should be left as they are. The min/max/mean are recalculated on import, the lat/lng don't matter to Orbiter as it seems from the OVP D3D7Client code base.
Meaning of the variables:

• <lowest> is the height value that should be associated with the lowest color value. In grayscale that's black, in color it's deep blue.
• <highest> is the height value that should be associated with the highest color value. In grayscale that's white, in color it's cyan.
• <scale> is the multiplication factor to get to the meter unit. I.e. if you have value 1 here, the height values mentioned above are in meters. With the beta versions, Orbiter supports other scales than 1 now, so you can have e.g. 0.5 as value there to get half meters. A height value of e.g. 25 would then mean 12.5m .
• <offset> is the height from mean planet radius that serves as zero-level for the tile data, unit in meters. So if you have a height value of e.g. 25 with scale 0.5 and offset -4, your absolute height from mean planet radius is 25x0.5+(-4)=8.5m .
• <type> is the type of Orbiter tile that should be created. Currently only "-16" and "8" are supported, corresponding to signed 16-bit precision and unsigned 8-bit precision.
• <colormap> denotes the color translation table that is taken into account when decoding 8-bit color PNG. Value "2" interprets the data with the OT3 look-up-table (LUT), which was invented to allow full 16-bit precision encoded in an 8-bit color PNG, and would hardly be found in external data sources. All other values will interpret data with a standard LUT ("HSV blue-cyan"). In addition, every 8-bit color import will also try to guess the value if it doesn't match the LUT according to trivial and single-channel grayscale mappings.

So let's say you have some external heightmap in grayscale, with lowest value -5 meter and highest value 2000m. You can then produce a metadata-file like so:

 vmin=-5 vmax=2000 scale=1 offset=0 type=-16 padding=1x1  colormap=0 smin=0 emin=0 smean=0 emean=0 smax=0 emax=0  latmin=0 latmax=0 lngmin=0 lngmax=0

 

[Face]

There is a new version of ele2png in this updated OT3 package: http://www.snoopie.at/face/beta/ot3.zip .

This is just an implementation of the changes discussed here: https://www.orbiter-forum.com/showthread.php?p=593923&postcount=51

• The meta-data extension is now *.hdr .
• For vmin and vmax values, floating point input is now tolerated, although truncated to integer internally. On save, these values are still serialized as integers.
• The lat/lng min and max values are now serialized and interpreted as degrees, in contrast to the former radian representation. This might break backwards-compatibility, but only so with values that are never used in Orbiter, anyway. I.e. an old (unedited) PNG converted back to ELE with this new version might be binary different in the header part containing the lat/lng values, but it should work just fine.

 

[astrogull]

Today I published a new version of Elv Tile Splitter at OH, see https://www.orbithangar.com/showAddon.php?id=068e90b9-edcc-4130-851f-46edb99a5405 for the new features.

see also https://www.orbiter-forum.com/showthread.php?p=608081&postcount=71 in the tileedit update thread.

As a last minute change (always dangerous) the extension is now .hdr.
I do not use the latmin etc values except when stitching maps or generating level-1 maps to store x,y coordinates of the emin-emax.

 

[Thinker55]

Is there a simple fix for existing bases?

Okay, so, I'm a serious newbie at base creation, and I've been trying to follow threads, including this one. Am I correct in assuming that Orbiter 2010 bases were not updated for 2016? Baikonur, for example, is awful in places -- if you try to occupy several of the pads, they actually MOVE and you can end up above or below them. Pad 7 is particularly bad. You don't appear on several of the pads when you select them in the scenario editor, and chasing them would be hilarious if it wasn't so irritating. The runway does not appear in the scenario editor. Is there a simple way to fix these things? The config file does not seem to provide any method of determining which object is which. Perhaps someone can point me at a method for determining that. Do I just run treeman as described early in this thread? does that fix things?

 

[Face]

Am I correct in assuming that Orbiter 2010 bases were not updated for 2016? Baikonur, for example, is awful in places -- if you try to occupy several of the pads, they actually MOVE and you can end up above or below them. Pad 7 is particularly bad. You don't appear on several of the pads when you select them in the scenario editor, and chasing them would be hilarious if it wasn't so irritating. The runway does not appear in the scenario editor.

Do you mean that you've taken an addon for Baikonur - which was created for 2010 - and installed it in 2016? This will certainly not work as expected.

Although the stock rendering engine still loads and displays the high-res tiles, it will do so in a weird way: still spherical mapped, but somehow shining through the terrain above, which can lead to all kinds of visual artifacts.

Is there a simple way to fix these things? The config file does not seem to provide any method of determining which object is which. Perhaps someone can point me at a method for determining that. Do I just run treeman as described early in this thread? does that fix things?

There is no simple way to convert 2010 bases to 2016 that I know of. What treeman can do is converting the high-res tiles from a 2010 base to new-style tree tiles. It can not convert the base elements to the proper position. What you could do with the tool set at hand is flattening the terrain so the 2010 base elements are properly visible again. However, flattening is far from being automatic.

I did some PoC implementation for a configuration file based flattening system here, but besides being fully functioning and promising, nobody ever picked up on it to get it into the mainline, and I must admit that I don't feel like it, either.

 

[Thinker55]

2016 bases

Sorry about the delay -- I didn't even know you responded. Hopefully, the new forums will include notifications. No, I was just trying to use delivered bases and scenarios -- some of which look awful. At this point, I've picked a base -- Wallops Island -- and I'm trying to develop a decent 2016 replacement. I've been having fits with ElevTileSplitterV2 -- I just cannot find a way to get it to produce proper results. I have a fine satellite map in high res that I COULD split up into tiles to get to probably Level 16 -- but I keep getting weird results and can't control outputs. I am currently using the older tools as best I can an hoping the product will turn out halfway decent. If I can figure out a decent system, I plan to do places like Baikonur, White Sands, Edwards Dry Lake and Vandenburg -- all of which will probably be easier, frankly.

 

[Notebook]

I did a base for Wallops Island, its on Orbiter Hanger.

If it helps feel free to use the surface tiles. They are from Google Earth.

 

[Thinker55]

Wallops Island

Where would I find it? Can you give me a link? Right now, search by author is broken. Maybe after next weekend...

 

[Notebook]

Yes same for me. It was fixed, but the admin are working on an upgrade and I haven't bothered them at the mo.

https://www.orbithangar.com/showAddon.php?id=1cf65b0e-421f-4fd4-b775-bf38c19cb9ef

Older than thought! Feb 2016.
Its actually finished though that screen shot dosent look like it.

 

[Thinker55]

Wallops Island

I will certainly be taking a look at this -- but I was given to understand that there were copyright issues with Google Maps. Besides, this is the start point for the development of a new base creation process. It isn't just about Wallops. I have data -- beautiful data -- but I have been unable to find a simple tool for working with elevation maps. Weirdly, the Level 10 tile for the Wallops area is absolute garbage. It's probably 8-bit -- it's DEFINITELY half the size of the surrounding tiles -- it looks awful, and doesn't even have the proper boundaries. There's no scaling it to anything beyond Level 11 -- even that is a total waste of time. I'm not sure how it got there, but it seems to be delivered that way in the base installation. I have been working with Astrogull's new Elev Tile Splitter V2, but it seems like what I don't know continues to impede progress. I'm wondering if I can just manually create tiles at the proper levels by splitting my high-res map. The Elev Tile Splitter lets me create a tile from a png file -- but then it won't read it in the cache. Tileedit does, however, so it isn't as if the tile isn't there. I haven't EVEN gotten to trying to create tiles from a map. I'm probably two weeks into this now and the frustration level is high. Astrogull has pointed out some mistakes, but I still can't follow his documentation. It appears to me that there are pieces missing from his demos. I've been wrong before, so I'm quite possibly wrong, but I couldn't follow the process as presented.

Eh, sorry about the rant. As I've noted, I'm somewhat frustrated.

 

[Face]

Eh, sorry about the rant. As I've noted, I'm somewhat frustrated.

If you feel frustrated, perhaps it is best to take a break, relax a little with things you like, then come back after a while and try again. Often enough, wanting things too much leads to so much frustration, that what follows is outright hate. I'm starting to see this pattern here, please stop it before you go down that road.

 

[Notebook]

For Thinker55 #217.

There has been discussion here about using Google for surface tiles. I always put it in the add-on if I've used Google. If you have any qualms about it, don't use them.

If Google contact me, obviously I'll take them off OH.

Re the new tile format. I've tried several times to get into it and the tools others have made available. Its too complex for me, though I may try again when personal circumstances ease and I can concentrate again!

Good luck with your project.

 

[jacquesmomo]

@ Thinker55

Hello :tiphat:

Managing tiles in Orbiter 2016 is not easy, but with a little perseverance you get there ... :lol:

You can install my Kourou-csg add-on and watch how I did it.
(and thank you again to Face who helped me a lot.)

friendly