Y and Z co-ordinates switch order for polyline

This might be something I’m doing wrong, or getting confused about orientation, but I’ve thought it through and I can’t see where I’m going wrong.

The modelling I’m doing at present involves creating accurate polylines, using 3D-co-ordinates with the Y co-ordinate set to zero, then rotating the shape around the z-axis. On about four or five occasions over the past three weeks, I put in a co-ordinate of the next point, say 3, 0, 21 and instead of the point appearing on front view as 21 “up”, in fact it shows as 21 on the Y-axis. For the remainder of the polyline, I have to use X, Z, Y co-ordinates, for example, 3, 21, 0 to get the shape I want. As long as it works, and doesn’t cause problems in downstream printing, this is annoying but not a show-stopper.

I don’t have a reproduction scenario yet, but I think the cases where it has occurred I think I will have recently done “Undo” on the polyline wizard and/or Esc-aping (cancelling) the poyline wizard to start again where I realised an earlier point had been entered incorrectly.

Can you think of an explanation for this or should I keep looking out for a reproduction?

Best regards

Phil

Just remember when you are inputting coordinates, that the coordinates are relative to the CPlane in the active viewport. Thus, if you enter 1,2,3 with the Top viewport active, you will have a point at world 1,2,3. However, if you enter the same coordinates with the Front viewport active, you will get a world coordinate point of 1,-3,2. The Z axis in the Front viewport is the -Y axis in world coordinates, and the Y axis in the Front viewport is the +Z world axis.

To avoid this, if you are always wanting world coordinates, use wx,y,z instead of just x,y,z. The “w” forces world coordinates.

HTH, --Mitch

Thanks a lot, Mitch. That helps a lot.

I was aware of the possibility of the active viewport being involved, but I tried making different viewports active without success However, I could well have selected every one except the one I needed.

I’ll stick to the w prefix from now on !

Best regards

Phil

Good explanation, Mitch. Is there a way to make the “W” prefix the default?

I, personally, don’t see why users would always prefer (or even be able!) to navigate 3D space without the W prefix. But, prolly there’s a good reason?

Related to this: would very much prefer a way to make the 0 axes for X, Y, and Z on the C Plane: Red, Green, and Blue. This alone would help reduce the confusion on coordinate directions I witness very frequently in orthographic views (and fall victim to myself when using Rhino intermittently).

While I’m on the topic, adding color and an arrow head to the positive direction for the little icon in the corner would also be a big help. ~Dave

Well, because a lot of work is done in 2D in local viewports/coordinate systems and there you just enter X,Y. If you had to think about which axis was the real world axis in each case, it would be painful/confusing.

–Mitch

I agree with you, Mitch. If 2D viewports can just accept x and y then that is preferable. (I suppose in that case, it’s arguable that Rhino should treat 3 co-ordinates in a 2D viewport as an error)

The problem there is that there are no “2D viewports”. All the viewports are 3D. It’s simply a matter of parallel projection versus perspective projection, plus an orthographic view along one of the axes and the “automatic” setting of a local CPlane when you use the standard Top, Front, Right, etc. views.

It’s perfectly possible to work in a 3D viewport in a 2D way, in fact very handy. One common case is setting a local CPlane in a perspective viewport that is not parallel to any of the principal planes (think of drawing skylights on the sloped roof of a house) you can set your local X,Y and create your drawing in 2D using local XY coordinates, then extrude the parts in local Z.

–Mitch

Actually, I find the opposite to be true. I would much rather think about real X, Y, and Z coordinates (inputing all three, instead of just two) in straight orthogonal views (Top, Front, Side, etc). Translating a desired Z position, into a positive or negative X or Y dimension is a needless brain pretzel, as Philip has accurately described.

Where I do (partially) agree with you is your non orthogonal sloped skylight example, with a custom CPlane. One could arguably enter only X and Y coordinates that are relative to that CPlane. But one could also enter X, Y, and Z coords (also relative to the Custom C plane.

In other words, I believe ideal behavior for defaults would be:

  1. World Orthographic CPlane views work with World XYZ coords.
  2. Custom CPlane views that are not orthogonal to the World would work with relative XYZ coords.
  3. Suggest different grid colors for Orthogonal vs non-Orthogonal CPlanes to help identify this condition.
  4. Ability to change World / Relative coords as an option would be nice for anyone aware of the complexity and has different preferences.

~Dave