This is fixed in Rhino WIP 6.0.16306.09301 that was just released.
Well I see no change from the v5 behaviour…
Call Extrude, select a curve, drag it to preview, type in a distance, and the extrusion is created based on the + or - direction as before even if the preview shows the opposite.
Cheers
rabbit
awesome Brian.
if you guys get positive feedback on this, maybe consider doing something similar with the Rotate commands.
How can this be…?
As far as I can see I do exactly what you are doing, but i get different results:
1] I create a curve in the perspective view as you do.
2] I call extrude curve
3] I select the curve and move the cursor so the preview is negative in the Z axis, type 10, and the curve extrudes 10 units in the + Z direction.
???
Rhino 6 SR0 2016-11-1 (Public Build, 6.0.16306.9301, Git hash:6.0.16306.09301 in branch n/a)
Windows 7 SP1 (Physical RAM: 7.9Gb)
ATI Mobility Radeon HD 4650 (OpenGL ver:3.3.11672 Compatibility Profile Context)
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Anti-alias mode: 4x
Mip Map Filtering: None
Anisotropic Filtering Mode: None
Vendor Name: ATI Technologies Inc.
Render version: 3.3
Shading Language: 3.30
Driver Date: 11-16-2012
Driver Version: 8.970.100.7000
Maximum Texture size: 8192 x 8192
Z-Buffer depth: 24 bits
Maximum Viewport size: 8192 x 8192
Total Video Memory: 1 GB
C:\Program Files\Rhino WIP\Plug-ins\Commands.rhp “Commands” n/a
C:\Program Files\Rhino WIP\Plug-ins\WebBrowser.rhp “WebBrowser” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk.rhp “Renderer Development Kit” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoScript.rhp “RhinoScript” n/a
C:\Program Files\Rhino WIP\Plug-ins\IdleProcessor.rhp “IdleProcessor” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoRender.rhp “Rhino Render” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI” n/a
C:\Program Files\Rhino WIP\Plug-ins\Alerter.rhp “Alerter” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoCycles.rhp “RhinoCycles” n/a
C:\Program Files\Rhino WIP\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” n/a
C:\Program Files\Rhino WIP\Plug-ins\Displacement.rhp “Displacement” n/a
cheers
rabbit
Yea, that’s what I was afraid of…
- Draw curve
- Select curve
- Call ExtrudeCrv
Now - I know that I need to extrude it 400 units in the negative z-direction (because I have a clear requirement and I know where I put my curve -doh-)
So I type -400
Where does the extrusion go?
Well - you’ll have to wait and see coz that depends on where you left the mouse after having drawn the curve (as selection of that curve is done with SelPrev, calling the command is done on the cmdline, inserting the distance also while having the hands safely on the keyboard…) This sucks…
I can see that this is a problem for those who rely heavily on typing commands. (I am not as hard core as you, but I do it a lot)
I guess this could be solved by tracking the mouse position and compare the data it to see if it has been moved after extrude was started and the distance was typed. If no movement use old direction.
In order to satisfy both parties, I would suggest that an additional sticky command line option be added - something like
_DefaultDirection=_Natural = old V5 behavior
_DefaultDirection=_FollowCursor = new, follow the mouse behavior
(can change the prompts to some other description, whatever)
This is the only way I can see to satisfy both parties - other than making some kind of general choice in Options.
–Mitch
“Global option” would be preferred, fostering consistent behavior throughout the system.
// Rolf
This is exactly why I was not super enthused about this change…
-Pascal
@pascal I’ll leave it to you to reopen the bug report and add the appropriate changes. I think Mitch’s suggestion is good - but I’d have the default be “FollowCursor”.
Hi Rolf - how global? Where would it apply other than in the Extrusion commands?
-Pascal
hey pascal,
maybe the Box command could get tied into this somehow?
it’s pretty weird regarding which way the extrusion will go after making the rectangle.
if the 3rd distance followed the cursor, it would make more sense (to me at least)…
probably Cylinder too. (but then again, i’m not sure if you’re already considering these to be ‘extrusion commands’)
ok, sussed it - i was using an alias for extrude curve that I’d been using since at least v3, and it had a few bits tacked onto it, which was causing this new release to work just as V5…
So Ive changed the alias to just the vanilla command, and all is good!
So I (of course) think this is a great improvement - thank you very much!
The dissenting comments from those who think it is crap remind me of what the novelist Patrick O’Brian often remarked on during the course of the 20 (well 20.5 since he died before completing the 21st) books collectively known as the Aubrey/Maturin series, set in and around the Napoleonic wars in the British navy.
Whenever there was a change in the routine aboard ship, regardless of whether it was for the better or worse, the seaman would grumble and become fractious, because, as O’Brian put it, they’d rather put up with various inconsistencies and difficulties, because they had got used to them, and above all, they liked what they knew…
oops, man overboard…
cheers
rabbit
[quote=“rabbit, post:54, topic:37118”]
British … seaman would grumble and become fractious, because, … they’d rather put up with various inconsistencies and difficulties, because they had got used to them…"[/quote]
Landlobbers OTOH didn’t always have the opportunity to get used to changes… (classic graph illustrating the successive losses during Napoleons Russian campaign) :
Don’t know whether they used Swish or Smash to illustrate this one though.
// Rolf
Making improvements to Rhino is always a trade off. One thing that frustrates me is that we’ve been so diligent about making sure everyone can do what they want that Rhino has become a sea of zillions of options that most people have no idea about and therefore never change. I feel another one coming on…
[quote=“wim, post:46, topic:37118, full:true”] This sucks…
[/quote]
hey wim.
i don’t entirely disagree with that but at the same time, i feel this change is the lesser of two evils.
having a preview showing you one thing then the execution being opposite is a fundamental type flaw in UI design (imo).
that’s the problem and while using the preview as the determining direction may be annoying or even slower in some cases, the UI at least does not suffer from poor design.
i have a lot to say on this matter but i’m going to skip a lot of the reasonings and suggest other solutions that i feel would be most suitable for power users (and still better for everyone else).
• everything works the same as normal except, you can press tab key to tell it to extrude in the direction being shown by the preview.. so if the extrusion preview is going in a negative direction, you could press tab then enter the distance and it will go in a ‘negative’ direction even though you’ve entered a positive number.
• everything works the same as normal except, depending on what you enter in the command line, the preview direction will change.. for example, if the preview is showing a positive direction and you type the negative sign ( - ), the preview will change to a negative direction to correspond with what youre typing.. if the preview is showing a negative direction and you enter a number without the negative sign in front, the preview will switch to the corresponding positive direction.
at the very least, these type of options will help prevent you from finishing a command, being surprised/wtf?, undo then redo the command.. if you make an error, you’ll know it while you’re still inside the command and will only need to retype with the negative sign if need be but, you won’t have to redo the entire command..
also, an advantage to either of these (as well as preview-determines-direction) is that you don’t have to focus in on a tiny area/textbox to see if rhino is thinking positive or negative.. the previews are big and easy to see and you can notice them out of your peripherals even to the point to where if youre looking at your keyboard, you can get good feedback on what you’re typing without looking directly at the screen or worse, looking at a tiny text box within the screen to see if there’s a dash or not.
both of those, to me, would be better to handle all situations but they’re also a little too confusing for all users/usages as a whole (in which case, i believe the wysiwyg change with the preview-determines-direction being the right choice).
I’m not sure if it’s possible, but what do you think of @jeff_hammond’s suggestion? If we could show you where the extrusion was going to go as you typed the number - that is, you type -4 and by the time you get to the zeroes, the preview would be going the opposite direction from what you expect.
This is an interesting idea. Right now, I don’t think Rhino pays attention to what you’re typing before you press Enter. But with autocomplete/autocorrect becoming so prevalent and familiar, I can see how this could be really cool. @mikko is it possible to peek at the command line as keystrokes happen, and change the preview direction?
That is essentially asking “Is preview possible” (or, implicitly stating; we currently don’t do preview) 
You can set up many rules or guidelines regarding UI, but some of them you may never break - Thou shalt not fool the user.
It’s better to show nothing than to tell the user it’s going in one direction while going in the opposite direction when pressing Enter.
// Rolf
I’m shooting from the hip here, so forgive me if this doesn’t seem too coherent.
How about making Extrude behave akin to Line? In my un-taught way of Rhino thinking, a line is a point extruded. An extrusion is a line extruded. With Line, I can pick a base point to start from, then type a distance and hit enter. The cursor is then constrained to allow me to draw a line of that length in any direction I so choose (restricted to X, Y, Z axes if ortho is on) or I can snap to some other piece of geometry to set the direction. Picking the point with the mouse creates that line segment. Hitting enter before I do that cancels the command, which always seemed a little odd to me - why isn’t the line created in the direction that was presently shown on screen? Putting a minus in front of the distance appears to have no effect on the direction of the line that’s subsequently created. But it does with Extrude?
I guess what I’m trying to say is that there’s a lack of consistency in the way that Rhino commands work. This is understandable, given that the considerable set of tools that Rhino has amassed over the years came at different times in its life. It’s the beaten up old toolbox that you’ve got in your shed; all the tools are good quality and dear to you and all have a specific purpose, but some of the handles are Stanley, some are Wera, some are Snap-On. Each one has its own idiosyncrasies. To the long-time owner this is of little consequence as you remember buying the tool and know its ways. To a new user, it just looks like a jumble of tired old stuff and it’s all a bit confusing and intimidating (and oily 
)
So, why not take the opportunity with V6 to bring things into line?:
Allow ‘c’ to be Copy on as many commands as possible. Even things like Move - why should I hit Alt to create a copy, with some weird stop-start mouse behaviour to get it to work, when everything else has a command line ‘c’ to copy? A rotational translation (Rotate) has ‘c’. Why not allow Copy in-command for things like Line and Extrude? It’d be great for quickly bashing out a load of items in quick order
Allow ‘d’ for Direction - again, fairly widely adopted across commands, but not universal by any means. Decide whether a “-” is going to modify the direction, then apply that consistently - even to Extrude.
Tab - Allow this to lock direction, but if a distance has already been set, do you need to still pick a point, or is Enter sufficient to compete the command? Applies to Move, Copy, Line, Fin, Extrude, etc.
Uniform, consistent and predictable behaviour like this would make Rhino even easier to learn.
Specifically for Extrude, the addition of an extra hit of the Enter key you could allow you to enter a distance (+ve or -ve) and see a preview of what that’s going to give you, before hitting Enter again to confirm. We get this double-Enter preview behaviour already for things like Array, so there is a precedent, but again, it’s inconsistent.