tileedit updates

[paddy2]

Looks like a bit of homework for me then.:hmm:

 

[martins]

The new Qt version of tileedit now has approximately the same functionality as the previous Matlab version, so I'll include it from the next Orbiter beta.

I have a question though: By default, Qt only supports dynamically linked applications. This requires them to ship with a fairly extensive set of runtime libraries, which seems a bit cumbersome. I'd rather have a statically linked tileedit, but static linking with the Qt runtimes doesn't seem to be trivial. I haven't found any static Qt installations, and the only way to do it appears to be to compile Qt yourself from the sources with static linking.

Before getting into that, does anybody know of a precompiled static Qt version?

 

[GLS]

The new Qt version of tileedit now has approximately the same functionality as the previous Matlab version, so I'll include it from the next Orbiter beta.

I have a question though: By default, Qt only supports dynamically linked applications. This requires them to ship with a fairly extensive set of runtime libraries, which seems a bit cumbersome. I'd rather have a statically linked tileedit, but static linking with the Qt runtimes doesn't seem to be trivial. I haven't found any static Qt installations, and the only way to do it appears to be to compile Qt yourself from the sources with static linking.

Before getting into that, does anybody know of a precompiled static Qt version?

Is this it? https://www.npcglib.org/~stathis/blog/precompiled-qt4-qt5/
Seems huge... :uhh:

 

[martins]

Is this it? https://www.npcglib.org/~stathis/blog/precompiled-qt4-qt5/
Seems huge... :uhh:

Thanks - looks promising. I'll try it, I'm just a bit worried about the OpenSSL dependency which I don't need. Hopefully that can just be ignored.

Yes, Qt isn't exactly a lightweight package ... Hopefully the static linker is clever enough to include only the actually referenced modules in the application code.

 

[martins]

Here is a trial build of the Qt-tileedit version I've been working on. This should work stand-alone without the need of installing any Qt runtimes. It has all the functionality of the original Matlab version, with a few notable additions:

• It can read from compressed archives as well as the cache (i.e. the individual tile files arranged in the directory tree). Use File | Configure to select read preferences. It has the same options as Orbiter itself.
• It can display 2x2 tile blocks instead of individual tiles, to make it easier to edit across tile boundaries. Again, select in File | Configure.
• It has a few eyecandy options for the elevation display. Select in Elevation | Configure. For Earth, try in particular the topographic colour maps and the "Display water mask" options.
• If you try to edit a non-existent elevation tile (i.e. one that has been synthesised from an ancestor sub-region), tileedit will warn you and give you the option to create that tile.

General usage should be pretty obvious. Load a planet tileset via File | Open, and pick the base directory of the planet's tileset, generally <orbiterroot>/Textures/<planet-name>. Select the layers you want to display via the dropdown lists for each of the three displays. Navigate the quadtree by moving over the images and clicking, or by entering a tile designation directly in the top left field.

There is some elevation editing capability (click the right "Action" button to access it). This is currently still very limited (essentially the same as the Matlab version), but I'll work on that next. If you want to try it, make sure you have a backup of your tileset in case things are going wrong. Changes are always written to the "Elev_mod" layer, so you can undo changes by deleting the relevant tiles in that layer, as long as you remember which ones are from your edit. One exception is if you created a new elevation tile in order to edit. This will create an entry in the "Elev" layer.

Let me know of any problems, and any additional features you would like to see. Even more welcome with code to go along with it. The sources are in https://github.com/mschweiger/orbiter-tileedit.

I do seem to get the occasional (infrequent) CTD when moving the mouse in and out of a tile display, which looks to be related to an infinite loop in the Qt notification chain. If any Qt-savvy coder can reproduce that and has a solution, I'd be very grateful.

 

[GLS]

Very cool!
No issues in the 5 minutes I played with it so far, and opened several planets with almost no CPU or RAM load. :thumbup:

 

[kuddel]

Ran tiledit -build from source- without any issues :thumbup:
I'll play around a bit and will report any issues (if I encounter any).
By the way: Nice "disco ball" app-icon !

 

[jacquesmomo]

I had already used (with difficulty but successfully) tileedit first matlab version to modify and add tiles for my add-on, Kourou-CSG that I am finalising ELA3 and ELA4(zones) ...:tiphat:

I just tested this new version quickly ... and I'm impressed by the difference!
Speed, ergonomics ... bravo! :woohoo:

I do not have time to test any longer, but if I notice anything, I will report it.
Thanks again !!!

 

[dgatsoulis]

Been testing for a couple of hours. Using it to get the coordinates of tiles and grabbing google maps textures with the help of a script. No CTDs and no problems whatsoever. :thumbup:

 

[4throck]

The center window should default to elevation. Otherwise, it CTDs on tile edit (if you put elevation on the left window).

How about an option to save / load a tile to PNG?
That seems like the most obvious feature to have

 

[jacquesmomo]

The center window should default to elevation. Otherwise, it CTDs on tile edit (if you put elevation on the left window).

I tried elevation on the left window: no ctd for me....

How about an option to save / load a tile to PNG?
That seems like the most obvious feature to have

I agree with you :
it should be an excellent idea .... but is it possible ?

:tiphat:

 

[Face]

it should be an excellent idea .... but is it possible ?

It is possible to convert tile data to PNG and back again, as demonstrate before with ele2png.

 

[martins]

The center window should default to elevation. Otherwise, it CTDs on tile edit (if you put elevation on the left window).

I'll look into that.

How about an option to save / load a tile to PNG?
That seems like the most obvious feature to have

It is possible to convert tile data to PNG and back again, as demonstrate before with ele2png.

Good idea - at least for the elevation data. I don't want to allow editing the surface layer, since it uses a lossy (DXT1) format, which means that every edit cycle potentially degrades the data. The surface layer should always be edited directly in the source data.

I think I remember that PNG supports 16-bit pixel values, correct? One potential problem I anticipate is the fact that the elevation tiles support a scale and offset parameter which I don't see how to preserve in PNG. What about TIFF instead? AFAIK that allows to store user-defined tags which I could use to encode those parameters. Also, we could then possibly store the tiles in GeoTIFF format, so they could be read directly into a GIS application.

 

[Face]

I think I remember that PNG supports 16-bit pixel values, correct? One potential problem I anticipate is the fact that the elevation tiles support a scale and offset parameter which I don't see how to preserve in PNG. What about TIFF instead? AFAIK that allows to store user-defined tags which I could use to encode those parameters. Also, we could then possibly store the tiles in GeoTIFF format, so they could be read directly into a GIS application.

PNG supports 16-bit pixel, but it is also possible to use a lossless LUT into the 8-bit RGB range.
PNG also supports meta-data strings that survive round-trips in certain editors (e.g. GIMP). For other editors, there is the option to write out a separate file with the meta-data. Worked just fine with e.g. Krita. This all is similar to the situation with TIFF regarding user-defined tags.

 

[4throck]

I don't want to allow editing the surface layer, since it uses a lossy (DXT1) format, which means that every edit cycle potentially degrades the data.

One use I see would be to completely replace the surface tiles, so no degradation.
For example, to have a 1980's shuttle pad at Vandenberg, created from original ground textures and edited terrain.

 

[martins]

Ok, I've started on the PNG export. Check out the 12-png_export branch if you want to follow progress. I'm exporting to 16-bit single-channel (greyscale) format, which seems to be read without problems by the latest Gimp.

I think for now I will implement the 2-file (PNG/meta) solution. It's a bit more cumbersome than embedding everything in a single file, but should make it easier to read the metadata, and hence interpret the info in the PNG, without the need of an additional tool to extract this info from the PNG. It might even make it possible to add metadata to an existing PNG file sourced elsewhere, to allow importing it into tileedit, thus replicating the functionality of plsplit64 for elevation data.

I also noticed that Gimp now supports floating point image formats. This could be a way to get around the problem of including the scale/offset information, by using the true elevation values directly in the image data. However the image formats supporting floating point data that I know of tend to be quite specialised, such as NIFTI or ANALYZE. They may not be very useful in this context, and I don't know if Gimp can read those anyway.

 

[Face]

I think for now I will implement the 2-file (PNG/meta) solution. It's a bit more cumbersome than embedding everything in a single file, but should make it easier to read the metadata, and hence interpret the info in the PNG, without the need of an additional tool to extract this info from the PNG. It might even make it possible to add metadata to an existing PNG file sourced elsewhere, to allow importing it into tileedit, thus replicating the functionality of plsplit64 for elevation data.

I'd like to suggest a format like so: https://www.orbiter-forum.com/showthread.php?p=567125&postcount=208 . If we keep it compatible, people could use ele2png and the tileedit-export/import together. That said, I don't know if there are even users for ele2png anymore :lol: .

 

[martins]

I'd like to suggest a format like so: https://www.orbiter-forum.com/showthread.php?p=567125&postcount=208 . If we keep it compatible, people could use ele2png and the tileedit-export/import together. That said, I don't know if there are even users for ele2png anymore :lol: .

Does your format allow to be extended by additional tags (e.g. by adding more lines after the first)?
I might want to add more info, such as resolution level, latitude and longitude indices (or index ranges, if the PNG is a mosaic of multiple tiles), name of the PNG file, etc.

 

[Nikogori]

Sorry for the noob question... but I don't understand how to use this.

This is what I did so far:

Open tileedit. Select specific region on the map.
Click Action button. Dialog shows up. Click yes.

Draw something on the map... I'm not sure what I'm supposed to do from here.

It seems .elv files have been created. But I couldn't find any differences in game.

 

[martins]

Sorry for the noob question... but I don't understand how to use this.

This is what I did so far:

Open tileedit. Select specific region on the map.
Click Action button. Dialog shows up. Click yes.

Draw something on the map... I'm not sure what I'm supposed to do from here.

It seems .elv files have been created. But I couldn't find any differences in game.

The elevation edits are written as soon as you navigate away from the edited tile. If you switch to a different tile after your edit, then switch back to the edited tile and the edits are still visible, they will have been written. I'll add some visual cue to indicate if a tile contains unsaved edits.

Edits are also propagated to ancestor tiles down to a given depth (currently hardcoded to 5 levels down from the edited tile resolution). However, I suspect that the propagation stops if an ancestor is missing in the chain (I haven't tested that yet). In your case, since you are creating a new tile at level 16, it is possible that the corresponding level-15 tile also doesn't exist, so the edit would be applied to level 16 only. You will only see it in orbiter when the LOD mechanism picks up that tile at exactly the correct resolution. Zooming in and out might trigger that.

Edits are currently not propagated to child tiles, since that could erase existing high-resolution content. I haven't quite figured out if and how to implement that (e.g. highpass-filtering the existing high-res tile, then adding the filtered high-frequency content to the low-frequency edit arriving from the ancestor tile).

Make sure that the tile load preference in Orbiter is set to "Try cache first, then compressed archive", since the edits are always written to the cache.