# Use of "Set XYZ Coordinates

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)

1. Open file
2. Use Four Square View
3. Enable only Point and End Snaps
4. 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

and
2. 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.