extrude-cut through all problem

[Anonymous]

I am finally getting to the point of designing an assembly in F360 and quickly ran into a very puzzling behavior.

I had assumed that when a component is active then I am editing just that component. That would make sense since the component is conceptually an individual part. But in fact if I do an extrude-cut and select 'all' for extents then the cut goes through all the components in my assembly.

This is very different from editing in-context in Solidworks where "through all" refers to 'all' features in the part rather than 'all' parts. But it is not just a difference between CAD systems. Here is an example where it becomes a problem:

Here I made two components. WIth the upper one active I made a sketch and cut the two holes. I really want them to go just through the upper component. I can't use the 'to' option because the bottom surface of the componenet is stepped. In any case, it would be a bother since what I want is obvous - a cut through the component. The dialog box does have an "Objects to Cut" item but the only choices are "2 bodies" and "auto", both of which select both components. It seems to me that the second body should not even be a possibility since it is not part of the active component. What is the sense of an "active component" if it gets mixed up with other components?

If I isolate the top component before making the cut then the cut only goes through that component. But this seems a messy work-around since I may have good reason to have both bodies visible during editing. It also confuses the purpose of "isolate". Is it a viewing tool or a functional tool or both?

I don't know if this is a bug, a badly thought-out decision, or I am missing some advantage to this way of working. I could put in a feature request but this feels more like a bug than a missing feature.

[PhilProcarioJr]

All you have to do is make sure that only the items you want to cut are visible. Use the lightbulb next to the objects to toggle visibility.

[Anonymous]

Thanks - I had finally figured that out. But I think that is a really bad design decision.. There are at least five things wrong with it:

1. A component is an independent entity. The default behavior for editing an independent entity should not be to modify other entities.

2. It is poor practice for two completely separate functions to be coupled to each other. View controls (e.g. visibility) should be about viewing only. Editing controls should be about editing only. One example of why they should remain separated: Given two components A and B: activate A, hide B, make a cut through A, unhide B, and then edit the cut (or related sketch) in A. What should happen? Does the cut now propagate through B or is it locked to only go through A? Does the hidden state at the time the cut was made become part of the timeline? This gets messy and can lead to all sorts of errors.

3. In a complex assembly the user may want to have some parts hidden because they are in the way and some parts visible for reference. This should not become further complicated by having to hide parts to control feature generation. The lack of flexible control of component visibility in assemblies has already been commented on by a number of participants; this just makes the problem worse.

4. This behavior is inconsistent with other tools. In fact F360 gets confused about it. In my test model I activated component 'A' and edited its extrude-cut and changed it to an extrude-add. I then hid the 'B' component using the context menu so I could check the 'A' part. But then I could not make the 'B' component visible again. Hiding and unhiding, changing the activation, or saving and re-opening the model did not fix this. So there really is a bug here, which may relate to the inconsistency of the cut behavior.

5. This behavior does not appear to serve any great purpose. It might be good for a demo: “We make two components, put a hole through both, and put an axle through them!” But in a real design it is rare to put an identical cut through two adjacent components. More likely a cut in one and a projection on the other, or one cut offset from the other, or one of many other variations. Again I have to refer to Solidworks, which does have an assembly-cut feature but saves it for special purposes (e.g. drilling a hole through already assembled components).

How hard would it be to change this mis-behavior? A couple of options:

1) Add one more choice to the “Objects to Cut” item and preferably make it the default: “Active Component”. With this setting F360 should behave as if the active component were isolated.

2) Just change the behavior so a cut in an active component never effects anything outside the component. This would be the safer solution and would avoid downstream problems. If a cut-multiple-components tools is wanted then put it on the assembly/model level where it makes sense in terms of design intent.

[Anonymous]

Here is the link to the buggy model descirbed in my previous post. On my computer it has a component that has become invisible.

http://a360.co/1W1rq3Z

[Anonymous]

Well - one more post. In that "buggy" model it turned out that the body within the component had been hidden. My mistake, but why does F360 hide the body instead of the component (using the context menu), especially when another component is active. Wouldn't it make more sense to hide the entire component in this case since the user is working on a component level? I obviously don't understand the thinking here.

[TrippyLighting]

Fusion does not hide bodies on it's own. That requires user interaction 😉

[Anonymous]

Um yeah - I get that. I had one component active, then right-clicked on another component and picked hide/unhide from the context menu. I assumed (incorrectly) that on this working-on-a-component level my action would hide a component. Instead it hid the body within the component. This is really a minor issue but goes back to my original concern - When working with an active component it does not seem to make sense for there to be interaction with *any* bodies that are contained in another component. Analogy: In C++ or Python it is considered very bad form to have a method in one class directly modify a field of another class, even if both classes are in the same file.

[PhilProcarioJr]

@Anonymous

The reason your experiencing the things you are is because Fusion doesn't use different files for parts and assemblies. They are both one and the same. In order for that concept to work it has to be set up in a way that is at least similar to what it is now. Granted it may not be ideal but it's not terrible once you get used to thinking differently. The entire idea behind Fusion 360 is different, you have to break away from conventional because Fusion is not that copy everyone else way of thinking. But by all means if you have better ways to do things in Fusion post them to the idea station and let others voice their opinion. If the masses agree they will make changes to the software, but in the mean time it is what it is. We are just trying to help you and others get your work done.

[jeff_strater]

thanks for your comments @Anonymous, and the replies @PhilProcarioJr and @TrippyLighting.  I can discuss a bit about the thinking behind the way this works.  You can make your own decisions about whether you like it or not...

When Fusion was first getting started, we wanted to make it as flexible as possible.  One of the guiding principles was to try to avoid the rigidity of traditional CAD systems, where each part and assembly is required to be a separate document, and where these documents are strongly typed (each document is either a part or an assembly, and changing your mind later is nearly impossible without breaking the design).  So, this is how we came to the idea of a generic "component".  A Fusion component can be a "part" (if it only has bodies), or an "assembly" (if it only has child components), or a weird kind of hybrid (if it has both bodies and child components).  Second, we wanted to not require separate documents for each component.  This is why you can make an entire design in Fusion, with many components, all in a single design document.  In fact, it wasn't until a year ago that we even added the concept of externally referenced design documents.  Next, we did not want to overly restrict which components you can operate on at any given time by having a restrictive mode that isolates you to only operate on a single component at a time.  So, in a single Fillet command, you can select edges from many different components.  Or, if you want to punch a hole through multiple components, you can do that.

However, this created a different problem for us:  we needed a method to determine which component owns things like sketches or work geometry.  We tried for a while to automatically assign ownership based on selection (if  you sketch on a face that is in a body owned by a component, then that component owns that sketch), but this didn't always work out.  Sometimes you do want to sketch on the face of one component, but have that sketch owned by a different component.  This is where the "active component" concept came from.  We needed some way to indicate where new objects would be owned.  Now, I will admit that this has caused some confusion, particularly among folks coming from Solidworks or Inventor, which have a much stronger notion of "edit in context".  Others have also been surprised to see that even though a component is active, I can affect other components.  So, it's a valid point.  However, once you realize what component activation is (and what it isn't), you will most likely find that the added flexibility is useful at times.

The third thing here is the "feature participant" model in Fusion.  This is really only a problem for Cut operations.  Join only joins to one body, but a Cut can affect many.  So, we need a way to specify which components or bodies are cut.  Our original preferred method was some kind of a list/chooser widget where you could manually turn off and on participants.  And, I think we will end up there some day.  But, the reality was that we had a lot to do, and this was a low-priority requirement, so we looked around for other ways to control what is affected.  Visibility seemed like an obvious choice.  You only cut what you can see.  If you want to change what has been cut, you can make it invisible, even while in the Extrude command.  I'm obviously biased, but I think it works pretty well.  It certainly is simple.  It originally caused some other problems (like changing the bodies/components affected during during edit feature), but I think we have all that fixed now.

So, in summary - I expect that we will change the participant model UI to be more explicit, and to not rely solely on visibility, some time in the future.  But, we don't have any plans to change the active component model any time soon.

Jeff Strater (Fusion development)

[Anonymous]

Jeff - I really appreciate your very detailed reply. I am very aware of the efforts you folks have made to create a more flexible and easy-to-use CAD environment. And I realize that my SW experience may get in the way sometimes.

The all-in-one assembly concept is great. In SW I do use the “internal part” functionality but it is limited and a bit clunky. Generally I am very impressed with the rethinking that has been done in F360. Sometimes it makes things go faster. Other times it actually requires more steps but creates a more logically organized model.

Given all that, I still think that the current behavior of extrude-cut-through is a mistake and will come back to bite you! You are creating some funny dependencies, where a cut in one component is “owned” by another component. And to deal with the question of how the hole should update after an edit you must be saving some state information that does not appear to the user in the timeline. Maybe putting links between components to keep track of where the cut should propagate? I have been playing around with editing extrude-cuts – turning them into extrude-add and back again – and have seen some funny results, which I will try to save.

From the user point of view (as opposed to what is happening under the hood) I think there is an issue about design intent. Where possible, intent should be explicit. This avoids confusion later when changes are made or new parts are added. It also avoids mistakes that don't get noticed till they become expensive to fix.

Explicit: “The hole goes through only the active component.”

Implicit: “The other component was hidden (and so the hole only went through this component).”

Being able to select “active component” for the “objects to cut” would make the choice explicit. It would provide a clear reference to user (and the programmer) when later editing the feature or sketch.

I can of course work around this issue and I know there is still much work to be done on F360. I am bothering about it because I think it is a bit of wrong in a mostly very right system.

[PhilProcarioJr]

The problem with your example is if only models in the active component can be cut then that negates having a part and assembly as one file. I cut many models in different components all the time and don't have a problem with design intent or unexspected results. You just have to think differently. For instance I may move a cut but I still want it to cut the same pieces, and if I don't then I edit the operation that cuts so models I don't want to cut or do are set to the proper visibility. I come from Solidworks myself and until I started thinking differently I thought the way you do. So I understand, but the way you think it should be would cause problems.

Just my 2 cents.

[TrippyLighting]

If I understand it correctly the aim is not to not prohibit it cuting other than the actve object but make the choice what is being cut and what not, explicit. Let the user actively choose what object is cut with an interface that makes it clear on editing what was selected initially. I find that a very reasonable request and would support it.

Currently this is done implicitely by hiding components that you don't want to have cut. If you go back and edit it, it's not recorded anywehre what was visible when the cut was performed. You'd have to guess by what is being cut at the moment.

In a more complex model I can see the benefit of making the choice of what is being cut explicitely.

[jeff_strater · Accepted solution]

A few more comments (sorry, I was on vacation last week, and am still digging out from the pile of email...)

Agreed - the "cut what is visible" method of picking cut participants could be considered less-than-ideal.  And, again, our goal is to someday replace it with better UI (a more explicit list of participants, for example, has been discussed).  But, if you spend as much time on this forum as @TrippyLighting and @PhilProcarioJr or, if you go look at the Fusion 360 Idea Station, you will agree that we have a LOT of stuff to do in Fusion.  We'd love to get it all done right now.  This one, in particular, is one that our head UX guy also shares your view on.   However, to be completely honest, things that are a bit cumbersome, but generally get the job done, are probably going to take a bit of time to get around to.

The other comment is to explain a bit about what goes on behind the curtain.  The UI for picking participants by visibility is only used in two places:  1) when first creating the feature, and 2) when editing the feature (more on edit in a minute).  Once the participants are selected at creation time, those are tracked internally, and on a compute, only those bodies or components will be affected, regardless of what components are visible.

I mentioned edit feature.  This is the other time that the visibility UI can come into effect.  Just like create, we need some UI to allow you to change the participants.  So, Fusion again uses the visibility UI to do this.  But, there is one fairly recent change here.  Not that long ago, when you edited a feature, the participant list was updated from whatever was visible at the time of the edit.  So, if you had a stack of components A -> B -> C -> D in that order, and you sketch on component D, then cut all the way to A, but turn off B and C, then you create a feature that cuts only A and D.  If you then later make B and C visible, compute will still only cut A and D.  But, Fusion does not remember component visibility states when you edit (otherwise, your timeline would have lots and lots of visibility features in it).  Before this change, though, if you edited your feature, and just changed, say the depth, it would bring B and C into the feature.  This was very bad.  Now, we have UI in the feature edit to choose to either keep the existing participants, or to "auto select" them (meaning, use their visibility states):

This, at least, prevented some really bad design errors from occurring.

Still, it's not the final UI, but it does more or less work today.

Jeff

[Anonymous]

Thanks all for your comments and information. I'm happy to accept this as a "solution". It since it is clear that the developers are well aware of this issue (and related ones) and plan to deal with it.

I think an interesting take away is that the flexibility of F360 is great asset but that this very flexibility can lead to some 'gotchas'. Sometimes a little constraint can actually make life easier. An example I like is how F360  handles references to other geometry in sketching. Solidworks lets you just click on anything while you are sketching; F360 makes you use project/include first to obtain the references. At first I saw this as a bother but I realized that it made me think carefully about what I was doing and that, in effect, it documents my sketches to show the relations to other geometry. Now when I sketch in SW I try to follow the same pattern; I use points and construction lines to get external references and then use these as references for my new sketch elements.

[docara]

Hi

I have just found this post after trying to find a solution to accidentally having a component cut through and not able to find out where in the time line.

Just to add something to the (old) conversation, to state that yo wanted to do something different from other CAD systems is to be applauded BUT please don't forget other CAD system are not necessarily wrong (you know what I mean).

Have any of you (the developers) properly sat down and used SolidEdge? The UI is SO intuitive and natural - this is what you need to aim for. If I could afford it I would not hesitate to buy it. It doesn't matter how good your software is, it matters if the user finds it easy to use and can be productive with it. From someone who has come from AutoCAD and who is REALLY struggling with F360 some of the UI just doesn't make any rational sense. Why for instance, in Extrude, do you have to grab and move the arrow then either choose a measurement or a face whatever. I've chosen the face just let me enter a measurement, or grab the arrow to indicate positive or negative dimension I should not then have to specify a minus sign. Snaps don't work in 3D why don't sketches update when we change the 3D model - the list goes on.

What I am trying to say is your software needs to be intuitive to use, F360 is definitely not! I've mentioned this elsewhere here but the frustration levels with F360 has brought close to tears a couple of times now and I've been in the IT game for many many years - I know software. To me if something on the screen is bold/lit up/solid then it should be affected by what is going on. If it is dim/dashed then it is there for reference. I should be able to choose via the mouse and a key press what I want to do - click on a dimmed body it becomes active . Shift+Click it becomes inactive that sort of thing needs to be considered / introduced

Please- you are Autodesk the designers of AutoCAD please go back there and take a look at what you developed - the method of data entry the way the interface works is sublime, the dashed lines for selections the prominence of objects/lines etc the way you can type into the command line and the command line gives you a prompt and a helping hand and lastly a help system that is so good you don't need a forum for basic functionality.

Lastly, I think you guys are almost too clever and have lost sight of the user (sorry). You guys need to keep nodding towards your intended user base. If it is a hobbyist level things need to be obvious. If it is professional designers then a nod towards other packages they might be using is necessary but the common factor between them is we don't know how your software works or what it wants from us in order for us to use it properly so it needs to be simple, obvious and intuitive in use.

Why not get someone who doesn't CAD but can draw and get them to try and use it and monitor their actions get feedback and thoughts.

Matt