Material name vs display_name


#1

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.


#2

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.


#3

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


#4

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.


#5

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 ?


#6

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.