CREATE EXPLODED VIEWS AND DISPLAY STATES IN VERSIONS AND RELEASES

shawn_crocker

I run into an issue quite regularly where an assembly gets released and during the drafting stage, it becomes clear that new display state will need to be created to properly document the design.  Usually an exploded view needs to be created or modified as most of my products are released from a master configured model.  As it stands, I have to go back to the master, navigate to the in progress workspace, reset all the configuration controls back to the desired setup and then add in all the extra visual representation features before releasing again.  Usually I resort to dropping the released assembly into another assembly that I set to not revision managed and then I can add exploded views and display states to that assembly.  If I already have some drawing views created that need to use different display states, they have to be deleted and the new assembly added in to sort of cheat.  Then these views of the other assembly are sort of floating.  Maybe there other ways but it just seems easier if display states and all of the things in a document involved with changing how a design is viewed could be processed differently by the version control system.  It would even be OK if you could maybe not change already created display features but at least add new ones.  When it really comes down to it though, it would probably be best if we could create customized ways of viewing a model (display states, named positions, exploded views) from within the drawing tab itself.  Like a way to create a new display definition that is initiated from the drawing and takes you into a temporary space where you can freely create viewing related features.  This definition would then be part of the drawing and would be able to follow whatever revision path the drawing takes instead of following the model.  It would also be great if this view definition could exist as its own entity even though it is created or initiated from the drawing.  It could be a definition that is attached to an assembly outside of the assemblies version control.  It would be version controlled independently of the assembly and drawing but accessed through the drawing.  If previously created display entities where created for an assembly and a user begins creating another drawing of the assembly, they will be available to use or make changes to.

Not sure if this is making sense as I'm sort of running with the wind here but basically I'm thinking saved views, named positions, exploded views, all that stuff should be decoupled from the assembly and be version controlled independently.  Adding the ability to hide certain things in a model is like changing the lens on the camera.  You wouldn't revise a product because the camera man needed to change his lens.  You would revise the document that was being use to record exactly how the product was being photographed.

lougallo

@shawn_crocker This is something that I have talked about before but is going to be a very difficult thing to implement when the explode, display states and other aspects need to be saved.  Versions are immutable so these things are inherently going to be disabled.  I understand the need and the workflow you are doing today to address it.  Today linked document workflows are going to be the best solution to maintain the immutability and provide a full suite of tools in the workspace. 

tim_hess427

Just wanted to add my support for this idea. I also agree that it would be great for "representations" of a model to somehow be separate from the model itself. 

Similarly, the display state of a part studio being captured in the document history is also annoying. On some of my models, 50% of the history is showing/hiding parts, which makes it hard to find the more meaningful changes. 

I know I've run into this issue in the past as well. I try to typically release drawings and models at the same time, so that helps me avoid it usually. 

shawn_crocker

Is this logged as an improvement request? Not seeing if people are voting for it. @lougallo

shawn_crocker

I get the whole issue with how versions have been coded and why the imutability of them is advantageous. There must be some way to allow for this. Versions are imutable but we are still able to change properties attached to them. I'm just thinking display related settings should be treated more like properties. They should be independent and not coupled to the versioning system. Or preferably, versioned independently like a separate entity that is applied when needed to an assembly that is registered with it.