[Problem] PartDesign single solid restriction is counterproductive

[adrianinsaval]

Is there an existing issue for this?

• I have searched the existing issues

Version

0.21 (Development)

Full version info

not relevant

Subproject(s) affected?

PartDesign

Problem description

Over the course of years since PartDesign "Next" and it's body paradigm was introduced we have observed multiple times situations where obtaining multiple solids from the same feature history would have been beneficial, many discussions on the matter can be found on the forum.
Users constantly face problems when they need to switch to a different workbench just to continue their work due to this limitation. Sometimes ending up with broken files due to mixing workbenches. In the best of cases they have to resort to workarounds adding material just for the sake of temporarily pleasing this limitation. This limitation gives unnecessary friction to the users for no tangible benefit.

Meanwhile realthunder has lifted this restriction on his branch with great success and user satisfaction.

Anything else?

One of the most recent in depth discussions on the subject: https://forum.freecad.org/viewtopic.php?t=77004

And an extract from this topic with my rebuttals to some arguments presented in opposition to lifting this rule (evidently highly opinionated):

this are the only three arguments (simplified to their core) I have heard an my rebutals:

1 - the definition of the word body is of a single solid (this the most common and annoying argument)
-- there is no reason why we should limit a computer's capability due to limits of the english language, we can very well use a different word if this is so important.
2 - there is some usecases where having a single solid rule could be beneficial
-- ok so you may ask for a feature to force single solids by user/organization choice or a warning or we may have automatic splitting as was shown in a solidworks video in this thread, it does not follow from this argument that all other use cases where multiple solids can be beneficial should be forbidden. What makes these usecases so much more valuable than the others that they can force the others out and cannot coexist?
3 - multiple solids are fragile to toponaming problem (this I only recall seeing once, is it even true?)
-- so what? so is attaching to faces or making fillets and we still allow them. I can make 100% toponaming safe models whether it has one solid or 100 solids, why does the software need to say "sorry, you are not allowed to do this because you might be too dumb to manage it". This should be my decision not the software's. Besides, toponaming algorithm is underway which makes this a non argument.

To properly justify a single solid rule one must justify why all the examples given where multiple solid can be useful must be forbidden, I sincerely cannot see how this is justifiable.

Code of Conduct

• I agree to follow this project's Code of Conduct

[adrianinsaval]

removing this limitation will be an objective for the next development cycle

[ghost]

I second that, especially when the TNP is solved.

[chrisb-github]

1. Sad to see that you got me (chrisb in the forum) utterly wrong. Even more sad to have the feeling that this is on purpose just to present the counterargument as something near to ridiculous.
   I would like to clarify that it is not about the word but rather about the notion i.e. about the very clear idea of a single solid body, which I would rate as something rather different from multiple solids. This is of course supported by the proper words. It's easy to explain, easy to understand, easy to handle.
   Beyond that, I'm not at all against a feature driven workflow for multiple solids. Perhaps it needs a bigger picture of PartDesign future where also other non solids such as faces are allowed.

[adrianinsaval]

Even more sad to have the feeling that this is on purpose just to present the counterargument as something near to ridiculous.

Apologies, I probably was growing frustrated at the moment of the original writing. However I do not intend to ridicule this argument, I just mean to say that this argument only really implies that we can't keep the name as it is not a valid reason to not have multiple solids. Also this is the only of the counterarguments that I found actually needs action when we move to multiple solids. As such I created a separate issue to discuss the body concept and how we need to change it: #9748

Perhaps it needs a bigger picture of PartDesign future where also other non solids such as faces are allowed.

This is also part of what I'm trying to say on the above mentioned issue.

[chrisb-github]

Adrian: Thanks for the clarification!
Luzpaz: I don't think this is a UI/UX thing. It is about a concept. Which finally will of course spread up to the user interface as do almost all other changes too. The UI/UX label may persist, but should be accompagnied by more, e.g. by "feature". Otherwise it may be mistaken as solely UI/UX issue.

[wsteffe]

Perhaps it needs a bigger picture of PartDesign future where also other non solids such as faces are allowed.

It would be sufficient to port what has been done in RT PartDesign. No need to reinvent the wheel.
I am regularly using LinkDaily PartDesign to define not only multiple solids but also multiple faces in a single Body. In my application these faces may be used, in example, to define boundary conditions of my electromagnetic solver.
Very often I am using surface objects also to define the planar metalizations of a PCB, even if in the physical implementation they must have a very thin but finite thickness. This is done to avoid very small edges in the 3D mesh (which would lead to very high computational times). This is just to say that surface objects, even if not existing in nature, may still play an important role in CAD models aimed to physical simulations.
And to me it is very important that RT PartDesign WB allows the definitions of hybrid models composed of solid and surface geometries arbitrarely grouped in different containers. Currently these containers are the Bodies (which may be a misleading term).

[wwmayer]

https://forum.freecad.org/viewtopic.php?p=687919#p687919

[yorikvanhavre]

A maybe silly idea, but: What if the limitation was removed, but there was a big checkbox well visible somewhere on the PartDesign WB "enforce single-solid" (that could even be on by default)? So we would consider single-solid not as a technical thing, but rather a modelling paradigm, that users could adopt or not

[FlachyJoe]

a big checkbox well visible somewhere on the PartDesign WB "enforce single-solid"

I agree!
Other thoughts:

• What about a SingleSolid Body object and a MultiSolid one with the ability to switch between the two (with a checking for multi to single)?
• What about to allow to use App::Part as PartDesign multi-solid container (acting as a multi-solid Body for PartDesign feature children and, in the same time, as group for other objects) and keep Body single-solid?

[wsteffe]

a big checkbox on the PartDesign WB "enforce single-solid"

I do not think it is necessary. If you do not want to have more than one solid inside a body just don' t make them.

[kadet1090]

If you do not want to have more than one solid inside a body just don' t make them.

Poeple make mistakes - If someone does not want to create multiple solids by accident (which can happen!) we can provide way of preventing that if we consider this as paradigm.

[wwmayer]

In his branch RT has a setting to check or ignore for multiple solids after each operation. IMO that's the easiest way to handle both cases.

[FEA-eng]

In his branch RT has a setting to check or ignore for multiple solids after each operation. IMO that's the easiest way to handle both cases.

That would be the best option - allow for multiple solids by default but let users turn this check back on if they want it for some reason (personally, I hate this limitation - it's pointless and confusing, in my opinion).

[FEA-eng]

removing this limitation will be an objective for the next development cycle

Is it still on the radar for 0.22/1.0 or rather for the next release after the upcoming one?

[kadet1090]

As it is very close to feature freeze and this seems to be quite important one. It's obvious that we won't be able to finish that in time.

My proposal is to add "Experimental" checkbox to disable the body count checks and essentially allow multi-solid bodies. I roughly checked if that will work and I did not found any major problems - that said there are probably some hence the experimental opt-in behavior.

This should be quite small PR, maybe 100 lines without UI. This would allow more people to test it and report bugs in stable release that we could later properly address in the next stable as well as to provide a better multi-solid workflows.

What do you think? I will provide PR on Friday if there will be no major opposition.

[FEA-eng]

What do you think? I will provide PR on Friday if there will be no major opposition.

Very good idea, I 100% agree.