Gives me swish


#1

Something that really annoys me is this:

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…

cheers
tony


ExtrudeCrv doesn't respect minus
#2

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).


#3

Ok good, I’m not the only one who thinks this problem is totally ridiculous.


#4

+1
happened to me more times than i dare to admit…


(Wim Dekeyser) #5

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 …


#6

The sign of the value you see here


Vittorio


(Wim Dekeyser) #7

Yes, that’s what Tony mentioned.

FWIW, I prefer to have that information closer at hand myself:


#8

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).


#9

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…

–Mitch


#10

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.


#11

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.


#12

Yes, there have always been previews, but IIRC, they were only in wireframe up to V3. --Mitch


#13

Yes, all the things mentioned here are not WYSIWYG - which is a baaad thing!
:wink:

Philip


#14

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


(Wim Dekeyser) #15

Here’s a few others for that command:

  • Move - vertical doesn’t allow you to move to 0 just by typing 0 at the Point to move to prompt. [This one bugs me all the time].
  • Move doesn’t have a Copy modifier. The other transformations do.

#16

What about a, say, FollowPreview option ?


(Pascal Golay) #17

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.

-Pascal


(Wim Dekeyser) #18

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.


(Pascal Golay) #19

Right, but keeping in mind Mitch’s comment…


at least you’d know what sign to type…

-Pascal


#20

To be clear:

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.

Cheers
rabbit