Materials and appearances...GRRRRRRRR

[cstarnes]

I have an assembly with thousands of parts made from various aluminum extrusions. All of them have been assigned a material named "AL6061", and that material file has a custom aluminum appearance assigned to it, which is stored in the global.dmt in the materials folder. "global_appearance_file" points to that, and I have "mat_assign_appearance" set to yes. Everything seems to work fine, until...

...I need to change the generic aluminum color for some reason. 

I can load the global.dmt file into the editor, change the appearance, and then save it. Or do it manually or any other way I want. I can verify the changes are in the global.dmt, but the part colors never update unless I un-assign and then re-assign the material. Even with some scripting and automation, this is a tedious task on thousands of parts buried in configurable assemblies.

This leads me to believe that the appearance definition is loaded into a part when a material is assigned, and stored with the part. If so, that is just goofy. If you are using "mat_assign_appearance" to pull the appearance from the assigned material, why doesn't it just update if the referenced appearance updates?

The part should store a pointer to an appearance...not the actual appearance definition itself.

Am I missing something? Is there a way to get parts to update their appearance (from the assigned material), without having to reassign the same material just to get it to refresh?

[cstarnes]

I'm so tired of trying to figure this goofiness out.

I've deleted every .dmt file on my system except for "appearances.dmt" in the start-up directory, and I even have the config option "global_appearance_file" pointing to that file. I change the ambient value of a color in that file and save it (either with Creo's ridiculous appearance editor or in notepad), verify the new value in the file... and when I relaunch Creo it comes in with the original unaltered ambience value....no matter what.

So... if I only have one .dmt file for Creo to find, and it has "x" values for various parameters for appearances...where is it getting the other values from?

Did they have an 8th grader design the colors and appearance functionality 15 years ago, and then just decide to completely ignore it? Shareware programs have had appearance functionality that leaves this in the dust for 20 years or more.

So frustrating.

[MartinHanak]

---

@cstarnes wrote:

I have an assembly with thousands of parts made from various aluminum extrusions. All of them have been assigned a material named "AL6061", and that material file has a custom aluminum appearance assigned to it, which is stored in the global.dmt in the materials folder. "global_appearance_file" points to that, and I have "mat_assign_appearance" set to yes. Everything seems to work fine, until...

...I need to change the generic aluminum color for some reason. 

I can load the global.dmt file into the editor, change the appearance, and then save it. Or do it manually or any other way I want. I can verify the changes are in the global.dmt, but the part colors never update unless I un-assign and then re-assign the material. Even with some scripting and automation, this is a tedious task on thousands of parts buried in configurable assemblies.

This leads me to believe that the appearance definition is loaded into a part when a material is assigned, and stored with the part. If so, that is just goofy. If you are using "mat_assign_appearance" to pull the appearance from the assigned material, why doesn't it just update if the referenced appearance updates?

The part should store a pointer to an appearance...not the actual appearance definition itself.

Am I missing something? Is there a way to get parts to update their appearance (from the assigned material), without having to reassign the same material just to get it to refresh?

---

Hi,

1.]

Contact PTC Support and verify that material definition + color definition is copied into model and saved in it.

2.]

Ask PTC Support how to easily and quickly modify this information in a set of models.

[KenFarley]

Appearances are assigned on an individual basis, and don't change with the material. This is obviously not a desirable behavior for you, but it does make sense for a lot of other cases.

For example, suppose you have an assembly and you've set the color of the items to what their final anodized color will be, so when you do a shaded view the thing you're building looks like it will in reality. Or you may have different bits of the assembly shaded a specific color to reflect that they are being purchased from a particular supplier. Or you might have colors depict which parts are built in-house, and which are purchased.

All of these other use case scenarios would be ruined if, every time you loaded the assembly, the material of each component determined its appearance.

[cstarnes]

How would automatically updating part appearances based on their assigned material, have any effect on assembly appearances? If a part or surface has an appearance assigned in a higher level, it takes precedence. At least, it always has for me.

[Patriot_1776]

Creo has always had issues with appearances based on material.  If you have a family table of parts where the geometry is the same but the material is different, then it does a lousy job of changing the appearance in the assembly if different instances are used with different appearances.

Try doing a mass properties analysis on it.  that might "re-boot" the appearances.

[cstarnes]

Yeah, that doesn't do it either.

Another annoying issue is that when you change appearance definitions in session, and then save them to the global.dmt (or appearance.dmt) file, they don't internally update for material definitions.

For example, let's say you have a material called "steel.mtl", and it references an appearance called "light_gray_steel". If you open the global.dmt file and change that appearance, and then save it, it will appear to be changed in the appearance manager, or if you assign that updated color to a part in session. But if you assign the material "steel.mtl" to a part, it will take on the original "light_gray_steel" appearance; not the updated one.

The only way I've found to get around this is to exit and restart Creo after making appearance changes. That is the only way to get a newly assigned (or re-assigned) material to use the latest updated color.

There are so many things about the appearance interface and appearance behavior that is just ridiculous. The non-resizable, non-persistent, under-sized, buggy interface is aggravating enough on it's own. How many years have they had to get this right now? 15? 20?