according to this post, doing a motorcycle frame in FreeCAD-core and LinkBranch, you get a file-size an order of magnitude larger with the LinkBranch (212Mb -vs- 13Mb). I wouldn't call it a "working implementation ". Has this been investigated further ?adrianinsaval wrote: ↑Fri Jul 15, 2022 5:23 pm I would agree if it weren't for the fact that we already have a working implementation for Part and Part Design
[meeting minutes] developer meeting on how to integrate Toponaming
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: [meeting minutes] developer meeting on how to integrate Toponaming
Re: [meeting minutes] developer meeting on how to integrate Toponaming
++1 !Zolko wrote: ↑Fri Jul 15, 2022 3:48 pm As it happens, Sketcher is quite standalone in the FreeCAD source, AND is the base for nearly all other tasks. Therefore, if we can solve the toponaming problem for sketches, then all users would profit from it, AND this could be a task done earlier that for the full-blown solution. So what I'd like to be considered is to lower the goal for v0.21 to solve the toponaming issue for sketches.
"It is a poor workman who blames his tools..."
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: [meeting minutes] developer meeting on how to integrate Toponaming
Yes, sure. See my analysis here, and here. It is most likely an OCC problem.Zolko wrote: ↑Fri Jul 15, 2022 10:42 pmaccording to this post, doing a motorcycle frame in FreeCAD-core and LinkBranch, you get a file-size an order of magnitude larger with the LinkBranch (212Mb -vs- 13Mb). I wouldn't call it a "working implementation ". Has this been investigated further ?adrianinsaval wrote: ↑Fri Jul 15, 2022 5:23 pm I would agree if it weren't for the fact that we already have a working implementation for Part and Part Design
- adrianinsaval
- Veteran
- Posts: 5534
- Joined: Thu Apr 05, 2018 5:15 pm
Re: [meeting minutes] developer meeting on how to integrate Toponaming
It's an implementation and it works, it has massive user testing, more than any other change ever accepted in master. What would you call it then?
I appreciate that you are actually looking into this thing and trying to find errors though, that's what we need. Delaying this thing further for no tangible reason is still not a good idea IMO.
Re: [meeting minutes] developer meeting on how to integrate Toponaming
Do you know and understand the algorithm and rhe implémentation ? I don't
What I do know is that the topological naming is an inherent problem of CAD systems. It is IMPOSSIBLE to generally SOLVE it, the best it is possible to do is to IMPROVE the situation..
Therefore, I'm trying to improve the situation in the least intrusive way. And in the most MAINTANABLE way And I will say it bluntly : if therre is only a single person., as competent and good-willing he might be, who knows the source code for such core functionality, it's the death of FreeCAD.
So I must insist : WHO knows and understands and can modify this toponaming part ?
Re: [meeting minutes] developer meeting on how to integrate Toponaming
Easy. We agreed in two meetings that as many as possible developer should understand the code. Therefore we have the separate branch and don't merge it directly to master. This way it can maturize and I hope you join us in testing and reviewing.
As I know @realthunder, he will also setup a Wiki page describing the idea behind his algorithm and the way he implements it. So stay tuned for his first actions in the toponaming branch.
- adrianinsaval
- Veteran
- Posts: 5534
- Joined: Thu Apr 05, 2018 5:15 pm
Re: [meeting minutes] developer meeting on how to integrate Toponaming
doesn't change the fact that it is implemented and it works, I'm not saying is perfect and should be accepted without review, but a fact is fact despite whatever you have on the implementation.
We've known this from the get go and nobody with half knowledge on the subject is saying otherwise. It was always about mitigating.What I do know is that the topological naming is an inherent problem of CAD systems. It is IMPOSSIBLE to generally SOLVE it, the best it is possible to do is to IMPROVE the situation..
I don't believe it's possible to be even less intrusive than realthunder's method, at least not in any significant wayTherefore, I'm trying to improve the situation in the least intrusive way.
This is a good point and it's the reason it's not merged yet after years of development and testing, but once again this is not a reason to discard and search for other methods (that would likely have the same problem).And in the most MAINTANABLE way And I will say it bluntly : if therre is only a single person., as competent and good-willing he might be, who knows the source code for such core functionality, it's the death of FreeCAD.
Re: [meeting minutes] developer meeting on how to integrate Toponaming
OK, so can we agree that you acknowledge that NO current developer - apart from realthunder himself of course - knows and understands the code to be merged ? A HUGE amount of code that is !adrianinsaval wrote: ↑Sat Jul 16, 2022 9:34 pmdoesn't change the fact that it is implemented and it works
What you believe or not is irrelevant. I've already explained how it is possible to solve the topological naming problem for sketches alone, all it needs is to know how it is possible to create OCC objects with FreeCAD-given names.
So it boils down to this: is it currently possible to create OCC objects with names chosen by FreeCAD ?
- if "yes", then please indicate where in the code it's done (Edge15, Vertex5 ...)
- if "no" then this is the first part to be implemented to solve the topological naming issue, independently from what exact algorithm is going to be used for that later down the road. This and only this, so it can be tested and debugged.
wmayer wrote: ping
abdullah wrote: ping
- adrianinsaval
- Veteran
- Posts: 5534
- Joined: Thu Apr 05, 2018 5:15 pm
Re: [meeting minutes] developer meeting on how to integrate Toponaming
As I said, that's why it's not merged.
I have probably confused you there, from my understanding the "names" that sketcher assigns are only for internal sketcher use, the subobjects in the shape property (and those are the ones being referenced outside) always have names given by occt and that is out of FreeCAD's control, the elements inside the sketch also don't have a stable numbering but I personally have never seen that causing problems, the unstable constraint numbers are problematic for expressions though, these unstable index are similar in nature to TNP but it is not the TNP so solving it would not solve the TNP.I've already explained how it is possible to solve the topological naming problem for sketches alone, all it needs is to know how it is possible to create OCC objects with FreeCAD-given names.
AFAIK no.So it boils down to this: is it currently possible to create OCC objects with names chosen by FreeCAD ?
Changing the names that occt uses would require changes in occt itself, if you have a proposal to have different toponaming in occt go ahead and make a proposal to them and then make an interface in FreeCAD once it's done, that would be a lot more years waiting for an hypothetical different implementation (that might be inferior or not have any tangible advantage) instead of using the working one we have here, why not make the effort to understand and improve were needed realthunder's code instead of trying to do everything from scratch?if "no" then this is the first part to be implemented to solve the topological naming issue, independently from what exact algorithm is going to be used for that later down the road. This and only this, so it can be tested and debugged.
If you mean to have a parallel naming algorithm in FreeCAD that is stable and can be mapped to the occt names then that's exactly what realthunder did and what he's trying to get merged so what's your point? You want to do it in stages? AFAIK that's already the plan.
Re: [meeting minutes] developer meeting on how to integrate Toponaming
Why do you make such statements?
You even cited my writing that we agreed that several developer must understand the code otherwise it cannot be merged. I think this very clear.
And now please get us to work and make it happen.