Steps forward to assembly infrastructure

[triplus]

*overrides placement of child object, not adds another placement on top of it

I read this as independent placement. That is independent placement for Draft Clone alike assembly solid feature. Or alternative description i guess could be "Part Tip" linked simple copy alike assembly solid feature.

And here i feel we will need to get clever as:

allows to make more stable links (as I proposed, links are to remember only instance path, so rearranging containers inside Part won't break assembly constraint links)

This assumes topology isn't an issue. It is and assembly constraints will break and will break often. Therefore FreeCAD assembly infrastructure should accommodate to that. I feel that if doable something like this could work:

Each feature that can represent "Part Tip" gets UUID assigned. This would be useful in a lot of places not just for Assembly purposes. For example simple tool like adding a note to existing feature can't be made reliably ATM. As original feature label/name can easily change and the note gets assigned to another feature after. If there would be UUID that problem wouldn't exist or it would be greatly reduced.

Now Part Tip is a feature itself and lets imagine it has its UUID. Storing this UUID therefore is the only thing needed for assembly feature to preserve link to the correct feature. The Part Tip feature itself provides topology to assembly feature. Adding for example plane/face constraint to such feature results in creation/storage/using of signature pair like (one pair):

• UUID: value
• Face: 7

This is all that should be needed. Now as for robustness. Solver should be made in a way if Part Tip gets deleted (unknown UUID) or if Face 7 isn't the correct face anymore due to changed topology of the Part Tip. Or if Face: 7 simply doesn't exist anymore due to the changes done to Part (Tip). That should represent localised issue. It shouldn't brake everything after that point in assembly tree. Constraints for assembly features considered to be added after should only care about corresponding UUID and topology of other assembly features (from another Part Tip). And as there was nothing changed there this doesn't affect the constraints made between them. Therefore only one single constraint needs to be redone to satisfy solver if some unresolvable condition was produced. Or if users simply decided to redefine one constraint. And the rest should just work after.

Likely one feature would need to be considered "base assembly feature" and after each constraint is resolved in some order independently. If something like this would be done maybe similar approach could be explored for PartDesign in the future. To better manage topology issues between features in the PartDesign workflow.

[DeepSOIC]

Triplus! What you are suggesting is to replace object name with some UUID, when object name already is a "UUID" (well, it's unchangeable and unique within one document).

[triplus]

Triplus! What you are suggesting is to replace object name with some UUID, when object name already is a "UUID" (well, it's unchangeable and unique within one document).

Not replacing just adding additional identifier that could be reliably used and would likely substantially reduce the effort needed to preserve links between features. For example if i would do a Python based Note module i wouldn't be comfortable in using:

Code: Select all

UUID: Cube

As reliable identifier of the feature in the tree. And probably it really shouldn't be made more complex than that (hence UUID). Therefore yes this is what i am proposing to be considered as a part of the future FreeCAD assembly infrastructure.

And basically this is how i understand the issues involved and possible solutions without much further ado:

viewtopic.php?f=10&t=17864&start=50#p141240

If i would be coding it i would likely take this approach as the first approach to be explored. As i won't be coding it and i feel that i shared my understanding gathered over the years (thanks for listening) it is now appropriate (from my point of view) for developers actually doing it to take over the discussion and decide on the appropriate direction to take. Good luck and looking forward to seeing progress being done.