Draw a line. Pick the rightmost point of the line and then hoover over the line somewhere (near on). Lock the constraint using “tab”. Enter a value, let’s say 500. Now note that you can either extend the line 500 units or go the reverse direction 500 units (-500 that is). This is all fine.
Now look at the rectangle above the line.
Draw a box using the rectangle as a shape. Wait with the z-value (height) of the box (don’t quit the box command yet). But look what happens - the box can either extend upwards (+) or downwards (-).
Now pick a point on the line (near on) and constrain the z-value direction to the vector of the line.
Now enter a value for the box height. Let’s say 500 again.
Now the box can only be 500 tall (+). It can’t be -500. (BTW: If the value entered is -500, it can only be -500.)
This is inconsistent. When locking the constraint to the simple line and entering a value it acts as if the value is a distance - it has no +/- direction - so both ways work fine.
But with the box command it is distance and direction.
Rhino needs to be consistent here. I think the constraint should only set distance. Not direction.
At the Box height prompt, a typed number isn’t a distance constraint like it is in Line. It’s the height value, and the sign is part of it. The positive direction comes from the base rectangle, so the cursor and the direction lock don’t affect a typed height. This is intentional, so that a typed height always gives the same result, including from scripts and macros.
The OP seems to understand this, but is “irritated” by the inconsistency between the box case and the line case. It is without question inconsistent. The amount of irritation it causes is probably related to the user’s priority between inconsistency and convenience. I suspect that users who have recognized, remembered and adapted to the inconsistency just model away happily using the appropriate technique. I can imagine that there are a lot of users who would argue that one technique or the other is handier for modeling and would prefer their preference to be the one chosen as the standard for both cases.
I agree with the OP that consistency is good. Does your experience suggest that the chosen method is the best in each case for most users?
But I do not think you fully understand. It might be that my explanation is clumsy.
I do understand the the box command is just accepting the height. That’s fine.
The written height can be 300 or -300. That works fine.
But when you write 300 and then you go the negative direction with the cursor, it should allow you to do a box that is -300 tall. Then it would work exactly like the line works.
It can be hard to guess which direction is + or -, depending on how the Cplane is oriented.
In the box case it has nothing to do with the tab-constraint. That’s wrong. The box height is already constrained.
A small video to show what I’m trying to say.
The “height” is set to 500 (without pressing enter). It can now only be a box 500. But it should be able to be -500 as well.
Thanks for the video, that clears it up. You’re talking about typing the height without pressing Enter and then picking with the cursor on the other side. Right now Box uses the typed value as-is, with its sign, both when you press Enter and when you click while the number is still typed. The cursor position doesn’t change it.
i totally agree that this question of direction-input is not solved nicely / consistent.
my wish:
pure keyboard input: finishing with pressing enter / space / right mouse button = pure Keyboard input, direction is cplane and or curve orientation (CCW/CW) and sign of input +/- is the only influence independent on mouse position.
direction by mouse: finish with a left click in the viewport. +/- will only influence wether the direction is with or against the mouse.
the worst we have current: even if you do a pure keyboard input, press enter, and do not touch the mouse at all, mouse position defines direction for extrudCrv … but not for others…
but maybe someone could go through all the different commands etc and come up with a consistent approach on how this is functioning. It causes quite some frustration when command behaviour is not consistent.
When I come to the last parameter “height”, I enter 1000 to finish the box. But due to the way the box is constructed (from left to right) it means that 1000 is pointing downward. I want it upward. Moving the mouse does not help (it should!). Only thing is to write -1000 instead.
Moving the mouse in the opposite direction should change the z-direction.
I come across this problem many times every day. Frustrating and such a simple feature to add / fix.
