Very often I need to just move gaps between solid objects keeping the precise width of the gap. Therefore the command MoveFace with DirectionConstraint=normal comes in quite handy.
Since years it worked just fine to fence select a number of parallel faces and move them for a certain distance to the desired direction. Distance and vector were set by start and end point by mouse clicks.
Constrain was determined by normal of first selected face.
It does not work anymore.
I am not 100% sure when it happened but today I noticed, that the MoveFace command behaves different in latest Version of Rhino 7 now (7.4.21078.1001, 2021-03-19). All selected faces move individually depending on DIRECTION of their normals.
And in a way it is very funny, because the same strange effect (bug?) appeard already when I changed from Rhino4 to Rhino5, almost exactly 8years ago.
In order not to repeat all the facts and arguments here again, I post the link to the previous discussion.
http://v5.rhino3d.com/forum/topics/moveface-command-with-directionconstraint-normal-works-different?id=6377196%3ATopic%3A109895&page=1#comments
In 2013 the command was finally fixed and made to work consitantly just as before “The preview still incorrectly shows two directions, but the result is that all faces move together.-Pascal pascal@mcneel.com”
I hope someone from mcneel can take care of this again and fix it the same way, Thanks
To understand that there is some sort of problem:
The command currently produces even different results when using the tool just in the same way.
When fence selecting all faces on either end of the test objekt (it actually should not be allowed to select more than parallel faces) the following happens:
left side of the bench (previous behaviour - which I like to keep)
right side of the bench (new strange behaviour - which is problematic with faces of the same object)
For analyzing the error I post the test file here:
2021-03-02_rh7_move face bug test.3dm (252.3 KB)
Since the inner faces of my gaps are parallel faces with their normals in oposite directions I surely understand why a “normal”-constraint could mean that the direction is preset by the positive normal of each face individually. But in this case the command tends to cause all sort of strange results (e.g. adjoining faces of the same cube would have to be scaled proportionally or the element needed to be transfered into a cross-like polysurface with additional faces).
In any way the simple gap-move is a really useful tool worth to carry on. Possibly other people and some scripts rely on the previous simple behaviour too.
May be for the future the wishlist asks for an additonal option within the command “IdenticalVector=yes/no”, this option activated should allow selection of parallel faces only.