Draw two boxes, one on top of the other like this
Activate MoveFace command and select the top of the bottom cube and the bottom of the top cube (so you have 2 surfaces which overlap selected)
Try moving both those faces down from one point to a lower point like this:
This is the result I get:
This is the result I expect:
Running 6.11.18348.17061, 12/14/2018
(I don’t dare updating yet with all the bugs related to 6.13 that I’ve been seeing on the forums.)
You need to change the DirectionConstraint=Normal command line setting to None…
(I agree it’s confusing)
I usually do this type of stuff with sub-object selection and Gumball.
Wait, so this is expected behavior? Not sure I understand when this would be useful.
Well, let’s put it this way - ‘not completely unexpected’… I would say it’s buggy though, and I think similar situations have been reported before, perhaps with a Gumball move.
As the two boxes are closed polysurfaces, the normals point outward on both objects - thus the two coincident faces have opposite facing normals. When you move both, Rhino gets confused - I think it probably takes the first face in the list and looks at the direction of the move relative to the normal - that could be positive or negative. Then it applies the same displacement to the other one (instead of inverting it), so it then goes in the wrong direction.
Looks like the Gumball handles this type of situation correctly, so I assume MoveFace should be “fixed” to do the same. @rajaa?
Hmm well it’s an option I’ve never looked at so maybe there are cases where it is useful which I just never considered. Perhaps it would just be better if None was the default instead of Normal?
Ok, so I played a bit around with it and now I understand more what it does. When I select faces on different objects in different directions like this.
Then I end up with this.
I can see it could be useful, but I cannot think of any real life examples where I would use this for now. I’d still put “None” as default though. Anyway, learned something new then.
