PR #4752 Topological Naming

[onekk]

]

Until "the integration" is finished, there is no real impact on the daily use of FreeCAD.

If we're planning to do this, ....

Yes, but from a user point of view:

"What i can argue for if I have not the way of test the behaviour"

From a developer "point of view" I could discuss maybe in code implementation, or I could foresee the impact on some other parts, but this point of view is maybe interesting two or three core developer?

As I don't know the "way the core developer are working" in other word who is in charge for what part of the codebase, if there such a division.

My fault maybe, but the "development" structure or assignment, is not "very visible" so who has to review and approve and merge PR such these?

Sorry if some of my post sometimes resemble a critics, only to "catch the point", as I'm interested in a better FreeCAD as I'm using it almost every day.

Regards

Carlo D.

[wsteffe]

It seems to me that this PR has stalled and that we will never see topological naming inside of the master FC.

[Kunda1]

It seems to me that this PR has stalled and that we will never see topological naming inside of the master FC.

Relax, we need to wait to hear from wmayer

[wsteffe]

Hello Kunda1, are you still waiting for a wmayer word ? I think it will never come.
To have topological naming we need to switch to the RT fork.

[Zolko]

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 ?

ping

ping

[wsteffe]

to be honest, I'm not entirely convinced by realthunder's algorithm.

Hello Zolko, many thanks for your post.

I do not know the sketch internals so I leave to others (abdullah) the answer to your question about admissibility of incomplete edge enumeration.
Anyway I apprexciate that you have entered into the problem and started a discussion on the merits/drawbacks of RT algorithm.

[Zolko]

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

... thinking further: I didn't read the code, and wouldn't be able to understand it, but from what I can infer I think that each element has at least 2 states: normal and construction. We could add a third state: deleted.

When an element (sketcher internal element) is deleted, all references to it are deleted per today's method, but the element itself has only it's state flipped to "deleted". An element in the "deleted" state is not shown anymore anywhere in the GUI, but is still referenced internally in the sketch. If necessary, it can retain its old references (like end-points) since they haven't been really deleted either. When calculating the number of DoF, elements in the deleted state mustn't be included.

Then remains the question on how to make OCC wires from Sketcher elements while retaining the Sketcher's internal non-consecutive naming scheme.

ping

[chrisb]

When an element (sketcher internal element) is deleted, all references to it are deleted per today's method, but the element itself has only it's state flipped to "deleted".

This would be ok as a workaround, but as a final solution it is a crook. I would indeed like to see the names being kept with gaps in the sequence if elements are deleted. The gap would even include the creation of new elements if the last element has been deleted.

[Kunda1]

Hello Kunda1, are you still waiting for a wmayer word ? I think it will never come.
To have topological naming we need to switch to the RT fork.

Your feedback is counter-productive and actually inflammatory. This thread is important and should stay rational and technical in nature (that means without drama). If you continue to participate in such a way on this thread you could potentially be ejected from the forum.

[wsteffe]

I also prefer to stay on the technical. And I said that I appreciate that zolko started that kind of discussion.
Perhaps my provocation helped to trigger the technical discussion. Before it, since a couple weeks, there was embarrassing silence with all waiting for a word.