Incomplete file names returned by SUTextureGetFileName()


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.


Joey Gaspe

There are a number of issues open for file name and path getters for the C API.

Errors for functions reported …

Missing functions requested …

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.

All the errors aside, …
Why would you need a valid path to the original texture file when it’s there inside the model ?

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.

Thanks again!

Joey Gaspe

1 Like

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.

Btw, do you mind logging an issue in the issue tracker if you think it’s a API bug?

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.

1 Like

For reference to other readers, this is followed up here: