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?

1 Like

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


see also here

Hi Tom - Box from 3 points does the right thing. I do not see changing it. It is not the Extrude command.

For ExtrudeCrv, my preference , I think, would be to show an indicator on screen for the + direction so that it is clear whether to type in a positive or negative number. Planar curves’ extrusion direction should not depend on the CPlane in any way. - it get’s too ambiguous with curve planes that are not parallel to the CPlane. ( unless it simply defaults to CPlane Z as it does now with multiple planar curves in different or non-parallel planes)


dear pascal - thanks for having a look at this older topic.

update for this section to make more clear what i meant up there: (cant edit older post)

  • numeric input should finishing by pressing enter and height should correspond to cplane z or for planar curves: ccw-direction curve plane normal, no influence of mouse postion, pure keyboard input.
  • mouse input should finish with a mouseclick in the viewport
    • interaction with mouse is nice
    • there should be a better approach in defining at which position the mouse changes the direction, some visual indicator, closest point / Pick point if available, my screenshots in above post show a possible approach / improvement ( in my opinion)

for some camera positions it is completely counter - intuitiv where to click. especially it not the entire curve is on screen.
and for those cases a pure numeric input would be most easy but does not work.

maybe this (fake-/pseudo) example is convincing:
a big project
a small detail
a huge curve to extrude
extrude the given curve 5 mm upwards - without changing the view - because the next (fictional) step is also some work at the detail

the extrusion i want

extrude_me_5mm.3dm (36.7 KB)

by the way - did you see my other _extrudeCrv wish ?


kind regards -tom

Hi Tom - SetBasePoint with Near should help here.


Dear Pascal

yes i know - but this is not an argument to keep the direction-indicator at the boundingbox-Center or to not allow a pure numeric input. If the position of the direction indicator would in some ways interact with the mouse-position, a more intuitive approach would be possible - and me and my students would appreciate this. thanks - kind regares -tom

just to give a nice example of a workflow that shows that a pure numeric input should be possilbe. (indicating the direction)
Example taken from a Rhino Introduction course - a question of one participant:

draw 10 concentric circles
extrude them from 1 to 10 mm…

if you do this as a beginner, and start with the outer circle you will suffer a lot.
(mouse postion is im important, but picking and extrusion direction combined with point snapping give a use potential of confusion…)
if you do this as a more experienced user, starting with the inner circle it gets more easy - but still you really need to care about the mouse position after each selection…

select curve
_extrudeCrv 10
(unnecessary : check mouse position)
select curve
_extrudeCrv 9
(unnecessary : check mouse position)
select curve
_extrudeCrv 8
(unnecessary : check mouse position)
select curve
_extrudeCrv 7
(unnecessary : check mouse position)

my opinion / suggested solution:
as stated somewhere else:

clicking in the viewport should use the mouse to indicate the direction
pressing enter - only the numeric value should define the direction

(currently even pressing enter, the mouse direction will be taken into account)

and if you do it with a macro… the dependency is even more frustraing (active viewport, zoomposition, place where you click to start macro):

Dear @ Mc Neel
Dear @theoutside
dear @Gijs

Sorry but I have to insist on this topic.

Today in the classroom, first session with 6 Rhino-Novice.
Explaining cplanes, coordinates +/-, trying to distinguish between mouse-input and numeric input…
and then it comes to extrudeCrv
and suddenly there is a mixture between mouse position and extrusion direction.

in terms of having a clear solution:

similar to _offset D=6 → click side to offset → click direction to extrude…

V8 would be the right moment to finally make this clear.


kind regards



hi @Tom_P The way this works was changed long time ago, and changing this is not very likely to happen. The benefit of how it works now is that you don’t need to bother about typing a - or paying attention to how your CPlane is oriented. What does work (I just found out) is entering a vector e.g. 0,0,12 This will disable attention to mouse position. The first two numbers seem to have no influence on the result however. Other than that, I think extrusions are far easier to make with Gumball, where you can enter positive and negative numbers.