toponaming solution for sketches

[Zolko]

re-inventing the wheel

good point: @realthunder , does your topological naming implementation use OCC's built-in topological naming framework TNaming ?

ping

[mfro]

good point: @realthunder , does your topological naming implementation use OCC's built-in topological naming framework TNaming ?

It doesn't.

I don't see why you seem to kind of insist to implement stable names based on libraries that have been investigated years ago and found to be unappropriate for FreeCAD instead of a proven, tested independent implementation under full control of the FreeCAD developers?

[onekk]

DISCLAIMER:

1) What is following is a personal opinion, but I think that could gave some point to make further discussion.
2) I'm a normal user so probably some of the affirmations are wrong and "behind the scenes" there are other things
3) I don't know in deep FC sources to make "precise affirmations"

But in the past:

1) Replies to this genre of post are very interesting, if the people who answer supply link to sources and explanation why one thing is not "as simple" as it appears
2) if the post has not started some "flame war" it has become very productive as when asking for clarification and obtaining some "authoritative answers" from developers is always a good thing to have.


MY PERSONAL OPINION:

I don't see why you seem to kind of insist to implement stable names based on libraries that have been investigated years ago and found to be unappropriate for FreeCAD instead of a proven, tested independent implementation under full control of the FreeCAD developers?

@Zolko has a peculiar way to confront with people, and somewhat it could be seems rude, but he has developed ASM4 so it is not only a "polemic guy", so it deserve some respect for his hard work. (It is not critics about quoted text, is a premise)

I agree with him about investigating the way OCCT has solved or mitigated the problem, as TNP has no a "solution" as "it depends" heavily on how you make a model, if you refer to face3 that is say the top of a nail and change this to a screw, probably face3 is not "translated" properly with something similar to a circle and probably attaching something to his center is not a clever thing, as there is the "hole" on which the tools has to be inserted.

So no "universal solution" for TNP is possible.

But

have been investigated years ago and found to be unappropriate

this sentece has some flaws

1) years ago
2) found to be unappropriate because ...

Probably some things are changed and probably some work on "reinvestigate could be done" as probably the because in point 2 could have been solved.

But also this "apparent solution" has some flaws:

1) how deep in the core of FC is the "workaround implemented" to circumvent the problem
2) why this approach has not been followed by RT, as he is probably the more entitled people to say something about TNP mitigation for FC.

As usual simple is rarely a viable solution when dealing with complex software.

It will be interesting to hear some other developers but as the TNP question has been discussed in deep time ago and the final decision was to rely on RT to bring his solution on FC, probably the most clever way is to make another meeting and see what help the developers could supply to RT to finish the "hard task".

He has recently posted some complains about divergent sources that are difficult to sort out due to the "amount of cosmetics changes" to the sources (so when he is doing a diff is difficult to sort out what relevant part of code is changed).

https://forum.freecadweb.org/viewtopic. ... 02#p611902

Sadly this is not a "one way" process, as he has a slow pace to sync sources of his branch with "stock FC" and some RT version user are complaining about this fact.

https://forum.freecadweb.org/viewtopic. ... 04#p612204

The only solution i could foresee is to "stop developing FC" and concentrate all efforts on "integrating TNP" helping RT to sort out the cosmetics changes, but this is a very difficult solution to implement due to the "creative anarchy" that an OpenSource project usually have in the "developing path".

But probably some steps could be achieved if maybe RT and "core developers" could establish a more strict coordination, if this has not already done as I'm a normal user so I have not idea how developers are working together.

Regards

Carlo D.

EDIT added some link to the discussion.

[realthunder]

The TNaming interface has been investigated by others. And in fact, around the same time I was developing my solution, there is another forum member ezzieyguywuf was giving another look at TNaming. See this thread. To complete the picture, this is the thread about my implementation. If any of you are really curious, be patient, and go through the posts there. For the inpatient ones, here is what ezzieyguywuf's opinion about using TNaming. And just few posts up, you can find wmayer's opinion about reinventing the wheels. Only if you have the chance to browse through OCCT's code, you'll know what is pain. Not that my code is easy to follow and all, but at least I am here as the first author to answer questions.

[Zolko]

The TNaming interface has been investigated by others. And in fact, around the same time I was developing my solution, there is another forum member ezzieyguywuf was giving another look at TNaming

Thanx, interesting read. If I understand correctly, it sort-of worked.

• the FreeCAD internals (Sketcher here)
• the OCC form (the shape)
• the Coin3D form (the node in the scenegraph)

From what I understand, the TNaming framework has many aspects: one of them is to create named shapes (Other aspects are the history representation for a general TNP solution, which seems difficult with the entire OCAF/TNaming code) :

https://dev.opencascade.org/doc/occt-7. ... t_ocaf_5_4

restricting the issue to only sketches, then the explicit naming of shapes could be used, and this could solve the toponaming problem for sketches alone, as described earlier.

Not sure how useful that would be. Not sure how difficult it would be either.