When i want to carry out an extrusion of a curve, I select the curve, call the extrude command, and the object is immediately previewed extruded to wherever my cursor is, giving me good feedback.
Now by moving the cursor, i can see this phantom extrusion change in real time. Good. So I decide, in conjunction with this feedback, to enter the extrude distance of lets say 30mm in the direction the phantom is showing in all the viewports, press enter, and as often as not, it extrudes in the opposite direction.
Now I know, because the readout at the bottom of the screen is telling me, if it is 30mm or minus 30mm, so all I need to do is observe this, and enter the correct distance, or negative distance.
So whats the problem? The problem is that I’ve already “told” rhino which way I want the extrusion to go - I see it happening on screen. So why doesn’t rhino just do it, instead of making me check the little numbers down the bottom of the screen to ensure it is going to do what I actually see in the preview?
It obviously can be made to work like that, “other” programs work like that, and it seems to me one of those things that makes sense in a programmers mind, but it gives me swish in my designers mind (modeling tools for designers!).
I’d like to see this command updated to work taking into account what is actually shown on the screen…
Well… It does make some sense to ask for this. Especially when you are in a phase where you need to play around with dimensions a bit. I get there as well.
But when you get to the point where you know what you want - a 10 units extrusion - and you know what is up and down on your model (or CW / CCW for rotation), you don’t necessarily care about the preview. The problem then would be that you would have to check where your mouse is in order for things to go the correct way.
And how would that work when running a script? The mouse will always be somewhere on the screen …
That should be no problem, as it works fine with the Offset command - it takes the winding by default, and the optional user direction input is added on top.
It is true that it would add an additional action to the extrude command. But then it would be more consistent with other commands.
E.g. move commands are sensitive to the mouse position (if you lock with Tab).
IIRC, Rhino paid attention to the mouse pull direction with Extrude up to Rhino 2 or so, then it was changed to the current behavior - for the inverse reason of Tony’s, i.e. people that simply wanted to extrude and type a value without having to pull the mouse in the direction they wanted it to go. Because if pays attention to the mouse cursor in that case, half the time it will be wrong as well…
move has an inconsistency within itself… if you use Move Vertical, it doesn’t pay attention to the cursor position… if you use Move then lock the direction to vertical with Tab, it does consider the cursor position… and both operations appear to behave identically in the viewport except different results are given.
another ‘error’ along these lines is if using Move Vertical, the distance readout will always show a positive number even though it’s one of the instances requiring you to enter a negative distance if wanting to move downwards.
were there preview extrusions available in the software when this decision was made? if not, then it makes a lot more sense to have +&- rules in place…
with previews however, i imagine the majority of people would rather have what-you-see-is-what-you-get functionality…
regardless of where the object is in relation to the axis, if an extrusion is showing it’s moving in a certain direction, this is the direction most users (i feel) would expect when entering a positive number…
what can happen now is that the preview is showing one thing then upon entering the distance, the exact opposite occurs.
Sounds to me like the real issue with this inconvenient and inconsistent behavior stems from the operator’s failure to consult the printed value at the bottom to find out whether the value to be typed in should be positive or negative. Given the amount of eye travel involved in most cases, it’s not surprising. It’s a PITA.
Wim’s “close at hand” idea is one possible help. Another, IMHO, might be for the live preview to be depicted in one color for positive values and another for negative values. This concept could be applied, for command consistency, to all commands with a live preview with the same type of relationship to typed-in values. @dale, @stevebaer
Probably not the correct person to answer this, but I’m reading the requests in the way that only positive numbers should ever be entered (unless one would want the output to be the opposite of what is shown in the preview). So probably not, no.
But allow me to back up a few steps here. @rabbit, @AlW, Al writes
[…] stems from the operator’s failure to consult the printed value at the bottom to find out whether the value to be typed in should be positive or negative.
But in Tony’s case (and all others?), it’s not just for finding out the sign of the value. The operator moves the mouse to get a preview of about where the extrusion should go but then types in the value (so that it doesn’t become 29.236 but 30.000). The only way to find out about that value is by looking in the place where the sign of the value also is displayed.
The point of this request is simply I want to be able to enter a unit value, which will automatically be + or - depending on what the preview displays. End of story.
For scripts, or If people prefer to ignore the preview and enter the value + or - directly that’s fine, and this will always override the preview.
So if the preview shows a + direction, and the user enters a negative number, that’s what would happen.
If the preview shows a negative direction, and the user enters a positive number ( ie enters the actual + sign) , then that’s what would happen.
So then we gave an entirely consistent mode of operation:
Entering a unit value will extrude in the preview direction.
Entering a specific + or - value will always do what it says.