intuitions on tree of pads and pockets

[sjoerd]

I've been using freecad for a while now. I think it is great but there is something I don't get. When you pad a sketch the Pad object includes the original shape; that's logical since you'd want the original surface to be removed in the places where the padding touches the support surface.

But what I don't get is that the original object is a sibling of the new Pad object in the object tree; I would really expect it to be a child just like the sketch that was padded...

This may be a deliberate design choice but in that case the behaviour needs some explaining in the documentation because I cannot think of a reason why it is this way (or why anyone would want it this way)...

Can anyone explain this behaviour to me?

[bejant]

Greetings sjoerd,

Can anyone explain this behaviour to me?

If you're in FreeCAD try using Tools > Dependency Graph. You must install GraphViz first from http://www.graphviz.org. Then maybe the dependencies become more apparent:



The dependency graph is from this post, which includes a .FCStd file if you'd like to have a look.

[NormandC]

sjoerd,

When I closed your issue #1729 I specifically linked to the Open discussion forum so you would post your comments there, not in Developers corner.

Accordingly I moved this topic to the appropriate forum.

But what I don't get is that the original object is a sibling of the new Pad object in the object tree; I would really expect it to be a child just like the sketch that was padded...

The thing is, when mapping a sketch to an existing solid and applying a PartDesign operation on it, it does not produce a new object, but it actually changes the state of the original object. The original object being the first PartDesign operation that produces a solid.

This is why we call PartDesign operations "features" to distinguish them from operations from other workbenches, which usually produce new objects.

In the PartDesign context, the tree is displayed in a linear fashion, and this is also by design. In the future, all features for a specific part will be grouped under a "Body" container.

You are right that this needs to be better explained in the documentation, but there are very few people contributing to it, and among them not many who have a good understanding of the PartDesign workbench. Contributors are often "specialized", knowing more about a workbench than an other.

[sjoerd]

When I closed your issue #1729 I specifically linked to the Open discussion forum so you would post your comments there, not in Developers corner.

Sorry about that.

The thing is, when mapping a sketch to an existing solid and applying a PartDesign operation on it, it does not produce a new object, but it actually changes the state of the original object. The original object being the first PartDesign operation that produces a solid.

This is why we call PartDesign operations "features" to distinguish them from operations from other workbenches, which usually produce new objects.

I'm a bit puzzled right now by operations, objects and features but I think I get it.

If I make a square with 2 pads on it there is actually only one object with 2 features? I can "toggle" the features visibility, but at first I was puzzled why the feature contains a copy of the original shape. Then I realised that this is necessary to produce a mesh in the end.

If the original object is merely the first operation in the sequence, then why is it not a child of the resulting object?

In the PartDesign context, the tree is displayed in a linear fashion, and this is also by design. In the future, all features for a specific part will be grouped under a "Body" container.

That sounds interesting!
Could you elaborate on that? Can I preview this in some dev version?
I am a bit worried about pockets/pads on pockets/pads on pockets/pads etc... That is often what I do because most of my features are directed in different angles...

If there is anything I can do to contribute please let me know...

[bejant]

If I make a square with 2 pads on it there is actually only one object with 2 features?

That depends on how you build your model. Right now it is possible to create a Cube, select a face, click "Create Sketch", make a Sketch of say a circle and a square, and Pad that Sketch. So now you have two Pads, but only one Feature named "Pad".

20140922a.png (4.61 KiB) Viewed 2222 times

IIRC this was an inadvertent result of code that was added to FreeCAD, and eventually FreeCAD will be changed back to only allow one enclosed shape per Sketch. The file is attached if you'd like to have a look.

Of course, another way to make the same model would be to have one Sketch for the square, Pad it, and make another Sketch for the circle, and Pad the circle. So now you have one object with 2 Features (both of them Pads, assuming to make the cube you chose the Create a Cube tool instead of Padding a Sketch.)

In the PartDesign context, the tree is displayed in a linear fashion, and this is also by design. In the future, all features for a specific part will be grouped under a "Body" container.

That sounds interesting!
Could you elaborate on that? Can I preview this in some dev version?

You can follow the progress here and here. You'll have to compile that branch yourself, and it is still in development.

If there is anything I can do to contribute please let me know...

I'm sure nobody here will turn down an offer to help. Just post how would you like to help, and someone (more knowledgeable than me) will point you in the right direction...

[NormandC]

So now you have two Pads, but only one Feature named "Pad".

This is incorrect. There is still only a single pad feature, no matter how many closed profiles were included in the sketch. The pad does not refer to the produced result(s), but rather to the operation itself.

IIRC this was an inadvertent result of code that was added to FreeCAD, and eventually FreeCAD will be changed back to only allow one enclosed shape per Sketch.

This is not entirely true.

Using your own example, since the sketch is mapped on an existing solid, it can contain any number of closed profiles, provided they are enclosed in, or at least intersect the supporting face ; or, if they're totally out of the support face, the pad or pocket feature created with it intersect the supporting solid. The closed profiles also can be enclosed in one another, but they should not intersect one another.

What should not be allowed, but actually is because of a side effect of some added code, is a base feature constructed from a sketch containing multiple closed profiles independent from each other. This would result in a part made of separate solids, and that is something that the PartDesign workbench does not/should not support.

Let's say we detach your Sketch from the face of the cube, and map it to the XY plane (for this, go to Part Design --> Reorient sketch). This detaches the sketch from the cube, and the Pad becomes a base feature, that is it creates a whole new part.

But there's a problem:

FC_Pad_multibody_01.png (8.55 KiB) Viewed 2215 times

This is what is commonly called a multibody part, and this is what should not be allowed by the PartDesign workbench. If you select the top face of either the box or the cylinder, create a new sketch, then pad or pocket it, you will see one of the solids disappear, because the "rules" operate as they should here. Typically, the first enclosed profile that was drawn in the sketch will be kept, and any other will be discarded.

I reported this discrepancy in issue #1724.

[NormandC]

In the PartDesign context, the tree is displayed in a linear fashion, and this is also by design. In the future, all features for a specific part will be grouped under a "Body" container.

That sounds interesting!
Could you elaborate on that? Can I preview this in some dev version?

Here's a screenshot taken from a tutorial based on the development branch which features this "Body" container. We removed the link to this tutorial from the tutorials page, because it was causing confusion to people who expected this to work with the regular version of FreeCAD. The page is still accessible though, the image below links to the image page on the wiki, and at the bottom of the page there's a link to the tutorial.


In the tree, you can see at the top that there are standard planes, then a "Body" object under which are reference planes added by the user (the yellow planes in the 3D view), then all the features of the part are listed under it at the same level.

Now I'm sorry to say I never managed to test this development branch myself , so I cannot tell you for certain if a part will be able to contain multiple bodies ("Body" containers); it may well be possible.

And we could also surmise that with a "Body" containing all features under it, reordering features in the tree may become possible.

In any case, when this is finally merged into the main branch of the source code, even us "FreeCAD old timers" will have to adapt to a new workflow!

You can follow the progress here and here. You'll have to compile that branch yourself, and it is still in development.

Just a word of caution, the Assembly workbench in that development branch is currently not functional. But the new tools in the PartDesign workbench should work.

If you are using Windows, compiling may prove a challenge. It's much easier on Linux, more specifically Ubuntu and its variants.

[sjoerd]

Wow, that's an unexpected new design

It looks like that will improve workflow in the future.
I'm on (arch)linux and already compiling from source so that shouldn't be a problem.

Now, I'd like to get back to the point I was making.
As I understand it now, the tree on the left is to be interpreted as a history rather than a dependency tree?

I think it would be more intuitive to have the dependency graph there.
That would imply forbidding to "fork", but that is exactly one of things that I unintentionally do sometimes: I inspect a previous pad and then accidentally create a feature on a surface of that object rather than the final object. This is something I don't think you want to allow anyway.