MoveFace command with DirectionConstraint=normal works different in Rhino v5

My specific workflow takes advantage of the command MoveFace (with DirectionConstraint=normal) quite often.

As soon as I move more than one face at the same time, Rhino v5 comes up with different results than it used to be in Rhino v4.

Rhino v5 now seems to automaticly flip the vector for each solid to uniformly increase OR decrease the lenght of all involved solids (dependig on the first selected face).

e.g.: two box-solids with one face touching each other. I try to move the touching faces simultaniously in one direction without affecting angles (using the command MoveFace and DirectionConstaint=NORMAL). After running the command, the faces do not touch anymore!?

Without the DirectionConstraint the command works fine, but I need the constraint parameter.

Is that a bug or has it been changed on purpose? It's irritating at least and I preferre the previous behaviour.

Tags: MoveFace

Views: 292

▶ Reply to This

Replies to This Discussion

Permalink Reply by Jeff Hammond on February 20, 2013 at 2:38pm

[EDIT] hmm..

actually.. if i think about it some more, MoveFace should probably do what it's doing now.. which is:

...and ExtrudeSrf should have the normal constraint option.. (it actually defaults to that option.. the problem is what happens when you select multiple faces on different planes)

?

Permalink Reply by M.Haertel on February 21, 2013 at 3:24pm

I can almost agree to all the things you say!

(except: deactivated constrains require a precise normal vector selection to produce a normal move. For me that complicates things a lot).

But yes, the capabilities of the moveface command become much wider by moving faces at different angles at the same time.

Anyway -  sice different users have different needs, what would be the problem of having both options, "normal-axis" and "normal-direction"?

Permalink Reply by Jeff Hammond on February 21, 2013 at 9:42pm

"

(except: deactivated constrains require a precise normal vector selection to produce a normal move. For me that complicates things a lot)."

yeah, as it is now and as i understand your previous workflow, i can see you needing to put in more effort to arrive at the same ends.. but it doesn't necessarily complicate things 'a lot' i don't think.. (me personally, i'd just draw a line or point in there in the correct position then snap to it but maybe that sounds like the correct solution since i'm coming from a sketchup background.. which often requires this type of setup then delete geometry due to it's low powered tools.. or, depending on the shape (and your example images are of acceptable shapes for this), you could just use inferencing/snaps/tab key etc..

"Anyway -  sice different users have different needs, what would be the problem of having both options, "normal-axis" and "normal-direction"?"

me personally, i don't see a problem i guess.. but that's because i'm involved in this thread.. i'm not quite sure how much sense that would make to other users..

but when it comes to that stage.. as in something would actually be changed in a tool, i think that's when i would rely on the developer to make the right call ;).. they're the ones that have to think about it from the broader point of view and make sure it ties in somewhat consistently and fluidly with the rest of the commands.. and i don't even know all the commands yet ;)

Permalink Reply by M.Haertel on February 19, 2013 at 3:28pm

Here are some pictures to illustrate the difference between Rhino v4 and v5 when using the MoveFace command with DirectionConstraint=normal:

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

Do you think it is possible to make the command work as it used to?

But sure, the behaviour as shown on my last pic_5c might be interesting to have as an option.

Attachments:
Permalink Reply by Jeff Hammond on February 19, 2013 at 3:43pm

i can't understand why you won't just turn off the normal constraint.. nothing in your examples show that it would be a problem to do so..

(or even subselect the faces then use regular Move command?)

Permalink Reply by M.Haertel on February 19, 2013 at 4:02pm

The objects are not adjusted to the world axis!

I usually have to "stretch" a dozen angled faces at once, using the constraints makes sure that:

- I will not grab an unprecise smart snap intersection point

- and I did really snap parallell faces only

And the constraint allows to align the new face position to a snap point with offset to the actual track.

I used it a lot as a save and really quick way to avoid my angles get messed up.

Permalink Reply by Pascal Golay on February 19, 2013 at 3:49pm

Thanks, I see it is moving unselected faces, I did not understand that was the problem.  I'll see if we can get this fixed.

-Pascal

pascal@mcneel.com

Permalink Reply by Jeff Hammond on February 19, 2013 at 4:07pm

Thanks, I see it is moving unselected faces, I did not understand that was the problem.  I'll see if we can get this fixed.

i guess it's just a case of different people expecting something totally different out of a particular tool but i feel if something was to get 'fixed' regarding MoveFace constraint:normal... it should be able to do this to a polysurface when selecting more than one face:

Permalink Reply by M.Haertel on February 19, 2013 at 4:48pm

@Jeff: NO! please do not get me wrong. A box should stay a box!!

Permalink Reply by M.Haertel on February 19, 2013 at 4:41pm

I think Jeff is exactly right - it is all about the fact, that Rhino suddenly takes care of the DIRECTION of the face's normal (POSITIVE OR NEGATIVE). Previously it just kept the normal-AXIS of selected faces. But it was the global direction of the custom-selected vector only that decided which side the face was moved to. Now it is related to the preset direction arrow of each selected face.

What I say is: It is not always practical to care about the direction of the face. For me it is much more intuitive and useful to select a bunch of faces and just tell them where to go BUT STILL KEEP THE DIRECTION CONSTRAINT TO THE NORMAL-AXIS.

e.g. I often have to move perpendicular gaps without loosing the preset width of it. Same time I can not trust the objects to be aligned to world axis. Now this takes me one or two steps more to reach the goal.

In V4 it was just perfect and I wonder why it had to change.

(The unselected faces are just an additional point that came up in the testing)

RSS

Translate

© 2013   Created by McNeel Admin.

Badges  |  Report an Issue  |  Terms of Service