Automatic Feature Folders from which part the features affect

maximilian_schommer

So this is a two part improvement request. First is that feature folders can include features which are not necessarily consecutive. The reason for this is that I would like to be able to put all features which affect a certain part in a single folder, that way it is clear which features are modifying which parts.

Next I'd like an automated way to put all features in folders based on which parts they affect. This would make it really easy to organize part studios, and see what features are doing what.

Max

owen_sparks

How would you maintain visibility of what order the features are to be executed in?

Owen S.

MBartlett21

Also, what about sketches?
And features that affect multiple parts?

maximilian_schommer

@owen_sparks Maybe it could be an alternate view where the features aren't necessarily in chronological order, but the view could be switched by a drop-down. Currently in the "filter" we can see all features affecting a part by searching `part: [String]`. Maybe there could be a view where we see all of the parts as folders in the feature tree, where every part has each feature and sketch that it is derived from. To @MBartlett21 I would probably think that a feature affecting multiple parts would show up in each part folder? Maybe color it differently to show it affects multiple parts? And if you hover over the feature you can see what parts it affects?

tim_hess427

I do think there could be better ways to see which features affect which parts, but I don't think folders in the way you describe them would be very useful (and I'm not sure it would be technically possible) because each feature only really makes sense in the context of the timeline for the part studio and each feature varied numbers of references and outputs. 

I could have a feature that modifies Part 1, but later on, a different feature deletes Part 1 or merges it with a different part. In another scenario, something like a pattern could have several references and create many many parts. In these cases, it could be hard to automatically create useful folder structures.

Instead of folders, I wonder if a simple filter that only shows features affecting a certain entity (could be a part, sketch, plane, surface...) could be interesting. It would just work backwards through all feature references and hide things from the feature tree that are not used. In this way, the order of the features is maintained, but you are still able to more quickly see that changing Sketch 10 affects Part 5, for example.

**The more I think about this, being able to quickly query dependencies throughout an entire model tree like this could be really useful for making changes to models (especially if its something someone else made or you haven't worked on it in a while). It could really help avoid problems where editing one dimension in an early sketch has unintended downstream consequences. 

maximilian_schommer

@tim_hess427 So there is the feature filter-by-part, which gives what you want for any individual part. What I think would be helpful is some sort of view which lets you instead of seeing just a feature tree, maybe see all features organized in this way for every part (where features can show up in multiple parts if they affect multiple parts, maybe with some visual indicator that they affect multiple parts). As you mentioned, I'm not sure if a "folder view" would be helpful or intuitive, but some way to visualize this could  be really helpful in organizing features, since a lot of the times what I'm interested in is how changing a feature will change all of my parts.

tim_hess427

@maximilian_schommer - Thanks for the tip! I never realized the filter could function that way.

I do think being able to see all of the dependencies in the model more explicitly would be interesting. 

I'm thinking back to one part studio I have with a couple hundred features, multiple parts, and multiple configurations for those parts. I would imagine any visualization of all those connections would be too busy to be useful without some serious filtering. But maybe all it would need to do is show me "what is affected if I edit feature X".  That could really be useful for "debugging".