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.
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.
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.
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.
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:
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
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
Creating a CGL Area Mesh: Challenges and Solutions
Currently, creating CGL area meshes in Microsoft Flight Simulator 2024 presents significant difficulties. Here is an analysis of the situation and some workarounds:
Limitations of the CGL Format: Creating meshes in CGL without an official SDK from Microsoft/Asobo Studio and without a dedicated tool is currently not a viable option. Tools like MSFS2020_CGLTools only allow you to work up to level of detail 12. However, if the simulator outputs mesh data in CGL at higher levels of detail, these will overwrite the custom mesh data.
Heightmap Terraforming: The heightmap terraforming method remains 90% effective in FS2024. However, the corresponding SDK does not offer satisfactory tools for handling large areas. This approach is recommended for limited areas. Furthermore, the freeware application (MSFS Toolkit) that previously facilitated this operation is no longer available.
Future Outlook: Although the current situation presents obstacles, there is room for improvement. Community involvement could incentivize Microsoft/Asobo to improve the SDK or release more suitable tools. With determination and knowledge sharing, some results are still achievable.
I would like to share some observations regarding the usage and implementation of the manifest.json file, especially regarding two attributes that I consider fundamental:
“package_order_hint”: “CUSTOM_WORLD_SCENERY”
For example, the files listed under the key
“globally_overriden_base_sim_files” are correctly indicated, as follows:
Despite these configurations, it seems that the declared options are not fully implemented or working as expected. I believe that with targeted intervention, it would be possible to achieve significantly better results.
If these attributes behaved, literally, as they are written, that might be the solution.
@ClevererElm8055 For clarification:
There’s no way to convince MSFS2024 to reader other CGL files than secondary aerial imagery files, correct?
I’ve had some success by placing default veg*.cgl files into another a folder with different QMID number for the folder and filename having it pop up in another region a few weeks ago.
Even that doesn’t seem to be possible anymore and MSFS2024 only reads DEM, vegetation mask, vector data etc. CGL files from the cloud.
