Convert FSX models to MSFS with ModelConverterX: import MDL files, repair textures and PBR materials, export glTF, package and troubleshoot.
ModelConverterX can import an FSX .mdl, recover its texture references, convert legacy materials and export the geometry as MSFS glTF assets. It does not create a finished add-on: place those assets in an SDK project, rebuild unsupported animations and effects, compile the package, then test it in Microsoft Flight Simulator.
What does ModelConverterX preserve from an FSX model?
ModelConverterX is most effective with static scenery objects and relatively simple animated models. Geometry and UV mapping usually transfer well, but FSX materials, effects and simulator-specific behaviour require inspection rather than blind conversion.
| FSX element | Typical conversion result |
|---|---|
| Geometry and UV coordinates | Usually retained, although scale, origin and shading must be checked. |
| Diffuse and night textures | References can be recovered if the original texture files are available. |
| Specular and bump maps | Require conversion to MSFS PBR texture channels and normal maps. |
| Animations | Basic geometry animation may survive; FSX animation tags and control logic may not. |
| Levels of detail | May be recoverable, but every LOD and its switching behaviour needs testing. |
| Effects, platforms and attach points | Often need to be recreated with the MSFS SDK. |
| Aircraft gauges and systems | Not converted by ModelConverterX. |
How do I convert an FSX MDL to MSFS?
- Confirm that conversion is permitted. Use a model you created or one whose licence allows modification. Technical access to an MDL does not grant permission to redistribute its geometry or textures.
- Collect the complete source assets. Make a working copy of the
.mdland gather every associated texture folder. If the object is embedded in an FSX scenery BGL, use ModelConverterX's scenery or object tools to extract the required library model. Our explanation of recovering editable geometry and textures from an FSX MDL covers this extraction stage in more depth. - Import the model into ModelConverterX. Select the FSX MDL as the input and configure any SDK or exporter paths requested by your ModelConverterX build. Check the event log after import; an object visible in the preview can still contain missing textures, unsupported animation tags or incomplete LODs.
- Resolve all texture references. An MDL normally stores texture names rather than the images themselves. Add the correct FSX texture directories to the search paths or copy the required files into a dedicated working folder. Avoid pooling unrelated scenery textures because identical filenames from different add-ons can overwrite one another.
- Inspect the geometry before export. Check dimensions in metres, model origin, orientation, normals, smoothing, animation hierarchy and every available LOD. Correct unwanted transforms now. A misplaced origin can leave an otherwise valid model underground, offset from its placement point or rotating around the wrong pivot.
- Convert the materials to MSFS PBR. Use the Material Editor to replace legacy FSX settings with suitable base-colour, normal, emissive and composite textures. The MSFS composite map convention uses ambient occlusion, roughness and metallic information in separate colour channels. Do not simply rename an FSX bump or specular map: its channel layout and meaning are different. FSX diffuse alpha may control transparency or reflectivity, so inspect each material before carrying that alpha into MSFS.
- Export MSFS glTF assets. Choose the MSFS-capable glTF exporter and write the output into the model-library source area of an SDK project, commonly under
PackageSources/ModelLib. Keep the.gltf, binary data, textures and model XML in their intended relative locations. Give the model a unique GUID rather than copying one from another project. - Add and build the SDK package. Create the package definition, register the model-library asset group and reference the model's GUID from scenery placement XML. Build it with the SDK belonging to the target simulator. ModelConverterX output placed directly in the Community folder is not a substitute for a compiled package. For complete airport and placement work, follow our FSX-to-MSFS scenery rebuilding workflow.
- Test the compiled result in the simulator. Inspect it in daylight and darkness, from close range and at distance. Check material response in different weather, animation, collision, LOD transitions and performance. Read the SDK build output and Developer Mode console before changing files at random; they often identify a missing URI, malformed XML or unresolved asset.
Why is the converted model invisible or incorrectly textured?
Most failed ModelConverterX conversions come from packaging, texture or material errors rather than damaged geometry. Match the symptom to these common causes:
- The model is completely invisible: check that the model-library asset group compiled, the placement references the correct GUID, and an over-aggressive LOD setting is not hiding the object.
- Textures are missing: confirm that every glTF texture URI points to a packaged file. Remove absolute paths leading back to an FSX installation or temporary folder.
- The object is transparent or looks like glass: review the base-colour alpha channel and the selected blend mode. FSX alpha values do not always represent transparency.
- Surfaces are black, faceted or inside-out: repair face normals and tangents, then verify that converted normal maps use the convention expected by MSFS.
- The model is huge, tiny or underground: correct its units, applied transforms and origin. Do not compensate for a bad model transform solely with scenery placement values.
- Animations remain frozen: rebuild unsupported FSX tags using MSFS animation definitions and confirm that the glTF retained the required nodes.
- Performance is poor: add practical LODs, reduce excessive material slots and draw calls, and resize textures that are far larger than the object warrants.
After changing source assets, rebuild the package rather than editing its compiled output. Generated files are replaced during the next build, which is why fixes made there appear to vanish.
Can ModelConverterX convert an entire FSX aircraft?
No. It can recover much of an aircraft's visual model, but it does not turn FSX gauges, flight dynamics, sounds, systems code or cockpit interactions into a working MSFS aircraft.
Compiled gauges and DLL-based modules require replacement, while animations tied to FSX-specific variables may need new definitions. Our breakdown of FSX add-on compatibility with MSFS explains why transferring the exterior model is only one part of the job. For a flyable result, use the visual conversion as a starting point and follow the full aircraft package, systems and animation workflow.
Should I convert the model or rebuild it?
Convert when the source is a clean static object with usable textures, sensible geometry and clear modification rights. Rebuild when the asset depends heavily on FSX effects or code, lacks practical LODs, contains excessive draw calls, or needs major geometry and material changes anyway.
A quick conversion can preserve an older landmark or library object efficiently. A complex aircraft, animated vehicle or poorly optimised airport object often takes less time to rebuild from editable source than to repair after automated conversion.
Will the same conversion work in MSFS 2020 and 2024?
The source glTF and textures may be reusable, but each package should be built and tested with the SDK for its target simulator. Do not assume that a package loading in Microsoft Flight Simulator 2020 proves that its materials, animations, LODs and package definitions behave correctly in Microsoft Flight Simulator 2024.
For dual support, keep shared source assets but maintain separate build output and any target-specific project definitions that become necessary. This also prevents files from one SDK toolchain being mixed accidentally with the other.