Sketcher WB: moving destroys hexagon

[uwestoehr]

I tried out the new moving feature in FC 0.18 (https://www.freecadweb.org/wiki/Release ... _Workbench) and noticed a strange behavior:

- input a hexagon to a sketch via the corresponding toolbar button
- select a line of the hexagon at the right side (not the complete hexagon)
- use the new move toolbar button
- set the movement vector to the left (so that it crosses the hexagon)

result: the hexagon becomes a square. To undo this action, you will need 2 undo steps.

- after you undo the previous movement, select the line again but this time point the movement vector to the right.

result: the hexagon keeps a hexagon but it is bigger and the hexagon is rotated.

Since the size change and the rotation was not what you wanted

- undo
- give the line a vertical constraint
- select the line and use the move tool to move it to the right

result: the line and the hexagon is not moved

I cannot read in the Wiki: https://www.freecadweb.org/wiki/Sketcher_Move that the movement tool has certain limitations.
So did I found a bug or do I need to add something to the Wiki page?

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15860 (Git)
Build type: Release
Branch: master
Hash: 3b708c7f84b0425076b520e1d95627b20fd75fe0
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)

[bejant]

I tried out the new moving feature in FC 0.18 (https://www.freecadweb.org/wiki/Release ... _Workbench) and noticed a strange behavior:

- input a hexagon to a sketch via the corresponding toolbar button
- select a line of the hexagon at the right side (not the complete hexagon)
- use the new move toolbar button
- set the movement vector to the left (so that it crosses the hexagon)

result: the hexagon becomes a square.

You might have found a bug, but I'm not sure that what you are doing is the intent of the tool. Do you want to move the whole hexagon and construction circle, or just the line segment?

OS: Ubuntu 18.04.1 LTS
Word size of OS: 32-bit
Word size of FreeCAD: 32-bit
Version: 0.18.15780 (Git)
Build type: Release
Branch: master
Hash: f94e76c1116ec3b818961ff65131b3d86fa5b95e
Python version: 2.7.15rc1
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

[HarryGeier]

I can confirm that habit.

But, what happens if you change the lenth of a single line.. the whole hexagon is influenced, as it is not a single special element, but a bunch of elements linked with constraints. So, if you move one, the constraints try to follow, which in some cases ( i think if the vector points over the centre ) lets the solver create someting strange.

Conclusion: We should amend a limitation to the MOVE TOOL wiki page, saying that groups of elements will change their shape when constraints of the result are impossible or unlogical

[abdullah]

I tried out the new moving feature in FC 0.18 (https://www.freecadweb.org/wiki/Release ... _Workbench) and noticed a strange behavior:

- input a hexagon to a sketch via the corresponding toolbar button
- select a line of the hexagon at the right side (not the complete hexagon)
- use the new move toolbar button
- set the movement vector to the left (so that it crosses the hexagon)

result: the hexagon becomes a square. To undo this action, you will need 2 undo steps.

Harry beat me to it...

I had fun reproducing.

If I understand you correctly, you are telling a line of a side of a hexagon to move. This causes the side to move. But moving does not free the line from its constraints (otherwise it would a very poor tool for a sketcher). Depending on where you land the side, the solver will try to find a valid solution for the constraints, which it finds in the form of a square looking disposition of six lines (in one of the very funny possible outcomes of this solver torture).

If you want a hexagon to move, you have to select the whole hexagon. Because you move constrained geometry as a whole, the solver will be happy with the outcome without moving it further. For moving, you might choose the starting point of the movement by de-selecting and re-selecting the relevant point (so that it is the last selected point), given that the tool takes as origin for the movement the last selected point. See:

MoveHex.gif (125.68 KiB) Viewed 191 times

[chrisb]

It sounds a bit funny, because the hexagon changes its shape, but most of this is in fact consistent. It's an issue of jumping lines as described already in the wiki.

Using the hexagon does not create a geometric hexagon entity. It is rather a shortcut for a set of other elements and certain constraints. If you move one point it can happen, that all constraints are still fulfilled but the shape has changed to a square.

I see instead two other issues:

1.) If I move a single side of a hexagon towards the inside, but not further than the center, then the hexagon does not move as expected.
2.) If I select a single point and move it, I get the message "A copy requires at least one selected non-external geometric element". This could be changed to "A copy or move ...".

Edit: Abdullah has already answered.

[uwestoehr]

Depending on where you land the side, the solver will try to find a valid solution for the constraints, which it finds in the form of a square looking disposition of six lines (in one of the very funny possible outcomes of this solver torture).

I understand that the solver will find different solutions, but a user will most probably expect these constraints when moving:
* the line is moved
* it is moved along the movement vector
* no lines are deleted by the movement

These 3 things are currently not assured I mean a square means 2 lines are deleted, moreover see my screenshot, sometimes even 3 lines are deleted by the movement and sometimes there is no movement at all. Note also that undoing the movement lead to a different position and size as before, see my screenshot.

I fear that other users will get the same problems I did. Since this is a new feature maybe there can be done something to improve the situation

Here is a screenshot of what I mean:

Hexagon-movement-bugs.gif (552.83 KiB) Viewed 170 times

It sounds a bit funny, because the hexagon changes its shape, but most of this is in fact consistent. It's an issue of jumping lines as described already in the wiki.

Where in the Wiki is this?

[chrisb]

The lines are not deleted, they are still there and they fulfill all the constraints. You can try this with a different solver, Levenber-Marquardt is known to be more stable with these conditions.
Still it's not what the tool should be used for (think of a hammer for opening a bottle: it is not forbidden, it somehow works, ...), So I don't see the use case for this. If I want to move the line I take it directly and move it and that's it.

I had a quick look and couldn't find the jumping in the wiki, sorry; perhaps someone else knows where to find it. However, I have written about it in my sketcher tutorial, and there are several discussions in the forum.

[meme2704]

Hi
If I dare a metaphor, it's like an umbrella in the storm, all faces are but packed on the same side, or crushed one on the other
a polygon (3 to many faces) draw with this tool moves by its center only

[uwestoehr]

The lines are not deleted, they are still there and they fulfill all the constraints. You can try this with a different solver, Levenber-Marquardt is known to be more stable with these conditions.

I had a quick look and couldn't find the jumping in the wiki, sorry; perhaps someone else knows where to find it. However, I have written about it in my sketcher tutorial, and there are several discussions in the forum.

I did not yet fully understand. I mean all 6 lines of the hexagon have the equal constraint. So if there are still 6 lines after the movement (despite I only see 4), this means that 2 lines have the length zero and thus violated the constraint.

And what about the undo issue? A typical case is that you want to move the whole hexagon but accidentally did not select all its lines. Just after the movement you notice your mistake and press undo. But then you end up with a different shape and position than before the movement. Maybe this can be improved?

I had a quick look and couldn't find the jumping in the wiki, sorry; perhaps someone else knows where to find it. However, I have written about it in my sketcher tutorial, and there are several discussions in the forum.

Do you mean this?: https://www.freecadweb.org/wiki/Sketcher_tutorial
I cannot read there something about the movement or line jumping.
Before I opened this thread I searched the Wiki and thus think if the movement behavior is expected and cannot be changed, it should be documented in
https://www.freecadweb.org/wiki/Sketcher_Move
I'll do so as son as I fully understood what is happening during the movement.

[bejant]

I'm thinking that if a user draws a Sketcher > Hexagon, then wants to move it, that the shape should remain a hexagon. I think the same holds true for any Sketcher > Polygon. For example, when moving a rectangle I don't expect it to somehow collapse into a triangle or into a line segment, with all 4 edges exactly on top of one another.

The Sketcher > Create Polygon tool creates polygons and applies Equality Constraints to all the edges of the Polygon. Instead, maybe the included angle of adjacent edges could be used but I don't know if that would be a "better" method.

I see uwestoehr posted while I was writing this ...