Display state

[jesseg010]

hello and good day, im using display states at work and im wondering how many display states 1 part can have without making another configuration? thank you

[matt]

Without answering your question, I'd like to offer a caution. Any time you start exploring the extreme limits of something, you'll find a limitation somewhere else. If you're coming up with some method that involves dozens of display states, I'd think of a more conventional way to achieve what you're trying to do. Configurations are already a pretty brittle functionality. Pushing them too hard is likely to end in crashes.

[Glenn Schroeder]

How many do you want?

[jcapriotti]

I think at most we have maybe 10. We typically unlink the display state from the configuration.

[Dwight]

I think at most we have maybe 10. We typically unlink the display state from the configuration.

Ten is no problem. Yes, do unlink display states from the configurations.

We use display states instead of configurations as much as we can. That includes avoiding exploded views and sections, if possible. Display states do not have much of a performance hit.

Dwight

[JuTu]

What's with unlinking the display states from configurations? Are there pros/cons for either method?

I have been pondering this and currently on our templates we use configuration-linked display states.

[jcapriotti]

What's with unlinking the display states from configurations? Are there pros/cons for either method?

I have been pondering this and currently on our templates we use configuration-linked display states.

Like Dwight mentioned, we do this to create different "views" for multiple exploded views as well as different views in larger assemblies to work on smaller sub sets of the data without having to display everything. We may also create them for use in drawings to show some parts removed like a cover or door removed to see inside of a cabinet. Doing this as configurations is very heavy and slow whereas display states are faster. Also each configuration balloons the file size and rebuild times.

[SPerman]

I need to learn to use and embrace display states. I've been doing everything with configurations.

[Glenn Schroeder]

I need to learn to use and embrace display states. I've been doing everything with configurations.

It will cut down on file sizes. I use them to hide components in Assemblies instead of suppressing them. That has an added benefit of not leaving other components that may be mated to the hidden components free to move, since the mates are suppressed if the component is.

[zxys001]

imho,.. be careful what you do with the combo of display/config/exploded states.... for simple stuff it's ok for on going revisions and final release,... but more complicated geometry and even minor iterations... a friggen hairball. good luck.
btw, creating saved views is a very good way to help manage states.

[Alin]

hello and good day, im using display states at work and im wondering how many display states 1 part can have without making another configuration? thank you

What is the use case? Depending of your answer, you might even be able to avoid both configs and displays states and use SnapShots instead. Those are magnificent creatures, capturing orientation, zoom factor, hide and show state and section view state.

[JuTu]

Like Dwight mentioned, we do this to create different "views" for multiple exploded views as well as different views in larger assemblies to work on smaller sub sets of the data without having to display everything. We may also create them for use in drawings to show some parts removed like a cover or door removed to see inside of a cabinet. Doing this as configurations is very heavy and slow whereas display states are faster. Also each configuration balloons the file size and rebuild times.

Yes, thank you, I'm aware of the these things, but my question was 'what is the gain on unlinking the display states from the configurations'? I cannot fathom this subject alone - someone enlighten me, please.

But on the other hand, file size is a minor inconvenience. Storage space is relatively cheap. SSD technology revolutionized open-time performances. And file size doesnt necessarily correlate to the open times. BUT file size has an effect on data transfer times e.g. from server to workstation.

Ballooning rebuild times and increased complication of the model itself is and issue with configurations. I am in the faith that Display states are the way to go in most cases, being much more robust and reliable since it doesnt involve rebuilding the design rather than redrawing things.

[DanPihlaja]

Yes, thank you, I'm aware of the these things, but my question was 'what is the gain on unlinking the display states from the configurations'? I cannot fathom this subject alone - someone enlighten me, please.

But on the other hand, file size is a minor inconvenience. Storage space is relatively cheap. SSD technology revolutionized open-time performances. And file size doesnt necessarily correlate to the open times. BUT file size has an effect on data transfer times e.g. from server to workstation.

Ballooning rebuild times and increased complication of the model itself is and issue with configurations. I am in the faith that Display states are the way to go in most cases, being much more robust and reliable since it doesnt involve rebuilding the design rather than redrawing things.

If you want to use 1 configuration/display state, then linking them is the way to go.

If you have a bunch of display states, but want to use them throughout your configurations at will, then unlink them.

I have used both ways. Just depends on what I want to do.

[jcapriotti]

Yes, thank you, I'm aware of the these things, but my question was 'what is the gain on unlinking the display states from the configurations'? I cannot fathom this subject alone - someone enlighten me, please.

For large complex assembly, I may only have one configuration. But I need to create different views of the model for model work, drawing views, multiple exploded views, etc.

[Dwight]

If you want to use 1 configuration/display state, then linking them is the way to go.

If you have a bunch of display states, but want to use them throughout your configurations at will, then unlink them.

I have used both ways. Just depends on what I want to do.

Yes to this. I do rather have them unlinked as the default, though, otherwise (1) you will create a bunch of display states that you might not want when you create configurations, and (2) you will not (I'm pretty sure) be able to see the whole range of available display states.

Dwight

[Frederick_Law]

When linked, activate config will activate linked display state.

Don't know if activate Display State would activate the config.

[m2shell]

In general I don't use Display States much; reason being in the past I ran into problems using Display States in Drawings. I recall that if my Open part/assy file was showing DS #1, but I wanted to create drawing views of DS #2, the drawing interface would not always show me the correct DS I think.

Again this is awhile ago, and my memory is hazy of exactly the issue. But if folks find Display States more robust than what I am describing, I'll be more inclined to work with them in the future.

[Dwight]

Don't know if activate Display State would activate the config.

I checked. I find that when display states are linked, you only see those linked to the active configuration in the list. You can add more display states to a configuration, but you only see those, while the others are hidden. I don't know how you can activate a hidden Display State.

Dwight

[Glenn Schroeder]

In general I don't use Display States much; reason being in the past I ran into problems using Display States in Drawings. I recall that if my Open part/assy file was showing DS #1, but I wanted to create drawing views of DS #2, the drawing interface would not always show me the correct DS I think.

Again this is awhile ago, and my memory is hazy of exactly the issue. But if folks find Display States more robust than what I am describing, I'll be more inclined to work with them in the future.

You can always select the desired display state from the drawing view's property manager, regardless of which display state is active (or was active when the model was last saved).

[SPerman]

My workflow would benefit greatly from having 2 display states: drawing and working. Now, I only have one, so anything I hide in the assembly for the work I am doing ends up being hidden on the drawing.

[jcapriotti]

My workflow would benefit greatly from having 2 display states: drawing and working. Now, I only have one, so anything I hide in the assembly for the work I am doing ends up being hidden on the drawing.

That's a really good idea. In our template, we unlink and name the one display state "ALL" to indicate that all should be shown. Then creating additional display states are optional for work per user. I should add a "WIP" display state maybe.

[Frederick_Law]

Didn't do that in SW.
I have "Default" and "Design" in IV.
Default show what will be in the drawing.
Design can have parts, features (planes, axis, points) turn on or off.
Helps in assembly when constraining.

[Dwight]

I see a couple icons in the listing for this thread that I don't on others (the red face and a pin). Also, the thread stays at the top of the list of threads. I can't find any controls to change it. This something I did locally? Something else?

[AlexLachance]

I see a couple icons in the listing for this thread that I don't on others (the red face and a pin). Also, the thread stays at the top of the list of threads. I can't find any controls to change it. This something I did locally? Something else?

image.png

The face was put by the original thread creator. The pin, that I do not know.

[Dwight]

The pin went away. I've no idea why.

[AlexLachance]

The pin went away. I've no idea why.

It generally means the thread has been 'stickied', which means it stays at the top of the forum it is located in, though this one wasn't. Not sure why you were seeing a pin.

[jcapriotti]

It generally means the thread has been 'stickied', which means it stays at the top of the forum it is located in, though this one wasn't. Not sure why you were seeing a pin.

First time I've noticed this. Not sure we mortals should have that power though @matt

[matt]

First time I've noticed this. Not sure we mortals should have that power though @matt

image.png

Yeah, that's in there. The permissions setup in phpbb is arcane. I would have to change it for every single subforum. It would only take a little time fix it, but no one has really abused the setting as far as I know, so I'll leave it for now.

Thanks for pointing that out. I guess I knew it was set that way at one time, but I've long since forgotten.

[Dwight]

Thanks for pointing that out. I guess I knew it was set that way at one time, but I've long since forgotten.

Hi, Matt. Can you get rid of the sticky? I tried, but it keeps coming back, stuck at the top of the SW General threads.

Thanks

Dwight

[matt]

re: sticky
I think the reason the option goes away is that it seems anyone can make a thread sticky, but only the OP (or mod) can unsticky it. I appear to have done this from my point of view. Can you verify that it is unstickied from your point of view?

I will change this option for the general posters as soon as I can (probably next week). The way it's set up right now, it has to be changed for every subforum... Just don't get carried away making things sticky between now and then.

[Dwight]

Looks like it went away.

Thanks

Dwight

[ryan-feeley]

Good stuff! I'm a little late to the party. We have a WIP display state in our templates, as @jcapriotti suggested. I agree 100% with @Dwight about using display states as much as possible. We do that up to the point of duplicating bodies within parts, and parts within assemblies, to leverage display states, rather than configurations, whenever it doesn't add too much spaghetti. We have a few settings to exclude hidden parts and bodies from mass calculations, BOMs, and the like, to support this.

The difficulty with using configurations at the part level is they force parent assemblies to also use configurations to control what they want to get. This can be a big ask. Better to do as much as practical with display states, and call in the big guns only when you really need to.

If you can avoid configurations entirely, top-down modeling and associated external references get way easier to manage.

[SPerman]

I don't understand the fear of configurations. I use them extensively and they never give me any problems (that I didn't create myself.)

[Dwight]

I don't understand the fear of configurations. I use them extensively and they never give me any problems (that I didn't create myself.)

I do use configurations extensively. Definitely when we have tabulated parts. However, they seem to have a bigger hit on performance than display states.

On our current project, we have a top level assembly that we can open in three minutes and can manipulate without waiting. This is the first project in twenty years that we have managed to do that. It has been achieved by strictly defending against excessive use of configurations, exploded views, and fancy mating schemes.

Dwight

[jcapriotti]

I do use configurations extensively. Definitely when we have tabulated parts. However, they seem to have a bigger hit on performance than display states.

On our current project, we have a top level assembly that we can open in three minutes and can manipulate without waiting. This is the first project in twenty years that we have managed to do that. It has been achieved by strictly defending against excessive use of configurations, exploded views, and fancy mating schemes.

Dwight

Same here. We primary use configurations for families of parts/assemblies and try to use Display states for hiding and showing stuff in different combinations. Large assemblies are where they show the best bang for the buck, part level rarely have more than one.

That said, I wish there were better tools for controlling and seeing differences between them. Like we have the "Configure" option, need something similar for display states.

[ryan-feeley]

I don't understand the fear of configurations. I use them extensively and they never give me any problems (that I didn't create myself.)

I certainly do use configurations at times, and pretty heavily with simulation models and prep for rapid prototyping, but they have their limitations. It depends what you're doing. If I can use a display state instead, even with a little hoop jumping, I will. It's faster and in my experience it's fewer headaches.

I question the use of configurations if you have external references, surfacing with edge/vertex dependencies, appearances applied at the face/body level, or long feature trees. They may still be the right call, but that's where I take pause.