In my SketchUp importer, SUTextureGetFileName() sometimes returns incorrect file names. They are partially truncated, and the issue seems to start with files that have certain symbols that are outside the usual alphanumeric set (ie letters and numbers and underscore) in their names, such as spaces. I checked whether it depended on UTF 8 or UTF 16 encoding, but I get the same results either way. The TextureWriter related code seems to work fine, outputting colorized and non-colorized textures as expected, so the correct texture files are present, just the names are not returning correctly.
The test files Iāve used are from the 3D Warehouse, in particular āHearst+Tower+(New+York).skpā is a good example, for which six textures return incomplete file names.
After observing several cases, I found a few rules of thumb could allow the correct file name and hence file to be found. Sometimes the wrong file is found, but itās still somewhat better than none at all.
Either Windows or macOS:
Sometimes a file name returns with one or more asterisks in it, which arenāt accepted due to being a wildcard symbol, so I have to replace them with underscore.
Example: My*Texture.png not found ā My_Texture.png is found.
Sometimes it requires adding a number to the name, from ā1ā on up.
Example: MyTtexture.png not found ā MyTexture1.png is found.
In the cases above, sometimes the extension is also missing, so adding .png is attempted to try to find a match.
Example: MyTexture not found ā MyTexture.png is found.
macOS specific:
Particularly on macOS, I have to check that the fileās original path is removed if part of the string, which means checking for slash and backslash from the end and taking only the part of the string after it.
Sometimes users get models from other sources, and they do not have the original texture files.
Downloading someone elseās model from the 3DW will be a good example. You yourself will not have the original texture image files.
If you are importing a .skp model into your application, then use ImageRep to directly access the texture data.
Thanks for the reply, you confirmed the issues with the SketchUp SDK arenāt limited to my usage of it, eliminating the possibility I was misusing it. I did base the importer on the example code that comes with the SketchUp SDK. You also make me come to the conclusion that to fix the resulting wrong texture file name issue, Iād have to export the texture in a new file and only then be stuck giving it a different name.
I donāt need the entire path, I just need the correct texture file name. Itās because itās best that the textures be outputted as files because the material system in our software, Cinema 4D, load them from files and support the same bitmap file formats, and that their names be the same to not confuse or irritate users. Itās also to minimize issues with a āback and forthā workflow if ever we write a SketchUp exporter: you donāt want a progressive āmanglingā of the metadata as you load and save in SketchUp and another program. You can always argue the user is asking for trouble in those situations by not importing a file only once and continuing their modifications in the target software. However, in real life users often prove they are stuck in non-ideal situations and any foresight of this sort goes a long way to ensure user satisfaction.
Hi Joey, can you share some example model + code with us to reproduce the various scenarios you are running into? You can share models privately if you donāt want them in the public.
The vast majority of example models weāve used are public, from the 3D Warehouse, so I can share them publicly. Iām sure itās one or more related API bugs, so I logged it:
Issues with truncated returned file names with SUTextureGetFileName() #429
I hope that helps! Let me know if you need anything else, like more examples and/or more parts of the code. I did simplify some of the code, such as the custom throwing code that I replaced with āreturn;ā in the error handling code, since itās not relevant and makes the code harder to read.