My workflow and future

[Anonymous]

Ok, so going through an example component, I discuss a modified workflow in this short video (please turn resolution to 720p) that is already doable/usable, and with few very minor adjustments to Fusion360 could be the default workflow, with I believe considerable enhancement of user friendliness and power -- i.e. for big prime time.  An additional short video is coming up that deals with the timeline aspect of this workflow that is quite exciting. 

Any feedback is greatly appreciated.

Jesse

[Anonymous]

Although I don't discuss the timeline aspects much yet in this first video, I did mention a little about timeline dependency ordering I manually do, vs the default pure sequential ordering.  I forgot to include in the short mention in the video of how a new timeline event can manually or potentially automatically move/sift back in time, until coming to an event that it depends on or would change the model if it crossed, hence creating the 'dependency ordering'.  Besides some additional independent/dependent component grouping and what not I will soon discuss, it also creates a much more comprehensible timeline, and simplified, say a new move event manually or auto replacing a previous move that it sifted adjacent to (and lots of other moving/editing essentially being direct modeling via sketch modification, for which no timeline events are captured), and improving performance by the solver always fully knowing the dependency tree and what needs recomputing, etc. 

Jesse 

[TrippyLighting]

Nice approach.
when you have an assembly with many components and always have the top level active the timeline will get very long and hard to manage.
The second problem is that if you want to export a component for reuse in another design you'll loose alle the sketches because they are not part of that component as you never activated it. You'll loose the parametric nature of the component

Both of these problems are solved by first creating an empty component and then activating it.
The timeline is filtered down to only those operations that pertain to the active component and is naturally much shorter and quite managable.
To further manage timeline better you can group items in the timeline and also name them infpdividually.
With the sketches in then component you'll also retain its full parametric nature. It's also not only the sketches but other things as well that accumulate at top level and will make an assembly difficult to manage. Joint origins are also part of a component.

[Anonymous]

Thanks for the feedback!

I didn't make everything really clear for this workflow yet, so here are some main points:

1) Having everything related to a component (sketches, bodies, construction planes, joints for subcomponents, etc) be located in the component folder is the way to go, including for this workflow.  However as you mentioned in an idea request, to allow the most natural user friendly workflow, users should be able to drag sketches into the component folder at any time, provided the sketch is not also directly driving another component body (but could be driving another component sketch through projection...as mentioned in the video, in my workflow sketches stay attached to spatially moved components in the model workspace, even when editing the sketches, so this does allow powerful in place projection of one component sketch into another component sketch).  When a sketch is moved into a component folder, anything directly driven by that sketch, such as bodies and offset planes, and other sketches defined by these body faces and offset planes, should move into that component folder automatically.  I just could not drag driving sketches into other components now of course because it's not currently supported, but wanted to demonstrate the user friendly nature of 'free flow' working, rather than constantly trying to stay mindful of proper component activation and deactivation. 

2) Moving a sketch into a component folder should automatically redefine the sketch coordinate system (CS) (as well as bodies, offset planes, etc. directly driven by that sketch) to the component CS, similar to as now occurs with moving a body into a component.  Note that this CS redefinition does not spatially move anything, since essentially 'sub CS' are used to deal with offset positions and angles with respect to the component CS (in the video I manually made a sub CS, via creating an empty subcomponent within the component, to manually redefine a sketch to).    

Note that I believe the event of a folder move of a sketch (and corresponding auto folder move of its directly driven features) into a component should not have its own timeline event (nor should body moves, which while fortunately are currently allowed, unfortunately generate a folder move timeline event), as this not only clutters the timeline and needlessly complicates a dependency ordered timeline I will further discuss soon, but also creates a useless placeholder (the folder move event) instead of the actual creation event in a timeline filtered by activating a component.

Will list more main aspects of this workflow soon.

Jesse 

[Anonymous]

3) Because (a) sketches of a component are defined by that component CS or subCS, and (b) because of dependency timeline ordering (which I now do manually), in this workflow as you can see sketches spatially move with component in component moves/aligns, and this new sketch position is held even when going into editing a sketch, being nice in general and allowing as I mentioned projection of a component feature (from a body, face, sketch etc.) into the sketch of a second component and hence being able to drive that second component from feature(s) of the first.  This is not shown in the video but can demonstrate this if there is interest.  

....More to come

[Anonymous]

And keep the feedback coming!

[Anonymous]

Any thing you would do differently/is impossible, before I submit it to the idea station?

[Anonymous]

Note it is somewhat unusual and tricky to understand, I will make a more concise clear video/or series of illustrations of the workflow soon. 

Jesse

[daniel_lyall]

you where going a bit fast through your ideas there is a lot to rember but you putting it on you tube I will just down load it

[jeff_strater]

That is a very clever workflow, Jesse.  I like it.  I will admit to scratching my head a lot in the section from 4:30 to 5:15...  You created a new sub-component in the Loft, then used the origin CS of that new component to Redefine that base sketch.  I even wrote on my notes:  "that should not be possible!".  I must have watched that little section 4 times .  It wasn't until a little later (around 6:30) that I saw what I had missed the first time - you had reordered the component creation feature to before the sketch.  Tricky!  Whether that is really easier than creating an empty component and activating it is debatable, but it does allow you to make it work when you forget to do that step, which I do all the time.

some other things I noticed:  

:45 (can't offset from projected geometry).  That is a bug - you should be able to do that.  

4:25:  Regarding not being able to restructure a sketch into the component that you create from that sketch, we are working on that!  We hope to get it done soon.  We do hear everyone on that item.

5:00 The redefine.  If the offset plane was made from the sketch, then it should come along when the base sketch is redefined, and the sketch on it should come too, and the projected geometry as well.  here is a short screencast showing this: http://autode.sk/1IFuOv3  I am still not sure what the difference is between this and what is in your video.  There may be a bug there.

Anyway, I found this very valuable.  Keep contributing stuff like this!

Jeff Strater (Fusion development)

[TrippyLighting]

Before posting it in the idea form please consder the following:

1. It takes you more than 4 minutes of a total 9 minutes of video to get to the actual core message "the real kicker". What comes before that shows good commandment of the available tools but is unneccessary to convey your main point and actually distracts from it. People have short attention spans 😉
2. Actually this should be the point. The purpose of an alternative workflow is to adress a problem or increase effectiveness and/or efficiency. Your video never really states what the actual problem(s) is(are) you are trying to address.
3. As such it is hard to tell what part of you differnt workflow adresses what particular problem. I needed to watch this twice and have a short attenion span as well.
4. It is not really clear in the video what it is that actually requires a change to the functioanlity of the software and what is actually simply a different workflow using existing functionality. For example at about 4:30 you start mentioning that if you "dragged the base sketch into the component that depedet on it it would redefine that sketch....". That functionality does currently not exist in in Fusion so your vid essentially mixes existing functionality with what you'd like to see in the future without making any dstinction betwen these at all. For users that are less well versed this is hightly confusing!

For posting this in the idea forum you can shorten this to 1-2 minutes max. The key points should fit on one slide using a 30 point font 😉

The workflow is interesting, however, it should not be a replacement for keeping all objects pertaing to a component in that component.

I am looking forward to yor timeline video! The timeline can really be a blessing and a curse 😉

[Anonymous]

LOL, sorry about 'reordering' the video a little like that 😉  I'm glad you find it interesting!  

Thanks for that screencast.  The problem I was having was when the first base sketch is redefined to a new component origin CS, and then doing a component move of that component (and consequently its origin CS).  It can cause geometry that is on the second sketch (that was defined onto an offset plane from the first sketch) to slide if it is not geometry projected from the first sketch, and hence I redefined that second sketch to a displaced subcomponent origin CS.  

I would like to go even more in depth with all this, but I need to focus on some other stuff for right now. 

All the best,

Jesse

[Anonymous]

Thanks for those points made TrippyLighting, they are very helpful, and will be well considered when making a refined very short video. 

The way things were presented it may have sounded like the workflow tries to not utilize organizing objects into pertinent components, but that is not the case.  In fact now with this workflow I do first create components and activate them.  But basically this workflow addresses somewhat new ways of how object and component organization, objects and their defined coordinate systems and the timeline interact with each other, and if tailored to this workflow, can form a very user friendly and I believe enhanced power environment than currently exists (and that's hard to claim), with relatively little modification. 

Jesse

[Anonymous]

Jeff wrote: "...you had reordered the component creation feature to before the sketch.  Tricky!  Whether that is really easier than creating an empty component and activating it is debatable, but it does allow you to make it work when you forget to do that step, which I do all the time."

I will just add for now that in a dependency ordered timeline scheme, which I will try to go into soon, this logical reordering would be done automatically, rather than manually as I did.  Note that when I manually reordered the component origin CS creation events and snapshots all to the timeline beginning, sketches can also be opened/edited and still maintain their positions with spatially moved components, significantly improving the workflow just from that and adding more functionalities.  There are other small things that if added for this updated timeline scheme would make for a very user friendly and powerful timeline, and also allow joints and rigid groups to still work properly, including updating their CS when sketches are updated that drive component faces.

Jesse 

[Anonymous]

I just had a thought, that I need to clarify what is causing the problem mentioned 5 minutes into that video with the moving and sliding.  Here are 4 tested scenarios and their results (note that loft body is located in the Created Component (CC) for all four, and no projected geometry was used/harmed in this experiment):

1) So if the base sketch, the offset plane and Sketch On Offset Plane (SOOP) are all located in CC (and consequently all are defined by this component CS or 'sub CSs" with simple displacements), then all come along when component is moved, and if snapshot is temporally placed before both sketches, then they are editable at new spatial location as well. 

2) If the construction plane is not in the CC, but both sketches are, then everything still works fine for a spatial move and the snapshot temporal placement.

3) If the base sketch is not in the C, but is redefined to the CC CS, the offset plane is in the CC, and the SOOP is not in CC nor redefined to it, then spatially moving component of course does not spatially move sketches or offset plane until the snapshot is temporally placed before both sketches. 

So far this is as would be expected, but here is where things get a little weird.

4) If the base sketch is not in the CC, but is redefined to the CC CS, the offset plane is not in the CC, and the SOOP is not in the component nor redefined to it, then as in (3) no sketch or offset plane movement upon CC spatial movement until snapshot is temporally placed before sketches.  When this is done, the base sketch moves to updated spatial position, yet the SOOP sketch will only be affected by CC motion perpendicular/normal to the offset plane it is on (with the snapshot temporally placed before it), not moving at all with a tangential motion snapshot before it.  Apparently, as it now stands, within the software an offset construction plane (and other construction planes likely) can have two aspects to its CS definition, its normal and tangential definition.  This like you said sounds like a bug, and is why for the workflow I used that empty subcomponent CS to redefine the SOOP in the demo trying to showcase the flow of not having to worry about if/when activate components. 

Well, I need to go to bed. 

Thanks for taking interest in this Jeff!

Jesse   

[fredsi]

Jesse,

1) To second what Daniel said, one less double shot expresso prior to making the video(s)   Some times have trouble following the flying cursor...

2) To amplify on TrippyLighting's point...would like to see the first part of any video explain the problem you are addressing and the second part detail the solution.

3) Lastly, if I remember, in an earlier post you mentioned that you develop all your parts (components) individually and assemble in a separate document....is that correct?

Thanks.

Fred

[Anonymous]

Haha, good tip there with the expresso

I think the comment you might be referring to is where I said if one or a few components is worked on exclusively for awhile, the current (purely sequential) timeline scheme will nevertheless then have a section of clean grouping of actions only applying to that component or few components, and so that might be a convenient place to create a grouping in the timeline, if it is geological and in need of some consolidation.  When you import a component, it has that same kind of independent group created in the timeline.  But no, I don't normally import components (just now I had the thought, for massive assemblies individual components could first be converted to a DM feature before importing to the massive assembly, could perhaps be useful).

I also recommend being sure the 'Component color swatch' is turned on in the little timeline settings area (gear on the bottom right), as this helps indicate for timeline actions which component they belong to via color coding.   

Jesse 

[Anonymous]

I wanted to mention I don't really need to use this custom workflow very much.  Also I found being sure the 'Active component visibility' in settings is turned on really helps keep awareness of which component is currently active 🙂

Jesse