Compatibility questions

Report observations made with the new Toponaming branch.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Compatibility questions

Post by IPowIPi »

With the toponaming fix getting in sight for FreeCAD 1.0 I am strongly considering FreeCAD for a projekt again. As FreeCAD 1.0 isn't there anytime soon yet the question would be which version to use (or to still wait). The question most likely goes towards the people who know the internals of the toponaming implementation:

1) If I start a design in FreeCAD 0.20.2, will it be "toponaming proof" once I import it in FreeCAD 1.0? Or would I have to restart from scratch to get the additional metainfos needed?

2) Essentially the same question as 1, just with 0.20.2 and the current Linkbranch version - if I start with 0.20.2, does the design get "toponaming proof" by just loading it in Linkbranch?

3) In case I couldn't make a 0.20.2 design "toponaming proof" by importing it into FreeCAD 1.0 or LinkBranch - would a design created with the current LinkBranch version be compatible with 1.0 regarding toponaming? Is there a way to switch off features in LinkBranch that couldn't be imported into 1.0 (if any incompatible features should exist)?
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Compatibility questions

Post by IPowIPi »

I think I can answer question 2 empirically: Created a design with a sketch on a face in 0.20.2, saved it and verified that the next operation (which introduces faces) triggers the TNP in 0.20.2 - it does, as expected. Then imported that file in LinkBranch 20230131. It asks for a recompute, when doing the same operation that breaks the sketch assignment in 0.20.2, it works in LinkBranch - yay! So no need to restart from scratch! (As soon as I press undo in LinkBranch the design interestingly *does* break - this is probably a bug, will report that. Edit: Undo just changes the working position (so some features get invisible) and doesn't break anything.).
chrisb
Veteran
Posts: 53925
Joined: Tue Mar 17, 2015 9:14 am

Re: Compatibility questions

Post by chrisb »

You will be able to open 0.20 files in 1.0. If you use Path workbench, the files have to pass an additional migration process.
There is no guarantee, that Linkbranch files can be opened in 1.0, although I guess they will.

Please note that the toponaming issues cannot be "fixed", they can only be mitigated (not only FreeCAD). The techniques to avoid toponaming are universal, and you should apply them in every CAD system: Apply references to the earliest state possible in the model. That will give you maximum stability, because as long as what you reference doesn't change nothing will brake.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Compatibility questions

Post by IPowIPi »

Thanks, sounds promising!

Referencing everything from the base planes is certainly possible but can become quite tedious (long formulas with many variables and chained transformation functions being involved, if things should still stay parametric) - just being able to use any face as reference can make things so much easier!
I often read that the TNP cannot be solved systematically. How is this approached in the commercial CAD kernels? Is it "just" layers on layers of heuristics to cover 99.99% of the cases? Would there be a known sequence of steps that would trigger the problem for an e.g. Parasolid based CAD program? Or even the LinkBranch fix? Or is it more that one cannot prove that such a sequence cannot exist, but none was found yet?
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Compatibility questions

Post by adrianinsaval »

plenty found on commercial software too, they just aren't nearly as bad as current FreeCAD without toponaming, I first learned of toponaming issues and mitigations on a CATIA course.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Compatibility questions

Post by onekk »

Some good introduction on what topology is with some implication on TNP could be found here:

http://quaoar.su/blog/page/indexing-the ... pencascade

There is a decent explanation on how things are done in OCCT and maybe some analysis on how to circumvent some problems.

It is done by a people that was (or maybe is yet) involved in OCCT developing, and from the comments, you could see probably some criticism about some decision taken in the '90 by former developers, but as OCCT is the only OpenSource CAD kenel around, there are no alternatives, for some comparison with existing kernels this article is interesting:

http://quaoar.su/blog/page/introduction ... ng-kernels

It seems that despite being involved in OCCT the author is very lucid in his analysis.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Compatibility questions

Post by IPowIPi »

Thanks, particularly the upper article was an interesting read!
It is plausible that a kernel where geometry is directly linked in the topology tree doesn't suffer at least from topological naming/ geometry numbering issues (as no named or numerical reference is needed, it's a direct link).
My guess is that the naive description of the mitigation is to introduce unique ids per geometry that can additionally be referenced in the topo tree? If yes, is there an easy to understand example where this approach could still fail? And if such an example exists, then this case would probably also be relevant for the kernels that work with direct links from topology to geometry?
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Compatibility questions

Post by adrianinsaval »

IPowIPi wrote: Tue Mar 21, 2023 1:12 pmIt is plausible that a kernel where geometry is directly linked in the topology tree doesn't suffer at least from topological naming/ geometry numbering issues (as no named or numerical reference is needed, it's a direct link).
No the topological naming problem is not an issue of the kernel itself but on how we use the kernel on the freecad side and how we pass topology references to opencascade. It has nothing to with this separation between geometry and topology, whenever we pass a topology reference to opencascade it always knows what underlying geometry that has. The problem is that the topology we are referencing may no longer be the topology we initially wanted to reference after we change the initial parameters and recompute.
My guess is that the naive description of the mitigation is to introduce unique ids per geometry that can additionally be referenced in the topo tree? If yes, is there an easy to understand example where this approach could still fail? And if such an example exists, then this case would probably also be relevant for the kernels that work with direct links from topology to geometry?
no we almost never deal with geometry in freecad, AFAIK only sketcher uses Geom_ objects. What the mitigation does is register the modelling history of each topological element so that when the shape is recomputed it can traceback the newly generated elements and find the equivalents and restore any reference we made to those elements.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Compatibility questions

Post by adrianinsaval »

as for an example of toponaming problem in commercial software, here a quick example on onshape:
brave_8jzTD527DP.gif
brave_8jzTD527DP.gif (455.87 KiB) Viewed 4265 times
hypothetical case: I made a pad and fillets to some edges, but it turns out I needed a round face on that side, so I edit the sketch and replace the line with a circle instead, now the fillet operations has lost it's topology reference because I deleted the edge from which they originated.+
As a human I can intuitively know that the fillet should be on the new face, but software does not have intuition.

Current version of FreeCAD by pure chance works in that example I gave on onshape but breaks on much more mundane stuff, like adding new profiles to the sketch, or would likely break if the model was more complex, and it's even worse because it doesn't let you know it broke unless the operation actually fails, so you could end up with a fillet somewhere else without realizing it. With toponaming algorithm (realthunder's branch) it has the same behavior as onshape.
IPowIPi
Posts: 90
Joined: Sun Jul 25, 2021 9:37 am

Re: Compatibility questions

Post by IPowIPi »

Thanks for the explanations and the example! Ok, if I outright delete the original reference then it is plausible that the association is broken and even a direct link between geometry and topology node wouldn't help. Perhaps in this case the CAD tool could warn before leaving the sketcher that this change removes a reference - and whether one either wants to
a) undo the change
b) select a new reference
c) delete the feature that was linked to the deleted reference

Apparently Onshape doesn't do this... But probably the current behavior (showing the feature as red and thus informing the user to reassign it to a new reference) might be better than guesstimating and auto-assigning it to a maybe-right (but perhaps also maybe-wrong) reference - as a mistake might not be obvious in a more complex design and lead to followup errors. So unless there is a certain solution no assumptions is probably better(?)
Post Reply