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âŚ
heh, yeah, iâve asked for the same thing in the past but the request didnât generate any tractionâŚ
another instance where iâd like it to work the way youâre saying is when rotating⌠no negative angles, itâs all positive numbers and the rotation goes in the direction the preview is showingâŚ
(well, you can still enter negative numbers in this instance⌠it would just rotate/extrude in a direction opposite of what the preview is showing).
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
Hi Tony, all - FIn shows some direction arrows to indicate what it considers the + direction to be (currently slightly buggy, but itâs the thought that counts) . Would that work here?
If I type a negative number, the fin will go in the preview direction (follows my mouse) and if I type a positive number, it will go in the arrow direction.
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.
