Insert Derive vs Insert Design - any woohoo.. I mean opinions?

[lichtzeichenanlage]

Sounds good, doesn't it?

• Editable in the link destination EDIT: (including hiding/showing bodies, sketches etc.)
• Receive updates from the source
• Cross project?
• Components, sketches bodies etc. are selecteable on the fly

[michallach81]

too soon to judge, but it might be no reason to insert design from now on.

[lichtzeichenanlage]

Sure, I'm early with this thread. But it looks like, AD has eliminated most of the down sides that do come with linked components (insert design). 

[michallach81]

Implementation is quite specific which will make only certain workflows possible, but it looks reasonable.

[lichtzeichenanlage]

Specific? I find it incredible flexible compared to insert design. But I don't know other CAD systems. What's so specific?

[kgrunawalt · Accepted solution]

Insert design allows you to insert an instance into the current active component. Derive design (when you select components in the source and choose the "model objects" option) will create instances in the top-level of the target design only.

If you want to instance the entire source model in the target model and you don't want to modify a copy in the target, you should continue to use insert. This would make it ready for any insert-specific functionality we add in the future.

Derive allows reuse of parts of the source when you don't want the whole thing and it also allows modification of those parts in the target.

[jeff_strater · Accepted solution]

One thing to add to Katrin's post:  Insert is still more efficient than Derive.  During update, Derive is a local copy of the referenced, selected, portions of the design.  Insert does not create a local copy in the target design.  Your design will be larger using Derive, but you will have the added benefit of being able to modify the local copy of the design, in a way that is fully associative to the original.  This usage of Derive is much better than the old "Insert + Break Link" if you want to make local modifications to the referenced component.

There is also a bit more compute overhead to Derive when the source has changed, because that copy must be updated.

One more difference (Katrin, correct me if this is wrong):  If you do multiple Inserts of the same design, they will be instances of one single design.  If you do Multiple Derives, they will not be associated with each other.

[lichtzeichenanlage]

That derived designs can only be placed in the top level might be a bummer for some people. Most of my projects are not big enough to feel a strong need for sub-components so it might be fine for me.

The problem with inserted designs is, that they are not easy to handle. Showing/hiding sketches, planes etc. is one week point and that they are not cross project is the other point I don't like at all. 

[lichtzeichenanlage]

That it takes moor compute time because of the local copy sounds logical. But isn't that true for the "old" insert design method, too? Because they don't work cross project users had to create copies anyway.

That multiple inserts of a derived design are different instances is different to the old behavior, but sounds logical, too. As long as I copy an component around I'm visualizing the intend that this is one and the same part. It looks like this is working for Ctrl+C / Ctrl + V as well as for patterns. If I'm inserting a derived design a 2nd time I'm adding a new "template" for a different part. Makes sense for me.

But I never guessed it. So thanks for pointing out.

[kgrunawalt · Accepted solution]

Jeff makes a good point about efficiency and is correct that multiple derives are independent copies (you can make more instances of derived component using move/copy just like regular components). If you want multiple instances of a derived component with no separate modifications of each one, use move/copy and don't derive it multiple times.

I'll just add a note about derive efficiency. Derive is efficient in its own way. The derive copy is not recomputed unless the derive link is updated to a newer version or a "compute all" is forced by the user. This is true even if you roll back the timeline and edit before the derive feature because it is not dependent on earlier features.

So most of the time, after the derive is made, the target model does not need the source model and does not need to recompute the copied stuff. That is pretty efficient. However, it does require a copy where "insert" does not because "insert" is instancing the source model directly. That direct instancing is more appropriate for building an assembly from separate parts, all things being equal.

However, Fusion cannot insert an internal (non-root) component from a source model into a target model -- it inserts the entire source model. This is where "derive" can be good for reusing internal components (or bodies, sketches, etc.) even when they don't need to be modified in the target. The flat pattern case is a good example. This is where derive fills in a gap left by insert. Fusion can build internal components in a unique "top-down" fashion using the model's assembly context. Derive allows you to reuse these in other models associatively.

[lichtzeichenanlage]

@kgrunawalt, @jeff_strater: Unless we're now able to edit this imported parts, it would be great to rename them, too. It would make the browser cleaner and a BOM would make much more sense.

[lichtzeichenanlage]

@kgrunawalt, @jeff_strater: What's the idea behind making parameters importable (btw: nice visualization in the parameters window) but not making them editable. 

[kgrunawalt]

Good question. The derived parameters are not editable because editing them in the target would not cause corresponding changes in the derived geometry. We don't derive the entire recomputable recipe for the derive geometry, just the resulting components, bodies, etc.

You can make new features that modify the derived geometry, but you can't edit/recompute the features that produced the derived content separately in the target model. For example, an extrusion in the source model is not copied to the target and is therefore not editable in the target. Derive is not a feature-level derive. You can go back to the source and edit the features and then update the target.

So the derived parameters are useful for reference and you can create new features/parameters that use them in expressions. If we allowed you to edit them, it would be misleading and we could not update them from the source later without losing your edits.

[kgrunawalt]

Good point. I'll forward this.

[lichtzeichenanlage]

Okay - I get this. It's not great but I can understand it.

---

@kgrunawalt wrote:

Good question. The derived parameters are not editable because editing them in the target would not cause corresponding changes in the derived geometry. We don't derive the entire recomputable recipe for the derive geometry, just the resulting components, bodies, etc.

[kgrunawalt]

I can guess that you'd like derive to derive the recipe to allow more configurable results in the target by changing parameters. Is that right? Derive is not really "configure" in that sense because requires target-side features to achieve a variation.

For example, if you had an extruded profile, you could derive the profile and create an extrusion in the target with a custom length. Or you could derive the body and offset and end face some distance (if the end face is simple). However, with more complex designs, achieving a desired variation by adding features might be a challenge. In short, derive is not a full answer to configurations.

[dmorris750]

      I was really excited when I first saw the derive function, but now it seems that it too will not provide an answer to my problem(which I feel is a rather normal function to need and rather big negative to using fusion 360).

       As a simple example of my problem,  lets say that I want to build a drawer with a cutout for a lock in the face?  I set up the parameters for the drawer so the parts are parametric.  Giving a parameter for the drawer opening width, depth, and height.  I use those in functions to create parameters for other aspects of the individual parts such as, Drawer Front width, Drawer bottom length, etc.

     I would like to make an individual file of the lock and insert it into the drawer assembly file as a linked component and use that to create the cutout for the lock centered in the drawer front.  Such that if the shape of the lock ever changes, the cutout will change too in all the files it is used in and remain in the position I set in the drawing(lets say the location is specific, such as 10" from the left edge of the drawer and 2" down from the top edge of the drawer front).

     The only parameters that will really change from project to project are the opening width, depth, and height, so I make those parameters favorites.

  I would like to be able to put the completed assembly into new designs and be able to change only the favorite(or certain) parameters I selected which are opening width, depth, and height and have it change the parts accordingly while maintaining the lock position and link to the lock component in case it changes in the future.  The only way I know to be able to currently do this and maintain a link back to the original lock component is to make a copy of the completed assembly, modify the favorite parameters and then save the copy as the specific sized drawer(which will leave me with lots and lots of individually saved copies) and insert it into new projects, or create one master start file with every individual component and sub assembly that I may possibly need and work backwards deleting or hiding the unnecessary ones.  The latter solution leaving me with a HUGE and confusing list of parameters(side note....it would be SO nice to be able to sort parameters into named groups!!!!).

Am I missing a workflow that would let me modify the size of a sub assembly to fit a design, but still allow component changes to propagate??

The new derive feature is especially frustrating because it shows the parameters and functionality I need and have been waiting for right in front of me, BUT IT WON'T LET ME CLICK ON THEM TO CHANGE THEM!!!!

Please help!....I can't be the only one pulling their hair out over this!?!?!

[lichtzeichenanlage]

I thing insert derived design did a step in the right direction (compared to insert design) that it allows to e.g. extrude profiles. And that's great. But like @dmorris750 described changing the dimensions would be very useful, too. Or think about a cabinet that I can derive and alter the number of drawers (pattern). That would add so much flexibility.

IMHO you shouldn't worry to much about synchronization problems. Go for e.g. favorites and ask the user for a decision  in case of an conflict. 

[GRSnyder]

---

@dmorris750 wrote: I would like to be able to put the completed assembly into new designs and be able to change only the favorite(or certain) parameters I selected which are opening width, depth, and height and have it change the parts accordingly...I can't be the only one pulling their hair out over this!?!?!

This is the feature usually referred to as "configurations," as mentioned above by @kgrunawalt. Inventor has it but Fusion 360, as yet, does not. As you suspect, it's a very useful feature.

A pretty good work-around is the Fusion Sheeter add-in. See if that addresses your particular needs.

Forgive me for warping your comments into a reflection of my own pet peeve, but the lock-sizing issue you mention is yet another thing that seems like it would be easily solved by the ability to reference driven dimensions. But wouldn't Derive in its current form solve this as well? If you derive the lock into the drawer assembly, you can capture the sizing parameters for the lock. Just drive the shape of your lock recesses off those parameters.

[lichtzeichenanlage]

@GRSnyder: Sure, that could be configuration management. But this thread is about "Insert Derive" and how close it is to allow user to alter "linked / derived" designs in target designs. It allows e.g.e extrusions but not e.g. parameters. 

As much as I like Fusion Sheeter, but that's a different story. It only can change the source design (or generate new designs). It doesn't help to create a flexible component library. 

---

@GRSnyder wrote:

This is the feature usually referred to as "configurations," as mentioned above by @kgrunawalt. Inventor has it but Fusion 360, as yet, does not. As you suspect, it's a very useful feature.

A pretty good work-around is the Fusion Sheeter add-in. See if that addresses your particular needs.

Forgive me for warping your comments into a reflection of my own pet peeve, but the lock-sizing issue you mention is yet another thing that seems like it would be easily solved by the ability to reference driven dimensions. But wouldn't Derive in its current form solve this as well? If you derive the lock into the drawer assembly, you can capture the sizing parameters for the lock. Just drive the shape of your lock recesses off those parameters.

---