Performance Hack #025 : Rendering : Controlling Appearances, Configuration vs. Display State

• Display states give me a hard time cause I need to define them on each level and I can’t reuse it from the sub-level
• Or at least I have a problem with sw showing me the correct graphics
• This might not sound like administration but it is a very important topic that could help Dean handle his 4gb model 🙂

Hi.

What’s the reason for the sub-levels? If I may enquire. what’s driving that decision?

I generally don’t have too much use for that, unless a model has already implemented it historically. it just tends to make the file size larger, but also this exponentially makes diagnosing mates and or other errors much harder.

ok, I think the main questions that I’m hearing is about display states vs configurations.

vs correct graphics.

let’s take a moment to rec-cap here. let’s recall the graphics display state hierarchy.

so here, you might want to open up your “master model” and then start picking on things that you’re trying to change colour wise. investigate, notice if there’s a pattern, or a general behavior “currently in play”. Then now take it account WHERE you were trying to apply this colour, and investigate if there was any other colour appearances higher up on the tree that were applied that caused the colour “you wanted” not to show.

so using this hierarchy investigation technique, I can usually see where a colour is applied. there’s a whole part level, assembly level and then a further face, body or feature level…..

you can of course, near the SolidWorks tree, open the display pane and investigate that way too.

Now for the second half of the conversation, in general the other thing that I have seen a lot of people do is not keep to “critical” display states. I used linked display states with configurations, fyi. but beyond that, I might have one colour schema for the sales, and another for the assembly guide, and I let the rest be. so that way I won’t loose my sanity, but stay prioritized for outputs required. production usually doesn’t require fancy colors for us…

over-all there’s a lot of layers to display states and how and where you can apply them.
there’s no right or wrong way, but the challenge always is, if a new person picks up the file, will the appearance schema be preserved so changes are easily and effortlessly applied?
For my automation packages, The team tends to only apply appearances and colors at the part level, and we manually just have the appearance library handy dandy in the task pane, with the library location shown, to apply the other door colors very quickly when a new sales order arrives.

also, if there’s been too much applied to any particular file, and you swear it’s going crazy display state wise, this can happen, it just gets jumbled. you may have to delete all current display states and start again with only the critical ones. you may have to make an exec decision whether linked display states to configs or NOT, serves you best.