FSDT releases Switzerland Mesh for MSFS 2020

[mrbump 2]

Funny to see the CGL method shunned - because I would have thought it's the other way round: CGL is the proper solution while heightmaps are a total hack. Yes, CGL is undocumented as of now, so such sceneries will have to be regarded as "experimental" - apart from that this format is the way to go for large scale meshes.

CGL:

It's the format that is used by default. A low resolution version is installed locally, a high resolution version is streamed from the cloud - but this can be prevented if there is a higher resolution CGL installed locally in the community folder.

The CGL contains the lower LODs precalculated/optimized. Render distance is all the way to the horizon.

As this mesh is on a lower level than all terraforming primitives there is no need to create holes for specific sceneries - airport terraforming always has the higher priority. So if there are conflicts - it's the airports fault. Once Asobo will come up with a better mesh from the cloud it will also work like the CGL.

Heightmaps:

The original intent by asobo was probably to provide a slightly more versatile terraforming tool to airport makers. I doubt they ever thought that people would abuse it to plaster over whole countries. And I doubt they would endorse this technique.

Because heightmaps occupy the same level as the terraforming on airports that is where the conflicts happen and therefore why there needs to be holes.

Heightmaps are not really a mesh, they have the ability to modify the underlying mesh but they are totally unaligned to it. I'm therefore also guessing, that both the underlying CGL based mesh and the heightmaps have to be loaded into memory - it's not a replacement.

As the heightmaps are not aligned with the underlying mesh and so the mesh needs to get calculated/modified at runtime. Probably has to be recalculated at the time of an LOD switch.

Render distance is really not that far and very visible for those flying high.

 

 

 

 

[virtuali 4,454]

7 minutes ago, Tomaz Drnovsek said:

10$ for mesh for one country is too much. For a continent of a bigger region, sure, for one country, no way.

I might generally agree, but:

- When you pay for a mesh, most of the cost it's not the actual product, but ( after deducting retailers fees ), the bandwidth used for the installers AND the updates, because we have a Live Update system, so whenever we release an update the mesh, we spend quite a bit of money just to let users download the upgrades automatically, without having to manually install/replace/fiddle with files.

- Switzerland is one specific country where mesh accuracy is very important, not just to "flying over the mountains", but because almost ALL airports are very close to dangerous/interesting terrain. And we had an exceptionally good original data source, and would be a waste not to use it.

- There's an overhead in making ANY commercial product, which makes impossible to price it much lower than 10$.

Regardless how the product is "big" or complex or how much time it took to be made, you still have to create installers, supports users by forum and email for *years* to come, setup payments for the people involved which results in some administrative cost, pay developers fees, pay licensing fees ( in the case, the tools are freeware for freeware products only ). Some retailers, like Digital River, have a minimum fee for that reason, so if you price the product lower than a certain amount, the fee will raise a lot in percentage. Dedicated hosting have additional monthly fees based how much space is used, that is even before users downloads it, so that bandwidth costs will add to it.

Yes, ideally we would be better served by having a single and fairly expensive product, instead of many cheaper ones, because all these overheads costs added just because a new product "exists", will be gone, but sometimes we need to do new things too.

To put things in perspective, 10$ might not be enough to get a single burger here in Switzerland. On a fast food.

[virtuali 4,454]

32 minutes ago, mrbump said:

Funny to see the CGL method shunned - because I would have thought it's the other way round: CGL is the proper solution while heightmaps are a total hack. Yes, CGL is undocumented as of now, so such sceneries will have to be regarded as "experimental" - apart from that this format is the way to go for large scale meshes.

BGL Heightmaps are documented and compiled by the official SDK. .CGL Mesh, instead ARE a "total hack", at least as of today, because the exact file specifications are not documented, and there's no tool in the SDK that can create such files so yes, as you correctly say, elevation .CGL sceneries should be considered experimental, until at least more information is known about them.

 

32 minutes ago, mrbump said:

The CGL contains the lower LODs precalculated/optimized.

Yes, this can be good for performance but, of course, there's the other side of the story, which is the inflexibility of the hardcode names, meaning two sceneries covering the same area with .CGL files will have issues working together.

As usual, you trade flexibility with performances, the more inflexible you are, the more performances you get ( X-plane inflexible 1x1 degree grid has some benefits at the cost of inflexibility )

 

32 minutes ago, mrbump said:

Render distance is really not that far and very visible for those flying high.

Which is not really a problem because, even if the heightmaps are not visible anymore, the underlying lower-level LODs from the .CGL will kick in anyway.

Fact is, heightmaps will show far less terrain morphing than .CGL, and by going around airports ( which we can do easily with .BGL heightmaps ), we completely remove any possible chance to cause problems to airports, which was our main design goal.

We obviously tried the .CGL method too, using the currently available tools. And it simply looked better with heightmaps, both because we could control the final resolution more precisely ( we could make it at 10m, 12m, 14m, 15m, while with .CGL we are limited to multiples of the Bing grid so, it's either 9.5 meters or it's 19, or it's 38, nothing in between ), but also because it shows less visible morphing while flying, in addition to all the other issues of not being able to protect airports, or other sceneries covering the same .CGL tile, and the fact that releasing a commercial product based on experimental tools producing a not fully documented binary file is not my idea of peace of mind.

OF COURSE, if in the near future the .CGL file format will end up to be better documented, if the tools will become less experimental or if official tools will eventually appear, or if a better way to solve conflicts between tiles of the same area will be available, it will be trivial for us to either switch to the .CGL method, or offer it as an alternative installer, same way as we are offering a 20 meter installer as an alternative ( which to me looks just as good ), because most of the work of collecting the data, pre-processing it to merge with bordering countries, resampling it at the correct resolution, has already done, it would become just a matter or outputting it in a different format, so no big deal.

Edited May 27, 2021 by virtuali

[Tomaz Drnovsek 440]

34 minutes ago, virtuali said:

To put things in perspective, 10$ might not be enough to get a single burger here in Switzerland. On a fast food.

I'm not saying it should be free of anything. I'm just commenting on the price to quantity ratio. There a commercial mesh product for P3D for the entire planet for 100$ in up to 1m resolution. In MSFS we're looking more in the 1000$ range for the same area. You can get quite a lot of burgers for that money. Even in Switzerland 😉

 

[GSalden 4,719]

@umberto

Any plans on the complete Alps mesh ?

Since years your products are very good with excellent support.

At Simmarket there is also 5-10-20 mesh for the Alps countries (Taburet) but they have some issues, which is honestly written at the products pages.

So I prefer your approach with leaving the airports out of the mesh.

Edited May 27, 2021 by GSalden

[mrbump 2]

7 minutes ago, virtuali said:

releasing a commercial product based on experimental tools producing a not fully documented binary file

This here is about the only thing I could theoretically agree with were it not for the fact that you completely ignore that your use of heightmaps is well beside their intended use (and I would therefore consider it unsupported).

 

11 minutes ago, virtuali said:

Fact is, heightmaps will show far less terrain morphing than .CGL

That is totally not a fact. If you see "terrain morphing" in let's say ItalyDEM it's because it was built on a an early version of the tool by muumimorko which does downsampling wrong. It has nothing to do with the CGL format.

 

16 minutes ago, virtuali said:

hardcode names, meaning two sceneries covering the same area with .CGL files will have issues working together.

They don't have issues working together if properly done. The way it works (my current theory...) is actually quite logical. In general the local CGL is prioritized. When you get closer and there is a higher LOD in the cloud it will switch to that (per 257x257 tile). So that would allow you to publish a CGL with high resolution Switzerland and low resolution france, where your low resolution france would not overwrite the (world updated) high resolution france from the cloud.

PS: I don't mean this as a personal attack. I just had the impression there was some misinformation in this thread.

[arsenal82 120]

10 minutes ago, GSalden said:

@Humberto

Any plans on the complete Alps mesh ?

Since years your products are very good with excellent support.

At Simmarket there is also 5-10-20 mesh for the Alps countries (Taburet) but they have some issues, which is honestly written at the products pages.

So I prefer your approach with leaving the airports out of the mesh.

taburet mesh use same tool as virtuali and exclude airports areas too

some smaller airport however can be left out - at first release -

[GSalden 4,719]

4 minutes ago, arsenal82 said:

taburet mesh use same tool as virtuali and exclude airports areas too

some smaller airport however can be left out - at first release -

Thanks for explaining.

 

So the Taburet mesh is :

Austria 10m

Swiss 10m

Itaky 5-10-5m

 

The FSDT mesh is :

Swiss 10-20m.
 

It would be good if one could choose 10m for VFR flying and 20m for IFR flying. I guess with using an external Addons folder, like I have now, and Addon Linker, this is possible.

And I am looking for France too.

 

[virtuali 4,454]

41 minutes ago, mrbump said:

This here is about the only thing I could theoretically agree with were it not for the fact that you completely ignore that your use of heightmaps is well beside their intended use (and I would therefore consider it unsupported).

The .CGL format not being documented and with no official tools is the only fact we are sure of.

That Heigthmaps are used outside their intended usage is speculation at best, and calling them "unsupported" is your own opinion.

 

Quote

So that would allow you to publish a CGL with high resolution Switzerland and low resolution france, where your low resolution france would not overwrite the (world updated) high resolution france from the cloud.

Which won't fix the issue if two mesh .CGL of the SAME area have the SAME resolution. Which would lead to the infamous "mesh war" we saw in FSX/P3D.

In order to prevent other mesh to damage their own (either mesh or airports), developers started to create fake up-sampled mesh with nominally higher LODs JUST to prevent other mesh to screw up their products.

We suffered a lot this, as airport developers, so we wanted to be sure to prevent this, as mesh developers.

 

Quote

That is totally not a fact. If you see "terrain morphing" in let's say ItalyDEM it's because it was built on a an early version of the tool by muumimorko which does downsampling wrong. It has nothing to do with the CGL format.

You just made my point. The risk of using experimental tools, which might change their end results at any time, because the format itself is not very well known. 

It's not just the fact it's a file format not fully deciphered with ever evolving tools ( yes, even Paavo Heightmaps tools are ever evolving, but they produce an official XML SDK-compliant code in the end, so they are not nearly as risky as creating a binary file directly ), it's also the issue of two .CGL files of the same tile conflicting, the higher chance to mess with airports, the inflexibility of the grid, so you can't resample at even intervals, but you are forced to use something on the Bing LOD grid, which makes resampling more tricky and prone to resampling artifacts, since if you have data at 1 meter you must resample it at either 9.5546 meters or 19.1093, while with heightmaps we can resample at precisely 10 or 20 meters ( or anything in between ), which makes the downsampling easier because of the even subdivision, without mentioning the better way to circle around airports with holes, since Heightmaps rectangles can be of any size, so they can stay close to airports and still not damage them.

The only thing I agree on .CGL being potentially better, is for straight performances and again, it won't be an issue for us switching to it, provided ALL the unknowns will be fully understood, and possibly a better way to solve scenery conflicts will appear in the sim, something like the old Scenery Library, where uses were allowed to manually set priorities, which is currently just not there in MSFS, which means we MUST try to play safe as possible to prevent conflicts with other sceneries users don't have any means to fix themselves.

Edited May 27, 2021 by virtuali

[virtuali 4,454]

45 minutes ago, arsenal82 said:

taburet mesh use same tool as virtuali and exclude airports areas too

some smaller airport however can be left out - at first release -

That's why we took the time to go in each and every airport in Switzerland, to manually create shapes to protect airport boundaries, even if the airport perimeter itself wasn't already covered by standard OSM layers, because you won't find the smaller airfields there, only the main ones.

Of course, this took a bit of time, otherwise we might have released it earlier. Also, we waited for a *better* version of Pavoo's tools, one that handled airport exclusions more cleverly.

As I've said, as mainly airport developers, we took the issue of being absolutely sure airports won't be ruined, quite seriously.

 

 

Edited May 27, 2021 by virtuali

[Noel 4,572]

Two questions if you will:

1. Will FSDT mesh products be available thru the MSFS Marketplace?
2. Can anyone speak to how mesh affects load on both CPU & GPU?

Thanks

[virtuali 4,454]

15 minutes ago, Noel said:

• Will FSDT mesh products be available thru the MSFS Marketplace?

Yes, we sent them to Microsoft for approval already.

 

Quote

1. Can anyone speak to how mesh affects load on both CPU & GPU?

Everything you add to the sim affects your system in some way. Anybody selling a product and telling you it has "no effect" on performances is not honest.

The mesh resolution is what impact performances the most but, of course, it depends on your LOD terrain slider, the higher you go, the most you'll have some impact on performances. Which doesn't necessarily mean "framerate", mostly it's RAM or VRAM taken so, if you have plenty of it, it will affect you less.

With .BGL-based mesh, we have some flexibility to work with. For example, having an entire country in a single .BGL will result in more RAM taken, and this is measurable but, doing the opposite and splitting a country in too many small .BGLs will also have a detrimental effect, so after several tests, we settled to a reasonable figure we were happy with, covering the whole of Switzerland with 27 .BGLs, which seemed to be a good compromise between a single .BGL and many smaller ones. We have an automated tool we wrote that makes testing different solutions very easily.

I think the 20 meters version is good enough for all purposes, we made the 10 meters version just because other developers did and, since most users don't follow detailed discussions about source data, resampling or even-spaced resampling, we were basically forced to create a 10 meter version for marketing reasons, but I personally use the 20 meters version, which looks almost as good, and takes 1/4th of the space.

Edited May 27, 2021 by virtuali

[mrbump 2]

Look, this doesn't have to be a pissing contest and I'm totally fine with you and others making money on heightmap sceneries generated with Paavo's tools. I just wish these developers would be more informed and then upfront about the technique they're using.

This is from Paavos documentation: (but he's obviously also just speculating)

Quote

Warning
The way MSFS implements height maps suggests that they are intended for smaller areas, such as for adding a hill or fixing a slope. While the same approach also works for very large areas, this may not be future-proof.

 

So with all that misinformation I read in this thread I just had the urge to jump in. No harm intended.

Full disclosure:

I'm working on my own CGL tool based on muumimorkos documentation and improved with my own research. My goal is to mainly improve a few meshes to bridge the time until they are officially world-updated. Whatever I may be releasing will be Freeware/CC so I don't have a financial stake in this discussion.

I use Paavo's tool to get even finer detail as part of airfield sceneries (small areas, as they were intended for).

But for all I care plaster the whole world with heightmaps, buy it, download it, be happy with it if it works for you. But don't spread misinformation!

[Nyxx 6,994]

17 minutes ago, mrbump said:

 But don't spread misinformation!

Well we dont know who you are, do we. But you are calling one of the most respected developers we have ever had for countless years. So I would be careful as he is one of the most open/helpfull also, and you are? ....what some hobbyist that knows better? really!

Edited May 27, 2021 by Nyxx

[virtuali 4,454]

13 minutes ago, mrbump said:

This is from Paavos documentation: (but he's obviously also just speculating)

 

 

Everybody is speculating here. That's the only thing "in doubt" about Heightmaps, but there are many more unknowns in the .CGL method.

As I've said, we'll won't waste any time switching to it, provided ALL the issues I mentioned will be finally understood. It's not that we married to Heightmaps. Our first and foremost design goal was to be sure we won't disrupt airports (even our own! ), and that's extremely easy to achieve with Heightmaps.

 

13 minutes ago, mrbump said:

So with all that misinformation I read in this thread I just had the urge to jump in. No harm intended.

There wasn't a single bit of misinformation here.

That .CGL is experimental, undocumented, with no official tools, tricky with solving conflict with other sceneries, inflexible in the resampling resolution chosen ( forcing to use uneven resample values ) is a fact.

That Heightmaps are an official part of the SDK and are way easier to setup in a way they *cannot* conflict with airports (if there's no rectangle there, it cannot cause troubles...) it's also fact.

The only speculation here, is they MIGHT not be the intended tool for larger scale regions. That's why we started with a fairly small country, one that has so much interesting terrain, and so many airports so close to mountains and in valleys they are at risk of being disrupted, so it was the ideal candidate.

It's also possible that, if many sceneries will use Heighmaps for larger regions, and those will also be sold on the MS Marketplace, it might be a good incentive for Asobo to improve/optimized them even further.

Conversely, if something doesn't work with a .CGL-based scenery, we shouldn't expect any help from Asobo, at least not until AFTER they'll release some official tools in the SDK.

Edited May 27, 2021 by virtuali