Box 3 point not using c-plane for extrusion height

looks light the numeric height in _box 3Points follows the right hand rule

i made another entry / post about this UI - inconsistency.

just to show the inconsitency in a simple comparison check out
_box _3Point
_rectangle _3Point _pause _pause _pause _selNone _selLast _extrudeCrv

or read my much longer post here:

@pascal (et al), have a look at the video I’ve linked. I think it demonstrates more clearly the issues with the current behaviour of box 3pt. That it is both unintuitive, user-unfriendly, but also inconsistent with the way other rhino commands operate.

1 Like

Direcetion depends on the clicking order.

It’s similar as when you rotate around an axis.

@martinsiegrist, - known that the whole way along. It was part of the first post (CW v CCW defines the z orientation if the implied plane)

The issue here is not so much understanding the behaviour of the tool but working out whether or not that’s how it should be behaving, given it’s different to most other geometry creation tools and it’s incredibly user unfriendly.

The CW v CCW bit, or Right Hand Rule or whatever you want to refer to that behavior by was understood from the beginning and part of my first post. So while it’s great that people have been keen to contribute and many have now re-confirmed that this is tool making assumptions based on RHR frame orientation, no one has really been able to weight in on whether or no this behaviour is a good way to have designed the tool given the negative impact it has on it in most use cases.

1 Like

It would be really great if you could enumerate these.


I see your point with the situation explained above but I also think McNeel has their reasons why certain commands are the way they are.

Mate just go watch the video I shared, there’s a pretty good example in there.

Or if you think it’s functioning correctly then how about you give me an example, of how using your first 3 points to define the positive direction of the extrusion is more useful than using them to define the position scale and orientation of the base rectangle. And why it’s better to lock-out the option to specify the direction on screen

@martinsiegrist Normally I’d agree. But I think in this one instance it’s something that may have just been overlooked, which is why I’ve asked the question.

Maybe most people who use box 3pt just click the final point on screen rather than numerically specifying a distance - in this case you can go whichever way you want. But numerous people have posted about this behaviour previously. It’s frustrating to me as a user (even understanding the mechanics of the tool), and it’s pretty clear it’s been an issue for others previsouly too

i totally agree.
the behaviour is not consistent and should be unified.

did any body checked this two identical workflows that result in different behaviour.
pleas @pascal have a look at Josh 's video - thanks

1 Like

Well, I don’t know, I understand the outrage but I think we could very possibly break many a workflow if this were to be changed. These are not identical workflows - Rectangle > 3pt says nothing, currently, to the Extrude command about an orientation of the plane There are two unrelated commands running whereas in Box > 3Pt explicitly lets you set that direction - Any workflow that depends on this feature would break.

Currently, if you run a macro like

! ExtrudeCrv 12 Enter

with planar curves pre-selected, you get an extrusion in either direction depending on where the cursor is when the command runs. It does not care how the curves were made.


thanks pascal for having a look.

When the extrudeCrv Command behaviour changed from Rh5 to Rh6 the same happend.
And i think it is a bad idea to have a pure number commandline input (or macro) depend on mouse position.
If mouse position matters, a click should be necessary.

_box 3pt gives different curve directions depending on the click-order

setting cplane to object will give different results. on those curves

it would be logical / more consistent if
_extrudeCrv 12 _enter
would use curve directions if not on current cplane.

but i have no idea for open planar curves. ;-(

Hi Pascal,

I don’t see how having an option to specify the direction on screen would break anyone’s workflow. Could still have the default direction set by the implied plane (and I’m gonna keep calling it “implied” plane because nothing in the way the tool is set up suggests that the points you select are/should be used to define a plane).

You’ve expressed concern that changing this could break some workflows, but as it is it DOES break others - including the primary use of the tool. And there are ways of making it work for both. Also, if there’s a specific workflow that requires an implied orientation then THAT is what the work around should be for. It’s probably already in some kind of macro, so makes more sense to customise it there. We shouldn’t be needing to make macros to replace basic commands like Box-3pt just to make them behave in a way that’s logical to an average user. Yet that is what’s been suggested again and again.

I get that it behaves as coded.
But we are still to determine if the behavior that’s been coded actually really is how the tool was intended to be used.

Are you able to provide any insights to that? I think the video I linked explained pretty well why it’s inconsistent with other tools, why it doesn’t produce the expected behaviour, why this behaviour limits it’s usefulness, and why it’s frustrating for users.

Ultimately, I think it comes down to this:


  • The 3 points in box 3-pt should be used to define the LOCATION, ORIENTATION & SIZE of the base rectangle.
  • The behaviour of the extrusion should then follow the same logic as other basic solid tools. As with most other basic solid tools, this is a separate and secondary part of the tool to defining the base rectangle


  • An ALTERNATIVE functionality of the tool is to use the 3 points to define the extrusion direction.
  • However this behaviour is not compatible with also using the 3-points in the first mode.

  • ALMOST EVERYTHING suggests the first mode is how the tool should be working. This includes tool descriptions, user expectations, functionality of other tools.
  • There are clear use cases and workflows for the first mode, but currently this IS BROKEN. (go watch my video)
  • There are some assumed use cases for the second mode

  • So far, no-one from McNeel has been able to say

’Yes the primary function of Box-3pt is to create an implied plane so we don’t have to specify an extrusion direction and we’ve deliberately mislabeled said direction as ‘height’ because why not, and if you want to use it to define the location size and orienation of the base rectangle (how we described it in the tool tip), then go make yourself a macro."


’Hmm, no. The intended use of Box-3pt was to let users set the location orientation and size of the base rectangle, the ‘height’ should still behave similar to the other box options. Occasionally going upside-down is an understandably unexpected and frustrating outcome, I guess that’s why so many other people have questioned it on other threads. This is something we’ll have to review and find a fix for that still works with other ways people may be using the tool’

Can you tell me which of these statements is correct?

I apologize if attitude on this is coming across as outrage. I certainly am starting to get a bit frustrated on it though as most of the responses so far have been:

  • Just trying to explain the behaviour. While I appreciate people trying to be helpful this isn’t the issue and the behaviour was both understood and explained in the first post.

  • Or basically just ignoring the issue, under the guise of “well scrpting and macros is more important anyway, and if it doesn’t work how you want you should just go make yourself a macro”

Currently, I’m trying to teach people how to use Rhino. Working in MODE 1, Box-3pt WOULD be one of our most frequent tools. We work in architecture so lots of things are still very boxy. But I can’t teach them the Box-3pt because it’s inconsistent FOR A USER. It might be consistent for A MACRO, but it’s bad FOR A USER.

The USER experience should come before the MACRO/SCRIPTING experience.

Just as a little reminder - This is how the box tool should be used as per MC NEEL.

2 separate steps.

DRAW a base rectangle
DRAW a height for the box.

And box 3-pt specifically…

All about using the 3 pts to define the rectangle. Not the ‘height’ direction.

I do not think this is likely to change. Not impossible, but unlikely, I would say. Removing that control, especially in cases where the inputs are not in the CPlane, would just cause too many problems, I predict.

In the meantime, a macro might be helpful

! _Rectangle _3Point _Pause _Pause _Pause _SelLast _ExtrudeCrv _Solid=Yes _Pause _Delete
@kelvin - maybe there is more we can do in the Help description? I understand what the OP wants here; I would hesitate, a lot, to remove the ability to set a base plane and direction, but maybe we can describe more fully in the help topic what that 3 point options does…?


First step is at least just acknowledging there’s a problem.

I don’t see why it would cause issues. It works fine for every other solid tool… Can you give an example where it would cause a problem if it were changed? I’ve given a bunch of where it causes problems how it is now.

Situations when you’re not working on the C-Plane are actually a much stronger use case for Mode 1. If you are not working on the C-Plane then your snaps become even more important. Ie it’s even more important that you can use them to set the location size and orientation of the base rectangle.

The description in the help is correct. There is a clear need and use for a tool that lets you draw a box by specifying the location size and orientation of the base rectangle. I’ve gone through such an example in my video. That’s why the tool exists.

If there is also a need for an option/tool that lets you create a box by specifying a plane with 3 points, then perhaps that should be a separate command, or THAT is the niche situation that should be dealt with in a macro. All the advantages/issues you’ve talked about are for situations where it’s used in a script/macro anyway…

Also, I don’t know why you’d have to remove the ability to still use the implied plane z direction. Surely there is a way to just add this as an option in the command such that it can still be used in a script/macro

it also will define the normal direction of a surface. that has been there since forever. maybe that is part of why the 3pt box extrudes down automatically because a surface created clockwise has the normals always showing down.

i also think that box 3pt should extrude up at least, not down since i think that is the rather more used user case.

at least constraining the direction should be possible, but having to enter a negative value for extruding upwards can only be bug in my opinion, it is obviously counter intuitive to say the least.

1 Like

dear @encephalon .
thanks for your post.

… this was more a comment on pascals statement - as far as i understood him correctly, he s arguing that the mouse is the only option to indicate a direction for a curve not on current c-plane - and i argue - similar to your explanation, that the curve-direction is identifying a normal-direction for a closed planar curve and can be used to identify a extrusion direction also.

i think what makes it most confusing is, that some commands are counter-intuitive regarding this height-Aspect - but have a mathematical explanation,
and some commands use the mouse-cursor position to identify the direction / the sign (+/-)
and as we have two approaches people get confused ;-(

I think Josh s initial video shows it very nice - but as the video still only has 3 views (and i am one of those 3 viewers ) not sure if the important people from mc neel had a look at it …

1 Like

Hi @pascal and @Kelvin,

We have clearly identified now that there is a problem with this. Has it actually been raised now to be reviewed by McNeel?

Just as a reminder for if you’re bringing others in to the discussion - I’ve tried to articulate the issue as clearly as possible in this little recording here

Pascal has expressed concern that there maybe, might possibly in theory be some issues to consider if it were changed - although this is entirely theortical at this point and still don’t have any examples of where changing it would cause problems.

On the other hand, we know 100% that it’s problematic the way it is now.

So far, the response seems to be to just dismiss it as ‘meh too hard, if you don’t like it just go make a macro’ - not a great response to be honest, so it would be nice to know if it has been or will be properly discussed by mcneel with a view towards fixing the issue.

I understand this is not a “coding” bug and that the tool is behaving as it was programed, but I think the operation of it needs to be assessed from a functionality and user experience perspective.

1 Like