Material name vs display_name

Does anyone know the history behind material name and display_name being separate? I’m working with a SketchUp to Unity workflow, but the material names in unity don’t match those used in the SketchUp UI. I guess i could just use the Ruby API to force the internal names to match the display name, but I’m curious why they are even separate properties.

ThomThom said

Speaking of Names…
The Material class has two seemingly similar methods, #name and #display_name. The documentation says that #display_name is preferred, but doesn’t explain why.

The difference is that if a material name is wrapped in square brackets, like “[MyMayerial]”, then #name will return “[MyMayerial]” and display_name will return “MyMayerial”. The latter is how SketchUp will display the material name in the UI, while #name returns the real name.

If you refer to a material by name, then you must use the string you get from #name instead of #display_name. model.materials[ material.display_name ] will return nil for materials wrapped in square brackets because the look-up failed.

So what the documentation should be saying is that #display_name is preferred when you present the material name to the UI, while #name must be used to look-up materials in the Materials collection.

1 Like

I use en-US SU so have never checked this theory…

I always thought the two were for allowing SU material name translations…

and that’s why we don’t have a :display_name = '' in the API…

i.e. :name points to the internal ‘filename’ and :display_name is the result from LanguageHandler…

I may be wrong…

john

2 Likes

I’m also using the original en-US (and watch my anime with subtitle, not dub). It’s an interesting theory though and I can test it one one of the localized installs I have.

Right now I just found it a bit ugly to have random names wrapped in square brackets in Unity, but not in SU.

Try this…

Make a new material [named ‘MAT’] in your model and apply it to a face.

m=face.material
m.name >>> MAT
m.display_name >>> MAT

If you rename ‘m’ to ‘MATX’.

m.name >>> 'MATX'
m.display_name >>> 'MATX'

However, import a material from a collection, that is named ‘MAT’, then apply it to the face…

m=face.material
m.name >>> [MAT] # showing it was imported
m.display_name >>> MAT # displayed name

NOW, if you rename ‘m’ to use ‘MATX’.

m.name >>> 'MATX' # the chosen name - the link to the import is broken.
m.display_name >>> 'MATX' # the chosen name

Does that help ?

1 Like

It’s indeed a very likely possibility.

I am working on a plugin in which I also implement a display_name method. Why? Because an ID as string (like “name”) must be permanent, unique and fulfill other constraints (e.g. subset of all possible strange file system’s character restrictions). Whereas a display name allows the user to use any Unicode characters and spaces, and allows me to swap it by a translation.

A string ID can be generated from a display name by canonicalizing it and ensuring it fulfills all constraints (e.g. replace or drop characters, make unique). This results in a name that I would not want to display to the user.

2 Likes