wsteffe wrote: ↑Sun Oct 09, 2022 6:24 am
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.
Zolko wrote: ↑Mon Oct 10, 2022 9:52 am
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.
Zolko wrote: ↑Mon Oct 10, 2022 9:52 am
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.
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.
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.
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 wrote: ↑Mon Oct 10, 2022 8:34 pm
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.
Try Assembly3 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
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: