[Eric Lagman]

I have been having a lot of issues lately with figuring out what materials are actually on an object. In a large assembly sometimes I drag a material onto a part that is either in the main assembly or part of a sub assembly, and the plugin shows the material has been applied. However when I render or open in studio the material is not on the object. What am I doing wrong. Should I just be putting materials on only at the solid or surface body in the actual part file instead of assembly? Is there a best practice for applying materials in a large assembly? Right now its looking like I should open up every single part that is in my assembly and place materials on that way. This can get very tedious though in a large assembly though.

Take a look at the screenshots. It shows I have a black plastic material applied at the component level to that piece. Open in studio or render straight from SW and that is not the case.

[JDHill]

Hi Eric,

Obviously something isn't working as designed there, but it's too hard for me to tell from a screenshot exactly that might be. Is it at all possible that you could send me this model, or if there are IP issues, a simpler one in which you can duplicate the behavior? The function by which the plugin figures out what is applied to any given item is quite complex due to the attribute-inheritance rules in SolidWorks - in some cases, it is very difficult to determine what is actually selected, and the rules by which its attributes should be over-ridden. I assume in this case, that there is really no material applied, and that the object-properties window is giving you a false indication. I think this, because you have the plugin's filter set to 'Select Any', yet you have a Component selected - this must have been selected not in the viewport, but in the FeatureManager, and this sometimes results in a the Component selected being given to the plugin in a different context than when it is selected in the viewport with the 'Select Components' filter on.

Thanks,

JD

[Eric Lagman]

JD I will see what I can come up with to send you. I will trim the model down to just a few parts to show whats going on.

What is interesting is if I open up the sub-assembly of that black parts with the Husky logo on it that slides into the blue selected one shown in the screenshot it has the proper materials applied when I render and export into studio. If I render or export from the larger main assembly it is in it has the default auto materials applied just like the smaller blue piece. Their is definately some wierdness going on with what materials are really applied where.

[JDHill]

That will be the issue: sub-assemby - there is a technical limitation to this:

- attributes applied to Components in an assembly will not be visible when that assembly is then inserted into a super-assembly

For Parts, this is different - materials applied to a Body, Face, or Feature are always the same, no matter where the item is found, but Component-level attributes only live in the assembly in which they were defined. I can't say that I really know why, but that's the case...I read the attribute in this context, and there is no data there - I assume this is to allow for having different attributes in different iterations of assemblies. Unfortunately, this makes for a material-color non-synchronization, because SW material appearances do not behave this way.

However, I'd still like to look at the model if it's convenient for you.

[Eric Lagman]

Ok thats the issue then I think. I either need to put all my materials on at the part body or face level or only at the highest level assembly it sounds like. To be able to use parts in other assemblies though and maintain maxwell materials a best practice is to only put materials on at the part level.

[JDHill]

Yes, it's best to think of Component-level attributes as overrides on what has been defined as the 'natural' state of a given object. Basically, I would assume the intention to be one such that you may want to have libraries of parts, with attributes defined as needed to spec. If you use them anywhere, it shouldn't be necessary to mess around with those attributes since they are meant to represent real items (think toolbox) which do not change very often. However, should you find yourself in any certain assembly where there is really a special case, you are meant to have the ability of making a local override there, without wrecking the general structure you've built. I think this is slightly less useful in a rendering context, than it is in an engineering one.