When to choose Part Design WB or Part WB?

[chrisb]

I haven't detected something I could do with PartDesign whereas I can't do with Part.

That's right - and understandable, as I read here multiple times that PartDesign is built on top of Part. The opposite does not hold.

[triplus]

In general you would choose Part workbench, when you want to create some solids, use Boolean operations in between them, attach some sketches and being able to externally link to everything from Sketch, hierarchy in between added features mostly being horizontal. If you want to work with a geometry, such as point, line, face, there is Part Shapebuilder, hopefully in the future there will be a parametric counterpart. In addition there are some good commands in Part workbench, like Part Defeaturing.

In general you would choose Part Design workbench, when you want to create a single solid and the steps needed to create it involve adding a plethora of (interconnected) features. Added features can have more vertical hierarchy, but that is not a requirement, as you can use datum features as a common reference.

In the end you can achieve most of the tasks in both workbenches, and can use both in an unconventional way. Therefore people usually just choose the workflow they prefer and the workbench it provides it, for being able to complete some specific task. Lets say you are in a room full of cartoon boxes. You want to just take some boxes and to manually arrange them to represent some structure, maybe to take scissors and cut a part of one box away. Or you would like to take a pencil and draw some lines in between them. For that best to start in Part workbench. Lets say you want to create a cartoon box. For that best to start in the Part Design workbench.

Can't we just merge them in the future? For sure it could be done, but the merged workbench needs to support both workflows, horizontal and vertical one, should be able to handle workflow including geometry such as points, lines, faces and solids. Based on the past discussions and evolutionary steps it is not likely this will happen anytime soon. What likely will happen is gradually the difference in between this two workbenches will get blurred again a bit. As over time both will likely adapt to paradigms people would like to adapt to.

[vocx]

... At this stage I haven't detected something I could do with PartDesign whereas I can't do with Part.
...

Well, of course, given that Part is the origin of all workbenches. All workbenches internally use the classes and functions implemented in Part. If you want to think about it, PartDesign Workbench is a prettier interface over Part.

And yes, PartDesign has primitives, like PartDesign AdditiveBox and the like.

[fcaduser]

@vocx

This is absolutely not a priority (an "official" assembly module is, for example) ; but I think the persistence of two WB having very similar goals might be a little detrimental, in the long haul. I don't know if both can be, or should be, sort of merged. Or one purely remove. I don't know, really.

[vocx]

... Or one purely remove...

Are you going to remove the pretty one? PartDesign Workbench?

Or are you going to remove the old one? Part Workbench, which you yourself use?

I think you can keep both. What we need is proper user documentation teaching you to use the right one to start.

I think the best solution is to merge the Part workbench inside the PartDesign workbench. Basically, placing its buttons inside a new toolbar. The functions of Part, however, would still be used under the hood for both sets of tools.

[RatonLaveur]

I actually also fully agree that despite the true "code" hierarchy, it seems that Part functions would be a good subset of PartDesign. Hereafter my own reasoning.

The industrial way of modelling is now based on a PartDesign workflow. That is a fact.
PartDesign already incorporates some primitives (not all) and some boolean operations (not all).

If all primitives and all booleans are accessible through PartDesign. Then only one workbench exists to produce 3D geometry with complete freedom about the workflow.

I would add that standardizing bodies for all these operations (Part and PartDesign) would clarify the whole shebang.

So i would be for merging Part into PartDesign.

[chrisb]

If all primitives and all booleans are accessible through PartDesign. Then only one workbench exists to produce 3D geometry with complete freedom about the workflow.

There is more than this: Faces, Slicing, multi-solid operations, advanced options for fillets, chamfers, extrude, operations such as mirror working on the whole body. And probably more to add.

[brjhaverkamp]

... Or one purely remove...

Are you going to remove the pretty one? PartDesign Workbench?

Or are you going to remove the old one? Part Workbench, which you yourself use?

I think you can keep both. What we need is proper user documentation teaching you to use the right one to start.

I think the best solution is to merge the Part workbench inside the PartDesign workbench. Basically, placing its buttons inside a new toolbar. The functions of Part, however, would still be used under the hood for both sets of tools.

Hi all,
Reading through this thread, I think the whole discussion in itself is already a "proof" that having two WBs with overlapping functions is a user-interface error. It confuses users and creates an sub-par eperience. Combining the two into one rule-them-all WB should be the (mid/long term) solution. As the underlying dataframework is now matured enough, would it be time to look into a roadmap?

Bert

[microelly2]

IMO we can use both workbenches depending on the situation.
Often I see that the pupils use Part because it's more robust and intuitive and they get fast results.
Starting with a given part (imported step file) both WB can be used to do modifications.
We still are far from direct modeling. I think this should be a long term goal. Models where I change one parameter and the connected faces are updated the parametric way.

[vocx]

... would it be time to look into a roadmap?

Can you program, and can you do it yourself? Then it makes sense to have this roadmap. Because otherwise, it's just wishes by users. Opinions and wishes by the users are good to have of course, however, what we really need is more C++ programmers who are willing to do the dirty work of looking after the code. This is easier said than done.