ModelconverterX MSFS2024 object

[grissven]

I Just made a compile of a model library with 3 models, I am sending you the Textures and the BGL, hope it helps

One drive Link
Model Library for Arno

 

[arno]

Thanks, I'll download it and have a look.

 

[rhumbaflappy]

It appears that all models and textures compiled by MSFS 2024 are encrypted, as shown by the above examples.

 

[arno]

The KTX2 texture format seems to be an open format, I have found the specification. Not sure if inside it can be encrypted.

As for the BGL file, I still need to check why they are not read. If they are encrypted that would be good news on one hand, but annoying on the other

 

[Azrsim]

The KTX2 texture format seems to be an open format, I have found the specification. Not sure if inside it can be encrypted.

As for the BGL file, I still need to check why they are not read. If they are encrypted that would be good news on one hand, but annoying on the other

Could be a settings thats either enabled or disabled in the blender to MSFS2024 exporter.

To my knowledge it could be that it gets encrypted if there is a author name to the exported MSFS2024 object.


Verzonden vanaf mijn iPhone met Tapatalk

 

[arno]

I don't think it is the Blender exporter, it's more likely something in the packager tool. If it can be configured is something to find out

But I think many commercial developers will be happy to have their work encrypted, as that can reduce piracy.

 

[rhumbaflappy]

Here's the ktx info output from LGS-FOUNTAIN_BOTTOM.PNG.KTX2

Validation successful

warning-7010: Custom key in Key/Value Data.
Custom key "ASOBO_flags" found in Key/Value Data.
warning-7010: Custom key in Key/Value Data.
Custom key "ASOBpacities" found in Key/Value Data.
warning-7010: Custom key in Key/Value Data.
Custom key "ASOBO_transp" found in Key/Value Data.
warning-7010: Custom key in Key/Value Data.
Custom key "ASOBOtexversion" found in Key/Value Data.

Header

identifier: «KTX 20»\r\n\x1A\n
vkFormat: VK_FORMAT_BC1_RGBA_UNORM_BLOCK
typeSize: 1
pixelWidth: 1024
pixelHeight: 1024
pixelDepth: 0
layerCount: 0
faceCount: 1
levelCount: 11
supercompressionScheme: KTX_SS_NONE
dataFormatDescriptor.byteOffset: 0x158
dataFormatDescriptor.byteLength: 44
keyValueData.byteOffset: 0x184
keyValueData.byteLength: 168
supercompressionGlobalData.byteOffset: 0
supercompressionGlobalData.byteLength: 0

Level Index

Level0.byteOffset: 0x2ace8
Level0.byteLength: 524288
Level0.uncompressedByteLength: 524288
Level1.byteOffset: 0xace8
Level1.byteLength: 131072
Level1.uncompressedByteLength: 131072
Level2.byteOffset: 0x2ce8
Level2.byteLength: 32768
Level2.uncompressedByteLength: 32768
Level3.byteOffset: 0xce8
Level3.byteLength: 8192
Level3.uncompressedByteLength: 8192
Level4.byteOffset: 0x4e8
Level4.byteLength: 2048
Level4.uncompressedByteLength: 2048
Level5.byteOffset: 0x2e8
Level5.byteLength: 512
Level5.uncompressedByteLength: 512
Level6.byteOffset: 0x268
Level6.byteLength: 128
Level6.uncompressedByteLength: 128
Level7.byteOffset: 0x248
Level7.byteLength: 32
Level7.uncompressedByteLength: 32
Level8.byteOffset: 0x240
Level8.byteLength: 8
Level8.uncompressedByteLength: 8
Level9.byteOffset: 0x238
Level9.byteLength: 8
Level9.uncompressedByteLength: 8
Level10.byteOffset: 0x230
Level10.byteLength: 8
Level10.uncompressedByteLength: 8

Data Format Descriptor

DFD total bytes: 44
Vendor ID: KHR_DF_VENDORID_KHRONOS
Descriptor type: KHR_DF_KHR_DESCRIPTORTYPE_BASICFORMAT
Version: KHR_DF_VERSIONNUMBER_1_3
Descriptor block size: 40
Flags: 0x0 (KHR_DF_FLAG_ALPHA_STRAIGHT)
Transfer: KHR_DF_TRANSFER_LINEAR
Primaries: KHR_DF_PRIMARIES_BT709
Model: KHR_DF_MODEL_BC1A
Dimensions: 4, 4, 1, 1
Plane bytes: 8, 0, 0, 0, 0, 0, 0, 0
Sample 0:
Qualifiers: 0x0 ()
Channel Type: 0x1 (KHR_DF_CHANNEL_BC1A_ALPHA)
Length: 64 bits Offset: 0
Position: 0, 0, 0, 0
Lower: 0x00000000
Upper: 0xffffffff

Key/Value Data

ASOBO_flags: [66, 73, 76, 73, 78, 69, 65, 82, 0, 67, 79, 77, 80, 82, 69, 83, 83, 73, 79, 78, 0, 77, 73, 80, 77, 65, 80, 0, 82, 69, 68, 85, 67, 69, 95, 76, 69, 83, 83, 0, 80, 76, 65, 84, 70, 79, 82, 77, 95, 70, 79, 82, 77, 65, 84, 0]
ASOBpacities: null
ASOBO_transp: [0]
ASOBOtexversion: [1, 0, 0, 0]
KTXwriter: ASOBO_FlightSim

11 mip levels (apparently), FORMAT_BC1_RGBA_UNORM, and uses custom Asobo keys. KTX extract fails because of the custom keys.

https://github.com/KhronosGroup/KTX-Software/releases/tag/v4.3.2

 

[arno]

I'm looking at the MDL data now, the GLB section is now GLBZ, so I think the data is zipped somehow. Just need to find out in which way now.

 

[arno]

Hi Dick,

No, the texture files are not encoded or so. You can safely ignore those warnings about the ASOBO keys/values. With the KTX2 tools you can extract the raw data of each mipmap. After decompressing that with my DXT decompressor I got this image out (which seems convincing to me):

 

[grissven]

Hello, I continued to make more testing and found out that its nesesary to add levels of detail to the models, it seems that the more levels of detail you add the distance increases before the models dessapear, I never had this problem before with any of the previous simulators, like FSX or P3D, I thought level of detail was nesseary in the past for rendering reasons because 15 to 20 years ago computers were not as powerful as todays so I remeber reading somewhere that adding level of detail to models was no longer needed, but I think that with 2024 is nesseary because of the fact all scenery is being streamed

 

[Azrsim]

Hello, I continued to make more testing and found out that its nesesary to add levels of detail to the models, it seems that the more levels of detail you add the distance increases before the models dessapear, I never had this problem before with any of the previous simulators, like FSX or P3D, I thought level of detail was nesseary in the past for rendering reasons because 15 to 20 years ago computers were not as powerful as todays so I remeber reading somewhere that adding level of detail to models was no longer needed, but I think that with 2024 is nesseary because of the fact all scenery is being streamed

Yeah but the issue is that its dynamic LODs, so from 10m distance you are going to see a broken model from the cockpit.

We cant adjust or change the values of “LOD min size” in the XML anymore, well we can but it doesn’t work.

Meaning that we need to remodel everything what we have made also in multiple sizes.

I’ve gotta say this “dynamic lod” is the most dumbest and biggest useless thing Asobo has given us.


Verzonden vanaf mijn iPhone met Tapatalk

 

[Azrsim]

Recently in MSFS2024 there is this new feature called “dynamic lods”

As a scenery developer if we want to port over our work from MSFS2020 to MSFS2024, we need to “optimize” our models to MSFS2024 standards

Well to optimize them we need to work on LODs, and working on them via the MSFS2020 manual by adjusting the “min size” values was and is the only best way.

In MSFS2024 however, this is not working anymore. Everything is going now “automatic” now this dynamic LODs feature is based on amount of vertex. We have to chop our models in to so many pieces that it will look horrible from the cockpit from 10m away.

So the decimate feature in blender and modelconverterx are of no use anymore, because we need to seperately remodel EVERYTHING but in multiple med/low poly levels to make it look good from the cockpit from 10M-20M away. Lets say its possible we waste a year on porting over sceneries to work on it in MSFS2024. It will still look horrible from the cockpit from 10M away.

Is there any news or any way we as developers can tell to Asobo to give us the option back on manual LODs? maybe signatures or maybe contacting them? Because this is super frustrating for me since I work behind the scenes on many other intl big projects.


Verzonden vanaf mijn iPhone met Tapatalk

 

[Y.A.G]

Same thing here,


Updating my Kuwait Airport scenery for MSFS2024 using the SDK has caused critical issues due to the new dynamic Level of Detail (LOD) system:


1. Visibility Issues: Objects without assigned LODs (LOD = 0) disappear at close distances (e.g., the control tower is no longer visible from the runway). In MSFS2020, these objects remained visible from far distances.
although ive decreased vertexs it started looking ugly i even reaches 7 lod for one model but couldn’t release it due to its crumbled appearance.

2. Editing Breaks Compatibility: Adding MSFS2024 features (e.g., ground textures, vegetation) disrupts existing objects and forces rework.


3. Impractical Workload: Rebuilding LODs for every object in my scenery would take over a year, making the process unfeasible for small or legacy sceneries.


These would make porting easier:

1. Legacy LOD Option: Add a toggle to allow custom objects to use the MSFS2020 LOD system.


2. Default Visibility for LOD 0: Ensure objects without assigned LODs remain visible from far distances, as in MSFS2020.


3. Non-Destructive Editing: Allow seamless integration of MSFS2024 features into existing MSFS2020 sceneries without breaking object visibility.

Would appreciate help.

 

[arno]

Hello, I continued to make more testing and found out that its nesesary to add levels of detail to the models, it seems that the more levels of detail you add the distance increases before the models dessapear, I never had this problem before with any of the previous simulators, like FSX or P3D, I thought level of detail was nesseary in the past for rendering reasons because 15 to 20 years ago computers were not as powerful as todays so I remeber reading somewhere that adding level of detail to models was no longer needed, but I think that with 2024 is nesseary because of the fact all scenery is being streamed

Using levels of detail to reduce the amount of details that have to be drawn in the distance is always a good idea of course. It makes no sense to render a 20000 polygon objects at 20 km distance, since you will only see it as a few pixels on screen. That was true 20 years ago, but is still true today as well. So with complex models, it is always good to add LODs to reduce the load they give on the system when drawn in the distance.

 

[rhumbaflappy]

Hi Dick,

No, the texture files are not encoded or so. You can safely ignore those warnings about the ASOBO keys/values. With the KTX2 tools you can extract the raw data of each mipmap. After decompressing that with my DXT decompressor I got this image out (which seems convincing to me):

Do you think you could work up a program to convert .ktx2 to PNG?

 

[arno]

Do you think you could work up a program to convert .ktx2 to PNG?

Yes, I think I can add KTX2 support to MCX and then you can convert it to other texture formats as well.

 

[arno]

I'm still puzzled about the compressed glTF data in the BGL files. I tried a few common compression algorithms, but none seems to work. If anybody has read something about what they changed in the BGL format let me know.

 

[grissven]

And little more testing, here is the diference between adding LODs, it doubles or triple the distance before objects dessapear, Arno I used MXC to add the LODs at 100, 50, 25, and 10, I haven't used the LOD tool in MCX thata many times so I am not that familiar with it, I have 2 quiestions: what does the Auto calculation does when enabled, I couldn't figure out and the other is how does the option of adding an emty LOD work, what is that for? I'll leave a little video to show the behavieour of when adding LODs vs not adding them

 

[arno]

what does the Auto calculation does when enabled, I couldn't figure out

When you have the auto calculate checlbox enabled the LOD will be directly calculated once you change one of the input parameters (e.g. desired number of triangles, target LOD, etc). When the checkbox is unchecked you have to press the calculate button to update the model.

and the other is how does the option of adding an emty LOD work, what is that for?

Some formats allow you to add an empty LOD, that is basically use to let the object dissapear at a certain distance. But since you have issues with it dissapearing too soon, I don't think that is what you need (and I also don't think the empty LOD is exported to glTF).

 

[arno]

Yes, I think I can add KTX2 support to MCX and then you can convert it to other texture formats as well.

Reading the KTX2 format proved not that hard. I have a basic implementation now (see screenshot with some default textures). I'm not sure the normal map read correctly, I need to check that one. At the moment I only support DXT1, DXT3 and DXT5. MSFS used other compressions for the normal map and comp map, but I don't see them in the default textures I tried at the moment.