Which issues will start to arrive with the splitting of complexity?

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!
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by adrianinsaval »

grd wrote: Wed Aug 17, 2022 5:48 am This is what I mean with a "hook". But this simple exercise also shows that PD already allows only ONE body, where the Part WB allows many.
This is one of those terrible decisions where an arbitrary artificial restriction is placed for some weird philosophy for no benefit.
You keep on talking mandatory, where I keep on talking optional.
I'm actually trying to highlight the fact that you are talking about optional so that others may stop talking as if this was going to be mandatory.
And also things such as assigning a material, to which body do you assign it? And what is the weight of that body? And things such as labels, it's the same thing. In Pro/E I could do assign a material and then I could measure the weight and even the COG (all within one program), I didn't need an external WB to do this.
This is completely unrelated to the subject, the functionality is not implemented in FreeCAD, adding restrictions to files does not change this. If you want this then what you need is to implement the functionality in FreeCAD. If you have trouble figuring out to what you should assign which materials you probably should review your modelling workflow. I don't get what you mean with labels.
Tell me, what is the difference with opening an assy and a multi-object part?
single file won't ever break due to a renamed/moved/missing file, also at creation it is a lot more convenient and easy to make a single file rather than creating each separately then creating a new one for the only purpose of putting them all together (this absurd limitation frustrated me a lot when I used solidworks after a long time with FreeCAD). For small or simple projects having separate files and dedicated assembly file is overkill, for products designed in a corporate environment separating is the best choice, FreeCAD allows both.
obelisk79 wrote:flexibility vs protecting a designer from themselves. I prefer flexibility.
agreed

Anyways, this discussion is going nowhere, you're never going to convince us that this is a must because it isn't for us and I see no point in convincing you don't need this. Like I said, it is clear there isn't a general interest in implementing this so it is up to the few that are interested, if you desire I recommend looking into how to implement this then create a topic dedicated exclusively to technical question about how to implement, not modelling philosophy. This might have been your intent, but the OP was too broad, without details of how you intend to implement such an option it is not possible to foresee the problems that will arise without doing research, and we're not going to do research on a subject we have no interest in, so initial research is once again up to the people interested. You can of course ask for help and/or guidance on technical stuff once you have started looking into it.
grd wrote: Sun Aug 14, 2022 8:00 am This should all be possible with a button somewhere in the preferences tab.
This is statement for example is very vague, what is going to be on the preference tab? An option to disallow saving as FCStd files? What if someone sends a FCStd file then? The two workflows have to coexist or we would have to go and change that setting very often. So the decision to use one or another workflow has to be made when creating or saving the file, at most you can make a setting for some default preferred behavior, but without details about how this works it's hard to think of what preferences would be meaningful.
No. Do you wanna know why? I think that I can do the part thing (as long as it is Python), but assemblies are a lot harder because of external WB and drafting is also a region that I don't know exactly.
Then you have a problem already, Zolko is the main dev for asm4 and has already expressed to be against this, I doubt you'll change his mind because your arguments are honestly not very strong and he's also kinda stubborn from what I've seen. Once again the change has to come from the people interested in it, if you implement an optional filetype in FreeCAD and make a PR to support this as an option in the WB it'll probably get accepted.

If there's nobody with the desire of implementing this then further discussion is pointless IMO.
grd
Posts: 328
Joined: Wed Apr 13, 2022 5:13 am
Location: Eindhoven, The Netherlands

Re: Which issues will start to arrive with the splitting of complexity?

Post by grd »

Well, if you don't want to do it, it's up to you guys. I tried and I failed so I wish you the best of luck. I think the only way to solve this issue is to fork. I really hate the current situation, everyone who has ever examined Document.xml knows that there is a lot of nonsense into it, which gets worse with every new feature. Especially assemblies.

So I stand down from this subject. I said what I need to say and unfortunately no one picked that up.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Which issues will start to arrive with the splitting of complexity?

Post by GeneFC »

adrianinsaval wrote: Wed Aug 17, 2022 2:12 pm This is one of those terrible decisions where an arbitrary artificial restriction is placed for some weird philosophy for no benefit.
Actually, at the time this was first introduced it might have made sense. The expectation was that PD would evolve to include a built-in assembly function. That never happened, so the restriction may no longer have any value.

Gene
user1234
Veteran
Posts: 3336
Joined: Mon Jul 11, 2016 5:08 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by user1234 »

adrianinsaval wrote: Wed Aug 17, 2022 2:12 pm This is one of those terrible decisions where an arbitrary artificial restriction is placed for some weird philosophy for no benefit.
Also as far i remember, this was while conception PartDesignNext. Can not find the thread anymore. Why: when Multibody, then you also have take care this on TNP. And it seems that the number of the solids switched often and PartDesignNext was barely to use.

@realthunder: one question, does your TNP solution also take care of the number of solid on multisolids? I thinks so, since your branch allows multsolids.


Greetings
user1234
drmacro
Veteran
Posts: 8865
Joined: Sun Mar 02, 2014 4:35 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by drmacro »

GeneFC wrote: Thu Aug 18, 2022 3:13 pm
adrianinsaval wrote: Wed Aug 17, 2022 2:12 pm This is one of those terrible decisions where an arbitrary artificial restriction is placed for some weird philosophy for no benefit.
Actually, at the time this was first introduced it might have made sense. The expectation was that PD would evolve to include a built-in assembly function. That never happened, so the restriction may no longer have any value.

Gene
I have never seen this a much of a hindrance.

From a code standpoint I guess this it is arbitrary and/or artificial. But, it does sort mirror the real world in some contexts. When I put a lump of material on the table of my mill (i.e. the first additive feature of a Body), I can put an end mill in the quill and remove material, only within the confines of the lump. Moving the table past the material (the end of the table travel) the end mill has no effect.

The argument, "well, a later operation will connect them" doesn't work in the mill context. It clearly, works for FDM sort of tools. And, I guess the people who have the most heartache about the single solid Body restriction, see it in their context.

Once again, if all you have is a hammer, everything looks like a nail. ;)
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by adrianinsaval »

GeneFC wrote: Thu Aug 18, 2022 3:13 pm Actually, at the time this was first introduced it might have made sense. The expectation was that PD would evolve to include a built-in assembly function. That never happened, so the restriction may no longer have any value.
I wasn't around back then but from what I've seen I think the idea was to make a separate assembly module (it was recently removed from master because it was dead), but assembly or not, the restriction helps nobody.
user1234 wrote: Thu Aug 18, 2022 3:20 pm Also as far i remember, this was while conception PartDesignNext. Can not find the thread anymore. Why: when Multibody, then you also have take care this on TNP. And it seems that the number of the solids switched often and PartDesignNext was barely to use.
From the discussions I've seen justifying it (including the devs) there was no mention of TNP, only silly semantics "a real body is defined as single contiguous solid" or something like that, also TNP is present even in single solid so that is not a very good argument anyways IMO.
user1234
Veteran
Posts: 3336
Joined: Mon Jul 11, 2016 5:08 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by user1234 »

adrianinsaval wrote: Thu Aug 18, 2022 3:39 pm TNP is present even in single solid so that is not a very good argument anyways IMO.
To be honest, it think that is what prevents atm much more crying from new users, since you just increase the number of possibilities of numbers significantly, especially if you begin with a multibody (for example an array with rods, just change the value of the array and the whole tree is useless).

But i agree, when really TNP issue is solved, this limitation should fall.


Greetings
user1234
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Which issues will start to arrive with the splitting of complexity?

Post by adrianinsaval »

drmacro wrote: Thu Aug 18, 2022 3:28 pm The argument, "well, a later operation will connect them" doesn't work in the mill context. It clearly, works for FDM sort of tools. And, I guess the people who have the most heartache about the single solid Body restriction, see it in their context.
There is no real reason why you would have to model exactly the same way you manufacture, but even then, what If I'm making two pieces from the same lump of material? (related enough to warrant modelling them at once). Also, have you never heard of soldering? I know you wouldn't model that for a CNC operation, but you would for technical drawings.
We should stop with the off-topic though :?
grd wrote: Thu Aug 18, 2022 6:30 am I think the only way to solve this issue is to fork.
So you are willing to fork but not to make a PR? Interesting way of thinking :?
grd
Posts: 328
Joined: Wed Apr 13, 2022 5:13 am
Location: Eindhoven, The Netherlands

Re: Which issues will start to arrive with the splitting of complexity?

Post by grd »

adrianinsaval wrote: Thu Aug 18, 2022 3:53 pm So you are willing to fork but not to make a PR? Interesting way of thinking :?
Of course I am not going to fork, but you said this
If there's nobody with the desire of implementing this then further discussion is pointless IMO.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Which issues will start to arrive with the splitting of complexity?

Post by GeneFC »

drmacro wrote: Thu Aug 18, 2022 3:28 pm I have never seen this a much of a hindrance.
Does not bother me either. Just flapping my jaw (or fingers.) 8-)

Gene
Post Reply