• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

ModelconverterX MSFS2024 object

arno said:
I'm still confused. The first proposal was to make a separate glTF file for each material in each LOD, now you are talking about individual LODs, which sounds like a glTF file per LOD (which you already get with glTF of course). It still does not make sense to me.

Splitting an object into a lot of different files makes it a lot harder to work with a model, since you are very likely to not keep the different files aligned correctly when working with them.
Click to expand...
Yes, however doing the LODs individually afterwards of each object within the model would be better then the overall model LOD method.
 
Let me check, but all these files work in msfs or are produced by the package tool?
 
Interesting. The ktx2 file that fails to load seems to use some additional compression, but the header field that should specify the compression used mentions that there is no compression.

The KTX2P files seem to be something different, they don't have the normal KTX2 identifier in them, but online I can't find any information about this format.
 
arno said:
Interesting. The ktx2 file that fails to load seems to use some additional compression, but the header field that should specify the compression used mentions that there is no compression.

The KTX2P files seem to be something different, they don't have the normal KTX2 identifier in them, but online I can't find any information about this format.
Click to expand...

You can probably find something in the plugins for Blender or 3ds Max.
 
KTX files are built as part of the sim build process - not the blender or 3DS export.

I also assume that "P" is for proprietary and ASOBO will be the only ones with the "key"
 
@Cygnific are you sure all textures are actually used in the model? Some don't seem to have a corresponding json file for example.
 
ronh said:
KTX files are built as part of the sim build process - not the blender or 3DS export.

I also assume that "P" is for proprietary and ASOBO will be the only ones with the "key"
Click to expand...

Yeah, I was just thinking about it and wanted to edit the post for the mistake. I had .gltf in my head.. ^^



It looks like it's a packed file (multiple files) to me.
 
arno said:
@Cygnific are you sure all textures are actually used in the model? Some don't seem to have a corresponding json file for example.
Click to expand...

They are used yes, the ones without are probably taking the info from the header in the ktx2 file itself... Also, they have autogen in their name, i'll check it out some more in a bit.
 
Cygnific said:
Yeah, I was just thinking about it and wanted to edit the post for the mistake. I had .gltf in my head.. ^^



It looks like it's a packed file (multiple files) to me.
Click to expand...
Looks like I was corrected on the dev hub for MSFS - they are NOT ASOBO/MS files. So who knows where they came from - If Carenado uses them - maybe they did something to make them work.

But if you download an aircraft - in SU3 - you will see files like decal_medico-autogen.ktx2p - they have no json associated to them.

 
Last edited:
I don't believe these ktx2p files are used in the glTF models. These ktx2p files are packed textures that already exist in the texture folder. They aren't created by the sim's compiler, so I assume they are created by the Marketplace prep process (controlled by Microsoft I think). I don't know their purpose. I suspect we don't need to be concerned with them at all. The other file (ktx2 with an unknown format) might be something we use if we can figure out what the actual format is. But it must be quite rare. I haven't come across it yet in the default files.

Meanwhile there are perhaps thousands of the ktxp2 files in the sim's texture folders. If they aren't referenced in the glTF models, why are they there?
 
I came a bit further in understanding the ktx2p files. They seem to be a container that contains different versions of a texture. In the examples I found a DXT7, DXT3/5 and DXT1 texture all of the same sizes. They use a ASOBO proprietary compression algorithm so I can't actually read the content of the textures at this moment.
 
I have been in contact with Asobo and it is indeed a custom proprietary compression that is used in these ktx2 files. That's added by the marketplace and more information on the scheme is not available. So I'll modify MCX to give a nice warning, but MCX will not be able to show these textures in the preview.
 
Hi,

After some further discussion with Asobo it is now clear to me that the ktx2p files are used by MSFS to stream textures. They can contain multiple textures (like albedo, comp, normal) in one file to make the streaming more efficient. The glTF object does not reference the ktx2p, but MSFS will use the file when present.

The ktx2p files always seem to use the proprietary Asobo compression. That combined with the fact that they are only used for streaming, means that I will not support them in MCX. They are not relevant for developers working on an addon.

For normal ktx2 textures I will make sure that when a file with the Asobo compression is encountered that a message is printed in the log, as MCX will not be able to decompress them. But this seems to apply only to marketplace content so should not be that relevant to developers either.
 
You must log in or register to reply here.
Back
Top