Version: all versions
Frequency: Consistently
Severity: Low
Context: Warning when building out packages.
Bug description:
when I export my aircraft models in 3DS Max 2024 (running the latest SDK tool), my gltf files contain an “images” array and each entries contains a full absolutely path to the texture source as defined in my materials. When I build I always get warnings that these should be relative and so I’ve had to build a python script to convert these to relative paths. My coworkers however seem to have no trouble with their exports so I’m trying to find out what is causing this in Max or the SDK tools and how I could fix it.
Also, could we just have the build tools suppress this warning since it doesn’t use those paths anyways in the model.
Hello @CptAirWo1f
Are your textures located on the same disk as the max file?
What is your Active Project set to ?
Regards,
Sylvain
Textures are typically stored in a folder called textures located in the same folder as the max file. Im fairly certain it isnt path related as i jave coworkers who use the same files, max version and sdk tools and they are able to export without the gltf assigning absolute paths. If i export that same model from blender using its addon, the parts are assigned as relative.
So the issue seems to be in how my specific version of max wants to handle file path but nothing ive tried seems to resolve it.
Have you tried using 3DSMax’s “Asset Tracking” tool to convert all paths back to relative?
My bad, this is more likely where the GLTF is exported that matters.
Are you exporting to a different disk?
If so, can you try exporting in the same disk as the one where textures are located and see if you still have the issue?
Regards,
Sylvain
Yes, all of our models get exported to different drives than the asset locations.
Our project repos exist in a different location than the source assets. But since this is the case for all our programmers, they should be running into the same issues I am.
As for the asset tracking tool, I believe I had attempted to resolve it using that method a while back and it had not worked (as a coworker uses that to fix his issue). Though it has been a while since my last attempt.
A suggested improvement for the sdk tool:
In the MSFS export tool, we should be given the option to “clean” the gltf’s image array of any path info since that stuff doesn’t get used anyways. Using a python script works perfectly fine but it would be nicer if it was just part of the export process in the babylon toolset.
We assume you have the “Textures” export option checked then?
I will have this reviewed.
Regards,
Sylvain
Ive tried with the export textures option both on and off. Unfortunately there is no difference. Our typical workflow involves initially exporting the textures but then turning it off and managing those separetely.
Thank you for taking the time to investigate. If there is anything i can provide to assist let me know. Cheers
Hello,
If you want to copy your textures to a different location you have to always keep the path and the texture option ticked otherwise your exported gltf will not know the right path to the textures you want to use in game.
Yasmine, please read the description of how the exported images are ignored below. (Weve confirmed this on our end)
The following was provided by a google search only because it can better explain it than i can lol.
…
The glTF files exported for Microsoft Flight Simulator 2024 can contain an images array populated by your 3D software’s exporter, but the simulator engine itself does not use those internal image paths/uris at runtime.
How Paths Work: The MSFS compilation and runtime system ignores relative or absolute paths defined inside the glTF’s images or texture URI properties. Instead, the engine looks up textures dynamically through texture.cfg fallback directories or package texture folders.Compilation Process: When you build your package via the official MSFS SDK Package Tool, source texture files (like .png or .jpg) are processed and compiled into optimized .ktx2 formats, while the geometry goes into .glb/.gltf containers relying on simulator-specific material extensions.Exporter Warnings: It is common during 3DS Max or Blender exports to see compiler/validator warnings if absolute or mismatched texture paths are written into the glTF images array, even though the simulation ignores them completely during rendering.
…
The proposed solution won’t work for our use case. We need to preserve the texture paths in the glTF file so that users can import it into tools like Blender without losing texture links.
Regarding absolute paths: by default, image paths are relative to the exported glTF file. However, if the glTF file and its textures (exported with the glTF or not) are stored on different drives, the paths become absolute because relative paths cannot span across separate drives.
I’m not entirely sure I follow the problem you’re encountering, so I’m trying to better understand where the issue is coming from.
1 Like
I see. That harddrive sync for both source and project is likely why mine are being assigned absolute paths. Do you guys think using a python script prior to project submission to change all gltf images array to relative paths is an ok work around for the time being?
If you’re not importing the glTF into another DCC (Blender, Maya, etc.), your Python script will work fine. Just note that the resulting glTF won’t be fully spec-compliant.
Ok that non compliance to spec is what worries us. Ideally, a modification to the sdk tool would be made that would force relative link assignments to all gltf exports regardless of source file location. Im guessing this effects quite a few of us that have several harddrives to manage multiple projects.
Thanks for hearing me out and confirming the issue though, much appreciated!
1 Like
