Folders for Features/Sketches? (Or, best way to organize them?)

exigent_ck

Hey everybody,

Unless I'm missing something there is no ability to group Sketches & Features into folders, correct?

This is really the #1 thing holding me back from enjoying OnShape right now (especially now that Loft is included)

OnShape seems to encourage heavy multibody part design and from what I can tell works well with driving layout sketches and lots of boolean operations. But for a design of some complexity this ends up being a nightmare in the feature tree! 

Does OnShape plan on adding feature folders or something crazier? I saw the Filter/search ability and that can be helpful. From my standpoint I'd encourage not reinventing the wheel as far as organizing features. Since OnShape is history based it's really nice to give the user control to organize them into a folder that can be supressed/unsupressed

If anyone else has suggestions on how to keep your tree organized I would appreciate those!

andrew_troup

You're right that folders are missing, and that their lack feels like a major impediment to organising a complex model. 

But it may well be that (due to the rather different underpinnings of Onshape from traditional solid MCAD) folders are not the optimum solution, and there has been quite a lot of discussion on this point on this forum. If I get a spare moment I'll try to find one thread in particular where (as an added bonus) a long-time beta user shared his cunning workarounds. 

The team at Onshape have repeatedly taken the time to evolve targetted and thoughtful, simple and elegant solutions, rather than the faster and easier implementation of "Me, Too" ones, and I personally suspect they may serve our long-term interests better if they keep that philosophy front and centre.

3dcad

Recent update brought filter, now all we need is tagging.

Narayan_K

Yes now we have a filter option.Type required feature in the filter box provided and get features grouped..

 

traveler_hauptman

One of the main reasons for organizing a feature tree via grouping (like folders) is to condense it so that the sequence of actions can be more easily understood by a newcomer or your future self. Filters and tags don't do this.

FYI here's a previous exploration of this issue:
https://forum.onshape.com/discussion/120/feature-manager-tree-wishlist

3dcad

@traveler_hauptman If you could set a tag to be 'folder type group' it would provide you the grouping you are after? I would like to able to get most out of grouping and searching with minimal extra work, that's why I suggest tagging.

I would like to see features autotagged with part names and other related features so that it would help searching even if you don't bother to rename or manually group things. If I need to change the diameter of a hole, I would like to search for hole (even if I didn't rename anything) and see all features that created circle with extrude/remove - does this make any sense?

I see a problem with folders with Onshapes great capability of reusing sketch entities for different features. The same sketch might need to belong in more than one folder --> tagging allows this behavior.

traveler_hauptman

Why limit the organizational tools? There is no reason tagging, grouping, filtering, and searching can't all coexist.

A part studio is a bunch of parts [EDIT: (This is not Onshape specific. I should have said 'A solid model part')] is created by walking a dependency graph, solving and building each feature only after that features dependencies have been built. The 'feature tree' list is our (poor) view of that graph.

So, the underlying structure is a graph of dependent features... how should we view and navigate it?

Filtering, either on feature characteristics (contains a circle) or on meta-data (tags) will show us a subset of the graph nodes with no regard to how they are connected. Great when we are using recall. ie when we know information about the thing we are looking for.

Often we aren't using recall though. We don't have information about the model, either because we forgot or we are seeing it for the first time. So we use recognition. We build our understanding of the model by recognizing patterns and structure. This can be challenging with big models where complexity hampers figuring out what depends on what.

One way we can reduce the apparent complexity of the graph but still maintain the structure is to group nodes that are closely connected and related. SolidWorks calls these folders, Creo calls them groups. Note that folders/groups in a solid modeler are different than folders in a file system. A file system graph structure is a tree, a solid model dependency graph is not. SolidWorks did a disservice to their users by calling the group a folder in my opinion. It's also a bit sad that CAD developers shoehorn the dependency graph into a tree shape for the feature list.

Does that help you understand why I think we need both tags and groups? Why they are different things solving different problems?

3dcad

Thanks for clarification. I agree with different methods coexisting - thought you didn't wan't tagging but rather only folders.

ilya_baran

@traveler_hauptman While I agree with the need for better organizational tools, actually the feature list is an accurate reflection of our underlying regen model: each feature potentially depends on all previous ones.  We could provide a graph view of which features' geometry depends on each other, but whether feature A depends on feature B can be affected by editing feature C that is earlier than both of them in the list.

traveler_hauptman

@ilya_baran I made a mistake in saying 'part studio is a bunch of parts' and should have used a more generic 'part is a bunch of bodies' since I was not talking about Onshape specifically.

That said, your comment has sparked a lot of thought but I'm not sure I'm understanding the correctly. Let me know if I've got it wrong:

ilya_baran said:

@traveler_hauptman While I agree with the need for better organizational tools, actually the feature list is an accurate reflection of our underlying regen model: each feature potentially depends on all previous ones.

I expect (hope) that this is only because you guys have not finished coding.

An analogy pops into my mind regarding this that might speak to you as a software engineer. If I put you on an operating system with no 'make' tool and told you "don't worry, building is easy, just create a list of your files in order of their dependency and feed it to a shell script"... would you be satisfied? Or would you ask you buddy to code you a make tool?

The tools I currently use, Creo and SolidWorks, project the dependency graph on a tree view in different ways. Regardless, both constrain me to reordering the tree only in ways that are valid for the dependency graph. I expect nothing less and hope for a bit more from Onshape.

 We could provide a graph view of which features' geometry depends on each other, but whether feature A depends on feature B can be affected by editing feature C that is earlier than both of them in the list.

The dependency graph of the features is different than what I think you're talking about here which is the dependency graph of the resulting geometry. As you note, a hole feature can get it's location from an earlier feature and based on that, happily be nowhere near a solid, creating a hole in nothing. That's ok. The hole is still there. I as a user need to be able to understand that the hole position is coming from another feature and break the link, create a new link or edit the upstream value as needed.




I tried thinking a bit about what managing the users intended geometry as a graph might look like. 'This boss must be circular and fit on the supporting surface. This hole must stay on the boss and get no closer that Y mm from any other hole'. It's interesting to think about.

kevin_quigley

Nobody using SolidWorks 2015 +?  See how they handle the parent child dependencies in the feature tree. At first I thought this was a gimmick but it is actually a brilliant interface element. We have debated this here in detail before, but something needs to happen soon. The plain list doesn't work for anything over 20 items, more than this it is a PIA. I see nothing wrong with using folders and filtering and tagging...but whatever happens keep it small. Anything that takes up modelling space is bad...and allow the user to scale it..like a timeline in any animation software...on a long feature tree this would offer rapid navigation to the relevant items (for those of us that prefer folders to search

ilya_baran

@traveler_hauptman
The analogy of CAD regen with build tools is an interesting one, but I think there are differences.  A big part of why build tools tend to work in terms of a dependency graph is to facilitate partial rebuilds: when I change a source file, I only want to rebuild things it depends on.  With CAD, while that sounds good in theory, the realities of working with an interconnected B-rep make it very difficult to get any efficiency out of nonlinear regen; and, at the end of the day, Parasolid calls have to be made in some order.  Regarding how easy it is to specify a build process, I have personally found dependency graphs can get difficult to navigate and debug -- there are definitely times when, if not for partial rebuild, I'd rather just specify imperatively what needs to be done.

All that said, I think I understand better which graph you're talking about -- it's which features reference geometry resulting from which prior features.  We could come up with a way to show that graph (and it would be more stable than the one I mentioned).   That would, for instance, make it clear when (as a result of a reorder) a feature reference is dangling because it is to something later in the history.  However, the order would still be necessary because (again unlike build tools) two features that do not depend on each other (in the referencing sense) will frequently fail to commute: for instance, a boss on a part and a shell of an unrelated face on the same part.

I tried thinking a bit about what managing the users intended geometry as a graph might look like. 'This boss must be circular and fit on the supporting surface. This hole must stay on the boss and get no closer that Y mm from any other hole'. It's interesting to think about.

Unless I misunderstand you, this sounds more like a more intelligent way of specifying an individual relationship, rather than managing the relationships themselves.  Unless you're thinking of a more constraint-based modeling approach overall.  While that is not currently on the radar, one thing that we are working on, that may be useful for some of the workflows you're talking about, is the ability to reference one part studio from another (and effectively construct a dependency graph on part studios).  I'll be curious to see what you can do with that.  In any case, this discussion is sparking a fair bit of thought on my part as well.

traveler_hauptman

I'm really enjoying this discussion.

I'm not sure we are talking about the same dependency graph yet. I think it's because I don't have the correct terminology.

In terms of Onshape, each Feature definition has a bunch of parameters and elements which themselves have parameters. A sketch has lines, whose endpoints have location parameters, an extrude has an extrude distance parameter, and so on. Each parameter is a node in the graph. We, the user, create the edges of the graph by creating constraints between parameters, equals, coincident, etc. Additional edges are created with constraints between parameters and derived geometry (more fragile) and existence constraints (extrude x depends on sketch y existing). 

Within-sketch constraints are part of the same graph, and create the same challenges in comprehension and navigation that the bigger graph creates. 

The geometry derived from the parasolid calls is part of the dependency graph, but only part of it. 

Other CAD has equations, configurations, and inter-document relations in addition.

Does that help clarify the dependency graph I'm talking about? 


Here's some thoughts from a users perspective:

• The graph is not a problem when you are first creating a document. The designer holds all the relationships in their head.
• The graph is a problem when you return to a document a year later, or when you open someone elses document.
• One's first view of an unfamiliar, non-trivial feature is often that it's a tangled mess and the original author needs to be punched (even if that author is yourself). Once you have the relationships figured out you are happily adding to the wonderfully intricate and time-saving model.
• Inexperienced modelers, when faced with a non-trivial dependency graph, will make a change and see if something breaks, or looks funny. Or worse they will hack the model. I have seen someone, unable to find the source of a position constraint, fill in a hole with an extrude and create a new hole in the new position... Horrifying!
• Experienced modelers will use the graph navigation tools provided by the CAD vendor and a scratch pad to figure it out. (Parent/Child in SolidWorks, Reference Viewer in Creo)
• As I noted earlier, SW and Creo both limit re-ordering of the feature tree to sequences that are valid for the dependency graph.  
• At any given moment we only care about the node of the graph we are trying to edit and the chain of dependencies and dependents.

Bottom line is that we need all the help in comprehending and making valid updates to the model that we can get. 

If you have not felt this pain personally, I highly recommend you do so. A reasonable exercise would be to take this medium complexity model and add 100mm to the X travel in a manner consistent with how the whole thing is modeled.

pete_yodis

Also like this this discussion, but from a different vantage point.

A little bit of a divergence here, but I suspect something like what Siemens is doing with Synchronous Technology would simplify the need to track and manage and troubleshoot and change the dependencies that we create with pure history based modelling.  I agree there is a better way to manage the relationships with history based modeling, but I also suspect there is a way to greatly lessen the need for them.  I often work with semi-complicated cast enclosures that can get fairly involved for myself as the designer/engineer let alone someone that would have to pick them up and edit them later down the road.  I don't think a method like sync tech is a magic bullet, but from what I have seen and heard from users themselves (pretty legit users too, I've checked it out)  - it goes a long way to reduce the tangled web that we weave for ourselves.

traveler_hauptman

NX (nor Unigraphics) is something I have not had a chance use. I looked at the marketing material for synchronous technology. Good stuff.

wiley

@traveler_hauptman Wouldn't a a list of tags and the ability to filter by tags achieve the same thing as groups? I see your point about the two scenarios (managing your own model vs. understanding someone else' model). I think for getting up to speed on all the "dumb decisions" someone else made, an "animate build" button where you could watch the model be built...might help get a quick sense of the timeline and decision-making process that went into the design. Combine that with showing comments while hovering/clicking over feature tree items, and a toggleable list of tags (along with an instance count for each unique tag) and I'd think one could get up to speed on a new model fairly quickly. Just a thought.

andrew_troup

@wiley
It is the interactions between features and sketches which get lost when filtering according to tag, and those interactions are crucial.

A solid model's feature list is effectively a recipe. We don't get a feel for how French bread is made by extracting a list of ingredients, which is only about four simple items. Nor by listing the processes involved.

Any aspect, shorn of context or taken in isolation, tells us little about the whole product. It's the intricate web of internal and external interactions and processes which deliver the crust, crumb and colour, not to mention smell and taste.
 

(hmmm ... note to self: shouldn't write this on an empty stomach)

traveler_hauptman

@wiley Not with the typical implementation of tags. 

A simple way to look at it is that you can't tag a tag but you can add a group to a group. 

However I can select 5 features and tag them "interface" and then select those same 5 features plus another 20 and tag them "business end".  Let's even say the selection interface is uncommonly good and the effort of selection is the same as with groups.

Does that achieve the same thing as a group? 

No, not really.

The difference is that a group must also follow the structural rules of the model. Everytime I select a group and then try to perform an operation on it (move it, copy it, add to it, remove from it) it does a bunch of work to make sure that the operation is valid.

Restriction to valid operations has two benefits. 1) The UI can be simplified to present only relevant options. 2) I don't have to check for validity myself.

That's part of why I think they are different things.

However this whole conversation can get murky real quick. It's all part of a continuum. One could say that groups are just tags with sophisticated business logic. And one could imagine that the Onshape team implement a tag system that spans the continuum to include all the sanity checking and workflow simplification that a separate 'group' feature would implement. It's up to them to figure out implementation.

The key thing for me is to be able to take a complex model and make it easier to understand and work with. The typical tags implementation would not be enough for me.