Assembly: TNP

[PaddleStroke]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

The assemblies can break easily because of TNP.

It is because the joints are computing the placements based on element names stored as string. For example a joint will store :
Object1 = "Body1"
Element1 = "Face10"
Vertex1 = "Vertex8"

Object1 = "Body2"
Element1 = "Edge5"
Vertex1 = "Vertex8"

So my question is how to solve TNP here :) @CalligaroV @bgbsww if you can give me some hints perhaps?
Thanks

Full version info

0.22

Subproject(s) affected?

Assembly

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bgbsww]

I'll try to stay available on Discord ( bgbsww ) so we can discuss in real time.

I don't know much about Assembly. Are we talking across files or within a file?

In any case, the elementMaps in the TNP code associate a history with the current name of an element. The history is the sequence of operations that caused a shape to exist, like making a box, making a cylinder, and doing a boolean between them is conceptually a three step history that describes a shape. There are both forward ( history to current name ) and reverse element maps (current name to history ). So if I've built something else on top of that shape above, and then I change that shape, if I look it up in the elementMaps I should get the correct shape and new name.

That's probably what you want to tap into here - looking up your references so they know when an underlying shape changes.

The vast majority of the magic happens underneath TopoShape::makeShapeWithElementMap which is called by the various TopoShape::makeElementShape methods that are called by anything that makes or changes a shape.

Examples that might help: AttachExtension::positionBySupport() and AttachExtension::extensionHandleChangedPropertyName() FeatureBoolean.cpp TopoShape::getSubTopoShape

Note that history and ancestry are referencing the same thing.

[PaddleStroke]

@bgbsww I made a small video to explain the TNP issue in assembly :

2024-05-27.15-35-14.mp4

If you need more details, let me know when you're available so we can hope in a video chat.
Thanks

[bgbsww]

Thank you for the video, it helps me understand a lot. I suspect the root of this issue is around the Element1,2 and Vertex1,2 properties which appear to be PropertyStrings and not PropertyLinks. There is a lot of code around PropertyLinkBase::_updateElementReference that essentially rewrites the links to be correct when there is a TNP change made. There is no way to detect that a PropertyString value needs to be changed.

So, I think the right approach here is to see if those can change type to be Links, at which point the TNP code should cut in and automagically make the right thing happen.

@PaddleStroke apologies for the long delay to getting to look into this.