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: 944

Replies to This Discussion

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!?

yeah.. that sounds right.. a solid can't have it's normals facing inward so this behavior will always happen..

fwiw, you can see the normals using the DIR command.. the white arrow will show the + direction a face will move upon MoveFace..

(fwiw pt2 -- i no longer have rhino4 as it's not available on mac anymore.. so i can't compare )

That definitely looks buggy here.  It shouldn't do that, not logical.

A workaround is to use Ctrl+Shift+select to get the faces as subobjects, and use the Gumball to move the faces (this works). Mkae sure you have Gumball options set to "Align to object"

----H

That definitely looks buggy here.  It shouldn't do that, not logical.

ha.. weird.. i see that behavior as logical (but then again, you all are probably a lot more experienced with rhino than i am)

but when i see Direction Constraint: Normal, i see it to mean that the face will lock to its normal vector (or perpendicular movement in the case of a box)

if i select multiple faces then move one in a negative direction, all of the faces should also move in a negative direction. (or make the boxes smaller in the case of the OP example).. and viceversa for positive direction..

to me, it would be illogical to have one face moving in a positive direction and one moving in a negative direction.. (maybe not the case in the box example.. but in that example, i think you should just turn off the normal constraint)

dunno, maybe a more official explanation is in order? 

or.. do the same cube example only this time, select the front face of one cube then the right face of the other.. 

it would be illogical if one cube ended up larger then the other ended up smaller (which is what the OP is expecting.. i think it's the wrong expectation)

Hi Jeff,

thanks for your different view on it.

I think I understand what you want to tell me, but even if it might be logical in terms of mathmatical relations it is not serving my everydays needs anymore!

But I also agree that the new behaviour might be a useful option of the command (especially when selecting non parallel faces) - ok fine, then McNeel might add it for those who need it -  I still miss the previous way.

By the way it is still NOT logical: Under the specific condition that I select two faces of the same box and move it - voila the move towards the same side and NOT TOWARDS THE DIRECTION OF THE NORMAL-ARROWS:

1) If you select oposite faces (they are parallel) it works "my way". Why is it different for similar faces on different objects?

and

2) If you select non paralle facesl (with DirectionConstraint=normal in Rhino v4 the command would fail - logically), then the second face is moving sideways - What about my request of DirectionCONSTRAINT.

For me it feels like a Bug - but you are right in some ways it might make sense and could be an interesting ADDITIONAL option.

@ Helvetosaur:

I gave it a chance and tried your workaround.

Even if it is never easy to let go old habbits it should work, right.

But unfortunately the option "align to object" works in my case with a single object only.

As soon as there are more parts selected the gumball switches back to the selection center point and world axis direction.

As long as all selected objects correspond to the same angle, Rhino should keep the gumball angle, shouldn't it?

- again no easy way for normal-restricted modifications.

The difference that I see so far between V4 and V5 is that in V4 the last face chosen sets the normal direction and on V5 it seems to be the first face chosen. If you can post a file with the start, and the results, and the desired results, that would be helpful in sorting this out.

thanks, 

Pascal

pascal@mcneel.com

The difference that I see so far between V4 and V5 is that in V4 the last face chosen sets the normal direction and on V5 it seems to be the first face chosen.

that's if you're selecting multiple faces on the same polysurface then those rules come into play..

but if you're selecting faces on different objects, then the normal direction of each surface determines which way it will move..

dunno, i'm coming from a sketchup background.. with it's push/pull tool, you can only do one face at a time.. the way moveface in rhino is working is how sketchup should be working.. preselect different faces then push/pull (or move) them according to which direction their normal (or frontface/backface) is pointing.. all at once

[edit].. for example..

6 different square planes showing normal direction..

after MoveFace

[edit2]..err. i guess that would be 7 squares..

This is fixed for SR2. The preview still incorrectly shows two directions, but the result is that all faces move together.

thanks, 

-Pascal

pascal@mcneel.com

wait..this is how it should work though.. 

all faces move together when you join them because it then orients all normals in the same direction..

i think though, something like this is happening:

i'm new to rhino (ok.. I'm not really that new.. i use it a lot and have done a few real world projects with it.. just not super knowledgable about it yet).. and maybe i dont quite get all the philosophies behind it etc.. and it feels like I'm talking about one thing while the people more used to rhino are talking about something different..

so i'm taking the command name MoveFace and basing my assumptions of what it should do via the name.. 

anyway, can you explain what the command is supposed to do or give a scenario of when you're supposed to use it?

[EDIT] or wait.. are you saying SR2 will allow you to select 2+ sides of a cube and they all (individually)move in a perpendicular direction of their particular face? if so, that's great news :)

1. Thanks Pascal, this is what I was asking for - all parallel faces should move together to the same side !!! (Because this is what it was doing before and is excactly what I need.)

2. In my case I never missed the functionality to move multiple faces according to their "inner" direction, BUT since Jeff is discussing that issue on a more mathematical base, I understand that the DirectionConstraint option in fact might have three possible values:

= NONE

= NORMAL (constrained to the normal-AXIS ... on multiple selection it works on parallel faces only, and does not care about the direction of each face. [just as it works in Rhino 4])

= NORMAL+DIRECTION (constrained to the normal-AXIS AND DIRECTION of each selected face ... multiple selection of faces in any direction is allowed, the move takes place with the same distance, but direction is acording to the direction of each face)

"", BUT since Jeff is discussing that issue on a more mathematical base,""

hmm..  i actually don't think i'm discussing this on a mathematical base (or other geeky theoretical type stuff about what's proper etc.. ;) )

i think i'm discussing from a practical standpoint (at least trying to)..

it's just that i feel like you should be able to do this simple example:

ExtrudeSrf does it right but you have to do it one step at a time.. MoveFace almost does it except it deforms the hexagon in an undesirable (to me) way..

but the wording and options of moveface constraint:normal seem like the more likely candidate to make this example possible with.. (ie- select all the faces then they move in their normal direction).. 

but to have MoveFace only able to deal with parallel faces seems kind of silly and/or a waste to me.. and once you get out of the parallel face realm, something has to decide which way the face will move and the only way i can see that is by it's normal direction..

but the stuff you (M.) seemingly want to do with MoveFace is more like an exploitation of it's previous errors.. ie- it only worked on parallel faces therefore you could use it to check if faces were parallel because if they weren't, the command would fail.. personally, i think there are better methods for making sure your models are to spec other than depending on a broken command.. continuing, MoveFace will do what you want with parallel faces-- just turn off the Normal constraint and move them accordingly.. 

i get it.. it used to do what you wanted and/or you found a way to make the command work for you.. but asking the devs to bring back a feature which was crippled (at least as i understand it's capabilities) seems like not the best way to go about it.. there might be a better and/or more practical solution..

 

RSS

Translate

© 2014   Created by McNeel Admin.

Badges  |  Report an Issue  |  Terms of Service