Fusion
Community
@Anonymous - if you would like to share your design here, we can take a look at it. Do you use large sketch patterns in this design? Those are known to be slow, and usually we recommend using feature or face pattern instead
Jeff Strater
Engineering Director
@Anonymous - if you would like to share your design here, we can take a look at it. Do you use large sketch patterns in this design? Those are known to be slow, and usually we recommend using feature or face pattern instead
Jeff Strater
Engineering Director
@Anonymous - a STEP file won't really help, as STEP export does not contain sketch information. See this article for information on how to share a Fusion design: How-to-share-a-Fusion-360-design . Any of those methods will work.
Regarding: "wouldn't it be prudent to fix it in the software rather than figure out work-arounds?". Obviously, yes, but any such fix is likely to take a long time to implement and make its way to the outside world. In the meantime, there are best practices and other recommendations that will make life more tolerable. It's up to individual users to decide whether those recommendations are worth following or not.
Also, not to be too defensive, but a constrained sketch implementation will always struggle if you throw a lot of complexity at it. Having the capability to dimension and constrain sketch primitives means that a lot of solving has to take place. Where other unconstrained sketch tools like Adobe Illustrator or Inkscape can handle thousands of primitives, that is largely because those tools don't have the ability to drive the sketch with dimensions and constraints. So, there is definitely a tradeoff here.
I look forward to seeing the design and understanding the source of the lagging that you are seeing.
Jeff Strater
Engineering Director
@Anonymous - a STEP file won't really help, as STEP export does not contain sketch information. See this article for information on how to share a Fusion design: How-to-share-a-Fusion-360-design . Any of those methods will work.
Regarding: "wouldn't it be prudent to fix it in the software rather than figure out work-arounds?". Obviously, yes, but any such fix is likely to take a long time to implement and make its way to the outside world. In the meantime, there are best practices and other recommendations that will make life more tolerable. It's up to individual users to decide whether those recommendations are worth following or not.
Also, not to be too defensive, but a constrained sketch implementation will always struggle if you throw a lot of complexity at it. Having the capability to dimension and constrain sketch primitives means that a lot of solving has to take place. Where other unconstrained sketch tools like Adobe Illustrator or Inkscape can handle thousands of primitives, that is largely because those tools don't have the ability to drive the sketch with dimensions and constraints. So, there is definitely a tradeoff here.
I look forward to seeing the design and understanding the source of the lagging that you are seeing.
Jeff Strater
Engineering Director
I see many other issues, but from the foundation - this sketch profile only need occur one time, should be fully constrained and could be simplified with a Feature Pattern. And then Component Pattern.
I see unresolved yellow highlighted issues indicated in the Timeline and tons of Moves.
The deeper I dig the more I find.
Unnecessarily complicated faceted faces.
This entire model could probably be simplified down to 5Meg or less.
I see many other issues, but from the foundation - this sketch profile only need occur one time, should be fully constrained and could be simplified with a Feature Pattern. And then Component Pattern.
I see unresolved yellow highlighted issues indicated in the Timeline and tons of Moves.
The deeper I dig the more I find.
Unnecessarily complicated faceted faces.
This entire model could probably be simplified down to 5Meg or less.
thanks for sharing the design, @Anonymous . It wasn't clear to me exactly which operations are "severe" for you. This started out as a sketch thread, so I assumed it was sketch issues, and I did find one sketch that has some concerns, but I wonder if your observations are more general than sketch.
A few observations:
- the mere size of the F3Z is an indication. This is not a very complex design, and it is 232MB (and that is compressed). That is a lot of data, and probably is at least partially responsible for the performance issues
- what I see is more of what I would call "compute performance". This is when you do a Compute All, or edit an early sketch and exit sketch mode, or change some parameter. This operation is VERY slow in this model. There are 871 features in this model. The 3 most expensive features are:
- Combine2 in "X_Carriage Assy" - this feature alone takes over 1 minute to compute. I'm not sure why, but it's worth looking at - is the tool body or target body extremely complex? Lots of faces? I did not look in detail
- Split1, also in "X_Carriage Assy", takes 10 sec to compute. Takes 10+ seconds to compute Again, worth investigating
- Sketch1 in "Y_Shaft_Clamp" takes over 8 seconds:
- Combine2 in "X_Carriage Assy" - this feature alone takes over 1 minute to compute. I'm not sure why, but it's worth looking at - is the tool body or target body extremely complex? Lots of faces? I did not look in detail
- the sketch, I was able to look into. It does have a LOT of projected geometry - from that faceted model that @TheCADWhisperer referred to. So, that body causes problems not just in its own complexity, but in the complexity of this sketch. You mentioned that you used mesh to BRep on that part. IMO, it would be worth re-modeling this body. You can use "Create Mesh Section Sketch" and "Fit Curves to Mesh Section" to help you create a sketch that would result in better geometry, which might help a lot.
- I noticed while I was investigating the sketch, that at that point in the timeline, there is a component called "OLD parts", which it looks like you may have used to contain previous versions of some of the component. I suspect (though I did not investigate any further) that you may have later "Removed" those components. THis is just a theory, but this may explain the F3Z file size. Remove is a timeline feature. Those components get removed only at that point in time, but all the geometry from them are still part of the design. This can get expensive, in terms of both compute time and file size (upload/download file open/save time). Might be worth seeing whether you really need those to hang around.
Finally, though it would be hard to do in this design, this is more for future designs: A lot of people have had success in segmenting large subsystems of the design into different F3Ds and assembling the whole thing in one top-level design - this can help with just this sort of compute performance, as it localizes those sub-assemblies' compute
Jeff Strater
Engineering Director
thanks for sharing the design, @Anonymous . It wasn't clear to me exactly which operations are "severe" for you. This started out as a sketch thread, so I assumed it was sketch issues, and I did find one sketch that has some concerns, but I wonder if your observations are more general than sketch.
A few observations:
- the mere size of the F3Z is an indication. This is not a very complex design, and it is 232MB (and that is compressed). That is a lot of data, and probably is at least partially responsible for the performance issues
- what I see is more of what I would call "compute performance". This is when you do a Compute All, or edit an early sketch and exit sketch mode, or change some parameter. This operation is VERY slow in this model. There are 871 features in this model. The 3 most expensive features are:
- Combine2 in "X_Carriage Assy" - this feature alone takes over 1 minute to compute. I'm not sure why, but it's worth looking at - is the tool body or target body extremely complex? Lots of faces? I did not look in detail
- Split1, also in "X_Carriage Assy", takes 10 sec to compute. Takes 10+ seconds to compute Again, worth investigating
- Sketch1 in "Y_Shaft_Clamp" takes over 8 seconds:
- Combine2 in "X_Carriage Assy" - this feature alone takes over 1 minute to compute. I'm not sure why, but it's worth looking at - is the tool body or target body extremely complex? Lots of faces? I did not look in detail
- the sketch, I was able to look into. It does have a LOT of projected geometry - from that faceted model that @TheCADWhisperer referred to. So, that body causes problems not just in its own complexity, but in the complexity of this sketch. You mentioned that you used mesh to BRep on that part. IMO, it would be worth re-modeling this body. You can use "Create Mesh Section Sketch" and "Fit Curves to Mesh Section" to help you create a sketch that would result in better geometry, which might help a lot.
- I noticed while I was investigating the sketch, that at that point in the timeline, there is a component called "OLD parts", which it looks like you may have used to contain previous versions of some of the component. I suspect (though I did not investigate any further) that you may have later "Removed" those components. THis is just a theory, but this may explain the F3Z file size. Remove is a timeline feature. Those components get removed only at that point in time, but all the geometry from them are still part of the design. This can get expensive, in terms of both compute time and file size (upload/download file open/save time). Might be worth seeing whether you really need those to hang around.
Finally, though it would be hard to do in this design, this is more for future designs: A lot of people have had success in segmenting large subsystems of the design into different F3Ds and assembling the whole thing in one top-level design - this can help with just this sort of compute performance, as it localizes those sub-assemblies' compute
Jeff Strater
Engineering Director
Forums Links
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
