Extrude direction


I wonder if I can adjust the settings when I extrude a line that the direction is related to the World coordinates and not to the Mouse position. like it was in Rhino 5.
As it is now it is not convenient since I work with many curves and do not know which direction they are going because I use the keyboard a lot and not the mouse.

Greetz Nick

If you specify a direction by typing either an negative or positive interager doesn’t this dictate the direction of an extrusion?

No, unfortunately no more. if i type a negative intergarer it goes the negative side of my mouse

It did in V5. It was changed in V6. In the case of V5, it was somewhat arbitrary as you actually had no idea which way the extrusion of a closed curve would go - depending on the direction of curve, clockwise or counterclockwise. So typing a + or - number was not always reliable.

That was why In V6, after much discussion, it was decided that a mouse cursor indication would be required to confirm the direction of the extrusion.

This will be a positive thing for some people and a negative thing for others - depending on your work habits.

Ah - haaa

I haven’t yet updated to V6 which explains my non familiarity with this.

Yes I can see what you mean there.

I guess the decision to make it this way was probably best. BUT it would be really convenient (workflow wise) if you could as NK is suggesting specify extrusion length and direction without your hands leaving the keyboard. Perhaps if after typing a decimal extrusion length the arrow keys could be used to toggle extrusion direction?

Thanks for the clear answer.
Unfortunately, for me it is a negative change. For me it was always clear wich direction it was going as we work around X axis (+X is always forward and -Y Always to Port side. +Z going up) and for the angled parts we zoom in to check.

So there not a possibility to switch between the 2 options?

No, unfortunately not. However, if you don’t need previews, a scripted solution that would act more or less like V5 can probably be crafted without too much effort.

I don’t see how i can script this? Or do i need to make a script and ad it to al the functions?

PS: If i use the move function it will act the same (related to the mouse) But when i use move “sub vertical” its not related any more to the mouse. But to the world.

This would be a script (Python or Rhinoscript), not a macro. With a macro it’s not possible.

How much work it would be to write the script depends on how you are going to use it and what kind of options you want in the script - capped or not being the main one I guess… A script could also be made which would extrude either surfaces or curves or a combination of both I guess.

Hmm So you mean that i need to script/ rewrite the extrude, offset, Move, etc, functions with all its sub options as we use them all.

Well Thanx for the fast responses. I will try to make some scripts when i have some free time.

sorry to pop this old topic back alive…

currently i try the mac-version, i hope this behaviour is consistent between mac and pc.

working with a large project, the concept for extrude direction feels not very intuitive.
especially as _extrudeCrv and _box → 3Points have different concepts.
(and _box 3Point is to draw a rectangle first and extrude it - in one command…)

in my opinion a numeric entered value should behave like a coordinate in current cplane z-direction. Entering stuff numerical should not interact with what is happening on screen.
If a user wants interaction with screen, he should klick on it !

while typing focus is on the input field, not on the mouse position.
i would prefer the V5 approach - it was more consistent with other commands …

a great thing about numeric input is, that i do not have to care about point snaps, mouse position and so on. imagine a huge architectural project within a complex file, nearly no area without a pointsnap, constructing boards that are very large compared to the desired thin thickness:

visually the mouse is above the rectangle.
but as it interacts with the invisible boundinbbox-center the extrude is directed downward

currently workflow
(1) select the curve (which affords zooming in)
(2) type 5 (not pressing enter)
(3) zoom till i see the entire curve
(4) control if the direction is indicated correctly
(5) press enter or click. (same behaviour)

it would be great if enter the height would be enough without looking at the mouse positon !
(1) select the curve (which affords zooming in)
(2) type 5, and press enter to use current c-plane z-direction
(3) zoom till i see the entire curve
(4) control if the direction is indicated correctly
(5) click on the screen / into viewport.
(or still press enter to accept the direction like (2))

But still
the current indication of the direction uses the center of the boundingbox.
this is not very intuitive - see first screenshot.
this point is not even within reach or within the viewport.
why should the mouse interact with something the user can’t see ?

current flow:
center of boundingbox (green dot)
virtual direction-indicator in 3d-space (on Boundingbox center)
shortest connection in screen-coordinates (green line) to the virtual direction indicator

more intuitiv and my suggestion:
the direction-indicator should be closest point curve to mouse.
in my example it would be the blue point → blue line
the final point identifing the height would be the red one - which is also visually above the rectangle and not below.

in summary

  • numeric input finishing by pressing enter should correspond to cplane z or for planar curves: ccw-direction curve plane normal
  • interaction with mouse is nice, but should have direction indicator closest to mouse

maybe this is part of the discussion about UI fine-tuning i had with @dan ?
kind regards -tom

there is another command that feels a bit unexpected in comparison to _extrudeCrv
entering a fixed value for the distance:

pick first point
pick second point
100 enter … to define numerically the distance for the dimension
now a mouse-click is needed to define the direction

but even more annoying:
clicking enter a second time, the command is canceled !!

please mc neel - make those direction inputs consistent !
i want the same workflow and feeling for similar input.
or at least - if a click in the viewport is needed - give some visual feedback.


kind regards