W.I.P. Tool for creating Elevation using Rectangles

[FoxtrotScenery]

For example, a .geotiff with a resolution of 1m, which is 418 MB for 76 km2, will result in the creation of around 4,277 “Rectangle Objects” with FSD->Elevation Editor, which by default creates tiles in 128/128. The .XML file is around 1.36 MB, which after compilation with fspackagetool will give a .BGL file of 130 MB.

Yes it's one of the many annoying features of the XML format and terraforming rectangles: the elevation data is stored as characters. Inherently, if you go beyond 4 characters to store the data in XML, you're storing more data than storing the raw 32 bit floating point value (even ignoring losless compression available in image formats). I want to add some extra features to improve the file sizes though, since the tool will now create unnecessary rectangles in some situation.

It would be great if it were possible to select multiple rasters.
Then, if possible, create the XML file(s) with the templates needed for compilation with fspackagetool.

Definitely, it's on the todo list and the new backend I've written actually supports this and it should also be included in some future update (whenever that may be )

For one or two .BGL files of this size over a small area of 2 x 76 km², the simulation still loads quickly, but for a larger area of 12 BGL files, or 912 km², loading takes several minutes, and when using the fast movement of the “CAMERA DEV,” the correct appearance of the new altitude data is excessively slow, which leads me to believe that we unfortunately do not yet have the right tool (Terraforming Rectangles) to start compiling large areas more accurately than streamed data.
I dare not believe that the native MSFS 2024 and 2020 elevation data is generated using the “Terraforming Rectangle” tool; it's not possible.
But fortunately, we can still create it using FSD->Elevation Editor.

Yes I definitely agree, this tool was merely created because I would not dare touch CGL files at that point in time, and I needed something to create elevation data in game. That being said, it's sad that Asobo haven't yet released any terrain editing capabilities to MSFS2020 since its creation. Although MSFS20204 now support biome editing, so maybe we're heading in the right direction?

Also, after testing 50 cm and 1 m data, it appears that the maximum resolution of MSFS 2024 elevation data is 1 m, as 50 cm adds nothing but larger files (*4).

This is definitely the limit in terms of resolution, MSFS uses the same underlying tile system as bing does, and it's limited to level 18 or 17 for mesh resolution if I recall correctly.

Otherwise, on MSFS 2020-2024 and under low-angle lighting, there is indeed some tile overlap, which is very annoying, although the falloff set to 1 m could be entirely satisfactory because beyond 1 m the overlap is much worse. Perhaps you should test an .XML with the “Priority” of the rectangles all set to a single value (0) to improve the rendering, or maybe try another tile size, 256*256 or more, to limit overly tight grid spacing.

I am familiar with that issue, and it's one of the reasons I rewrote a lot of the backend on how things are done, including looking at how the underlying bing maps tile system works. I hope the next update actually adresses this issue, but it's not finished yet. That being said, I cannot test this in MSFS2024 anyway since I haven't bought it yet.

Great that you are able to use the tool though! Looking forward to seeing what you've made with it!

 

[GaryGB]

It would be great if it were possible to select multiple rasters.
Then, if possible, create the XML file(s) with the templates needed for compilation with fspackagetool.

<?xml version="1.0" encoding="utf-8"?>
<FSData version="9.0">


</FSData>


Some observations regarding file size after my numerous tests:

For example, a .geotiff with a resolution of 1m, which is 418 MB for 76 km2, will result in the creation of around 4,277 “Rectangle Objects” with FSD->Elevation Editor, which by default creates tiles in 128/128. The .XML file is around 1.36 MB, which after compilation with fspackagetool will give a .BGL file of 130 MB.

For one or two .BGL files of this size over a small area of 2 x 76 km², the simulation still loads quickly, but for a larger area of 12 BGL files, or 912 km², loading takes several minutes, and when using the fast movement of the “CAMERA DEV,” the correct appearance of the new altitude data is excessively slow, which leads me to believe that we unfortunately do not yet have the right tool (Terraforming Rectangles) to start compiling large areas more accurately than streamed data.
I dare not believe that the native MSFS 2024 and 2020 elevation data is generated using the “Terraforming Rectangle” tool; it's not possible.
But fortunately, we can still create it using FSD->Elevation Editor.

Also, after testing 50 cm and 1 m data, it appears that the maximum resolution of MSFS 2024 elevation data is 1 m, as 50 cm adds nothing but larger files (*4).

It should also be noted that fspackagetool does not seem to accept .XML files = or > 2 GB at all, as compilation crashes. Therefore, it is important to avoid .geotiff files larger than 450 MB, and if your .Xml file is = or > 2 GB, there is no point in even trying to compile it.

Otherwise, on MSFS 2020-2024 and under low-angle lighting, there is indeed some tile overlap, which is very annoying, although the falloff set to 1 m could be entirely satisfactory because beyond 1 m the overlap is much worse. Perhaps you should test an .XML with the “Priority” of the rectangles all set to a single value (0) to improve the rendering, or maybe try another tile size, 256*256 or more, to limit overly tight grid spacing.

Thanks for this tool already!

Translated with DeepL.com (free version)

This is definitely the limit in terms of resolution, MSFS uses the same underlying tile system as bing does, and it's limited to level 18 or 17 for mesh resolution if I recall correctly.

I believe that in time, it will become clear that MSFS' run time Terrain sub-system is capable of resolving up to a full Zoom level 21.

GaryGB

 

[NovembreFox]

Hello,

Microsoft/Asobo has launched a survey among MSFS developers. I think many of you are already aware of this, but if not, don't hesitate to participate and ask for a tool to create DEM and Aerial for large areas, similar to what our FSX “resample” did so well. In any case, that's what I just did.

https://devsupport.flightsimulator.com/t/microsoft-flight-simulator-developer-survey/16709

NF

 

[lazaro]

Translating is one thing; allowing an AI app to search, interpret, and explain is something else entirely.

I recommend Google Translate which started out with limited skills, and is now very good at translating content into a target language:

https://www.google.com/search?q=tra...BwE5uAfiBcIHBTItOS4yyAc5&sclient=gws-wiz-serp


Please do not take my critique too much to heart, as my admonishment is primarily directed at clueless geeks that code AI apps.

And you may note I use my own fair share of abbreviations gleaned from the Inter-Web; but hopefully I'll never slip into using "thx".


I would much rather sleep peacefully knowing that you are also sleeping peacefully; most of my post was an attempt at humor.


I encourage participation here even if English is a second language; Arno, Thorsten, Christian Bahr etc. became very proficient over time.

https://www.fsdeveloper.com/forum/threads/sound-effects.424400/post-800007


"FTSEE" may be a useful abbreviation for FoxTrotScenery's “Elevation Editor”, just as 'MCX' became used for Arno's ModelConverterX.

GaryGB (aka "ChatGGB" )

Not to derail the conversation here, but DeepL is a very reputable tool and company, far away from being "clueless AI geeks". They have been around for a while before the whole "AI" craze. It produces great translations and is even better than G-Translate (imho)
They are also a german company, so no silicon valley hype bulls***