Ticket #4300 - Part object moves to 0,0 when dragged into Part Design Body

[drmacro]

With an object formed with a sketches and extrudes and a boolean in Part WB.
I then change the placement of resultant object.

I then create a Body in Part Design WB and drag the previous object into the Body.

The BaseFeature moves to the origin.

Is this desired behavior?

parttopartdesign.png (56.74 KiB) Viewed 1258 times

OS: Ubuntu 19.10 (XFCE/ubuntustudio)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Python version: 3.7.5
Qt version: 5.12.4
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

[chrisb]

Is this desired behavior?

Yes. It may be worth a feature request though to
- add AttachmentOffset to BaseFeatures
- add TraceSupport as it is used for ShapeBinders.

[openBrain]

Just compound the (lone) Cut (in your example) and use the newly created Compound as BaseFeature.

[drmacro]

Just compound the (lone) Cut (in your example) and use the newly created Compound as BaseFeature.

Intuitively obvious...

NOT

[openBrain]

Actually this is (maybe not obvious), but normal when you know a bit the why.

What happens :

1. FC computes the shape of the cut
2. Then it applies the move shift corresponding to the placement

But actually, the internal shape object is still 'referenced' to the computation origin. Thus when you use it as BaseFeature, FC copies the shape only (without placement attributes of the cut) hence it's back to origin.
When you compound the cut, FC recomputes a new shape which actually is the shifted shape of the cut. This means that the cut placement shift has been 'integrated' into the compound internal shape. Hence it is included when using the compound as BaseFeature.
Notice that if you further move the compound with its placement, this won't be included in the BaseFeature (same case as with the cut).

This is a tip I often use to center ShapeStrings, then eventually further move them based on the centered shape.

[drmacro]

Actually this is (maybe not obvious), but normal when you know a bit the why.

What happens :

1. FC computes the shape of the cut
2. Then it applies the move shift corresponding to the placement

But actually, the internal shape object is still 'referenced' to the computation origin. Thus when you use it as BaseFeature, FC copies the shape only (without placement attributes of the cut) hence it's back to origin.
When you compound the cut, FC recomputes a new shape which actually is the shifted shape of the cut. This means that the cut placement shift has been 'integrated' into the compound internal shape. Hence it is included when using the compound as BaseFeature.
Notice that if you further move the compound with its placement, this won't be included in the BaseFeature (same case as with the cut).

After explanation, the behavior makes sense. But to the end user, who sees on the screen an object that is not at the origin, there's no good reason to expect including in another wrapper (the Body) would move it to origin. Unless, said user is aware that that is the defined behavior. (it may be defined in user docs somewhere, I'm just saying I haven't noted it. and, it may well be defined as SOP in the programming docs. )

In any case, as chrisb suggested, I put in a feature request. If that were to be implemented, then there would be a distinct need to document the outward behavior (what the user sees) and what effect the new feature provides.

This is a tip I often use to center ShapeStrings, then eventually further move them based on the centered shape.

And, that indeed is a good tip.

[drmacro]

This is a tip I often use to center ShapeStrings, then eventually further move them based on the centered shape.

Playing around with this.

- I created a ShapeString at an arbitrary location
- Extruded in Part WB (The extrude remains at the arbitrary location, but Placement value is 0,0,0)
- create body, drag Extrude to body

BaseFeature is at the arbitrary location. I expected, per this discussion, it'd move to global origin. Obviously I missed the point...

I thought maybe:

- create Shapestring at global origin
- extrude
- move placement
- drag to body
No error in report view, but it does not create a BaseFeature.

I tried other combinations. Geometry created in a sketch and moved, goes to global origin when dragged into a body.

But, geometry created with a shapestring does not move to origin.

What don't I know or understand?

[chrisb]

Found this old topic when looking for the tracker issue concerning Placement of BaseFeatures. I found another way of changing the BaseFeatures position:
Use "ShowAll" in the attributes and then change the Placement. By setting it in an expression to the placement of its source it always follows as if it had a TraceSupport=true property.

Now for this special question:

- create Shapestring at global origin
- extrude
- move placement
- drag to body
No error in report view, but it does not create a BaseFeature.

I tried other combinations. Geometry created in a sketch and moved, goes to global origin when dragged into a body.

But, geometry created with a shapestring does not move to origin.

If you have more than one letter, the BaseFeature would create a multiple solid body. With a single letter I had no problems using an extruded ShapeString as a BaseFeature.