Array Bug Right View Rhino 7

create an object go to right view. then array along y axis, it arrays along z instead. array along y in all other views work as expected.

ps:
why do lines not show up as little dots from a side view anymore? they are now practically invisible.

That’s normal. Array uses the active CPlane coordinate system X, Y, and Z axes, so if you have the right view active, CPlane Y is World Z.

no sorry, that is not normal.

i want to array this little yellow dot along y. on the left bottom i have 2 axis showing up. the command line asks me how many in which direction.

why would i ignore the command line questions in this view only.

By ‘normal’ I mean that this is designed-in behavior and the way that Rhino has worked since… 1.0 or earlier. Every viewport has its own CPlane and most commands use local CPlane coordinates unless forced otherwise. All the ortho viewports are +X to the left and +Y up locally.

If you start the Box command in the Right viewport, pick some point there, and then type 10 Enter 20 Enter 30 Enter, you will get a box that measures 10 in World Y, 20 in World Z and 30 in World X

If you place a point in the Right view and type in 10,20,30, the point will be at those local coordinates in that view, but their world coordinates will be 30,10,20. It’s only if you type w10,20,30 that you will get the point directly in world coordinates.

All the Ortho views work this way… Try it in Front.

If the World axis reference indicators confuse you, you can turn them off in the individual display modes.

just to be clear.

in Top, Front and Perspective array corresponds directly with the axis indicators, leading to a straight forward easy to distinguish experience.

now the Right view is the only one which has this quirk… forcing me to ignore all indicators.

i dont see that as a good experience having to remember that, and to be honest i still dont understand why it is so. meaning i probably will have trouble remembering it and not to speak about new users running into it.

so for me it is a bug.

Nope. In Front, if I array an object with 10 in X, 20 in Y, and 30 in Z, I get 10 objects along the world +X axis, 30 along the world -Y axis and 20 along the world +Z axis. (note the -Y, as in the Front viewport, +Z local is equivalent to -Y world)

The Top and Perspective viewports have the same CPlane by default, so they will behave identically. Try changing the CPlane in the Perspective viewport to something tilted off-axis and try the array again.

i have to see into it once again when i get to it, but that means it is even more confusing!

Yup, i thought i checked al other views thoroughly, the Front view has as you say also a curdled up non corresponding array as you say.

So it obviously has a scrambled user feedback.

Been ‘scrambled’ then for the last 22 years or so… Of course, if you consider that the coordinates X, Y and Z are expressed in local (active CPlane) coordinates in the Array command (as in many other Rhino commands), then they are not scrambled at all.

it is not corresponding with the UI, what more is there to say. if you got used to it so be it. for the rest i think that would be easier to understand if it would just coincide with what one sees on the axis.

if that quirk has persisted for 22 years then maybe one could rethink that at some point. i dont want to remember each time i array from the right vie… ahh stop no here i have to see y as z suddenly…

What I’m trying to say is that it’s not a ‘quirk’ just reserved to the Array command - it’s a result of how Rhino works (has worked from the beginning) with local viewport coordinate systems. By default, coordinates X, Y and Z are considered to be in local coordinates unless specified otherwise. If you start adding points to your document by typing X, Y, Z values in the different viewports, you will see. If you add a point at 1,2,3 the result is not the same point depending on if you have the Top, Front or Right views active.

There are a number of commands that obey the same ‘local coordinates’ logic when mentioning the X, Y, Z axes in the command line - notably Mirror and ScaleNU - there are a few others as well. Generally when an axis is specified, it it relative to the local CPlane, such as Revolve or Plane>Vertical. So all of these commands behave differently depending on which CPlane is active.

All that being said, there are some commands that work relative to axes that have built-in Local<>World switches on the command line, notably Align (option added in V6), BoxEdit and CageEdit. I think Array could also benefit from this. In doing a search of Youtrack, I came up with an 8 year old request for this by @pascal.

https://mcneel.myjetbrains.com/youtrack/issue/RH-11417

Still listed as ‘future’ since its request during the course of Rhino V5… :grimacing:

@dale - could this be moved from ‘future’ to ‘present’ ??

1 Like

oh wow, that is still from the news group times, thanks Mitch

What might also help is to make your Cplane grid visible in the viewport (Display Modes), so you can see the local axis’, X in red, Y in green, Z in blue. (I am still on Rhino 5, the appearance may differ in later versions).

hm, even though that helps a bit, it points out a further flaw. As @Helvetosaur pointed out each cplane has ist own cplane, but since only the Top View and the Perspective View directly relate to the axis icon that further confuses the visual feedback. the cplane should be 3 dimensional and therefore true for all viewports.

edit: further more, when i select an object, having all 4 views running, for instance in Perspective View the gumball correctly corresponds to the axis in all views. When i mark the same object, again with all 4 views open, in the right view it suddenly changes its orientation, corresponding to the local cplane.

maybe there is a logic which explains it, but i certainly would prefer direct visual feedback having a fixed 3d logic.

Yes there is - all of it.

First the ‘axis indicators’ you are talking about are specifically World Axis indicators. They exist to remind you of the orientation of the WORLD axes even though you may be in a view/CPlane which does not correspond to World. The Local CPlane axes are always indicated by the Grid and/or Grid Axes. Do not confuse the two indications.

The colors for the World and CPlane axes are all user-settable options - the conventions/defaults for the local CPlane axes are desaturated Red (X), Green (Y) and Blue (Z). Showing the local Z axis is also optional. The default colors for the World axis indicators are a medium-dark gray - all three.

That is because the Top view is considered “World” - i.e. the XY plane ‘horizontal’, +X pointing ‘right’, +Y pointing ‘up’ and the Z axis pointing ‘at you’ or ‘vertical’ in the Perspective viewports. So that is why the world axis indicators in those viewports correspond to the CPlane axes (by default). You can of course change the CPlane in the Perspective viewport, in that case it will no longer correspond to the world axis indicators either. You can also change the CPlane in the ortho viewports, but it is not recommended - see next part.

Let’s assume that was true, and you set the “Top” world CPlane for all the standard views, including Front and Right. You can actually try this yourself. Now, try and draw something like a circle or a rectangle in either of those two viewports. You can’t. Why? You are looking at the construction plane edge-on. You can’t see to draw anything in those viewports that lies on the construction plane… except maybe a line.

That is why individual views have different construction planes. In Rhino by default, setting one of the ortho views automatically sets the corresponding local CPlane. You can also turn that behavior off if you want, but then you are on your own.

i understand all that, but it does not make sense having a command line not corresponding with what you see. that is where my understanding breaks.

If the world axis icon confuses you that much, you should probably just turn that feature off then. Either in your start-up template or in your display modes.
-wim

no.

i probably expressed myself with the wrong terminology. either way there seems to be some misunderstanding. my issue is that the command line in array does not correspond with a regular 3 dimensional behaviour. i could not care less about a local cplane system in this regards, which screws up the WYSIWYG aka UI behaviour call it what you like…

the youtrack @Helvetosaur was so kind to provide explains pretty much what i am after. would be great if that could be taken into consideration for version 8.

If you need to define an array for multiplying roof tiles on a slanted roof on a house which is not oriented on the X- or Y axis, the CPlane approach comes in mighty handy…

yes and i am not asking to replace that.

imagine this adorable little house i have to fill up with an array of light sources moving from one side to the other. for it being handy i naturally use the right view (not the 4 view at this point), now i use the command array and want to replicate that along the y axis -> see the arrow in the screenshot as an emphasize to the world indicators. i call up array relying on that natural given orientation being prompted with Nr. in X, Y, Z direction, i enter 10 along the world y axis. and voila, instead of what i assume would happen, something else happens.

at this point i have to ask the forum wtf is happening, to get a lecture about cplanes which i am not after, understanding that there is no way to directly relate to what you see and get prompted with currently having to use all 4 views switching on my brain and rethinking my direct approach. even if you know that beforehand, it is rather inconvenient to quickly solve such a banal task. having a check for world orientation would solve that confusion, in that case for a few more commands.

1 Like