1 hour ago, Baber20 said:

Doesn't look all that impressive to be honest. I will stick with default for now and wait for Asobo to fix the morphing issues.

LOL you will be waiting a long time.

44 minutes ago, AnkH said:

Quiet beautiful, yes, but the mountains in Switzerland are barely recognizable without addon mesh. If that is fine for you...

Yes, it's ok with me, I don't mind at all.

I suspect Asobo will eventually will address mesh issues, so I rather wait then to spend $$$ on alternative products. Patience is a virtue!

 

Some impressions

 

Default vs. 10m mesh

August:

November:

10m mesh:

August:

November:

10m mesh:

 

 

 

It makes a huge difference. If you're familiar with the region this is absolutely worth it. Finally the mountains look like they should. Moreover, there's harldy any more morphing (if any). Now we only need better imagery and less „roundedness“. Still not perfect but a vast improvement.

Edited May 25, 20215 yr by Shack95

1 hour ago, HighTowers said:

Interesting since a freeware 20m mesh recently released as well.  Wonder how different a 10m and 20m mesh is. 

Please don't look at the nominal resolution as it was the only factor which affects quality and usability of a mesh, because the resolution alone doesn't tell the whole story.

- The freeware Switzerland mesh, according to the description page, has been taken from this original data source of 20 meters:

http://data.opendataportal.at/dataset/a949dd6f-9f19-4727-872c-b70d35adb550

Our mesh, which is available in both 10m and 20m resolution, has been downsampled from an original 1m source so even at the same "nominal" resolution, the quality is higher, because extra detail can be retained.
 

- The freeware Switzerland mesh uses .CGL files. If you follow the discussion on fsdeveloper.com, there are lots of unknowns about this format, because there's no SDK for it, the tools that create .CGL files create binary files directly, using the limited information that has been discovered by reverse-engineering until today.

Our mesh use a completely different method, Heightmaps, which are not only fully documented, but they are also compiled by the SDK itself, because they starts as standard XML source files in the official SDK format.

Also, there's an inherent issue when using .CGL files, that no two .CGLs for the same area ( and the area is quite big, the whole of Switzerland is covered by a single file ) can be installed in the sim, because they will conflict with each other, because the naming convention is forced. .CGL files are used for both mesh scenery *and* photoreal scenery, which also means if you have a mesh made in .CGL format and a photoreal scenery also made in .CGL format for the SAME area, you'll have to choose which one to keep. So, for example, if you have the freeware Switzerland mesh installed, and somebody would release a photoreal scenery of, let's say, Zurich or Geneva, either the mesh or the photoreal would work, but not both, because they *must* have the same filename.

Another issue, which I'm sure you have already seen in other mesh products that has been released recently ( also using the .CGL method ), is that a .CGL mesh must be contiguous in its own coverage, it cannot have "holes". This means, it will cover airports so, anything can happen around airports, some of them might be completely ruined, unless there's some cooperation between the mesh and the airport developer.

Since we made so many airports that got ruined by 3rd party mesh in the past, we took great care about ensuring this won't happen. So we processed the mesh to not cover anything that falls inside the airport perimeters of the country, which is fairly easy to do with the Heightmaps .BGL method we use, because it's enough to just not create data there, due to the different data structure.

In fact, the freeware tool ( which we obviously licensed commercially ) to create such kind of mesh, which you can find at fsdeveloper, made by the very talented Paavo, has been recently updated with such function, following our suggestion., this post have a very easy to understand image which explains why using this method we cannot mess up other airports:

https://www.fsdeveloper.com/forum/threads/msfs-toolkit-by-nool-aerosystems.452363/post-882661

 

Doing this in FSX or P3D was impossible, because such "hole" would be visible but Heightmaps in MSFS have a blending factor that helps with the transition between the mesh and the rest of the scenery.

About resolution, while the original data source is at 1m, the downsampled version at 20m is already so good ( because the original was way better ), that I don't find to be really necessary to use the 10m version, we only provided it for marketing reasons, because most users only look at the nominal resolution, but I think 20m is just fine.

We tried 5 meters, and the only result was we took 4 times more disk space and RAM compared to 10m (16 times more than 20m), for an almost no benefit when flying, unless you tried to get so close to a mountain you would already crashed into it.

Going as low as 1/2 meters ( and yes, we have original data sources up to 0.5 meters in Switzerland! ) is insane, and I would use it only for VERY specific reasons, like terraforming a single ( small ) airport, because the space and memory requirements are absurd, at least for large areas.

Edited May 25, 20215 yr by virtuali

@Shack95 Many thanks for the comparisons!

@virtuali Thanks for the insight! Can you also talk about what you did to reduce the terrain morphing, and whether it would be possible for Asobo to adapt a similar technique?

2 hours ago, Baber20 said:

Doesn't look all that impressive to be honest. I will stick with default for now and wait for Asobo to fix the morphing issues.

39 minutes ago, CarlosF said:

I suspect Asobo will eventually will address mesh issues, so I rather wait then to spend $$$ on alternative products. Patience is a virtue!

As a heads-up, it was clear from the last Q&A that Asobo were not aware of the terrain morphing, and that other mesh issues (like the coastline glitch and mountain seams) are low on their priority list. I wouldn't expect a fix in the foreseeable future.

It's great to see that mesh add-ons are coming to life in the recent weeks. But 'm not yet sure that I will jump onto the mesh for money wagon.  30(?) € for the European Alps + ? € for the Canadian Rockies + ? € Himalaya, 15 € NZ, Pyrenees, South American Andes ... that sums up to a fair amount of cash and disk space.

Edited May 25, 20215 yr by Nemo

@virtuali if .cgl meshes can not contain holes, I wonder why those meshes on flightsim.to do in fact exclude many if not most addon airports correctly without resulting in display issues? According to your post, this should be not possible, yet it is...

24 minutes ago, ChaoticBeauty said:

As a heads-up, it was clear from the last Q&A that Asobo were not aware of the terrain morphing, and that other mesh issues (like the coastline glitch and mountain seams) are low on their priority list. I wouldn't expect a fix in the foreseeable future.

Yes, it just defies belief - I have to think they must fly / test their own version that doesn't have these problems. 

You can spot it a easily and it is very distracting, just like the white spinner in the bottom right corner of the screen (note: this seems to be reduced when clearing the console messages in dev mode, so hopefully fixable as well. I just wish they could completely turn it off).

47 minutes ago, virtuali said:

The freeware Switzerland mesh uses .CGL files.

No it does not. Troglodytus uses the same method that you use.

The italian freeware mesh that also covers the entire alps with Switzerland included, that one uses the CGL method.

Edited May 25, 20215 yr by Farlis

3 minutes ago, AnkH said:

if .cgl meshes can not contain holes, I wonder why those meshes on flightsim.to do in fact exclude many if not most addon airports correctly without resulting in display issues?

There are two meshes for Switzeland available on flightsim.to, one is part of the Alps, which is made as .CGL, another one is just Switzerland and it's made using the same method we used, that's why that one has probably managed to protect airports.

Looking at the comments for the OrbX NZ Mesh, which is also made as .CGL, it seemed the main problems were elevation issues at airports, so we wanted to be sure this couldn't happen, that's why we asked Paavo to add that feature to its tool, because it would solve the problem at its root. Since this is a freeware tool ( meaning only commercial developers have to pay for it ), we obviously expect other freeware products would benefit for it too.

5 minutes ago, Farlis said:

No it does not. Troglodytus uses the same method that you use.

That wasn't the freeware mesh I was referring to. I was referring to this one:

https://flightsim.to/file/5552/italydem

Which contains the whole of Switzerland too and IT IS made as .CGL. As I've said, the method used by us Troglodytus, allows to exclude airports, because the free tool that creates such kind of .BGL-based Heighmaps, has added this feature very recently, because we asked for it.

Edited May 25, 20215 yr by virtuali

32 minutes ago, ChaoticBeauty said:

are low on their priority list. I wouldn't expect a fix in the foreseeable future.

That is fine, I have no problem with the mesh as it is now, besides, the more detail the mesh I'm afraid my system will be taxed to its limits, yielding stutters when flying around mountains. This sim runs quite fine as it is now, I'm a happy camper even with its shortcomings.

38 minutes ago, ChaoticBeauty said:

Can you also talk about what you did to reduce the terrain morphing, and whether it would be possible for Asobo to adapt a similar technique?

We haven't done anything special, it's likely the LOD handling of .BGL Heightmaps is different than the one in .CGL, which is what the sim by default use. So, in a way, Asobo might already "fixed" it, because we are using a 100% fully SDK-documented method.

Doing meshes is not rocket science, the end result quality is mostly due to:

- The original data source. We are lucky to have extremely good data for Switzerland, which is even free to use for commercial purposes.

- Knowing your way with GIS software.

- Having good automated tools, like the one from Paavo at fsdeveloper.

- Knowing what you can possibly mess up. Airports. As airport developers, we think to be fairly aware of these issues.

Edited May 25, 20215 yr by virtuali