A randomly started discussion about the necessity of the PD single solid rule

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Locked
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: #4828 PartDesign: inverse for pocket

Post by adrianinsaval »

drmacro wrote: Thu Mar 23, 2023 10:50 am Pointless? Someone had a reason, at some point.
but is it a good reason? I don't think so, a good reason has not been brought up yet...
drmacro wrote: Thu Mar 23, 2023 10:50 am And, why is it a problem? It is simple enough to make multiple solids in Part workbench if that it is needed.
read the thread... plenty said about this already
drmacro
Veteran
Posts: 8867
Joined: Sun Mar 02, 2014 4:35 pm

Re: #4828 PartDesign: inverse for pocket

Post by drmacro »

adrianinsaval wrote: Thu Mar 23, 2023 12:06 pm
drmacro wrote: Thu Mar 23, 2023 10:50 am Pointless? Someone had a reason, at some point.
but is it a good reason? I don't think so, a good reason has not been brought up yet...
Is it a good reason? I don't know. ( I think the reason is really, that the underlying Boolean that happens when a Pocket is made into the gap between multiple solids and fails is avoided. ...conjecture on my part based on no looking at the code. Obviously, it can be dealt with since it works in LK3)

It has not been changed in main and has been a rub to users that have an issue with it for years. Why hasn't been changed?
drmacro wrote: Thu Mar 23, 2023 10:50 am And, why is it a problem? It is simple enough to make multiple solids in Part workbench if that it is needed.
read the thread... plenty said about this already
This and many other threads, here and in other social media, basically say is it's inconvenient and doesn't work like other CAD systems. Again for years.

There exists a tool that does multiple solids just fine. While we wait for PD to be changed, if you can't think around designing a Body as a single solid, then use the tool that already exists (and has for years) and works fine with multiple solids.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
User avatar
-alex-
Veteran
Posts: 1856
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: A randomly started discussion about the necessity of the PD single solid rule

Post by -alex- »

Of course multi-solids paradigm should be authorized in PD, single solid paradigm is a pita:
- too many objects in treeview
- tedious workflow for parametric designs: body-> other body -> binder -> sketcher Xref -> constrained parametric element. Pffffiew :|

IIRC body container with single paradigm was introduced as a way to manage solids resulting from multiple freatures in PD. It's a way to identify, locate and select solids resulting from PD.
But it's a manual way to do it, like in Catia if I understand correctly what said above. It's not powerful and involves a lots of drawbacks.

If multiple solids were allowed in PD, I vote for, the next step would be to create a new container to collect automatically solids elements resulting from PD features.
Grouping similar solids would be a must (algorithm needed).

Big CADs works this way, it's powerfull.

BTW RT branch is quite a role model about all this stuffs.
saso wrote: Mon Mar 13, 2023 2:28 pm you will now have people that will say that this is not true, or that it is too complicated or that in FC we can do things differently etc. etc. etc. fact is they just don't understand or don't want to understand how things really work, or think that if something just "looks" similar that it can be good enough to work similar and they will happy go on and on defending their tower of babilon and arguing about things that are actually very standard all across the industry, one just has to properly understand them.
+1, well said.
That's sad, because such people brings FC to a lower level.
Last edited by -alex- on Thu Mar 23, 2023 2:25 pm, edited 1 time in total.
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: A randomly started discussion about the necessity of the PD single solid rule

Post by wsteffe »

drmacro wrote: Thu Mar 23, 2023 12:34 pm This and many other threads, here and in other social media, basically say is it's inconvenient and doesn't work like other CAD systems. Again for years.
In fact a lot of people is complaining about the assurdity of the one body/one solid rule.
drmacro wrote: Thu Mar 23, 2023 12:34 pm Is it a good reason? I don't know.
By yourself admission you do not understand why the rule is needed. But you are anyway saying that we should keep it.

You are not alone to follow such an irrational line of tought. It seems to me that it is a quite common practice in the FC developer community.
From time to time I come back here hoping that the many improvements brought by RT in his branch (removal of this rule being one of them) can be ported back to master closing the gap between the two.

But every time such kind of meaningless posts take me away any hope.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: #4828 PartDesign: inverse for pocket

Post by adrianinsaval »

drmacro wrote: Thu Mar 23, 2023 12:34 pm Is it a good reason? I don't know. ( I think the reason is really, that the underlying Boolean that happens when a Pocket is made into the gap between multiple solids and fails is avoided. ...conjecture on my part based on no looking at the code. Obviously, it can be dealt with since it works in LK3)
I have looked at the code, these days a good portion of it is shared with Part workbench and it's trending towards more shared code. Multiple solids work fine on Part WB, this limitation in Part Design is purely artificial.
It has not been changed in main and has been a rub to users that have an issue with it for years. Why hasn't been changed?
First and obvious reason: nobody has made a PR
But there are other underlying reasons such as the unreasonable opposition that there is against this change.
And of course all of us long time users have learned to workaround this silly thing so usually other improvements get more attention.
There exists a tool that does multiple solids just fine. While we wait for PD to be changed, if you can't think around designing a Body as a single solid, then use the tool that already exists (and has for years) and works fine with multiple solids.
drmacro you've seen me long enough in this forum, do you really think I don't know how to workaround this limitation? You know that is not the point.
-alex- wrote: Thu Mar 23, 2023 1:06 pm like in Catia if I understand correctly what said above. It's not powerful and involves a lots of drawbacks.
No CATIA allows multiple solids in the same container without issues. I am not aware of any drawback for this.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: A randomly started discussion about the necessity of the PD single solid rule

Post by adrianinsaval »

wsteffe wrote: Thu Mar 23, 2023 1:10 pm You are not alone to follow such an irrational line of tought. It seems to me that it is a quite common practice in the FC developer community.
From time to time I come back here hoping that the many improvements brought by RT in his branch (removal of this rule being one of them) can be ported back to master closing the gap between the two.

But every time such kind of meaningless posts take me away any hope.
please keep things civil, insulting people is not productive. And rt branch improvements will obviously not get ported if no PR is made...

A common misconception from people is to believe that everything in realthunder's branch can just be merged into master and that this doesn't happen just because devs reject the ideas... this is not the case at all. There's much more work behind merging stuff than the common non contributing complainers realize.
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: A randomly started discussion about the necessity of the PD single solid rule

Post by wsteffe »

adrianinsaval wrote: Thu Mar 23, 2023 1:25 pm please keep things civil,
But saying "many people complaint about this low. I do not understand the reason but I still do pretend that everyone follows it" is truly irrational (and also a little bit arrogant).

Personally I have nothing against whom said that. Actually I am grateful to drmacro who helped me in a few occasions. But pointing the finger against such irrational arguments has noting to do with civil behaviour. It is very difficult to have a constructive discussion if the logic is not required.
drmacro
Veteran
Posts: 8867
Joined: Sun Mar 02, 2014 4:35 pm

Re: A randomly started discussion about the necessity of the PD single solid rule

Post by drmacro »

wsteffe wrote: Thu Mar 23, 2023 1:10 pm
drmacro wrote: Thu Mar 23, 2023 12:34 pm This and many other threads, here and in other social media, basically say is it's inconvenient and doesn't work like other CAD systems. Again for years.
In fact a lot of people is complaining about the assurdity of the one body/one solid rule.
Umm...that's what I said, that there are and have been for years. This sentence was agreeing that this is what the posts in this thread say.
drmacro wrote: Thu Mar 23, 2023 12:34 pm Is it a good reason? I don't know.
By yourself admission you do not understand why the rule is needed. But you are anyway saying that we should keep it.

You are not alone to follow such an irrational line of tought. It seems to me that it is a quite common practice in the FC developer community.
From time to time I come back here hoping that the many improvements brought by RT in his branch (removal of this rule being one of them) can be ported back to master closing the gap between the two.

But every time such kind of meaningless posts take me away any hope.
I said "while we wait" you can use other tools in FC. I did NOT say it should not be changed.

I'm out.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
wsteffe
Posts: 461
Joined: Thu Aug 21, 2014 8:17 pm

Re: A randomly started discussion about the necessity of the PD single solid rule

Post by wsteffe »

adrianinsaval wrote: Thu Mar 23, 2023 1:25 pm There's much more work behind merging stuff than the common non contributing complainers realize
Yes but that work will never start if the core developers do not understand that it may bring an improvement and refuse also to consider the possibility of a change into that direction.

TPN seems to have (finally) won all these resistances but it took a long time and we have still to see if it will succesfully land into Master.
A similar hystory happened several years ago with the marging of Link functionality.
But there are several other improvements in the RT branch which probably will never come to Master.

On the other side RT has much less difficulty with syncing of Master. Quite soon we will see a new sync with Master as it was at 25th December 2022. This merge is in preparation in a temporary dedicated branch (LinkMerge).

In my vew the RT branch is the official one (because it has all what I really need to do my work) while Master is the experimental one (where improvements are made by some developers in their WBs like abdullah is doing with Sketch). From time to time Master experiments enter into the RT branch.
User avatar
-alex-
Veteran
Posts: 1856
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: #4828 PartDesign: inverse for pocket

Post by -alex- »

adrianinsaval wrote: Thu Mar 23, 2023 1:17 pm First and obvious reason: nobody has made a PR
But there are other underlying reasons such as the unreasonable opposition that there is against this change.
And of course all of us long time users have learned to workaround this silly thing so usually other improvements get more attention.
+1
-alex- wrote: Thu Mar 23, 2023 1:06 pm like in Catia if I understand correctly what said above. It's not powerful and involves a lots of drawbacks.
No CATIA allows multiple solids in the same container without issues. I am not aware of any drawback for this.
OK, thanks. I've got something wrong. So, lets focus on FC :-)
Locked