FreeCAD Forum

Hello all, recent development of the sketch export feature got me inspired to take on the infamous Topological Naming problem. I've released a custom build of FreeCAD for anyone interested to test first. Currently, the new stable names only work for compound and sketch. I'll add more in the next release. You can find technical document at here.

The following screencast shows its working. As you can see, after I reordered compound children, the Shapebinder's element reference is auto corrected. And when you copy the body and all its dependent object, new element names are generated, but without negative effect on the copied Shapebinder's reference.

Looks very promising. Will this be in master as soon as 0.17 is stable? I haven't gone through the self compiling process yet.

chrisb wrote: ↑Tue Mar 06, 2018 8:54 am Looks very promising. Will this be in master as soon as 0.17 is stable? I haven't gone through the self compiling process yet.

You can try it with the pre-built image in the release page. It is in sync with the current upstream master. Although, if you aren't a developer, there isn't much to see for the stable topo naming effect yet. Maybe you will be interested in other features. I know you want the enhanced shape binder

Wow! I'm impressed (and a bit jealous ). I still think I'll move forward with the work I'm doing (essentially, a wrapper around OCC to make unit testing easier, and then a c++ version of my previous python solution utilizing this OCC wrapper) as at the very least it will give us two different approaches to consider and evaluate.

I'm super impressed at the depth with which you attacked this and the level of integration into the core FreeCAD codebase, this is exactly what we need in order to solve this problem.

Whow, thank you so much for your great work.
I hope you can crack the nut.

Hi @realthunder.

First of all i guess now we can finally agree on something we discussed in the past. Link effort by itself doesn't have all that much with topological naming issue does it?

Each document object in FreeCAD will now be assigned an integer identification number that is unique within its owner document.

This would likely be nice to have in general. Checking the features against some UUID and not caring about Undo/Redo framework and things like that. For example a "Notes App" could add a Note to a feature with some UUID. Rather straightforward approach. I guess.

As for the rest (topology related) i read the proposal. It doesn't feel like a history based solution. The sketcher proposal is easier to understand. And i see some sense there. Use other geometry in sketch to try to determine what was added or removed. And try to name everything accordingly after. But as for the more general question. For example creating a Sketcher Rectangle and Pad it. Use the top face of the Pad feature to create a Shapebinder. Go back and modify the Sketcher Rectangle by adding a circle inside it. Is the Shapebinder at expected Pad feature top face after?

This is what topological naming is after to resolve. I do feel your understanding of the issues involved has improved. From the initial discussions. But still likely (at least the impression i got reading your current proposal) you aren't tackling this with your current proposal directly.

triplus wrote: ↑Tue Mar 06, 2018 9:03 pm For example creating a Sketcher Rectangle and Pad it. Use the top face of the Pad feature to create a Shapebinder. Go back and modify the Sketcher Rectangle by adding a circle inside it. Is the Shapebinder at expected Pad feature top face after?

The proposal is mostly a framework such that other workbench can focus on how to implement the details of naming the elements without worrying about other distracting yet critical issues. For your particular example, it is simple. We can name the face by sorting and concatenating the names of the edges of the outer wire only. Since sketch now provides stable names for its edges, its derived face will be stable too. And I will be doing that for the next release.

This is what topological naming is after to resolve. I do feel your understanding of the issues involved has improved. From the initial discussions. But still likely (at least the impression i got reading your current proposal) you aren't tackling this with your current proposal directly.

A proper topological naming is not the solution for everything like many people seem to think. There will always be certain ways of modification that cause the element to be renamed. And that may be a good thing, as long as we make sure the names are not reused if the elements are topologically different.

Such as for your example above, if the user adds an edge to the outer wire, then the face name will change. We may have more complex rules to still keep the same name, but there will never be a catch-all magic rule. What if the user adds 10 edges? The solution I proposed in Assembly3, i.e. the Element concept, is a higher level solution for this problem. So that when the inevitable changes of element names do occur, it is explicit and easy to fix, but it has to be done by the user, manually.

Sounds good. Maybe one more observation. When you say "topologically different". Likely an (possibly complementary) approach where saying "geometrically different" exist too. Each having its pros and cons. But anyway this is now already theoretical discussion.

You decided to work on something. And we can test in practice on what results your approach produces. Hard to argue with that.

I have added full support of element mapping to Part WB. In addition, pure python feature now should be able to get full benefit of stable names without any code change. I have tested some python feature in Part WB. Unfortunately, PartDesign mostly use c++, and never really use Part::TopoShape, but instead, access OCCT TopoDS_Shape directly, which means lots of code changes awaiting. I still need to do some more tests before release a new version. PartDesign will definitely have to wait for the next release. Here is a sneak peek.




As you can see, after fusion the element got some funny looking names. I didn't turn on hashing, so you are seeing the raw names. After refine, the fillet edge index changed from 9 to 5, but the fillet stays the same. The refined top face got a really long names. I'll post naming algorithm in my wiki page later.

I then turned on the hasher. The name became manageable. Mind you that once hasher setting is changed, all element names of all geometry objects in the document must be regenerated, hence the recompute. But, as you can see, the fillet still remains correct.

Finally, I added another cylinder, and the edge geometrically changed. The fillet is officially broken. But, fear not, once you double click the fillet, it can magically suggest you the correct edge. So you know that I can deduce the related edges, but choose not to do it automatically. Because I think it is better to be explicit here, like many other fancy CAD do. Maybe that'll make FreeCAD feel 'expensive', too.

PS. I've modified tree view to auto expand and show you any items that failed during a recompute, so you'll know exactly what to fix.

realthunder wrote: ↑Wed Mar 21, 2018 11:19 am Finally, I added another cylinder, and the edge geometrically changed. The fillet is officially broken. But, fear not, once you double click the fillet, it can magically suggest you the correct edge. So you know that I can deduce the related edges, but choose not to do it automatically. Because I think it is better to be explicit here, like many other fancy CAD do. Maybe that'll make FreeCAD feel 'expensive', too.

It looks great! Indeed we will for sure be able to increase the yearly subscription by 500% because of this, from 0 to 0

realthunder wrote: ↑Wed Mar 21, 2018 11:19 am PS. I've modified tree view to auto expand and show you any items that failed during a recompute, so you'll know exactly what to fix.

How about showing it also in the model, like maybe coloring the broken fillet in red or something?