Box 3 point not using c-plane for extrusion height

Rhino
1

Hi McNeel team,

I’ve been using the Box-3pt command a lot more lately and I’ve noticed an odd/annoying behaviour with it. Rather than using the active c-plane to determine the ‘Height’ of the box (like the other box commands) it seems to create it’s own plane using the 3 points used to define the base rectangle. The problem with this is that the inferred plane is flipped depending on which direction you draw the points (ie clockwise or counter-clockwise). So a ‘height’ of positive x sometimes goes in the wrong direction. What’s more annoying, is that while the other box commands allow you to enter a number and then click on screen to define the direction, Box-3pt doesn’t have this option and is limited to extruding in the direction defined by the inferred plane.

Is this how the tool was intended to behave? Given the prompt is “height”, and the behaviour of the other options, this seems like a bug to me and the tool should be able to extrude a box upwards, regardless of if the base rectangle was constructed CW or CCW.

This is not a new issue either. Was first raised here:
https://discourse.mcneel.com/t/issue-box-3pt-height-counter-intuitive-behavior/121695
Although I don’t think they got as far as working out the cause of the odd behaviour.

Thanks, look forward to getting this one resolved.

2

It was actually also raise in the below posts and never resolved.
https://discourse.mcneel.com/t/wish-box-3point-height-always-in-wcs-direction/127495
https://discourse.mcneel.com/t/negative-height-in-box-3-point-height/70674
https://discourse.mcneel.com/t/bug-entering-dimensions-for-box/70342/6

3

Hello - as far as I know this is the designed behavior - keep in mind that the box base can be oriented any way in space and is not constrained to having the points picked on the CPlane.

-Pascal

4

Hi Pascal, thanks for the prompt response.
Is there any reason it was designed this way?

Other box methods give you an option to define the direction of the height to be either side of the cplane based on which side the cursor is on.

The current behaviour of Box 3pt means you need to remember which direction clicking results in which direction extruding, and limiting the order in which you have to select the points also limits the usefulness of the tool.

5

As a simple example:

image
image1273×785 78.5 KB

If I want to create this white box aligned to the corner/edge of the orange box, I would

  • snap to the corner
  • snap to the edge
  • draw out the width
  • enter ‘1500’ for the height.

However, with this does not work with the way the tool is currently implemented. When I get to specifying the height, if I want to enter a value then I cannot also define the direction. The direction has been ‘locked’ based on the direction I moved the cursor when selecting the first 3 points.

This is contrary to the way almost every other command in Rhino seems to work. If I were to draw a 3pt rectangle, and then use the ‘extrude curve’ command, I could type a distance and then specify a direction, but for some reason the 3pt box command can’t.

The same constraint is an issue when creating a box with points that are not picked in the cplane.

Perhaps my post title doesn’t correctly reflect the issue. I’ve learnt a little more myself since writing that. The issue isn’t that the command doesn’t use the c-plane, the issue is that it doesn’t let you specify the direction in the same way every other command does. This is more evident when drawing the base rectangle in the cplane because there is a much clearer ‘up’/‘positive’ direction but no less of an issue when drawing in other orientations.

6

The image in my example I worked around the issue. What you actually get is this:

image
image1126×888 73.6 KB

Where specifying ‘1500’ results in a downwards extrusion, with no option to select one side or the other. To get a vertical extrusion here you’d have to type ‘-1500’ which is incredibly unintuitive. And I can’t see any reason you can’t just enter an absolute value and then specify the direction on screen like with almost every other similar command, or any situation where the current behaviour would be an advantage.

1 Like
7

Hi Josh- I understand, but now imagine your 3 points are not in the CPlane - in some arbitrary orientation in space - how would you specify the direction if you could not conrol it by base plane direction? I believe that is the intent here.

-Pascal

8

I’d do it by indicating the direction on screen with the cursor, the same as many other commands like extrude curve for example. The way this command should work, is basically 3pt rectangle followed by extrude curve. That would allow you to type a distance and then specify the direction on screen with your cursor.

I would certainly not do it by arbitrarily implying it based on the order the points were selected in - given the use of those points is mostly to specify the location and orientation of the base rather than the extrusion, and trying to get it to do both often doesn’t work.

If this is a deliberate implementation and there’s some particular use case I’m unaware of where this particular behaviour is actually more useful than defining the orientation by clicking on screen, then there should at least be a command line option to ‘flip’. But it still seems to me it’s just a coincidence of how it’s been coded more so than an intended behaviour.

1 Like
9

Is the main advantage of using box 3pt that you can use those points to define a ‘positive’ extrusion direction? or that you can draw a box that’s aligned to some geometry/orientation other than the cplane.

At the moment it’s being forced to do both, and this is what causes the conflict.

Using the first 3 points to specify the orientation makes sense. Don’t have many better options for that.
Using the first 3 points to define the extrusion direction doesn’t, and there are plenty of examples of other commands that do it better.

10

Well, in this case you are able to specify a particular plane and use it for direction - that is not the case for ExtrudeCrv - I believe that is the intent of the three point version. This way it can be predictably scripted, for example.

-Pascal

11

Pascal, I do not think that is the intent of the 3pt version at all.

For starters, there are MUCH better ways of defining a boxes extrusion direction than picking 3 points in a specific CW/CCW direction to define a plane

But secondly, just go and read the way the command is described. It even falls under the heading “Base rectangle options”. These points are supposed to be used for the base rectangle location, size and orientation. NOT extrusion direction. The extrusion should follow the same “type a distance, click a direction” approach that almost every other rhino command uses.

Just because those 3 points could be used to define the plane, doesn’t mean they should be.
Trying to use 3 points to specify 4 bits information does not work, which is why you’re left with an “implied but not really specified” instruction in the form of the CW/CCW click orientation. But the fact that it overlaps with the 3 “defined” points means it cannot be specified without potential conflict. And all this confusion to save 1 single click to just define the orientation? I don’t believe that’s how it was intended.

People clearly aren’t aware of the nuances of this behaviour, as shown from the 4 posts that have raised it previously, none of which have mentioned the CW/CCW issue. This is just further proof that it’s not a designed behaviour (it at least not a user friendly one).

2 Likes
12

@pascal: Do you have any way to backtrack who designed and coded this command and getting them to explain the design and it’s relation to the points raised?

1 Like
13

Although AFAIK none of the other Solid Primitives work that way. If one has a base on a plane AB, then a positive value extrudes in the C direction, where ABC are orthogonal axes and follow the right-hand rule. Any click of the mouse to indicate the opposite direction changes the direction but overrides the distance.

In terms of indicating in the model which direction the extrusion will go, the 3pt box shows a preview of its position when you type in a distance. This is consistent with all the other Solid Primitives. If you don’t like the direction you insert a negative sign before the value and it flips.

A one-click flip would be slightly more convenient than repositioning the cursor and typing -, but is not something I’d put ahead of many other issues on the backlog.

On the basis that prevention is better than cure, I’d be keener on an indicator of the +ve extrusion direction appearing on the base plane before asking for a height value, so you know whether to enter a positive or negative value.

I would not like to see a solution that adversely impacts the ability to script the command, per @pascal’s point.

14

Hi Jeremy,
From the original topic here and everything that’s been discussed so far you’ve picked out a rather odd point to respond to.
Fair enough no not all the extrusion tools works like that, but ask this question then:
“are there any other solid primitive tools that, when drawn on the cplanes, and have all positive values entered, will create an extrusion in the negative direction?”
Or even better
“Are there any solid primitive tools that when drawn on the cplane and have all positive values entered will sometimes create a positive extrusion and sometimes create a negative extrusion?”
And most importantly “is this user-friendly behaviour?”

All of the other commands are at least consistent.

Box diagonal for example seems to make do. A positive value always results in an upwards extrusion. As I stated earlier to Pascal, just because we can use 3points to define a positive orientation, doesn’t mean we should. Especially when those points also already need to specify the location, orientation and size of the base rectangle. In most cases it will make most sense for positive to be cplane positive. In other cases, you’ve got 50/50 chance so you should be able to specify it. When creating an extrusion, from a user’s perspective the value entered “height” is just specifying the scale of the 3rd dimension.

I cannot comprehend any scenario where a tool that, using a positive value for “height” will half the time extruder downwards, is useful to a user.
Also, user’s should not need to have an understanding of the theory of creating planes, right-hand-rule etc just to use understand and use a basic Box command.

Since coming across this issue I’ve shared it with a few others and they’ve all been baffled by this behaviour. I’m not suggesting it needs to be made a priority by McNeel to fix, but it would at least be good if we can establish is this is the intended functional behaviour from a user’s perspective, or just a quirk/byproduct of how the tool has been coded.

I understand that yes it is still possible to get the extrusion to go the other way by editing the distance, but haven’t to constantly stop and check and then go back and edit slows down or workflow to an extent that really just seems unnecessary. Not too mention frustrating for a designer who is using a tool and having it arbitrarily behave differently half the time.

I appreciate greatly the amazingly prompt response from now a number of people on the McNeel team. But so far the response seems to just be trying to explain why the tool ended up the way it is, not whether or not that’s how it actually should be.

15

Just a little background on this here. I work in architecture, and we are currently undergoing a pilot test on whether we switch the company from SketchUp to Rhino. I am running a training program for it.

Little issues like this will be confusing and frustrating for users in our company. So I need to know what tools and workflows I can train then in that are going to allow them to work efficiently and aren’t going to create these extra points of friction.

16

Hi Josh,

Have you never tried using Box Diagonal, to take your example, in the front viewport? A positive height results in an extrusion in the world negative Y. That threw me too, until the right-hand rule was explained to me (again, but that’s another story). It’s a great shame that the Right-hand rule is hard to find in the documentation - it should be front and centre.

Same direction for all the other solids. And height is an odd term in the WCS directions when applied to the front viewport, But it makes sense in the context of an object extruded from a base plane.

Regards
Jeremy

17

Why not, if that makes the behaviour predictable? I used the Box commands for many years before I hit a scenario where the extrusion went the opposite way to my expectation. My reaction was “it’s a bug, report it”. Pascal gently reminded me of the Right-hand rule and what was happening then made sense. I could move on, I can anticipate whether I need a positive or negative value.

I’m not saying that the Rhino user-interaction around Solid Primitives is the best it could be. But I do think it is good enough that I’d be reluctant to see McNeel redeveloping it while there are far more significant issues for their finite workforce to address.

18

Well, that will be down to the quality of your training programme! :wink:

1 Like
19

This is very interesting, and while taking us a step closer understand how the tool is technically implemented no closer to understanding whether that’s actually the desired behaviour for users.

20

Why not teach the right hand rule?

  1. It shouldn’t be necessarily so it’s wasted resources.
  2. Some people just won’t get it. Having also taught robotics I am familiar with trying to educate people on concepts of frames of reference. Being able to rotate and change the height of the cplane is as much as some people will be able to handle, let alone needing to keep something more abstract like the RHR in their mind just tell draw a box, while also making sure that the RHR points they select are also logical for the actual location size and orientation including snapping to existing geometry.

All this is redundant if we can just get some clarity on of this is actually the desired user behaviour.