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.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: PR #4752 Topological Naming

Post by abdullah »

Zolko wrote: Fri Jun 25, 2021 2:36 pm
wsteffe wrote: Fri Jun 25, 2021 2:12 pm To have topological naming we need to switch to the RT fork.
to be honest, I'm not entirely convinced by realthunder's algorithm.

I think that Sketch and Part (OCC) should be treated separately, and sketch be done before Part. Solving the topo-naming issue for Sketch would advance us a lot forward.

When looking at how sketcher treats edges, there are 2 issues: sketcher's internal naming and then the export to wire. You can see the difference that when you change a segment to construction, the internal name doesn't change but the exported name does. When you delete a segment, all internal segments are renamed. I'm not sure how realthunder's topo-naming solution addresses this.

One solution to this could be to keep shadow references of all created elements, and when one is deleted then keep the names of all others constant: once an element is named, it's name cannot be changed, and if it's deleted it's name cannot be re-used. When a new elements is created, add a new name to the end of the queue. And then, when exporting to wire, keep the internal names. This way, you might end-up with a wire containing Edge1-Edge3-Edge17-Edge18-Edge19-Edge666: does it matter ?
I tried in Q4 2020 to excise RT's sketcher functionality from the rest of topo-naming to move this development forward. So a new index was introduced in FC master at sketcher level, so that the position of a geometry in the geometry array (which changes with deletions as you say) is not what determines the order of the wires. RT's branch now, I understood, uses this index.

In very general terms the RT's approach is to use this index a black box "Toponaming" and a modified algorithm to sort the edges of the profile that is generated when going out of edit mode. The black box is not specific to the sketcher, but a general component.

This means that any can try to solve the problem in an alternative way using RT master.

It is my understanding that the size of the PR, the extend of the PR and the lack of available free time in the post-pandemic world is playing against a proper review and possible merge. Me myself, I am overwhelmed by work to the borderline between keeping the pace and avoiding getting sick.
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: PR #4752 Topological Naming

Post by wsteffe »

abdullah wrote: Sat Jun 26, 2021 5:37 am So a new index was introduced in FC master at sketcher level,...
If I have understood it (after reading also the page https://github.com/realthunder/asm3-wik ... -Naming.md) the new indexing is meant to create the mapped (stable) names with setElementName(...). The mapped names are used in the references made with PropertyLinkSub, PropertyLinkSubList, and PropertyXLink. This mapping should be automatically updated after a change of the CAD geometry.

I think that this infrastructure is useful to decouple the links from the unstable internal names generated by workbench algorithms. The mechanism for the generation of original names may so stay unchanged. The original names may still be used also by the links when a mapped name has not been defined. In this way the introduction of topological names doesn't break the compatibility with older versions.

Of course the best strategy to create stable names (to be associated with original names) is still an open question and the answer depends on the specific workbench (sketch way being different than part way). But, in my opinion, the general infrastructure which deals with the name mapping and decouples the links from the original (unstable) names is well thought.

So I would propose to merge this first PR and move on with a review of the specific (workbench related) ways to define stable (for what is possible) names. The testers will then be able to test the solutions already introduced by RT for Sketch and Part WBs and eventually propose different solutions.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: PR #4752 Topological Naming

Post by onekk »

I also think that a discussion on a theoretical "name scheme", is not the first problem.

Every advancement on a "stable way" to name thing and reuse these "names" across recomputing and modifications, would be a great advance.

Supposing I'm using scripting, it very useful to have a mean to refer to a "single components" of a created solid in a manner that will survive some "transformations". as example

If I create a solid and store the name of an edge, say "solid1.edge3" and then I want to retrieve this edge, i would search for "solid1.edge3".

Eventually if the search function will return a "edge not found" i will be very happy to do a search that could tell me "solid1.edge3" was "transformed in" solid33.edge1, "solid33.edg2" and so on, if this could be stored in sub properties of the "solid33.edge1" or in another list like "mod_edges" that couple the "suppressed edge" and take a reference to the new edges, is not a big deal.

I know that this history or "modification history" could lead to some problems, but eventually (I'm biased by my use of scripting), if I could "register" that i want to track the modification of an element, it will be a very useful thing.

But maybe I'm totally misunderstanding the "toponaming issue", or the scope of having this problem solved, I've read the realthunder document, but not recently so maybe my memory is not so sharp.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
chrisb
Veteran
Posts: 53920
Joined: Tue Mar 17, 2015 9:14 am

Re: PR #4752 Topological Naming

Post by chrisb »

onekk wrote: Sat Jun 26, 2021 2:46 pm Eventually if the search function will return a "edge not found" i will be very happy to do a search that could tell me "solid1.edge3" was "transformed in" solid33.edge1
I think the whole problem with topological naming is to get this very information that solid1.edge3 is mapped to solid33.edge1.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: PR #4752 Topological Naming

Post by onekk »

chrisb wrote: Sat Jun 26, 2021 11:15 pm
onekk wrote: Sat Jun 26, 2021 2:46 pm Eventually if the search function will return a "edge not found" i will be very happy to do a search that could tell me "solid1.edge3" was "transformed in" solid33.edge1
I think the whole problem with topological naming is to get this very information that solid1.edge3 is mapped to solid33.edge1.
So the solution of realthunder will address following problems:

1) after some transformation, the edge exist and the name retained
2) if the name "has disappeared" due to some transformation, i could retrieve a sort of history or know that the edge is transformed. Maybe it was filleted so the original edge was changed, or maybe the "main part" is retain the old name but the new parts have "new names", or maybe it was splitted in two and i could retrieve that solid1.edge3 has became (solid33.edge1, solid33.edge2)

EDIT: From the explanation on Realthunder site, linked in one of the starting post is not very clear about the history, there are some hint about a history and persistence, and it is not clear (maybe because it is not the "stock FreeCAD" implementation after this PR) if some of the 2) point above is fulfilled.

I see that there is some helpers methods to use the "new naming scheme" and retrieve some infos, like if the object was modified or not, and if copied there is a way to copy the "history" across different documents.

Anyone know more about this (a part from Realthunder)?

Hoping to having guess right.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: PR #4752 Topological Naming

Post by Zolko »

chrisb wrote: Sat Jun 26, 2021 11:15 pm I think the whole problem with topological naming is to get this very information that solid1.edge3 is mapped to solid33.edge1.
I don't think that's the issue about topological naming, because design history doesn't play a role in it: if I attach a datum object to solid1.edge3, and this edge is replaced-by / renemed-to solid33.edge1 then the attachment will fail, even if there is a scripted way to retrieve that that has happened. Now, you can say that we'll change the attacher too so that it's aware of this new mechanism, but we will add another level of complexity meaning more future errors.

No, the real issue about topological naming is that solid1.edge3 keeps its name whatever design modifications happen. But that is not entirely possible, as I will show you here. What we can do is to reduce such renaming, but it's impossible to 100% solve it for any parametric CAD program.

This post will be quite long, and I'm not sure it's the bets place for it, but at least all concerned people are in this thread.


SITUATION IN 3D

The topological naming question is different in 3D than in 2D. I created a very simple design in PartDesign, with 2 rectangles on the XY plane and extruded in the Z+ and Z- directions.

Topology.png
Topology.png (274.57 KiB) Viewed 5273 times


I then modified the dimensions of these 2 rectangles, in the property panels, without editing the sketches, and got the following resulting geometries:

topo_all.png
topo_all.png (58.51 KiB) Viewed 5273 times

As you can see, with the exact same topology - 2 extruded rectangles - we can get completely different geometries. And what's important is that these geometries don't always have corresponding edges. And since the sketches themselves where not edited, there isn't any notion of "history" or "modification" or "transformation". If you create a fillet on the visible edge of geom6 and then change the dimensions to make it geom4 : where will the fillet apply ? Where should it apply ?

Of course, this example was designed as a trap to foul the system, but it will do so with any parametric 3D CAD software, be it CATIA or NX. Any real-world design that grows in complexity will at some point reach a state to foul the system, there is NOTHING that can be done to completely prevent this. What CAN be done is to improve the result, reduce the likelyhood of such traps to happen, but we can't suppress it. And therefore I thing that we should not only look into reducing the likelyhood of toponaming problems, but we should aim to do so in the simplest and most robust of the ways, and not by doing some unmaintainable black-magic that nobody understands.


SITUATION IN 2D

The situation in 2D is completely different: conceptually, you can't foul the system, meaning that you can't create, even on purpose, a design that will lead to the same topological naming problem as in 3D: to a topology corresponds a single geometry, you cannot create many different geometries with a single 2D topology.

I created a similar geometry in sketcher as the 3D example above, and changed the dimensions to try to fouls the system:


2D_all.png
2D_all.png (395.88 KiB) Viewed 5273 times


When I set the dimensions to equal to suppress the small line, the system detects an error: it doesn't let itself be fouled. A line segment with 0 length isn't allowed ... which is good. The situation is not completely identical in other 2D drawing programs, as you can have segments with 0 length is Inkscape for example. But FreeCAD's behaviour is logical and consistent.

I've also drawn another example of 2 lines with varying angles:

sketch_all.png
sketch_all.png (33.51 KiB) Viewed 5273 times


When the 2 segments are in line, they remain 2 segments, and this is mathematically correct. While the fusion of inline faces is ISO-compliant, you cannot invoke the "then don't do the refine thing".


BUT THEN, WHY DO WE STILL HAVE THE TOPO-NAMING PROBLEM WITH SKETCHER ?

In this case, it's FreeCAD's "fault", this problem doesn't need to exist, it is mathematically solvable. There are 2 different issues:

  • sketcher's internal naming: when I delete Line4, then what was Line5 becomes the new Line4 ... which is actually inconsistent with FreeCAD's convention that an object's name is immutable: Line5 should remain Line5 independently whether other elements where deleted or not.
  • during export to 3D, when sketcher's internal geometries are converted to external OCC geometries. Since this happens in some order, when rotating a sketch the same Line can become a different Edge.
Therefore, the 2D and 3D problems are conceptually different, and should be treated differently.

abdullah wrote: Sat Jun 26, 2021 5:37 am In very general terms the RT's approach is to use this index a black box "Toponaming" and a modified algorithm to sort the edges of the profile that is generated when going out of edit mode. The black box is not specific to the sketcher, but a general component.
This also means that if this is true, I think this is a wrong approach. Most 3D design begins with a sketch, therefore we should first solve Sketcher's topological naming, and only then try to improve - not solve because it's impossible - the 3D topological naming.


SOLVING SKETCHER4S INTERNAL NAMING

The first step to solve sketcher's topological naming is to have immutable internal names for internal geometries. I tried to read the source-code but I cant' do C++ coding therefore I might be wrong.

I think it's the std::vector<int> GeoIdList that holds these references ... or may-be std::vector<PointPos> PosIdList, not sure. Or std::vector<Part::Geometry *> &geoList ?

One solution could be, as I mentioned before, that deleting a geometry in sketcher doesn't actually remove it but only sets it state to removed. There is an index that could be a good candidate for this state, it's the GeometryMode in SketchGeometryExtension.h:

Code: Select all

namespace GeometryMode {
    enum GeometryMode {
        Blocked                 = 0,
        Construction            = 1,
        NumGeometryMode        // Must be the last
    };
We could adda new state:

Code: Select all

        Deleted                 = 2,

then, if I read it correctly, in Sketcher.cpp:

Code: Select all

int SketchObject::delGeometry(int GeoId, bool deleteinternalgeo)
{
...
    const std::vector< Part::Geometry * > &vals = getInternalGeometry();
...
    std::vector< Part::Geometry * > newVals(vals);
    newVals.erase(newVals.begin()+GeoId);
this newVals.erase() is the culprit: instead of erasing an element from the vector, we should flip the GeometryMode of the corresponding GeoId to "Deleted". And then, getInternalGeometry() needs to be adapted to ignore geometries that have the "Deleted" state.

Does this make sense ?
try the Assembly4 workbench for FreCAD — tutorials here and here
leobin0
Posts: 46
Joined: Tue Jun 08, 2021 3:48 pm

Re: PR #4752 Topological Naming

Post by leobin0 »

i think this is a good idea.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: PR #4752 Topological Naming

Post by onekk »

@Zolko goo explanation.

Obviously FreeCAD should not take care of all the things a designer can do with an object.

But If I create a BREP object, so i create faces and join faces using some edges, create a shell and then "declare" that that shell (watertight) is a solid.

If i modify one edge say i want a line to be a curved edge, what I'm expecting is that if the original solid has six faces i could refer to the "same" six faces with a consistent name.

In the preceding discussion we have focused (or better I have made and example using edges and other people followed me with this example).

Obviously the "nature of the edges" will change, so there will be a mechanism to "name the edges" and "name the faces" in a consistent way that could "resist" to "simple transformations", obviously, the "engine" and in this case is FreeCAD not OCCT has to ask or "signal" the user when some "incongurences" will be created by my action.

Suppose i want to add an edge to one face and raise the face in a manner, think to transform a cube in a "house shaped" solid, and the "solid1.F1" will be split in "solid1.F10" and "solid1.F11" and suppose that the other faces affected did not change their names and remains "solid1.F2" and "solid1.F4".

What I'm expecting is that the faces and edges that will not be affected by the change, retain their names.

This face in solid2 is lacking so it has disappeared.
toponaming2.png
toponaming2.png (6.41 KiB) Viewed 5205 times
But this face (and the corresponding at rear) are simply transformed so I'm expecting that at least the name is retained, and maybe also the edge names that are not modified.
toponaming1.png
toponaming1.png (6.41 KiB) Viewed 5205 times

Hope to have explained my point of view, if not sorry for bothering.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
chrisb
Veteran
Posts: 53920
Joined: Tue Mar 17, 2015 9:14 am

Re: PR #4752 Topological Naming

Post by chrisb »

Even with a simple cube things are not easy and you have to take the history of building it into account. While it is for humans very easy to point at the faces before and after a change which should be considered "the same", this can be quite challenging for a machine.

Let's assume a cube made from a square sketch. this is the state I will refer to as the state "before" the change. Now change the sketch which will result in a changed cube. I will refer to this as the state "after" the change.

If we change the sketch in a way where all four corners change their position, then none of the faces of the cube remains in its place. In fact the cube "after" can have an empty intersection with the cube "before" and thus no point of the cube will stay in place. Neither does any edge or any vertex or face. If I understood previous discussions correctly we cannot rely on the numbering of the state "after" given by OCC.
So the only way to recognize the faces being identical "before" and "after" is to take their history into account. And this has to be obtained through the whole recompute chain.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: PR #4752 Topological Naming

Post by wsteffe »

chrisb wrote: Sun Jun 27, 2021 6:00 pm Let's assume a cube made from a square sketch
Once you have solved the topological name problem for the sketch, it is not difficult to define stable names also for the extruded cube considered by chrisb.
In this case there is a map which identifies sketch edges after change with corresponding sketch edges before change.
It is then sufficient to identify two faces if they are extruded from corresponding edges.
The base face (the face in the sketch plane) of the cube after change is clearly identified with the base of the cube before change.
Same consideration for the last remaining face (that one parallel to the base face).

The zolco case is more complex. It consists of the separate extrusion (in opposite direction) of two rectangles (drawn on the same plane) and
an implicit fusion of the two boxes. The first part of the evolution (extrusion of separate boxes) may be dealt as in the crisb case.
The real difficulty arises in the second part (the boolean fusion).

Stable names for the vertical faces (those normal to the sketch plane) can still be defined.
Depending on the rectangles position a vertical face my be:
- the union of two coplanar faces belonging to different boxes (let say B1_F1 + B2_F1)
or
- it may coincide with a vertical face of a single box (let say B1_F1)

A quite good stability may be assured with name concatenation "B1_F1+B2_F1" or "B1_F1"
This kind of stability would be granted only for changes that preserve the topology (not for a transition from "B1_F1" to "B1_F1+B2_F1").
But I think that this kind of stability would still be a good property to have. As already said by zolco the stability of names
may not be assured for all the transformations of a 3D structure.
Post Reply