Good afternoon! babylon automatically renames texture names to Image1 or Image_0.003 when exporting to glb 3ds max 2024, can this be fixed? Exported from 3ds max with the texture ID_color (32832_color), I import the model into Blender and see the texture name as follows: Image_0.003 and so on.
Cc @PatrickRyan
@UdixOper, renaming the textures is something that the exporters have done for a long time. If I remember correctly, this was done as a way to share textures on export, but I don’t remember the full reasoning behind renaming. But I do remember raising the concern years ago and learning there was a reason to do it.
Originally, this was not seen as an issue because glTF is intended to be a runtime format, meaning it doesn’t matter what the textures are called because it was the final step in delivery to the end user. It wasn’t intended to be a transfer format moving a file between digital content creation packages. There are a few reasons for this such as vertices along UV seams are unwelded, which is done as an optimization. But moving that file to another package would mean dealing with unwelded vertices.
I’m curious why you are exporting from Max as glTF to move to Blender as glTF and not something like FBX, which is the more traditional route?
I think there may be an issue that was opened about changing this, but we are not investing in our exporters for new features, only bug fixes. So we have tagged this issue as help wanted.
1 Like
There is a problem that when importing into a system that uses this format, all textures must have the name: IDModel_color. But I noticed that when exporting to glb format from 3ds max, the texture is renamed. I use Blender as a test
@UdixOper, thank you for the clarification about the problem you are running into and your use of Blender. Makes complete sense. Without an update to the exporter there is no simple way to correct the file renaming as you would need to export as glTF, rename the texture files, and edit the glTF json to match the new file names and then pack to glb if needed. To fix it in the exporter would be the best user flow, but I have no idea how large of a change this would be. Maybe @srzerbetto is familiar enough with the code to estimate the size of the change, but we are hoping someone in the community has some bandwidth to contribute the change.
1 Like
I will take a look at the codebase to see how much of a change that would be.
1 Like
Thank you very much!