PR #4752 Topological Naming

Post here if you have re-based and finalised code to integrate into master, which was discussed, agreed to and tested in other forums. You can also submit your PR directly on github.
User avatar
Zolko
Posts: 1425
Joined: Mon Dec 17, 2018 10:02 am

Re: PR #4752 Topological Naming

Postby Zolko » Mon Jul 05, 2021 8:01 am

realthunder wrote: Sun Jul 04, 2021 11:04 pm The new topo names are stored as a string table inside each shape (Part::TopoShape) that maps the encoded name to index. Internally, we still need the index name to access OCC sub-shapes.
OK it begins to make sense. So, how do objects reference elements now: by the (old) index names or the (new) mapped names ? For example, when I attach an LCS to elements of a sketch, I can see that the references that are displayed are the (old) index names. Is that only for display ?

When I attach an LCS to a corner of a sketch, I see the following in the Document.xml file (inside the FCStd) :

Code: Select all

<Property name="Support" type="App::PropertyLinkSubList">
    <LinkSubList count="3">
    <Link obj="Sketch_Part_1" sub="Vertex1" shadow=";g1v1;SKT.Vertex1"/>
    <Link obj="Sketch_Part_1" sub="Edge1" shadow=";g1;SKT.Edge1"/>
    <Link obj="Sketch_Part_1" sub="Edge5" shadow=";g4;SKT.Edge5"/>
    </LinkSubList>
</Property>
and when I change the sketch by deleting and adding lines, I get:

Code: Select all

<Property name="Support" type="App::PropertyLinkSubList">
    <LinkSubList count="3">
    <Link obj="Sketch_Part_1" sub="Vertex3" shadow=";g1v1;SKT.Vertex3"/>
    <Link obj="Sketch_Part_1" sub="Edge3" shadow=";g1;SKT.Edge3"/>
    <Link obj="Sketch_Part_1" sub="Edge2" shadow=";g4;SKT.Edge2"/>
    </LinkSubList>
</Property>
So the index names changed, but the mapped names didn't. Therefore, I guess that this (your -asm3 branch) does solve the toponaming problem (for sketches at least, and it's what I care about the most). Congratulations !

Now, this also changes the data structure of FreeCAD files, therefore I think we should also be careful about what is displayed and saved. May I challenge the "for compatibility reasons" ? Displaying a secondary info (the varying index name) instead of the really important info (the stable mapped name) might seem like a good idea at first glance, but it might bite us in the future.


EDIT: when I open the same file with main FreeCAD, I read the following in Document.xml:

Code: Select all

<Property name="Support" type="App::PropertyLinkSubList">
    <LinkSubList count="3">
        <Link obj="Sketch_Part_1" sub="Vertex3"/>
        <Link obj="Sketch_Part_1" sub="Edge3"/>
        <Link obj="Sketch_Part_1" sub="Edge2"/>
    </LinkSubList>
</Property>
try the Assembly4 workbench for FreCAD v0.19
install with Tools > Addon Manager > Assembly4 — tutorials here and here
wsteffe
Posts: 286
Joined: Thu Aug 21, 2014 8:17 pm

Re: PR #4752 Topological Naming

Postby wsteffe » Mon Jul 05, 2021 8:30 am

realthunder wrote: Sun Jul 04, 2021 2:19 pm See here for an explanation of how the recursive encoding using shape history works.
I have looked at. I may undersatand the intent but it is quite difficult to fully grasp the logic of name enconding.
realthunder wrote: Sun Jul 04, 2021 2:19 pm The heuristics lies in the fact that one can often find more than one match, and I usually just pick the first one.

Here the match should refer to the "search the current (modified) shape for elements that can be traced back to the same geometry element".
Is it true ?
This search is done in the last shape (after the history has been fully regenerated). On the other side the last matching of a named geometry in the recursive decoding could be associated with a previous state in the history. So when there is "more than one match" does it mean that more than one element of the same type was derived from the last mapped common ancestor ?
realthunder
Posts: 2000
Joined: Tue Jan 03, 2017 10:55 am

Re: PR #4752 Topological Naming

Postby realthunder » Sun Jul 11, 2021 6:32 am

Zolko wrote: Mon Jul 05, 2021 8:01 am OK it begins to make sense. So, how do objects reference elements now: by the (old) index names or the (new) mapped names ? For example, when I attach an LCS to elements of a sketch, I can see that the references that are displayed are the (old) index names. Is that only for display ?
Part::TopoShape has API to allow accessing sub shape with both the index name or the mapped name. But internal to TopoShape, it will always translate the name to index because that's what OCC understands. For programmer, as long as the sub shape name is retrieved from a link type property before accessing (i.e. not stored in some user data structure or other property like a PropertyString), then it can be trusted.

Now, this also changes the data structure of FreeCAD files, therefore I think we should also be careful about what is displayed and saved. May I challenge the "for compatibility reasons" ? Displaying a secondary info (the varying index name) instead of the really important info (the stable mapped name) might seem like a good idea at first glance, but it might bite us in the future.
The displayed name is for human to read, but the mapped names are really not for that. You may find very similar name with maybe only one character change, or you may find a name with hundreds of characters long, which are obviously not suitable for display. What's important is how the program uses the name.
Try Assembly3 (latest version 0.11) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Posts: 2000
Joined: Tue Jan 03, 2017 10:55 am

Re: PR #4752 Topological Naming

Postby realthunder » Sun Jul 11, 2021 6:41 am

wsteffe wrote: Mon Jul 05, 2021 8:30 am Here the match should refer to the "search the current (modified) shape for elements that can be traced back to the same geometry element".
Is it true ?
A match requires two parts. The first part is from the mapped element name stored in some link type property that is now missing in the modified shape. So we perform recursive decoding to that element name to trace to some element in the ancestor shape. The second part is the elements in the current modified shape. Decode those element names and try to find one that can be traced back to the same element in the same ancestor shape.

So when there is "more than one match" does it mean that more than one element of the same type was derived from the last mapped common ancestor ?
Yes, that is correct. Depending on the extend of model changes, and how far back into the history, it is common to get many matches.
Try Assembly3 (latest version 0.11) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
wsteffe
Posts: 286
Joined: Thu Aug 21, 2014 8:17 pm

Re: PR #4752 Topological Naming

Postby wsteffe » Mon Jul 12, 2021 6:34 am

Hello RT, thanks for the clarification.