I must something wrong here. I have a circle that is slightly off.
So I do set XYZ Coordinates and change the Y coorinate:
Rather than moving, the circle is getting crushed
What do I have to do to just move the circle with precise positioning
Select circle, Move, use Cen osnap, snap to circle center, type exact coordinates or snap to something existing…
fwiw, using SetPt will set all points to an equal value… same X,Y, or Z value (or any combination of)…
for example, using the black angled rectangle as the starting curve… then SetPt on the Z axis… or setPt on the X…
Is there some way in the move command to specify relative distance or non-movement.
If I want to move to X, Y and keep Z unchanged, is there simple way to specify that?
If I want to move X by n and keep Y and Z unchanged, is there simple way to specify that?
there are a few ways to do that in rhino… my personal method would be to move in the two directions independently of each other… (first move X by desired length… then the same with Y)
i use the shift key a lot to temporarily engage Ortho… while you’re moving an object, press & hold the shift key and the direction will lock to the nearest degree of your ortho setting… (which by default is 90º… or- it will lock to the X or Y axis.)
once you have it on the desired axis, press the tab key… the tab key will lock the move to your specified vector.
at this point, you can take hands off keyboard and mouse and the cursor will still be locked to your desired direction… then enter the distance you’d like.
I have a circle that I want to move the coordinates to round value.
Now I do a move command
I enter nice values:
Then I see where the circle moved to.
I told it to go to :
0.0,0.2343750,9.9375
It ended up at:
0.0,-0.2343750,-9.9375
What is that?
You are specifying a 'move to"-point in CPlane coordinates, but your properties window shows world coordinates. Did you manipulate your CPlane position or orientation? Try changing it to “World Top”, and retry your move. (Alternatively, you can specify a point in world coordinates, like ***w***xx,yy,zz).
I did not change the Cplane at all.
I have found Rhino for Mac to be very impressive, especially considering it is a V1 product.
However, I find object position to be its weakest feature. There are too many steps required to simply move something to specific point.
Rhino V1 for Mac is simply Rhino V5 for Windows with a few features removed and a somewhat different interface. Therefore, it’s actually a pretty mature product, considering Rhino for Windows has been around since about 1996.
Somehow I think you’re making it more complicated than it is. Move in Rhino is From (point) → To (point). Either or both point coordinates can be typed, object snapped, or just randomly mouse clicked. There are a raft of possible distance constraints, plus relative moves (using “r” or “@”) and smart tracking…
–Mitch
Welcome, Big Jim! I agree with you on this.
Relative moves (and snaps) are more involved than they could or should be. While one can get Rhino to do what they desire, simple tasks often take an unnecessary amount of effort and/or familiarity with Rhino-specific methods.
Mitch is right about the “r” and “@” prefixes for relative moves. That said, very few new users discover this tidbit soon enough (if at all!) and we’ve seen a number of posts on this particular topic. One can find a number of useful “accuracy tips” here. And it’s well worth reviewing this document from Day One with Rhino.
One cautionary note is that unlike most other programs I’ve used, Rhino has one serious tripping hazard— Ortho is over-ridden by snaps. One may be drawing (particularly in 4 view) with Ortho on and a line appears to snap to the desired object in a way that “looks” constrained orthogonally and correct—however, when switching to perspective or another view, one more often than not (if they have a thicket of geometry) finds that this new element has snapped deep into space in an undesired way. For the life of me, I can’t figure out any instance where this behavior is desired.
It would be great for snaps and relative drawing to be more intuitive. I believe both would improve one’s modeling efforts (especially as they are introduced to Rhino). Improving Ortho’s behavior, on the other hand, is a much bigger deal since there is currently significant potential for serious errors.
~Dave
How exactly might they be improved to be more intuitive and still retain their functionality? What would you change, what would you put in, what would you leave out?
I can. I work with Ortho on all the time. If I want to snap to some point, I do want to snap to that point regardless if it’s on my ortho line or not. If I don’t want to snap, then I hit the Alt key. You can also work differently, have Ortho always off and turn it on with the shift key when needed, or have osnaps always off and turn them on with the alt key when needed. Either way, it’s easy to snap to something you don’t want when working in a busy area, whether Ortho is on or not; as far as I know there’s no mind-reading workaround for this aside from zooming in and making sure where you’re snapping is really where you want.
–Mitch
Thanks for asking, Mitch. Desired behavior, in addition to existing methods (likely not “instead of”) is: While geometry is being drawn (such as the second point for a line), one could “on the fly” simply toggle a key (meaning: “tap and release”—or, I guess, one could even hold the key down) that serves as a keyboard shortcut for the desired snap. Optimally, one could also change one’s mind mid-routine, pressing a different snap shortcut before selecting the second point. I’ve used a number of programs with this method and it is MUCH faster and more convenient than even the under-mouse-snap-pop-up (which I is what I always use now in Rhino).
Pascal, a while back, suggested this desired behavior was currently possible using Aliases. However, I tried his suggestion and it “almost” worked, but not reliably. He then tried the same and found it didn’t work well for him either.
Here’s an easy example (with one point and two lines) illustrating the existing Ortho problem, and why I believe it is quite hazardous.
Ortho_Issue.3dm (37.5 KB)
- Open file
- Use Four Square View
- Enable only Point and End Snaps
- In Front view, start a new Line at the Point (-10,0,0) with Ortho enabled. (Grid Snap, Planar, Smart track are all OFF)
If you’re getting what I’m getting (which you can only see in the other windows), the new line snaps to the end point of the line in front (0,-11,0) of the desired line (0,0,0). However, when looking solely in the Front view (where one is drawing, and other views may be closed), the new line “appears” to snap to the desired 0,0,0 endpoint—which is the expected behavior for Ortho—however, it is not actually orthogonally snapping, as desired, but snapping to a non-orthogonal point on the line in front. This might sound like a rare example, but for those of us who work with complex geometry It. Happens. All. The. Time.
You might ask, “Well, what if there was no line endpoint at 0,0,0, and only the other line? What would you want to happen then if Ortho was ON?” (See, hopefully I’m prepared for you here!) 
Answer: Nothing. No snap of any kind would or should be displayed. Snaps when Ortho is ON should only display if a geometry is truly orthogonal in the desired operation.
If my desired behavior were implemented, Ortho would work not only as expected, it would also serve as a helpful double-check confirming that geometry was truly orthogonal. (Much the same as when one attempts to join a bunch of lines that appear to be closed, only to find that the curve is still open due to some irregularity that one must diagnose and fix.)
Now, back to the question you might pose: if there really was no endpoint that is truly orthogonal, a snap would in fact display only if Ortho was OFF. This would be expected and helpful at this point.
Does this make sense and do you see how the existing behavior of Ortho can easily create some really nasty errors?
~Dave
[quote=“DigiFabLab, post:12, topic:25794, full:true”]
If you’re getting what I’m getting (which you can only see in the other windows), the new line snaps to the end point of the line in front (0,-11,0) of the desired line (0,0,0). However, when looking solely in the Front view (where one is drawing, and other views may be closed), the new line “appears” to snap to the desired 0,0,0 endpoint—which is the expected behavior for Ortho—however, it is not actually orthogonally snapping, as desired, but snapping to a non-orthogonal point on the line in front. This might sound like a rare example, but for those of us who work with complex geometry It. Happens. All. The. Time.[/quote]
use the tab key… that’s like the 3rd most used key in rhino 
(for me at least)
Totally! Tab is a lifesaver!!! In many ways better than Ortho since one can work in Perspective very easily (and reliably).
(For those not familiar with this little piece of wizardry, the Tab key, pressed while drawing, constrains the direction one’s cursor moves in (both forward and backward) based on the vector of the cursor when Tab is pressed.)
Ironically, no mention of the Tab key in the Accurate Modeling article. Not sure how or when I discovered this (certainly years after using Rhino, maybe watching some online video or something) and fer’ sure worth adding to the article if anyone from McNeel is watching this thread.
~Dave
One of the main problems with any of the keyboard inputs is how an in-command keypress is interpreted - it could be something like an object snap, but it could also be the first letter of a command option. So for example, if you have “I” as your shortcut for intersection object snap and you use the Copy command, how is “I” to be interpreted? The InPlace option or the Intersection object snap?
I’m willing to bet those programs did not have a command line interface… correct?
–Mitch
Correct.
Are you suggesting in-command snaps will not work technically because of the command line, or simply require careful implementation to avoid conflicts?
What careful implementation could avoid the conflict I cited above…?
–Mitch
Three possible approaches:
A) Pre-Command: Choose shortcuts that don’t conflict with any other Aliases.
B) In-Command: Choosing shortcuts (same as above), but which also do not conflict with any in-command shortcuts for operations which utilize snapping. Likely some (many?) in-command shortcuts would have to be revised.
C) For “A” and/or “B”, choose shortcuts that use a modifier. Less ideal, but might reduce conflicts.
While “B” (In-Command) operation would be ideal (if it’s even technically possible), this would be more work no doubt. However, even “A” (Pre-Command) shortcuts would be a big step forward.
The part I don’t understand is that I tried “A” as Aliases and it didn’t work reliably. Why not? If McNeel were to develop Snap shortcuts, is there some other internal mechanism that would work more reliably, such as making this part of rhinoscriptsyntax?
On another note, did you happen to look at the Ortho issue and have any reactions?
~Dave
Simply given that
- Command-line options can be ANYTHING - i.e,. start with any letter you can imagine a word can start with…
and - Aliases can also be anything you could imagine from one letter on. You can even alias other aliases.
I don’t see how either A or B could be made to work without largely restricting the user’s ability to customize their workflow, or having to completely re-write the command line interface.
I don’t know. What did you try that doesn’t work?
I did look at it but I don’t have a reaction… I just don’t work that way, 98% of the time I’m in Perspective view so I see where I’m snapping, so for me it’s not an issue.
–Mitch
IMHO, the fundamental problem is that there are too many steps required to do simple move and resize operations. You have the What command and the Object panel that display information that one would want to change but it is read only. There should be something like that, that is read/write.
Turbocad has a simple, intuitive solution. There is a status bar displayed for every selection:
Once conceptual difference is that Turbocad has the notion of a persistent “reference point”. Every object has a reference point that identifies its location. Normally the reference point is the center of the object but you can change it to be any point on the object (or group of object) and easily reset it to the center. I am not aware of anything like that in Rhino, which might make something like this more difficult to inplement. (E.g., when you scale, you select the reference point each time.)
In Turbocad, if you want to move something 1" up, you (1) select the object and (2) enter 1" in the Delta Z block; at most 2 steps and usually 1 step.