but is it a good reason? I don't think so, a good reason has not been brought up yet...
read the thread... plenty said about this already
but is it a good reason? I don't think so, a good reason has not been brought up yet...
read the thread... plenty said about this already
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)adrianinsaval wrote: ↑Thu Mar 23, 2023 12:06 pmbut is it a good reason? I don't think so, a good reason has not been brought up yet...
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.
+1, well said.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.
In fact a lot of people is complaining about the assurdity of the one body/one solid rule.
By yourself admission you do not understand why the rule is needed. But you are anyway saying that we should keep it.
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.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)
First and obvious reason: nobody has made a PRIt 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 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.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.
No CATIA allows multiple solids in the same container without issues. I am not aware of any drawback for this.
please keep things civil, insulting people is not productive. And rt branch improvements will obviously not get ported if no PR is made...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.
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).
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.
I said "while we wait" you can use other tools in FC. I did NOT say it should not be changed.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.
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.adrianinsaval wrote: ↑Thu Mar 23, 2023 1:25 pm There's much more work behind merging stuff than the common non contributing complainers realize
+1adrianinsaval 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.
OK, thanks. I've got something wrong. So, lets focus on FC