Multi Part/Level Process Skeletal Method

[bradeneuropeArthur]

Hi @CGBenner @johnsonshiue,

Can anybody explain why in this method the "Derive Function/method" is not listed?

See video link:

Multi Level Process 

Also found in all help files:

Help File Multi Part Skeletal 

In all other skeletal methods this "Derive Function/method" is listed.

So there will be a good plausible reason I think that this is not to be used. I don't think that is is easily forgotten because it is explicit not written and listed in the explanation.

But why is this the  case.

[johnsonshiue]

Hi Arthur,

I am not sure who author the document. Anyway, from my perspective, Derive and Project (Adaptive) are two completely different concepts. Derive is an out-of-context modeling approach. This means the derive part, though influenced by the derive source, is built within its own context. The part can stand on its own and it can be repurposed elsewhere. But, the derive source model can always drive the part.

Project (Adaptive) is an in-context modeling approach. This means the projection is done within the context of a particular assembly. Such projection may not make sense elsewhere. It is rarely an adaptive part can be repurposed.

I try not to use the term "Top-Down", since its definition can be interpreted differently. It is confusing to communicate the concept by using the term. Some say it is the same as Skeletal Modeling. Some say it is about defining geometry within one document. Regardless, it is very rare you would leverage one approach to design a large assembly.

Many thanks!

[bradeneuropeArthur]

Hi @johnsonshiue ,

Thanks for the support.

Don't you think that still there is a reason for not using the derive method in the "Multi part/Level Process" of skeletal design.

I am sure that there is a good reason for not using it since we see it in the Video and also in the Help files, which makes it kind of plausible.

I am really curious why, and if derive will bring us into issues. Is this maybe related to performance that the derive method is not listed here?

Do you have any ideas only to shoot and brainstorm!?

Regards,

[BDCollett]

When I look at that diagram, I assume it's "derive" even though it has "project geometry" noted, I don't think that's correct personally.

[bradeneuropeArthur]

And what is correct than to your opinion, derive or projected geometrie or both and why do you think that?

I think there is a good reason because ot is found at least in two different places (video and help files)

Thanks.

[BDCollett]

---

@bradeneuropeArthur wrote:

And what is correct than to your opinion, derive or projected geometrie or both and why do you think that?

I think there is a good reason because ot is found at least in two different places (video and help files)

Thanks.

---

In my opinion the fact "Adaptive" is not mentioned to me means the "project geometry" is actually meaning "derived geometry". I could be wrong, but I would never use adaptive to create linked parts and sub-assemblies like that. That's just me though, I only use adaptive for very specific workflows.

[bradeneuropeArthur]

I would appreciate some official feedback from Autodesk about what the fact is in this case. Either it is a mistake in the help file and also in the trainings video, or there is really a good reason for not using derive in this case. I have some good reasons and benefits using copy objects and using adaptivity, but that goes beyond my general question.

Regards,

[johnsonshiue]

Hi Arthur,

I did not author the document, so I cannot comment on the specifics why the doc was written this way. But, I think the term "Skeletal Modeling" already implies it is Derive. The Project mentioned here is probably projecting the derived skeletal geometry within the derived part, not across components (Adaptive).

In some cases, Adaptive does make things easier and it does make sense for a particular context. But, never overuse it. Treat it like a credit card. You borrow to certain limit. You have to pay back anyway.

Large Assembly Modeling is a science and an art. There isn't a one-size-fit-all solution. It will depend on your project, your goal, your team, and your design practice. I don't think the document suggests a gold standard for all cases.

I like to use two extremes to explain the whole thing. One extreme is that each part has no feature except a dumb solid body. And, each part is reused to the max. It is as if the whole assembly is imported from STEP. You will get the nearly the best performance as such. However, nobody designs an assembly like this. It will be hard to make any change.

The other extreme is that one skeletal model drives everything. Essentially, the skeletal part is the true driver and all the parts derive from the driver totally or partially. The downside is that every subtle change may trigger cascading updates. The skeletal model becomes so complicated and unmanageable. Update may take forever.

In real world, modeling a large assembly is always somewhere between the two extremes. It usually consists of subassemblies (modules). Each module should not totally rely on the skeletal model, unless you build everything yourself. There could be vendor components with predefined sizes. For the module you build yourself, there should be a skeletal model.

By decomposing the model, you will have a more manageable, resilient design and the compute will work more efficient.

Many thanks!

[bradeneuropeArthur · Accepted solution]

Hi @johnsonshiue ,

Thanks for the good description you gave.

In special I like the sentence "Large Assembly Modeling is a science and an art".

I agree with you completely that the method described in the help file and in the video (Multi Part/Level Process Skeletal Method) is not the simplest and easiest way that can be used, and is an "Art".
Something in between Multi-body (One Skeletal model) and (Multi Part/Level Process Skeletal Method) which is a split up into logical and separate skeletal-models, will maybe doable.
As you described this will make it to an "Art" which to my opinion is not easy and needs special training.
On the other hand the "Multi Part/Level Process Skeletal Method" splits thing logical up which is a benefit for the quantity of updates required.
On the other hand not everything (parameter/feature) is in one and the same part (One Skeletal model) which makes the search and overview a bit more complex.

To keep thing simple and out of the box I think users need to be aware to make it less an "Art" (as you also wrote) and make it as much as possible useful also for non or less experienced Inventor users in a company.
Or use the Art designs (made by special group of users) as a template where other users can make use of, but not to think about the configuration selves. Because in the configuration of "Multi Part/Level Process Skeletal Method" you can make one simple mistake an you will eliminate the work you have done before (split up in to logical pieces). 

Personally I find myself always starting with it and somewhere in the design I need to start over (delete things) because of wrong assumptions and wrong relations made in the wrong environment or in the wrong (Skeletal Part). It is more like test and trial!

This means to my opinion that this needs to be done very carefully and with understanding what each relation (Derive/Project Geometry) can cause. 

Thanks and regards,