Maintain Design View Representation when turning Part Visibility on/off

[Anonymous]

Changing the visibility of a child part in an assembly from On > Off > On , resets the Part's View Representation back to "Master". The problem is "master" usually has all the working geometry of the part like sketches, planes, etc. This becomes very troublesome when you are working with skeleton modeling. It would be great if the View rep would be maintained even if visibilty is changed.

Example:

-Opened Assembly

-Set view rep of child part to "Default" within the assembly (1st picture)

-Turned visibility of child part off (2nd Pic)

-Turned visibility of child part back on (3rd Pic)

-View rep of child part is now set to "MASTER" showing all working geometry

-Manually change view rep of child part back to "default"

[swalton]

 WIth IV 2014, when you set a sub-component view rep as associative and then hid the component, IV throws a warning that the associative link will be broken.  I have to remember to go back and re-link the view rep when a show the sub-component again. 

Please make sure that any sub-components that I have set to associative (ie any changes in the sub-component view rep will be reflected in the parent assembly view rep) stays linked.

[jtylerbc]

I believe that the Isolate command (which is essentially a massive visibility switcher) also messes up the view representations and associativity settings.

All of this needs to be cleaned up.  Someone who uses View Representations a lot essentially can't use the Isolate command, and can't change Visibility without destroying work that has already been done setting the representations.

Visibility should behave independently of View Representation.  If a component's visibility is turned off, the assembly View Representation should store that setting.  However, it should also remember what View Representation settings were active, and restore them when visibility is turned back on.

[Anonymous]

This problem is also biting me. Isolation and visibility switching of sub assemblies can't be used properly for skeletal modeling because the view representation keeps switching back to master when the visibility is turned back on. If the tips on this page are still true about isolating components for performance gains, this means skeletal modelers will either suffer a modeling efficiency loss or a rebuild performance loss.

[Anonymous]

Hi,

Just want to add myself (and all of my colleagues) to the list of people that find this behaviour not only very very annoying but SERIOUSLY time consuming and inefficient.

I work with large assemblies and taking visibility on & off of subassemblies is a task I do hundreds of times, and each time I have to go and select the default view representation again as I use a lot of construction geometry. Also, I do use several view representations to work, review, etc. It’s also worth mentioning this issue being a big problem when using Frame Generator and having skeleton 3D sketches and other construction geometry that should remain invisible after use.

I don’t think this should be the standard behaviour as the logical approach would be to the software to remember the desired user setting (including when switching visibility on and off!).

I really hope Autodesk takes this into consideration.

Thanks

Jonathan M.

(I just posted this on the other thread, but repeating here trying to make more noise about this!!)

[philm]

Yes put me down as one of the "wish this wasnt so" people on the list. 

The irony being that its such a distraction when "Inventing" - designing, to have to constantly work on the way things are displayed so you "see" what you need to and nothign else. 

[Anonymous]

This would be very usefull, as me and my coworkers are struggling with the same things.

[SBix26]

I think it's important to distinguish between visible/enabled changes to individual components of subassemblies and the entire subassembly.  I believe what we're all asking for is that these be handled differently.  Attempting to change the visible/enabled state of a component of Weld Fixture:1 (in @Anonymous's example above) should result in the warning and breaking of associativity, as it does in Inventor now.  But changing the visible/enabled state of the entire Weld Fixture:1 as shown should simply do that, with the ordinary change in icon color in the browser.  That state would be saved with the current View Rep of Ribbon_asm.iam (along with the associative view rep information for Weld Fixture.iam).  When the visible/enabled states are returned to "on", there is Weld Fixture.iam, looking just as it did before using the Default view rep.

This is far more intutive and useful for most (all?) of us, I believe.  I suspect that there are further implications that I am not considering (such as: what do the browser icons look like for subcomponents of an invisible subassembly with an associative VR?).

Sam B

Inventor Professional 2016 R3 SP1 Update 1
Vault Basic 2016 SP1
Windows 7 Enterprise 64-bit, SP1

[Anonymous]

This problem set me back about half a day trying to figure out why planes were just appearing out of nowhere. No one one the forum seemed to be able to help, and kept telling me that my models had planes/sketches et to visible, which was not true. I had no idea this could happen. I was working on someone elses old drawing where they were already there, and this was a nightmare to solve independantly...

[DRoam]

@dan_szymanski, I wanted poke some attention at this one as well, as another (hopefully) "JDI" candidate. This is another one that (hopefully) isn't a big deal on the programming side but would make a HUGE difference for us.

Can it please be changed such that a component's View Rep setting will be preserved as we toggle visibility, transparency, and enabled? In other words; visibility, transparency, and enabled should temporarily "override" the applied associative View Rep settings, if any, not un-apply them.

PS, if and when this is looked at, while the team is at it, maybe they could look into knocking out this bird with the same stone: Allow locking a View Representation AND keeping associative links.

[DRoam]

Here's another View Rep enhancement that would be really helpful: Allow visibility overrides to Associative views in Drawings.

[DRoam]

Here's another suggestion to try and make View Reps less tedious: Apply Visibility/Color overrides ON TOP of View Reps, rather than unlinking them

[sbromley]

Crazy that this happens. Turning visibility back on should bring the item back in the same state as when it was turned off.

[Anonymous]

98 Votes and it is still there in 2018!!!!!! mmmm

[ihiengdept]

This is a huge issue and I can't believe it hasn't been dealt with yet.  Visibility should be a setting in it's own right separate from a selected view and association.  It should not cause the removal of any associative view representations.  It makes sense to have the visibility of an object stored in a view representation, but it shouldn't affect which representation is selected when visibility is turned back on.  The representation and association should be remembered and restored when visibility is turned back on. 

The current implementation feels like a programming shortcut that doesn't understand the purpose of turning visibility on or off for an entire object (part, subassembly, etc.)

There's almost no point in setting views inside sub-assemblies since the association will be broken the first time you need to toggle that assembly off. If I have 15 objects in the way, that's 15 items I have to restore to the previous settings after I turn them off so I can work on the portion of the assembly that they were obscuring.  I may note even know which view was selected for most of those sub-assemblies.  I often have to turn that same group of assemblies on and off quite a few times when working a one area of a design.  Even worse, the state it returns to when it's turned back on can be incredibly disruptive since it shows all the planes and sketches that were only intended to be internal to that sub-assembly.  In the end, almost everything ends up being un-associated and left that way since it's the only practical way to work.  

It's a real killer for teamwork as well, since it could take quite some time to track down which assembly is harboring a troubling plane or sketch that is obscuring your view because it's in someone else's model, and the worst part is, none of the team members even wanted that behavior.  The sketch was a design tool that gets "accidentally" turned back on well after anyone remembers where it is at.

[neljoshua]

This is annoying indeed. Please change/fix this behavior!

[Anonymous]

Very irritating. At least provide the user with a choice. This costs me a LOT of time. Turning off visiblity om a subassembly in the master assembly and then turning it back on even shows all reference parts. No way to undo that AFAIK.

Please provide a solution or include reference parts in the Object Visibility menu.

[Anonymous]

Why does a sub-assembly always come back in the master view representation? I defined the view of the sub-assembly I want to have in the main assembly with the "Default" view representation because the master can't be changed. But when I need to turn off visibility for just a moment, because of whatever reason, and then I turn visibility back on it comes back as a not associative master view. 

This frustrates me.

[DRoam]

A new related idea: Show an indicator if components are associatively linked to a View Rep or not. Please consider voting!

[aconwayAXDXE]

if you select the button below where my mouse pointer is you can change which representation is opened and remove the planes ect in this panel

[karthur1]

Here we are in Inv 2020 and we have the same issue with loosing the associative View Rep when we change the visibility of a component.  WHY does Inventor have to do this? It would make life so much simpler if the setting of the assembly was remembered when the visibility was turned back on.  It does the same thing when a component is "Isolated".  This is much worse b/c when you "UnIsolate" later, ALL of the subs VR is reset.  On a large assembly that is HUGE waste of time to have to go back and fix all of them.

@johnsonshiue: Come on guys. Please JDI and fix this!