Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:

  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Why is it not possible to Suppress a Feature Folder?

StephenGStephenG Member Posts: 230 ✭✭✭
Feature Folders were a much needed addition to help address difficult to manage and manipulate feature lists. However, it appears it is not possible to suppress/unsuppress the folder such that all the features it "contains" are suppressed/unsuppressed. I would have thought that folder suppression should be possible.

Am I missing something?  Is there a logical reason why Folder suppression is not possible?

Here is my usage scenario where it makes sense to support feature folder supression...

All my modeling is initially done as a idealized concept where everything is modeled to a nominal size; a 1" dia shaft fits nicely in a 1" hole. Once the concept is worked out I will tweak the geometry using direct modeling approach to introduce the proper amount of tolerance gaps where needed. I collect these modeling tweaks in a feature folder.

Also, I 3D print a lot of my models, as either an actual end use parts, or as a semi functional mock up. Because FDM 3D printers often over extrude material I will make further adjustments to the geometry that has critical fit features, or small features (<2 mm).  I collect theses adjustments in a feature folder as well.

I do this so it is clear where the critical interfaces are, and to isolate the tweaks made to support 3D printing. If I need to change the design concept I want to be able to suppress all these geometry tweaks while making the change. Suppression/unsuppressing a folder would be a lot easier than expanding it, using Shift section the top and bottom entry, then RMB select Suppress/Unsuppress.

Feature folder suppression could be something that be can added to part configurations.             


  • Jake_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,285

    I very much agree that this would be useful functionality!

    The answer to your question about why we did not release this with feature folders is the same as all other similar questions:  When releasing new functionality, we aim to release the MVP (Minimum Viable Product), collect feedback, and then make improvements.

    There are a number of design considerations here that would have slowed down the release of feature folders. The main one I can think of is as follows:
    1. I create a folder with a number of features inside of it.  Some of these features are suppressed, and some are active.
    2. I suppress the folder, now all of the features inside of it are suppressed.
    3. I unsuppress the folder.  Now what happens?  Do all of the features become unsuppressed?  Do only the features that were previously unsuppressed become unsuppressed?
    I suspect that a majority of users would like the second case.  But, for the users who would like the first case, folder suppression would be more of a shortcut to suppressing/unsuppressing all of the features, rather than a true suppression state.  Additionally, if we were to go with the first case, the suppression would not be configurable because a configuration would not be deterministic.  An example of what I mean:  Folder A contains features 1, 2, and 3.  I am currently in config alpha, which keeps folder A unsuppressed.  I suppress feature 2.  I switch to config beta, which suppresses folder A.  I switch back to config alpha, which unsuppresses folder A.  Now feature 2 is unsuppressed again, meaning that something the configuration is not supposed to control has changed, meaning config alpha is unstable (not deterministic). (In other words, when I am in config alpha, then switch to beta, then back to alpha, everything needs to be exactly the same as before switching.  This workflow violates that condition.)

    So, it seems the second is more stable and correct (if we want feature folder suppression to be configurable, and not just a shortcut to suppress/unsuppress all the features in a folder).  So, if we go with that, now there has to be a new concept of whether a feature is "suppressed by feature" or "suppressed by folder" or potentially both.  Does "suppressed by folder" have a different piece of UI?  Maybe the strikethough is grey instead of black? Is this color choice high contrast enough for accessibility purposes?  If a feature has both kinds of suppression, do we represent it with two strikethroughs instead of one? If I right click on a feature inside of a suppressed folder, do I still have the ability to "supressed by feature" state of that feature?  If that suppression state just adds or removes an additional strikethough, will the user be confused about what is happening?  Maybe we would need to change the wording of the right click dialog, or not allow this operation at all.  Etc, etc, etc.  All of these questions need to be iterated on, then user tested, changed in response to the user testing, and then user tested again.  The client needs a bunch of UI changes and the server and database need plumbing for a new suppression concept, and configurations needs to understand how to work with it.

    My point is, if we go down every rabbit hole we see, we would never release any functionality.  So instead, we release when we have something useful, collect feedback, and constantly improve.  Go agile!

    Let me know if you have feedback on any of the above questions! As you can tell, folder suppression is something we've been mulling over and any additional feedback would be very useful.

    - Jake
    Jake Rosenfeld - Modeling Team
  • glen_dewsburyglen_dewsbury Member, OS Professional Posts: 95 PRO
    My preference would be leave previous state of suppression when unsuppressing folder. Anything that was already suppressed in folder should maintain state.
  • owen_sparksowen_sparks Member, Developers Posts: 2,259 PRO
    Just because I'm feeling evil I'll add a third option:- Suppressing a folder should invert the suppression state of the features inside.
    Owen S.
    Kidding, mostly.
    Production Engineer
    HWM-Water Ltd
  • StephenGStephenG Member Posts: 230 ✭✭✭
    Without bringing "Part Configurations" into the discussion, it makes sense to support Feature Folder suppression. The behavior of how Suppress/Unsuppress should function at a folder level has been a long established UI behavior; it would affect the entire "contents" of the folder.

    For the benefit of the user, a suppressed featured count should be added next to the feature count for the folder.

    For example...

      becomes      the  2  denotes two features in the Feature Folder are suppressed.

    Now for my idea regarding making Feature Folder Suppression" configurable...

    When I mentioned the possibility of supporting "Feature Folder" suppression as a configurable feature I knew it would require additional thought and it would raise interesting questions. 

    My initial thought for suggesting adding Feature Folder Suppression as a configurable feature has a lot to do with my current use of Part Configurations. I find that my usage requires suppressing a lot features which greatly increases the configuration table horizontally. Being able to "group" blocks of features in a Feature Folder and then add just the Feature Folder for suppression to the part configuration would reduce the size/complexity of the configuration table.

    I realizing I am using Part Configurations in a manner different from what it was originally intended. I do not use it to create families of parts that have just  a few parameters that vary. I am more likely to use Part Configurations for reengineering activity where I want to capture the original "As-Built" design as one configuration and changes made to "improve" the design and an "Improved"  configuration. For this reason, the entire concept of make Feature Folder Suppression (if it existed) configurable should be rejected. (Maybe I should be use versioning, branches, and version compare, but using configurations gives me a much finer control of documenting the changes.)

    After giving it some additional thought, the "Feature Folder" is a lousy grouping mechanism and should not be a configurable item. Feature Folders should be all about compressing the length of the Feature List to improve the user's efficiency working the feature list.

    What is needed is something completely different, something  that does not depend on the features being grouped linearly in the Part Studio's feature list. Even then many of @Jake_Rosenfeld points about non deterministic configurations are still valid. My gut feel is there is a workable solution, but this forum is not place to iron out the feasibility of it.   

  • MBartlett21MBartlett21 Member Posts: 1,550 EDU
    StephenG said:
    What is needed is something completely different, something  that does not depend on the features being grouped linearly in the Part Studio's feature list. Even then many of @Jake_Rosenfeld points about non deterministic configurations are still valid. My gut feel is there is a workable solution, but this forum is not place to iron out the feasibility of it.   

    Maybe we could have 'configuration groups' (groups of features that have the same suppressed state)
    MB - I make FeatureScripts: view FS (My FS's have "Official" beside them)
  • owen_sparksowen_sparks Member, Developers Posts: 2,259 PRO
    edited March 4
    I think we're nearly there with "labels". If we tag a feature with a label we then set suppression state of anything with the appropriate tag. Doesn't matter where they are in the tree then. They're also be searchable. We could also choose to put them in a standard folder if we wished.

    This is only useful go suppression not input parameters though.

    Idea 2
    The concept of "suppression only" folders. The items within cannot be individually or manually suppressed, a config may either turn them all on, or turn them all off. Stability resumed, but has limited functionality. I still kinda like it though, even if it were only a stepping stone to something else.

    Idea 3. Half baked idea of revising the search functionality to make something a bit like featurescript queries. You then have a suppression method built around queries rather than user clicks.
    Cheers, Owen.
    Production Engineer
    HWM-Water Ltd
  • lanalana Onshape Employees Posts: 454
     I want to capture the original "As-Built" design as one configuration and changes made to "improve" the design and an "Improved"  configuration. 
    We intended branches to be used for this. Why would you prefer using configurations? 
  • StephenGStephenG Member Posts: 230 ✭✭✭

    Your question as why I did not use OS "Branching" deserves a response. I have had to rethink what branching is and to reconsider using it in my workflow.

    When I started using OS I experimented with branching a little, but set it aside because branching was a foreign concept to me and my understanding of what it was intended for did not fit my workflow.  I do not think I am unique in this respect; I bet branching is not utilized as much as it should be for that reason. It is my understanding OS is the first MCAD product to offer this capability, therefore, it is a foreign concept to anyone experienced in other MCAD tools. It is a capability that does not have established usage in a typical MCAD workflow, therefore it it not leveraged.

    As a single individual working a design I thought branching could be used as a way to go off on tangents to explore different design approaches, but I found simple versioning works just as well.    

    It was my understanding that branching was intended as a collaboration tool allowing multiple people to work on a design within the same OS document, where the individual contributions would be eventually consolidated into the final design. I am a 1 man show so there is minimal collaboration going on. I guess the biggest reason I do not use it is because the work done in branches is "hidden". When I open a OS doc it isn't immediately clear as to whether the doc has branches and how many. When I am working a design that has multiple design variants I found that using Folders, multiple tabs, part/assy configurations are a much more obvious way of communicating what is taking place in the document.

    As I said, I will revisit using branching. Based on my workflow I will attempt to use branches to represent various states of a design with different geometric states, for example, geometric differences that are driven by redesign of an As-Is condition to correct a design flaw, or geometric differences attributed to refactoring the design to accommodate changes in either material, or manufacturing processes.
  • Jake_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,285
    edited March 28

    Here is an example of a document I used (to make a small keychain of a chef's knife) where I had to branch for different manufacturing processes:

    After doing a few test prints, I found that I wanted to test with medium and small clearances at the same time, so I branched off and made those changes in separate branches, and did those two tests at the same time.  Then, I wanted to print it using metal, and had to make additional changes.  Branching here helped me keep the original design intent of the finalized design "Third Print", while making adjustments for the manufacturing process "Med Clearances", "Low Clearances", and "Metal print" branches. 

    Since these branches can have any number of versions on them, and act in parallel, you can imagine that it would be very helpful if I had three entirely different manufacturing processes (let's say 3d print, cast, and machined), and needed to do design iterations for all three.  Instead of having a mess of part studios with no associativity, or a bunch of versions for three unrelated concepts along the "Main" branch, I could be separately iterating on the design for all three manufacturing processes in an organized, contained manner; creating versions as checkpoints on each branch as I go.

    Here is the link for that doc: https://cad.onshape.com/documents/ec4d9c75a4f6b2b6741f2799/w/ce408aac3197e266c0b46523/e/2a1630ebfa945ac5703a4289
    Jake Rosenfeld - Modeling Team
  • tim_hess427tim_hess427 Member Posts: 111 PRO
    @Jake_Rosenfeld ; - In your example, how well do the branches handle changes to the "base" geometry that should be applied to each of the different manufacturing methods? Say you wanted to change the length of your knife blade and update each of the branches with the new geometry. What would be the best way to do that?
  • Jake_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,285

    If you wanted to do that, you would make the change on the "Main" branch, and then merge "Main" into all of the branches which you wanted to consume that change.

    Jake Rosenfeld - Modeling Team
  • tim_hess427tim_hess427 Member Posts: 111 PRO
    @Jake_Rosenfeld ; - somehow that seems like too simple of a solution and had I not just tested it, I wouldn't believe that it works. Your team and your product just keeps on amazing me!

    I think my head is still stuck in some sort of history-based modeling mode, so its hard for me to wrap my head around the concept of updating geometry from the future into the past.

    Mind blown. Thank you.

    (and apologies for going down a tangent in this thread)
  • lanalana Onshape Employees Posts: 454
    Thank you for your response. Indeed we find that we have to convince experienced CAD users one-by-one to test-drive branching. Please do not hesitate to ask for help if branches don't work as you expect them.
  • romeograhamromeograham Member Posts: 192 PRO

    This is indeed pretty amazing.

    @Jake_Rosenfeld I couldn't get your knife design intent to hold together well enough to try this (merging changes in Master into Branches) but did a simple model of my own to test. 


    This is an area that will take a while to understand and to use effectively. 
Sign In or Register to comment.