Many Commands need Plane (infinity) / Orientation (fixed spacial Location) / Direction (Vector) / Axis (fixed Location) Input. The Behaviour for those Inputs varies a lot.
_cplane _3point
allows enter / skip first input to keep the origin at 0,0,0
_orient
has the same behaviour for the first target point.
_orient3Pt
will cancel if there is no input for the first point
_gumballRelocate
will cancel if there is no input for the first point
_cplane vs. _iPlane
should have the same input / option naming
_mirror
has a bad naming because
Mirror → x is a 2d approach / naming (XZ Plane)
Mirror → y is a 2d approach / naming (YZ Plane)
Mirror → z does not follow this naming concept (XY Plane)
_rotate vs _rotate3d vs _revolve vs _arrayPolar
_orient vs _orient3Pt
most commands become “3d” with additional Axis / 2nd point input.
rotate and orient have 2d and 3d version that can not default to each other.
there is many many more…
The first step in learning CAD is to understand geometry.
For example it s important to understand the difference between a movement (vector somewhere but with length) and an axis (fixed position, but without length) (revolve, rotate3d, …)
that s already a challenge for many newbies’ brains.
Now this Geometry-Knowledge has to be translated into “CAD-Input” (RhinoGet..)
It would be consistent if the same Geometric element has the same interface.
This Input issue is now combined with other UI / Input challenges:
(maybe this should be split to another topic ?)
(1) default inputs - Points / directions etc:
what happens if i press enter:
“press Enter to use current c-plane z-axis direction” ( _revolve stated in the command line)
“Target Point 1 <Reference point 1>” ( _orient which means: “press Enter to use Reference Point 1 as first Target point”)
some commands do not not explicit state default option / input
some commands cancel if no input is provided (_orient3pt)
(2) verb-noun / noun-verb (command first / selection frist)
it is great that rhino allows both approaches.
But for many new users this is challenging as it gives two (micro) workflows for each command.
(3) Options at first step only vs Options that survive the entire input-Cycle
some commands require a strict linear input of options - if you miss “multiple matches” from _matchSrf before clicking the first edge you need to cancel.
Some commands allow to select “delete = yes/no” until the last enter is pressed.
Some commands like _filletEdge behave non-linear and allow back and for (“select edges” = go back to step 1)
(4) Saved / recall / forgotten inputs or options
Some options are saved (“delete = no”)
Some options are saved and mess up usage completely (_revolve Startangle= 21.456 )
Some options can be recalled (“use last axis” in arraypolar).
Some options are not saved (_offset both sides).
ok… but now sum it up:
→ command with 2 Versions for 2d/3d or single version **
→ verb / noun vs noun/verb
→ optional usage of default input or command that cancels **
→ options are saved / not saved
→ options that are eventually only available on first input step **
→ inputs same Geometry with different interface **
if each of this choices is *2, it is 64 different scenarios. for a single action.
a modern ui / input concept should be able to skip 3 or 4 (marked with **) of these aspects and make them consistent. this would dramatically reduce the amount of scenarios and shows why consistency is so important
thanks for addressing this topic.
kind regards - tom