Thanks for the upload! Very thorough work. In my understanding TNP is a fundamental logical problem of feature based CAD programs. In my company we used to use several commercial CAD programs before, and I cannot remember one where a more complicated design did not collapse eventually. I think TNP can only be solved by the solver - actually with bruteforce. The difference with FreeCAD is, that its comunity at least adresses this issue openly. I think it only occurs in Part Design, that is a feature based method. By the nature of the issue I would think, the other fundamental method, Part (based on constructive solid geometry) is free of this issue. The good thing is that FreeCAD can do both. The interesting thing is, understanding the problem, it is very easy to make safe designs. In the rarity when it still happens, it is easy to fix. In my practice FreeCAD is still the best CAD program, not because it is free of charge, but because it is free of secret, corporate wizardry. In my experience community support is less elegant than corporate support, but it is always more efficient. I prefer donating a project like this.
Thanks for a great comment. Loved "In my practice FreeCAD is still the best CAD program, not because it is free of charge, but because it is free of secret, corporate wizardry." We know what we have, and we are thankful for it.
I'd agree but, to expand on it being a "fundamental logical problem", I think the issue is that there are times when the change is inherently ambiguous. In simple cases it's so obvious that it seems stupid that it's even an issue, but there are cases where there is intrinsic uncertainty about what the designer wants. I think about it a bit like translating between languages. In japanese there are name-suffixes (-kun, -chan, etc.) but there aren't in english. That means (unless you retain the suffix in the english translation) there is no way, from text alone, to convert perfectly from japanese->english->japanese. Converting to english requires making lossy changes that leave more ambiguity in the translation than there was originally. (this is true for all translations and is why if you send text through google translate a bunch of times it comes out completely mangled) An example that *_might_* be good for describing this is: assume you had a perfectly square box with a hole going through the top-center all the way through the bottom. Then assume you changed the shape from a box to a "house" that had a pointed roof. What face should that hole-punch be attached to? There are no more flat faces on the top of the shape; the change you made is intrinsically lossy. However, by making a datum-plane you're not saying "attach it to the top face" you're saying "go as high as the the shape is and punch a hole through it downwards", removing the reliance on the geometry of the shape itself. In this sense the "topological naming problem" isn't actually the problem at all, it's just how the problem manifests in Freecad specifically. (I've seen plenty of people say that other CAD suites break down as well, they just tend to have a bit more flexibility and will let you get away with more) In a manner of thinking the TNP is basically the same as a merge-conflict in something like git; you went back in time and changed something and changing that thing means the later changes that you made no-longer work properly. Thinking about it even *_more_* generally, it's basically a time-paradox. (or, maybe not a "paradox", but time travel breaking stuff in-general) John grabs an apple and eats it on the way to work, so he doesn't bring his lunch. If you go back in time and replace the apple with a banana, everything should more or less work out the same. If you go back in time and steal the apple without replacing it then it no longer makes sense why he didn't bring his lunch to work. There are some changes you can make to the timeline which *_shouldn't_* break anything, and there are other changes you can make to the timeline that would lead to entirely different things taking place. "fixing" the TNP really just means making an algorithm that can somewhat-accurately predict what it is that the designer wants the new model to be, but it's not a "solvable" problem. (this is why I kinda hope that they also streamline making datum-planes. No matter how good that algorithm is it'll never be perfect so it'll always be good practice to use datum-planes. Tons of focus has been put on "fixing" the TNP, but datum-planes will always be a better solution so using them should be made clearer and easier.)
@@robonator2945 I think you hit the nail by the head. I like your analogy with languages, because this is really where TNP lies. In practice models are specified in some human language: "Please design a body with a flat top, and drill a hole in the top. Then: "Change the footprint of the body from rectangle to pentagon." But it contains some implicite details for a human: "Top" is the highest surface "flat" probably means horizontal, and straight. "Footprint" is a drawing on the ground plane. Humans know what they mean. However a cad program executes it like: "Design a body with a flat top, then drill a hole in the 6th face". Thus the pentagon mod will corrupt the model, because it turns the top into face 7. Yet, in fact, the program does what it is supposed to do, it is just not what human mind expects. As for the datum plane, I would extend it: a good designer must highlight the essential details in the task. In your example it is the TOP FACE where the hole should go. With this assumption, he will break down the original instruction like: - Create an arbitrary profile (it happens to be a rectangle now, but the client always changes his mind, so make it generic), - Pad it to a given height, specified with a variable (or aliased spreadsheet cell). - Create a sketch (or a datum plane with a sketch on it) parallel with the pad profile sketch, in a height equal to the pad length (variable) - the TOP. - Draw the hole profile on this plane, and pocket it. Although a good designer must always work with this mindset, unfortunately, this is very labor intensive, and I think, some situations can be corrected with some smart algorithms considering these implicit human rules. I have never been involved in cad program development, but I think this is how TNP can be more or less eliminated. I check the weekly build of FC 0.22 eventually, and I think, these guys are doing some magic. AFAIK they partially reimplement RealThunder's mods, but from what I've seen, they go much farther. Well done FC team, and thanks.
hi again mate. good job. I appreciate it. for people watching your videos, another workaround can be: in "Datum Plane parameters" >> "Attachment Offset" >> "In z-direction:" instead of using data from spreadsheet we can use .Length it gives the same result without using spreadsheet.
Your explanations with examples is just what i needed to understand the issue. A temporary convenience the programmers could do would be to add a "create data plane from selected face" feature. You'd still need to update the offset to match any change like you did or hook it to a spreadsheet or whatever, but it would make it easier to get the data plane set up.
that wouldn't even be a "temporary convenience" actually, it'd be a permanent one. The TNP isn't a problem that can be entirely "solved". If you make a square, draw a sketch on top, and put a hole through the middle of it *_then_* you change the shape to be a "house" shape with a triangular roof there are no longer any valid planes for that sketch to attach to. (well, I mean you could make a sketch on the bottom of the shape, but then you could just make that triangular too) If however you used a datum-plane then it doesn't matter that there are no valid planes for the sketch to attach to, and the hole will still be drilled through the middle like you wanted. When people talk about "solving" the TNP, they really mean making an algorithm that can guess what the user wants in simple-cases, but it's not a "solvable" problem. There are cases where using either shape-faces or datum-planes more accurately represent what you want as a designer and using datum-planes will always be best-practice as a result. (to be clear, I don't disagree with you, they should streamline their usage. My point is just that it wouldn't be a temporary-fix because datum-planes themselves will always be necessary.)
1:16 Tip: You do this with fewer constraints: One symmetry constraint between 2 diagonal vertices ,symmetrical about the origin (0,0) One equal constraint between any pair of conjoined sides One length constraint on any side
The Part and Part Design differences are a mystery to me sometimes. They seem to have Yellow and Blue block looking Icons and very little explanation further. Both build Parts but one has "Body" but the other not. I agree, Part WB just works easier imo. The whole "tree" thing sometimes works in one WB and does not work in the other. What is map mode ? What does "topological" mean ? Anyway, thanks for the explanation of the "Datum" plain.
My dream is for FreeCAD to consolidate these two workbenches with their best features included. But for now, agreed that Part wb works better. In my Beginner's Test series, I used mostly part workbench. In the new 200 model series, I will try to do some work in part design to discover its features.
@@kattkushol Yes. I suppose it is very complicated for the developers as the basis of operation is different. There are some guys who do amazing things in Part Designer workbench. Mine works sometimes and then I do some parameterizing and the model falls apart. 😂
I am a software designer. They should use a guid (random numbers and letters) to name things. They could still allow a visible custom created "friendly name" if needed, but using a guid instead of a numbered name would get rid of this problem.
Exactly. A sequential number is not required in this case. Thanks for that. Naming these faces using a "guid" would solve a big part of this problem. Apparently, there is another issue that the developers are also trying to solve. To quote Brad Collette (@sliptonic on X) "Consider if you named the top face 'top' and then made a change that divided it in half. Which of the new faces is 'top'?" As I read on FreeCAD's blog, solving this naming problem is their one of four major milestones that they want to achieve before releasing a 1.0 version of the software. So, that's hopeful.
@@kattkushol Using a GUID for the face name solves close to nothing, as you would still have to match the "new faces" to the old faces to keep the GUID constant. And if you can perform that feat, you could also assign the new faces the old style "incremental" names.
If you travel back in time, you will see at 0.19 a (partial) fix was said to be coming in 0.20. In 0.20, it was coming in the next release (0.21). I'm sure it will be fixed in the "next" release.
The FreeCAD blog (15 Nov 2023 blog.freecad.org/) said, @chennes is working on Toponaming merge and TopoShape. So you are right about the "next" release. I am praying for @chennes. I love this software so much that it's worth praying for @chennes for two minutes every day.
@@kattkusholvirtually same post exist on 0.20. Always "next". I know it's free, but something this big needs pulled to the top of the list for all hands on deck and ger'r done.
@@warrenbrown8670 Apparently, the prayer worked, and we do have some mitigation of TNP in the new FreeCAD 1.0 version. If we the userbase keep asking for the things that we care most about, it helps the entire community.
I wonder if every primitive element could have a prefix invisible to the user - the file name. Then each individual element named by convention starting with 0 and 1 logical coding by class (points start with 000’ lines with 001, planes 003, etc and two places may be enough). Then assemblies would be protected from the same issue when an external model is linked as a component. That subassembly might need to be broken in context, modified, and recollected as a new part number. The nature of part assemblies and part numbers would provide the needed “invisible prefix” input. Perhaps this is too much overhead, I don’t know.
I gave up using FreeCAD for anything important, but not because of the naming problem, mainly to do with text handling. I use DesignSpark mechanical instead. I can draw on any surface or plane, and then at some point, delete the surface or plane without affecting any other part of my design. If DS can do it, why not FreeCAD? I did wonder if there was a way to automatically create a plane on a surface that didn't rely on the surface for it's location in space. If you get what I mean.
Well, a lot of people make the distinction between open source and commercial software packages. The least we could do to promote FreeCAD, an open source software, is to use it and be a part of the discussion.
![The most annoying problem in FreeCAD 0.19 Part Design - Topological Naming [LIVE] (English)](http://i.ytimg.com/vi/GKn5kAYmfQE/mqdefault.jpg)
Thanks for the upload! Very thorough work.
In my understanding TNP is a fundamental logical problem of feature based CAD programs. In my company we used to use several commercial CAD programs before, and I cannot remember one where a more complicated design did not collapse eventually. I think TNP can only be solved by the solver - actually with bruteforce. The difference with FreeCAD is, that its comunity at least adresses this issue openly.
I think it only occurs in Part Design, that is a feature based method. By the nature of the issue I would think, the other fundamental method, Part (based on constructive solid geometry) is free of this issue. The good thing is that FreeCAD can do both.
The interesting thing is, understanding the problem, it is very easy to make safe designs. In the rarity when it still happens, it is easy to fix.
In my practice FreeCAD is still the best CAD program, not because it is free of charge, but because it is free of secret, corporate wizardry. In my experience community support is less elegant than corporate support, but it is always more efficient. I prefer donating a project like this.
Thanks for a great comment. Loved "In my practice FreeCAD is still the best CAD program, not because it is free of charge, but because it is free of secret, corporate wizardry."
We know what we have, and we are thankful for it.
I'd agree but, to expand on it being a "fundamental logical problem", I think the issue is that there are times when the change is inherently ambiguous. In simple cases it's so obvious that it seems stupid that it's even an issue, but there are cases where there is intrinsic uncertainty about what the designer wants.
I think about it a bit like translating between languages. In japanese there are name-suffixes (-kun, -chan, etc.) but there aren't in english. That means (unless you retain the suffix in the english translation) there is no way, from text alone, to convert perfectly from japanese->english->japanese. Converting to english requires making lossy changes that leave more ambiguity in the translation than there was originally. (this is true for all translations and is why if you send text through google translate a bunch of times it comes out completely mangled)
An example that *_might_* be good for describing this is: assume you had a perfectly square box with a hole going through the top-center all the way through the bottom. Then assume you changed the shape from a box to a "house" that had a pointed roof. What face should that hole-punch be attached to? There are no more flat faces on the top of the shape; the change you made is intrinsically lossy. However, by making a datum-plane you're not saying "attach it to the top face" you're saying "go as high as the the shape is and punch a hole through it downwards", removing the reliance on the geometry of the shape itself.
In this sense the "topological naming problem" isn't actually the problem at all, it's just how the problem manifests in Freecad specifically. (I've seen plenty of people say that other CAD suites break down as well, they just tend to have a bit more flexibility and will let you get away with more) In a manner of thinking the TNP is basically the same as a merge-conflict in something like git; you went back in time and changed something and changing that thing means the later changes that you made no-longer work properly. Thinking about it even *_more_* generally, it's basically a time-paradox. (or, maybe not a "paradox", but time travel breaking stuff in-general) John grabs an apple and eats it on the way to work, so he doesn't bring his lunch. If you go back in time and replace the apple with a banana, everything should more or less work out the same. If you go back in time and steal the apple without replacing it then it no longer makes sense why he didn't bring his lunch to work. There are some changes you can make to the timeline which *_shouldn't_* break anything, and there are other changes you can make to the timeline that would lead to entirely different things taking place.
"fixing" the TNP really just means making an algorithm that can somewhat-accurately predict what it is that the designer wants the new model to be, but it's not a "solvable" problem. (this is why I kinda hope that they also streamline making datum-planes. No matter how good that algorithm is it'll never be perfect so it'll always be good practice to use datum-planes. Tons of focus has been put on "fixing" the TNP, but datum-planes will always be a better solution so using them should be made clearer and easier.)
@@robonator2945 I think you hit the nail by the head. I like your analogy with languages, because this is really where TNP lies. In practice models are specified in some human language: "Please design a body with a flat top, and drill a hole in the top. Then: "Change the footprint of the body from rectangle to pentagon." But it contains some implicite details for a human: "Top" is the highest surface "flat" probably means horizontal, and straight. "Footprint" is a drawing on the ground plane. Humans know what they mean. However a cad program executes it like: "Design a body with a flat top, then drill a hole in the 6th face". Thus the pentagon mod will corrupt the model, because it turns the top into face 7. Yet, in fact, the program does what it is supposed to do, it is just not what human mind expects.
As for the datum plane, I would extend it: a good designer must highlight the essential details in the task. In your example it is the TOP FACE where the hole should go. With this assumption, he will break down the original instruction like:
- Create an arbitrary profile (it happens to be a rectangle now, but the client always changes his mind, so make it generic),
- Pad it to a given height, specified with a variable (or aliased spreadsheet cell).
- Create a sketch (or a datum plane with a sketch on it) parallel with the pad profile sketch, in a height equal to the pad length (variable) - the TOP.
- Draw the hole profile on this plane, and pocket it.
Although a good designer must always work with this mindset, unfortunately, this is very labor intensive, and I think, some situations can be corrected with some smart algorithms considering these implicit human rules. I have never been involved in cad program development, but I think this is how TNP can be more or less eliminated. I check the weekly build of FC 0.22 eventually, and I think, these guys are doing some magic. AFAIK they partially reimplement RealThunder's mods, but from what I've seen, they go much farther. Well done FC team, and thanks.
hi again mate. good job. I appreciate it.
for people watching your videos, another workaround can be:
in "Datum Plane parameters" >> "Attachment Offset" >> "In z-direction:" instead of using data from spreadsheet we can use .Length
it gives the same result without using spreadsheet.
Thanks, will give it a try. It might be a better one, especially if spreadsheet is not used in the project for any other reason.
I don't use a datum plane, I directly set the z offset of the sketch to the pad length.
@@philippdenzler1229 A fellow sketch offset'er :)
I wanted to say the same. I tried it and it works on FreeCAD 0.20.2
instead of defining variable in spreadsheet you can use datum plane as face for pad offset (pad type: up to face)
Your explanations with examples is just what i needed to understand the issue.
A temporary convenience the programmers could do would be to add a "create data plane from selected face" feature. You'd still need to update the offset to match any change like you did or hook it to a spreadsheet or whatever, but it would make it easier to get the data plane set up.
that wouldn't even be a "temporary convenience" actually, it'd be a permanent one. The TNP isn't a problem that can be entirely "solved". If you make a square, draw a sketch on top, and put a hole through the middle of it *_then_* you change the shape to be a "house" shape with a triangular roof there are no longer any valid planes for that sketch to attach to. (well, I mean you could make a sketch on the bottom of the shape, but then you could just make that triangular too) If however you used a datum-plane then it doesn't matter that there are no valid planes for the sketch to attach to, and the hole will still be drilled through the middle like you wanted.
When people talk about "solving" the TNP, they really mean making an algorithm that can guess what the user wants in simple-cases, but it's not a "solvable" problem. There are cases where using either shape-faces or datum-planes more accurately represent what you want as a designer and using datum-planes will always be best-practice as a result.
(to be clear, I don't disagree with you, they should streamline their usage. My point is just that it wouldn't be a temporary-fix because datum-planes themselves will always be necessary.)
Once you fully understand how to sketch in FreeCAD the topological naming problem goes away and your models become very stable for changes.
🙏 thank you
1:16 Tip: You do this with fewer constraints:
One symmetry constraint between 2 diagonal vertices ,symmetrical about the origin (0,0)
One equal constraint between any pair of conjoined sides
One length constraint on any side
I was kinda waiting for this comment. So, thanks. I see you.
The Part and Part Design differences are a mystery to me sometimes. They seem to have Yellow and Blue block looking Icons and very little explanation further. Both build Parts but one has "Body" but the other not. I agree, Part WB just works easier imo. The whole "tree" thing sometimes works in one WB and does not work in the other.
What is map mode ? What does "topological" mean ?
Anyway, thanks for the explanation of the "Datum" plain.
My dream is for FreeCAD to consolidate these two workbenches with their best features included. But for now, agreed that Part wb works better. In my Beginner's Test series, I used mostly part workbench. In the new 200 model series, I will try to do some work in part design to discover its features.
@@kattkushol Yes. I suppose it is very complicated for the developers as the basis of operation is different. There are some guys who do amazing things in Part Designer workbench. Mine works sometimes and then I do some parameterizing and the model falls apart. 😂
I am a software designer. They should use a guid (random numbers and letters) to name things. They could still allow a visible custom created "friendly name" if needed, but using a guid instead of a numbered name would get rid of this problem.
Exactly. A sequential number is not required in this case. Thanks for that.
Naming these faces using a "guid" would solve a big part of this problem. Apparently, there is another issue that the developers are also trying to solve. To quote Brad Collette (@sliptonic on X) "Consider if you named the top face 'top' and then made a change that divided it in half. Which of the new faces is 'top'?"
As I read on FreeCAD's blog, solving this naming problem is their one of four major milestones that they want to achieve before releasing a 1.0 version of the software. So, that's hopeful.
@@kattkushol Using a GUID for the face name solves close to nothing, as you would still have to match the "new faces" to the old faces to keep the GUID constant.
And if you can perform that feat, you could also assign the new faces the old style "incremental" names.
What is a "guid" ?
@@Appregator Globally Unique Identifier.
@@jhon614 Thanks. Computer people speak a different language of acronyms.
How about giving the faces the same names as the navigation cube? Sounds kind of intuitive.
If you travel back in time, you will see at 0.19 a (partial) fix was said to be coming in 0.20. In 0.20, it was coming in the next release (0.21). I'm sure it will be fixed in the "next" release.
The FreeCAD blog (15 Nov 2023 blog.freecad.org/) said, @chennes is working on Toponaming merge and TopoShape. So you are right about the "next" release. I am praying for @chennes. I love this software so much that it's worth praying for @chennes for two minutes every day.
@@kattkusholvirtually same post exist on 0.20. Always "next". I know it's free, but something this big needs pulled to the top of the list for all hands on deck and ger'r done.
@@warrenbrown8670 Apparently, the prayer worked, and we do have some mitigation of TNP in the new FreeCAD 1.0 version. If we the userbase keep asking for the things that we care most about, it helps the entire community.
The Real Thunder link branch version seems to help with much of this.
help me out here, is that a different variant of FreeCAD?
th-cam.com/video/p_ZEry2wTfg/w-d-xo.htmlsi=PRTKlD2os3gIuZ8b@@kattkushol
I wonder if every primitive element could have a prefix invisible to the user - the file name. Then each individual element named by convention starting with 0 and 1 logical coding by class (points start with 000’ lines with 001, planes 003, etc and two places may be enough). Then assemblies would be protected from the same issue when an external model is linked as a component. That subassembly might need to be broken in context, modified, and recollected as a new part number. The nature of part assemblies and part numbers would provide the needed “invisible prefix” input. Perhaps this is too much overhead, I don’t know.
I gave up using FreeCAD for anything important, but not because of the naming problem, mainly to do with text handling. I use DesignSpark mechanical instead. I can draw on any surface or plane, and then at some point, delete the surface or plane without affecting any other part of my design. If DS can do it, why not FreeCAD? I did wonder if there was a way to automatically create a plane on a surface that didn't rely on the surface for it's location in space. If you get what I mean.
Well, a lot of people make the distinction between open source and commercial software packages. The least we could do to promote FreeCAD, an open source software, is to use it and be a part of the discussion.
With Python scripting you can do many things in FreeCAD