Moving objects into and out of assembly container causes unintentional displacement

[ceremcem]

I'm trying to create a Binder for a shape.

• I'm clicking the shape,
• clicking the "PartDesign/Sub-Shape Binder"
• this generates the `Binder
• I move the binder 1 level out of its current hierarchy
• Placement of Binder changes unintentionally

Model: test2.zip

[ceremcem]

This is not specific to the binder, it can also be observed on normal objects dragged out of container:

[realthunder]

This is expected. The final position of an object in 3D view is determined by the accumulated placement of the object and all its containers. When you drag and drop the object, its parent changes, hence its 3D view position changes as well.

[ceremcem]

Objection: While it's completely required by design to calculate objects' positions relatively, "dragging and dropping an object into another container" would never be performed with the intention of position change, the "drag and drop" event must never change the objects position.

Proposal

When an object is dropped into or out of a container, its own placement should be recalculated regarding the container it's dragged into or out of and then overwritten. This will still satisfy the relative calculation requirement and also let us group some objects with a new Assembly container in the middle of the design process, change their position by moving the new Assembly container and then take them out of the container without breaking any previous valuable placement adjustments.

[easyw]

Proposal
When an object is dropped into or out of a container, its own placement should be recalculated regarding the container it's dragged into or out of and then overwritten. This will still satisfy the relative calculation requirement and also let us group some objects with a new Assembly container in the middle of the design process, change their position by moving the new Assembly container and then take them out of the container without breaking any previous valuable placement adjustments.

This should be an option IMO. In many cases it is useful to drag an object inside a container and let the object get the placement multiplied by the container. So if this behavior is going to change, it would be nice to have an option to keep the old one when dragging in/out objects.

[realthunder]

This staionary drag and drop does seem useful in many use cases. But yes, it may also break some other existing mechanism (although I couldn't think of one immediately). I think I'll add a FC parameter to enable this behavior.

[realthunder]

@ceremcem I have just added this feature in my LinkStage3 branch. Since you are very active in testing my branch, it is better for you to use your own build to test the latest feature and fix. To activate the feature, right click anywhere in the tree, select Tree options->Sync placement.

[ceremcem]

I was about to say that I'm able to build LinkStage3 from source for a while with a virtual machine, so, anyway, here we are:

It seems a permanent setting, which is great.

[ceremcem]

This feature works, thank you!

[ceremcem]

Version

OS: Debian GNU/Linux 9.5 (stretch)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.14961 (Git)
Build type: Unknown
Branch: LinkStage3
Hash: 0f69c9bfb3a9959e284565576cc5780eafe6fcea
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)

File

test2.zip

Description

Starting over, here I have two components and I will cut the panel according to sockets:

Prepare the socket cuts

(Fail) I'm creating a solid which describes the windows to be cut:

(Success) It seems it's not supported explicitly, so I need to go to parent object and create the shape:

(Fail) Cut the panel by directly using front-panel-cuts

(Fail) Exception arises here:

<type 'exceptions.AttributeError'>: 'App.Document' object has no attribute 'Extrude'

(Success) Separate the front-panel-cuts and try again:

(ISSUE) It seems there is something still "shifts":

Cutting is succeeded, but result seems shifted.

Bonus finding: Broken Visibility Toggling*

Since something seems shifted, I give up and

1. delete the front-panel-cuts link and the Cut itself.
2. See the visibility toggling functionality for the panel is broken:

Workaround for broken visibility toggle

Move panel out of assembly, then back to the assembly container which seems to fix the visibility toggling issue:

(Success) Cut panel by using sub-shape binder

1. Re-link the front-panel-cuts
2. Create a sub-shape binder for front-panel-cuts
3. Cut panel with Binder
4. An exception is thrown as Cannot compute Inventor representation for the shape of Cut.
5. Delet the Cut, Binder etc and re-do the same.
6. See Cut is created as expected. (tip: move panel in order to move the Cut ATM)
   

(Success) Cut the panel by directly using front-panel-cuts

If we move the front-panel-cut out of its Assembly Container, it also works just like Binder:

Conclusion

1. There is a visibility toggling issue
2. Why do we need the Binder at the moment? (can "Cut the panel by using front-panel-cuts" section be fixed?)
3. The front-panel-cut should reside in project file because it's not related with RaspberryPi itself, it would change from project to project (we might want to prevent exposing 2 usb ports in a model), so how do we create that front-panel-cut sketch in the project?
4. Something still shifts? ("Separate the front-panel-cuts and try again" part)

[realthunder]

There is a visibility toggling issue

I am aware of this issue. There is a potential fix but involves quite significant core changes. I put it to low priority. For an explanation of the cause of the problem, see here. In short, you are in fact seeing the same object appear in more than one coordinate space, and this time they located at the exact same spot. To hide the object in the global coordinate space, select it in the 3D view, and press space. You need to select it twice, to hide both it in both coordinate space.

Why do we need the Binder at the moment? (can "Cut the panel by using front-panel-cuts" section be fixed?)

Part/PartDesign feature only works when all its tool and base features are inside the same coordinate space. Binder is a way to bring in objects from another coordinate space. In my tutorial, the cut shape, and the USB socket are contained in a sub-assembly, which has its own coordinate space. The binder binds the cut shape, and bring it to the parent assembly at the same location in 3D view. Without the binder, if you directly create a Cut using objects from two different coordinate system, it will be out of place, similar to when you drag an object across different assembly container. My new added feature recalculate the drag object's coordinate and changed its placement so that it appears stationary, binder does the same thing.

The front-panel-cut should reside in project file because it's not related with RaspberryPi itself

In my tutorial, the cut shape stays with the socket model. The socket and cut shape sub-assembly is then assembled with the PCB in a higher assembly.

Something still shifts? ("Separate the front-panel-cuts and try again" part)

This is not a regular drag and drop. It does not move any object, but creates a link inside the assembly. I'll see if I can do the same trick on this case. On the other hand, since you are using assembly workbench, you shouldn't rely too much on the manual placement, but use constraint to configure the parts. With the blueprint you showed in the other post, I would create a master sketch to define each components place exactly as shown in the blueprint, and then place each component by as simple PlaneConicident.