Creating the terrain mesh with .cgl files. Problem with Priority of .CGL Files to CGL_Azure(DEM)

[ClevererElm8055]

Hi all, I’m currently working on creating a terrain mesh using the .cgl file

Given that:

• The file was created by a freeware program that is a few years old and may be incomplete.
• The scenario is successfully registered and mounted inside the MSFS 2024 scenario library.
• I’m not sure if the scenery renders correctly inside the simulator.
• I am aware that the Microsoft Asobo team does not favor this type of scenario and that the documentation may not be detailed enough.

As you can see in the image below in MSFS version Beta 1.3.10.0 the .CGL was correctly rendered.

I upgraded to Beta 1.3.13.0 and the same dem112.cgl file is no longer rendered, at least it should be since at various levels the cgl file is the one from CGL_Azure.

Are there any special precautions or steps to follow to ensure the terrain mesh renders correctly?

Question
Is there an official way to prioritize a local .CGL file over Azure DEM data (CGL_Azure)?
Is there an option to force MSFS to use the local .CGL file exclusively, without completely disabling streaming?

If someone from the ASOBO team can clarify the behavior of loading .CGL files, it would be a great help for developers who want to customize the DEM.

Thanks in advance for your support!

[GodzoneVF]

I did come here to report a similar issue with aerial CGLs, but I’ll combine it with this post for the moment.
I’ve built a number of custom airports, for MSFS2020 and now converted for 2024, and my custom aerial CGLs have worked well up until the beta. I joined the beta a few days ago, so I haven’t been involved for long. Now none of my aerial images show up. These are all built to the SimpleAerial specs, all using LOD20 imagery.
Any ideas why they no longer appear? I did report this as a beta bug, as I consider it a regression – it worked before the beta but not after – but my post was moved, and I was asked to report it here.

[GodzoneVF]

I’m pretty sure there is nothing logged. I did log a SP1 regression bug on the MSFS forum, but was asked to bring it here. Yes, I probably should have logged it here, but I decided to wait until SP1 drops and the dust settles. Feel free to log it.

[SPQR]

The answer to this is straight forward and there will not be any change to it as it goes up to these days; if Azure have an higher lod mesh is the priority mesh. Any cgl mesh you might make can become obsolete without any warning; as azure mesh get updated; or manipulated my Ms.

[Sasa]

It may be related to this as CGL files in general seem to be affected, including those created through the SDK tools.

Which of course doesn’t include DEM CGLs as they’re not supported by the SDK but I assume the logic behind the whole thing is similar:

SU1 beta graphic bugs with CGL imagery

Version: 1.3.13.0 Frequency: Consistently Severity: High Marketplace package name: Aerosoft EDDB Bug description: Overlay layer “peeling up” around the aircraft when moving around CGL imagery + jagged borders between CGL and default imagery, particularly at locations where the color is quite different. Had this reported by testers but couldn’t replicate till I installed SU1 beta. Tried TIN on/off, doesn’t have an impact. [image] [image] [image]

https://forums.flightsimulator.com/t/grass-textures-issue-on-custom-airports/706541

[ClevererElm8055]

Dear community members,
I have been waiting for SU1 to discuss this topic, as the MS/Asobo team has done an amazing job in fixing the multitude of bugs found. Thanks to them for their efforts! However, I would like to bring attention to a topic that, in my opinion, does not receive the right attention in our community: the terrain mesh.

Procedure followed to set a higher priority to the DEM/CGL:
The source DEM data used has a resolution of 10m (8.50 horizontal spacing X 10 vertical spacing). The manifest.json file was configured as follows, trying to consider relevant parameters, but without achieving the desired result:

• “package_order_hint”: “GENERIC_SCENERY_PATCH”,

• “globally_overriden_base_sim_files”: [

  “https:\sunriseworld.akamaized.net\sr-results\dem_lossless_2024_11_04\dem\122\dem11221.cgl?version=3”,
  “https:\sunriseworld.akamaized.net\sr-results\dem_lossless_2024_11_04\dem\122\dem11222.cgl?version=3”,
  “https:\sunriseworld.akamaized.net\sr-results\dem_lossless_2024_11_04\dem\122\dem11223.cgl?version=3”
  ]

Despite the attempts, the system does not seem to prioritize the DEM/CGL file as expected.

Perspectives and alternatives:
If no answers or solutions emerge from the MS/Asobo team, I will continue to create the terrain mesh using the terraforming/BGL method, even if I would prefer to avoid this less practical solution.

What do you think? My intent is not polemical, but constructive: I believe that a discussion on this topic can benefit our simmer community.

Regards.

PS: Two shots of how the default terrain mesh can change
Default

Enhanced Terrain Mesh

[JonRainmanATC]

What even is the method of creating these with CGLs?

I had a method in FS2020 to do it with terraforming rectangles, but that’s entirely BROKEN in FS2024 because of the hard falloff between adjacent rectangles.

It seems it’s near impossible to properly terraform an area even the size of an airport with nice mesh data