Topological Naming, My Take

[Zolko]

But only until you have generated the names of modified faces. Then you may delete the old shape.
...
Of course the general TN algorithm should be suspended (not used) for the face names handled by this code snippet.

If I'm not mistaken, this is the other theoretical method to solve the TPN issue: to check the naming at each change, by comparing "before" and "after", and forgetting the "before" when "after" is reached. This is the method used by OCC's internal TPN algorithm.

Realthunder's solution uses an absolute algorithm that tracks the naming history from the beginning of the model history.

I don't think that it's safe to mix the 2 methods

[adrianinsaval]

If I'm not mistaken, this is the other theoretical method to solve the TPN issue: to check the naming at each change, by comparing "before" and "after", and forgetting the "before" when "after" is reached. This is the method used by OCC's internal TPN algorithm.

Is it really? my take from what I read was that it also tracked history, I could easily be wrong here though as my understanding of OCCT's toponaming is very vague.

Realthunder's solution uses an absolute algorithm that tracks the naming history from the beginning of the model history.

I don't think that it's safe to mix the 2 methods

IIRC realthunder's algorithm also has a fallback that does shape comparison. If I'm not mistaken when this is used the feature is marked with an error and requires user confirmation to use the detected topology. This can be a confusing subject though because strictly speaking that is not really the topological naming algorithm, but rather a reference auto fixing algorithm.

[wsteffe]

If I'm not mistaken, this is the other theoretical method to solve the TPN issue: to check the naming at each change, by comparing "before" and "after", and forgetting the "before" when "after" is reached. This is the method used by OCC's internal TPN algorithm.

Realthunder's solution uses an absolute algorithm that tracks the naming history from the beginning of the model history.

I have to admit that I have not really understood the details of RT method but I am not so sure that these two approaches are really different and incompatible.

At this page https://github.com/realthunder/FreeCAD_ ... -Algorithm it is written:

The core function to generate element names is TopoShape::makESHAPE(). At a high level, the algorithm can be described as using four steps to try to name as many elements as possible.

• 1 Find any unchanged and named elements that appear in both the input and out shape, and just copy those names over to the new shape

• 2 Assign names for generated and modified elements by querying the Mapper.

• 3 For all unnamed elements, assign an indexed based name using its upper named element. For example, if a face is named F1, its unnamed edges will be named as F1;:U1, F1;:U2, etc. In this step, an element may be assigned multiple names, if it appear in more than one named upper elements. This is to improve the name stability of the next step.

• 4 For all remaining unnamed elements, use the combination of lower named elements as its name. For example, if a face has all its edges named, then the face will be named as something like (edge1,edge2,edge3);:L.

Here I am mainly interested with the first point in which RT says that names of unchanged elements are just copied to the output shape.
I suppose that here RT is referring to input output shape of a CAD feature such as, in example, the base shape and the result of a Fillet.
So what suggested in my previous post is just to apply the first rule not only to unchanged shapes but also, in example, to the faces modified by a Fillet. In fact these may be regarded as the same faces, just a little bit shrinked by the fillet.

[Zolko]

I have to admit that I have not really understood the details of RT method

me either ... and that's the thing that worries me: who, apart from realthunder, fully undestands his method ?

At this page https://github.com/realthunder/FreeCAD_ ... -Algorithm it is written:

• 1 Find any unchanged and named elements that appear in both the input and out shape, and just copy those names over to the new shape

so if the Sketcher gives explicit names to the generated OCC geometries, would these be re-used as-is by realthunder's algorithm ? I don't want to seem stubborn, but what speaks against fixing Sketcher to have persistent names internally (for geometries and constraints) and use them as explicit names for the resulting elements ? (apart from the work that it needs, of course, and which far exceeds my level of competence).

Here I am mainly interested with the first point in which RT says that names of unchanged elements are just copied to the output shape.
I suppose that here RT is referring to input output shape of a CAD feature such as, in example, the base shape and the result of a Fillet.
So what suggested in my previous post is just to apply the first rule not only to unchanged shapes but also, in example, to the faces modified by a Fillet. In fact these may be regarded as the same faces, just a little bit shrinked by the fillet.

Sounds good.

[adrianinsaval]

I don't want to seem stubborn, but what speaks against fixing Sketcher to have persistent names internally (for geometries and constraints) and use them as explicit names for the resulting elements ?

I've shown you realthunder is already doing this... (for geometries, constraint index has nothing to do with TNP)

[Zolko]

I've shown you realthunder is already doing this

I'm sorry but I think I've missed that. Could you please re-post that information ?

[adrianinsaval]

I'm sorry but I think I've missed that. Could you please re-post that information ?

https://forum.freecadweb.org/viewtopic. ... 78#p628678 I also rambled very long on the post above that one but the juice is on the linked post

[Zolko]

I'm sorry but I think I've missed that. Could you please re-post that information ?

https://forum.freecadweb.org/viewtopic. ... 78#p628678 I also rambled very long on the post above that one but the juice is on the linked post

Thank-you. I've missed that one, may-be because of the rumble above

So I tried to reproduce your example, and here is what I've found:

• using only PartDesign, I create a Body, then a Sketch
• In that sketch, I draw 1 circle, then a larger one.
• I exit, and I'm looking at the name of the pre-selected object, as shown in the status bar
• the first, smaller, circle has name Edge1, and the larger has name Edge2
• I edit the sketch, delete the smaller circle (was Edge1), and create a new even larger circle (should be Edge3)
• now, the smaller – previously the larger, previously called Edge2 – circle is called Edge1, and the new larger circle is Edge2

this doesn't look like the behavior I was proposing.

Code: Select all

OS: Debian GNU/Linux 11 (bullseye) (KDE/plasma)
Word size of FreeCAD: 64-bit
Version: 2022.709.26244 +5001 (Git) AppImage
Build type: Release
Branch: LinkDaily
Hash: 096210d21183e9dfdc3b25777760bfb6c00a210b
Python version: 3.9.13
Qt version: 5.12.9
Coin version: 4.0.1
OCC version: 7.5.3
Locale: English/United Kingdom (en_GB)

[realthunder]

this doesn't look like the behavior I was proposing.

The indexed name of a shape element is mostly controlled by OCC. It is still so with my topo naming algorithm. If I were to override this indexed naming scheme, there would have required a much larger change set, and most likely broken many existing code. There is a underlying persistent ID (or call it index, or whatever) for sketch geometry, you can see it using Selection View. It's something like 'Sketch.;g1.edge1' when selected in editing mode, or 'Sketch.;g1;SKT.Edge1' when not in editing. That number after 'g' is the persistent index.

The thing is, with my implementation, users do not need to be aware of this underlying topo naming. They can use indexed based reference as usual through various link properties. The index will be auto changed when the shape is modified. For sketch, this auto change has no ambiguity, so it will be transparent to the user.

[wsteffe]

@realthunder

Hi RT, may you please replay also to my posts about overriding the current naming rule (and using instead using rule 1 described at page https://github.com/realthunder/FreeCAD_ ... -Algorithm) for faces modified (not generated) by fillets ?

From your previous replay to my proposal it is clear that you don't have understood what I wanted to do. So I have better clarified my proposal here:

and here:

May you please have a look at those two posts and tell me what would be wrong, if any, with this approach ?