AutoCAD - Moving 3D Objects in One Axis or Plane Using Point Filters, Relative Coordinates Not Working

[grenier4]

To put it simply, I'm trying to precisely move objects around in 3D space relative to other objects without using the 3D Gizmo. I'm often trying to do this in an orthogonal view such as Front, Left, etc. (I'm avoiding the 3D Gizmo at the moment because it only works in 3D wireframe and it often appears in the middle of the 3D object; it has to be relocated to the desired location on the object before the move can happen.) Point filters seem to be the most promising way of doing this but I just can't get them to work right.

Let's say I invoke the Move or 3DMove command because I want to move an object in only the Z direction. I click on a base point on the object. I invoke a point filter of .z and select a destination reference point, perhaps on some other object at a different elevation. The object is moved to that z value but then AutoCAD is asking me for xy coordinates before it will complete the move. I want the xy coordinates to remain unchanged. I was only trying to move the object in the z direction. How do I tell it to just use the existing xy coordinates of the base point? A relative coordinate of 0,0? No dynamic input is giving the desired result... @0,0,0, #0,0,0, *0,0,0 all try to move the object to the drawing origin. Enabling ortho only seems to help if I'm in a 3D view and not an orthogonal view.

Perhaps the answer is the 3D Gizmo is the only effective way of making these kinds of moves, I just don't understand why point filters can't be used reliably in a similar way. I'm 95% of the way there but I can't tell it NOT to change the values of the other coordinates. I have the same issue if I'm moving in two axes at once. If I use a .xy point filter to specify the destination point it then wants a z value... but I don't want the z value to change.

For context, I'm a long-time Vectorworks user and I'm used to making single-axis/planar moves of 3D objects from orthogonal views with essentially no problems. In AutoCAD, I'm finding it constantly wants to throw objects forward and backward in the screen plane when I'm in a front or side view, for example. This seems to happen no matter what combination of snaps I try. Ideally, it would be nice if there was a way to tell AutoCAD to just restrict movements to the screen plane in certain contexts. Front view? Only allow movements in XZ. Left view? Only allow movements in YZ. Such behavior would be much more convenient. Vectorworks seems to do this innately. 

[ The subject line of this post has been edited for clarity by @handjonathan Original: Moving 3D Objects in One Axis or Plane Using Point Filters, Relative Coordinates Not Working ]

[j.palmeL29YX]

---

@grenier4 wrote:

In your video you move an object ...

I'm trying to move an object ...

---

OK, even if you don't want to show us in a dwg what you want, my next attempt (>>Video<<). 

Assuming we want to move the black cylinder to the X-value of the blue cylinder, to the Y-value of the red cylinder. Both cylinders are on a different Z-level, but the black cylinder must not move in the Z-direction. 

One of the possibilities is shown in the video. 

[Kent1Cooper]

---

@grenier4 wrote:

.... I click on a base point on the object. I invoke a point filter of .z and select a destination reference point, perhaps on some other object at a different elevation. The object is moved to that z value but then AutoCAD is asking me for xy coordinates before it will complete the move. I want the xy coordinates to remain unchanged. ....

---

Just type "@" when it is asking for the XY coordinates.  It will use those of your base point.

[grenier4]

---

---

Just type "@" when it is asking for the XY coordinates.  It will use those of your base point.

---

That is what I assumed I needed to do, but I could not get this to work. If I typed @ it wanted coordinates in Dynamic Input no matter what. I tried turning off Dynamic Input and then I could get this to work. It does seem to work with Dynamic Input on, but only if I go down and place the cursor in the Command Line and then type @. Does anyone know why Dynamic Input is interfering with this order of operations? Is there a way to do this without having to turn it off or place the cursor in the Command Line? (Besides creating a macro)

[grenier4]

---

In this case (Z) - read about OSNAPZ

---

Thank you, this is helpful and does seem to make a notable difference. As the name would imply, this does seem to require having the UCS match the orthogonal view, meaning if I'm in a front or side view I need XY to be the view plane and Z to be in/out of the screen. As long as that is the case this seems to work.

Thank you for the breakdown of the macro steps.

---

Move <object selection> <1.point> .Z <enter> @ <enter> <2.Point to get XY value>

---

I think I understand in theory what this is supposed to do. You're saying you want the Z value of the destination point to be the same as the Z value of the base point, and then get XY from some other reference. When I try this I can't make any sense of it. When I try it from an isometric view it does not seem to preserve the Z value at all.

[j.palmeL29YX]

---

@grenier4 wrote:

---

When I try it from an isometric view it does not seem to preserve the Z value at all.

---

It does not seem to preserve or it does not preserve?

If you follow exactly the steps suggested by @cadffm (and also by me and others) it should always work. It doesn't matter from which direction you look at the drawing. Please show us what you're doing ...

BTW: OSNAPZ only helps if you want to move in the XY plane and ignore the Z values. It doesn't help if you want e.g. move in the XZ-plane end ignore the Y-values. In this case you should use the point filters as described several times.

[grenier4]

---

---

It does not seem to preserve or it does not preserve?

If you follow exactly the steps suggested by @cadffm (and also by me and others) it should always work. It doesn't matter from which direction you look at the drawing.

---

Regarding this:

Move <object selection> <1.point> .Z <enter> @ <enter> <2.Point to get XY value>

When I was first trying it, no it did not seem to be working. I tried it again and yes it does work. This order of operations was confusing to me, because this is what I have been doing instead:

Move <object selection> <base point> .XY <destination point> [Prompts for Z] <@ enter>

---

BTW: OSNAPZ only helps if you want to move in the XY plane and ignore the Z values. It doesn't help if you want e.g. move in the XZ-plane end ignore the Y-values. In this case you should use the point filters as described several times.

---

Right, so if you are working in an orthogonal view looking at the YZ or XZ plane it probably makes more sense to change the UCS to match the view (now looking at XY plane) than it does to use the Point Filtering method. (With OSNAPZ set to 1). It would be useful if AutoCAD just treated movements done in orthogonal views similarly whether you were looking at XY, YZ, or XZ but that doesn't seem to be possible. I'm curious how common it is for people to use OSNAPZ to ignore Z values. For me personally, if I'm in an orthogonal view I NEVER want objects to be snapping in and out of the screen (in the direction that I can't see what's happening).

My question still remains about how to use Dynamic Input with the Point Filtering procedure above. Why is Dynamic Input interfering with the ability to type @<enter> in the command line? Is there some setting or method there that I'm not aware of? Do a lot of people just not use Dynamic Input?

[cadffm]

>>"My question still remains about how to use Dynamic Input with the Point Filtering procedure above. "

With the absolutely identical input I wrote above!

>>"Why is Dynamic Input interfering with the ability to type @<enter> in the command line?"

It isn't (or it shouldn't). Record a screencast and show us your problem (please work slowly, so we can better following all details)

>>"Is there some setting or method there that I'm not aware of?"

If so, I am aware of it too.

>>"Do a lot of people just not use Dynamic Input?"

A lot: YES (but what means 'a lot' in % ? I don't know.

- A lot of long time users disable the dynmode all the time.

- A lot Users who starting with Autcad in Version 2006 and newer using dynamic input all the time.

Good experienced users switch all modes from task to task as and when it makes sense.

Two basic situations and the most used on my side for example:

1. Dynmode off is my usual daily setting

2. Dynmode=3 and Dynpicoords=0 if I have to enter the most points relative

[grenier4]

---

>>"Why is Dynamic Input interfering with the ability to type @<enter> in the command line?"

It isn't (or it shouldn't). Record a screencast and show us your problem (please work slowly, so we can better following all details)

See this YouTube video showing my issue with Point Filters, Dynamic Input, and typing @<enter> to preserve the other values of the base point when moving objects. DYNMODE is set to 3.

Dynamic Input is interfering when I'm using a two-coordinate Point Filter (YZ). For some reason it's not interfering when I'm using a one-coordinate Point Filter (Y).

[cadffm]

Thank you for this video  - bad quality, really hard to see - but it was good enough.

It shows your steps and I can reproduce it, so it works as designed (not as expected, but as designd)

Okay, you don't followed my sample, you used another one!

What is the difference between what I said and you did: The Order!

I can't say why it not works in your case, but if you following my sample it works.

First: .X @

then choose your YZ Point (but you don't need to start .YZ filter now, just click to the point)

Just:

move/object selection

basepoint<click>

.X

@

<second point>

done.

HTH?

[grenier4]

---

It shows your steps and I can reproduce it, so it works as designed (not as expected, but as designd)

---

I'm not sure if we can say it's working as designed, since it's interfering with something that should be a valid operation (and is a valid operation when using single-coordinate point filters). You shouldn't have to avoid using two-coordinate point filters in order be able to type @<enter> when Dynamic Input is enabled.

---

Just:

move/object selection

basepoint<click>

.X

@

<second point>

done.

---

I see how this works, it's just a different way of thinking about the same desired result. Some users are going to think about this problem as "I need to lock the X value of this object during move" and others are going to think "I want to constrain the movement of this object to YZ." It's a subtle difference, but it does affect what a user may try to do so both operations should work.

[cadffm]

"...so both operations should work."

Also my opinion, tell it to AutoDESK!