Steps forward to assembly infrastructure

[yorik]

Thanks for the explanations! I think I begin to understand better and agree with both of you about containers and not allowing to link from one to something inside another. It is a new kind of object after all, it makes sense to decides its rules early...

I like App.ActiveContainer too, rockn worked on something like that with groups some time ago (that you would have an "active group" and every new object would go in it automatically).

About the instance issue, I'm more of ickby's opinion too. A typical example for me: You have a sloped roof, and you have walls under it. You would want to use the roof object to "trim" the walls so they meet the roof line and don't go above it. But it seems weird to me that each wall would need a separate instance of the roof to perform the subtraction...

And if the objects that are used multiple times appeared multiple times in the tree, but with a different aspect/color, and would behave differently? For example, you would click one, and they would become all selected together in the tree...

[DeepSOIC]

Yorik, I think you got me wrong. My intent is that Instance is like Draft Clone of a group. Except that it is very lightweight, in that it only renders the part in another place and provides special selection behavior. For the rest, the usual graph way of doing things will still hold; what I'm against is a graph structure of containment. I think it's very confusing.

In your design you make a InstanceObject of a Subassembly. This gets IMHO confusing very quickly, as you can't open a subassembly in the tree to see what is inside etc.

Well, that can be fixed easily by making the instance to claimchildren the contents of Part it is linking to. But I actually would like it to not show its contents, just for emphasizing that this is just a copy, that can't be edited independently.

2. ... Getting the global position of a shape? Not possible.

I already said how it is to be done: Selection object should include the list of instances, through which the object was selected. Nothing impossible.

3. When selecting something in the 3d view, it must select the original object. Or the instance? A bit confusing.

Kind of both, see above. In graph container structure, you still need to know which containers the object was selected through, so they are kinda selected, just like the instance. If we are to stick with tree, we don't need to keep track of containers, only instances.

5. Operations would always be done on the orginal object in the 3d scene and not where the user selects it. For example the user selects a sketch in the Instance of a Part. Than he hits "edit". The edit mode would be at a totally different position in the 3d scene as it edits the original sketch. such behavior is strange.

Same happens with containers, no? Either edit mode has to remember the CS path to selected object. In my case, it has to remember only the instances though which it is activated; in your case it will have to remember the whole container path. But in my case, if sketch editing doesn't take care about instances, it will still work correctly, even though displayed in a slightly unexpected place (but not totally unexpected, because it will be the place where the sketch was originally drawn at, which isn't a totally unexpected place).

[DeepSOIC]

Suggestion on terminology for now.

CONTAINER, or more specifically PLAIN CONTAINER, or maybe UNMOVEABLE CONTAINER = document object that can be activated to receive newly created objects. I would also like it to parent all viewproviders of contained objects, so that it controls their visibility.

LOCAL CS = document object that has placement, and renders some other object(s) in the new place. In Lattice it is called simply "Placement".

LOCAL CS CONTAINER, or MOVEABLE CONTAINER = a container with placement.


"Part" object is a local CS container. Body is, too.
DocumentObjectGroup is a container, but not a local CS.
Free links are to be forbidden across local CS containers. Free links are to be allowed across plain containers.

[NormandC]

About the instance issue, I'm more of ickby's opinion too. A typical example for me: You have a sloped roof, and you have walls under it. You would want to use the roof object to "trim" the walls so they meet the roof line and don't go above it. But it seems weird to me that each wall would need a separate instance of the roof to perform the subtraction...

I think your example is a different thing altogether. At least from the non-programmer end user point of view.

For me, a typical instance example is an assembly of parts that contains 50 identical bolts. Or a few identical parts or sub-assemblies. What you are describing is more about a single object linked to multiple other objects.

[DeepSOIC]

OK, thanks to Norm, I have another advantage about going for instances. BOM! (BOM = bill of materials).

[DeepSOIC]

I have found one more reason to have instances. Array (aka pattern)! An array can be a subclass of Instance, that renders Part in multiple places in a pattern.

[triplus]

If i understand different views correctly.

• Container provide local coordinate system to features and features added to containers use that local coordinate system.
• Moving around the whole container therefore doesn’t affect features placement inside container.

Hopefully this is correct and hopefully it doesn't have to be more complex than that. That is having movable/non-movable, PartDesign/Part and placed/super-placed containers in the future.

Anyway using link to external geometry between features in different containers in theory should be possible but as the use case is small and implementation effort is substantial and due to potential problems this won't be allowed. As for using expressions. That will be possible and end users will decide when to use it or not.

After this point you two start to have slightly different view on how should container be used in assembly.

@DeepSOIC

You propose "instance object". I see this as new assembly feature similar to Draft Clone. The feature itself is more or less the result of everything in the container.

@ickby

You propose to have a system for using container with all its features directly. Therefore using a container in assembly should add the whole feature tree from the inside of the container to the assembly tree.

If i got this correct the main difference i see is when using single part or sub-assembly in assembly the workflow remains similar to the one used in PartDesign. That is you can easily select a feature in the assembly tree view and edit it in place. Using "instance object" on the other hand likely does simplify some things but editing features inside container will likely be considered as a separate operation done outside the assembly tree.

[DeepSOIC]

The different views is on how to make copies of Parts for assemblies.

My way: create multiple instances of same object using specialized Instance object (instance object is mimicked by clone in this example, as one isn't yet implemented). My way allows to simplify container structure to a tree, which I think makes things much easier to understand (one object can only belong to one container).

instance by instance object (clone).png (28.11 KiB) Viewed 1504 times

instance by instance object (clone).FCStd

(4.87 KiB) Downloaded 28 times

ickby's way (probably originated by jriegel). This requires full graph support for container structure (one object can belong to many containers)

instance by multiple containment.png (42.3 KiB) Viewed 1504 times

instance by multiple containment.FCStd

(3.85 KiB) Downloaded 33 times

More differences:
DeepSOIC: there is a master Part, that is editable, and instances of the Part, that aren't editable. Deleting master part will delete actual geometry, and break all its instances.
vs.
ickby: there is no master part. Any "instance" of part is just another part re-using some objects. Any "instance" can be deleted with no consequences; only when the very last instance that uses the objects is deleted, the actual objects (geometry) will get lost.

I hope I got it right and I hope it should become clearer.

[triplus]

I will look into it tomorrow in more detail. It does look like we are progressing. Now there are nice images involved and that for sure makes things easier to understand.

And i was wondering could an estimate in man years be made:

• Assembly2 reviewed, solver improved and additional constraint or two added.
• @DeepSOIC way.
• @ickby way.

Thanks.

[NormandC]

Without pretending to understand the whole issue, I think this is where implementing specific file extensions would have a huge advantage: for example *.FCPart for a document containing a single part, *.FCAsm for an assembly file linked to other files. All the major commercial parametric CAD programs do that. They even have a separate file extension for drawings (*.FCDwg ).

In the FCPart document tree, you see everything that you normally see in the current FCStd document: Part container, bodies, other stuff.

In the FCAsm document tree, there is no need to display the full structure of an imported FCPart (what's nested under its container), only the container itself is shown. Okay, maybe its PartOrigin as well. It is thus possible to have multiple instances of the same part (or even assembly) listed in the tree but not make it very complex. All that is needed is to append some suffix with a digit indicating which instance it is. To differentiate from the usual 3 digits added to primitives or features (Pad001, Pad002...) and make it visually clear they are instances, maybe some separator could be added, or the suffix placed inside parenthesis.

M6x25_Bolt(001)
M6x25_Bolt(002)
M6x25_Bolt(003)

The CAD software I use at work adds a colon:

M6x25_Bolt:1
M6x25_Bolt:2
M6x25_Bolt:3

Editing the part would open the FCPart document separately. It could be done from any instance shown in the tree, not only from the "original" one.

Now that I think about it, it is exactly what the Assembly2 module does.